diff mbox

sched/core: WARNING in __might_sleep

Message ID 20160201111313.GQ6357@twins.programming.kicks-ass.net (mailing list archive)
State Rejected
Delegated to: Johannes Berg
Headers show

Commit Message

Peter Zijlstra Feb. 1, 2016, 11:13 a.m. UTC 
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(+)



> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Johannes Berg Feb. 1, 2016, 11:26 a.m. UTC | #1 
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

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Peter Zijlstra Feb. 1, 2016, 11:44 a.m. UTC | #2 
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!
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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);