From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753865Ab1C1RMV (ORCPT ); Mon, 28 Mar 2011 13:12:21 -0400 Received: from hrndva-omtalb.mail.rr.com ([71.74.56.122]:58893 "EHLO hrndva-omtalb.mail.rr.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751755Ab1C1RMU (ORCPT ); Mon, 28 Mar 2011 13:12:20 -0400 X-Authority-Analysis: v=1.1 cv=ZtuXOl23UuD1yoJUTgnZ6i6Z5VPlPhPMWCeUNtN8OGA= c=1 sm=0 a=XYJHFtupD_QA:10 a=D48tj3hmCtUA:10 a=kj9zAlcOel0A:10 a=OPBmh+XkhLl+Enan7BmTLg==:17 a=LESEnKSbvW59AB97iioA:9 a=PeO1bUB_sFzj-rYQNsQA:7 a=TU2OqO3_9d_pbHpYzllarIdWW9sA:4 a=CjuIK1q_8ugA:10 a=OPBmh+XkhLl+Enan7BmTLg==:117 X-Cloudmark-Score: 0 X-Originating-IP: 67.242.120.143 Date: Mon, 28 Mar 2011 13:12:17 -0400 From: Steven Rostedt To: Tetsuo Handa Cc: peterz@infradead.org, mingo@redhat.com, linux-kernel@vger.kernel.org Subject: Re: [RFC] seqlock,lockdep: Add lock primitives to read_seqbegin(). Message-ID: <20110328171217.GA8529@home.goodmis.org> References: <201103261312.AEJ01293.OVFJFSLtHOFOMQ@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201103261312.AEJ01293.OVFJFSLtHOFOMQ@I-love.SAKURA.ne.jp> User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 26, 2011 at 01:12:17PM +0900, Tetsuo Handa wrote: > I got a freeze between "seqlock_t rename_lock" and "DEFINE_BRLOCK(vfsmount_lock)" Egad, that DEFINE_BRLOCK() is a scary macro. Turns into DEFINE_LGLOCK() and creates a local and global lock. > > But there is still a problem. It seems to me that lockdep checks for this bug > only when a new locking pattern (a locking pattern which was not already added > to lockdep database) is added. This freeze can be triggered by running > > while :; do newns /sbin/pivot_root /proc/ /proc/sys/; done > > on one terminal and running > > while :; do /bin/ls -l /proc/*/exe; done > > on another terminal. (The "newns" is a program that unshares the mnt namespace > before execve() using CLONE_NEWNS.) But even after applying the patch above, > lockdep does not show the trace above. > > lockdep shows the trace above only after I run test programs for TOMOYO (which > causes a locking pattern that was generated by neither > "/sbin/pivot_root /proc/ /proc/sys/" nor "/bin/ls -l /proc/*/exe" to be added > to lockdep database). > > I think that we want some method for rechecking already added locking pattern. > Maybe it is run by (e.g.) every 60 seconds. Maybe it is run when stall checking > mechanisms report the possibility of stall. (The sysrq key didn't work after > the freeze occurred.) This is where you confused me. Why would a pattern that was previously checked, suddenly break? If we found A->B and then come across B->A, lockdep should surely catch it. Maybe I don't understand exactly whay you are trying to say. > > Also, what to do with __read_seqcount_begin() case? Since seqcount_t does not > have a spinlock embedded into the struct, we can't use lock primitives...? > We could probably just add a lockdep key to the seqcount, and "acquire" and "release" it when necessary. I can look into that as I'm playing around with lockdep now anyway ;) -- Steve