All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>,
	Cedric Le Goater <clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>,
	Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	Trond Myklebust
	<trond.myklebust-41N18TsMXrtuMpJDpNschA@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux Containers
	<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
	linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [RFC][PATCH] sunrpc: fix oops in rpc_create() when the mount namespace is unshared
Date: Tue, 09 Sep 2008 13:08:29 -0700	[thread overview]
Message-ID: <m17i9lm69u.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <869FF00C-4DAF-4D19-80AF-9230617A9223-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> (Chuck Lever's message of "Tue, 9 Sep 2008 15:00:55 -0400")

Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> writes:

> On Sep 9, 2008, at Sep 9, 2008, 2:20 PM, ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org wrote:
>> Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> writes:
>>
>>> If the upper layers are responsible for providing the utsname, you will need
>>> to
>>> fix up lockd and the NFS server's callback client too, at  least.
>>
>> Actually looking at the code.  It looks like a proper fix may be even simpler.
>> Why do we have both clnt->cl_server and clnt->cl_nodename?    Or is cl_server
>> the other side of the connection?
>
> cl_server is the server-side.  cl_nodename is the "machine name" of the client.

Thanks, Darn.  Looks like we need to capture both names at the same or a
similar point.

I'm wondering if we need to capture a network namespace as well.

>>> I don't like the idea of an oops in here.  Instead, (for now) it should warn
>>> and
>>> fail to create the client, IMO.
>>
>> Which is interesting when the problem happens during NFS unmount.  Although
>> frankly it could fail anyway.
>>
>> It seems strange that we are creating a client during unmount anyway.
>
> It's worth investigating.  Just enable RPC tracing (/usr/sbin/rpcdebug -m rpc -s
> all) before shutting down the client.
>
> NFS unmounting is historically difficult because during a system shutdown,
> unmounting is the last thing to occur, and usually happens  after most system
> services (such as the portmapper service) have become unavailable.  That's fine
> for local file systems, but it makes  for a rather dodgy situation for NFS.

Interesting.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Chuck Lever <chuck.lever@oracle.com>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
	Cedric Le Goater <clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Trond Myklebust <trond.myklebust@fys.uio.no>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Containers
	<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
	linux-nfs@vger.kernel.org
Subject: Re: [RFC][PATCH] sunrpc: fix oops in rpc_create() when the mount namespace is unshared
Date: Tue, 09 Sep 2008 13:08:29 -0700	[thread overview]
Message-ID: <m17i9lm69u.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <869FF00C-4DAF-4D19-80AF-9230617A9223@oracle.com> (Chuck Lever's message of "Tue, 9 Sep 2008 15:00:55 -0400")

Chuck Lever <chuck.lever@oracle.com> writes:

> On Sep 9, 2008, at Sep 9, 2008, 2:20 PM, ebiederm@xmission.com wrote:
>> Chuck Lever <chuck.lever@oracle.com> writes:
>>
>>> If the upper layers are responsible for providing the utsname, you will need
>>> to
>>> fix up lockd and the NFS server's callback client too, at  least.
>>
>> Actually looking at the code.  It looks like a proper fix may be even simpler.
>> Why do we have both clnt->cl_server and clnt->cl_nodename?    Or is cl_server
>> the other side of the connection?
>
> cl_server is the server-side.  cl_nodename is the "machine name" of the client.

Thanks, Darn.  Looks like we need to capture both names at the same or a
similar point.

I'm wondering if we need to capture a network namespace as well.

>>> I don't like the idea of an oops in here.  Instead, (for now) it should warn
>>> and
>>> fail to create the client, IMO.
>>
>> Which is interesting when the problem happens during NFS unmount.  Although
>> frankly it could fail anyway.
>>
>> It seems strange that we are creating a client during unmount anyway.
>
> It's worth investigating.  Just enable RPC tracing (/usr/sbin/rpcdebug -m rpc -s
> all) before shutting down the client.
>
> NFS unmounting is historically difficult because during a system shutdown,
> unmounting is the last thing to occur, and usually happens  after most system
> services (such as the portmapper service) have become unavailable.  That's fine
> for local file systems, but it makes  for a rather dodgy situation for NFS.

Interesting.

Eric


WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Chuck Lever <chuck.lever@oracle.com>
Cc: "Serge E. Hallyn" <serue@us.ibm.com>,
	Cedric Le Goater <clg@fr.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Trond Myklebust <trond.myklebust@fys.uio.no>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Containers <containers@lists.osdl.org>,
	linux-nfs@vger.kernel.org
Subject: Re: [RFC][PATCH] sunrpc: fix oops in rpc_create() when the mount namespace is unshared
Date: Tue, 09 Sep 2008 13:08:29 -0700	[thread overview]
Message-ID: <m17i9lm69u.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <869FF00C-4DAF-4D19-80AF-9230617A9223@oracle.com> (Chuck Lever's message of "Tue, 9 Sep 2008 15:00:55 -0400")

Chuck Lever <chuck.lever@oracle.com> writes:

> On Sep 9, 2008, at Sep 9, 2008, 2:20 PM, ebiederm@xmission.com wrote:
>> Chuck Lever <chuck.lever@oracle.com> writes:
>>
>>> If the upper layers are responsible for providing the utsname, you will need
>>> to
>>> fix up lockd and the NFS server's callback client too, at  least.
>>
>> Actually looking at the code.  It looks like a proper fix may be even simpler.
>> Why do we have both clnt->cl_server and clnt->cl_nodename?    Or is cl_server
>> the other side of the connection?
>
> cl_server is the server-side.  cl_nodename is the "machine name" of the client.

Thanks, Darn.  Looks like we need to capture both names at the same or a
similar point.

I'm wondering if we need to capture a network namespace as well.

>>> I don't like the idea of an oops in here.  Instead, (for now) it should warn
>>> and
>>> fail to create the client, IMO.
>>
>> Which is interesting when the problem happens during NFS unmount.  Although
>> frankly it could fail anyway.
>>
>> It seems strange that we are creating a client during unmount anyway.
>
> It's worth investigating.  Just enable RPC tracing (/usr/sbin/rpcdebug -m rpc -s
> all) before shutting down the client.
>
> NFS unmounting is historically difficult because during a system shutdown,
> unmounting is the last thing to occur, and usually happens  after most system
> services (such as the portmapper service) have become unavailable.  That's fine
> for local file systems, but it makes  for a rather dodgy situation for NFS.

