| 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
| ||
|
Message-ID: <20101018162105.GB9571@infradead.org> Date: Mon, 18 Oct 2010 12:21:05 -0400 From: Christoph Hellwig <hch@...radead.org> To: Andi Kleen <andi@...stfloor.org> Cc: Nick Piggin <npiggin@...nel.dk>, Dave Chinner <david@...morbit.com>, Christoph Hellwig <hch@...radead.org>, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 11/18] fs: Introduce per-bucket inode hash locks On Mon, Oct 18, 2010 at 06:16:50PM +0200, Andi Kleen wrote: > > Hiding the type of lock, and hiding the fact that it sets the low bit? > > I don't agree. We don't have synchronization in our data structures, > > where possible, because it is just restrictive or goes wrong when people > > don't think enough about the locking. > > I fully agree. The old skb lists in networking made this mistake > long ago and it was a big problem, until people essentially stopped > using it (always using __ variants) and it was eventually removed. > > Magic locking in data structures is usually a bad idea. Err, there is no implicit locking in the calls to hlist_*. There is just two small wrappers for the bit-lock/unlock so that the callers don't have to know how the lock is overloaded onto the pointer in the list head. -- 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