linux-kernel - Re: get/put_cpu() usage in block/blk-mq.c

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

Date:   Tue, 9 May 2017 08:53:05 -0600
From:   Jens Axboe <axboe@...com>
To:     Mike Galbraith <efault@....de>
CC:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: get/put_cpu() usage in block/blk-mq.c

On 05/09/2017 12:07 AM, Mike Galbraith wrote:
> Hi Jens,
> 
> I was about to fix up this splat..
> 
> [  445.022141] loop: module loaded
> [  445.078116] BUG: using smp_processor_id() in preemptible [00000000] code: loop0/3801
> [  445.085873] caller is debug_smp_processor_id+0x17/0x20
> [  445.091016] CPU: 7 PID: 3801 Comm: loop0 Tainted: G            E   4.12.0-default #40
> [  445.098838] Hardware name: IBM System x3550 M3 -[7944K3G]-/69Y5698     , BIOS -[D6E150AUS-1.10]- 12/15/2010
> [  445.108564] Call Trace:
> [  445.111016]  dump_stack+0x65/0x89
> [  445.114330]  check_preemption_disabled+0xde/0xf0
> [  445.118945]  debug_smp_processor_id+0x17/0x20
> [  445.123300]  blk_stat_add+0xb0/0x130
> [  445.126876]  __blk_mq_complete_request+0xb5/0x150
> [  445.131575]  blk_mq_complete_request+0x16/0x20
> [  445.136020]  loop_queue_work+0x5f/0xaa0 [loop]
> [  445.140461]  ? _raw_spin_unlock_irq+0x21/0x40
> [  445.144816]  ? finish_task_switch+0x85/0x270
> [  445.149085]  ? __schedule+0x291/0x8c0
> [  445.152747]  kthread_worker_fn+0xc2/0x1d0
> [  445.156754]  kthread+0x114/0x150
> [  445.159983]  ? __kthread_init_worker+0xb0/0xb0
> [  445.164424]  ? kthread_park+0x60/0x60
> [  445.168085]  ret_from_fork+0x2c/0x40

Is it from this_cpu_ptr() in blk_stat_add()?

> ..but then noticed that __blk_mq_run_hw_queue() is also called under
> get_cpu(), but recently grew a might_sleep(), so maybe wants some block
> layer eyeballs.

That part is fine. The might sleep depends on BLOCKING being set in
the hardware queue flags. And if that is set, then we don't call
it under get_cpu().

-- 
Jens Axboe