linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <clm@fb.com>
To: Dave Jones <davej@redhat.com>,
	Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: btrfs BUG() in __set_extent_bit on GFP_ATOMIC failure.
Date: Fri, 8 Aug 2014 10:43:01 -0400	[thread overview]
Message-ID: <53E4E1F5.8090409@fb.com> (raw)
In-Reply-To: <20140808042659.GA28040@redhat.com>

On 08/08/2014 12:26 AM, Dave Jones wrote:
> While playing with fault injection, I hit this quite easily.
> 
> kernel BUG at fs/btrfs/extent_io.c:990!
> invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> CPU: 1 PID: 1270 Comm: fsx Not tainted 3.16.0+ #41
> task: ffff88023fe46d60 ti: ffff8802405a8000 task.ti: ffff8802405a8000
> RIP: 0010:[<ffffffffc0319af4>]  [<ffffffffc0319af4>] __set_extent_bit+0x574/0x660 [btrfs]
> ...
>  [<ffffffff851be7fc>] ? set_track+0x9c/0x140
>  [<ffffffffc031aa94>] lock_extent_bits+0x94/0x310 [btrfs]
>  [<ffffffff85166454>] ? pagecache_get_page+0xb4/0x210
>  [<ffffffffc030d4de>] lock_and_cleanup_extent_if_need+0xee/0x1f0 [btrfs]
>  [<ffffffffc030e6e1>] __btrfs_buffered_write+0x1b1/0x680 [btrfs]
>  [<ffffffff850a258b>] ? preempt_count_sub+0xab/0x100
>  [<ffffffffc030ed2e>] btrfs_file_write_iter+0x17e/0x570 [btrfs]
>  [<ffffffff851d78ce>] new_sync_write+0x8e/0xd0
>  [<ffffffff851d8127>] vfs_write+0xb7/0x1f0
>  [<ffffffff851d8d68>] SyS_write+0x58/0xd0
>  [<ffffffff8576371f>] tracesys+0xdd/0xe2
> 
> 
>  989                 prealloc = alloc_extent_state_atomic(prealloc);
>  990                 BUG_ON(!prealloc);
> 
>  541 static struct extent_state *
>  542 alloc_extent_state_atomic(struct extent_state *prealloc)
>  543 {
>  544         if (!prealloc)
>  545                 prealloc = alloc_extent_state(GFP_ATOMIC);
>  546 
>  547         return prealloc;
>  548 }
> 
> 
> Going BUG() on a GFP_ATOMIC allocation failure seems a bit excessive.
> Surely there's something better we can do here ?
> 

Ugh, yes we can.  It should jump back to outside the lock and get the
prealloc there.

-chris


      reply	other threads:[~2014-08-08 14:43 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-08  4:26 btrfs BUG() in __set_extent_bit on GFP_ATOMIC failure Dave Jones
2014-08-08 14:43 ` Chris Mason [this message]

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=53E4E1F5.8090409@fb.com \
    --to=clm@fb.com \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).