On Oct 20, 2014, at 12:18 PM, Manuel Bouyer <[email protected]> wrote:
> On Mon, Oct 20, 2014 at 03:58:45PM +0000, Taylor R Campbell wrote: >> Date: Mon, 20 Oct 2014 17:46:06 +0200 >> From: Manuel Bouyer <[email protected]> >> >> Sure. There's lot of other ways to crash the kernel with a broken ffs. >> In this specific case it's OK to return an error, but in the general >> case I prefer to have the kernel panic when an inconsistency is >> detected in ffs, than return an error and try to continue running with >> a bogus filesystem. >> >> Continuing to run with a bogus file system is no good, but panicking >> the kernel is worse. If the kernel takes any drastic action beyond >> merely returning an error, it should remount the file system >> read-only. > > definitively not. I want a panic. If the filesystsem is corrupted something > has gone really wrong and you can't trust the running system any more. > And there are cases where returning EROFS is worse than panicing (e.g. > a NFS server). I disagree. There’s a principle of networking product design, which is that you are never allowed to crash due to external input. If you receive an invalid packet, you can complain about it and say the sender is broken, but if you crash from it it’s always your bug, no excuses, no exceptions. I would treat all external inputs that way; storage is an external input. Panics are for INTERNAL consistency failures, for example a state machine that gets into a non-existent state. But any objection to outside data must be a rejection of that data, nothing more. (The root file system might be a corner case. But non-root file systems, no.) paul
