Re: sched/core: WARNING in __might_sleep

Re: sched/core: WARNING in __might_sleep

[Peter Zijlstra]

On Sun, Jan 31, 2016 at 11:33:43PM +0800, Baozeng wrote:
> Hello,
>      The following program triggers WARNING in __might_sleep:

Yeah, from the rfkill code, which you failed to CC.

Also, please don't use the gmail web interface to send email, it
completely destroys stuff and almost guarantees lkml will drop it
silently on the floor.

Excessive quoting of the original email because this email never made it
to the list and the Cc'ed people might be interested.

> // autogenerated by syzkaller (http://github.com/google/syzkaller)
> #include <unistd.h>
> #include <sys/syscall.h>
> #include <string.h>
> #include <stdint.h>
> #include <pthread.h>
> #include <fcntl.h>
> 
> long r[19];
> 
> void *thr(void *arg) {
> switch((long)arg) {
> case 0:
> r[0] = syscall(SYS_mmap, 0x20000000ul, 0x93000ul, 0x3ul, 0x32ul,
> 0xfffffffffffffffful, 0x0ul);
> break;
> case 1:
> r[2] = syscall(SYS_open, "/dev/rfkill", O_RDWR, 0);
> break;
> case 2:
> *(uint64_t*)0x2009027e = (uint64_t)0x20090000;
> *(uint64_t*)0x20090286 = (uint64_t)0x8;
> *(uint64_t*)0x2009028e = (uint64_t)0x20090000;
> *(uint64_t*)0x20090296 = (uint64_t)0x61;
> *(uint64_t*)0x2009029e = (uint64_t)0x20090faf;
> *(uint64_t*)0x200902a6 = (uint64_t)0xb4;
> *(uint64_t*)0x200902ae = (uint64_t)0x20090f11;
> *(uint64_t*)0x200902b6 = (uint64_t)0xef;
> *(uint64_t*)0x200902be = (uint64_t)0x20090fe4;
> *(uint64_t*)0x200902c6 = (uint64_t)0x7b;
> r[13] = syscall(SYS_readv, r[2], 0x2009027eul, 0x5ul, 0, 0, 0);
> break;
> case 3:
> 
> *(uint64_t*)0x20018ff4 = (uint64_t)0x2008ffe0;
> *(uint64_t*)0x20018ffc = (uint64_t)0x68;
> *(uint64_t*)0x20019004 = (uint64_t)0x2008f40f;
> *(uint64_t*)0x2001900c = (uint64_t)0x49;
> r[18] = syscall(SYS_readv, r[2], 0x20018ff4ul, 0x2ul, 0, 0, 0);
> break;
> }
> return 0;
> }
> 
> int main()
> { long i;
> pthread_t th[4];
> memset(r, -1, sizeof(r));
> for (i = 0; i < 4; i++) {
> pthread_create(&th[i], 0, thr, (void*)i);
> usleep(10000);
> }
> for (i = 0; i< 4; i++){
> pthread_create(&th[i], 0, thr, (void*)i);
> if (i%2 == 0)
> usleep(10000);
> }
> usleep(100000);
> return 0;
> }
> 
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 11126 at kernel/sched/core.c:7663
> __might_sleep+0x138/0x1a0()
> do not call blocking ops when !TASK_RUNNING; state=1 set at
> [<ffffffff813e45f1>] prepare_to_wait_event+0x141/0x410
> /home/fuzzy/tovald_kernel/kernel/kernel/sched/wait.c:210

As stated, gmail web crap will destroy the email; see the below
unreadable mess. Also, maybe change your script to
's/\/home\/fuzzy\/tovald_kernel\///'

(And also, its spelled: Torvalds)

In any case, this is a fail in the rfkill code, which should be sorted
with the below patch (but the rfkill people should double check), and
ideally they'd use list_empty_careful() instead of the mutex, but I
don't know their code well enough to say if that's safe or not.

---
 net/rfkill/core.c | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/net/rfkill/core.c b/net/rfkill/core.c
