From: Stanislav Kinsbursky <skinsbursky@parallels.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: <akpm@linux-foundation.org>, <linux-nfs@vger.kernel.org>,
<Trond.Myklebust@netapp.com>, <linux-kernel@vger.kernel.org>,
<devel@openvz.org>
Subject: Re: [PATCH 0/2] NFSD: fix races in service per-net resources allocation
Date: Tue, 12 Feb 2013 10:49:12 +0400 [thread overview]
Message-ID: <5119E5E8.9030803@parallels.com> (raw)
In-Reply-To: <20130211163715.GA19342@fieldses.org>
11.02.2013 20:37, J. Bruce Fields пишет:
> On Mon, Feb 11, 2013 at 10:18:18AM +0400, Stanislav Kinsbursky wrote:
>> This one looks a bit complicated and confusing to me. Probably because
>> I'm not that familiar with service transports processing logic. So,
>> as I can see, we now try to run over all per-net pool-assigned
>> transports, remove them from "ready" queue and delete one by one.
>> Then we try to enqueue all temporary sockets. But where in enqueueing
>> of permanent sockets? I.e. how does they be destroyed with this patch?
>> Then we once again try to run over all per-net pool-assigned
>> transports, remove them from "ready" queue and delete one by one. Why
>> twice? I.e. why not just lose them, then enqueue them and
>> svc_clean_up_xprts()?
>
> I think you missed the first svc_close_list?:
>
Yeah, thanks! To many deleted lines confused me.
>>> svc_close_list(serv, &serv->sv_permsocks, net);
>>> + svc_clean_up_xprts(serv, net);
>>> + svc_close_list(serv, &serv->sv_tempsocks, net);
>>> + svc_clean_up_xprts(serv, net);
>
> The idea is that before we'd like to close all the listeners first, so
> that they aren't busy creating more tempsocks while we're trying to
> close them.
>
> I overlooked a race, though: if another thread was already handling an
> accept for one of the listeners then it might not get closed by that
> first svc_clean_up_xprts.
>
> I guess we could do something like:
>
> delay = 0;
>
> again:
> numclosed = svc_close_list(serv, &serv->sv_permsocks, net);
> numclosed += svc_close_list(serv, &serv->sv_tempsocks, net);
> if (numclosed) {
> svc_clean_up_xprts(serv, net);
> msleep(delay++);
> goto again;
> }
>
> Seems a little cheesy, but if we don't care much about shutdown
> performance in a rare corner case, maybe it's the simplest way out?
>
Agreed. This part (per-net shutdown) has enough logical complexity already and would be great to not
increase it.
--
Best regards,
Stanislav Kinsbursky
prev parent reply other threads:[~2013-02-12 6:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-01 11:28 [PATCH 0/2] NFSD: fix races in service per-net resources allocation Stanislav Kinsbursky
2013-02-01 11:28 ` [PATCH 1/2] per-cpu semaphores: export symbols to modules Stanislav Kinsbursky
2013-02-01 11:28 ` [PATCH 2/2] SUNRPC: protect transport processing with per-cpu rw semaphore Stanislav Kinsbursky
2013-02-11 0:25 ` [PATCH 0/2] NFSD: fix races in service per-net resources allocation J. Bruce Fields
2013-02-11 6:18 ` Stanislav Kinsbursky
2013-02-11 16:37 ` J. Bruce Fields
2013-02-11 20:58 ` J. Bruce Fields
2013-02-12 9:52 ` Stanislav Kinsbursky
2013-02-12 20:45 ` J. Bruce Fields
2013-02-12 21:18 ` Peter Staubach
2013-02-12 21:18 ` Peter Staubach
2013-02-13 5:16 ` Stanislav Kinsbursky
2013-02-12 6:49 ` Stanislav Kinsbursky [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5119E5E8.9030803@parallels.com \
--to=skinsbursky@parallels.com \
--cc=Trond.Myklebust@netapp.com \
--cc=akpm@linux-foundation.org \
--cc=bfields@fieldses.org \
--cc=devel@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.