4 ms·

I’m not au fait with Rust or memory management or systems code to understand the issue here. Does anyone have a good explanation?

steveklabnik 6y ago
The short explanation is, this code wasn't in its final form yet, but good enough to ask for a high level review of the code, the review came back "hey this looks okay overall but I have some questions about <details>" and the reply was "great! <details> is the work we haven't done yet; we'll get on that."
- andy_ppp 6y ago
  Ah I understand that bit! I don’t understand why panicking if you run out of memory is a thing and or why it’s especially bad in kernel code...
  - steveklabnik 6y ago
    Ah okay. Rust's panics are used as the "I cannot recover from this error" mechanism. Most applications don't really properly handle OOM, and so this kind of error falls into the "I want my current thread to just die, thanks" style of error handling, hence a panic. That's bad in the kernel because you don't want the kernel to die, you do want to handle it and do something. The semi-ironic part here is that this behavior is the way that it is largely because of how the Linux userland works, where it's often tough to even tell that your system is is in a near-OOM or OOM state. Which is why applications rarely handle it, even if they theoretically could. Now, Rust itself has good support for these environments; I work on an embedded kernel, and we do no allocations at all. But what the kernel wants is where Rust is currently weakest in support; we have good support for "no allocations" and "panic on OOM or return Result on OOM" but not great support for "return Result on OOM and do not panic on OOM", and reasonably, the kernel would like the behavior they don't want to be impossible. That's the work that needs to be done.
    - utxaa 6y ago
      > we have good support for "no allocations" and "panic on OOM or return Result on OOM" so if i understand it correctly, the ability is there by just "returning a result on oom" - linus is just asking for complete assurance that a panic will never happen? like say from a library?
      - steveklabnik 6y ago
        It is not 100% clear to me if he's asking for no panic in any possible situation. (AFAIK, the BUG macro in the kernel does something very similar, so I would find it slightly surprising, though he may only want it to happen "explicitly" or something, we'll just have to see.) It is clear to me that he is asking for no panics for OOM.
        utxaa 6y ago
        > It is clear to me that he is asking for no panics for OOM. agreed. which is why i'm confused. maybe this is a non-issue that has exploded into an issue :) thanks.

steveklabnik 6y ago

The short explanation is, this code wasn't in its final form yet, but good enough to ask for a high level review of the code, the review came back "hey this looks okay overall but I have some questions about <details>" and the reply was "great! <details> is the work we haven't done yet; we'll get on that."

andy_ppp 6y ago
Ah I understand that bit! I don’t understand why panicking if you run out of memory is a thing and or why it’s especially bad in kernel code...
- steveklabnik 6y ago
  Ah okay. Rust's panics are used as the "I cannot recover from this error" mechanism. Most applications don't really properly handle OOM, and so this kind of error falls into the "I want my current thread to just die, thanks" style of error handling, hence a panic. That's bad in the kernel because you don't want the kernel to die, you do want to handle it and do something. The semi-ironic part here is that this behavior is the way that it is largely because of how the Linux userland works, where it's often tough to even tell that your system is is in a near-OOM or OOM state. Which is why applications rarely handle it, even if they theoretically could. Now, Rust itself has good support for these environments; I work on an embedded kernel, and we do no allocations at all. But what the kernel wants is where Rust is currently weakest in support; we have good support for "no allocations" and "panic on OOM or return Result on OOM" but not great support for "return Result on OOM and do not panic on OOM", and reasonably, the kernel would like the behavior they don't want to be impossible. That's the work that needs to be done.
  - utxaa 6y ago
    > we have good support for "no allocations" and "panic on OOM or return Result on OOM" so if i understand it correctly, the ability is there by just "returning a result on oom" - linus is just asking for complete assurance that a panic will never happen? like say from a library?
    - steveklabnik 6y ago
      It is not 100% clear to me if he's asking for no panic in any possible situation. (AFAIK, the BUG macro in the kernel does something very similar, so I would find it slightly surprising, though he may only want it to happen "explicitly" or something, we'll just have to see.) It is clear to me that he is asking for no panics for OOM.
      - utxaa 6y ago
        > It is clear to me that he is asking for no panics for OOM. agreed. which is why i'm confused. maybe this is a non-issue that has exploded into an issue :) thanks.