| 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: <20101017004515.GB1614@infradead.org> Date: Sat, 16 Oct 2010 20:45:15 -0400 From: Christoph Hellwig <hch@...radead.org> To: Nick Piggin <npiggin@...nel.dk> Cc: Christoph Hellwig <hch@...radead.org>, Dave Chinner <david@...morbit.com>, linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org Subject: Re: [PATCH 11/18] fs: Introduce per-bucket inode hash locks On Sun, Oct 17, 2010 at 04:12:13AM +1100, Nick Piggin wrote: > > With the changes Dave implemented based on my suggestions we now have > > an abstract locked hash list data type. It has the normal hash list > > operations plus lock/unlock operations. > > That's ugly. It just hides the locking. If a bit of casting bothers > you then put it in a function where it is used like I did. Exposing the implementation details of which bit of a pointer can be used as lock when cast to an unsigned long to every user of an abstract type is what I would consider ugly, and on similar issues I've certainly not been the only one. > > So if e.g. the -rt folks need > > real locks in there there is one single place they need to touch > > instead of every user. Similarly if we want to add lockdep support > > there is just one place to touch. > > It's unnecessary. What, lockdep support? -- 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