Re: 4.11.0: kernel BUG at fs/btrfs/ctree.h:1779!

[Hugo Mills <hugo@carfax.org.uk>]

[-- Attachment #1: Type: text/plain, Size: 2519 bytes --]

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 #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]