07 Jan, 2006

6 commits

  • The NFSv4 model requires us to complete all RPC calls that might
    establish state on the server whether or not the user wants to
    interrupt it. We may also need to schedule new work (including
    new RPC calls) in order to cancel the new state.

    The asynchronous RPC model will allow us to ensure that RPC calls
    always complete, but in order to allow for "synchronous" RPC, we
    want to add the ability to wait for completion.
    The waits are, of course, interruptible.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • Shrink the RPC task structure. Instead of storing separate pointers
    for task->tk_exit and task->tk_release, put them in a structure.

    Also pass the user data pointer as a parameter instead of passing it via
    task->tk_calldata. This enables us to nest callbacks.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • I submitted this one previously - svc_tcp_recvfrom currently returns
    any errors to the caller, including ECONNRESET and the like.

    This is something svc_recv isn't able to deal with:

    len = svsk->sk_recvfrom(rqstp);
    [...]
    if (len == 0 || len == -EAGAIN) {
    [...]
    return -EAGAIN;
    }

    [...]
    return len;

    The nfsd main loop will exit when it sees an error code other than
    EAGAIN.

    The following patch fixes this problem

    svc_recv is not equipped to deal with error codes other than EAGAIN,
    and will propagate anything else (such as ECONNRESET) up to nfsd,
    causing it to exit.

    Signed-off-by: Olaf Kirch
    Cc: Trond Myklebust
    Cc: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Olaf Kirch
     
  • The hash.h hash_long function, when used on a 64 bit machine, ignores many
    of the middle-order bits. (The prime chosen it too bit-sparse).

    IP addresses for clients of an NFS server are very likely to differ only in
    the low-order bits. As addresses are stored in network-byte-order, these
    bits become middle-order bits in a little-endian 64bit 'long', and so do
    not contribute to the hash. Thus you can have the situation where all
    clients appear on one hash chain.

    So, until hash_long is fixed (or maybe forever), us a hash function that
    works well on IP addresses - xor the bytes together.

    Thanks to "Iozone" for identifying this problem.

    Cc: "Iozone"

    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     

06 Jan, 2006

22 commits


05 Jan, 2006

10 commits


04 Jan, 2006

2 commits