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
| ||
|
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/
Powered by blists - more mailing lists