Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Uncovering a 24-year-old bug in the Linux Kernel (2021)

engineering.skroutz.gr

Post reply on HN
Print view View original

51–60 of 84 posts

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#51

Post by capitol_ »

beachy wrote: post #45
sneak wrote: post #42

> These snapshots are updated daily through a pipeline that involves taking an LVM snapshot of production data, anonymizing the dataset by stripping all personal data, and transferring it via rsync to the development database servers. I don’t know what sort of data these people process, but most datasets about people are not anonymized by simply removing the PII.

Yes they are. Any information that can be used to identify a person by definition is PII. Once all the PII is removed, by definition the dataset is anonymized.

This is obviously true, as you are stating an axiom. But what I think the grand parent is trying to say is that databases with PII can often be deanonymized by looking at the other data that isn't obviously PII.

Take for example a database over all mobile phone positions over time, this can be 'anonymized' by removing all connections from the phones to information on who owns the phones.

But it can still be trivially deanonymized by analyzing where the phones are at night and during office hours, not very many persons work in the same building and sleep in the same house.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#52

Post by trasz »

stjohnswarts wrote: post #31
trasz wrote: post #16

Earlier quoted context omitted.

This _is_ the meaningful stuff. Engineers might have the urge, but most don’t have the opportunity, because they need to focus on the currently fashionable framework. A good rule of thumb regarding meaningful battles is to ignore everything promoted by companies like Google or Facebook - everything they do is either going to be abandoned in five years, or makes sense only in the context of solving problems nobody els…

seems like something an engineer might fix on their own time if they were feeling feisty about the matter. Something tells me if it went on for 20 years it was an edge case that only very rarely came up and was mostly a non-issue.

I suspect it was definitely an issue, it’s just that most companies like Google don’t care about reliability, only availability, and it might just not show up in their stats.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#53

Post by verisimilitudes »

How is it possible for a TCP bug that leads to stuck connections to go unnoticed for 24 years?

It's because the fools responsible never rewrite their code, use a broken language, and don't even try to prove half of the broken garbage they write. Then, when it turns out to have been broken for decades, they chuckle and shove another finger into another crack, never understanding how they misuse computers.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#54

Post by pvillano »

didgetmaster wrote: post #6

As someone who thrives on tracking down rare but annoying bugs in a debugger, I love stories like this. It is not just bugs that cause real failures which can be headaches; but also bugs that just slow things down unexpectantly. They can sometimes go undetected for decades like this one. I wrote an article this past year that talks about silent bugs that slowly eat resources and collectively can be very expensive in…

> but also bugs that just slow things down unexpectantly. They can sometimes go undetected for decades like this one.

Reminds me of the GTA Online quadratic time JSON parsing bug

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#55

Post by cryptonector »

myself248 wrote: post #25

Okay so I got to the wrap-up at the end, about "why did nobody else find this", the author sets up some logical dominoes but doesn't knock them down. Allow me to try: Earlier in the article, the author mentions that they recently upgraded some network hardware, and the problem seemed to become more frequent after that. Packet loss or other network issues would force the stack to fall out of fast-path and update the c…

One might expect this to have been hit by HPN (high performance networking) users, but perhaps if they are storage I/O bound rather than CPU or network I/O bound, then probably not.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#56

Post by themoonisachees »

perth wrote: post #50
justin_oaks wrote: post #44

I love when you're using open source software and can find the bug yourself, even if it's deep down the stack. Imagine if this bug were somewhere in closed source software. You'd have to reach out to the software's customer support team. Every time I reach out to customer support I expect to have an unpleasant experience. It is rarely otherwise.

And even if you did reach out to customer support, it would rarely ever get dev attention unless most people have the issue. Even in that case, it sometimes still gets a fat wontfix, like the famous OneDrive file corruption bug.

Raising this bug in windows (how? Microsoft sells support, barely, but you can't talk to the ipv4 stack dev anyway) woul get you laughed out of the chat room because it can't posibly be the ip stack's fault.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#57

Post by shurane »

didgetmaster wrote: post #34
myself248 wrote: post #24

Earlier quoted context omitted.

Okay but where's the bug story? Did I miss the story?

I wrote the article right after I fixed a huge inefficiency problem in a function within my own project. I neglected to give the specifics in the article, but here they are since you asked. My Didgets tool lets you create pivot tables against relational database tables, even very large ones. For the pivot values, you can choose to just count the occurrence of each value or if it is a number type you can add them up.…

I guess there is a lost art of writing for optimal code/memory/execution time, especially as our resources increase.

I think the idea here is to write code quickly that's inefficient, and re-write it to be efficient if the performance is required down the line. For companies where there's bigger fish to fry, i.e. customer acquisition, it's more useful to pump out more features (even at the expense of bugs) because that draws customers.

But in places where performance is important, you do see developers squeeze out more cycles/memory. I.e. kernel/OS development, database servers, video games. It's just that most developers aren't in those areas of specialty anymore.

Btw, have you heard of https://handmade.network/ and https://en.wikipedia.org/wiki/Demoscene ? Wondering what your thoughts are in those areas. There are probably more communities like the ones I mentioned, where developers are interested in writing the kind of code that you are talking about.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#58

Post by xani_ »

didgetmaster wrote: post #6

As someone who thrives on tracking down rare but annoying bugs in a debugger, I love stories like this. It is not just bugs that cause real failures which can be headaches; but also bugs that just slow things down unexpectantly. They can sometimes go undetected for decades like this one. I wrote an article this past year that talks about silent bugs that slowly eat resources and collectively can be very expensive in…

> As someone who thrives on tracking down rare but annoying bugs in a debugger,

As someone that is cursed to inevitably find some obscure bug the second I start using some piece of software I'm happy I'm not the only one

> I wrote an article this past year that talks about silent bugs that slowly eat resources and collectively can be very expensive in terms of wasted time and energy

"Using JS for backend is ecoterrorism" lmao

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#59

Post by xani_ »

justin_oaks wrote: post #44

I love when you're using open source software and can find the bug yourself, even if it's deep down the stack. Imagine if this bug were somewhere in closed source software. You'd have to reach out to the software's customer support team. Every time I reach out to customer support I expect to have an unpleasant experience. It is rarely otherwise.

Kinda why I'm not a fan of cloud, same black box problem.

Re: Uncovering a 24-year-old bug in the Linux Kernel (2021)

#60

Post by xani_ »

gizmo686 wrote: post #27
sponaugle wrote: post #21

This was a cool example of a class of bugs that are both hard to find with no active example, and hard to prevent in complex systems. The optimization that was added many years ago for performance didn't update something that had a use case that was incompatible with not being updated in a very small number of circumstances. It is an interesting thought experiment to consider what kind of tool or automated detection…

Probably the only way to prevent this type of issue in an automated fashion is to change your perspective from proving that a bug exists, to proving that it doesn't exist. That is, you define some properties that your program must satisfy to be considered correct. Then, when you make optimizations such as bulk receiver fast-path, you must prove (to the static analysis tool) that your optimizations to not break any of…

> That is not to say that formal verification takes 5x the work. You also have to write your source-code in such a way that it is ammenable to being formally verified, which makes it more difficult to write, and limits what you can reasonably do.

Also hire significantly more skilled people. Write formal verification on job requirement and the pool of candidates will shrink massively.

Explains why it is so rare really. "Spend 5-10x on developers to have some bugs not happen" is not a great sell.

Post reply on HN