6 ms·

I know next to nothing about kernel programming, but I'm not sure here what Linus' objection to the comment he is responding to here is. The comment seemed to

I know next to nothing about kernel programming, but I'm not sure here what Linus' objection to the comment he is responding to here is. The comment seemed to be making reference to rust's safety guarantees about undefined behaviour like use after free. Linus' seems to have a completely different definition of "safey" that conflates allocation failures, indexing out of bounds, and division by zero with memory safety. Rust makes no claims about those problems, and the comment clearly refers to undefined behaviour. Obviously, those other problems are real problems, but just not ones that Rust claims to solve. Edit: Reading the chain further along, it increasingly feels like Linus is aruging against a strawman.

pfortuny 4y ago
I am probably wrong but I understood that “safety meaning panic” is noeither “safe” not allowed in the Linux kernel because the kernel must not panic when an error arises.
- a_humean 4y ago
  Which is why Rust has been accommodating the kernel by adding non-panic versions of the functions that Linus has been complaining about (namely that memory allocation is infallible, because that isn't an unreasonable thing to assume in applicationc code.). Still doesn't change the fact that "safe" in this context has a technical meaning, and what Linus is describing isn't that.
  - Vt71fcAqt7 4y ago
    maybe his point is that the technical meaning should use a more acurate word in his opinion?
    - a_humean 4y ago
      His point seems to be the opposite, that "safety" should have a vaguer meaning in his opinion, and not the well established technical definition that the author clearly meant when he used the word.
      - LtWorf 4y ago
        Or, in other words, rust-safety should mean what safety means in every other context, or rust people need to come up with a different word.
        a_humean 4y ago
        You don't get to change the definition of a term used by another when it had a clear meaning in its use, and then make an arugment on the basis that the author meant y when they clearly meant x. That is just conflation.
        LtWorf 4y ago
        I think the word "safety" existed before rust…
        a_humean 4y ago
        This has nothing to do with the common definition of "safety".Terms change their meaning based upon their use and context. The author has a clear use in mind - memory safety. The rules of arugment existed long before the linux kernel. You don't get to change terms introduced within a arugment with a clear meaning because it helps you create a strawman. If you want to change the definition of a term mid arugment, you telegraph it. Once again, this is called conflation.
        Vt71fcAqt7 4y ago
        >when it had a clear meaning in its use Thats not the issue though. It's that "safe" means something is actualy safe. My house isn't safe if its on fire, even if the house is in a safe neighborhood. Linus' claim is that "rust people" sometimes themselves conflate memory saftey with general code saftey, simply because "safe" is in the name. So much so that they will at times sacrifice code quality to achieve this goal despite (a) memory saftey not being real saftey and (b) there is no way to guarantee memory saftey in the kernel anyway. What he is saying is that "rust people" (whatever that means) are at times trading off real saftey or real code maintenance/performance for "rust saftey." >a compiler - or language infrastructure - that says "my rules are so ingrained that I cannot do that" is not one that is valid for kernel work. And >I think you are missing just how many things are "unsafe" in certain contexts and cannot be validated. >This is not some kind of "a few special things". >This is things like absolutely _anything_ that allocates memory, or takes a lock, or does a number of other things. >Those things are simply not "safe" if you hold a spinlock, or if you are in a RCU read-locked region. >And there is literally no way to check for it in certain configurations. None. You can judge wheter he is correct but he never said rust's saftey implies absolute saftey, only that some rust users are treating it that way by sacrificing the code for it. If that's the case then it makes a lot of sense to start using a more sensible word like "guaranteed" instead of safe. I think part of what contibutes to this idea is that "unsafe" code is written with the keyword "unsafe" as if code written not that way is safe, and code written with "unsafe" is bad. That's not to say that "unsafe" actually implies any of that - all it means is that it's not guaranteed to be memory safe - but according to Linus it creates a certain mentality which is incongruent with the nature of kernel development. And the reason for that is that safe and unsafe are general english words with strong connotations such as: >protected from or not exposed to danger or risk; not likely to be harmed or lost. >uninjured; with no harm done. And for unsafe: >able or likely to cause harm, damage, or loss
  - layer8 4y ago
    The issue that Linus is probably coming from is that many Rust aficionados evangelize for Rust as if the very specific technical meaning of “safe” in Rust was the generic meaning of “safe”. For those who understand the limitations and the trade-offs, that can be quite tiresome.
    - a_humean 4y ago
      Except, the person he is responding to doesn't make those claims - though I haven't read further up the chain - only downwards.
- rowanG077 4y ago
  Safety doesn't mean panic. I don't feel that was the point the person Linus responded to was making.
deleted 4y ago
[deleted]
arinlen 4y ago
> I know next to nothing about kernel programming, but I'm not sure here what Linus' objection to the comment he is responding to here is. You should read the email thread, as Linhas explains in clear terms. Take for instance Linus's insightful followup post: https://lkml.org/lkml/2022/9/19/1250 https://lkml.org/lkml/2022/9/19/1250
- ChrisSD 4y ago
  What is better: continuing to "limp along" in some unknown corrupted state (aka undefined behaviour) or in a well defined (albeit invalid) state?
  - throw827474737 4y ago
    Had the same topic often on MCUs: limp along to hopefully get the error out somehow, otherwise it won't be noticed if not with JTAG debugger attached (default in field). So I can understand where Linus comes from.
    - gmueckl 4y ago
      Yes. You could still hard reset after the error is reported if you wanted to. And if system availability matters, a hardware watchdog would handle the case where the error handling doesn't finish.
    - mlindner 4y ago
      Limping along is what the salesman and the business people want as failures look bad. Engineers should want the immediate stop, because that's safer, especially in safety critical situations.
      - wtallis 4y ago
        The kernel is not the whole system. The kernel needs to offer the "limping along" option so that the other parts of the system can implement whatever graceful failure method is appropriate for that system. There's no one size fits all solution for the kernel to pick.
4bpp 4y ago
From a quick skim, it seems to me that at least in Linus's interpretation, his interlocutor is requesting changes to the way the kernel does things in order to accommodate/maintain Rust's "there is no undefined behaviour; in cases where circumstances conspire to make behaviour undefined, terminate immediately" philosophy even in kernel Rust code. He then figures that if he said he is not willing to do that, the other side would respond with something to the effect of "but implementing the Rust philosophy in full means you get safety, and you surely can't have a goal more important than that", and therefore leaps to talking down the importance of the safety that Rust actually guarantees, to argue that it is not actually so great that all other objectives would be secondary to it. If his initial interpretation and expectation of the Rustacean response is in fact correct, the line of argumentation does not seem per se wrong, but I do think that it is bad practice in adversarial conversations to do the thing where you silently skip forward several steps in the argument and respond to what you expect (their response to your response)^n to be instead of the immediate argument at hand.

pfortuny 4y ago

I am probably wrong but I understood that “safety meaning panic” is noeither “safe” not allowed in the Linux kernel because the kernel must not panic when an error arises.

a_humean 4y ago
Which is why Rust has been accommodating the kernel by adding non-panic versions of the functions that Linus has been complaining about (namely that memory allocation is infallible, because that isn't an unreasonable thing to assume in applicationc code.). Still doesn't change the fact that "safe" in this context has a technical meaning, and what Linus is describing isn't that.
- Vt71fcAqt7 4y ago
  maybe his point is that the technical meaning should use a more acurate word in his opinion?
  - a_humean 4y ago
    His point seems to be the opposite, that "safety" should have a vaguer meaning in his opinion, and not the well established technical definition that the author clearly meant when he used the word.
    - LtWorf 4y ago
      Or, in other words, rust-safety should mean what safety means in every other context, or rust people need to come up with a different word.
      - a_humean 4y ago
        You don't get to change the definition of a term used by another when it had a clear meaning in its use, and then make an arugment on the basis that the author meant y when they clearly meant x. That is just conflation.
        LtWorf 4y ago
        I think the word "safety" existed before rust…
        a_humean 4y ago
        This has nothing to do with the common definition of "safety".Terms change their meaning based upon their use and context. The author has a clear use in mind - memory safety. The rules of arugment existed long before the linux kernel. You don't get to change terms introduced within a arugment with a clear meaning because it helps you create a strawman. If you want to change the definition of a term mid arugment, you telegraph it. Once again, this is called conflation.
        Vt71fcAqt7 4y ago
        >when it had a clear meaning in its use Thats not the issue though. It's that "safe" means something is actualy safe. My house isn't safe if its on fire, even if the house is in a safe neighborhood. Linus' claim is that "rust people" sometimes themselves conflate memory saftey with general code saftey, simply because "safe" is in the name. So much so that they will at times sacrifice code quality to achieve this goal despite (a) memory saftey not being real saftey and (b) there is no way to guarantee memory saftey in the kernel anyway. What he is saying is that "rust people" (whatever that means) are at times trading off real saftey or real code maintenance/performance for "rust saftey." >a compiler - or language infrastructure - that says "my rules are so ingrained that I cannot do that" is not one that is valid for kernel work. And >I think you are missing just how many things are "unsafe" in certain contexts and cannot be validated. >This is not some kind of "a few special things". >This is things like absolutely _anything_ that allocates memory, or takes a lock, or does a number of other things. >Those things are simply not "safe" if you hold a spinlock, or if you are in a RCU read-locked region. >And there is literally no way to check for it in certain configurations. None. You can judge wheter he is correct but he never said rust's saftey implies absolute saftey, only that some rust users are treating it that way by sacrificing the code for it. If that's the case then it makes a lot of sense to start using a more sensible word like "guaranteed" instead of safe. I think part of what contibutes to this idea is that "unsafe" code is written with the keyword "unsafe" as if code written not that way is safe, and code written with "unsafe" is bad. That's not to say that "unsafe" actually implies any of that - all it means is that it's not guaranteed to be memory safe - but according to Linus it creates a certain mentality which is incongruent with the nature of kernel development. And the reason for that is that safe and unsafe are general english words with strong connotations such as: >protected from or not exposed to danger or risk; not likely to be harmed or lost. >uninjured; with no harm done. And for unsafe: >able or likely to cause harm, damage, or loss
- layer8 4y ago
  The issue that Linus is probably coming from is that many Rust aficionados evangelize for Rust as if the very specific technical meaning of “safe” in Rust was the generic meaning of “safe”. For those who understand the limitations and the trade-offs, that can be quite tiresome.
  - a_humean 4y ago
    Except, the person he is responding to doesn't make those claims - though I haven't read further up the chain - only downwards.
rowanG077 4y ago
Safety doesn't mean panic. I don't feel that was the point the person Linus responded to was making.

deleted 4y ago

[deleted]

arinlen 4y ago

> I know next to nothing about kernel programming, but I'm not sure here what Linus' objection to the comment he is responding to here is. You should read the email thread, as Linhas explains in clear terms. Take for instance Linus's insightful followup post: https://lkml.org/lkml/2022/9/19/1250 https://lkml.org/lkml/2022/9/19/1250

ChrisSD 4y ago
What is better: continuing to "limp along" in some unknown corrupted state (aka undefined behaviour) or in a well defined (albeit invalid) state?
- throw827474737 4y ago
  Had the same topic often on MCUs: limp along to hopefully get the error out somehow, otherwise it won't be noticed if not with JTAG debugger attached (default in field). So I can understand where Linus comes from.
  - gmueckl 4y ago
    Yes. You could still hard reset after the error is reported if you wanted to. And if system availability matters, a hardware watchdog would handle the case where the error handling doesn't finish.
  - mlindner 4y ago
    Limping along is what the salesman and the business people want as failures look bad. Engineers should want the immediate stop, because that's safer, especially in safety critical situations.
    - wtallis 4y ago
      The kernel is not the whole system. The kernel needs to offer the "limping along" option so that the other parts of the system can implement whatever graceful failure method is appropriate for that system. There's no one size fits all solution for the kernel to pick.

4bpp 4y ago

From a quick skim, it seems to me that at least in Linus's interpretation, his interlocutor is requesting changes to the way the kernel does things in order to accommodate/maintain Rust's "there is no undefined behaviour; in cases where circumstances conspire to make behaviour undefined, terminate immediately" philosophy even in kernel Rust code. He then figures that if he said he is not willing to do that, the other side would respond with something to the effect of "but implementing the Rust philosophy in full means you get safety, and you surely can't have a goal more important than that", and therefore leaps to talking down the importance of the safety that Rust actually guarantees, to argue that it is not actually so great that all other objectives would be secondary to it. If his initial interpretation and expectation of the Rustacean response is in fact correct, the line of argumentation does not seem per se wrong, but I do think that it is bad practice in adversarial conversations to do the thing where you silently skip forward several steps in the argument and respond to what you expect (their response to your response)^n to be instead of the immediate argument at hand.