Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 07 1月, 2009 7 次提交
  3. 24 12月, 2008 1 次提交
  5. 25 11月, 2008 1 次提交
    • C
      NLM: client-side nlm_lookup_host() should avoid matching on srcaddr · a8d82d9b
      由 Chuck Lever 提交于 
      Since commit c98451bd, the loop in nlm_lookup_host() unconditionally
compares the host's h_srcaddr field to the incoming source address.
For client-side nlm_host entries, both are always AF_UNSPEC, so this
check is unnecessary.

Since commit 781b61a6, which added support for AF_INET6 addresses to
nlm_cmp_addr(), nlm_cmp_addr() now returns FALSE for AF_UNSPEC
addresses, which causes nlm_lookup_host() to create a fresh nlm_host
entry every time it is called on the client.

These extra entries will eventually expire once the server is
unmounted, so the impact of this regression, introduced with lockd
IPv6 support in 2.6.28, should be minor.

We could fix this by adding an arm in nlm_cmp_addr() for AF_UNSPEC
addresses, but really, nlm_lookup_host() shouldn't be matching on the
srcaddr field for client-side nlm_host lookups.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      a8d82d9b
  7. 31 10月, 2008 1 次提交
  9. 30 10月, 2008 1 次提交
  11. 29 10月, 2008 1 次提交
  13. 04 10月, 2008 4 次提交
  15. 30 9月, 2008 11 次提交
  17. 24 4月, 2008 4 次提交
    • J
      lockd: convert nsm_mutex to a spinlock · d8421202
      由 J. Bruce Fields 提交于 
      There's no reason for a mutex here, except to allow an allocation under
the lock, which we can avoid with the usual trick of preallocating
memory for the new object and freeing it if it turns out to be
unnecessary.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      d8421202
    • J
      lockd: clean up __nsm_find() · a95e56e7
      由 J. Bruce Fields 提交于 
      Use list_for_each_entry().  Also, in keeping with kernel style, make the
normal case (kzalloc succeeds) unindented and handle the abnormal case
with a goto.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      a95e56e7
    • J
      lockd: fix race in nlm_release() · 164f98ad
      由 J. Bruce Fields 提交于 
      The sm_count is decremented to zero but left on the nsm_handles list.
So in the space between decrementing sm_count and acquiring nsm_mutex,
it is possible for another task to find this nsm_handle, increment the
use count and then enter nsm_release itself.

Thus there's nothing to prevent the nsm being freed before we acquire
nsm_mutex here.
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      164f98ad
    • N
      knfsd: Remove NLM_HOST_MAX and associated logic. · 1447d25e
      由 NeilBrown 提交于 
      Lockd caches information about hosts that have recently held locks to
expedite the taking of further locks.

It periodically discards this information for hosts that have not been
used for a few minutes.

lockd currently has a value NLM_HOST_MAX, and changes the 'garbage
collection' behaviour when the number of hosts exceeds this threshold.

However its behaviour is strange, and likely not what was intended.
When the number of hosts exceeds the max, it scans *less* often (every
2 minutes vs every minute) and allows unused host information to
remain around longer (5 minutes instead of 2).

Having this limit is of dubious value anyway, and we have not
suffered from the code not getting the limit right, so remove the
limit altogether.  We go with the larger values (discard 5 minute old
hosts every 2 minutes) as they are probably safer.

Maybe the periodic garbage collection should be replace to with
'shrinker' handler so we just respond to memory pressure....
Acked-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NNeil Brown <neilb@suse.de>
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      1447d25e
  19. 20 3月, 2008 1 次提交
  21. 11 2月, 2008 2 次提交
    • J
      NLM: have server-side RPC clients default to soft RPC tasks · 90bd17c8
      由 Jeff Layton 提交于 
      Now that it no longer does an RPC ping, lockd always ends up queueing
an RPC task for the GRANT_MSG callback. But, it also requeues the block
for later attempts. Since these are hard RPC tasks, if the client we're
calling back goes unresponsive the GRANT_MSG callbacks can stack up in
the RPC queue.

Fix this by making server-side RPC clients default to soft RPC tasks.
lockd requeues the block anyway, so this should be OK.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      90bd17c8
    • J
      NLM: set RPC_CLNT_CREATE_NOPING for NLM RPC clients · 031fd3aa
      由 Jeff Layton 提交于 
      It's currently possible for an unresponsive NLM client to completely
lock up a server's lockd. The scenario is something like this:

1) client1 (or a process on the server) takes a lock on a file
2) client2 tries to take a blocking lock on the same file and
   awaits the callback
3) client2 goes unresponsive (plug pulled, network partition, etc)
4) client1 releases the lock

...at that point the server's lockd will try to queue up a GRANT_MSG
callback for client2, but first it requeues the block with a timeout of
30s. nlm_async_call will attempt to bind the RPC client to client2 and
will call rpc_ping. rpc_ping entails a sync RPC call and if client2 is
unresponsive it will take around 60s for that to time out. Once it times
out, it's already time to retry the block and the whole process repeats.

Once in this situation, nlmsvc_retry_blocked will never return until
the host starts responding again. lockd won't service new calls.

Fix this by skipping the RPC ping on NLM RPC clients. This makes
nlm_async_call return quickly when called.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NJ. Bruce Fields <bfields@citi.umich.edu>
      031fd3aa
  23. 02 2月, 2008 2 次提交
  25. 11 7月, 2007 2 次提交
  27. 15 5月, 2007 1 次提交
  29. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      由 Tim Schmielau 提交于 
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
recently, it makes sense again to remove other superfluous sched.h includes.
There are quite a lot of files which include it but don't actually need
anything defined in there.  Presumably these includes were once needed for
macros that used to live in sched.h, but moved to other header files in the
course of cleaning it up.

To ease the pain, this time I did not fiddle with any header files and only
removed #includes from .c-files, which tend to cause less trouble.

Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
configs in arch/arm/configs on arm.  I also checked that no new warnings were
introduced by the patch (actually, some warnings are removed that were emitted
by unnecessarily included header files).
Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a