1. 06 1月, 2012 5 次提交
    • J
      7a6ef8c7
    • C
      NFSD: Change name of extended attribute containing junction · 9b4146e8
      Chuck Lever 提交于
      As of fedfs-utils-0.8.0, user space stores all NFS junction
      information in a single extended attribute: "trusted.junction.nfs".
      
      Both FedFS and NFS basic junctions are stored in this one attribute,
      and the intention is that all future forms of NFS junction metadata
      will be stored in this attribute.  Other protocols may use a different
      extended attribute.
      
      Thus NFSD needs to look only for that one extended attribute.  The
      "trusted.junction.type" xattr is deprecated.  fedfs-utils-0.8.0 will
      continue to attach a "trusted.junction.type" xattr to junctions, but
      future fedfs-utils releases may no longer do that.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      9b4146e8
    • J
      svcrpc: don't revert to SVC_POOL_DEFAULT on nfsd shutdown · 9689dcce
      J. Bruce Fields 提交于
      This was unexpected behavior (at least for me)--why would you want
      configuration settings automatically lost on nfsd restart?
      
      In practice this won't affect distributions, which likely set everything
      on every startup.  But I'd expect the behavior to be less confusing to
      someone manually restarting nfsd for testing.
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      9689dcce
    • J
      svcrpc: fix double-free on shutdown of nfsd after changing pool mode · 61c8504c
      J. Bruce Fields 提交于
      The pool_to and to_pool fields of the global svc_pool_map are freed on
      shutdown, but are initialized in nfsd startup only in the
      SVC_POOL_PERCPU and SVC_POOL_PERNODE cases.
      
      They *are* initialized to zero on kernel startup.  So as long as you use
      only SVC_POOL_GLOBAL (the default), this will never be a problem.
      
      You're also OK if you only ever use SVC_POOL_PERCPU or SVC_POOL_PERNODE.
      
      However, the following sequence events leads to a double-free:
      
      	1. set SVC_POOL_PERCPU or SVC_POOL_PERNODE
      	2. start nfsd: both fields are initialized.
      	3. shutdown nfsd: both fields are freed.
      	4. set SVC_POOL_GLOBAL
      	5. start nfsd: the fields are left untouched.
      	6. shutdown nfsd: now we try to free them again.
      
      Step 4 is actually unnecessary, since (for some bizarre reason), nfsd
      automatically resets the pool mode to SVC_POOL_GLOBAL on shutdown.
      
      Cc: stable@kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      61c8504c
    • J
      nfsd4: be forgiving in the absence of the recovery directory · b8548894
      J. Bruce Fields 提交于
      If the recovery directory doesn't exist, then behavior after a reboot
      will be suboptimal.  But it's unnecessarily harsh to then prevent the
      nfsv4 server from working at all.  Instead just print a warning
      (already done in nfsd4_init_recdir()) and soldier on.
      Tested-by: NLior <lior@tonian.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      b8548894
  2. 03 1月, 2012 1 次提交
  3. 15 12月, 2011 1 次提交
  4. 14 12月, 2011 1 次提交
  5. 13 12月, 2011 1 次提交
  6. 08 12月, 2011 1 次提交
  7. 07 12月, 2011 7 次提交
    • S
      SUNRPC: create svc_xprt in proper network namespace · bd4620dd
      Stanislav Kinsbursky 提交于
      This patch makes svc_xprt inherit network namespace link from its socket.
      Signed-off-by: NStanislav Kinsbursky <skinsbursky@parallels.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      bd4620dd
    • J
      svcrpc: update outdated BKL comment · 94cf3179
      J. Bruce Fields 提交于
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      94cf3179
    • M
      nfsd41: allow non-reclaim open-by-fh's in 4.1 · 0cf99b91
      Mi Jinlong 提交于
      With NFSv4.0 it was safe to assume that open-by-filehandles were always
      reclaims.
      
      With NFSv4.1 there are non-reclaim open-by-filehandle operations, so we
      should ensure we're only insisting on reclaims in the
      OPEN_CLAIM_PREVIOUS case.
      Signed-off-by: NMi Jinlong <mijinlong@cn.fujitsu.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      0cf99b91
    • J
      svcrpc: avoid memory-corruption on pool shutdown · b4f36f88
      J. Bruce Fields 提交于
      Socket callbacks use svc_xprt_enqueue() to add an xprt to a
      pool->sp_sockets list.  In normal operation a server thread will later
      come along and take the xprt off that list.  On shutdown, after all the
      threads have exited, we instead manually walk the sv_tempsocks and
      sv_permsocks lists to find all the xprt's and delete them.
      
      So the sp_sockets lists don't really matter any more.  As a result,
      we've mostly just ignored them and hoped they would go away.
      
      Which has gotten us into trouble; witness for example ebc63e53
      "svcrpc: fix list-corrupting race on nfsd shutdown", the result of Ben
      Greear noticing that a still-running svc_xprt_enqueue() could re-add an
      xprt to an sp_sockets list just before it was deleted.  The fix was to
      remove it from the list at the end of svc_delete_xprt().  But that only
      made corruption less likely--I can see nothing that prevents a
      svc_xprt_enqueue() from adding another xprt to the list at the same
      moment that we're removing this xprt from the list.  In fact, despite
      the earlier xpo_detach(), I don't even see what guarantees that
      svc_xprt_enqueue() couldn't still be running on this xprt.
      
      So, instead, note that svc_xprt_enqueue() essentially does:
      	lock sp_lock
      		if XPT_BUSY unset
      			add to sp_sockets
      	unlock sp_lock
      
      So, if we do:
      
      	set XPT_BUSY on every xprt.
      	Empty every sp_sockets list, under the sp_socks locks.
      
      Then we're left knowing that the sp_sockets lists are all empty and will
      stay that way, since any svc_xprt_enqueue() will check XPT_BUSY under
      the sp_lock and see it set.
      
      And *then* we can continue deleting the xprt's.
      
      (Thanks to Jeff Layton for being correctly suspicious of this code....)
      
      Cc: Ben Greear <greearb@candelatech.com>
      Cc: Jeff Layton <jlayton@redhat.com>
      Cc: stable@kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      b4f36f88
    • J
      svcrpc: destroy server sockets all at once · 2fefb8a0
      J. Bruce Fields 提交于
      There's no reason I can see that we need to call sv_shutdown between
      closing the two lists of sockets.
      
      Cc: stable@kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      2fefb8a0
    • J
      svcrpc: make svc_delete_xprt static · 7710ec36
      J. Bruce Fields 提交于
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      7710ec36
    • S
      nfsd: Fix oops when parsing a 0 length export · b2ea70af
      Sasha Levin 提交于
      expkey_parse() oopses when handling a 0 length export. This is easily
      triggerable from usermode by writing 0 bytes into
      '/proc/[proc id]/net/rpc/nfsd.fh/channel'.
      
      Below is the log:
      
      [ 1402.286893] BUG: unable to handle kernel paging request at ffff880077c49fff
      [ 1402.287632] IP: [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
      [ 1402.287632] PGD 2206063 PUD 1fdfd067 PMD 1ffbc067 PTE 8000000077c49160
      [ 1402.287632] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
      [ 1402.287632] CPU 1
      [ 1402.287632] Pid: 20198, comm: trinity Not tainted 3.2.0-rc2-sasha-00058-gc65cd37 #6
      [ 1402.287632] RIP: 0010:[<ffffffff812b4b99>]  [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
      [ 1402.287632] RSP: 0018:ffff880077f0fd68  EFLAGS: 00010292
      [ 1402.287632] RAX: ffff880077c49fff RBX: 00000000ffffffea RCX: 0000000001043400
      [ 1402.287632] RDX: 0000000000000000 RSI: ffff880077c4a000 RDI: ffffffff82283de0
      [ 1402.287632] RBP: ffff880077f0fe18 R08: 0000000000000001 R09: ffff880000000000
      [ 1402.287632] R10: 0000000000000000 R11: 0000000000000001 R12: ffff880077c4a000
      [ 1402.287632] R13: ffffffff82283de0 R14: 0000000001043400 R15: ffffffff82283de0
      [ 1402.287632] FS:  00007f25fec3f700(0000) GS:ffff88007d400000(0000) knlGS:0000000000000000
      [ 1402.287632] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [ 1402.287632] CR2: ffff880077c49fff CR3: 0000000077e1d000 CR4: 00000000000406e0
      [ 1402.287632] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      [ 1402.287632] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      [ 1402.287632] Process trinity (pid: 20198, threadinfo ffff880077f0e000, task ffff880077db17b0)
      [ 1402.287632] Stack:
      [ 1402.287632]  ffff880077db17b0 ffff880077c4a000 ffff880077f0fdb8 ffffffff810b411e
      [ 1402.287632]  ffff880000000000 ffff880077db17b0 ffff880077c4a000 ffffffff82283de0
      [ 1402.287632]  0000000001043400 ffffffff82283de0 ffff880077f0fde8 ffffffff81111f63
      [ 1402.287632] Call Trace:
      [ 1402.287632]  [<ffffffff810b411e>] ? lock_release+0x1af/0x1bc
      [ 1402.287632]  [<ffffffff81111f63>] ? might_fault+0x97/0x9e
      [ 1402.287632]  [<ffffffff81111f1a>] ? might_fault+0x4e/0x9e
      [ 1402.287632]  [<ffffffff81a8bcf2>] cache_do_downcall+0x3e/0x4f
      [ 1402.287632]  [<ffffffff81a8c950>] cache_write.clone.16+0xbb/0x130
      [ 1402.287632]  [<ffffffff81a8c9df>] ? cache_write_pipefs+0x1a/0x1a
      [ 1402.287632]  [<ffffffff81a8c9f8>] cache_write_procfs+0x19/0x1b
      [ 1402.287632]  [<ffffffff8118dc54>] proc_reg_write+0x8e/0xad
      [ 1402.287632]  [<ffffffff8113fe81>] vfs_write+0xaa/0xfd
      [ 1402.287632]  [<ffffffff8114142d>] ? fget_light+0x35/0x9e
      [ 1402.287632]  [<ffffffff8113ff8b>] sys_write+0x48/0x6f
      [ 1402.287632]  [<ffffffff81bbdb92>] system_call_fastpath+0x16/0x1b
      [ 1402.287632] Code: c0 c9 c3 55 48 63 d2 48 89 e5 48 8d 44 32 ff 41 57 41 56 41 55 41 54 53 bb ea ff ff ff 48 81 ec 88 00 00 00 48 89 b5 58 ff ff ff
      [ 1402.287632]  38 0a 0f 85 89 02 00 00 c6 00 00 48 8b 3d 44 4a e5 01 48 85
      [ 1402.287632] RIP  [<ffffffff812b4b99>] expkey_parse+0x28/0x2e1
      [ 1402.287632]  RSP <ffff880077f0fd68>
      [ 1402.287632] CR2: ffff880077c49fff
      [ 1402.287632] ---[ end trace 368ef53ff773a5e3 ]---
      
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: linux-nfs@vger.kernel.org
      Cc: stable@kernel.org
      Signed-off-by: NSasha Levin <levinsasha928@gmail.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      b2ea70af
  8. 26 11月, 2011 1 次提交
  9. 16 11月, 2011 2 次提交
  10. 09 11月, 2011 1 次提交
  11. 08 11月, 2011 19 次提交