07 Jan, 2006

5 commits


26 Nov, 2005

1 commit


07 Nov, 2005

1 commit

  • This is the fs/ part of the big kfree cleanup patch.

    Remove pointless checks for NULL prior to calling kfree() in fs/.

    Signed-off-by: Jesper Juhl
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Jesper Juhl
     

05 Nov, 2005

3 commits

  • Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • RFC 3530 states that for OPEN_DOWNGRADE "The share_access and share_deny
    bits specified must be exactly equal to the union of the share_access and
    share_deny bits specified for some subset of the OPENs in effect for
    current openowner on the current file.

    Setattr is currently violating the NFSv4 rules for OPEN_DOWNGRADE in that
    it may cause a downgrade from OPEN4_SHARE_ACCESS_BOTH to
    OPEN4_SHARE_ACCESS_WRITE despite the fact that there exists no open file
    with O_WRONLY access mode.

    Fix the problem by replacing nfs4_find_state() with a modified version of
    nfs_find_open_context().

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • We must not remove the nfs4_state structure from the inode open lists
    before we are in sequence lock.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     

21 Oct, 2005

2 commits


19 Oct, 2005

6 commits

  • Storing a pointer to the struct rpc_task in the nfs_seqid is broken
    since the nfs_seqid may be freed well after the task has been destroyed.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • Currently we fail to do so if the process was signalled.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • We no longer need to worry about collisions between close() and the state
    recovery code, since the new close will automatically recheck the
    file state once it is done waiting on its sequence slot.

    Ditto for the nfs4_proc_locku() procedure.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • OPEN, CLOSE, etc no longer need these semaphores to ensure ordering of
    requests.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • Once the state_owner and lock_owner semaphores get removed, it will be
    possible for other OPEN requests to reopen the same file if they have
    lower sequence ids than our CLOSE call.
    This patch ensures that we recheck the file state once
    nfs_wait_on_sequence() has completed waiting.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • NFSv4 file state-changing functions such as OPEN, CLOSE, LOCK,... are all
    labelled with "sequence identifiers" in order to prevent the server from
    reordering RPC requests, as this could cause its file state to
    become out of sync with the client.

    Currently the NFS client code enforces this ordering locally using
    semaphores to restrict access to structures until the RPC call is done.
    This, of course, only works with synchronous RPC calls, since the
    user process must first grab the semaphore.
    By dropping semaphores, and instead teaching the RPC engine to hold
    the RPC calls until they are ready to be sent, we can extend this
    process to work nicely with asynchronous RPC calls too.

    This patch adds a new list called "rpc_sequence" that defines the order
    of the RPC calls to be sent. We add one such list for each state_owner.
    When an RPC call is ready to be sent, it checks if it is top of the
    rpc_sequence list. If so, it proceeds. If not, it goes back to sleep,
    and loops until it hits top of the list.
    Once the RPC call has completed, it can then bump the sequence id counter,
    and remove itself from the rpc_sequence list, and then wake up the next
    sleeper.

    Note that the state_owner sequence ids and lock_owner sequence ids are
    all indexed to the same rpc_sequence list, so OPEN, LOCK,... requests
    are all ordered w.r.t. each other.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     

23 Jun, 2005

3 commits


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds