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:2.596 / U:0.084 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site