linux-kernel - Re: [PATCH 05/17] fs: icache lock i

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, 1 Oct 2010 02:16:02 -0400
From:	Christoph Hellwig <hch@...radead.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Christoph Hellwig <hch@...radead.org>,
	Dave Chinner <david@...morbit.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 05/17] fs: icache lock i_count

On Thu, Sep 30, 2010 at 11:04:16PM -0700, Andrew Morton wrote:
> No, we've run into problems *frequently*.  A common case is where we
> convert a mutex to a spinlock or vice versa.  If you don't rename the
> lock, the code still compiles (with warnings) and crashes horridly at
> runtime.

Sorry, if you run code with that obvious warnings you beg for trouble.
If you really believe your advanced users arw too stupid to read
compiler warnings enforcing -Werror is for sure better than obsfucating
the code.

> Still wrong.  We do this frequently and we do it in areas where we
> believe that the implementation might change in the future.
> 
> Had we done it with i_count from day one then this part of the patchset
> would be far simpler.

I don't thin that's quite true.  The big point of using i_lock is that
we can hold it over accessing other things that also are protected by
it.  No accessor is going to help you with that.  For plain opencoded
increments we indeed need a helper as shown by Chris' aio speedup and
the churn in here - but that's already added later in the series and I
asked Dave to move it before this patch.

--
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/