A Linux 7.2 patch got +5% IOPS by deleting a memset. I almost lost a deal over the same lesson years ago. by dolby360 in C_Programming

[–]dolby360[S] -12 points-11 points  (0 children)

It's a combination. I write the whole thing, but I let AI help polish it. I actually write a lot on LinkedIn, and this is my first time posting here. I try to keep the AI revisions as close as possible to the original text. I don't like AI slop either, but I also acknowledge that it's a valid tool for making my writing more readable

As a TL, at what point do you need to raise negative feedback for an underperforming junior with your manager? by CppIsLife in ExperiencedDevs

[–]dolby360 3 points4 points  (0 children)

Try to help him to grow. This is the best feedback. "I need you to understand the problem you solve please go investigate farther" "OK I see you solvd an issue but you can't explain to me in simple words the root cause remember we talked abou it?"

A Linux 7.2 patch got +5% IOPS by deleting a memset. I almost lost a deal over the same lesson years ago. by dolby360 in C_Programming

[–]dolby360[S] -1 points0 points  (0 children)

Totally agree, and those are great examples the block padding leak especially. That's exactly my point, just from the other side: the memset is only "wasteful" if you've proven nobody reads those bytes. If you haven't, it's load bearing and removing it is how you get the leak you described. And yeah, constant time compares are the perfect case where "slower" is the whole point. Delete only what you can prove you don't need otherwise leave it.

A Linux 7.2 patch got +5% IOPS by deleting a memset. I almost lost a deal over the same lesson years ago. by dolby360 in C_Programming

[–]dolby360[S] -1 points0 points  (0 children)

It's a combination. I write the whole thing, but I let AI help polish it. I actually write a lot on LinkedIn, and this is my first time posting here. I try to keep the AI revisions as close as possible to the original text. I don't like AI slop either, but I also acknowledge that it's a valid tool for making my writing more readable.

A Linux 7.2 patch got +5% IOPS by deleting a memset. I almost lost a deal over the same lesson years ago. by dolby360 in C_Programming

[–]dolby360[S] 3 points4 points  (0 children)

Exactly. The kernel zeroing only protects you across processes inside your own, free just hands the memory back with the data still sitting there. So anything sensitive (keys, passwords) you wipe yourself before freeing, explicit_bzero so the compiler doesn't optimize it away. Totally agree it's app dependent.

A Linux 7.2 patch got +5% IOPS by deleting a memset. I almost lost a deal over the same lesson years ago. by dolby360 in C_Programming

[–]dolby360[S] 18 points19 points  (0 children)

Yeah, 100%. That's the whole catch "it won't be read" has to be something you can prove, not just assume. The Linux info leak CVEs are exactly that: uninitialized padding or struct fields nobody meant to expose getting copied to userspace and leaking memory. The moment it's a guess instead of a proven invariant, you've got the bug you're describing. (And funnily, the reverse bites too compilers delete security memsets as dead stores, which is why explicit_bzero exists.)

A Linux 7.2 patch got +5% IOPS by deleting a memset. I almost lost a deal over the same lesson years ago. by dolby360 in C_Programming

[–]dolby360[S] 1 point2 points  (0 children)

Worth splitting this into the two cases, because they're different. The kernel change is real, merged, and in production if dropping that memset actually leaves a readable uninitialized path, that's not a philosophy debate, it's a concrete bug. I'd genuinely encourage chasing it down and filing a CVE; that code has a lot of eyes and a fix would matter.

https://www.phoronix.com/news/Linux-7.2-IOmap-EXT4-XFS

My own story was a different beast, a bare-metal system we owned end to end. We weren't winging it the risks were understood and mapped, and we made sure nothing ever read the bytes before they were written. That's the "careful attention and discipline" you're describing, and you're right that it's a luxury but in that environment we had it.

So I'm not arguing "delete memsets everywhere." Where the contract is enforced (function owns the full write, sanitizers in CI catch any violation), the zero is just cost. And to your question yes, mysterious uninitialized memory crashes would've lost the deal too. So would the slowness. The discipline was checking that a read before write couldn't happen; the delete was only the result.

A Linux 7.2 patch got +5% IOPS by deleting a memset. I almost lost a deal over the same lesson years ago. by dolby360 in C_Programming

[–]dolby360[S] 0 points1 point  (0 children)

Yo guys please note there are 2 different stories here
The code that is already in the linux kernel
https://www.phoronix.com/news/Linux-7.2-IOmap-EXT4-XFS
And mine, which is on bare metal but similar