All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
@ 2012-08-13 11:37 Stanislav Kinsbursky
  2012-08-13 12:10 ` Jeff Layton
  0 siblings, 1 reply; 17+ messages in thread
From: Stanislav Kinsbursky @ 2012-08-13 11:37 UTC (permalink / raw)
  To: Trond.Myklebust; +Cc: bfields, linux-nfs, linux-kernel, devel

v2:
1) rpc_clnt_set_nodename() prototype updated.
2) fixed errors in comment.

When child reaper exits, it can destroy mount namespace it belongs to, and if
there are NFS mounts inside, then it will try to umount them. But in this
point current->nsproxy is set to NULL and all namespaces will be destroyed one
by one. I.e. we can't dereference current->nsproxy to obtain uts namespace.

Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
---
 net/sunrpc/clnt.c |   16 +++++++++++++---
 1 files changed, 13 insertions(+), 3 deletions(-)

diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
index 9a9676e..8fbcbc8 100644
--- a/net/sunrpc/clnt.c
+++ b/net/sunrpc/clnt.c
@@ -277,8 +277,18 @@ void rpc_clients_notifier_unregister(void)
 	return rpc_pipefs_notifier_unregister(&rpc_clients_block);
 }
 
-static void rpc_clnt_set_nodename(struct rpc_clnt *clnt, const char *nodename)
+static void rpc_clnt_set_nodename(struct rpc_clnt *clnt)
 {
+	const char *nodename;
+
+	/*
+	 * We have to protect against dying child reaper, which has released
+	 * its nsproxy already and is trying to destroy mount namespace.
+	 */
+	if (current->nsproxy == NULL)
+		return;
+
+	nodename = utsname()->nodename;
 	clnt->cl_nodelen = strlen(nodename);
 	if (clnt->cl_nodelen > UNX_MAXNODENAME)
 		clnt->cl_nodelen = UNX_MAXNODENAME;
@@ -365,7 +375,7 @@ static struct rpc_clnt * rpc_new_client(const struct rpc_create_args *args, stru
 	}
 
 	/* save the nodename */
-	rpc_clnt_set_nodename(clnt, utsname()->nodename);
+	rpc_clnt_set_nodename(clnt);
 	rpc_register_client(clnt);
 	return clnt;
 
@@ -524,7 +534,7 @@ rpc_clone_client(struct rpc_clnt *clnt)
 	err = rpc_setup_pipedir(new, clnt->cl_program->pipe_dir_name);
 	if (err != 0)
 		goto out_no_path;
-	rpc_clnt_set_nodename(new, utsname()->nodename);
+	rpc_clnt_set_nodename(new);
 	if (new->cl_auth)
 		atomic_inc(&new->cl_auth->au_count);
 	atomic_inc(&clnt->cl_count);


^ permalink raw reply related	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
  2012-08-13 11:37 [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation Stanislav Kinsbursky
@ 2012-08-13 12:10 ` Jeff Layton
  2012-09-07 22:32     ` Myklebust, Trond
  0 siblings, 1 reply; 17+ messages in thread
From: Jeff Layton @ 2012-08-13 12:10 UTC (permalink / raw)
  To: Stanislav Kinsbursky
  Cc: Trond.Myklebust, bfields, linux-nfs, linux-kernel, devel

On Mon, 13 Aug 2012 15:37:31 +0400
Stanislav Kinsbursky <skinsbursky@parallels.com> wrote:

> v2:
> 1) rpc_clnt_set_nodename() prototype updated.
> 2) fixed errors in comment.
> 
> When child reaper exits, it can destroy mount namespace it belongs to, and if
> there are NFS mounts inside, then it will try to umount them. But in this
> point current->nsproxy is set to NULL and all namespaces will be destroyed one
> by one. I.e. we can't dereference current->nsproxy to obtain uts namespace.
> 
> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
> ---
>  net/sunrpc/clnt.c |   16 +++++++++++++---
>  1 files changed, 13 insertions(+), 3 deletions(-)
> 
> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> index 9a9676e..8fbcbc8 100644
> --- a/net/sunrpc/clnt.c
> +++ b/net/sunrpc/clnt.c
> @@ -277,8 +277,18 @@ void rpc_clients_notifier_unregister(void)
>  	return rpc_pipefs_notifier_unregister(&rpc_clients_block);
>  }
>  
> -static void rpc_clnt_set_nodename(struct rpc_clnt *clnt, const char *nodename)
> +static void rpc_clnt_set_nodename(struct rpc_clnt *clnt)
>  {
> +	const char *nodename;
> +
> +	/*
> +	 * We have to protect against dying child reaper, which has released
> +	 * its nsproxy already and is trying to destroy mount namespace.
> +	 */
> +	if (current->nsproxy == NULL)
> +		return;
> +
> +	nodename = utsname()->nodename;
>  	clnt->cl_nodelen = strlen(nodename);
>  	if (clnt->cl_nodelen > UNX_MAXNODENAME)
>  		clnt->cl_nodelen = UNX_MAXNODENAME;
> @@ -365,7 +375,7 @@ static struct rpc_clnt * rpc_new_client(const struct rpc_create_args *args, stru
>  	}
>  
>  	/* save the nodename */
> -	rpc_clnt_set_nodename(clnt, utsname()->nodename);
> +	rpc_clnt_set_nodename(clnt);
>  	rpc_register_client(clnt);
>  	return clnt;
>  
> @@ -524,7 +534,7 @@ rpc_clone_client(struct rpc_clnt *clnt)
>  	err = rpc_setup_pipedir(new, clnt->cl_program->pipe_dir_name);
>  	if (err != 0)
>  		goto out_no_path;
> -	rpc_clnt_set_nodename(new, utsname()->nodename);
> +	rpc_clnt_set_nodename(new);
>  	if (new->cl_auth)
>  		atomic_inc(&new->cl_auth->au_count);
>  	atomic_inc(&clnt->cl_count);
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Acked-by: Jeff Layton <jlayton@redhat.com>

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
  2012-08-13 12:10 ` Jeff Layton
@ 2012-09-07 22:32     ` Myklebust, Trond
  0 siblings, 0 replies; 17+ messages in thread
From: Myklebust, Trond @ 2012-09-07 22:32 UTC (permalink / raw)
  To: Jeff Layton; +Cc: Stanislav Kinsbursky, bfields, linux-nfs, linux-kernel, devel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 2918 bytes --]

On Mon, 2012-08-13 at 08:10 -0400, Jeff Layton wrote:
> On Mon, 13 Aug 2012 15:37:31 +0400
> Stanislav Kinsbursky <skinsbursky@parallels.com> wrote:
> 
> > v2:
> > 1) rpc_clnt_set_nodename() prototype updated.
> > 2) fixed errors in comment.
> > 
> > When child reaper exits, it can destroy mount namespace it belongs to, and if
> > there are NFS mounts inside, then it will try to umount them. But in this
> > point current->nsproxy is set to NULL and all namespaces will be destroyed one
> > by one. I.e. we can't dereference current->nsproxy to obtain uts namespace.
> > 
> > Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
> > ---
> >  net/sunrpc/clnt.c |   16 +++++++++++++---
> >  1 files changed, 13 insertions(+), 3 deletions(-)
> > 
> > diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> > index 9a9676e..8fbcbc8 100644
> > --- a/net/sunrpc/clnt.c
> > +++ b/net/sunrpc/clnt.c
> > @@ -277,8 +277,18 @@ void rpc_clients_notifier_unregister(void)
> >  	return rpc_pipefs_notifier_unregister(&rpc_clients_block);
> >  }
> >  
> > -static void rpc_clnt_set_nodename(struct rpc_clnt *clnt, const char *nodename)
> > +static void rpc_clnt_set_nodename(struct rpc_clnt *clnt)
> >  {
> > +	const char *nodename;
> > +
> > +	/*
> > +	 * We have to protect against dying child reaper, which has released
> > +	 * its nsproxy already and is trying to destroy mount namespace.
> > +	 */
> > +	if (current->nsproxy == NULL)
> > +		return;
> > +
> > +	nodename = utsname()->nodename;
> >  	clnt->cl_nodelen = strlen(nodename);
> >  	if (clnt->cl_nodelen > UNX_MAXNODENAME)
> >  		clnt->cl_nodelen = UNX_MAXNODENAME;
> > @@ -365,7 +375,7 @@ static struct rpc_clnt * rpc_new_client(const struct rpc_create_args *args, stru
> >  	}
> >  
> >  	/* save the nodename */
> > -	rpc_clnt_set_nodename(clnt, utsname()->nodename);
> > +	rpc_clnt_set_nodename(clnt);
> >  	rpc_register_client(clnt);
> >  	return clnt;
> >  
> > @@ -524,7 +534,7 @@ rpc_clone_client(struct rpc_clnt *clnt)
> >  	err = rpc_setup_pipedir(new, clnt->cl_program->pipe_dir_name);
> >  	if (err != 0)
> >  		goto out_no_path;
> > -	rpc_clnt_set_nodename(new, utsname()->nodename);
> > +	rpc_clnt_set_nodename(new);
> >  	if (new->cl_auth)
> >  		atomic_inc(&new->cl_auth->au_count);
> >  	atomic_inc(&clnt->cl_count);
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> Acked-by: Jeff Layton <jlayton@redhat.com>

OK, colour me confused (again). Why should a umount trigger an
rpc_create() or rpc_clone_client()?

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
@ 2012-09-07 22:32     ` Myklebust, Trond
  0 siblings, 0 replies; 17+ messages in thread
From: Myklebust, Trond @ 2012-09-07 22:32 UTC (permalink / raw)
  To: Jeff Layton; +Cc: Stanislav Kinsbursky, bfields, linux-nfs, linux-kernel, devel

T24gTW9uLCAyMDEyLTA4LTEzIGF0IDA4OjEwIC0wNDAwLCBKZWZmIExheXRvbiB3cm90ZToNCj4g
T24gTW9uLCAxMyBBdWcgMjAxMiAxNTozNzozMSArMDQwMA0KPiBTdGFuaXNsYXYgS2luc2J1cnNr
eSA8c2tpbnNidXJza3lAcGFyYWxsZWxzLmNvbT4gd3JvdGU6DQo+IA0KPiA+IHYyOg0KPiA+IDEp
IHJwY19jbG50X3NldF9ub2RlbmFtZSgpIHByb3RvdHlwZSB1cGRhdGVkLg0KPiA+IDIpIGZpeGVk
IGVycm9ycyBpbiBjb21tZW50Lg0KPiA+IA0KPiA+IFdoZW4gY2hpbGQgcmVhcGVyIGV4aXRzLCBp
dCBjYW4gZGVzdHJveSBtb3VudCBuYW1lc3BhY2UgaXQgYmVsb25ncyB0bywgYW5kIGlmDQo+ID4g
dGhlcmUgYXJlIE5GUyBtb3VudHMgaW5zaWRlLCB0aGVuIGl0IHdpbGwgdHJ5IHRvIHVtb3VudCB0
aGVtLiBCdXQgaW4gdGhpcw0KPiA+IHBvaW50IGN1cnJlbnQtPm5zcHJveHkgaXMgc2V0IHRvIE5V
TEwgYW5kIGFsbCBuYW1lc3BhY2VzIHdpbGwgYmUgZGVzdHJveWVkIG9uZQ0KPiA+IGJ5IG9uZS4g
SS5lLiB3ZSBjYW4ndCBkZXJlZmVyZW5jZSBjdXJyZW50LT5uc3Byb3h5IHRvIG9idGFpbiB1dHMg
bmFtZXNwYWNlLg0KPiA+IA0KPiA+IFNpZ25lZC1vZmYtYnk6IFN0YW5pc2xhdiBLaW5zYnVyc2t5
IDxza2luc2J1cnNreUBwYXJhbGxlbHMuY29tPg0KPiA+IC0tLQ0KPiA+ICBuZXQvc3VucnBjL2Ns
bnQuYyB8ICAgMTYgKysrKysrKysrKysrKy0tLQ0KPiA+ICAxIGZpbGVzIGNoYW5nZWQsIDEzIGlu
c2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pDQo+ID4gDQo+ID4gZGlmZiAtLWdpdCBhL25ldC9z
dW5ycGMvY2xudC5jIGIvbmV0L3N1bnJwYy9jbG50LmMNCj4gPiBpbmRleCA5YTk2NzZlLi44ZmJj
YmM4IDEwMDY0NA0KPiA+IC0tLSBhL25ldC9zdW5ycGMvY2xudC5jDQo+ID4gKysrIGIvbmV0L3N1
bnJwYy9jbG50LmMNCj4gPiBAQCAtMjc3LDggKzI3NywxOCBAQCB2b2lkIHJwY19jbGllbnRzX25v
dGlmaWVyX3VucmVnaXN0ZXIodm9pZCkNCj4gPiAgCXJldHVybiBycGNfcGlwZWZzX25vdGlmaWVy
X3VucmVnaXN0ZXIoJnJwY19jbGllbnRzX2Jsb2NrKTsNCj4gPiAgfQ0KPiA+ICANCj4gPiAtc3Rh
dGljIHZvaWQgcnBjX2NsbnRfc2V0X25vZGVuYW1lKHN0cnVjdCBycGNfY2xudCAqY2xudCwgY29u
c3QgY2hhciAqbm9kZW5hbWUpDQo+ID4gK3N0YXRpYyB2b2lkIHJwY19jbG50X3NldF9ub2RlbmFt
ZShzdHJ1Y3QgcnBjX2NsbnQgKmNsbnQpDQo+ID4gIHsNCj4gPiArCWNvbnN0IGNoYXIgKm5vZGVu
YW1lOw0KPiA+ICsNCj4gPiArCS8qDQo+ID4gKwkgKiBXZSBoYXZlIHRvIHByb3RlY3QgYWdhaW5z
dCBkeWluZyBjaGlsZCByZWFwZXIsIHdoaWNoIGhhcyByZWxlYXNlZA0KPiA+ICsJICogaXRzIG5z
cHJveHkgYWxyZWFkeSBhbmQgaXMgdHJ5aW5nIHRvIGRlc3Ryb3kgbW91bnQgbmFtZXNwYWNlLg0K
PiA+ICsJICovDQo+ID4gKwlpZiAoY3VycmVudC0+bnNwcm94eSA9PSBOVUxMKQ0KPiA+ICsJCXJl
dHVybjsNCj4gPiArDQo+ID4gKwlub2RlbmFtZSA9IHV0c25hbWUoKS0+bm9kZW5hbWU7DQo+ID4g
IAljbG50LT5jbF9ub2RlbGVuID0gc3RybGVuKG5vZGVuYW1lKTsNCj4gPiAgCWlmIChjbG50LT5j
bF9ub2RlbGVuID4gVU5YX01BWE5PREVOQU1FKQ0KPiA+ICAJCWNsbnQtPmNsX25vZGVsZW4gPSBV
TlhfTUFYTk9ERU5BTUU7DQo+ID4gQEAgLTM2NSw3ICszNzUsNyBAQCBzdGF0aWMgc3RydWN0IHJw
Y19jbG50ICogcnBjX25ld19jbGllbnQoY29uc3Qgc3RydWN0IHJwY19jcmVhdGVfYXJncyAqYXJn
cywgc3RydQ0KPiA+ICAJfQ0KPiA+ICANCj4gPiAgCS8qIHNhdmUgdGhlIG5vZGVuYW1lICovDQo+
ID4gLQlycGNfY2xudF9zZXRfbm9kZW5hbWUoY2xudCwgdXRzbmFtZSgpLT5ub2RlbmFtZSk7DQo+
ID4gKwlycGNfY2xudF9zZXRfbm9kZW5hbWUoY2xudCk7DQo+ID4gIAlycGNfcmVnaXN0ZXJfY2xp
ZW50KGNsbnQpOw0KPiA+ICAJcmV0dXJuIGNsbnQ7DQo+ID4gIA0KPiA+IEBAIC01MjQsNyArNTM0
LDcgQEAgcnBjX2Nsb25lX2NsaWVudChzdHJ1Y3QgcnBjX2NsbnQgKmNsbnQpDQo+ID4gIAllcnIg
PSBycGNfc2V0dXBfcGlwZWRpcihuZXcsIGNsbnQtPmNsX3Byb2dyYW0tPnBpcGVfZGlyX25hbWUp
Ow0KPiA+ICAJaWYgKGVyciAhPSAwKQ0KPiA+ICAJCWdvdG8gb3V0X25vX3BhdGg7DQo+ID4gLQly
cGNfY2xudF9zZXRfbm9kZW5hbWUobmV3LCB1dHNuYW1lKCktPm5vZGVuYW1lKTsNCj4gPiArCXJw
Y19jbG50X3NldF9ub2RlbmFtZShuZXcpOw0KPiA+ICAJaWYgKG5ldy0+Y2xfYXV0aCkNCj4gPiAg
CQlhdG9taWNfaW5jKCZuZXctPmNsX2F1dGgtPmF1X2NvdW50KTsNCj4gPiAgCWF0b21pY19pbmMo
JmNsbnQtPmNsX2NvdW50KTsNCj4gPiANCj4gPiAtLQ0KPiA+IFRvIHVuc3Vic2NyaWJlIGZyb20g
dGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5lICJ1bnN1YnNjcmliZSBsaW51eC1uZnMiIGluDQo+ID4g
dGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRvIG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcNCj4gPiBN
b3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5rZXJuZWwub3JnL21ham9yZG9tby1p
bmZvLmh0bWwNCj4gDQo+IEFja2VkLWJ5OiBKZWZmIExheXRvbiA8amxheXRvbkByZWRoYXQuY29t
Pg0KDQpPSywgY29sb3VyIG1lIGNvbmZ1c2VkIChhZ2FpbikuIFdoeSBzaG91bGQgYSB1bW91bnQg
dHJpZ2dlciBhbg0KcnBjX2NyZWF0ZSgpIG9yIHJwY19jbG9uZV9jbGllbnQoKT8NCg0KLS0gDQpU
cm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRBcHANClRy
b25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0KDQo=

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
  2012-09-07 22:32     ` Myklebust, Trond
  (?)
@ 2012-09-08  5:59     ` Stanislav Kinsbursky
  2012-09-08 14:33         ` Myklebust, Trond
  -1 siblings, 1 reply; 17+ messages in thread
From: Stanislav Kinsbursky @ 2012-09-08  5:59 UTC (permalink / raw)
  To: Myklebust, Trond; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

08.09.2012 01:32, Myklebust, Trond пишет:
> On Mon, 2012-08-13 at 08:10 -0400, Jeff Layton wrote:
>> On Mon, 13 Aug 2012 15:37:31 +0400
>> Stanislav Kinsbursky <skinsbursky@parallels.com> wrote:
>>
>>> v2:
>>> 1) rpc_clnt_set_nodename() prototype updated.
>>> 2) fixed errors in comment.
>>>
>>> When child reaper exits, it can destroy mount namespace it belongs to, and if
>>> there are NFS mounts inside, then it will try to umount them. But in this
>>> point current->nsproxy is set to NULL and all namespaces will be destroyed one
>>> by one. I.e. we can't dereference current->nsproxy to obtain uts namespace.
>>>
>>> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
>>> ---
>>>   net/sunrpc/clnt.c |   16 +++++++++++++---
>>>   1 files changed, 13 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
>>> index 9a9676e..8fbcbc8 100644
>>> --- a/net/sunrpc/clnt.c
>>> +++ b/net/sunrpc/clnt.c
>>> @@ -277,8 +277,18 @@ void rpc_clients_notifier_unregister(void)
>>>   	return rpc_pipefs_notifier_unregister(&rpc_clients_block);
>>>   }
>>>   
>>> -static void rpc_clnt_set_nodename(struct rpc_clnt *clnt, const char *nodename)
>>> +static void rpc_clnt_set_nodename(struct rpc_clnt *clnt)
>>>   {
>>> +	const char *nodename;
>>> +
>>> +	/*
>>> +	 * We have to protect against dying child reaper, which has released
>>> +	 * its nsproxy already and is trying to destroy mount namespace.
>>> +	 */
>>> +	if (current->nsproxy == NULL)
>>> +		return;
>>> +
>>> +	nodename = utsname()->nodename;
>>>   	clnt->cl_nodelen = strlen(nodename);
>>>   	if (clnt->cl_nodelen > UNX_MAXNODENAME)
>>>   		clnt->cl_nodelen = UNX_MAXNODENAME;
>>> @@ -365,7 +375,7 @@ static struct rpc_clnt * rpc_new_client(const struct rpc_create_args *args, stru
>>>   	}
>>>   
>>>   	/* save the nodename */
>>> -	rpc_clnt_set_nodename(clnt, utsname()->nodename);
>>> +	rpc_clnt_set_nodename(clnt);
>>>   	rpc_register_client(clnt);
>>>   	return clnt;
>>>   
>>> @@ -524,7 +534,7 @@ rpc_clone_client(struct rpc_clnt *clnt)
>>>   	err = rpc_setup_pipedir(new, clnt->cl_program->pipe_dir_name);
>>>   	if (err != 0)
>>>   		goto out_no_path;
>>> -	rpc_clnt_set_nodename(new, utsname()->nodename);
>>> +	rpc_clnt_set_nodename(new);
>>>   	if (new->cl_auth)
>>>   		atomic_inc(&new->cl_auth->au_count);
>>>   	atomic_inc(&clnt->cl_count);
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Acked-by: Jeff Layton <jlayton@redhat.com>
> OK, colour me confused (again).

What color?

> Why should a umount trigger an
> rpc_create() or rpc_clone_client()?

It calls nsm_create().
Here is the trace (https://bugzilla.redhat.com/show_bug.cgi?id=830862, 
comment 68):

CR2: 0000000000000008
Process mysqld

Call Trace:
? __schedule+0x3c7
nsm_create+0x8b
nsm_mon_unmon+0x64
nlm_destroy_host_locked+0x6b
nlmclnt_release_host+0x88
nlmclnt_done+0x1a
nfs_destroy_server+0x24
nfs_free_server+0xce
nfs_kill_super+0x34
deactivate_locked_super+0x57
deactivate_super+0x4e
mntput_no_expire+0xcc
mntput+0x26
release_mounts+0x77
put_mnt_ns+0x78
free_nsproxy+0x1f
switch_task_namespaces+0x50
exit_task_namespaces+0x10
do_exit+0x456
do_group_exit+0x3f
sys_exit_group+0x17
system_call_fastpath+0x16
RIP rpc_create+0x401 [sunrpc]
Kernel panic - not syncing




>


^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
  2012-09-08  5:59     ` Stanislav Kinsbursky
@ 2012-09-08 14:33         ` Myklebust, Trond
  0 siblings, 0 replies; 17+ messages in thread
From: Myklebust, Trond @ 2012-09-08 14:33 UTC (permalink / raw)
  To: Stanislav Kinsbursky; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 3539 bytes --]

On Sat, 2012-09-08 at 08:59 +0300, Stanislav Kinsbursky wrote:
> 08.09.2012 01:32, Myklebust, Trond пишет:
> > On Mon, 2012-08-13 at 08:10 -0400, Jeff Layton wrote:
> >> On Mon, 13 Aug 2012 15:37:31 +0400
> >> Stanislav Kinsbursky <skinsbursky@parallels.com> wrote:
> >>
> >>> v2:
> >>> 1) rpc_clnt_set_nodename() prototype updated.
> >>> 2) fixed errors in comment.
> >>>
> >>> When child reaper exits, it can destroy mount namespace it belongs to, and if
> >>> there are NFS mounts inside, then it will try to umount them. But in this
> >>> point current->nsproxy is set to NULL and all namespaces will be destroyed one
> >>> by one. I.e. we can't dereference current->nsproxy to obtain uts namespace.
> >>>
> >>> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
> >>> ---
> >>>   net/sunrpc/clnt.c |   16 +++++++++++++---
> >>>   1 files changed, 13 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> >>> index 9a9676e..8fbcbc8 100644
> >>> --- a/net/sunrpc/clnt.c
> >>> +++ b/net/sunrpc/clnt.c
> >>> @@ -277,8 +277,18 @@ void rpc_clients_notifier_unregister(void)
> >>>   	return rpc_pipefs_notifier_unregister(&rpc_clients_block);
> >>>   }
> >>>   
> >>> -static void rpc_clnt_set_nodename(struct rpc_clnt *clnt, const char *nodename)
> >>> +static void rpc_clnt_set_nodename(struct rpc_clnt *clnt)
> >>>   {
> >>> +	const char *nodename;
> >>> +
> >>> +	/*
> >>> +	 * We have to protect against dying child reaper, which has released
> >>> +	 * its nsproxy already and is trying to destroy mount namespace.
> >>> +	 */
> >>> +	if (current->nsproxy == NULL)
> >>> +		return;
> >>> +
> >>> +	nodename = utsname()->nodename;
> >>>   	clnt->cl_nodelen = strlen(nodename);
> >>>   	if (clnt->cl_nodelen > UNX_MAXNODENAME)
> >>>   		clnt->cl_nodelen = UNX_MAXNODENAME;
> >>> @@ -365,7 +375,7 @@ static struct rpc_clnt * rpc_new_client(const struct rpc_create_args *args, stru
> >>>   	}
> >>>   
> >>>   	/* save the nodename */
> >>> -	rpc_clnt_set_nodename(clnt, utsname()->nodename);
> >>> +	rpc_clnt_set_nodename(clnt);
> >>>   	rpc_register_client(clnt);
> >>>   	return clnt;
> >>>   
> >>> @@ -524,7 +534,7 @@ rpc_clone_client(struct rpc_clnt *clnt)
> >>>   	err = rpc_setup_pipedir(new, clnt->cl_program->pipe_dir_name);
> >>>   	if (err != 0)
> >>>   		goto out_no_path;
> >>> -	rpc_clnt_set_nodename(new, utsname()->nodename);
> >>> +	rpc_clnt_set_nodename(new);
> >>>   	if (new->cl_auth)
> >>>   		atomic_inc(&new->cl_auth->au_count);
> >>>   	atomic_inc(&clnt->cl_count);
> >>>
> >>> --
> >>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >>> the body of a message to majordomo@vger.kernel.org
> >>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> Acked-by: Jeff Layton <jlayton@redhat.com>
> > OK, colour me confused (again).
> 
> What color?
> 
> > Why should a umount trigger an
> > rpc_create() or rpc_clone_client()?
> 
> It calls nsm_create().
> Here is the trace (https://bugzilla.redhat.com/show_bug.cgi?id=830862, 
> comment 68):

Right, but if we're using NFSv3 lock monitoring, we know in advance that
we're going to need an nsm call to localhost. Why can't we just cache
the one that we used to start lock monitoring in the first place?

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
@ 2012-09-08 14:33         ` Myklebust, Trond
  0 siblings, 0 replies; 17+ messages in thread
