linux-kernel - Re: kernel BUG at fs/btrfs/volumes.c:LINE!

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180607165213.GI3215@twin.jikos.cz>
Date:   Thu, 7 Jun 2018 18:52:13 +0200
From:   David Sterba <dsterba@...e.cz>
To:     Dmitry Vyukov <dvyukov@...gle.com>
Cc:     dsterba@...e.cz, Anand Jain <anand.jain@...cle.com>,
        syzbot <syzbot+5b658d997a83984507a6@...kaller.appspotmail.com>,
        clm@...com, dsterba@...e.com, Josef Bacik <jbacik@...com>,
        linux-btrfs@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
        syzkaller-bugs <syzkaller-bugs@...glegroups.com>
Subject: Re: kernel BUG at fs/btrfs/volumes.c:LINE!

On Thu, Jun 07, 2018 at 06:28:02PM +0200, Dmitry Vyukov wrote:
> > Normally the GFP_NOFS allocations do not fail so I think the fuzzer
> > environment is tuned to allow that, which is fine for coverage but does
> > not happen in practice. This will be fixed eventually.
> 
> Isn't GFP_NOFS more restricted than normal allocations?  Are these
> allocations accounted against memcg? It's easy to fail any allocation
> within a memory container.

https://lwn.net/Articles/723317/ The 'too small to fail' and some
unwritten semantics of GFP_NOFS but I think you're right about the
memory controler that can fail any allocation though.

Error handling is being improved over time, the memory allocation
failures are in some cases hard and this one would need to update some
logic so it's not a oneliner.