linux-kernel - Re: ext4: BUG: scheduling while atomic in ext4_commit

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] [day] [month] [year] [list]

Message-ID: <20160210135748.GH12245@quack.suse.cz>
Date:	Wed, 10 Feb 2016 14:57:48 +0100
From:	Jan Kara <jack@...e.cz>
To:	Dmitry Vyukov <dvyukov@...gle.com>
Cc:	Theodore Ts'o <tytso@....edu>,
	Andreas Dilger <adilger.kernel@...ger.ca>,
	linux-ext4@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	syzkaller <syzkaller@...glegroups.com>,
	Kostya Serebryany <kcc@...gle.com>,
	Alexander Potapenko <glider@...gle.com>,
	Sasha Levin <sasha.levin@...cle.com>
Subject: Re: ext4: BUG: scheduling while atomic in ext4_commit_super

On Sun 24-01-16 17:48:00, Dmitry Vyukov wrote:
> Hello,
> 
> I've hit the following BUG while running syzkaller fuzzer:
> 
> JBD2: Spotted dirty metadata buffer (dev = sda, blocknr = 1). There's
> a risk of filesystem corruption in case of system crash.
> EXT4-fs error (device sda): ext4_init_block_bitmap:194: comm
> kworker/u10:2: Checksum bad for group 3
> BUG: sleeping function called from invalid context at
> include/linux/buffer_head.h:354
> in_atomic(): 1, irqs_disabled(): 0, pid: 20922, name: kworker/u10:2
> INFO: lockdep is turned off.
> CPU: 3 PID: 20922 Comm: kworker/u10:2 Tainted: G        W       4.4.0+ #276
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: writeback wb_workfn (flush-8:0)
>  00000000ffffffff ffff8800608ded00 ffffffff82999e2d ffff880067570000
>  00000000000051ba 0000000000000000 ffff8800608ded28 ffffffff813cc25b
>  ffff880067570000 ffffffff864a4ba0 0000000000000162 ffff8800608ded68
> Call Trace:
>  [<     inline     >] __dump_stack lib/dump_stack.c:15
>  [<ffffffff82999e2d>] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
>  [<ffffffff813cc25b>] ___might_sleep+0x27b/0x3a0 kernel/sched/core.c:7703
>  [<ffffffff813cc410>] __might_sleep+0x90/0x1a0 kernel/sched/core.c:7665
>  [<     inline     >] lock_buffer include/linux/buffer_head.h:354
>  [<ffffffff8186b353>] __sync_dirty_buffer+0x63/0x270 fs/buffer.c:3129
>  [<ffffffff81acb8b3>] ext4_commit_super+0x713/0xa80 fs/ext4/super.c:4333
>  [<     inline     >] save_error_info fs/ext4/super.c:316
>  [<ffffffff81acc547>] __ext4_error+0xe7/0x1d0 fs/ext4/super.c:419
>  [<     inline     >] ext4_init_block_bitmap fs/ext4/balloc.c:194

Yeah, we call ext4_error() from inappropriate place. Thanks for reporting
this. I'll send a fix in a moment.

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR