LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: dsterba@suse.cz, Anand Jain <anand.jain@oracle.com>,
	syzbot <syzbot+5b658d997a83984507a6@syzkaller.appspotmail.com>,
	clm@fb.com, dsterba@suse.com, Josef Bacik <jbacik@fb.com>,
	linux-btrfs@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	syzkaller-bugs <syzkaller-bugs@googlegroups.com>
Subject: Re: kernel BUG at fs/btrfs/volumes.c:LINE!
Date: Thu, 7 Jun 2018 18:52:13 +0200	[thread overview]
Message-ID: <20180607165213.GI3215@twin.jikos.cz> (raw)
In-Reply-To: <CACT4Y+arBwkwhD-kob9fg1pVBXiMepW6KBK2LkhwjQ9HnDcoqw@mail.gmail.com>

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.

  reply	other threads:[~2018-06-07 16:55 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-06 13:31 syzbot
2018-06-06 16:15 ` Anand Jain
2018-06-07 15:34   ` David Sterba
2018-06-07 16:28     ` Dmitry Vyukov
2018-06-07 16:52       ` David Sterba [this message]
2019-06-10 23:14         ` Eric Biggers
2019-06-11 10:01           ` David Sterba
2019-12-04 14:59 ` Johannes Thumshirn
2019-12-05 10:00   ` Johannes Thumshirn
2019-12-05 10:07     ` Dmitry Vyukov
2019-12-05 10:07       ` syzbot
2019-12-05 11:38       ` Johannes Thumshirn
2019-12-05 11:50         ` David Sterba
2019-12-05 12:06           ` Dmitry Vyukov
2019-12-10 15:11             ` Dmitry Vyukov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180607165213.GI3215@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=anand.jain@oracle.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=dvyukov@google.com \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=syzbot+5b658d997a83984507a6@syzkaller.appspotmail.com \
    --cc=syzkaller-bugs@googlegroups.com \
    --subject='Re: kernel BUG at fs/btrfs/volumes.c:LINE'\!'' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).