[lkml]   [2000]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: NFS locking bug -- limited mtime resolution means nfs_lock() does not provide coherency guarantee

    > Yes. fs/read_write calls the NFS subsystem. The problem then is that
    > NFS uses the generic_file_{read,write,mmap}() interfaces. These are
    > what enforce use of the page cache.

    So, don't use generic*() when locking is active. It's what most other
    UNIX-based NFS clients do. Even if it is "stupid beyond
    belief", it works.

    > You could drop these functions, but that would mean designing an
    > entire VFS for NFS's use alone. Such a decision would have to be very
    > well motivated in order to convince Linus.

    Avoiding corruption.

    > >> As far as I can see, the current use of the page cache should
    > >> be safe as long as applications respect the locking boundaries,
    > >> and don't expect consistency outside locked areas.
    > > Then the code ought to enforce page aligned locks. Of course,
    > > while that will produce correctness, it will violate the
    > > principle of least surprise. It might be better to simply
    > AFAICS that would be a bad idea, since it will lead to programs having
    > to know about the hardware granularity. You could easily imagine
    > deadlock situations that could arise if one program is unwittingly
    > locking an area that is meant to be claimed by another.

    I can't imagine any deadlock scenarios. If the app locks on a page
    boundary, then accept it, otherwise return an error. But
    it does violate least surprise, so I think bypassing the page
    cache when locking is active is better.

    > I'm not clear on why you want to enforce page alignedness though? As
    > long as writes respect the lock boundaries (and not page boundaries)
    > why would use of a page cache change matters?

    For the reason that was pointed earlier by someone else as to why your fix in
    adequate. Since the I/O is page-based, if the locks are not, then two threads
    on two different clients will step over each other's locked regions.

    Folks might think that NLM locking is brain dead, and they wouldn't get an
    argument from me. But if you are going to document that you support it, then
    please get it right.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 12:45    [W:10.095 / U:0.476 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site