From: Trond Myklebust <Trond.Myklebust@netapp.com>
To: Stanislav Kinsbursky <skinsbursky@parallels.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: Wed, 11 Jan 2012 11:23:23 -0500 [thread overview]
Message-ID: <1326299003.17212.7.camel@lade.trondhjem.org> (raw)
In-Reply-To: <4F0C35F3.7060508@parallels.com>
On Tue, 2012-01-10 at 16:58 +0400, Stanislav Kinsbursky wrote:
> 06.01.2012 00:58, Trond Myklebust пишет:
> > 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?
What I mean is that currently, I have various ways to Oops the kernel
when I apply "SUNRPC: handle RPC client pipefs dentries by network
namespace aware routine" before all these other followup patches are
applied.
One way to could fix this, might be to add dummy versions of
rpc_pipefs_notifier_register()/unregister() so that "NFS: idmap PipeFS
notifier introduced" and the other such patches can be applied without
compilation errors or Oopses before the "handle RPC client pipefs
dentries..." patch is applied. The latter could then enable the real
rpc_pipefs_notifier_register()/....
The point is to not have these patches add _known_ bugs to the kernel at
any point, so that someone who is trying to track down an unknown bug
via "git bisect" doesn't have to also cope with these avoidable
issues...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
next prev parent reply other threads:[~2012-01-11 16:23 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-29 10:10 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 ` [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:19 ` Stanislav Kinsbursky
2011-11-29 12:40 ` tao.peng
2011-11-29 13:13 ` Stanislav Kinsbursky
2011-11-29 15:05 ` Peng Tao
2011-11-29 13:35 ` Myklebust, Trond
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 17:19 ` Trond Myklebust
2011-11-29 17:27 ` J. Bruce Fields
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
2012-01-11 16:23 ` Trond Myklebust [this message]
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=1326299003.17212.7.camel@lade.trondhjem.org \
--to=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=skinsbursky@parallels.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®