From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754575AbbAFISX (ORCPT ); Tue, 6 Jan 2015 03:18:23 -0500 Received: from cantor2.suse.de ([195.135.220.15]:33304 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752933AbbAFISW (ORCPT ); Tue, 6 Jan 2015 03:18:22 -0500 Date: Tue, 06 Jan 2015 09:18:20 +0100 Message-ID: From: Takashi Iwai To: Dave Jones Cc: Linus Torvalds , Linux Kernel Mailing List , Al Viro , Eric Paris , Peter Zijlstra Subject: Re: Linux 3.19-rc3 In-Reply-To: <20150106024634.GA26714@codemonkey.org.uk> References: <20150106024634.GA26714@codemonkey.org.uk> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL/10.8 Emacs/24.4 (x86_64-suse-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org At Mon, 5 Jan 2015 21:46:34 -0500, Dave Jones wrote: > > On Mon, Jan 05, 2015 at 05:46:15PM -0800, Linus Torvalds wrote: > > It's a day delayed - not because of any particular development issues, > > but simply because I was tiling a bathroom yesterday. But rc3 is out > > there now, and things have stayed reasonably calm. I really hope that > > implies that 3.19 is looking good, but it's equally likely that it's > > just that people are still recovering from the holiday season. > > > > A bit over three quarters of the changes here are drivers - mostly > > networking, thermal, input layer, sound, power management. The rest is > > misc - filesystems, core networking, some arch fixes, etc. But all of > > it is pretty small. > > > > So go out and test, > > This has been there since just before rc1. Is there a fix for this > stalled in someones git tree maybe ? > > [ 7.952588] WARNING: CPU: 0 PID: 299 at kernel/sched/core.c:7303 __might_sleep+0x8d/0xa0() > [ 7.952592] do not call blocking ops when !TASK_RUNNING; state=1 set at [] prepare_to_wait+0x2a/0x90 > [ 7.952595] CPU: 0 PID: 299 Comm: systemd-readahe Not tainted 3.19.0-rc3+ #100 > [ 7.952597] 0000000000001c87 00000000720a2c76 ffff8800b2513c88 ffffffff915b47c7 > [ 7.952598] ffffffff910a3648 ffff8800b2513ce0 ffff8800b2513cc8 ffffffff91062c30 > [ 7.952599] 0000000000000000 ffffffff91796fb2 000000000000026d 0000000000000000 > [ 7.952600] Call Trace: > [ 7.952603] [] dump_stack+0x4c/0x65 > [ 7.952604] [] ? down_trylock+0x28/0x40 > [ 7.952606] [] warn_slowpath_common+0x80/0xc0 > [ 7.952607] [] warn_slowpath_fmt+0x50/0x70 > [ 7.952608] [] ? prepare_to_wait+0x2a/0x90 > [ 7.952610] [] ? prepare_to_wait+0x2a/0x90 > [ 7.952611] [] __might_sleep+0x8d/0xa0 > [ 7.952614] [] mutex_lock_nested+0x39/0x3e0 > [ 7.952616] [] ? trace_hardirqs_on+0xd/0x10 > [ 7.952617] [] ? prepare_to_wait+0x5c/0x90 > [ 7.952620] [] fanotify_read+0xe0/0x5b0 > [ 7.952622] [] ? sched_clock_cpu+0xc1/0xd0 > [ 7.952624] [] ? selinux_file_permission+0xb9/0x130 > [ 7.952626] [] ? prepare_to_wait_event+0xf0/0xf0 > [ 7.952628] [] __vfs_read+0x13/0x50 > [ 7.952629] [] vfs_read+0x88/0x140 > [ 7.952631] [] SyS_read+0x57/0xd0 > [ 7.952633] [] system_call_fastpath+0x12/0x17 Just "me too" (but overlooked until recently). The cause is a mutex_lock() call right after prepare_to_wait() with TASK_INTERRUPTIBLE in fanotify_read(). static ssize_t fanotify_read(struct file *file, char __user *buf, size_t count, loff_t *pos) { .... while (1) { prepare_to_wait(&group->notification_waitq, &wait, TASK_INTERRUPTIBLE); mutex_lock(&group->notification_mutex); I saw Peter already fixed a similar code in inotify_user.c by commit e23738a7300a (but interestingly for a different reason, "Deal with nested sleeps"). Supposedly a similar fix would be needed for fanotify_user.c. Eric, any fixes planned? thanks, Takashi