Interesting.

Eric


  parent reply	other threads:[~2008-09-09 20:08 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-08 13:39 [RFC][PATCH] sunrpc: fix oops in rpc_create() when the mount namespace is unshared Cedric Le Goater
     [not found] ` <48C52B29.4020204-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-09-08 15:19   ` Serge E. Hallyn
2008-09-08 15:19     ` Serge E. Hallyn
2008-09-08 15:19     ` Serge E. Hallyn
     [not found]     ` <20080908151932.GA19023-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-09-08 15:27       ` Serge E. Hallyn
2008-09-08 15:27         ` Serge E. Hallyn
2008-09-08 15:27         ` Serge E. Hallyn
2008-09-08 15:37       ` Cedric Le Goater
2008-09-08 15:37         ` Cedric Le Goater
2008-09-08 15:37         ` Cedric Le Goater
     [not found]         ` <48C546C0.504-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-09-08 15:43           ` Serge E. Hallyn
2008-09-08 15:43             ` Serge E. Hallyn
2008-09-08 15:43             ` Serge E. Hallyn
2008-09-08 16:09   ` Eric W. Biederman
2008-09-08 16:09     ` Eric W. Biederman
2008-09-08 16:09     ` Eric W. Biederman
     [not found]     ` <m163p6pqkv.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-09-09 11:54       ` Cedric Le Goater
2008-09-09 11:54         ` Cedric Le Goater
2008-09-09 11:54         ` Cedric Le Goater
2008-09-09 12:43   ` Serge E. Hallyn
2008-09-09 12:43     ` Serge E. Hallyn
2008-09-09 12:43     ` Serge E. Hallyn
     [not found]     ` <20080909124311.GA10053-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-09-09 15:09       ` Eric W. Biederman
2008-09-09 15:09         ` Eric W. Biederman
2008-09-09 15:09         ` Eric W. Biederman
     [not found]         ` <m18wu1nyon.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-09-09 15:29           ` Serge E. Hallyn
2008-09-09 15:29             ` Serge E. Hallyn
2008-09-09 15:29             ` Serge E. Hallyn
     [not found]             ` <20080909152952.GA21207-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2008-09-09 15:40               ` Cedric Le Goater
2008-09-09 15:40                 ` Cedric Le Goater
2008-09-09 15:40                 ` Cedric Le Goater
2008-09-09 17:07               ` Chuck Lever
2008-09-09 17:07                 ` Chuck Lever
2008-09-09 17:07                 ` Chuck Lever
     [not found]                 ` <DE845309-1684-472A-8269-78AB3A2823A9-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2008-09-09 18:20                   ` Eric W. Biederman
2008-09-09 18:20                     ` Eric W. Biederman
2008-09-09 18:20                     ` Eric W. Biederman
     [not found]                     ` <m1fxo9mba5.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-09-09 19:00                       ` Chuck Lever
2008-09-09 19:00                         ` Chuck Lever
2008-09-09 19:00                         ` Chuck Lever
     [not found]                         ` <869FF00C-4DAF-4D19-80AF-9230617A9223-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2008-09-09 20:08                           ` Eric W. Biederman [this message]
2008-09-09 20:08                             ` Eric W. Biederman
2008-09-09 20:08                             ` Eric W. Biederman
2008-09-10  9:23                       ` Cedric Le Goater
2008-09-10  9:23                         ` Cedric Le Goater
2008-09-10  9:23                         ` Cedric Le Goater
     [not found]                         ` <48C791F9.8090606-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-09-10 15:12                           ` Chuck Lever
2008-09-10 15:12                             ` Chuck Lever
2008-09-10 15:12                             ` Chuck Lever
     [not found]                             ` <76bd70e30809100812r4a7fa71crfc7196350e3ed1cf-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2008-09-10 20:02                               ` Eric W. Biederman
2008-09-10 20:02                                 ` Eric W. Biederman
2008-09-10 20:02                                 ` Eric W. Biederman
     [not found]                                 ` <m1ej3rixbx.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-09-10 20:54                                   ` Chuck Lever
2008-09-10 20:54                                     ` Chuck Lever
2008-09-10 20:54                                     ` Chuck Lever
2008-09-11  9:02                                 ` Cedric Le Goater
     [not found]                                   ` <48C8DEA0.9080905-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-09-11 10:27                                     ` Eric W. Biederman
2008-09-11 10:27                                       ` Eric W. Biederman
2008-09-11 10:27                                       ` Eric W. Biederman
2008-09-11 16:39                                     ` Chuck Lever
2008-09-11 16:39                                       ` Chuck Lever
2008-09-11 16:39                                       ` Chuck Lever

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=m17i9lm69u.fsf@frodo.ebiederm.org \
    --to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
    --cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=clg-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org \
    --cc=trond.myklebust-41N18TsMXrtuMpJDpNschA@public.gmane.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.