05 Jul, 2017

2 commits

  • refcount_t type and corresponding API should be
    used instead of atomic_t when the variable is used as
    a reference counter. This allows to avoid accidental
    refcounter overflows that might lead to use-after-free
    situations.

    Signed-off-by: Elena Reshetova
    Signed-off-by: Hans Liljestrand
    Signed-off-by: Kees Cook
    Signed-off-by: David Windsor
    Signed-off-by: David S. Miller

    Reshetova, Elena
     
  • refcount_t type and corresponding API should be
    used instead of atomic_t when the variable is used as
    a reference counter. This allows to avoid accidental
    refcounter overflows that might lead to use-after-free
    situations.

    Signed-off-by: Elena Reshetova
    Signed-off-by: Hans Liljestrand
    Signed-off-by: Kees Cook
    Signed-off-by: David Windsor
    Signed-off-by: David S. Miller

    Reshetova, Elena
     

28 Feb, 2017

1 commit

  • Now that %z is standartised in C99 there is no reason to support %Z.
    Unlike %L it doesn't even make format strings smaller.

    Use BUILD_BUG_ON in a couple ATM drivers.

    In case anyone didn't notice lib/vsprintf.o is about half of SLUB which
    is in my opinion is quite an achievement. Hopefully this patch inspires
    someone else to trim vsprintf.c more.

    Link: http://lkml.kernel.org/r/20170103230126.GA30170@avx2
    Signed-off-by: Alexey Dobriyan
    Cc: Andy Shevchenko
    Cc: Rasmus Villemoes
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Alexey Dobriyan
     

25 Dec, 2016

1 commit


10 Dec, 2016

1 commit

  • There are two problems with refcounting of auth_gss messages.

    First, the reference on the pipe->pipe list (taken by a call
    to rpc_queue_upcall()) is not counted. It seems to be
    assumed that a message in pipe->pipe will always also be in
    pipe->in_downcall, where it is correctly reference counted.

    However there is no guaranty of this. I have a report of a
    NULL dereferences in rpc_pipe_read() which suggests a msg
    that has been freed is still on the pipe->pipe list.

    One way I imagine this might happen is:
    - message is queued for uid=U and auth->service=S1
    - rpc.gssd reads this message and starts processing.
    This removes the message from pipe->pipe
    - message is queued for uid=U and auth->service=S2
    - rpc.gssd replies to the first message. gss_pipe_downcall()
    calls __gss_find_upcall(pipe, U, NULL) and it finds the
    *second* message, as new messages are placed at the head
    of ->in_downcall, and the service type is not checked.
    - This second message is removed from ->in_downcall and freed
    by gss_release_msg() (even though it is still on pipe->pipe)
    - rpc.gssd tries to read another message, and dereferences a pointer
    to this message that has just been freed.

    I fix this by incrementing the reference count before calling
    rpc_queue_upcall(), and decrementing it if that fails, or normally in
    gss_pipe_destroy_msg().

    It seems strange that the reply doesn't target the message more
    precisely, but I don't know all the details. In any case, I think the
    reference counting irregularity became a measureable bug when the
    extra arg was added to __gss_find_upcall(), hence the Fixes: line
    below.

    The second problem is that if rpc_queue_upcall() fails, the new
    message is not freed. gss_alloc_msg() set the ->count to 1,
    gss_add_msg() increments this to 2, gss_unhash_msg() decrements to 1,
    then the pointer is discarded so the memory never gets freed.

    Fixes: 9130b8dbc6ac ("SUNRPC: allow for upcalls for same uid but different gss service")
    Cc: stable@vger.kernel.org
    Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1011250
    Signed-off-by: NeilBrown
    Signed-off-by: Trond Myklebust

    NeilBrown
     

27 Oct, 2016

