Debugging a Linux network stack crash via a single register value

Re:Debugging a Linux network stack crash via a single regist... by abainbridge on Friday November 19, 2021 @12:16PM (#29279606)

Impressive bug hunting skills.

When was this bug introduced? Does anyone maintain a list of when all the known Linux kernel bugs were introduced? I'd love to know how many bugs are added to the kernel each year, and if the rate is changing.

I'm not trying to troll. I think the Linux kernel is an amazing piece of software engineering. I just think this would be an interesting metric.

[ Parent | on HN ]

Re:Debugging a Linux network stack crash via a single regist... by LukeShu on Friday November 19, 2021 @03:24PM (#29281917)

The kernel folks do a pretty good job of keeping track of which past commits a new commit "fixes", which they put in the commit message. For example, the patch linked in the article says:

    Fixes: bf296b125b21 ("tcp: Add GRO support")
    Fixes: f993bc25e519 ("net: core: handle encapsulation offloads when computing segment lengths")
    Fixes: e20cf8d3f1f7 ("udp: implement GRO for plain UDP sockets.")

That said, using this to track how many bugs are introduced each year is problematic. It's often the case that commit A introduces a bug, commit B aims to fix it and says "Fixes: A" but turns out to only be a partial fix, and then commit C completes the fix and says "Fixes: B". Naively, based on the se annotations it would make sense to say "B introduced a bug", but as in my example, this isn't always the case.

Greg KH discusses this in his talk "CVEs are dead" (video: https://www.youtube.com/watch?v=HeeoTE9jLjM slides: https://github.com/gregkh/presentation-cve-is-dead/blob/mast... ).

[ Parent | on HN ]

Re:Debugging a Linux network stack crash via a single regist... by sbierwagen on Friday November 19, 2021 @08:18PM (#29284690)

For the curious, bf296b125b21 was from 2008, f993bc25e519 was from 2014 and e20cf8d3f1f7 was in 2018.

[ Parent | on HN ]