> -Original Message-
> From: tao.p...@emc.com [mailto:tao.p...@emc.com]
> Sent: Tuesday, November 29, 2011 7:40 AM
> To: skinsbur...@parallels.com
> Cc: Myklebust, Trond; linux-...@vger.kernel.org; xe...@parallels.com;
> ne...@suse.de; net...@vger.kernel.org; linux-ker.
> -Original Message-
> From: Stanislav Kinsbursky [mailto:skinsbur...@parallels.com]
> Sent: Thursday, January 19, 2012 10:32 AM
> To: Myklebust, Trond
> Cc: Dr James Bruce Fields; linux-...@vger.kernel.org; Pavel Emelianov;
> ne...@suse.de; net...@vger.ker
> -Original Message-
> From: bfie...@fieldses.org [mailto:bfie...@fieldses.org]
> Sent: Thursday, January 19, 2012 10:48 AM
> To: Stanislav Kinsbursky
> Cc: Myklebust, Trond; Dr James Bruce Fields; linux-...@vger.kernel.org;
> Pavel Emelianov; ne...@suse.de; net...@vger
On Mon, 2012-01-30 at 13:29 -0500, Paul Gortmaker wrote:
> On Tue, Dec 6, 2011 at 8:42 AM, Stanislav Kinsbursky
> wrote:
> > This patch makes it possible to create NFS program entry
> > ("/proc/net/rpc/nfs")
> > in passed network namespace context instead of hard-coded "init_net".
>
> Hi Trond,
On Mon, 2012-01-23 at 17:26 +, Stanislav Kinsbursky wrote:
> This patch makes nfs_clients_lock allocated per network namespace. All items
> it
> protects are already network namespace aware.
>
> Signed-off-by: Stanislav Kinsbursky
>
> ---
> fs/nfs/client.c | 51
On Tue, 2012-02-07 at 15:44 +0400, Stanislav Kinsbursky wrote:
> Trond, what are your plans about this patch set?
> Are you waiting for me and Eric to reach some decision, that suits both of us?
Yes. I'd like a consensus on the solution.
--
Trond Myklebust
Linux NFS client maintainer
NetApp
tro
On Tue, 2012-02-07 at 18:09 +0400, Stanislav Kinsbursky wrote:
> 07.02.2012 17:51, Myklebust, Trond пишет:
> > 8<-
> > From 5a489156da4fd15dd143f2b21dd9657b97dcef88 Mon Sep 17 00:00:00 2001
> > From:
On Tue, 2012-02-07 at 10:32 -0500, Bryan Schumaker wrote:
> I fixed up my bisect and identified this patch instead. The problem I'm
> seeing is:
>
> CC [M] fs/nfs/delegation.o
> CC [M] fs/nfs/idmap.o
> fs/nfs/idmap.c: In function 'rpc_pipefs_event':
> fs/nfs/idmap.c:535:9: error: implicit
On Tue, 2012-02-07 at 10:43 -0500, Bryan Schumaker wrote:
> On 01/26/12 06:11, Stanislav Kinsbursky wrote:
>
> > Network namespace is taken from request transport and passed as a part of
> > cb_process_state structure.
> >
> > Signed-off-by: Stanislav Kinsbursky
> >
> > ---
> > fs/nfs/callback
On Thu, 2012-02-16 at 19:06 +0400, Stanislav Kinsbursky wrote:
> Local tranports uses UNIX sockets and connecting of these sockets is done in
> context of file system namespace (i.e. task file system root).
> Currenly, all sockets connect operations are performed by rpciod work queue,
> which actua
On Mon, 2012-02-27 at 17:49 +0400, Stanislav Kinsbursky wrote:
> Lockdep is sad otherwise, because inode mutex is taken on PipeFS dentry
> creation, which can be called on mount notification, where this per-net client
> lock is taken on clients list walk.
>
> Note: I used simple mutex instead of r
On Mon, 2012-02-27 at 19:50 +0400, Stanislav Kinsbursky wrote:
> Lockdep is sad otherwise, because inode mutex is taken on PipeFS dentry
> creation, which can be called on mount notification, where this per-net client
> lock is taken on clients list walk.
>
> Signed-off-by: Stanislav Kinsbursky
>
On Mon, 2012-02-27 at 20:55 +0400, Stanislav Kinsbursky wrote:
> 27.02.2012 20:21, Myklebust, Trond пишет:
> > On Mon, 2012-02-27 at 19:50 +0400, Stanislav Kinsbursky wrote:
> >> Lockdep is sad otherwise, because inode mutex is taken on PipeFS dentry
> >> creation, w
On Wed, 2012-03-07 at 00:19 +, Myklebust, Trond wrote:
> On Wed, 2012-02-29 at 18:59 +0400, Stanislav Kinsbursky wrote:
> > Today, there is a problem in connecting of local SUNRPC thansports. These
> > transports uses UNIX sockets and connection itself is done by rpciod
> &g
On Wed, 2012-02-29 at 18:59 +0400, Stanislav Kinsbursky wrote:
> Today, there is a problem in connecting of local SUNRPC thansports. These
> transports uses UNIX sockets and connection itself is done by rpciod
> workqueue.
> But UNIX sockets lookup is done in context of process file system root. I
On Wed, 2012-03-07 at 12:34 +0400, Stanislav Kinsbursky wrote:
> 07.03.2012 04:19, Myklebust, Trond пишет:
> > On Wed, 2012-02-29 at 18:59 +0400, Stanislav Kinsbursky wrote:
> >> Today, there is a problem in connecting of local SUNRPC thansports. These
> >> trans
On Wed, 2012-04-25 at 13:30 -0400, J. Bruce Fields wrote:
> 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
On Fri, 2012-04-20 at 18:19 +0400, Stanislav Kinsbursky wrote:
> +static int __rpc_pipefs_event(struct rpc_clnt *clnt, unsigned long event,
> + struct super_block *sb)
> +{
> + int error;
> +
> + if (!rpc_clnt_skip_event(clnt, event)) {
> + error = _
On Tue, 2012-05-22 at 11:37 +0400, Stanislav Kinsbursky wrote:
> From: root (none)
>
What happened to the Subject: and changelog?
--
Trond Myklebust
Linux NFS client maintainer
NetApp
trond.mykleb...@netapp.com
www.netapp.com
___
Devel mailing lis
On Tue, 2012-05-22 at 12:03 +0400, Stanislav Kinsbursky wrote:
> Signed-off-by: Stanislav Kinsbursky
> ---
> fs/nfs/client.c |4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/fs/nfs/client.c b/fs/nfs/client.c
> index 44cd70f..ae29d4f 100644
> --- a/fs/nfs/client.c
On Tue, 2012-05-22 at 16:40 +0400, Stanislav Kinsbursky wrote:
> Client have to be initialized prior to adding it to per-net clients list,
> because otherwise there are races, shown below:
>
> CPU#0 CPU#1
> _ _
>
> nfs_get_cl
On Tue, 2012-05-22 at 18:41 +0400, Stanislav Kinsbursky wrote:
> On 22.05.2012 18:37, Myklebust, Trond wrote:
> > On Tue, 2012-05-22 at 12:03 +0400, Stanislav Kinsbursky wrote:
> >> Signed-off-by: Stanislav Kinsbursky
> >> ---
> >> fs/nfs/client.c |4 +++-
On Tue, 2012-05-22 at 10:29 -0400, Trond Myklebust wrote:
> On Tue, 2012-05-22 at 16:40 +0400, Stanislav Kinsbursky wrote:
> > Client have to be initialized prior to adding it to per-net clients list,
> > because otherwise there are races, shown below:
> >
> > CPU#0
On Tue, 2012-05-22 at 19:29 +0400, Stanislav Kinsbursky wrote:
> On 22.05.2012 19:00, Myklebust, Trond wrote:
> > On Tue, 2012-05-22 at 10:29 -0400, Trond Myklebust wrote:
> >> On Tue, 2012-05-22 at 16:40 +0400, Stanislav Kinsbursky wrote:
> >>> Client have to be ini
On Tue, 2012-05-22 at 20:18 +0400, Stanislav Kinsbursky wrote:
> On 22.05.2012 19:51, Myklebust, Trond wrote:
> > On Tue, 2012-05-22 at 19:29 +0400, Stanislav Kinsbursky wrote:
> >> On 22.05.2012 19:00, Myklebust, Trond wrote:
> >>> On Tue, 2012-05-22 at 10:2
On Tue, 2012-05-22 at 12:43 -0400, Trond Myklebust wrote:
> On Tue, 2012-05-22 at 20:18 +0400, Stanislav Kinsbursky wrote:
> > We have another problem here.
> > nfs4_init_client() will try to create pipe dentries prior to set of
> > NFS_CS_READY
> > to the client. And dentries will be created sin
On Wed, 2012-05-23 at 15:30 +0400, Stanislav Kinsbursky wrote:
> On 23.05.2012 00:32, Myklebust, Trond wrote:
> > On Tue, 2012-05-22 at 12:43 -0400, Trond Myklebust wrote:
> >> On Tue, 2012-05-22 at 20:18 +0400, Stanislav Kinsbursky wrote:
> >>> We have another proble
On Fri, 2012-07-20 at 15:57 +0400, Stanislav Kinsbursky wrote:
> Without this patch kernel will panic on LockD start, because lockd_up() checks
> lockd_up_net() result for negative value.
> >From my pow it's better to return negative value from rpcbind routines
> >instead
> of replacing all such c
On Mon, 2012-08-20 at 17:43 +0400, Stanislav Kinsbursky wrote:
> Put net reference we got in nfs_alloc_client() on error path.
>
> Signed-off-by: Stanislav Kinsbursky
> ---
> fs/nfs/nfs4client.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/fs/nfs/nfs4client.c b/
On Mon, 2012-08-13 at 08:10 -0400, Jeff Layton wrote:
> On Mon, 13 Aug 2012 15:37:31 +0400
> Stanislav Kinsbursky 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
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 wrote:
> >>
> >>>
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) w
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 L
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
&
On Fri, 2012-09-14 at 13:01 -0400, Chuck Lever wrote:
> What happens if statd is restarted?
Nothing unusual. Why?
> Sent from my iPhone
>
> On Sep 14, 2012, at 10:25 AM, Stanislav Kinsbursky
> wrote:
>
> > This is a bug fix for https://bugzilla.redhat.com/show_bug.cgi?id=830862.
> >
> > The
On Tue, 2012-10-09 at 15:35 -0400, J. Bruce Fields wrote:
> Cc'ing Eric since I seem to recall he suggested doing it this way?
>
> Seems OK to me, but maybe that swap_root should be in common code? (Or
> maybe we could use set_fs_root()?)
>
> I'm assuming it's up to Trond to take this.--b.
I'm
On Mon, 2012-12-17 at 20:18 +0300, Stanislav Kinsbursky wrote:
> There are SUNRPC clients, which program doesn't have pipe_dir_name. These
> clients can be skipped on PipeFS events, because nothing have to be created or
> destroyed. But instead of breaking in case of such a client was found, search
37 matches
Mail list logo
