[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101001061602.GA19107@infradead.org>
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/
Powered by blists - more mailing lists