All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Stanislav Kinsbursky <skinsbursky@parallels.com>
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: Mon, 11 Feb 2013 11:37:15 -0500	[thread overview]
Message-ID: <20130211163715.GA19342@fieldses.org> (raw)
In-Reply-To: <51188D2A.4070605@parallels.com>

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?:

> >  	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?

--b

  reply	other threads:[~2013-02-11 16:37 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 [this message]
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

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=20130211163715.GA19342@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=Trond.Myklebust@netapp.com \
    --cc=akpm@linux-foundation.org \
    --cc=devel@openvz.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=skinsbursky@parallels.com \
    /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.