Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 17 12月, 2010 2 次提交
  3. 25 10月, 2010 1 次提交
  5. 30 9月, 2010 1 次提交
    • S
      sunrpc: fix up rpcauth_remove_module section mismatch · c135e84a
      由 Stephen Rothwell 提交于 
      On Wed, 29 Sep 2010 14:02:38 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the final tree, today's linux-next build (powerpc
> ppc44x_defconfig) produced tis warning:
>
> WARNING: net/sunrpc/sunrpc.o(.init.text+0x110): Section mismatch in reference from the function init_sunrpc() to the function .exit.text:rpcauth_remove_module()
> The function __init init_sunrpc() references
> a function __exit rpcauth_remove_module().
> This is often seen when error handling in the init function
> uses functionality in the exit path.
> The fix is often to remove the __exit annotation of
> rpcauth_remove_module() so it may be used outside an exit section.
>
> Probably caused by commit 2f72c9b7
> ("sunrpc: The per-net skeleton").

This actually causes a build failure on a sparc32 defconfig build:

`rpcauth_remove_module' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o

I applied the following patch for today:

Fixes:

`rpcauth_remove_module' referenced in section `.init.text' of net/built-in.o: defined in discarded section `.exit.text' of net/built-in.o
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NPavel Emelyanov <xemul@openvz.org>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      c135e84a
  7. 13 9月, 2010 1 次提交
  9. 11 8月, 2010 1 次提交
  11. 04 8月, 2010 5 次提交
  13. 21 7月, 2010 1 次提交
  15. 15 5月, 2010 3 次提交
  17. 23 4月, 2010 1 次提交
  19. 03 12月, 2009 1 次提交
    • T
      RPC: Fix two potential races in put_rpccred · f0380f3d
      由 Trond Myklebust 提交于 
      It is possible for rpcauth_destroy_credcache() to cause the rpc credentials
to be unhashed while put_rpccred is waiting for the rpc_credcache_lock on
another cpu. Should this happen, then we can end up calling
hlist_del_rcu(&cred->cr_hash) a second time in put_rpccred, thus causing
list corruption.

Should the credential actually be hashed, it is also possible for
rpcauth_lookup_credcache to find and reference it before we get round to
unhashing it. In this case, the call to rpcauth_unhash_cred will fail, and
so we should just exit without destroying the cred.
Reported-by: NNeil Brown <neilb@suse.de>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      f0380f3d
  21. 30 11月, 2009 1 次提交
  23. 16 9月, 2009 1 次提交
  25. 24 12月, 2008 2 次提交
    • P
      optimize attribute timeouts for "noac" and "actimeo=0" · 64672d55
      由 Peter Staubach 提交于 
      Hi.

I've been looking at a bugzilla which describes a problem where
a customer was advised to use either the "noac" or "actimeo=0"
mount options to solve a consistency problem that they were
seeing in the file attributes.  It turned out that this solution
did not work reliably for them because sometimes, the local
attribute cache was believed to be valid and not timed out.
(With an attribute cache timeout of 0, the cache should always
appear to be timed out.)

In looking at this situation, it appears to me that the problem
is that the attribute cache timeout code has an off-by-one
error in it.  It is assuming that the cache is valid in the
region, [read_cache_jiffies, read_cache_jiffies + attrtimeo].  The
cache should be considered valid only in the region,
[read_cache_jiffies, read_cache_jiffies + attrtimeo).  With this
change, the options, "noac" and "actimeo=0", work as originally
expected.

This problem was previously addressed by special casing the
attrtimeo == 0 case.  However, since the problem is only an off-
by-one error, the cleaner solution is address the off-by-one
error and thus, not require the special case.

    Thanx...

        ps
Signed-off-by: NPeter Staubach <staubach@redhat.com>
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      64672d55
    • T
      SUNRPC: Remove the last remnant of the BKL... · 88a9fe8c
      由 Trond Myklebust 提交于 
      Somehow, this escaped the previous purge. There should be no need to keep
any extra locks in the XDR callbacks.

The NFS client XDR code only writes into private objects, whereas all reads
of shared objects are confined to fields that do not change, such as
filehandles...

Ditto for lockd, the NFSv2/v3 client mount code, and rpcbind.

The nfsd XDR code may require the BKL, but since it does a synchronous RPC
call from a thread that already holds the lock, that issue is moot.
Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      88a9fe8c
  27. 14 11月, 2008 3 次提交
  29. 29 10月, 2008 2 次提交
  31. 17 10月, 2008 1 次提交
  33. 20 4月, 2008 1 次提交
  35. 15 3月, 2008 6 次提交
  37. 30 1月, 2008 3 次提交
  39. 20 7月, 2007 1 次提交
  41. 18 7月, 2007 1 次提交
  43. 11 7月, 2007 1 次提交