From: Myklebust, Trond @ 2012-09-08 14:33 UTC (permalink / raw)
  To: Stanislav Kinsbursky; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

T24gU2F0LCAyMDEyLTA5LTA4IGF0IDA4OjU5ICswMzAwLCBTdGFuaXNsYXYgS2luc2J1cnNreSB3
cm90ZToNCj4gMDguMDkuMjAxMiAwMTozMiwgTXlrbGVidXN0LCBUcm9uZCDQv9C40YjQtdGCOg0K
PiA+IE9uIE1vbiwgMjAxMi0wOC0xMyBhdCAwODoxMCAtMDQwMCwgSmVmZiBMYXl0b24gd3JvdGU6
DQo+ID4+IE9uIE1vbiwgMTMgQXVnIDIwMTIgMTU6Mzc6MzEgKzA0MDANCj4gPj4gU3RhbmlzbGF2
IEtpbnNidXJza3kgPHNraW5zYnVyc2t5QHBhcmFsbGVscy5jb20+IHdyb3RlOg0KPiA+Pg0KPiA+
Pj4gdjI6DQo+ID4+PiAxKSBycGNfY2xudF9zZXRfbm9kZW5hbWUoKSBwcm90b3R5cGUgdXBkYXRl
ZC4NCj4gPj4+IDIpIGZpeGVkIGVycm9ycyBpbiBjb21tZW50Lg0KPiA+Pj4NCj4gPj4+IFdoZW4g
Y2hpbGQgcmVhcGVyIGV4aXRzLCBpdCBjYW4gZGVzdHJveSBtb3VudCBuYW1lc3BhY2UgaXQgYmVs
b25ncyB0bywgYW5kIGlmDQo+ID4+PiB0aGVyZSBhcmUgTkZTIG1vdW50cyBpbnNpZGUsIHRoZW4g
aXQgd2lsbCB0cnkgdG8gdW1vdW50IHRoZW0uIEJ1dCBpbiB0aGlzDQo+ID4+PiBwb2ludCBjdXJy
ZW50LT5uc3Byb3h5IGlzIHNldCB0byBOVUxMIGFuZCBhbGwgbmFtZXNwYWNlcyB3aWxsIGJlIGRl
c3Ryb3llZCBvbmUNCj4gPj4+IGJ5IG9uZS4gSS5lLiB3ZSBjYW4ndCBkZXJlZmVyZW5jZSBjdXJy
ZW50LT5uc3Byb3h5IHRvIG9idGFpbiB1dHMgbmFtZXNwYWNlLg0KPiA+Pj4NCj4gPj4+IFNpZ25l
ZC1vZmYtYnk6IFN0YW5pc2xhdiBLaW5zYnVyc2t5IDxza2luc2J1cnNreUBwYXJhbGxlbHMuY29t
Pg0KPiA+Pj4gLS0tDQo+ID4+PiAgIG5ldC9zdW5ycGMvY2xudC5jIHwgICAxNiArKysrKysrKysr
KysrLS0tDQo+ID4+PiAgIDEgZmlsZXMgY2hhbmdlZCwgMTMgaW5zZXJ0aW9ucygrKSwgMyBkZWxl
dGlvbnMoLSkNCj4gPj4+DQo+ID4+PiBkaWZmIC0tZ2l0IGEvbmV0L3N1bnJwYy9jbG50LmMgYi9u
ZXQvc3VucnBjL2NsbnQuYw0KPiA+Pj4gaW5kZXggOWE5Njc2ZS4uOGZiY2JjOCAxMDA2NDQNCj4g
Pj4+IC0tLSBhL25ldC9zdW5ycGMvY2xudC5jDQo+ID4+PiArKysgYi9uZXQvc3VucnBjL2NsbnQu
Yw0KPiA+Pj4gQEAgLTI3Nyw4ICsyNzcsMTggQEAgdm9pZCBycGNfY2xpZW50c19ub3RpZmllcl91
bnJlZ2lzdGVyKHZvaWQpDQo+ID4+PiAgIAlyZXR1cm4gcnBjX3BpcGVmc19ub3RpZmllcl91bnJl
Z2lzdGVyKCZycGNfY2xpZW50c19ibG9jayk7DQo+ID4+PiAgIH0NCj4gPj4+ICAgDQo+ID4+PiAt
c3RhdGljIHZvaWQgcnBjX2NsbnRfc2V0X25vZGVuYW1lKHN0cnVjdCBycGNfY2xudCAqY2xudCwg
Y29uc3QgY2hhciAqbm9kZW5hbWUpDQo+ID4+PiArc3RhdGljIHZvaWQgcnBjX2NsbnRfc2V0X25v
ZGVuYW1lKHN0cnVjdCBycGNfY2xudCAqY2xudCkNCj4gPj4+ICAgew0KPiA+Pj4gKwljb25zdCBj
aGFyICpub2RlbmFtZTsNCj4gPj4+ICsNCj4gPj4+ICsJLyoNCj4gPj4+ICsJICogV2UgaGF2ZSB0
byBwcm90ZWN0IGFnYWluc3QgZHlpbmcgY2hpbGQgcmVhcGVyLCB3aGljaCBoYXMgcmVsZWFzZWQN
Cj4gPj4+ICsJICogaXRzIG5zcHJveHkgYWxyZWFkeSBhbmQgaXMgdHJ5aW5nIHRvIGRlc3Ryb3kg
bW91bnQgbmFtZXNwYWNlLg0KPiA+Pj4gKwkgKi8NCj4gPj4+ICsJaWYgKGN1cnJlbnQtPm5zcHJv
eHkgPT0gTlVMTCkNCj4gPj4+ICsJCXJldHVybjsNCj4gPj4+ICsNCj4gPj4+ICsJbm9kZW5hbWUg
PSB1dHNuYW1lKCktPm5vZGVuYW1lOw0KPiA+Pj4gICAJY2xudC0+Y2xfbm9kZWxlbiA9IHN0cmxl
bihub2RlbmFtZSk7DQo+ID4+PiAgIAlpZiAoY2xudC0+Y2xfbm9kZWxlbiA+IFVOWF9NQVhOT0RF
TkFNRSkNCj4gPj4+ICAgCQljbG50LT5jbF9ub2RlbGVuID0gVU5YX01BWE5PREVOQU1FOw0KPiA+
Pj4gQEAgLTM2NSw3ICszNzUsNyBAQCBzdGF0aWMgc3RydWN0IHJwY19jbG50ICogcnBjX25ld19j
bGllbnQoY29uc3Qgc3RydWN0IHJwY19jcmVhdGVfYXJncyAqYXJncywgc3RydQ0KPiA+Pj4gICAJ
fQ0KPiA+Pj4gICANCj4gPj4+ICAgCS8qIHNhdmUgdGhlIG5vZGVuYW1lICovDQo+ID4+PiAtCXJw
Y19jbG50X3NldF9ub2RlbmFtZShjbG50LCB1dHNuYW1lKCktPm5vZGVuYW1lKTsNCj4gPj4+ICsJ
cnBjX2NsbnRfc2V0X25vZGVuYW1lKGNsbnQpOw0KPiA+Pj4gICAJcnBjX3JlZ2lzdGVyX2NsaWVu
dChjbG50KTsNCj4gPj4+ICAgCXJldHVybiBjbG50Ow0KPiA+Pj4gICANCj4gPj4+IEBAIC01MjQs
NyArNTM0LDcgQEAgcnBjX2Nsb25lX2NsaWVudChzdHJ1Y3QgcnBjX2NsbnQgKmNsbnQpDQo+ID4+
PiAgIAllcnIgPSBycGNfc2V0dXBfcGlwZWRpcihuZXcsIGNsbnQtPmNsX3Byb2dyYW0tPnBpcGVf
ZGlyX25hbWUpOw0KPiA+Pj4gICAJaWYgKGVyciAhPSAwKQ0KPiA+Pj4gICAJCWdvdG8gb3V0X25v
X3BhdGg7DQo+ID4+PiAtCXJwY19jbG50X3NldF9ub2RlbmFtZShuZXcsIHV0c25hbWUoKS0+bm9k
ZW5hbWUpOw0KPiA+Pj4gKwlycGNfY2xudF9zZXRfbm9kZW5hbWUobmV3KTsNCj4gPj4+ICAgCWlm
IChuZXctPmNsX2F1dGgpDQo+ID4+PiAgIAkJYXRvbWljX2luYygmbmV3LT5jbF9hdXRoLT5hdV9j
b3VudCk7DQo+ID4+PiAgIAlhdG9taWNfaW5jKCZjbG50LT5jbF9jb3VudCk7DQo+ID4+Pg0KPiA+
Pj4gLS0NCj4gPj4+IFRvIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBsaXN0OiBzZW5kIHRoZSBsaW5l
ICJ1bnN1YnNjcmliZSBsaW51eC1uZnMiIGluDQo+ID4+PiB0aGUgYm9keSBvZiBhIG1lc3NhZ2Ug
dG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9yZw0KPiA+Pj4gTW9yZSBtYWpvcmRvbW8gaW5mbyBh
dCAgaHR0cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQo+ID4+IEFja2Vk
LWJ5OiBKZWZmIExheXRvbiA8amxheXRvbkByZWRoYXQuY29tPg0KPiA+IE9LLCBjb2xvdXIgbWUg
Y29uZnVzZWQgKGFnYWluKS4NCj4gDQo+IFdoYXQgY29sb3I/DQo+IA0KPiA+IFdoeSBzaG91bGQg
YSB1bW91bnQgdHJpZ2dlciBhbg0KPiA+IHJwY19jcmVhdGUoKSBvciBycGNfY2xvbmVfY2xpZW50
KCk/DQo+IA0KPiBJdCBjYWxscyBuc21fY3JlYXRlKCkuDQo+IEhlcmUgaXMgdGhlIHRyYWNlICho
dHRwczovL2J1Z3ppbGxhLnJlZGhhdC5jb20vc2hvd19idWcuY2dpP2lkPTgzMDg2MiwgDQo+IGNv
bW1lbnQgNjgpOg0KDQpSaWdodCwgYnV0IGlmIHdlJ3JlIHVzaW5nIE5GU3YzIGxvY2sgbW9uaXRv
cmluZywgd2Uga25vdyBpbiBhZHZhbmNlIHRoYXQNCndlJ3JlIGdvaW5nIHRvIG5lZWQgYW4gbnNt
IGNhbGwgdG8gbG9jYWxob3N0LiBXaHkgY2FuJ3Qgd2UganVzdCBjYWNoZQ0KdGhlIG9uZSB0aGF0
IHdlIHVzZWQgdG8gc3RhcnQgbG9jayBtb25pdG9yaW5nIGluIHRoZSBmaXJzdCBwbGFjZT8NCg0K
LS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRB
cHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0KDQo=

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
  2012-09-08 14:33         ` Myklebust, Trond
  (?)
@ 2012-09-10  8:43         ` Stanislav Kinsbursky
  2012-09-10 15:27             ` Myklebust, Trond
  -1 siblings, 1 reply; 17+ messages in thread
From: Stanislav Kinsbursky @ 2012-09-10  8:43 UTC (permalink / raw)
  To: Myklebust, Trond; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

08.09.2012 18:33, Myklebust, Trond пишет:
> On Sat, 2012-09-08 at 08:59 +0300, Stanislav Kinsbursky wrote:
>> 08.09.2012 01:32, Myklebust, Trond пишет:
>>> On Mon, 2012-08-13 at 08:10 -0400, Jeff Layton wrote:
>>>> On Mon, 13 Aug 2012 15:37:31 +0400
>>>> Stanislav Kinsbursky <skinsbursky@parallels.com> wrote:
>>>>
>>>>> v2:
>>>>> 1) rpc_clnt_set_nodename() prototype updated.
>>>>> 2) fixed errors in comment.
>>>>>
>>>>> When child reaper exits, it can destroy mount namespace it belongs to, and if
>>>>> there are NFS mounts inside, then it will try to umount them. But in this
>>>>> point current->nsproxy is set to NULL and all namespaces will be destroyed one
>>>>> by one. I.e. we can't dereference current->nsproxy to obtain uts namespace.
>>>>>
>>>>> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
>>>>> ---
>>>>>    net/sunrpc/clnt.c |   16 +++++++++++++---
>>>>>    1 files changed, 13 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
>>>>> index 9a9676e..8fbcbc8 100644
>>>>> --- a/net/sunrpc/clnt.c
>>>>> +++ b/net/sunrpc/clnt.c
>>>>> @@ -277,8 +277,18 @@ void rpc_clients_notifier_unregister(void)
>>>>>    	return rpc_pipefs_notifier_unregister(&rpc_clients_block);
>>>>>    }
>>>>>
>>>>> -static void rpc_clnt_set_nodename(struct rpc_clnt *clnt, const char *nodename)
>>>>> +static void rpc_clnt_set_nodename(struct rpc_clnt *clnt)
>>>>>    {
>>>>> +	const char *nodename;
>>>>> +
>>>>> +	/*
>>>>> +	 * We have to protect against dying child reaper, which has released
>>>>> +	 * its nsproxy already and is trying to destroy mount namespace.
>>>>> +	 */
>>>>> +	if (current->nsproxy == NULL)
>>>>> +		return;
>>>>> +
>>>>> +	nodename = utsname()->nodename;
>>>>>    	clnt->cl_nodelen = strlen(nodename);
>>>>>    	if (clnt->cl_nodelen > UNX_MAXNODENAME)
>>>>>    		clnt->cl_nodelen = UNX_MAXNODENAME;
>>>>> @@ -365,7 +375,7 @@ static struct rpc_clnt * rpc_new_client(const struct rpc_create_args *args, stru
>>>>>    	}
>>>>>
>>>>>    	/* save the nodename */
>>>>> -	rpc_clnt_set_nodename(clnt, utsname()->nodename);
>>>>> +	rpc_clnt_set_nodename(clnt);
>>>>>    	rpc_register_client(clnt);
>>>>>    	return clnt;
>>>>>
>>>>> @@ -524,7 +534,7 @@ rpc_clone_client(struct rpc_clnt *clnt)
>>>>>    	err = rpc_setup_pipedir(new, clnt->cl_program->pipe_dir_name);
>>>>>    	if (err != 0)
>>>>>    		goto out_no_path;
>>>>> -	rpc_clnt_set_nodename(new, utsname()->nodename);
>>>>> +	rpc_clnt_set_nodename(new);
>>>>>    	if (new->cl_auth)
>>>>>    		atomic_inc(&new->cl_auth->au_count);
>>>>>    	atomic_inc(&clnt->cl_count);
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>> Acked-by: Jeff Layton <jlayton@redhat.com>
>>> OK, colour me confused (again).
>>
>> What color?
>>
>>> Why should a umount trigger an
>>> rpc_create() or rpc_clone_client()?
>>
>> It calls nsm_create().
>> Here is the trace (https://bugzilla.redhat.com/show_bug.cgi?id=830862,
>> comment 68):
>
> Right, but if we're using NFSv3 lock monitoring, we know in advance that
> we're going to need an nsm call to localhost. Why can't we just cache
> the one that we used to start lock monitoring in the first place?
>

Do you suggest to cache the call or the client for the call?

-- 
Best regards,
Stanislav Kinsbursky

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
  2012-09-10  8:43         ` Stanislav Kinsbursky
@ 2012-09-10 15:27             ` Myklebust, Trond
  0 siblings, 0 replies; 17+ messages in thread
From: Myklebust, Trond @ 2012-09-10 15:27 UTC (permalink / raw)
  To: Stanislav Kinsbursky; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4262 bytes --]

On Mon, 2012-09-10 at 12:43 +0400, Stanislav Kinsbursky wrote:
> 08.09.2012 18:33, Myklebust, Trond пишет:
> > On Sat, 2012-09-08 at 08:59 +0300, Stanislav Kinsbursky wrote:
> >> 08.09.2012 01:32, Myklebust, Trond пишет:
> >>> On Mon, 2012-08-13 at 08:10 -0400, Jeff Layton wrote:
> >>>> On Mon, 13 Aug 2012 15:37:31 +0400
> >>>> Stanislav Kinsbursky <skinsbursky@parallels.com> wrote:
> >>>>
> >>>>> v2:
> >>>>> 1) rpc_clnt_set_nodename() prototype updated.
> >>>>> 2) fixed errors in comment.
> >>>>>
> >>>>> When child reaper exits, it can destroy mount namespace it belongs to, and if
> >>>>> there are NFS mounts inside, then it will try to umount them. But in this
> >>>>> point current->nsproxy is set to NULL and all namespaces will be destroyed one
> >>>>> by one. I.e. we can't dereference current->nsproxy to obtain uts namespace.
> >>>>>
> >>>>> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
> >>>>> ---
> >>>>>    net/sunrpc/clnt.c |   16 +++++++++++++---
> >>>>>    1 files changed, 13 insertions(+), 3 deletions(-)
> >>>>>
> >>>>> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
> >>>>> index 9a9676e..8fbcbc8 100644
> >>>>> --- a/net/sunrpc/clnt.c
> >>>>> +++ b/net/sunrpc/clnt.c
> >>>>> @@ -277,8 +277,18 @@ void rpc_clients_notifier_unregister(void)
> >>>>>    	return rpc_pipefs_notifier_unregister(&rpc_clients_block);
> >>>>>    }
> >>>>>
> >>>>> -static void rpc_clnt_set_nodename(struct rpc_clnt *clnt, const char *nodename)
> >>>>> +static void rpc_clnt_set_nodename(struct rpc_clnt *clnt)
> >>>>>    {
> >>>>> +	const char *nodename;
> >>>>> +
> >>>>> +	/*
> >>>>> +	 * We have to protect against dying child reaper, which has released
> >>>>> +	 * its nsproxy already and is trying to destroy mount namespace.
> >>>>> +	 */
> >>>>> +	if (current->nsproxy == NULL)
> >>>>> +		return;
> >>>>> +
> >>>>> +	nodename = utsname()->nodename;
> >>>>>    	clnt->cl_nodelen = strlen(nodename);
> >>>>>    	if (clnt->cl_nodelen > UNX_MAXNODENAME)
> >>>>>    		clnt->cl_nodelen = UNX_MAXNODENAME;
> >>>>> @@ -365,7 +375,7 @@ static struct rpc_clnt * rpc_new_client(const struct rpc_create_args *args, stru
> >>>>>    	}
> >>>>>
> >>>>>    	/* save the nodename */
> >>>>> -	rpc_clnt_set_nodename(clnt, utsname()->nodename);
> >>>>> +	rpc_clnt_set_nodename(clnt);
> >>>>>    	rpc_register_client(clnt);
> >>>>>    	return clnt;
> >>>>>
> >>>>> @@ -524,7 +534,7 @@ rpc_clone_client(struct rpc_clnt *clnt)
> >>>>>    	err = rpc_setup_pipedir(new, clnt->cl_program->pipe_dir_name);
> >>>>>    	if (err != 0)
> >>>>>    		goto out_no_path;
> >>>>> -	rpc_clnt_set_nodename(new, utsname()->nodename);
> >>>>> +	rpc_clnt_set_nodename(new);
> >>>>>    	if (new->cl_auth)
> >>>>>    		atomic_inc(&new->cl_auth->au_count);
> >>>>>    	atomic_inc(&clnt->cl_count);
> >>>>>
> >>>>> --
> >>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> >>>>> the body of a message to majordomo@vger.kernel.org
> >>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >>>> Acked-by: Jeff Layton <jlayton@redhat.com>
> >>> OK, colour me confused (again).
> >>
> >> What color?
> >>
> >>> Why should a umount trigger an
> >>> rpc_create() or rpc_clone_client()?
> >>
> >> It calls nsm_create().
> >> Here is the trace (https://bugzilla.redhat.com/show_bug.cgi?id=830862,
> >> comment 68):
> >
> > Right, but if we're using NFSv3 lock monitoring, we know in advance that
> > we're going to need an nsm call to localhost. Why can't we just cache
> > the one that we used to start lock monitoring in the first place?
> >
> 
> Do you suggest to cache the call or the client for the call?

Hi Stanislav,

Sorry, I agree that the above was unclear. My intention was to suggest
that we should cache a reference to the rpc client that we used to
connect to rpc.statd when initiating lock monitoring.

Basically, I'm suggesting that we should do something similar to the
rpcbind rpc_client caching scheme in net/sunrpc/rpcb_clnt.c.

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
@ 2012-09-10 15:27             ` Myklebust, Trond
  0 siblings, 0 replies; 17+ messages in thread
From: Myklebust, Trond @ 2012-09-10 15:27 UTC (permalink / raw)
  To: Stanislav Kinsbursky; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

T24gTW9uLCAyMDEyLTA5LTEwIGF0IDEyOjQzICswNDAwLCBTdGFuaXNsYXYgS2luc2J1cnNreSB3
cm90ZToNCj4gMDguMDkuMjAxMiAxODozMywgTXlrbGVidXN0LCBUcm9uZCDQv9C40YjQtdGCOg0K
PiA+IE9uIFNhdCwgMjAxMi0wOS0wOCBhdCAwODo1OSArMDMwMCwgU3RhbmlzbGF2IEtpbnNidXJz
a3kgd3JvdGU6DQo+ID4+IDA4LjA5LjIwMTIgMDE6MzIsIE15a2xlYnVzdCwgVHJvbmQg0L/QuNGI
0LXRgjoNCj4gPj4+IE9uIE1vbiwgMjAxMi0wOC0xMyBhdCAwODoxMCAtMDQwMCwgSmVmZiBMYXl0
b24gd3JvdGU6DQo+ID4+Pj4gT24gTW9uLCAxMyBBdWcgMjAxMiAxNTozNzozMSArMDQwMA0KPiA+
Pj4+IFN0YW5pc2xhdiBLaW5zYnVyc2t5IDxza2luc2J1cnNreUBwYXJhbGxlbHMuY29tPiB3cm90
ZToNCj4gPj4+Pg0KPiA+Pj4+PiB2MjoNCj4gPj4+Pj4gMSkgcnBjX2NsbnRfc2V0X25vZGVuYW1l
KCkgcHJvdG90eXBlIHVwZGF0ZWQuDQo+ID4+Pj4+IDIpIGZpeGVkIGVycm9ycyBpbiBjb21tZW50
Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBXaGVuIGNoaWxkIHJlYXBlciBleGl0cywgaXQgY2FuIGRlc3Ry
b3kgbW91bnQgbmFtZXNwYWNlIGl0IGJlbG9uZ3MgdG8sIGFuZCBpZg0KPiA+Pj4+PiB0aGVyZSBh
cmUgTkZTIG1vdW50cyBpbnNpZGUsIHRoZW4gaXQgd2lsbCB0cnkgdG8gdW1vdW50IHRoZW0uIEJ1
dCBpbiB0aGlzDQo+ID4+Pj4+IHBvaW50IGN1cnJlbnQtPm5zcHJveHkgaXMgc2V0IHRvIE5VTEwg
YW5kIGFsbCBuYW1lc3BhY2VzIHdpbGwgYmUgZGVzdHJveWVkIG9uZQ0KPiA+Pj4+PiBieSBvbmUu
IEkuZS4gd2UgY2FuJ3QgZGVyZWZlcmVuY2UgY3VycmVudC0+bnNwcm94eSB0byBvYnRhaW4gdXRz
IG5hbWVzcGFjZS4NCj4gPj4+Pj4NCj4gPj4+Pj4gU2lnbmVkLW9mZi1ieTogU3RhbmlzbGF2IEtp
bnNidXJza3kgPHNraW5zYnVyc2t5QHBhcmFsbGVscy5jb20+DQo+ID4+Pj4+IC0tLQ0KPiA+Pj4+
PiAgICBuZXQvc3VucnBjL2NsbnQuYyB8ICAgMTYgKysrKysrKysrKysrKy0tLQ0KPiA+Pj4+PiAg
ICAxIGZpbGVzIGNoYW5nZWQsIDEzIGluc2VydGlvbnMoKyksIDMgZGVsZXRpb25zKC0pDQo+ID4+
Pj4+DQo+ID4+Pj4+IGRpZmYgLS1naXQgYS9uZXQvc3VucnBjL2NsbnQuYyBiL25ldC9zdW5ycGMv
Y2xudC5jDQo+ID4+Pj4+IGluZGV4IDlhOTY3NmUuLjhmYmNiYzggMTAwNjQ0DQo+ID4+Pj4+IC0t
LSBhL25ldC9zdW5ycGMvY2xudC5jDQo+ID4+Pj4+ICsrKyBiL25ldC9zdW5ycGMvY2xudC5jDQo+
ID4+Pj4+IEBAIC0yNzcsOCArMjc3LDE4IEBAIHZvaWQgcnBjX2NsaWVudHNfbm90aWZpZXJfdW5y
ZWdpc3Rlcih2b2lkKQ0KPiA+Pj4+PiAgICAJcmV0dXJuIHJwY19waXBlZnNfbm90aWZpZXJfdW5y
ZWdpc3RlcigmcnBjX2NsaWVudHNfYmxvY2spOw0KPiA+Pj4+PiAgICB9DQo+ID4+Pj4+DQo+ID4+
Pj4+IC1zdGF0aWMgdm9pZCBycGNfY2xudF9zZXRfbm9kZW5hbWUoc3RydWN0IHJwY19jbG50ICpj
bG50LCBjb25zdCBjaGFyICpub2RlbmFtZSkNCj4gPj4+Pj4gK3N0YXRpYyB2b2lkIHJwY19jbG50
X3NldF9ub2RlbmFtZShzdHJ1Y3QgcnBjX2NsbnQgKmNsbnQpDQo+ID4+Pj4+ICAgIHsNCj4gPj4+
Pj4gKwljb25zdCBjaGFyICpub2RlbmFtZTsNCj4gPj4+Pj4gKw0KPiA+Pj4+PiArCS8qDQo+ID4+
Pj4+ICsJICogV2UgaGF2ZSB0byBwcm90ZWN0IGFnYWluc3QgZHlpbmcgY2hpbGQgcmVhcGVyLCB3
aGljaCBoYXMgcmVsZWFzZWQNCj4gPj4+Pj4gKwkgKiBpdHMgbnNwcm94eSBhbHJlYWR5IGFuZCBp
cyB0cnlpbmcgdG8gZGVzdHJveSBtb3VudCBuYW1lc3BhY2UuDQo+ID4+Pj4+ICsJICovDQo+ID4+
Pj4+ICsJaWYgKGN1cnJlbnQtPm5zcHJveHkgPT0gTlVMTCkNCj4gPj4+Pj4gKwkJcmV0dXJuOw0K
PiA+Pj4+PiArDQo+ID4+Pj4+ICsJbm9kZW5hbWUgPSB1dHNuYW1lKCktPm5vZGVuYW1lOw0KPiA+
Pj4+PiAgICAJY2xudC0+Y2xfbm9kZWxlbiA9IHN0cmxlbihub2RlbmFtZSk7DQo+ID4+Pj4+ICAg
IAlpZiAoY2xudC0+Y2xfbm9kZWxlbiA+IFVOWF9NQVhOT0RFTkFNRSkNCj4gPj4+Pj4gICAgCQlj
bG50LT5jbF9ub2RlbGVuID0gVU5YX01BWE5PREVOQU1FOw0KPiA+Pj4+PiBAQCAtMzY1LDcgKzM3
NSw3IEBAIHN0YXRpYyBzdHJ1Y3QgcnBjX2NsbnQgKiBycGNfbmV3X2NsaWVudChjb25zdCBzdHJ1
Y3QgcnBjX2NyZWF0ZV9hcmdzICphcmdzLCBzdHJ1DQo+ID4+Pj4+ICAgIAl9DQo+ID4+Pj4+DQo+
ID4+Pj4+ICAgIAkvKiBzYXZlIHRoZSBub2RlbmFtZSAqLw0KPiA+Pj4+PiAtCXJwY19jbG50X3Nl
dF9ub2RlbmFtZShjbG50LCB1dHNuYW1lKCktPm5vZGVuYW1lKTsNCj4gPj4+Pj4gKwlycGNfY2xu
dF9zZXRfbm9kZW5hbWUoY2xudCk7DQo+ID4+Pj4+ICAgIAlycGNfcmVnaXN0ZXJfY2xpZW50KGNs
bnQpOw0KPiA+Pj4+PiAgICAJcmV0dXJuIGNsbnQ7DQo+ID4+Pj4+DQo+ID4+Pj4+IEBAIC01MjQs
NyArNTM0LDcgQEAgcnBjX2Nsb25lX2NsaWVudChzdHJ1Y3QgcnBjX2NsbnQgKmNsbnQpDQo+ID4+
Pj4+ICAgIAllcnIgPSBycGNfc2V0dXBfcGlwZWRpcihuZXcsIGNsbnQtPmNsX3Byb2dyYW0tPnBp
cGVfZGlyX25hbWUpOw0KPiA+Pj4+PiAgICAJaWYgKGVyciAhPSAwKQ0KPiA+Pj4+PiAgICAJCWdv
dG8gb3V0X25vX3BhdGg7DQo+ID4+Pj4+IC0JcnBjX2NsbnRfc2V0X25vZGVuYW1lKG5ldywgdXRz
bmFtZSgpLT5ub2RlbmFtZSk7DQo+ID4+Pj4+ICsJcnBjX2NsbnRfc2V0X25vZGVuYW1lKG5ldyk7
DQo+ID4+Pj4+ICAgIAlpZiAobmV3LT5jbF9hdXRoKQ0KPiA+Pj4+PiAgICAJCWF0b21pY19pbmMo
Jm5ldy0+Y2xfYXV0aC0+YXVfY291bnQpOw0KPiA+Pj4+PiAgICAJYXRvbWljX2luYygmY2xudC0+
Y2xfY291bnQpOw0KPiA+Pj4+Pg0KPiA+Pj4+PiAtLQ0KPiA+Pj4+PiBUbyB1bnN1YnNjcmliZSBm
cm9tIHRoaXMgbGlzdDogc2VuZCB0aGUgbGluZSAidW5zdWJzY3JpYmUgbGludXgtbmZzIiBpbg0K
PiA+Pj4+PiB0aGUgYm9keSBvZiBhIG1lc3NhZ2UgdG8gbWFqb3Jkb21vQHZnZXIua2VybmVsLm9y
Zw0KPiA+Pj4+PiBNb3JlIG1ham9yZG9tbyBpbmZvIGF0ICBodHRwOi8vdmdlci5rZXJuZWwub3Jn
L21ham9yZG9tby1pbmZvLmh0bWwNCj4gPj4+PiBBY2tlZC1ieTogSmVmZiBMYXl0b24gPGpsYXl0
b25AcmVkaGF0LmNvbT4NCj4gPj4+IE9LLCBjb2xvdXIgbWUgY29uZnVzZWQgKGFnYWluKS4NCj4g
Pj4NCj4gPj4gV2hhdCBjb2xvcj8NCj4gPj4NCj4gPj4+IFdoeSBzaG91bGQgYSB1bW91bnQgdHJp
Z2dlciBhbg0KPiA+Pj4gcnBjX2NyZWF0ZSgpIG9yIHJwY19jbG9uZV9jbGllbnQoKT8NCj4gPj4N
Cj4gPj4gSXQgY2FsbHMgbnNtX2NyZWF0ZSgpLg0KPiA+PiBIZXJlIGlzIHRoZSB0cmFjZSAoaHR0
cHM6Ly9idWd6aWxsYS5yZWRoYXQuY29tL3Nob3dfYnVnLmNnaT9pZD04MzA4NjIsDQo+ID4+IGNv
bW1lbnQgNjgpOg0KPiA+DQo+ID4gUmlnaHQsIGJ1dCBpZiB3ZSdyZSB1c2luZyBORlN2MyBsb2Nr
IG1vbml0b3JpbmcsIHdlIGtub3cgaW4gYWR2YW5jZSB0aGF0DQo+ID4gd2UncmUgZ29pbmcgdG8g
bmVlZCBhbiBuc20gY2FsbCB0byBsb2NhbGhvc3QuIFdoeSBjYW4ndCB3ZSBqdXN0IGNhY2hlDQo+
ID4gdGhlIG9uZSB0aGF0IHdlIHVzZWQgdG8gc3RhcnQgbG9jayBtb25pdG9yaW5nIGluIHRoZSBm
aXJzdCBwbGFjZT8NCj4gPg0KPiANCj4gRG8geW91IHN1Z2dlc3QgdG8gY2FjaGUgdGhlIGNhbGwg
b3IgdGhlIGNsaWVudCBmb3IgdGhlIGNhbGw/DQoNCkhpIFN0YW5pc2xhdiwNCg0KU29ycnksIEkg
YWdyZWUgdGhhdCB0aGUgYWJvdmUgd2FzIHVuY2xlYXIuIE15IGludGVudGlvbiB3YXMgdG8gc3Vn
Z2VzdA0KdGhhdCB3ZSBzaG91bGQgY2FjaGUgYSByZWZlcmVuY2UgdG8gdGhlIHJwYyBjbGllbnQg
dGhhdCB3ZSB1c2VkIHRvDQpjb25uZWN0IHRvIHJwYy5zdGF0ZCB3aGVuIGluaXRpYXRpbmcgbG9j
ayBtb25pdG9yaW5nLg0KDQpCYXNpY2FsbHksIEknbSBzdWdnZXN0aW5nIHRoYXQgd2Ugc2hvdWxk
IGRvIHNvbWV0aGluZyBzaW1pbGFyIHRvIHRoZQ0KcnBjYmluZCBycGNfY2xpZW50IGNhY2hpbmcg
c2NoZW1lIGluIG5ldC9zdW5ycGMvcnBjYl9jbG50LmMuDQoNCkNoZWVycw0KICBUcm9uZA0KDQot
LSANClRyb25kIE15a2xlYnVzdA0KTGludXggTkZTIGNsaWVudCBtYWludGFpbmVyDQoNCk5ldEFw
cA0KVHJvbmQuTXlrbGVidXN0QG5ldGFwcC5jb20NCnd3dy5uZXRhcHAuY29tDQoNCg==

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
  2012-09-10 15:27             ` Myklebust, Trond
  (?)
@ 2012-09-10 15:37             ` Stanislav Kinsbursky
  2012-09-10 15:41                 ` Myklebust, Trond
  -1 siblings, 1 reply; 17+ messages in thread
From: Stanislav Kinsbursky @ 2012-09-10 15:37 UTC (permalink / raw)
  To: Myklebust, Trond; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

10.09.2012 19:27, Myklebust, Trond пишет:
> On Mon, 2012-09-10 at 12:43 +0400, Stanislav Kinsbursky wrote:
>> 08.09.2012 18:33, Myklebust, Trond пишет:
>>> On Sat, 2012-09-08 at 08:59 +0300, Stanislav Kinsbursky wrote:
>>>> 08.09.2012 01:32, Myklebust, Trond пишет:
>>>>> On Mon, 2012-08-13 at 08:10 -0400, Jeff Layton wrote:
>>>>>> On Mon, 13 Aug 2012 15:37:31 +0400
>>>>>> Stanislav Kinsbursky <skinsbursky@parallels.com> wrote:
>>>>>>
>>>>>>> v2:
>>>>>>> 1) rpc_clnt_set_nodename() prototype updated.
>>>>>>> 2) fixed errors in comment.
>>>>>>>
>>>>>>> When child reaper exits, it can destroy mount namespace it belongs to, and if
>>>>>>> there are NFS mounts inside, then it will try to umount them. But in this
>>>>>>> point current->nsproxy is set to NULL and all namespaces will be destroyed one
>>>>>>> by one. I.e. we can't dereference current->nsproxy to obtain uts namespace.
>>>>>>>
>>>>>>> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
>>>>>>> ---
>>>>>>>     net/sunrpc/clnt.c |   16 +++++++++++++---
>>>>>>>     1 files changed, 13 insertions(+), 3 deletions(-)
>>>>>>>
>>>>>>> diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c
>>>>>>> index 9a9676e..8fbcbc8 100644
>>>>>>> --- a/net/sunrpc/clnt.c
>>>>>>> +++ b/net/sunrpc/clnt.c
>>>>>>> @@ -277,8 +277,18 @@ void rpc_clients_notifier_unregister(void)
>>>>>>>     	return rpc_pipefs_notifier_unregister(&rpc_clients_block);
>>>>>>>     }
>>>>>>>
>>>>>>> -static void rpc_clnt_set_nodename(struct rpc_clnt *clnt, const char *nodename)
>>>>>>> +static void rpc_clnt_set_nodename(struct rpc_clnt *clnt)
>>>>>>>     {
>>>>>>> +	const char *nodename;
>>>>>>> +
>>>>>>> +	/*
>>>>>>> +	 * We have to protect against dying child reaper, which has released
>>>>>>> +	 * its nsproxy already and is trying to destroy mount namespace.
>>>>>>> +	 */
>>>>>>> +	if (current->nsproxy == NULL)
>>>>>>> +		return;
>>>>>>> +
>>>>>>> +	nodename = utsname()->nodename;
>>>>>>>     	clnt->cl_nodelen = strlen(nodename);
>>>>>>>     	if (clnt->cl_nodelen > UNX_MAXNODENAME)
>>>>>>>     		clnt->cl_nodelen = UNX_MAXNODENAME;
>>>>>>> @@ -365,7 +375,7 @@ static struct rpc_clnt * rpc_new_client(const struct rpc_create_args *args, stru
>>>>>>>     	}
>>>>>>>
>>>>>>>     	/* save the nodename */
>>>>>>> -	rpc_clnt_set_nodename(clnt, utsname()->nodename);
>>>>>>> +	rpc_clnt_set_nodename(clnt);
>>>>>>>     	rpc_register_client(clnt);
>>>>>>>     	return clnt;
>>>>>>>
>>>>>>> @@ -524,7 +534,7 @@ rpc_clone_client(struct rpc_clnt *clnt)
>>>>>>>     	err = rpc_setup_pipedir(new, clnt->cl_program->pipe_dir_name);
>>>>>>>     	if (err != 0)
>>>>>>>     		goto out_no_path;
>>>>>>> -	rpc_clnt_set_nodename(new, utsname()->nodename);
>>>>>>> +	rpc_clnt_set_nodename(new);
>>>>>>>     	if (new->cl_auth)
>>>>>>>     		atomic_inc(&new->cl_auth->au_count);
>>>>>>>     	atomic_inc(&clnt->cl_count);
>>>>>>>
>>>>>>> --
>>>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>>> Acked-by: Jeff Layton <jlayton@redhat.com>
>>>>> OK, colour me confused (again).
>>>>
>>>> What color?
>>>>
>>>>> Why should a umount trigger an
>>>>> rpc_create() or rpc_clone_client()?
>>>>
>>>> It calls nsm_create().
>>>> Here is the trace (https://bugzilla.redhat.com/show_bug.cgi?id=830862,
>>>> comment 68):
>>>
>>> Right, but if we're using NFSv3 lock monitoring, we know in advance that
>>> we're going to need an nsm call to localhost. Why can't we just cache
>>> the one that we used to start lock monitoring in the first place?
>>>
>>
>> Do you suggest to cache the call or the client for the call?
>
> Hi Stanislav,
>
> Sorry, I agree that the above was unclear. My intention was to suggest
> that we should cache a reference to the rpc client that we used to
> connect to rpc.statd when initiating lock monitoring.
>
> Basically, I'm suggesting that we should do something similar to the
> rpcbind rpc_client caching scheme in net/sunrpc/rpcb_clnt.c.
>

Hi, Trond.
So, if I understand you right, we can create rpc client (or increase usage 
counter) on NSMPROC_MON call and destroy (or decrease usage counter) on 
NSMPROC_UNMON call.
Will this solution works?

> Cheers
>    Trond
>


-- 
Best regards,
Stanislav Kinsbursky

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
  2012-09-10 15:37             ` Stanislav Kinsbursky
@ 2012-09-10 15:41                 ` Myklebust, Trond
  0 siblings, 0 replies; 17+ messages in thread
From: Myklebust, Trond @ 2012-09-10 15:41 UTC (permalink / raw)
  To: Stanislav Kinsbursky; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 713 bytes --]

On Mon, 2012-09-10 at 19:37 +0400, Stanislav Kinsbursky wrote:
> Hi, Trond.
> So, if I understand you right, we can create rpc client (or increase usage 
> counter) on NSMPROC_MON call and destroy (or decrease usage counter) on 
> NSMPROC_UNMON call.
> Will this solution works?

The rpc client(s) will need to be per-net-namespace, which complicates
matters a little bit, but yes, creation at NSMPROC_MON, and destruction
at NSMPROC_UNMON should work.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
@ 2012-09-10 15:41                 ` Myklebust, Trond
  0 siblings, 0 replies; 17+ messages in thread
From: Myklebust, Trond @ 2012-09-10 15:41 UTC (permalink / raw)
  To: Stanislav Kinsbursky; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

T24gTW9uLCAyMDEyLTA5LTEwIGF0IDE5OjM3ICswNDAwLCBTdGFuaXNsYXYgS2luc2J1cnNreSB3
cm90ZToNCj4gSGksIFRyb25kLg0KPiBTbywgaWYgSSB1bmRlcnN0YW5kIHlvdSByaWdodCwgd2Ug
Y2FuIGNyZWF0ZSBycGMgY2xpZW50IChvciBpbmNyZWFzZSB1c2FnZSANCj4gY291bnRlcikgb24g
TlNNUFJPQ19NT04gY2FsbCBhbmQgZGVzdHJveSAob3IgZGVjcmVhc2UgdXNhZ2UgY291bnRlcikg
b24gDQo+IE5TTVBST0NfVU5NT04gY2FsbC4NCj4gV2lsbCB0aGlzIHNvbHV0aW9uIHdvcmtzPw0K
DQpUaGUgcnBjIGNsaWVudChzKSB3aWxsIG5lZWQgdG8gYmUgcGVyLW5ldC1uYW1lc3BhY2UsIHdo
aWNoIGNvbXBsaWNhdGVzDQptYXR0ZXJzIGEgbGl0dGxlIGJpdCwgYnV0IHllcywgY3JlYXRpb24g
YXQgTlNNUFJPQ19NT04sIGFuZCBkZXN0cnVjdGlvbg0KYXQgTlNNUFJPQ19VTk1PTiBzaG91bGQg
d29yay4NCg0KLS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5l
cg0KDQpOZXRBcHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0K
DQo=

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
  2012-09-10 15:41                 ` Myklebust, Trond
  (?)
@ 2012-09-10 15:55                 ` Stanislav Kinsbursky
  -1 siblings, 0 replies; 17+ messages in thread
From: Stanislav Kinsbursky @ 2012-09-10 15:55 UTC (permalink / raw)
  To: Myklebust, Trond; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

10.09.2012 19:41, Myklebust, Trond пишет:
> On Mon, 2012-09-10 at 19:37 +0400, Stanislav Kinsbursky wrote:
>> Hi, Trond.
>> So, if I understand you right, we can create rpc client (or increase usage
>> counter) on NSMPROC_MON call and destroy (or decrease usage counter) on
>> NSMPROC_UNMON call.
>> Will this solution works?
>
> The rpc client(s) will need to be per-net-namespace, which complicates
> matters a little bit, but yes, creation at NSMPROC_MON, and destruction
> at NSMPROC_UNMON should work.
>

Not really. We already have per-net Lockd data. So, adding one more 
reference-counted rpc client doesn't look that complicated.
Ok, thanks. I'll try to implement this.

-- 
Best regards,
Stanislav Kinsbursky

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
  2012-09-10 15:41                 ` Myklebust, Trond
  (?)
  (?)
@ 2012-09-13 12:11                 ` Stanislav Kinsbursky
  2012-09-13 13:30                     ` Myklebust, Trond
  -1 siblings, 1 reply; 17+ messages in thread
From: Stanislav Kinsbursky @ 2012-09-13 12:11 UTC (permalink / raw)
  To: Myklebust, Trond; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

10.09.2012 19:41, Myklebust, Trond пишет:
> On Mon, 2012-09-10 at 19:37 +0400, Stanislav Kinsbursky wrote:
>> Hi, Trond.
>> So, if I understand you right, we can create rpc client (or increase usage
>> counter) on NSMPROC_MON call and destroy (or decrease usage counter) on
>> NSMPROC_UNMON call.
>> Will this solution works?
>
> The rpc client(s) will need to be per-net-namespace, which complicates
> matters a little bit, but yes, creation at NSMPROC_MON, and destruction
> at NSMPROC_UNMON should work.
>

Hi, Trond.
With reference-counted NSM client I got this:

BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
IP: [<ffffffffa00c0d7f>] encode_mon_id+0x2e/0x64 [lockd]
PGD 0
Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
Modules linked in: nfsv3 nfs_acl nfs lockd veth sunrpc bridge stp llc i2c_piix4 
i2c_core virtio_blk virtio_net floppy virtio_pci virtio_ring virtio
CPU 1
Pid: 1174, comm: bash Not tainted 3.5.0-kitchensink+ #44 Bochs Bochs
RIP: 0010:[<ffffffffa00c0d7f>]  [<ffffffffa00c0d7f>] encode_mon_id+0x2e/0x64 [lockd]
RSP: 0018:ffff88001d0f1a08  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88001d0f1c38 RCX: 0000000000000000
RDX: ffff88001c85803f RSI: ffff88001d23b204 RDI: ffff88001d0f1a48
RBP: ffff88001d0f1a18 R08: ffff88001c858040 R09: 0000000000000003
R10: ffff88001a5aba10 R11: ffff88001d0f1ac8 R12: ffff88001d0f1a48
R13: ffff88001a8a3138 R14: ffffffffa008d580 R15: ffffffffa00c0db5
FS:  00007f0d60eea700(0000) GS:ffff88001f700000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000000000008 CR3: 000000001db3d000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process bash (pid: 1174, threadinfo ffff88001d0f0000, task ffff88001d1f4160)
Stack:
  ffff88001d0f1a48 ffff88001c858030 ffff88001d0f1a28 ffffffffa00c0dc9
  ffff88001d0f1ab8 ffffffffa00731a0 ffff88001a5aba10 ffff88001d0f1c38
  ffff88001c858040 ffff88001a8a3140 ffff88001c858854 ffff88001a8a3140
Call Trace:
  [<ffffffffa00c0dc9>] nsm_xdr_enc_unmon+0x14/0x16 [lockd]
  [<ffffffffa00731a0>] rpcauth_wrap_req+0xa1/0xb2 [sunrpc]
  [<ffffffffa006b83f>] ? xprt_prepare_transmit+0x83/0x93 [sunrpc]
  [<ffffffffa0068e54>] call_transmit+0x1e4/0x263 [sunrpc]
  [<ffffffffa00728e2>] __rpc_execute+0xe7/0x313 [sunrpc]
  [<ffffffffa0068c70>] ? call_transmit_status+0xb8/0xb8 [sunrpc]
  [<ffffffff81055ed9>] ? wake_up_bit+0x25/0x2a
  [<ffffffffa0072be0>] rpc_execute+0x9d/0xa5 [sunrpc]
  [<ffffffffa006a6ae>] rpc_run_task+0x7e/0x86 [sunrpc]
  [<ffffffffa006a7a3>] rpc_call_sync+0x44/0x65 [sunrpc]
  [<ffffffffa00c0883>] nsm_mon_unmon+0x81/0xad [lockd]
  [<ffffffffa00c0931>] nsm_unmonitor+0x82/0x13a [lockd]
  [<ffffffffa00bc251>] nlm_destroy_host_locked+0x93/0xc9 [lockd]
  [<ffffffffa00bc33a>] nlmclnt_release_host+0xb3/0xc3 [lockd]
  [<ffffffffa00ba09f>] nlmclnt_done+0x1a/0x26 [lockd]
  [<ffffffffa00d583e>] nfs_destroy_server+0x24/0x26 [nfs]
  [<ffffffffa00d5d85>] nfs_free_server+0xad/0x134 [nfs]
  [<ffffffffa00dd5ff>] nfs_kill_super+0x22/0x26 [nfs]
  [<ffffffff8112b278>] deactivate_locked_super+0x26/0x57
  [<ffffffff8112bd89>] deactivate_super+0x45/0x4c
  [<ffffffff811423ec>] mntput_no_expire+0x110/0x119
  [<ffffffff8114241f>] mntput+0x2a/0x2c
  [<ffffffff81142605>] release_mounts+0x72/0x84
  [<ffffffff811427cf>] put_mnt_ns+0x6f/0x7e
  [<ffffffff8105a3db>] free_nsproxy+0x1f/0x87
  [<ffffffff8105a49f>] switch_task_namespaces+0x5c/0x65
  [<ffffffff8105a4b8>] exit_task_namespaces+0x10/0x12
  [<ffffffff8103c232>] do_exit+0x69b/0x84f
  [<ffffffff8103c469>] do_group_exit+0x83/0xae
  [<ffffffff8103c4ab>] sys_exit_group+0x17/0x1b
  [<ffffffff814657e9>] system_call_fastpath+0x16/0x1b
Code: e5 41 54 53 66 66 66 66 90 48 89 f3 49 89 fc 48 8b 76 18 e8 93 ff ff ff 4c 
89 e7 65 48 8b 04 25 c0 b9 00 00 48 8b 80 00 05 00 00 <48> 8b 70 08 48 83 c6 45 
e8 73 ff ff ff 4c 89 e7 be 0c 00 00 00
RIP  [<ffffffffa00c0d7f>] encode_mon_id+0x2e/0x64 [lockd]


There are more places, where NFS and Lockd code dereference utsname().
In XDR layer, for instance.

So, probably, we have to tie NFS to utsns as well as to netns.
Add one more ns to xprt? What do you think?

-- 
Best regards,
Stanislav Kinsbursky

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
  2012-09-13 12:11                 ` Stanislav Kinsbursky
@ 2012-09-13 13:30                     ` Myklebust, Trond
  0 siblings, 0 replies; 17+ messages in thread
From: Myklebust, Trond @ 2012-09-13 13:30 UTC (permalink / raw)
  To: Stanislav Kinsbursky; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="utf-8", Size: 4840 bytes --]

On Thu, 2012-09-13 at 16:11 +0400, Stanislav Kinsbursky wrote:
> 10.09.2012 19:41, Myklebust, Trond пишет:
> > On Mon, 2012-09-10 at 19:37 +0400, Stanislav Kinsbursky wrote:
> >> Hi, Trond.
> >> So, if I understand you right, we can create rpc client (or increase usage
> >> counter) on NSMPROC_MON call and destroy (or decrease usage counter) on
> >> NSMPROC_UNMON call.
> >> Will this solution works?
> >
> > The rpc client(s) will need to be per-net-namespace, which complicates
> > matters a little bit, but yes, creation at NSMPROC_MON, and destruction
> > at NSMPROC_UNMON should work.
> >
> 
> Hi, Trond.
> With reference-counted NSM client I got this:
> 
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> IP: [<ffffffffa00c0d7f>] encode_mon_id+0x2e/0x64 [lockd]
> PGD 0
> Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
> Modules linked in: nfsv3 nfs_acl nfs lockd veth sunrpc bridge stp llc i2c_piix4 
> i2c_core virtio_blk virtio_net floppy virtio_pci virtio_ring virtio
> CPU 1
> Pid: 1174, comm: bash Not tainted 3.5.0-kitchensink+ #44 Bochs Bochs
> RIP: 0010:[<ffffffffa00c0d7f>]  [<ffffffffa00c0d7f>] encode_mon_id+0x2e/0x64 [lockd]
> RSP: 0018:ffff88001d0f1a08  EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffff88001d0f1c38 RCX: 0000000000000000
> RDX: ffff88001c85803f RSI: ffff88001d23b204 RDI: ffff88001d0f1a48
> RBP: ffff88001d0f1a18 R08: ffff88001c858040 R09: 0000000000000003
> R10: ffff88001a5aba10 R11: ffff88001d0f1ac8 R12: ffff88001d0f1a48
> R13: ffff88001a8a3138 R14: ffffffffa008d580 R15: ffffffffa00c0db5
> FS:  00007f0d60eea700(0000) GS:ffff88001f700000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000008 CR3: 000000001db3d000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process bash (pid: 1174, threadinfo ffff88001d0f0000, task ffff88001d1f4160)
> Stack:
>   ffff88001d0f1a48 ffff88001c858030 ffff88001d0f1a28 ffffffffa00c0dc9
>   ffff88001d0f1ab8 ffffffffa00731a0 ffff88001a5aba10 ffff88001d0f1c38
>   ffff88001c858040 ffff88001a8a3140 ffff88001c858854 ffff88001a8a3140
> Call Trace:
>   [<ffffffffa00c0dc9>] nsm_xdr_enc_unmon+0x14/0x16 [lockd]
>   [<ffffffffa00731a0>] rpcauth_wrap_req+0xa1/0xb2 [sunrpc]
>   [<ffffffffa006b83f>] ? xprt_prepare_transmit+0x83/0x93 [sunrpc]
>   [<ffffffffa0068e54>] call_transmit+0x1e4/0x263 [sunrpc]
>   [<ffffffffa00728e2>] __rpc_execute+0xe7/0x313 [sunrpc]
>   [<ffffffffa0068c70>] ? call_transmit_status+0xb8/0xb8 [sunrpc]
>   [<ffffffff81055ed9>] ? wake_up_bit+0x25/0x2a
>   [<ffffffffa0072be0>] rpc_execute+0x9d/0xa5 [sunrpc]
>   [<ffffffffa006a6ae>] rpc_run_task+0x7e/0x86 [sunrpc]
>   [<ffffffffa006a7a3>] rpc_call_sync+0x44/0x65 [sunrpc]
>   [<ffffffffa00c0883>] nsm_mon_unmon+0x81/0xad [lockd]
>   [<ffffffffa00c0931>] nsm_unmonitor+0x82/0x13a [lockd]
>   [<ffffffffa00bc251>] nlm_destroy_host_locked+0x93/0xc9 [lockd]
>   [<ffffffffa00bc33a>] nlmclnt_release_host+0xb3/0xc3 [lockd]
>   [<ffffffffa00ba09f>] nlmclnt_done+0x1a/0x26 [lockd]
>   [<ffffffffa00d583e>] nfs_destroy_server+0x24/0x26 [nfs]
>   [<ffffffffa00d5d85>] nfs_free_server+0xad/0x134 [nfs]
>   [<ffffffffa00dd5ff>] nfs_kill_super+0x22/0x26 [nfs]
>   [<ffffffff8112b278>] deactivate_locked_super+0x26/0x57
>   [<ffffffff8112bd89>] deactivate_super+0x45/0x4c
>   [<ffffffff811423ec>] mntput_no_expire+0x110/0x119
>   [<ffffffff8114241f>] mntput+0x2a/0x2c
>   [<ffffffff81142605>] release_mounts+0x72/0x84
>   [<ffffffff811427cf>] put_mnt_ns+0x6f/0x7e
>   [<ffffffff8105a3db>] free_nsproxy+0x1f/0x87
>   [<ffffffff8105a49f>] switch_task_namespaces+0x5c/0x65
>   [<ffffffff8105a4b8>] exit_task_namespaces+0x10/0x12
>   [<ffffffff8103c232>] do_exit+0x69b/0x84f
>   [<ffffffff8103c469>] do_group_exit+0x83/0xae
>   [<ffffffff8103c4ab>] sys_exit_group+0x17/0x1b
>   [<ffffffff814657e9>] system_call_fastpath+0x16/0x1b
> Code: e5 41 54 53 66 66 66 66 90 48 89 f3 49 89 fc 48 8b 76 18 e8 93 ff ff ff 4c 
> 89 e7 65 48 8b 04 25 c0 b9 00 00 48 8b 80 00 05 00 00 <48> 8b 70 08 48 83 c6 45 
> e8 73 ff ff ff 4c 89 e7 be 0c 00 00 00
> RIP  [<ffffffffa00c0d7f>] encode_mon_id+0x2e/0x64 [lockd]
> 
> 
> There are more places, where NFS and Lockd code dereference utsname().
> In XDR layer, for instance.
> 
> So, probably, we have to tie NFS to utsns as well as to netns.
> Add one more ns to xprt? What do you think?
> 

We've already saved the utsname in the rpc_client as clnt->cl_nodename.
All XDR users can be trivially converted to use that.

Cheers
  Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com
ÿôèº{.nÇ+‰·Ÿ®‰­†+%ŠËÿ±éݶ\x17¥Šwÿº{.nÇ+‰·¥Š{±þG«éÿŠ{ayº\x1dʇڙë,j\a­¢f£¢·hšïêÿ‘êçz_è®\x03(­éšŽŠÝ¢j"ú\x1a¶^[m§ÿÿ¾\a«þG«éÿ¢¸?™¨è­Ú&£ø§~á¶iO•æ¬z·švØ^\x14\x04\x1a¶^[m§ÿÿÃ\fÿ¶ìÿ¢¸?–I¥

^ permalink raw reply	[flat|nested] 17+ messages in thread

* Re: [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation
@ 2012-09-13 13:30                     ` Myklebust, Trond
  0 siblings, 0 replies; 17+ messages in thread
From: Myklebust, Trond @ 2012-09-13 13:30 UTC (permalink / raw)
  To: Stanislav Kinsbursky; +Cc: Jeff Layton, bfields, linux-nfs, linux-kernel, devel

