* [PATCH] pnfsblock: add missing rpc_put_mount and path_put
@ 2011-09-13 20:24 Jim Rees
2011-09-14 10:19 ` Benny Halevy
0 siblings, 1 reply; 8+ messages in thread
From: Jim Rees @ 2011-09-13 20:24 UTC (permalink / raw)
To: Benny Halevy; +Cc: linux-nfs, peter honeyman
From: Peng Tao <bergwolf@gmail.com>
Reported-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Peng Tao <peng_tao@emc.com>
Signed-off-by: Jim Rees <rees@umich.edu>
---
fs/nfs/blocklayout/blocklayout.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
index 9675ef9..8f97578 100644
--- a/fs/nfs/blocklayout/blocklayout.c
+++ b/fs/nfs/blocklayout/blocklayout.c
@@ -1009,17 +1009,20 @@ static int __init nfs4blocklayout_init(void)
mnt,
NFS_PIPE_DIRNAME, 0, &path);
if (ret)
- goto out_remove;
+ goto out_putrpc;
bl_device_pipe = rpc_mkpipe(path.dentry, "blocklayout", NULL,
&bl_upcall_ops, 0);
+ path_put(&path);
if (IS_ERR(bl_device_pipe)) {
ret = PTR_ERR(bl_device_pipe);
- goto out_remove;
+ goto out_putrpc;
}
out:
return ret;
+out_putrpc:
+ rpc_put_mount();
out_remove:
pnfs_unregister_layoutdriver(&blocklayout_type);
out_stop:
@@ -1035,6 +1038,7 @@ static void __exit nfs4blocklayout_exit(void)
pnfs_unregister_layoutdriver(&blocklayout_type);
pnfsiod_stop();
rpc_unlink(bl_device_pipe);
+ rpc_put_mount();
}
MODULE_ALIAS("nfs-layouttype4-3");
--
1.7.4.1
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH] pnfsblock: add missing rpc_put_mount and path_put
2011-09-13 20:24 [PATCH] pnfsblock: add missing rpc_put_mount and path_put Jim Rees
@ 2011-09-14 10:19 ` Benny Halevy
2011-09-19 1:09 ` Myklebust, Trond
0 siblings, 1 reply; 8+ messages in thread
From: Benny Halevy @ 2011-09-14 10:19 UTC (permalink / raw)
To: Jim Rees, Peng Tao, Trond Myklebust; +Cc: linux-nfs, peter honeyman
We need to decide on a process here :)
If we would like to maintain a staging tree in front of Trond's
then to simplify merging and rebasing, fixes to code that's already
upstream, i.e. in linux-2.6 or already queued in nfs-2.6, that we decide
to send to Trond ahead of queue need to be queued in front of stuff in
the staging tree and the latter should be rebased on top of them.
Benny
On 2011-09-13 22:24, Jim Rees wrote:
> From: Peng Tao <bergwolf@gmail.com>
>
> Reported-by: Jeff Layton <jlayton@redhat.com>
> Signed-off-by: Peng Tao <peng_tao@emc.com>
> Signed-off-by: Jim Rees <rees@umich.edu>
> ---
> fs/nfs/blocklayout/blocklayout.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
> index 9675ef9..8f97578 100644
> --- a/fs/nfs/blocklayout/blocklayout.c
> +++ b/fs/nfs/blocklayout/blocklayout.c
> @@ -1009,17 +1009,20 @@ static int __init nfs4blocklayout_init(void)
> mnt,
> NFS_PIPE_DIRNAME, 0, &path);
> if (ret)
> - goto out_remove;
> + goto out_putrpc;
>
> bl_device_pipe = rpc_mkpipe(path.dentry, "blocklayout", NULL,
> &bl_upcall_ops, 0);
> + path_put(&path);
> if (IS_ERR(bl_device_pipe)) {
> ret = PTR_ERR(bl_device_pipe);
> - goto out_remove;
> + goto out_putrpc;
> }
> out:
> return ret;
>
> +out_putrpc:
> + rpc_put_mount();
> out_remove:
> pnfs_unregister_layoutdriver(&blocklayout_type);
> out_stop:
> @@ -1035,6 +1038,7 @@ static void __exit nfs4blocklayout_exit(void)
> pnfs_unregister_layoutdriver(&blocklayout_type);
> pnfsiod_stop();
> rpc_unlink(bl_device_pipe);
> + rpc_put_mount();
> }
>
> MODULE_ALIAS("nfs-layouttype4-3");
^ permalink raw reply [flat|nested] 8+ messages in thread* RE: [PATCH] pnfsblock: add missing rpc_put_mount and path_put
2011-09-14 10:19 ` Benny Halevy
@ 2011-09-19 1:09 ` Myklebust, Trond
2011-09-19 2:04 ` Jim Rees
0 siblings, 1 reply; 8+ messages in thread
From: Myklebust, Trond @ 2011-09-19 1:09 UTC (permalink / raw)
To: Benny Halevy, Jim Rees, Peng Tao; +Cc: linux-nfs, peter honeyman
> -----Original Message-----
> From: Benny Halevy [mailto:bhalevy@tonian.com]
> Sent: Wednesday, September 14, 2011 6:20 AM
> To: Jim Rees; Peng Tao; Myklebust, Trond
> Cc: linux-nfs@vger.kernel.org; peter honeyman
> Subject: Re: [PATCH] pnfsblock: add missing rpc_put_mount and path_put
>
> We need to decide on a process here :)
> If we would like to maintain a staging tree in front of Trond's then
to simplify
> merging and rebasing, fixes to code that's already upstream, i.e. in
linux-2.6
> or already queued in nfs-2.6, that we decide to send to Trond ahead of
> queue need to be queued in front of stuff in the staging tree and the
latter
> should be rebased on top of them.
Unless we're talking about a large merge, I tend to prefer patches. They
are much easier to review...
Cheers
Trond
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] pnfsblock: add missing rpc_put_mount and path_put
2011-09-19 1:09 ` Myklebust, Trond
@ 2011-09-19 2:04 ` Jim Rees
2011-09-19 2:06 ` Myklebust, Trond
0 siblings, 1 reply; 8+ messages in thread
From: Jim Rees @ 2011-09-19 2:04 UTC (permalink / raw)
To: Myklebust, Trond; +Cc: Benny Halevy, Peng Tao, linux-nfs, peter honeyman
Myklebust, Trond wrote:
> -----Original Message-----
> From: Benny Halevy [mailto:bhalevy@tonian.com]
> Sent: Wednesday, September 14, 2011 6:20 AM
> To: Jim Rees; Peng Tao; Myklebust, Trond
> Cc: linux-nfs@vger.kernel.org; peter honeyman
> Subject: Re: [PATCH] pnfsblock: add missing rpc_put_mount and path_put
>
> We need to decide on a process here :)
> If we would like to maintain a staging tree in front of Trond's then
to simplify
> merging and rebasing, fixes to code that's already upstream, i.e. in
linux-2.6
> or already queued in nfs-2.6, that we decide to send to Trond ahead of
> queue need to be queued in front of stuff in the staging tree and the
latter
> should be rebased on top of them.
Unless we're talking about a large merge, I tend to prefer patches. They
are much easier to review...
I guess the problem is that we now have a patch in Trond's tree that
conflicts with the workqueue patch that's staged for later in Benny's tree.
I think what I need to do is send Benny a set of patches that starts with
the same patch I sent Trond, and follows with one that adds the workqueue.
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH] pnfsblock: add missing rpc_put_mount and path_put
2011-09-19 2:04 ` Jim Rees
@ 2011-09-19 2:06 ` Myklebust, Trond
2011-09-19 3:01 ` Benny Halevy
0 siblings, 1 reply; 8+ messages in thread
From: Myklebust, Trond @ 2011-09-19 2:06 UTC (permalink / raw)
To: Jim Rees; +Cc: Benny Halevy, Peng Tao, linux-nfs, peter honeyman
> -----Original Message-----
> From: Jim Rees [mailto:rees@umich.edu]
> Sent: Sunday, September 18, 2011 10:05 PM
> To: Myklebust, Trond
> Cc: Benny Halevy; Peng Tao; linux-nfs@vger.kernel.org; peter honeyman
> Subject: Re: [PATCH] pnfsblock: add missing rpc_put_mount and path_put
>
> Myklebust, Trond wrote:
>
> > -----Original Message-----
> > From: Benny Halevy [mailto:bhalevy@tonian.com]
> > Sent: Wednesday, September 14, 2011 6:20 AM
> > To: Jim Rees; Peng Tao; Myklebust, Trond
> > Cc: linux-nfs@vger.kernel.org; peter honeyman
> > Subject: Re: [PATCH] pnfsblock: add missing rpc_put_mount and
path_put
> >
> > We need to decide on a process here :)
> > If we would like to maintain a staging tree in front of Trond's
then
> to simplify
> > merging and rebasing, fixes to code that's already upstream, i.e.
in
> linux-2.6
> > or already queued in nfs-2.6, that we decide to send to Trond
ahead of
> > queue need to be queued in front of stuff in the staging tree and
the
> latter
> > should be rebased on top of them.
>
> Unless we're talking about a large merge, I tend to prefer patches.
They
> are much easier to review...
>
> I guess the problem is that we now have a patch in Trond's tree that
conflicts
> with the workqueue patch that's staged for later in Benny's tree.
> I think what I need to do is send Benny a set of patches that starts
with the
> same patch I sent Trond, and follows with one that adds the workqueue.
Yes. That's the other good feature of patches: the onus of fixing up
conflicts is on you and not on me... :-)
Trond
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] pnfsblock: add missing rpc_put_mount and path_put
2011-09-19 2:06 ` Myklebust, Trond
@ 2011-09-19 3:01 ` Benny Halevy
0 siblings, 0 replies; 8+ messages in thread
From: Benny Halevy @ 2011-09-19 3:01 UTC (permalink / raw)
To: Jim Rees; +Cc: Myklebust, Trond, Peng Tao, linux-nfs, peter honeyman
On 2011-09-19 05:06, Myklebust, Trond wrote:
>> -----Original Message-----
>> From: Jim Rees [mailto:rees@umich.edu]
>> Sent: Sunday, September 18, 2011 10:05 PM
>> To: Myklebust, Trond
>> Cc: Benny Halevy; Peng Tao; linux-nfs@vger.kernel.org; peter honeyman
>> Subject: Re: [PATCH] pnfsblock: add missing rpc_put_mount and path_put
>>
>> Myklebust, Trond wrote:
>>
>> > -----Original Message-----
>> > From: Benny Halevy [mailto:bhalevy@tonian.com]
>> > Sent: Wednesday, September 14, 2011 6:20 AM
>> > To: Jim Rees; Peng Tao; Myklebust, Trond
>> > Cc: linux-nfs@vger.kernel.org; peter honeyman
>> > Subject: Re: [PATCH] pnfsblock: add missing rpc_put_mount and
> path_put
>> >
>> > We need to decide on a process here :)
>> > If we would like to maintain a staging tree in front of Trond's
> then
>> to simplify
>> > merging and rebasing, fixes to code that's already upstream, i.e.
> in
>> linux-2.6
>> > or already queued in nfs-2.6, that we decide to send to Trond
> ahead of
>> > queue need to be queued in front of stuff in the staging tree and
> the
>> latter
>> > should be rebased on top of them.
>>
>> Unless we're talking about a large merge, I tend to prefer patches.
> They
>> are much easier to review...
>>
>> I guess the problem is that we now have a patch in Trond's tree that
> conflicts
>> with the workqueue patch that's staged for later in Benny's tree.
>> I think what I need to do is send Benny a set of patches that starts
> with the
>> same patch I sent Trond, and follows with one that adds the workqueue.
>
> Yes. That's the other good feature of patches: the onus of fixing up
> conflicts is on you and not on me... :-)
>
Right. If the required rebase is not trivial I prefer you do it
for many reasons, including familiarity with the change and testing
the end result. Then, either send the patchset to the list and/or
point me to a branch in your tree for me to get the series from
Benny
> Trond
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] pnfsblock: add missing rpc_put_mount and path_put
@ 2011-09-13 16:16 Peng Tao
2011-09-13 16:44 ` Jeff Layton
0 siblings, 1 reply; 8+ messages in thread
From: Peng Tao @ 2011-09-13 16:16 UTC (permalink / raw)
To: Trond Myklebust; +Cc: Jim Rees, Benny Halevy, Jeff Layton, linux-nfs, Peng Tao
Reported-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Peng Tao <peng_tao@emc.com>
---
fs/nfs/blocklayout/blocklayout.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
index cc78e62..66f2f73 100644
--- a/fs/nfs/blocklayout/blocklayout.c
+++ b/fs/nfs/blocklayout/blocklayout.c
@@ -1009,17 +1009,20 @@ static int __init nfs4blocklayout_init(void)
mnt,
NFS_PIPE_DIRNAME, 0, &path);
if (ret)
- goto out_stop;
+ goto out_putrpc;
bl_device_pipe = rpc_mkpipe(path.dentry, "blocklayout", NULL,
&bl_upcall_ops, 0);
+ path_put(&path);
if (IS_ERR(bl_device_pipe)) {
ret = PTR_ERR(bl_device_pipe);
- goto out_stop;
+ goto out_putrpc;
}
out:
return ret;
+out_putrpc:
+ rpc_put_mount();
out_stop:
pnfsiod_stop();
out_remove:
@@ -1035,6 +1038,7 @@ static void __exit nfs4blocklayout_exit(void)
pnfs_unregister_layoutdriver(&blocklayout_type);
pnfsiod_stop();
rpc_unlink(bl_device_pipe);
+ rpc_put_mount();
}
MODULE_ALIAS("nfs-layouttype4-3");
--
1.7.1.262.g5ef3d
^ permalink raw reply related [flat|nested] 8+ messages in thread* Re: [PATCH] pnfsblock: add missing rpc_put_mount and path_put
2011-09-13 16:16 Peng Tao
@ 2011-09-13 16:44 ` Jeff Layton
0 siblings, 0 replies; 8+ messages in thread
From: Jeff Layton @ 2011-09-13 16:44 UTC (permalink / raw)
To: Peng Tao; +Cc: Trond Myklebust, Jim Rees, Benny Halevy, linux-nfs, Peng Tao
On Tue, 13 Sep 2011 09:16:26 -0700
Peng Tao <bergwolf@gmail.com> wrote:
> Reported-by: Jeff Layton <jlayton@redhat.com>
> Signed-off-by: Peng Tao <peng_tao@emc.com>
> ---
> fs/nfs/blocklayout/blocklayout.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/fs/nfs/blocklayout/blocklayout.c b/fs/nfs/blocklayout/blocklayout.c
> index cc78e62..66f2f73 100644
> --- a/fs/nfs/blocklayout/blocklayout.c
> +++ b/fs/nfs/blocklayout/blocklayout.c
> @@ -1009,17 +1009,20 @@ static int __init nfs4blocklayout_init(void)
> mnt,
> NFS_PIPE_DIRNAME, 0, &path);
> if (ret)
> - goto out_stop;
> + goto out_putrpc;
>
> bl_device_pipe = rpc_mkpipe(path.dentry, "blocklayout", NULL,
> &bl_upcall_ops, 0);
> + path_put(&path);
> if (IS_ERR(bl_device_pipe)) {
> ret = PTR_ERR(bl_device_pipe);
> - goto out_stop;
> + goto out_putrpc;
> }
> out:
> return ret;
>
> +out_putrpc:
> + rpc_put_mount();
> out_stop:
> pnfsiod_stop();
> out_remove:
> @@ -1035,6 +1038,7 @@ static void __exit nfs4blocklayout_exit(void)
> pnfs_unregister_layoutdriver(&blocklayout_type);
> pnfsiod_stop();
> rpc_unlink(bl_device_pipe);
> + rpc_put_mount();
> }
>
> MODULE_ALIAS("nfs-layouttype4-3");
Looks correct. Thanks.
Reviewed-by: Jeff Layton <jlayton@redhat.com>
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-09-19 3:01 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-13 20:24 [PATCH] pnfsblock: add missing rpc_put_mount and path_put Jim Rees
2011-09-14 10:19 ` Benny Halevy
2011-09-19 1:09 ` Myklebust, Trond
2011-09-19 2:04 ` Jim Rees
2011-09-19 2:06 ` Myklebust, Trond
2011-09-19 3:01 ` Benny Halevy
-- strict thread matches above, loose matches on Subject: below --
2011-09-13 16:16 Peng Tao
2011-09-13 16:44 ` Jeff Layton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).