linux-kernel - Re: [Fwd: [PATCH 2/7] lock_list: a fine grain locked double linked list]

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]

Message-Id: <1170066040.6189.128.camel@twins>
Date:	Mon, 29 Jan 2007 11:20:40 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [Fwd: [PATCH 2/7] lock_list: a fine grain locked double linked
	list]

On Sun, 2007-01-28 at 17:20 +0000, Christoph Hellwig wrote:
> > Provide a simple fine grain locked double link list.
> > 
> > It is build upon the regular double linked list primitives, spinlocks and RCU.
> > 
> > Locking is peculiar in that edges are locked, this avoid the circular lock
> > dependancy created by the fact that the regular linked lists are circular.
> > 
> > Item deletion requires that both surrounding elements are locked, however since
> > the locking rules dictate that we lock elements in a single direction we have
> > to lock the previous element while it might be deleted under us. Hence the
> > requirement that all elements are RCU freed.
> 
> I think implicitly locked data structures are very bad for code readability
> and debugability.  What's even worse here is that we have a requirement that
> all members are RCU freed.
> 
> Note that we also have another implicitly locked (and refcounted) list
> implementation in klist.[ch] - if we find consensus that we want implicitly
> locked list we should figure out whether we want lock_list or klist semantics
> and stick to one of them.

klist is quite different in that it locks the whole list. The proposed
data structure locks each edge, that is it will allow concurrent
deletion of elements as long as they don't share neighbours.

> What uses do you have planned for this data structure?  In general I think
> we'd be better off to simplify the data structures as in my files_list_lock
> proposal instead of complicating the locking.

Getting rid of the s_files list like you proposed would of course be a
much better solution, and I'll look into that.

Not having the VFS knowledge you do I just smashed the lock and kept
current semantics.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/