|
|
Subscribe / Log in / New account

An Ubuntu kernel bug causes container crashes

An Ubuntu kernel bug causes container crashes

Posted Jul 6, 2022 2:38 UTC (Wed) by DSMan195276 (guest, #88396)
In reply to: An Ubuntu kernel bug causes container crashes by NightMonkey
Parent article: An Ubuntu kernel bug causes container crashes

I think the issue there is that in this case the patch applied correctly to the right locations, but the internals had changed in some way causing it to be wrong. It's entirely possible the relevant changes were in others source files, so unless you're hashing an entire directory tree or the entire source you still might not catch it. And at that point you're really just saying you should review every patch you're applying every time you apply it. Which might very well be true :D but I'm not sure you need the hashing at that point.

I think the more straightforward solution here is just testing after the patch is applied to verify the functionality still works. That's what we really care about anyway, staring at the code only gets you so far if you never actually try it. And also, don't maintain your own patches if you can avoid it :D


to post comments

An Ubuntu kernel bug causes container crashes

Posted Jul 6, 2022 5:53 UTC (Wed) by developer122 (guest, #152928) [Link] (2 responses)

I suppose that you might be able to generate metadata for a piece of software in the form of a directed acyclic graph representing a kind of causality or dependency. Something that touches one branch isn't blocked by something on another branch, but something upstream blocks downstream patches due to changed downstream-visible behavior. With language fine-tuning you could manage what does and does not cause a downstream-visible change of behavior, and what behavior precisely a patch depends on. Dunno whether most software lends itself to a good directed acyclic graph of behavior causality though.

An Ubuntu kernel bug causes container crashes

Posted Jul 6, 2022 17:39 UTC (Wed) by NYKevin (subscriber, #129325) [Link] (1 responses)

You can't do this without either using an incredibly strict language or an incredibly broad definition of "breakage." Any time code interacts with state, the state is subject to some set of invariants (e.g. "when foo() returns -1, errno can take on these values..."). Most languages explicitly encode only a small subset of those invariants in their type systems, and leave everything else for comments and documentation. Even languages like SQL, where most invariants are encoded as constraints, still have business logic invariants (e.g. "the value in the price column is the real-world price of the item, excluding tax"), which usually cannot be expressed or checked by a type checker (sure, you can check for negative or zero price, but you can't check for "the price is too expensive for this item, because somebody changed the price column to include tax"). So you have to use a broad definition of "breakage" - X "breaks" Y if X touches any state which Y later reads. But that means that everything breaks everything, in practice.

The other problem is that your graph is probably not acyclic, because most nontrivial programs contain loops. So not only does X break Y, Y also probably breaks X, meaning that you can't automatically order X and Y with respect to one another.

An Ubuntu kernel bug causes container crashes

Posted Jul 7, 2022 22:48 UTC (Thu) by roc (subscriber, #30627) [Link]

Changing the names of things when their meaning changes helps reduce these issues. But you're right, there's no way to fully avoid them.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds