public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stanislav Kinsbursky <skinsbursky@parallels.com>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"devel@openvz.org" <devel@openvz.org>
Subject: Re: [PATCH v2] SUNRPC: skip dead but not buried clients on PipeFS events
Date: Thu, 26 Apr 2012 01:14:57 +0400	[thread overview]
Message-ID: <4F986951.50105@parallels.com> (raw)
In-Reply-To: <20120425173005.GD751@fieldses.org>

25.04.2012 21:30, J. Bruce Fields написал:
> On Fri, Apr 20, 2012 at 06:11:02PM +0400, Stanislav Kinsbursky wrote:
>> v2: atomic_inc_return() was replaced by atomic_inc_not_zero().
>>
>> These clients can't be safely dereferenced if their counter in 0.
> I'm pretty confused by how these notifiers work....

There were made as simple as possible - i.e. notifier holds a client 
while creating of destroying PipeFS dentries. But event in this case 
there were races.

> rpc_release_client decrements cl_count to zero temporarily, to have it
> immediately re-incremented by rpc_free_auth.

BTW, I'm really confused with these re-incrementing reference counter 
technic. It makes life-time of RPC client unpredictable.
Is this a real-world valid situation, when usage of it reached zero, but 
while we destroying auth, there can some other user of client appear and 
client become alive again?
It it was done just to make sure that client is still active while we 
destroying auth, then maybe we can just remove the client from the 
clients list before rpc_free_auth? It will simplify the notifier 
callback logic greatly...


> So if we're called concurrently with rpc_release_client then it's sort
> of random whether someone gets this callback.
>
> Is that a problem?
>
> Also, is this an existing bug?  (In which case Trond should take it
> now.)

This is probably not a bug (I can't llok at the code right now; because 
these dentries will be destroyed), but a flaw.
Today (without this patch) notifier can try to create dentries for 
clients, which are dead already (i.e. auth was destroyed and client is 
going to be destroyed very soon, but notifier gained lock first.


>
> --b.
>
>> Signed-off-by: Stanislav Kinsbursky<skinsbursky@parallels.com>
>>
>> ---
>>   net/sunrpc/clnt.c |    3 ++-
>>   1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
>> index 6797246..d10ebc4 100644
>> --- a/net/sunrpc/clnt.c
>> +++ b/net/sunrpc/clnt.c
>> @@ -218,7 +218,8 @@ static struct rpc_clnt *rpc_get_client_for_event(struct net *net, int event)
>>   		if (((event == RPC_PIPEFS_MOUNT)&&  clnt->cl_dentry) ||
>>   		    ((event == RPC_PIPEFS_UMOUNT)&&  !clnt->cl_dentry))
>>   			continue;
>> -		atomic_inc(&clnt->cl_count);
>> +		if (atomic_inc_not_zero(&clnt->cl_count) == 0)
>> +			continue;
>>   		spin_unlock(&sn->rpc_client_lock);
>>   		return clnt;
>>   	}
>>


  parent reply	other threads:[~2012-04-25 21:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-20 14:11 [PATCH v2] SUNRPC: skip dead but not buried clients on PipeFS events Stanislav Kinsbursky
2012-04-25 17:30 ` J. Bruce Fields
2012-04-25 18:54   ` Myklebust, Trond
2012-04-25 21:14   ` Stanislav Kinsbursky [this message]
2012-04-26  6:31   ` 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=4F986951.50105@parallels.com \
    --to=skinsbursky@parallels.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox