From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753998Ab0D1TiX (ORCPT ); Wed, 28 Apr 2010 15:38:23 -0400 Received: from mail-bw0-f219.google.com ([209.85.218.219]:42631 "EHLO mail-bw0-f219.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751206Ab0D1TiS (ORCPT ); Wed, 28 Apr 2010 15:38:18 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=qmf94yQdthLahARN7AlMnQr7TXggJSg+eMb1jjE3F1yn5+kFO51z+FMIMiceoF6dZ8 tacDIOoJ/b2gOBbQFvwWkclVBn5AuxCqdqpJYZwcD7LTeItB8BoZklkMxTbhalz7xt4A dycH45rsP5Ai680HNifU2uGZgbf6lwEu7pGko= Subject: Re: 2.6.34-rc5-git7 (plus all patches) -- another suspicious rcu_dereference_check() usage. From: Eric Dumazet To: paulmck@linux.vnet.ibm.com Cc: Miles Lane , Vivek Goyal , Eric Paris , Lai Jiangshan , Ingo Molnar , Peter Zijlstra , LKML , nauman@google.com, netdev@vger.kernel.org, Jens Axboe , Gui Jianfeng , Li Zefan , Johannes Berg , shemminger@vyatta.com In-Reply-To: <20100428175426.GK2540@linux.vnet.ibm.com> References: <20100428175426.GK2540@linux.vnet.ibm.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 28 Apr 2010 21:38:11 +0200 Message-ID: <1272483491.2201.9.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le mercredi 28 avril 2010 à 10:54 -0700, Paul E. McKenney a écrit : > On Mon, Apr 26, 2010 at 08:51:06PM -0400, Miles Lane wrote: > > This one occurred during the wakeup from suspend to RAM. > > > > [ 984.724697] [ INFO: suspicious rcu_dereference_check() usage. ] > > [ 984.724700] --------------------------------------------------- > > [ 984.724703] include/linux/fdtable.h:88 invoked > > rcu_dereference_check() without protection! > > [ 984.724706] > > [ 984.724707] other info that might help us debug this: > > [ 984.724708] > > [ 984.724711] > > [ 984.724711] rcu_scheduler_active = 1, debug_locks = 1 > > [ 984.724714] no locks held by dbus-daemon/4680. > > [ 984.724717] > > [ 984.724717] stack backtrace: > > [ 984.724721] Pid: 4680, comm: dbus-daemon Not tainted 2.6.34-rc5-git7 #33 > > [ 984.724724] Call Trace: > > [ 984.724734] [] lockdep_rcu_dereference+0x9d/0xa6 > > [ 984.724740] [] fcheck_files+0xb1/0xc9 > > [ 984.724745] [] fget_light+0x35/0xab > > [ 984.724751] [] ? sock_poll_wait+0x13/0x18 > > [ 984.724755] [] ? unix_poll+0x19/0x95 > > [ 984.724762] [] do_sys_poll+0x1ff/0x3e5 > > [ 984.724766] [] ? __pollwait+0x0/0xc7 > > [ 984.724771] [] ? pollwake+0x0/0x4f > > [ 984.724776] [] ? pollwake+0x0/0x4f > > [ 984.724780] [] ? pollwake+0x0/0x4f > > [ 984.724784] [] ? pollwake+0x0/0x4f > > [ 984.724788] [] ? pollwake+0x0/0x4f > > [ 984.724793] [] ? pollwake+0x0/0x4f > > [ 984.724797] [] ? pollwake+0x0/0x4f > > [ 984.724802] [] ? pollwake+0x0/0x4f > > [ 984.724806] [] ? pollwake+0x0/0x4f > > [ 984.724812] [] sys_poll+0x50/0xbb > > [ 984.724818] [] system_call_fastpath+0x16/0x1b > > Hmmm... I am not convinced that this is a false positive. Couldn't > there be a multi-threaded process where one thread is invoking poll() > on a UNIX socket just as another thread is calling close() on it? > > The current fcheck_files() logic requires that the caller either (1) be in > an RCU read-side critical section, (2) hold ->files_lock, or (3) passing > in a files_struct with ->count equal to 1 (initialization or cleanup). > > So I don't feel comfortable just slapping an RCU read-side critical > section around this one, at least not unless someone who understands > the locking says that doing so is OK. > > Its a single threaded program. So fget_light() calls fcheck_files(files, fd); without rcu lock, but some /proc/pid/fd/... user temporarly raised files->count just before we perform the condition check.