Demi M. Obenour <[email protected]> wrote:

> On 10/24/20 10:41 AM, Stefan Sperling wrote:
> > On Sat, Oct 24, 2020 at 04:11:00PM +0200, Filippo Valsorda wrote:
> >> Fair enough, but "there's no auto-assembly and it's inefficient and
> >> nothing stops you from messing with the intermediate discipline" is a
> >> different kind of not supported than "you should expect kernel panics".
> >>
> >> If the latter is the case, maybe it should be documented in the
> >> softraid(4) CAVEATS, as it breaks the sd(4) abstraction.
> > 
> > Neither Joel's mail nor the word "unsupported" imply a promise
> > that it will work without auto-assembly and with inefficient i/o.
> > 
> > Unsupported means unsupported. We don't need to list any reasons
> > for this in user-facing documentation.
> 
> One could also argue that the kernel must never panic because userspace
> did something wrong.  The only exceptions I am aware of are:
> 
> - init dying
> - corrupt kernel image
> - corrupt root filesystem
> - not being able to mount the root filesystem
> - overwriting kernel memory with /dev/mem or DMA
> - hardware fault

Really.

rm -rf /
reboot

Oh my god, it panics on reboot.  And hundreds of other possible ways for
root to configure a broken system for the next operation.

Sadly, the margin was too narrow for any solution in the form of source code
or diff, instead we as developers get instructed on What To Do.

If you guys aren't part of the solution, you are part of the precipitate.

Reply via email to