1. 13 12月, 2011 1 次提交
  2. 08 12月, 2011 1 次提交
  3. 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
  4. 26 11月, 2011 1 次提交
  5. 16 11月, 2011 2 次提交
  6. 09 11月, 2011 1 次提交
  7. 08 11月, 2011 27 次提交