From: Stanislav Kinsbursky <skinsbursky@parallels.com>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
Cc: "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
Pavel Emelianov <xemul@parallels.com>,
"neilb@suse.de" <neilb@suse.de>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
James Bottomley <jbottomley@parallels.com>,
"bfields@fieldses.org" <bfields@fieldses.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"devel@openvz.org" <devel@openvz.org>
Subject: Re: [PATCH 0/5] NFS: create blocklayout pipe per network namesapce context
Date: Tue, 10 Jan 2012 16:58:27 +0400 [thread overview]
Message-ID: <4F0C35F3.7060508@parallels.com> (raw)
In-Reply-To: <1325797111.11084.22.camel@lade.trondhjem.org>
06.01.2012 00:58, Trond Myklebust пишет:
> On Fri, 2011-12-30 at 17:55 -0500, Trond Myklebust wrote:
>> On Tue, 2011-11-29 at 13:10 +0300, Stanislav Kinsbursky wrote:
>>> This patch set was created in context of clone of git
>>> branch: git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git.
>>> tag: v3.1
>>>
>>> This patch set depends on previous patch sets titled:
>>> 1) "SUNRPC: initial part of making pipefs work in net ns"
>>> 2) "SUNPRC: cleanup PipeFS for network-namespace-aware users"
>>> 3) "SUNRPC: make RPC clients use network-namespace-aware PipeFS routines"
>>> 4) "NFS: create clients and IDMAP pipes per network namespace"
>>>
>>> This patch set is the final part of making SUNRPC PipeFS and it's users work in
>>> network namespace context.
>>>
>>> The following series consists of:
>>>
>>> ---
>>>
>>> Stanislav Kinsbursky (5):
>>> NFS: handle blocklayout pipe PipeFS dentry by network namespace aware routines
>>> NFS: blocklayout pipe creation per network namespace context introduced
>>> NFS: blocklayout PipeFS notifier introduced
>>> NFS: remove RPC PipeFS mount point reference from blocklayout routines
>>> SUNRPC: kernel PipeFS mount point creation routines removed
>>>
>>>
>>> fs/nfs/blocklayout/blocklayout.c | 154 ++++++++++++++++++++++++++++-------
>>> fs/nfs/blocklayout/blocklayout.h | 3 -
>>> fs/nfs/blocklayout/blocklayoutdev.c | 5 +
>>> fs/nfs/blocklayout/blocklayoutdm.c | 7 +-
>>> fs/nfs/inode.c | 1
>>> fs/nfs/netns.h | 1
>>> include/linux/sunrpc/rpc_pipe_fs.h | 2
>>> net/sunrpc/rpc_pipe.c | 21 -----
>>> 8 files changed, 137 insertions(+), 57 deletions(-)
>>
>>
>> These patches need rebasing in order to apply on top of 3.2-rc7...
>
> OK. Further testing seems to indicate that we're going to have to
> postpone merging these patches until the 3.4 merge window.
>
> The problems are twofold:
>
> As the patches stand now in the linux-next tree, they can (and
> occasionally do) Oops on unmount. The reason was that I rejected the
> PipeFS notifier patch for the idmapper (due to the reported problem of
> nfs_idmap_init/nfs_idmap_quit being undefined when CONFIG_NFS_V4 is
> undefined), and the fact that it is missing causes the unmount at the
> end of our tests to hit the BUG() in fs/dcache.c:905. This suggests that
> we will have the same problem with the pNFS block layout driver, since I
> still haven't received a rebased update of the 5 'create blocklayout
> pipe per network namesapce context' patches.
>
Hello, Trond.
I've resend the patch set (rebased with fix for nfs_idmap_init/nfs_idmap_quit).
> The second problem that was highlighted was the fact that as they stand
> today, these patchsets do not allow for bisection. When we hit the Oops,
> I had Bryan try to bisect where the problem arose. He ended up pointing
> at the patch "SUNRPC: handle RPC client pipefs dentries by network
> namespace aware routine", which is indeed the cause, but which is one of
> the _dependencies_ for all the PipeFS notifier patches that fix the
> problem.
>
I'm confused here. Does this means, that I have to fix patch "SUNRPC: handle RPC
client pipefs dentries by network namespace aware routine" to make it able to
bisect?
--
Best regards,
Stanislav Kinsbursky
next prev parent reply other threads:[~2012-01-10 12:58 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-29 10:10 [PATCH 0/5] NFS: create blocklayout pipe per network namesapce context Stanislav Kinsbursky
2011-11-29 9:17 ` Stanislav Kinsbursky
2011-11-29 10:10 ` [PATCH 1/5] NFS: handle blocklayout pipe PipeFS dentry by network namespace aware routines Stanislav Kinsbursky
2011-11-29 10:10 ` [PATCH 2/5] NFS: blocklayout pipe creation per network namespace context introduced Stanislav Kinsbursky
2011-11-29 10:10 ` [PATCH 3/5] NFS: blocklayout PipeFS notifier introduced Stanislav Kinsbursky
2011-11-29 10:10 ` Stanislav Kinsbursky
2011-11-29 10:10 ` [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from blocklayout routines Stanislav Kinsbursky
2011-11-29 12:00 ` tao.peng
2011-11-29 12:00 ` tao.peng-mb1K0bWo544
2011-11-29 12:00 ` tao.peng
2011-11-29 12:19 ` Stanislav Kinsbursky
2011-11-29 12:40 ` tao.peng
2011-11-29 12:40 ` tao.peng-mb1K0bWo544
2011-11-29 12:40 ` tao.peng
2011-11-29 13:13 ` Stanislav Kinsbursky
2011-11-29 15:05 ` Peng Tao
2011-11-29 15:05 ` Peng Tao
2011-11-29 13:35 ` Myklebust, Trond
2011-11-29 13:35 ` Myklebust, Trond
2011-11-29 13:35 ` Myklebust, Trond
2011-11-29 15:10 ` Peng Tao
2011-11-29 15:10 ` Peng Tao
2011-11-29 15:18 ` Trond Myklebust
2011-11-29 15:30 ` Peng Tao
2011-11-29 16:40 ` Trond Myklebust
2011-11-29 16:42 ` J. Bruce Fields
2011-11-29 16:42 ` J. Bruce Fields
2011-11-29 17:19 ` Trond Myklebust
2011-11-29 17:19 ` Trond Myklebust
2011-11-29 17:27 ` J. Bruce Fields
2011-11-29 17:27 ` J. Bruce Fields
2011-11-29 17:30 ` Peng Tao
2011-11-29 17:30 ` Peng Tao
2012-05-28 11:43 ` Boaz Harrosh
2011-11-29 10:10 ` [PATCH 5/5] SUNRPC: kernel PipeFS mount point creation routines removed Stanislav Kinsbursky
2011-12-30 22:55 ` [PATCH 0/5] NFS: create blocklayout pipe per network namesapce context Trond Myklebust
2012-01-05 20:58 ` Trond Myklebust
2012-01-10 12:58 ` Stanislav Kinsbursky [this message]
2012-01-11 16:23 ` Trond Myklebust
2012-01-11 17:23 ` Stanislav Kinsbursky
2012-01-11 17:46 ` Trond Myklebust
2012-01-11 18:03 ` Stanislav Kinsbursky
2012-01-10 10:50 ` Stanislav Kinsbursky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4F0C35F3.7060508@parallels.com \
--to=skinsbursky@parallels.com \
--cc=Trond.Myklebust@netapp.com \
--cc=bfields@fieldses.org \
--cc=davem@davemloft.net \
--cc=devel@openvz.org \
--cc=jbottomley@parallels.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=neilb@suse.de \
--cc=netdev@vger.kernel.org \
--cc=xemul@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.