1 commit

  • As of ac4e97abce9b "scatterlist: sg_set_buf() argument must be in linear
    mapping", sg_set_buf hits a BUG when make_checksum_v2->xdr_process_buf,
    among other callers, passes it memory on the stack.

    We only need a scatterlist to pass this to the crypto code, and it seems
    like overkill to require kmalloc'd memory just to encrypt a few bytes,
    but for now this seems the best fix.

    Many of these callers are in the NFS write paths, so we allocate with
    GFP_NOFS. It might be possible to do without allocations here entirely,
    but that would probably be a bigger project.

    Cc: Rusty Russell
    Signed-off-by: J. Bruce Fields

    J. Bruce Fields
     

01 Oct, 2016

1 commit


05 Aug, 2016

1 commit

  • It's possible to have simultaneous upcalls for the same UIDs but
    different GSS service. In that case, we need to allow for the
    upcall to gssd to proceed so that not the same context is used
    by two different GSS services. Some servers lock the use of context
    to the GSS service.

    Signed-off-by: Olga Kornievskaia
    Cc: stable@vger.kernel.org # v3.9+
    Signed-off-by: Trond Myklebust

    Olga Kornievskaia
     

25 Jul, 2016

1 commit


20 Jul, 2016

1 commit

  • A generic_cred can be used to look up a unx_cred or a gss_cred, so it's
    not really safe to use the the generic_cred->acred->ac_flags to store
    the NO_CRKEY_TIMEOUT flag. A lookup for a unx_cred triggered while the
    KEY_EXPIRE_SOON flag is already set will cause both NO_CRKEY_TIMEOUT and
    KEY_EXPIRE_SOON to be set in the ac_flags, leaving the user associated
    with the auth_cred to be in a state where they're perpetually doing 4K
    NFS_FILE_SYNC writes.

    This can be reproduced as follows:

    1. Mount two NFS filesystems, one with sec=krb5 and one with sec=sys.
    They do not need to be the same export, nor do they even need to be from
    the same NFS server. Also, v3 is fine.
    $ sudo mount -o v3,sec=krb5 server1:/export /mnt/krb5
    $ sudo mount -o v3,sec=sys server2:/export /mnt/sys

    2. As the normal user, before accessing the kerberized mount, kinit with
    a short lifetime (but not so short that renewing the ticket would leave
    you within the 4-minute window again by the time the original ticket
    expires), e.g.
    $ kinit -l 10m -r 60m

    3. Do some I/O to the kerberized mount and verify that the writes are
    wsize, UNSTABLE:
    $ dd if=/dev/zero of=/mnt/krb5/file bs=1M count=1

    4. Wait until you're within 4 minutes of key expiry, then do some more
    I/O to the kerberized mount to ensure that RPC_CRED_KEY_EXPIRE_SOON gets
    set. Verify that the writes are 4K, FILE_SYNC:
    $ dd if=/dev/zero of=/mnt/krb5/file bs=1M count=1

    5. Now do some I/O to the sec=sys mount. This will cause
    RPC_CRED_NO_CRKEY_TIMEOUT to be set:
    $ dd if=/dev/zero of=/mnt/sys/file bs=1M count=1

    6. Writes for that user will now be permanently 4K, FILE_SYNC for that
    user, regardless of which mount is being written to, until you reboot
    the client. Renewing the kerberos ticket (assuming it hasn't already
    expired) will have no effect. Grabbing a new kerberos ticket at this
    point will have no effect either.

    Move the flag to the auth->au_flags field (which is currently unused)
    and rename it slightly to reflect that it's no longer associated with
    the auth_cred->ac_flags. Add the rpc_auth to the arg list of
    rpcauth_cred_key_to_expire and check the au_flags there too. Finally,
    add the inode to the arg list of nfs_ctx_key_to_expire so we can
    determine the rpc_auth to pass to rpcauth_cred_key_to_expire.

    Signed-off-by: Scott Mayhew
    Signed-off-by: Trond Myklebust

    Scott Mayhew
     

12 Jul, 2016

