From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757761AbbIDBPJ (ORCPT ); Thu, 3 Sep 2015 21:15:09 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:37384 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753109AbbIDBPG (ORCPT ); Thu, 3 Sep 2015 21:15:06 -0400 X-Helo: d03dlp01.boulder.ibm.com X-MailFrom: paulmck@linux.vnet.ibm.com X-RcptTo: linux-security-module@vger.kernel.org Date: Thu, 3 Sep 2015 18:14:58 -0700 From: "Paul E. McKenney" To: "Serge E. Hallyn" Cc: Tejun Heo , Felipe Balbi , James Morris , linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Linux OMAP Mailing List Subject: Re: [PATCH v2] security: device_cgroup: fix RCU lockdep splat Message-ID: <20150904011458.GT4029@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150902125608.GA8299@saruman.tx.rr.com> <1441199548-29633-1-git-send-email-balbi@ti.com> <20150902162450.GJ22326@mtj.duckdns.org> <20150903001433.GB4029@linux.vnet.ibm.com> <20150903134839.GB8834@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150903134839.GB8834@mail.hallyn.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15090401-8236-0000-0000-00000EE4AF65 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 03, 2015 at 08:48:39AM -0500, Serge E. Hallyn wrote: > On Wed, Sep 02, 2015 at 05:14:33PM -0700, Paul E. McKenney wrote: > > On Wed, Sep 02, 2015 at 12:24:50PM -0400, Tejun Heo wrote: > > > cc'ing Paul. > > > > > > On Wed, Sep 02, 2015 at 08:12:28AM -0500, Felipe Balbi wrote: > > > > while booting AM437x device, the following splat > > > > triggered: > > > > > > > > [ 12.005238] =============================== > > > > [ 12.009749] [ INFO: suspicious RCU usage. ] > > > > [ 12.014116] 4.2.0-next-20150831 #1154 Not tainted > > > > [ 12.019050] ------------------------------- > > > > [ 12.023408] security/device_cgroup.c:405 device_cgroup:verify_new_ex called without proper synchronization! > > > ... > > > > [ 12.128326] [] (verify_new_ex) from [] (devcgroup_access_write+0x374/0x658) > > > > [ 12.137426] [] (devcgroup_access_write) from [] (cgroup_file_write+0x28/0x1bc) > > > > [ 12.146796] [] (cgroup_file_write) from [] (kernfs_fop_write+0xc0/0x1b8) > > > > [ 12.155620] [] (kernfs_fop_write) from [] (__vfs_write+0x1c/0xd8) > > > > [ 12.163783] [] (__vfs_write) from [] (vfs_write+0x90/0x16c) > > > > [ 12.171426] [] (vfs_write) from [] (SyS_write+0x44/0x9c) > > > > [ 12.178806] [] (SyS_write) from [] (ret_fast_syscall+0x0/0x1c) > > > > > > This shouldn't be happening because devcgroup_access_write() always > > > grabs devcgroup_mutex. Looking at the log, the culprit seems to be > > > f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to > > > RCU_LOCKDEP_WARN()"). It missed the bang for the second test while > > > inverting it, so adding rcu_read_lock() isn't the right fix here. > > > > > > Paul, can you please fix it? > > > > Gah! Please see below. > > > > Thanx, Paul > > > > ------------------------------------------------------------------------ > > > > security/device_cgroup: Fix RCU_LOCKDEP_WARN() condition > > > > f78f5b90c4ff ("rcu: Rename rcu_lockdep_assert() to RCU_LOCKDEP_WARN()") > > introduced a bug by incorrectly inverting the condition when moving from > > rcu_lockdep_assert() to RCU_LOCKDEP_WARN(). This commit therefore fixes > > the inversion. > > > > Reported-by: Felipe Balbi > > Reported-by: Tejun Heo > > Signed-off-by: Paul E. McKenney > > Cc: Serge Hallyn > > Oh, makes sense :) (didn't see the original patch when it came by, sorry) I should have CCed you, apologies for failing to do so. > Acked-by: Serge Hallyn Added, thank you! Thanx, Paul > > diff --git a/security/device_cgroup.c b/security/device_cgroup.c > > index 73455089feef..03c1652c9a1f 100644 > > --- a/security/device_cgroup.c > > +++ b/security/device_cgroup.c > > @@ -401,7 +401,7 @@ static bool verify_new_ex(struct dev_cgroup *dev_cgroup, > > bool match = false; > > > > RCU_LOCKDEP_WARN(!rcu_read_lock_held() && > > - lockdep_is_held(&devcgroup_mutex), > > + !lockdep_is_held(&devcgroup_mutex), > > "device_cgroup:verify_new_ex called without proper synchronization"); > > > > if (dev_cgroup->behavior == DEVCG_DEFAULT_ALLOW) { >