T24gVGh1LCAyMDEyLTA5LTEzIGF0IDE2OjExICswNDAwLCBTdGFuaXNsYXYgS2luc2J1cnNreSB3
cm90ZToNCj4gMTAuMDkuMjAxMiAxOTo0MSwgTXlrbGVidXN0LCBUcm9uZCDQv9C40YjQtdGCOg0K
PiA+IE9uIE1vbiwgMjAxMi0wOS0xMCBhdCAxOTozNyArMDQwMCwgU3RhbmlzbGF2IEtpbnNidXJz
a3kgd3JvdGU6DQo+ID4+IEhpLCBUcm9uZC4NCj4gPj4gU28sIGlmIEkgdW5kZXJzdGFuZCB5b3Ug
cmlnaHQsIHdlIGNhbiBjcmVhdGUgcnBjIGNsaWVudCAob3IgaW5jcmVhc2UgdXNhZ2UNCj4gPj4g
Y291bnRlcikgb24gTlNNUFJPQ19NT04gY2FsbCBhbmQgZGVzdHJveSAob3IgZGVjcmVhc2UgdXNh
Z2UgY291bnRlcikgb24NCj4gPj4gTlNNUFJPQ19VTk1PTiBjYWxsLg0KPiA+PiBXaWxsIHRoaXMg
c29sdXRpb24gd29ya3M/DQo+ID4NCj4gPiBUaGUgcnBjIGNsaWVudChzKSB3aWxsIG5lZWQgdG8g
YmUgcGVyLW5ldC1uYW1lc3BhY2UsIHdoaWNoIGNvbXBsaWNhdGVzDQo+ID4gbWF0dGVycyBhIGxp
dHRsZSBiaXQsIGJ1dCB5ZXMsIGNyZWF0aW9uIGF0IE5TTVBST0NfTU9OLCBhbmQgZGVzdHJ1Y3Rp
b24NCj4gPiBhdCBOU01QUk9DX1VOTU9OIHNob3VsZCB3b3JrLg0KPiA+DQo+IA0KPiBIaSwgVHJv
bmQuDQo+IFdpdGggcmVmZXJlbmNlLWNvdW50ZWQgTlNNIGNsaWVudCBJIGdvdCB0aGlzOg0KPiAN
Cj4gQlVHOiB1bmFibGUgdG8gaGFuZGxlIGtlcm5lbCBOVUxMIHBvaW50ZXIgZGVyZWZlcmVuY2Ug
YXQgMDAwMDAwMDAwMDAwMDAwOA0KPiBJUDogWzxmZmZmZmZmZmEwMGMwZDdmPl0gZW5jb2RlX21v
bl9pZCsweDJlLzB4NjQgW2xvY2tkXQ0KPiBQR0QgMA0KPiBPb3BzOiAwMDAwIFsjMV0gU01QIERF
QlVHX1BBR0VBTExPQw0KPiBNb2R1bGVzIGxpbmtlZCBpbjogbmZzdjMgbmZzX2FjbCBuZnMgbG9j
a2QgdmV0aCBzdW5ycGMgYnJpZGdlIHN0cCBsbGMgaTJjX3BpaXg0IA0KPiBpMmNfY29yZSB2aXJ0
aW9fYmxrIHZpcnRpb19uZXQgZmxvcHB5IHZpcnRpb19wY2kgdmlydGlvX3JpbmcgdmlydGlvDQo+
IENQVSAxDQo+IFBpZDogMTE3NCwgY29tbTogYmFzaCBOb3QgdGFpbnRlZCAzLjUuMC1raXRjaGVu
c2luaysgIzQ0IEJvY2hzIEJvY2hzDQo+IFJJUDogMDAxMDpbPGZmZmZmZmZmYTAwYzBkN2Y+XSAg
WzxmZmZmZmZmZmEwMGMwZDdmPl0gZW5jb2RlX21vbl9pZCsweDJlLzB4NjQgW2xvY2tkXQ0KPiBS
U1A6IDAwMTg6ZmZmZjg4MDAxZDBmMWEwOCAgRUZMQUdTOiAwMDAxMDI0Ng0KPiBSQVg6IDAwMDAw
MDAwMDAwMDAwMDAgUkJYOiBmZmZmODgwMDFkMGYxYzM4IFJDWDogMDAwMDAwMDAwMDAwMDAwMA0K
PiBSRFg6IGZmZmY4ODAwMWM4NTgwM2YgUlNJOiBmZmZmODgwMDFkMjNiMjA0IFJESTogZmZmZjg4
MDAxZDBmMWE0OA0KPiBSQlA6IGZmZmY4ODAwMWQwZjFhMTggUjA4OiBmZmZmODgwMDFjODU4MDQw
IFIwOTogMDAwMDAwMDAwMDAwMDAwMw0KPiBSMTA6IGZmZmY4ODAwMWE1YWJhMTAgUjExOiBmZmZm
ODgwMDFkMGYxYWM4IFIxMjogZmZmZjg4MDAxZDBmMWE0OA0KPiBSMTM6IGZmZmY4ODAwMWE4YTMx
MzggUjE0OiBmZmZmZmZmZmEwMDhkNTgwIFIxNTogZmZmZmZmZmZhMDBjMGRiNQ0KPiBGUzogIDAw
MDA3ZjBkNjBlZWE3MDAoMDAwMCkgR1M6ZmZmZjg4MDAxZjcwMDAwMCgwMDAwKSBrbmxHUzowMDAw
MDAwMDAwMDAwMDAwDQo+IENTOiAgMDAxMCBEUzogMDAwMCBFUzogMDAwMCBDUjA6IDAwMDAwMDAw
ODAwNTAwM2INCj4gQ1IyOiAwMDAwMDAwMDAwMDAwMDA4IENSMzogMDAwMDAwMDAxZGIzZDAwMCBD
UjQ6IDAwMDAwMDAwMDAwMDA2ZTANCj4gRFIwOiAwMDAwMDAwMDAwMDAwMDAwIERSMTogMDAwMDAw
MDAwMDAwMDAwMCBEUjI6IDAwMDAwMDAwMDAwMDAwMDANCj4gRFIzOiAwMDAwMDAwMDAwMDAwMDAw
IERSNjogMDAwMDAwMDBmZmZmMGZmMCBEUjc6IDAwMDAwMDAwMDAwMDA0MDANCj4gUHJvY2VzcyBi
YXNoIChwaWQ6IDExNzQsIHRocmVhZGluZm8gZmZmZjg4MDAxZDBmMDAwMCwgdGFzayBmZmZmODgw
MDFkMWY0MTYwKQ0KPiBTdGFjazoNCj4gICBmZmZmODgwMDFkMGYxYTQ4IGZmZmY4ODAwMWM4NTgw
MzAgZmZmZjg4MDAxZDBmMWEyOCBmZmZmZmZmZmEwMGMwZGM5DQo+ICAgZmZmZjg4MDAxZDBmMWFi
OCBmZmZmZmZmZmEwMDczMWEwIGZmZmY4ODAwMWE1YWJhMTAgZmZmZjg4MDAxZDBmMWMzOA0KPiAg
IGZmZmY4ODAwMWM4NTgwNDAgZmZmZjg4MDAxYThhMzE0MCBmZmZmODgwMDFjODU4ODU0IGZmZmY4
ODAwMWE4YTMxNDANCj4gQ2FsbCBUcmFjZToNCj4gICBbPGZmZmZmZmZmYTAwYzBkYzk+XSBuc21f
eGRyX2VuY191bm1vbisweDE0LzB4MTYgW2xvY2tkXQ0KPiAgIFs8ZmZmZmZmZmZhMDA3MzFhMD5d
IHJwY2F1dGhfd3JhcF9yZXErMHhhMS8weGIyIFtzdW5ycGNdDQo+ICAgWzxmZmZmZmZmZmEwMDZi
ODNmPl0gPyB4cHJ0X3ByZXBhcmVfdHJhbnNtaXQrMHg4My8weDkzIFtzdW5ycGNdDQo+ICAgWzxm
ZmZmZmZmZmEwMDY4ZTU0Pl0gY2FsbF90cmFuc21pdCsweDFlNC8weDI2MyBbc3VucnBjXQ0KPiAg
IFs8ZmZmZmZmZmZhMDA3MjhlMj5dIF9fcnBjX2V4ZWN1dGUrMHhlNy8weDMxMyBbc3VucnBjXQ0K
PiAgIFs8ZmZmZmZmZmZhMDA2OGM3MD5dID8gY2FsbF90cmFuc21pdF9zdGF0dXMrMHhiOC8weGI4
IFtzdW5ycGNdDQo+ICAgWzxmZmZmZmZmZjgxMDU1ZWQ5Pl0gPyB3YWtlX3VwX2JpdCsweDI1LzB4
MmENCj4gICBbPGZmZmZmZmZmYTAwNzJiZTA+XSBycGNfZXhlY3V0ZSsweDlkLzB4YTUgW3N1bnJw
Y10NCj4gICBbPGZmZmZmZmZmYTAwNmE2YWU+XSBycGNfcnVuX3Rhc2srMHg3ZS8weDg2IFtzdW5y
cGNdDQo+ICAgWzxmZmZmZmZmZmEwMDZhN2EzPl0gcnBjX2NhbGxfc3luYysweDQ0LzB4NjUgW3N1
bnJwY10NCj4gICBbPGZmZmZmZmZmYTAwYzA4ODM+XSBuc21fbW9uX3VubW9uKzB4ODEvMHhhZCBb
bG9ja2RdDQo+ICAgWzxmZmZmZmZmZmEwMGMwOTMxPl0gbnNtX3VubW9uaXRvcisweDgyLzB4MTNh
IFtsb2NrZF0NCj4gICBbPGZmZmZmZmZmYTAwYmMyNTE+XSBubG1fZGVzdHJveV9ob3N0X2xvY2tl
ZCsweDkzLzB4YzkgW2xvY2tkXQ0KPiAgIFs8ZmZmZmZmZmZhMDBiYzMzYT5dIG5sbWNsbnRfcmVs
ZWFzZV9ob3N0KzB4YjMvMHhjMyBbbG9ja2RdDQo+ICAgWzxmZmZmZmZmZmEwMGJhMDlmPl0gbmxt
Y2xudF9kb25lKzB4MWEvMHgyNiBbbG9ja2RdDQo+ICAgWzxmZmZmZmZmZmEwMGQ1ODNlPl0gbmZz
X2Rlc3Ryb3lfc2VydmVyKzB4MjQvMHgyNiBbbmZzXQ0KPiAgIFs8ZmZmZmZmZmZhMDBkNWQ4NT5d
IG5mc19mcmVlX3NlcnZlcisweGFkLzB4MTM0IFtuZnNdDQo+ICAgWzxmZmZmZmZmZmEwMGRkNWZm
Pl0gbmZzX2tpbGxfc3VwZXIrMHgyMi8weDI2IFtuZnNdDQo+ICAgWzxmZmZmZmZmZjgxMTJiMjc4
Pl0gZGVhY3RpdmF0ZV9sb2NrZWRfc3VwZXIrMHgyNi8weDU3DQo+ICAgWzxmZmZmZmZmZjgxMTJi
ZDg5Pl0gZGVhY3RpdmF0ZV9zdXBlcisweDQ1LzB4NGMNCj4gICBbPGZmZmZmZmZmODExNDIzZWM+
XSBtbnRwdXRfbm9fZXhwaXJlKzB4MTEwLzB4MTE5DQo+ICAgWzxmZmZmZmZmZjgxMTQyNDFmPl0g
bW50cHV0KzB4MmEvMHgyYw0KPiAgIFs8ZmZmZmZmZmY4MTE0MjYwNT5dIHJlbGVhc2VfbW91bnRz
KzB4NzIvMHg4NA0KPiAgIFs8ZmZmZmZmZmY4MTE0MjdjZj5dIHB1dF9tbnRfbnMrMHg2Zi8weDdl
DQo+ICAgWzxmZmZmZmZmZjgxMDVhM2RiPl0gZnJlZV9uc3Byb3h5KzB4MWYvMHg4Nw0KPiAgIFs8
ZmZmZmZmZmY4MTA1YTQ5Zj5dIHN3aXRjaF90YXNrX25hbWVzcGFjZXMrMHg1Yy8weDY1DQo+ICAg
WzxmZmZmZmZmZjgxMDVhNGI4Pl0gZXhpdF90YXNrX25hbWVzcGFjZXMrMHgxMC8weDEyDQo+ICAg
WzxmZmZmZmZmZjgxMDNjMjMyPl0gZG9fZXhpdCsweDY5Yi8weDg0Zg0KPiAgIFs8ZmZmZmZmZmY4
MTAzYzQ2OT5dIGRvX2dyb3VwX2V4aXQrMHg4My8weGFlDQo+ICAgWzxmZmZmZmZmZjgxMDNjNGFi
Pl0gc3lzX2V4aXRfZ3JvdXArMHgxNy8weDFiDQo+ICAgWzxmZmZmZmZmZjgxNDY1N2U5Pl0gc3lz
dGVtX2NhbGxfZmFzdHBhdGgrMHgxNi8weDFiDQo+IENvZGU6IGU1IDQxIDU0IDUzIDY2IDY2IDY2
IDY2IDkwIDQ4IDg5IGYzIDQ5IDg5IGZjIDQ4IDhiIDc2IDE4IGU4IDkzIGZmIGZmIGZmIDRjIA0K
PiA4OSBlNyA2NSA0OCA4YiAwNCAyNSBjMCBiOSAwMCAwMCA0OCA4YiA4MCAwMCAwNSAwMCAwMCA8
NDg+IDhiIDcwIDA4IDQ4IDgzIGM2IDQ1IA0KPiBlOCA3MyBmZiBmZiBmZiA0YyA4OSBlNyBiZSAw
YyAwMCAwMCAwMA0KPiBSSVAgIFs8ZmZmZmZmZmZhMDBjMGQ3Zj5dIGVuY29kZV9tb25faWQrMHgy
ZS8weDY0IFtsb2NrZF0NCj4gDQo+IA0KPiBUaGVyZSBhcmUgbW9yZSBwbGFjZXMsIHdoZXJlIE5G
UyBhbmQgTG9ja2QgY29kZSBkZXJlZmVyZW5jZSB1dHNuYW1lKCkuDQo+IEluIFhEUiBsYXllciwg
Zm9yIGluc3RhbmNlLg0KPiANCj4gU28sIHByb2JhYmx5LCB3ZSBoYXZlIHRvIHRpZSBORlMgdG8g
dXRzbnMgYXMgd2VsbCBhcyB0byBuZXRucy4NCj4gQWRkIG9uZSBtb3JlIG5zIHRvIHhwcnQ/IFdo
YXQgZG8geW91IHRoaW5rPw0KPiANCg0KV2UndmUgYWxyZWFkeSBzYXZlZCB0aGUgdXRzbmFtZSBp
biB0aGUgcnBjX2NsaWVudCBhcyBjbG50LT5jbF9ub2RlbmFtZS4NCkFsbCBYRFIgdXNlcnMgY2Fu
IGJlIHRyaXZpYWxseSBjb252ZXJ0ZWQgdG8gdXNlIHRoYXQuDQoNCkNoZWVycw0KICBUcm9uZA0K
LS0gDQpUcm9uZCBNeWtsZWJ1c3QNCkxpbnV4IE5GUyBjbGllbnQgbWFpbnRhaW5lcg0KDQpOZXRB
cHANClRyb25kLk15a2xlYnVzdEBuZXRhcHAuY29tDQp3d3cubmV0YXBwLmNvbQ0K

^ permalink raw reply	[flat|nested] 17+ messages in thread

end of thread, other threads:[~2012-09-13 13:30 UTC | newest]

Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-13 11:37 [PATCH v2] SUNRPC: check current nsproxy before set of node name on client creation Stanislav Kinsbursky
2012-08-13 12:10 ` Jeff Layton
2012-09-07 22:32   ` Myklebust, Trond
2012-09-07 22:32     ` Myklebust, Trond
2012-09-08  5:59     ` Stanislav Kinsbursky
2012-09-08 14:33       ` Myklebust, Trond
2012-09-08 14:33         ` Myklebust, Trond
2012-09-10  8:43         ` Stanislav Kinsbursky
2012-09-10 15:27           ` Myklebust, Trond
2012-09-10 15:27             ` Myklebust, Trond
2012-09-10 15:37             ` Stanislav Kinsbursky
2012-09-10 15:41               ` Myklebust, Trond
2012-09-10 15:41                 ` Myklebust, Trond
2012-09-10 15:55                 ` Stanislav Kinsbursky
2012-09-13 12:11                 ` Stanislav Kinsbursky
2012-09-13 13:30                   ` Myklebust, Trond
2012-09-13 13:30                     ` Myklebust, Trond

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.