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
prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.