02 Oct, 2006

2 commits

  • If lockd_up fails - what should we expect? Do we have to later call
    lockd_down?

    Well the nfs client thinks "no", the nfs server thinks "yes". lockd thinks
    "yes".

    The only answer that really makes sense is "no" !!

    So:
    Make lockd_up only increment nlmsvc_users on success.
    Make nfsd handle errors from lockd_up properly.
    Make sure lockd_up(0) never fails when lockd is running
    so that the 'reclaimer' call to lockd_up doesn't need to
    be error checked.

    Cc: "J. Bruce Fields"
    Signed-off-by: Neil Brown
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    NeilBrown
     
  • Currently lockd listens on UDP always, and TCP if CONFIG_NFSD_TCP is set.

    However as lockd performs services of the client as well, this is a problem.
    If CONFIG_NfSD_TCP is not set, and a tcp mount is used, the server will not be
    able to call back to lockd.

    So:
    - add an option to lockd_up saying which protocol is needed
    - Always open sockets for which an explicit port was given, otherwise
    only open a socket of the type required
    - Change nfsd to do one lockd_up per socket rather than one per thread.

    This
    - removes the dependancy on CONFIG_NFSD_TCP
    - means that lockd may open sockets other than at startup
    - means that lockd will *not* listen on UDP if the only
    mounts are TCP mount (and nfsd hasn't started).

    The latter is the only one that concerns me at all - I don't know if this
    might be a problem with some servers.

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

    NeilBrown
     

27 Sep, 2006

1 commit


09 Jun, 2006

1 commit

  • Currently it is possible for a task to remove its locks at the same time as
    the NLM recovery thread is trying to recover them. This quickly leads to an
    Oops.
    Protect the locks using an rw semaphore while they are being recovered.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     

21 Mar, 2006

4 commits

  • Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • The patch "stop abusing file_lock_list introduces a couple of bugs since
    the locks may be copied and need to be removed from the lists when they are
    destroyed.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • Currently lockd directly access the file_lock_list from fs/locks.c.
    It does so to mark locks granted or reclaimable. This is very
    suboptimal, because a) lockd needs to poke into locks.c internals, and
    b) it needs to iterate over all locks in the system for marking locks
    granted or reclaimable.

    This patch adds lists for granted and reclaimable locks to the nlm_host
    structure instead, and adds locks to those.

    nlmclnt_lock:
    now adds the lock to h_granted instead of setting the
    NFS_LCK_GRANTED, still O(1)

    nlmclnt_mark_reclaim:
    goes away completely, replaced by a list_splice_init.
    Complexity reduced from O(locks in the system) to O(1)

    reclaimer:
    iterates over h_reclaim now, complexity reduced from
    O(locks in the system) to O(locks per nlm_host)

    Signed-off-by: Christoph Hellwig
    Signed-off-by: Trond Myklebust

    Christoph Hellwig
     
  • Instead we use the nlm_lockowner->pid.

    Signed-off-by: Trond Myklebust

    Trond Myklebust
     

15 Feb, 2006

1 commit

  • If 2 threads attached to the same process are blocking on different locks on
    different files (maybe even on different servers) but have the same lock
    arguments (i.e. same offset+length - actually quite common, since most
    processes try to lock the entire file) then the first GRANTED call that wakes
    one up will also wake the other.

    Currently when the NLM_GRANTED callback comes in, lockd walks the list of
    blocked locks in search of a match to the lock that the NLM server has
    granted. Although it checks the lock pid, start and end, it fails to check
    the filehandle and the server address.

    By checking the filehandle and server IP address, we ensure that this only
    happens if the locks truly are referencing the same file.

    Signed-off-by: Trond Myklebust
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Trond Myklebust
     

20 Dec, 2005

1 commit


23 Jun, 2005

2 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