linux-kernel - Re: configfs, dlm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 12 Dec 2008 11:06:15 +0100
From:	Louis Rilling <Louis.Rilling@...labs.com>
To:	Steven Whitehouse <swhiteho@...hat.com>,
	linux-kernel@...r.kernel.org, cluster-devel@...hat.com
Subject: Re: configfs, dlm_controld & lockdep

On 11/12/08  9:34 -0800, Joel Becker wrote:
> On Thu, Dec 11, 2008 at 03:44:41PM +0100, Louis Rilling wrote:
> > These warnings are known issues. This results from a lack of lockdep annotations
> > in configfs. I must admit that I started to send patches for that a few months
> > ago, and then could not find time to finish this work.
> > 
> > The problem is a bit harder than just playing with I_MUTEX_CHILD, I_MUTEX_PARENT
> > and I_MUTEX_NORMAL, since configfs recursively locks variable numbers
> > (this can go to as many as the depth of the whole configfs tree) of
> > config_group inodes during operations like mkdir(), rmdir(), and depend_item().
> > 
> > I was working on two kinds of solutions:
> > 1) insert lockdep_off()/lockdep_on() at the places of recursion,
> > 2) separate default groups inode mutex classes according to their depth under
> > the created group they belong to.
> > 
> > People tend to reject any proposition like 1), but IIRC Joel was tending to
> > accept it.
> > 
> > Solution 2) does not work for depend_item(). This needs to rework the locking
> > scheme of depend_item() by removing the variable lock recursion depth, and I
> > think that it's doable thanks to the configfs_dirent_lock.
> > 	Joel, what do you think about this?
> 
> 	I've been waiting for your patch for (1).  I am wary of the (2)
> approach.  Not because it wouldn't work for mkdir(2) - I think it would.
> But rmdir(2) has the same recursive locking, with far more importance
> (live objects), and would print the same error.

??

(2) is fine for both mkdir() and rmdir(), since they both lock inodes'
mutexes along paths, and only paths. The problem is depend_item().

Anyway, I'll post patches based on (1) and later I'll propose patches based
on (2).

Louis

-- 
Dr Louis Rilling			Kerlabs
Skype: louis.rilling			Batiment Germanium
Phone: (+33|0) 6 80 89 08 23		80 avenue des Buttes de Coesmes
http://www.kerlabs.com/			35700 Rennes

Download attachment "signature.asc" of type "application/pgp-signature" (190 bytes)