linux-kernel - btrfs BUG() in __set_extent_bit on GFP

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 8 Aug 2014 00:26:59 -0400
From:	Dave Jones <davej@...hat.com>
To:	Chris Mason <clm@...com>
Cc:	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: btrfs BUG() in __set_extent_bit on GFP_ATOMIC failure.

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 ?

	Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/