On Fri, May 19, 2017 at 05:11:34PM -0700, Marc MERLIN wrote: > On Fri, May 19, 2017 at 12:03:58PM -0700, Liu Bo wrote: > > Hi Marc, > > > > On Thu, May 18, 2017 at 09:16:38PM -0700, Marc MERLIN wrote: > > > Looks like all the unhelpful BUG() aren't gone yet :-/ > > > This one is really not helpful, I don't even know which one of my filesystems caused the crash :( > > > > > > Why is this not remounting the filesystem read only? > > > Really, from a user and admin perspective, this is really not helpful. > > > > > > Could someone who know more than me do a pass and eradicate those? > > > Btrfs cannot be a production filesystem as long as those are still around IMO. > > > > Looks like there's a security hole hidden in code, I don't think it's > > a bug in code, it's more like caused by a corrupted metadata reading > > from disk rather than a memory corruption. > > > > A quick glance at the stack shows in extent-tree.c:lookup_inline_extent_backref() > > > > type = btrfs_extent_inline_ref_type(leaf, iref); > > then... > > ptr += btrfs_extent_inline_ref_size(type); > > > > I agree that a corrupted image should not corrupt the kernel, so we > > can fix it by forcing it to readonly. > > Thanks. > Can I make another plea for just removing all those BUG/BUG_ON? > They really have no place in production code, there is no excuse for a > filesystem to bring down the entire and in the process not even tell you > which of your filesystems had the issue to start with. > > Could this be made part of a cleanup for this build to remove them all? The removal of these has been an ongoing process for at least the last 5 years. I don't understand the specifics of the kernel code in question(*), but compared to 5 years ago, btrfs has got rid of most of the BUG_ONs(**) a few years ago. The remaining ones are probably complicated to deal with in any way more elegant than just stopping. I recall seeing someone's stats on BUG_ON locations a couple of years ago, and btrfs had managed to get the number of locations down below XFS (but no other FS). It's a kind of success, at least... Hugo. (*) I don't have the spare time to fully comprehend the process. Sorry. (**) A good fraction went away in the first year after the decision to get rid of them. > Pretty please with cherry on top? :) > > Marc -- Hugo Mills | IMPROVE YOUR ORGANISMS!! hugo@... carfax.org.uk | http://carfax.org.uk/ | PGP: E2AB1DE4 | Subject line of spam email
Attachment:
signature.asc
Description: Digital signature
