linux-kernel - Re: [PATCH block/for-3.4/core] cfq: fix cfqg ref handling when BLK_CGROUP && !CFQ_GROUP

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: <4F6C74C6.2090002@kernel.dk>
Date:	Fri, 23 Mar 2012 14:04:06 +0100
From:	Jens Axboe <axboe@...nel.dk>
To:	Tejun Heo <tj@...nel.org>
CC:	Fengguang Wu <fengguang.wu@...el.com>,
	Vivek Goyal <vgoyal@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH block/for-3.4/core] cfq: fix cfqg ref handling when BLK_CGROUP
 && !CFQ_GROUP_IOSCHED

On 03/15/2012 05:35 PM, Tejun Heo wrote:
> When BLK_CGROUP is enabled but CFQ_GROUP_IOSCHED is, cfq ends up
> calling blkg_get/put() on dummy cfqg leading to the following crash.
> 
>   BUG: unable to handle kernel NULL pointer dereference at 00000000000000b0
>   IP: [<ffffffff813d44d8>] cfq_init_queue+0x258/0x430
>   PGD 0
>   Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
>   CPU 0
>   Modules linked in:
> 
>   Pid: 1, comm: swapper/0 Not tainted 3.3.0-rc6-work+ #125 Bochs Bochs
>   RIP: 0010:[<ffffffff813d44d8>]  [<ffffffff813d44d8>] cfq_init_queue+0x258/0x430
>   RSP: 0018:ffff88001f9dfd80  EFLAGS: 00010046
>   RAX: ffff88001aefbbf0 RBX: ffff88001aeedbf0 RCX: 0000000000000100
>   RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff820ffd40
>   RBP: ffff88001f9dfdd0 R08: 0000000000000000 R09: 0000000000000001
>   R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
>   R13: 0000000000000009 R14: ffff88001aefbc30 R15: 0000000000000003
>   FS:  0000000000000000(0000) GS:ffff88001fc00000(0000) knlGS:0000000000000000
>   CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>   CR2: 00000000000000b0 CR3: 000000000206f000 CR4: 00000000000006f0
>   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>   DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>   Process swapper/0 (pid: 1, threadinfo ffff88001f9de000, task ffff88001f9dc040)
>   Stack:
>    ffff88001aeedbf0 ffff88001aefbdb0 ffff88001aef1548 ffff88001aefbbf0
>    ffff88001f9dfdd0 ffff88001aef1548 ffffffff820d6320 ffffffff8165ce30
>    ffffffff82c555e0 ffff88001aeebbf0 ffff88001f9dfe00 ffffffff813b0507
>   Call Trace:
>    [<ffffffff813b0507>] elevator_init+0xd7/0x140
>    [<ffffffff813b83d5>] blk_init_allocated_queue+0x125/0x150
>    [<ffffffff813b94d3>] blk_init_queue_node+0x43/0x80
>    [<ffffffff813b9523>] blk_init_queue+0x13/0x20
>    [<ffffffff821aec00>] floppy_init+0x82/0xec7
>    [<ffffffff810001d2>] do_one_initcall+0x42/0x170
>    [<ffffffff821835fc>] kernel_init+0xcb/0x14f
>    [<ffffffff81b40b24>] kernel_thread_helper+0x4/0x10
>   Code: 00 e8 1d 9e 76 00 48 8b 43 48 48 85 c0 48 89 83 28 03 00 00 74 07 4c 8b a0 10 ff ff ff 8b 15 b0 2e d0 00 85 d2 0f 85 49 01 00 00 <41> 8b 84 24 b0 00 00 00 85 c0 0f 8e 8c 01 00 00 83 e8 01 85 c0
>   RIP  [<ffffffff813d44d8>] cfq_init_queue+0x258/0x430
> 
> Because cfq's blkcg support has a on/off switch, CFQ_GROUP_IOSCHED,
> separate from BLK_CGROUP, blkg access through cfqg needs to be
> conditioned on it.
> 
> * Make blkg_to_cfqg() and cfqg_to_blkg() conditioned on
>   CFQ_GROUP_IOSCHED.  If disabled, they always return %NULL.
> 
> * Introduce cfqg_get() and cfqg_put() conditioned on
>   CFQ_GROUP_IOSCHED.  If disabled, they are noops.
> 
> Reported-by: Fengguang Wu <fengguang.wu@...el.com>
> Signed-off-by: Tejun Heo <tj@...nel.org>
> ---
> Yeap, forgot to test that config combination.  Fengguang, can you
> please test this patch?  Jens, once Fengguang confirms the fix, can
> you please apply this on top of for-3.4/core along with the pending
> stats updates?

Added to for-3.5/core, thanks.

-- 
Jens Axboe

--
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/