lkml.org 
[lkml]   [2010]   [Oct]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2010-10-03 22:39    [W:0.123 / U:0.768 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site