1 commit

  • Direct data placement is not allowed when using flavors that
    guarantee integrity or privacy. When such security flavors are in
    effect, don't allow the use of Read and Write chunks for moving
    individual data items. All messages larger than the inline threshold
    are sent via Long Call or Long Reply.

    On my systems (CX-3 Pro on FDR), for small I/O operations, the use
    of Long messages adds only around 5 usecs of latency in each
    direction.

    Note that when integrity or encryption is used, the host CPU touches
    every byte in these messages. Even if it could be used, data
    movement offload doesn't buy much in this case.

    Signed-off-by: Chuck Lever
    Tested-by: Steve Wise
    Signed-off-by: Anna Schumaker

    Chuck Lever
     

09 May, 2016

1 commit

  • We need to be able to call the generic_cred creator from different
    contexts. Add a gfp_t parm to the crcreate operation and to
    rpcauth_lookup_credcache. For now, we just push the gfp_t parms up
    one level to the *_lookup_cred functions.

    Signed-off-by: Jeff Layton
    Signed-off-by: Anna Schumaker

    Jeff Layton
     

05 Apr, 2016

1 commit

  • PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} macros were introduced *long* time
    ago with promise that one day it will be possible to implement page
    cache with bigger chunks than PAGE_SIZE.

    This promise never materialized. And unlikely will.

    We have many places where PAGE_CACHE_SIZE assumed to be equal to
    PAGE_SIZE. And it's constant source of confusion on whether
    PAGE_CACHE_* or PAGE_* constant should be used in a particular case,
    especially on the border between fs and mm.

    Global switching to PAGE_CACHE_SIZE != PAGE_SIZE would cause to much
    breakage to be doable.

    Let's stop pretending that pages in page cache are special. They are
    not.

    The changes are pretty straight-forward:

    - << (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> ;

    - >> (PAGE_CACHE_SHIFT - PAGE_SHIFT) -> ;

    - PAGE_CACHE_{SIZE,SHIFT,MASK,ALIGN} -> PAGE_{SIZE,SHIFT,MASK,ALIGN};

    - page_cache_get() -> get_page();

    - page_cache_release() -> put_page();

    This patch contains automated changes generated with coccinelle using
    script below. For some reason, coccinelle doesn't patch header files.
    I've called spatch for them manually.

    The only adjustment after coccinelle is revert of changes to
    PAGE_CAHCE_ALIGN definition: we are going to drop it later.

    There are few places in the code where coccinelle didn't reach. I'll
    fix them manually in a separate patch. Comments and documentation also
    will be addressed with the separate patch.

    virtual patch

    @@
    expression E;
    @@
    - E << (PAGE_CACHE_SHIFT - PAGE_SHIFT)
    + E

    @@
    expression E;
    @@
    - E >> (PAGE_CACHE_SHIFT - PAGE_SHIFT)
    + E

    @@
    @@
    - PAGE_CACHE_SHIFT
    + PAGE_SHIFT

    @@
    @@
    - PAGE_CACHE_SIZE
    + PAGE_SIZE

    @@
    @@
    - PAGE_CACHE_MASK
    + PAGE_MASK

    @@
    expression E;
    @@
    - PAGE_CACHE_ALIGN(E)
    + PAGE_ALIGN(E)

    @@
    expression E;
    @@
    - page_cache_get(E)
    + get_page(E)

    @@
    expression E;
    @@
    - page_cache_release(E)
    + put_page(E)

    Signed-off-by: Kirill A. Shutemov
    Acked-by: Michal Hocko
    Signed-off-by: Linus Torvalds

    Kirill A. Shutemov
     

23 Feb, 2016

1 commit

  • * multipath:
    NFS add callback_ops to nfs4_proc_bind_conn_to_session_callback
    pnfs/NFSv4.1: Add multipath capabilities to pNFS flexfiles servers over NFSv3
    SUNRPC: Allow addition of new transports to a struct rpc_clnt
    NFSv4.1: nfs4_proc_bind_conn_to_session must iterate over all connections
    SUNRPC: Make NFS swap work with multipath
    SUNRPC: Add a helper to apply a function to all the rpc_clnt's transports
    SUNRPC: Allow caller to specify the transport to use
    SUNRPC: Use the multipath iterator to assign a transport to each task
    SUNRPC: Make rpc_clnt store the multipath iterators
    SUNRPC: Add a structure to track multiple transports
    SUNRPC: Make freeing of struct xprt rcu-safe
    SUNRPC: Uninline xprt_get(); It isn't performance critical.
    SUNRPC: Reorder rpc_task to put waitqueue related info in same cachelines
    SUNRPC: Remove unused function rpc_task_reset_client

    Trond Myklebust
     

18 Feb, 2016

1 commit

  • On Mon, 15 Feb 2016, Trond Myklebust wrote:

    > Hi Scott,
    >
    > On Mon, Feb 15, 2016 at 2:28 PM, Scott Mayhew wrote:
    > > md5 is disabled in fips mode, and attempting to import a gss context
    > > using md5 while in fips mode will result in crypto_alg_mod_lookup()
    > > returning -ENOENT, which will make its way back up to
    > > gss_pipe_downcall(), where the BUG() is triggered. Handling the -ENOENT
    > > allows for a more graceful failure.
    > >
    > > Signed-off-by: Scott Mayhew
    > > ---
    > > net/sunrpc/auth_gss/auth_gss.c | 3 +++
    > > 1 file changed, 3 insertions(+)
    > >
    > > diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c
    > > index 799e65b..c30fc3b 100644
    > > --- a/net/sunrpc/auth_gss/auth_gss.c
    > > +++ b/net/sunrpc/auth_gss/auth_gss.c
    > > @@ -737,6 +737,9 @@ gss_pipe_downcall(struct file *filp, const char __user *src, size_t mlen)
    > > case -ENOSYS:
    > > gss_msg->msg.errno = -EAGAIN;
    > > break;
    > > + case -ENOENT:
    > > + gss_msg->msg.errno = -EPROTONOSUPPORT;
    > > + break;
    > > default:
    > > printk(KERN_CRIT "%s: bad return from "
    > > "gss_fill_context: %zd\n", __func__, err);
    > > --
    > > 2.4.3
    > >
    >
    > Well debugged, but I unfortunately do have to ask if this patch is
    > sufficient? In addition to -ENOENT, and -ENOMEM, it looks to me as if
    > crypto_alg_mod_lookup() can also fail with -EINTR, -ETIMEDOUT, and
    > -EAGAIN. Don't we also want to handle those?

    You're right, I was focusing on the panic that I could easily reproduce.
    I'm still not sure how I could trigger those other conditions.

    >
    > In fact, peering into the rats nest that is
    > gss_import_sec_context_kerberos(), it looks as if that is just a tiny
    > subset of all the errors that we might run into. Perhaps the right
    > thing to do here is to get rid of the BUG() (but keep the above
    > printk) and just return a generic error?

    That sounds fine to me -- updated patch attached.

    -Scott

    >From d54c6b64a107a90a38cab97577de05f9a4625052 Mon Sep 17 00:00:00 2001
    From: Scott Mayhew
    Date: Mon, 15 Feb 2016 15:12:19 -0500
    Subject: [PATCH] auth_gss: remove the BUG() from gss_pipe_downcall()

    Instead return a generic error via gss_msg->msg.errno. None of the
    errors returned by gss_fill_context() should necessarily trigger a
    kernel panic.

    Signed-off-by: Scott Mayhew
    Signed-off-by: Trond Myklebust

    Scott Mayhew
     

06 Feb, 2016

1 commit


24 Oct, 2015

1 commit

  • The gss_key_timeout() function causes a harmless warning in some
    configurations, e.g. ARM imx_v6_v7_defconfig with gcc-5.2, if the
    compiler cannot figure out the state of the 'expire' variable across
    an rcu_read_unlock():

    net/sunrpc/auth_gss/auth_gss.c: In function 'gss_key_timeout':
    net/sunrpc/auth_gss/auth_gss.c:1422:211: warning: 'expire' may be used uninitialized in this function [-Wmaybe-uninitialized]

    To avoid this warning without adding a bogus initialization, this
    rewrites the function so the comparison is done inside of the
    critical section. As a side-effect, it also becomes slightly
    easier to understand because the implementation now more closely
    resembles the comment above it.

    Signed-off-by: Arnd Bergmann
    Fixes: c5e6aecd034e7 ("sunrpc: fix RCU handling of gc_ctx field")
    Signed-off-by: J. Bruce Fields

    Arnd Bergmann
     

25 Nov, 2014

1 commit


14 Nov, 2014

1 commit

  • Bruce reported that he was seeing the following BUG pop:

    BUG: sleeping function called from invalid context at mm/slab.c:2846
    in_atomic(): 0, irqs_disabled(): 0, pid: 4539, name: mount.nfs
    2 locks held by mount.nfs/4539:
    #0: (nfs_clid_init_mutex){+.+.+.}, at: [] nfs4_discover_server_trunking+0x4a/0x2f0 [nfsv4]
    #1: (rcu_read_lock){......}, at: [] gss_stringify_acceptor+0x5/0xb0 [auth_rpcgss]
    Preemption disabled at:[] printk+0x4d/0x4f

    CPU: 3 PID: 4539 Comm: mount.nfs Not tainted 3.18.0-rc1-00013-g5b095e9 #3393
    Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
    ffff880021499390 ffff8800381476a8 ffffffff81a534cf 0000000000000001
    0000000000000000 ffff8800381476c8 ffffffff81097854 00000000000000d0
    0000000000000018 ffff880038147718 ffffffff8118e4f3 0000000020479f00
    Call Trace:
    [] dump_stack+0x4f/0x7c
    [] __might_sleep+0x114/0x180
    [] __kmalloc+0x1a3/0x280
    [] gss_stringify_acceptor+0x58/0xb0 [auth_rpcgss]
    [] ? gss_stringify_acceptor+0x5/0xb0 [auth_rpcgss]
    [] rpcauth_stringify_acceptor+0x18/0x30 [sunrpc]
    [] nfs4_proc_setclientid+0x199/0x380 [nfsv4]
    [] ? nfs4_proc_setclientid+0x200/0x380 [nfsv4]
    [] nfs40_discover_server_trunking+0xda/0x150 [nfsv4]
    [] ? nfs40_discover_server_trunking+0x5/0x150 [nfsv4]
    [] nfs4_discover_server_trunking+0x7f/0x2f0 [nfsv4]
    [] nfs4_init_client+0x104/0x2f0 [nfsv4]
    [] nfs_get_client+0x314/0x3f0 [nfs]
    [] ? nfs_get_client+0xe0/0x3f0 [nfs]
    [] nfs4_set_client+0x8a/0x110 [nfsv4]
    [] ? __rpc_init_priority_wait_queue+0xa8/0xf0 [sunrpc]
    [] nfs4_create_server+0x12f/0x390 [nfsv4]
    [] nfs4_remote_mount+0x32/0x60 [nfsv4]
    [] mount_fs+0x39/0x1b0
    [] ? __alloc_percpu+0x15/0x20
    [] vfs_kern_mount+0x6b/0x150
    [] nfs_do_root_mount+0x86/0xc0 [nfsv4]
    [] nfs4_try_mount+0x44/0xc0 [nfsv4]
    [] ? get_nfs_version+0x27/0x90 [nfs]
    [] nfs_fs_mount+0x47d/0xd60 [nfs]
    [] ? mutex_unlock+0xe/0x10
    [] ? nfs_remount+0x430/0x430 [nfs]
    [] ? nfs_clone_super+0x140/0x140 [nfs]
    [] mount_fs+0x39/0x1b0
    [] ? __alloc_percpu+0x15/0x20
    [] vfs_kern_mount+0x6b/0x150
    [] do_mount+0x210/0xbe0
    [] ? copy_mount_options+0x3a/0x160
    [] SyS_mount+0x6f/0xb0
    [] system_call_fastpath+0x12/0x17

    Sleeping under the rcu_read_lock is bad. This patch fixes it by dropping
    the rcu_read_lock before doing the allocation and then reacquiring it
    and redoing the dereference before doing the copy. If we find that the
    string has somehow grown in the meantime, we'll reallocate and try again.

    Cc: # v3.17+
    Reported-by: "J. Bruce Fields"
    Signed-off-by: Jeff Layton
    Signed-off-by: Trond Myklebust

    Jeff Layton
     

04 Aug, 2014

1 commit

  • The handling of the gc_ctx pointer only seems to be partially RCU-safe.
    The assignment and freeing are done using RCU, but many places in the
    code seem to dereference that pointer without proper RCU safeguards.

    Fix them to use rcu_dereference and to rcu_read_lock/unlock, and to
    properly handle the case where the pointer is NULL.

    Cc: Arnd Bergmann
    Cc: Paul McKenney
    Signed-off-by: Jeff Layton
    Signed-off-by: Trond Myklebust

    Jeff Layton
     

13 Jul, 2014

2 commits


18 Apr, 2014

1 commit

  • Mostly scripted conversion of the smp_mb__* barriers.

    Signed-off-by: Peter Zijlstra
    Acked-by: Paul E. McKenney
    Link: http://lkml.kernel.org/n/tip-55dhyhocezdw1dg7u19hmh1u@git.kernel.org
    Cc: Linus Torvalds
    Cc: linux-arch@vger.kernel.org
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

17 Feb, 2014

2 commits

  • In gss_alloc_msg(), if the call to gss_encode_v1_msg() fails, we
    want to release the reference to the pipe_version that was obtained
    earlier in the function.

    Fixes: 9d3a2260f0f4b (SUNRPC: Fix buffer overflow checking in...)
    Signed-off-by: Trond Myklebust

    Trond Myklebust
     
  • Fix a race in which the RPC client is shutting down while the
    gss daemon is processing a downcall. If the RPC client manages to
    shut down before the gss daemon is done, then the struct gss_auth
    used in gss_release_msg() may have already been freed.

    Link: http://lkml.kernel.org/r/1392494917.71728.YahooMailNeo@web140002.mail.bf1.yahoo.com
    Reported-by: John
    Reported-by: Borislav Petkov
    Cc: stable@vger.kernel.org # 3.12+
    Signed-off-by: Trond Myklebust

    Trond Myklebust
     

11 Feb, 2014

1 commit

  • An infinite loop is caused when nfs4_establish_lease() fails
    with -EACCES. This causes nfs4_handle_reclaim_lease_error()
    to sleep a bit and resets the NFS4CLNT_LEASE_EXPIRED bit.
    This in turn causes nfs4_state_manager() to try and
    reestablished the lease, again, again, again...

    The problem is a valid RPCSEC_GSS client is being created when
    rpc.gssd is not running.

    Link: http://lkml.kernel.org/r/1392066375-16502-1-git-send-email-steved@redhat.com
    Fixes: 0ea9de0ea6a4 (sunrpc: turn warn_gssd() log message into a dprintk())
    Reported-by: Steve Dickson
    Signed-off-by: Trond Myklebust

    Trond Myklebust
     

28 Jan, 2014

1 commit

  • The original printk() made sense when the GSSAPI codepaths were called
    only when sec=krb5* was explicitly requested. Now however, in many cases
    the nfs client will try to acquire GSSAPI credentials by default, even
    when it's not requested.

    Since we don't have a great mechanism to distinguish between the two
    cases, just turn the pr_warn into a dprintk instead. With this change we
    can also get rid of the ratelimiting.

    We do need to keep the EXPORT_SYMBOL(gssd_running) in place since
    auth_gss.ko needs it and sunrpc.ko provides it. We can however,
    eliminate the gssd_running call in the nfs code since that's a bit of a
    layering violation.

    Signed-off-by: Jeff Layton
    Signed-off-by: Trond Myklebust

    Jeff Layton
     

07 Dec, 2013

1 commit

  • Now that we have a more reliable method to tell if gssd is running, we
    can replace the sn->gssd_running flag with a function that will query to
    see if it's up and running.

    There's also no need to attempt an upcall that we know will fail, so
    just return -EACCES if gssd isn't running. Finally, fix the warn_gss()
    message not to claim that that the upcall timed out since we don't
    necesarily perform one now when gssd isn't running, and remove the
    extraneous newline from the message.

    Signed-off-by: Jeff Layton
    Signed-off-by: Trond Myklebust

    Jeff Layton
     

27 Nov, 2013

1 commit


29 Oct, 2013

2 commits


18 Sep, 2013

1 commit

  • This fixes a regression since eb6dc19d8e72ce3a957af5511d20c0db0a8bd007
    "RPCSEC_GSS: Share all credential caches on a per-transport basis" which
    could cause an occasional oops in the nfsd code (see below).

    The problem was that an auth was left referencing a client that had been
    freed. To avoid this we need to ensure that auths are shared only
    between descendants of a common client; the fact that a clone of an
    rpc_client takes a reference on its parent then ensures that the parent
    client will last as long as the auth.

    Also add a comment explaining what I think was the intention of this
    code.

    general protection fault: 0000 [#1] PREEMPT SMP
    Modules linked in: rpcsec_gss_krb5 nfsd auth_rpcgss oid_registry nfs_acl lockd sunrpc
    CPU: 3 PID: 4071 Comm: kworker/u8:2 Not tainted 3.11.0-rc2-00182-g025145f #1665
    Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
    Workqueue: nfsd4_callbacks nfsd4_do_callback_rpc [nfsd]
    task: ffff88003e206080 ti: ffff88003c384000 task.ti: ffff88003c384000
    RIP: 0010:[] [] rpc_net_ns+0x53/0x70 [sunrpc]
    RSP: 0000:ffff88003c385ab8 EFLAGS: 00010246
    RAX: 6b6b6b6b6b6b6b6b RBX: ffff88003af9a800 RCX: 0000000000000002
    RDX: ffffffffa00001a5 RSI: 0000000000000001 RDI: ffffffff81e284e0
    RBP: ffff88003c385ad8 R08: 0000000000000001 R09: 0000000000000000
    R10: 0000000000000000 R11: 0000000000000015 R12: ffff88003c990840
    R13: ffff88003c990878 R14: ffff88003c385ba8 R15: ffff88003e206080
    FS: 0000000000000000(0000) GS:ffff88003fd80000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
    CR2: 00007fcdf737e000 CR3: 000000003ad2b000 CR4: 00000000000006e0
    Stack:
    ffffffffa00001a5 0000000000000006 0000000000000006 ffff88003af9a800
    ffff88003c385b08 ffffffffa00d52a4 ffff88003c385ba8 ffff88003c751bd8
    ffff88003c751bc0 ffff88003e113600 ffff88003c385b18 ffffffffa00d530c
    Call Trace:
    [] ? rpc_net_ns+0x5/0x70 [sunrpc]
    [] __gss_pipe_release+0x54/0x90 [auth_rpcgss]
    [] gss_pipe_free+0x2c/0x30 [auth_rpcgss]
    [] gss_destroy+0x9b/0xf0 [auth_rpcgss]
    [] rpcauth_release+0x23/0x30 [sunrpc]
    [] rpc_release_client+0x51/0xb0 [sunrpc]
    [] rpc_shutdown_client+0xe5/0x170 [sunrpc]
    [] ? cpuacct_charge+0xa4/0xb0
    [] ? cpuacct_charge+0x5/0xb0
    [] nfsd4_process_cb_update.isra.17+0x2f/0x210 [nfsd]
    [] ? _raw_spin_unlock_irq+0x30/0x60
    [] ? _raw_spin_unlock_irq+0x3b/0x60
    [] ? process_one_work+0x15b/0x510
    [] nfsd4_do_callback_rpc+0x8d/0xa0 [nfsd]
    [] process_one_work+0x1ce/0x510
    [] ? process_one_work+0x15b/0x510
    [] worker_thread+0x11b/0x370
    [] ? manage_workers.isra.24+0x2b0/0x2b0
    [] kthread+0xdb/0xe0
    [] ? _raw_spin_unlock_irq+0x30/0x60
    [] ? __init_kthread_worker+0x70/0x70
    [] ret_from_fork+0x7c/0xb0
    [] ? __init_kthread_worker+0x70/0x70
    Code: a5 01 00 a0 31 d2 31 f6 48 c7 c7 e0 84 e2 81 e8 f4 91 0a e1 48 8b 43 60 48 c7 c2 a5 01 00 a0 be 01 00 00 00 48 c7 c7 e0 84 e2 81 8b 98 10 07 00 00 e8 91 8f 0a e1 e8
    +3c 4e 07 e1 48 83 c4 18
    RIP [] rpc_net_ns+0x53/0x70 [sunrpc]
    RSP

    Signed-off-by: J. Bruce Fields
    Signed-off-by: Trond Myklebust

    J. Bruce Fields
     

12 Sep, 2013

1 commit


04 Sep, 2013

2 commits

  • Most of the time an error from the credops crvalidate function means the
    server has sent us a garbage verifier. The gss_validate function is the
    exception where there is an -EACCES case if the user GSS_context on the client
    has expired.

    Signed-off-by: Andy Adamson
    Signed-off-by: Trond Myklebust

    Andy Adamson
     
  • This patch provides the RPC layer helper functions to allow NFS to manage
    data in the face of expired credentials - such as avoiding buffered WRITEs
    and COMMITs when the gss context will expire before the WRITEs are flushed
    and COMMITs are sent.

    These helper functions enable checking the expiration of an underlying
    credential key for a generic rpc credential, e.g. the gss_cred gss context
    gc_expiry which for Kerberos is set to the remaining TGT lifetime.

    A new rpc_authops key_timeout is only defined for the generic auth.
    A new rpc_credops crkey_to_expire is only defined for the generic cred.
    A new rpc_credops crkey_timeout is only defined for the gss cred.

    Set a credential key expiry watermark, RPC_KEY_EXPIRE_TIMEO set to 240 seconds
    as a default and can be set via a module parameter as we need to ensure there
    is time for any dirty data to be flushed.

    If key_timeout is called on a credential with an underlying credential key that
    will expire within watermark seconds, we set the RPC_CRED_KEY_EXPIRE_SOON
    flag in the generic_cred acred so that the NFS layer can clean up prior to
    key expiration.

    Checking a generic credential's underlying credential involves a cred lookup.
    To avoid this lookup in the normal case when the underlying credential has
    a key that is valid (before the watermark), a notify flag is set in
    the generic credential the first time the key_timeout is called. The
    generic credential then stops checking the underlying credential key expiry, and
    the underlying credential (gss_cred) match routine then checks the key
    expiration upon each normal use and sets a flag in the associated generic
    credential only when the key expiration is within the watermark.
    This in turn signals the generic credential key_timeout to perform the extra
    credential lookup thereafter.

    Signed-off-by: Andy Adamson
    Signed-off-by: Trond Myklebust

    Andy Adamson
     

03 Sep, 2013

1 commit


01 Sep, 2013

2 commits


30 Aug, 2013

2 commits