Eric Lee / smarc-fsl-linux-kernel

18 Jul, 2007

1 commit

  • 9a8db97e7   knfsd: lockd: nfsd4: use same grace period for lockd and nfsd4 ... Browse Code »

    Both lockd and (in the nfsv4 case) nfsd enforce a "grace period" after reboot,
    during which clients may reclaim locks from the previous server instance, but
    may not acquire new locks.

    Currently the lockd and nfsd enforce grace periods of different lengths. This
    may cause problems when we reboot a server with both v2/v3 and v4 clients.
    For example, if the lockd grace period is shorter (as is likely the case),
    then a v3 client might acquire a new lock that conflicts with a lock already
    held (but not yet reclaimed) by a v4 client.

    This patch calculates a lease time that lockd and nfsd can both use.

    Signed-off-by: Marc Eshel
    Signed-off-by: J. Bruce Fields
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Marc Eshel
     

14 Dec, 2006

1 commit

21 Oct, 2006

1 commit

17 Oct, 2006

1 commit

  • d343fce14   [PATCH] knfsd: Allow lockd to drop replies as appropriate ... Browse Code »

    It is possible for the ->fopen callback from lockd into nfsd to find that an
    answer cannot be given straight away (an upcall is needed) and so the request
    has to be 'dropped', to be retried later. That error status is not currently
    propagated back.

    So:
    Change nlm_fopen to return nlm error codes (rather than a private
    protocol) and define a new nlm_drop_reply code.
    Cause nlm_drop_reply to cause the rpc request to get rpc_drop_reply
    when this error comes back.
    Cause svc_process to drop a request which returns a status of
    rpc_drop_reply.

    [akpm@osdl.org: fix warning storm]
    Cc: Marc Eshel
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     

17 Apr, 2005

1 commit

  • 1da177e4c   Linux-2.6.12-rc2 ... Browse Code »

    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