linux-kernel - Re: [PATCH v2] iio: fix sched WARNING "do not call blocking ops when !TASK

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:   Sun, 21 Aug 2016 12:21:55 +0100
From:   Jonathan Cameron <jic23@...nel.org>
To:     Lars-Peter Clausen <lars@...afoo.de>,
        Brian Norris <briannorris@...omium.org>
Cc:     Hartmut Knaack <knaack.h@....de>,
        Peter Meerwald-Stadler <pmeerw@...erw.net>,
        linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
        Guenter Roeck <linux@...ck-us.net>,
        Brian Norris <computersforpeace@...il.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH v2] iio: fix sched WARNING "do not call blocking ops when
 !TASK_RUNNING"

On 16/08/16 16:27, Lars-Peter Clausen wrote:
> On 08/15/2016 05:54 PM, Jonathan Cameron wrote:
>> On 09/08/16 01:19, Brian Norris wrote:
>>> When using CONFIG_DEBUG_ATOMIC_SLEEP, the scheduler nicely points out
>>> that we're calling sleeping primitives within the wait_event loop, which
>>> means we might clobber the task state:
>>>
>>> [   10.831289] do not call blocking ops when !TASK_RUNNING; state=1 set at [<ffffffc00026b610>]
>>> [   10.845531] ------------[ cut here ]------------
>>> [   10.850161] WARNING: at kernel/sched/core.c:7630
>>> ...
>>> [   12.164333] ---[ end trace 45409966a9a76438 ]---
>>> [   12.168942] Call trace:
>>> [   12.171391] [<ffffffc00024ed44>] __might_sleep+0x64/0x90
>>> [   12.176699] [<ffffffc000954774>] mutex_lock_nested+0x50/0x3fc
>>> [   12.182440] [<ffffffc0007b9424>] iio_kfifo_buf_data_available+0x28/0x4c
>>> [   12.189043] [<ffffffc0007b76ac>] iio_buffer_ready+0x60/0xe0
>>> [   12.194608] [<ffffffc0007b7834>] iio_buffer_read_first_n_outer+0x108/0x1a8
>>> [   12.201474] [<ffffffc000370d48>] __vfs_read+0x58/0x114
>>> [   12.206606] [<ffffffc000371740>] vfs_read+0x94/0x118
>>> [   12.211564] [<ffffffc0003720f8>] SyS_read+0x64/0xb4
>>> [   12.216436] [<ffffffc000203cb4>] el0_svc_naked+0x24/0x28
>>>
>>> To avoid this, we should (a la https://lwn.net/Articles/628628/) use the
>>> wait_woken() function, which avoids the nested sleeping while still
>>> handling races between waiting / wake-events.
>>>
>>> Signed-off-by: Brian Norris <briannorris@...omium.org>
>> Looks good to me, but given Lars' involvement in the discussion I'd
>> like his review before applying this.
> 
> Looks good. Thanks Brian for fixing this.
> 
> Reviewed-by: Lars-Peter Clausen <lars@...afoo.de>
I've applied to this to the fixes-togreg branch of iio.git

For now I haven't marked it for stable, purely because I'm not sure
when the first 'problem' usage was introduced.  I'm happy to explicitly
send a request for stable inclusion if anyone wants to track down
which stable trees this is applicable to.

I've very low on time today (holiday catch up) so won't get to
dig into it myself for a at least a few weeks.

Jonathan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>