Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 160
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 24 1月, 2012 1 次提交
  3. 13 1月, 2012 1 次提交
  5. 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
  7. 05 1月, 2012 2 次提交
  9. 04 1月, 2012 2 次提交
  11. 12 12月, 2011 1 次提交
  13. 08 12月, 2011 1 次提交
  15. 07 12月, 2011 6 次提交
    • 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
    • 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
    • J
      Freezer / sunrpc / NFS: don't allow TASK_KILLABLE sleeps to block the freezer · d310310c
      由 Jeff Layton 提交于 
      Allow the freezer to skip wait_on_bit_killable sleeps in the sunrpc
layer. This should allow suspend and hibernate events to proceed, even
when there are RPC's pending on the wire.

Also, wrap the TASK_KILLABLE sleeps in NFS layer in freezer_do_not_count
and freezer_count calls. This allows the freezer to skip tasks that are
sleeping while looping on EJUKEBOX or NFS4ERR_DELAY sorts of errors.
Signed-off-by: NJeff Layton <jlayton@redhat.com>
Signed-off-by: NRafael J. Wysocki <rjw@sisk.pl>
      d310310c
  17. 02 12月, 2011 2 次提交
  19. 23 11月, 2011 2 次提交
  21. 11 11月, 2011 1 次提交
  23. 01 11月, 2011 3 次提交
  25. 25 10月, 2011 9 次提交
  27. 20 10月, 2011 1 次提交
  29. 19 10月, 2011 3 次提交
  31. 11 10月, 2011 1 次提交
  33. 14 9月, 2011 1 次提交
  35. 20 8月, 2011 1 次提交