redonkable
/
alistair23-linux
1
0
Fork 0
Code Releases Activity

svcrpc: simplify svc_close_all 

There's no need to be fooling with XPT_BUSY now that all the threads
are gone.

The list_del_init() here could execute at the same time as the
svc_xprt_enqueue()'s list_add_tail(), with undefined results.  We don't
really care at this point, but it might result in a spurious
list-corruption warning or something.

And svc_close() isn't adding any value; just call svc_delete_xprt()
directly.

Signed-off-by: J. Bruce Fields <bfields@redhat.com>
hifive-unleashed-5.1
J. Bruce Fields 2010-10-25 18:11:21 -04:00
parent ca7896cd83
commit f8c0d226fe
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
net/sunrpc/svc_xprt.c
View File

@ -941,16 +941,16 @@ void svc_close_all(struct list_head *xprt_list)
struct svc_xprt *xprt;
struct svc_xprt *tmp;
/*
* The server is shutting down, and no more threads are running.
* svc_xprt_enqueue() might still be running, but at worst it
* will re-add the xprt to sp_sockets, which will soon get
* freed. So we don't bother with any more locking, and don't
* leave the close to the (nonexistent) server threads:
*/
list_for_each_entry_safe(xprt, tmp, xprt_list, xpt_list) {
set_bit(XPT_CLOSE, &xprt->xpt_flags);
if (test_bit(XPT_BUSY, &xprt->xpt_flags)) {
/* Waiting to be processed, but no threads left,
* So just remove it from the waiting list
*/
list_del_init(&xprt->xpt_ready);
clear_bit(XPT_BUSY, &xprt->xpt_flags);
}
svc_close_xprt(xprt);
svc_delete_xprt(xprt);
}
}