On Sat, Oct 03, 2015 at 08:38:02AM -0400, Jeff Layton wrote:
> I don't see any need to order callbacks with respect to one another.
I thought the code in nfsd4_process_cb_update really depended on this.
The locking it has is against nfsd threads, it probably assumes it's
only run from a cb thread and that it's the only one running at a time.
But I haven't reviewed it lately.
--b.
> Also, these are generally not involved in memory reclaim, so I don't see
> the need for a rescuer thread here either.
>
> Signed-off-by: Jeff Layton <jeff.layton@xxxxxxxxxxxxxxx>
> ---
> fs/nfsd/nfs4callback.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/nfsd/nfs4callback.c b/fs/nfsd/nfs4callback.c
> index e7f50c4081d6..7dabbb436290 100644
> --- a/fs/nfsd/nfs4callback.c
> +++ b/fs/nfsd/nfs4callback.c
> @@ -1017,7 +1017,7 @@ static const struct rpc_call_ops nfsd4_cb_ops = {
>
> int nfsd4_create_callback_queue(void)
> {
> - callback_wq = create_singlethread_workqueue("nfsd4_callbacks");
> + callback_wq = alloc_workqueue("%s", WQ_UNBOUND, 0, "nfsd4_callbacks");
> if (!callback_wq)
> return -ENOMEM;
> return 0;
> --
> 2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
