Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 10 12月, 2014 1 次提交
  3. 02 12月, 2014 1 次提交
  5. 25 11月, 2014 2 次提交
  7. 29 10月, 2014 1 次提交
  9. 18 8月, 2014 1 次提交
  11. 23 6月, 2014 1 次提交
  13. 04 1月, 2014 1 次提交
  15. 14 11月, 2013 1 次提交
  17. 04 7月, 2013 1 次提交
  19. 17 2月, 2013 1 次提交
  21. 24 1月, 2013 1 次提交
  23. 18 12月, 2012 1 次提交
  25. 11 12月, 2012 1 次提交
  27. 08 11月, 2012 1 次提交
  29. 05 11月, 2012 3 次提交
  31. 01 6月, 2012 3 次提交
  33. 16 5月, 2012 1 次提交
  35. 15 2月, 2012 3 次提交
  37. 01 2月, 2012 5 次提交
  39. 06 1月, 2012 2 次提交
    • 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
  41. 12 12月, 2011 1 次提交
  43. 07 12月, 2011 3 次提交
    • J
      svcrpc: update outdated BKL comment · 94cf3179
      由 J. Bruce Fields 提交于 
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      94cf3179
    • 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
  45. 01 11月, 2011 1 次提交
  47. 25 10月, 2011 3 次提交