index f53bf3b6558b..74c99ad28a0c 100644
--- a/net/rfkill/core.c
+++ b/net/rfkill/core.c
@@ -1099,6 +1099,15 @@ static bool rfkill_readable(struct rfkill_data *data)
 {
 	bool r;
 
+	/*
+	 * The below mutex_lock() will destroy task::state when it blocks
+	 * and cause the outer wait_event loop to not block.
+	 *
+	 * Assuming contention on this mutex is rare, an occasional extra loop
+	 * in the wait_event code will not hurt.
+	 */
+	sched_annotate_sleep();
+
 	mutex_lock(&data->mtx);
 	r = !list_empty(&data->events);
 	mutex_unlock(&data->mtx);


> Modules linked in:
> CPU: 1 PID: 11126 Comm: syz-executor Not tainted 4.4.0+ #5
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
>  00000000ffffffff ffff88003676f908 ffffffff8292049d ffff88003676f978
>  ffff88003804c500 ffffffff85e68220 ffff88003676f948 ffffffff812fdf19
>  ffffffff81375b58 ffffed0006cedf2b ffffffff85e68220 0000000000001def
> Call Trace:
>  [<     inline     >] __dump_stack
> /home/fuzzy/tovald_kernel/kernel/lib/dump_stack.c:15
>  [<ffffffff8292049d>] dump_stack+0x6f/0xa2
> /home/fuzzy/tovald_kernel/kernel/lib/dump_stack.c:50
>  [<ffffffff812fdf19>] warn_slowpath_common+0xd9/0x140
> /home/fuzzy/tovald_kernel/kernel/kernel/panic.c:482
>  [<ffffffff81375b58>] ? __might_sleep+0x138/0x1a0
> /home/fuzzy/tovald_kernel/kernel/kernel/sched/core.c:7658
>  [<ffffffff812fe029>] warn_slowpath_fmt+0xa9/0xd0
> /home/fuzzy/tovald_kernel/kernel/kernel/panic.c:494
>  [<ffffffff812fdf80>] ? warn_slowpath_common+0x140/0x140
> /home/fuzzy/tovald_kernel/kernel/kernel/panic.c:468
>  [<ffffffff81374c50>] ? cpu_cgroup_can_attach+0x120/0x120
> /home/fuzzy/tovald_kernel/kernel/include/linux/sched/rt.h:15
>  [<ffffffff813e45f1>] ? prepare_to_wait_event+0x141/0x410
> /home/fuzzy/tovald_kernel/kernel/kernel/sched/wait.c:210
>  [<ffffffff813e45f1>] ? prepare_to_wait_event+0x141/0x410
> /home/fuzzy/tovald_kernel/kernel/kernel/sched/wait.c:210
>  [<ffffffff81375b58>] __might_sleep+0x138/0x1a0
> /home/fuzzy/tovald_kernel/kernel/kernel/sched/core.c:7658
>  [<ffffffff85d80ee4>] mutex_lock_nested+0x74/0x890
> /home/fuzzy/tovald_kernel/kernel/kernel/locking/mutex.c:617
>  [<     inline     >] ? spin_unlock_irqrestore
> /home/fuzzy/tovald_kernel/kernel/include/linux/spinlock.h:362
>  [<ffffffff813e464e>] ? prepare_to_wait_event+0x19e/0x410
> /home/fuzzy/tovald_kernel/kernel/kernel/sched/wait.c:217
>  [<ffffffff85d80e70>] ? mutex_lock_interruptible_nested+0x980/0x980
> /home/fuzzy/tovald_kernel/kernel/include/linux/compiler.h:218
>  [<ffffffff813fd7ad>] ? trace_hardirqs_on+0xd/0x10
> /home/fuzzy/tovald_kernel/kernel/kernel/locking/lockdep.c:2619
>  [<     inline     >] rfkill_readable
> /home/fuzzy/tovald_kernel/kernel/net/rfkill/core.c:1102
>  [<ffffffff85b625cd>] rfkill_fop_read+0x23d/0x3e0
> /home/fuzzy/tovald_kernel/kernel/net/rfkill/core.c:1125
>  [<ffffffff85b62390>] ? rfkill_fop_ioctl+0x150/0x150
> /home/fuzzy/tovald_kernel/kernel/net/rfkill/core.c:1227
>  [<ffffffff813e48c0>] ? prepare_to_wait_event+0x410/0x410
> /home/fuzzy/tovald_kernel/kernel/include/linux/sched.h:2897
>  [<ffffffff82727d55>] ? common_file_perm+0x155/0x3a0
> /home/fuzzy/tovald_kernel/kernel/security/apparmor/lsm.c:426
>  [<ffffffff817453c1>] do_loop_readv_writev+0x141/0x1e0
> /home/fuzzy/tovald_kernel/kernel/fs/read_write.c:719
>  [<ffffffff8265ead9>] ? security_file_permission+0x89/0x1e0
> /home/fuzzy/tovald_kernel/kernel/security/security.c:733
>  [<ffffffff85b62390>] ? rfkill_fop_ioctl+0x150/0x150
> /home/fuzzy/tovald_kernel/kernel/net/rfkill/core.c:1227
>  [<ffffffff85b62390>] ? rfkill_fop_ioctl+0x150/0x150
> /home/fuzzy/tovald_kernel/kernel/net/rfkill/core.c:1227
>  [<ffffffff81749158>] do_readv_writev+0x5f8/0x6e0
> /home/fuzzy/tovald_kernel/kernel/fs/read_write.c:849
>  [<ffffffff81748b60>] ? vfs_write+0x4a0/0x4a0
> /home/fuzzy/tovald_kernel/kernel/include/linux/sched.h:3152
>  [<ffffffff816f498c>] ? cmpxchg_double_slab.isra.41+0x15c/0x190
> /home/fuzzy/tovald_kernel/kernel/mm/slub.c:428
>  [<     inline     >] ? spin_unlock_irqrestore
> /home/fuzzy/tovald_kernel/kernel/include/linux/spinlock.h:362
>  [<ffffffff816f661a>] ? __slab_free+0x19a/0x320
> /home/fuzzy/tovald_kernel/kernel/mm/slub.c:2731
>  [<ffffffff817a4e27>] ? __fget+0x47/0x3b0
> /home/fuzzy/tovald_kernel/kernel/fs/file.c:696
>  [<     inline     >] ? rcu_lock_release
> /home/fuzzy/tovald_kernel/kernel/include/linux/rcupdate.h:495
>  [<     inline     >] ? rcu_read_unlock
> /home/fuzzy/tovald_kernel/kernel/include/linux/rcupdate.h:930
>  [<ffffffff817a5015>] ? __fget+0x235/0x3b0
> /home/fuzzy/tovald_kernel/kernel/fs/file.c:712
>  [<ffffffff817a4e27>] ? __fget+0x47/0x3b0
> /home/fuzzy/tovald_kernel/kernel/fs/file.c:696
>  [<ffffffff817492c3>] vfs_readv+0x83/0xb0
> /home/fuzzy/tovald_kernel/kernel/fs/read_write.c:873
>  [<     inline     >] SYSC_readv
> /home/fuzzy/tovald_kernel/kernel/fs/read_write.c:899
>  [<ffffffff8174c231>] SyS_readv+0x111/0x2b0
> /home/fuzzy/tovald_kernel/kernel/fs/read_write.c:891
>  [<ffffffff8174c120>] ? rw_copy_check_uvector+0x260/0x260
> /home/fuzzy/tovald_kernel/kernel/fs/read_write.c:809
>  [<ffffffff81003044>] ? lockdep_sys_exit_thunk+0x12/0x14
> /home/fuzzy/tovald_kernel/kernel/arch/x86/entry/thunk_64.S:44
>  [<ffffffff85d87eb6>] entry_SYSCALL_64_fastpath+0x16/0x7a
> /home/fuzzy/tovald_kernel/kernel/arch/x86/entry/entry_64.S:185
> ---[ end trace b62102ffe729fb4a ]---
> 
> 
> On commit: 9638685e32af961943b679fcb72d4ddd458eb18f

Re: sched/core: WARNING in __might_sleep

[Johannes Berg]

On Mon, 2016-02-01 at 12:13 +0100, Peter Zijlstra wrote:
> 
> Yeah, from the rfkill code, which you failed to CC.

Thanks Peter :)

> In any case, this is a fail in the rfkill code, which should be
> sorted
> with the below patch (but the rfkill people should double check), and
> ideally they'd use list_empty_careful() instead of the mutex, but I
> don't know their code well enough to say if that's safe or not.

Even list_empty() is fine in this case since we go and recheck it
anyway in the calling loop, while the mutex is held.

I have commit 6736fde9672f on its way to mainline.

johannes

Re: sched/core: WARNING in __might_sleep

[Peter Zijlstra]

On Mon, Feb 01, 2016 at 12:26:06PM +0100, Johannes Berg wrote:
> On Mon, 2016-02-01 at 12:13 +0100, Peter Zijlstra wrote:
> > 
> > Yeah, from the rfkill code, which you failed to CC.
> 
> Thanks Peter :)
> 
> > In any case, this is a fail in the rfkill code, which should be
> > sorted
> > with the below patch (but the rfkill people should double check), and
> > ideally they'd use list_empty_careful() instead of the mutex, but I
> > don't know their code well enough to say if that's safe or not.
> 
> Even list_empty() is fine in this case since we go and recheck it
> anyway in the calling loop, while the mutex is held.
> 
> I have commit 6736fde9672f on its way to mainline.

OK, that looks good. Thanks!