Reported-by: Jeff Layton <[email protected]>
Signed-off-by: Peng Tao <[email protected]>
---
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
> -----Original Message-----
> From: Jim Rees [mailto:[email protected]]
> Sent: Sunday, September 18, 2011 10:05 PM
> To: Myklebust, Trond
> Cc: Benny Halevy; Peng Tao; [email protected]; peter honeyman
> Subject: Re: [PATCH] pnfsblock: add missing rpc_put_mount and path_put
>
> Myklebust, Trond wrote:
>
> > -----Original Message-----
> > From: Benny Halevy [mailto:[email protected]]
> > Sent: Wednesday, September 14, 2011 6:20 AM
> > To: Jim Rees; Peng Tao; Myklebust, Trond
> > Cc: [email protected]; 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
> -----Original Message-----
> From: Benny Halevy [mailto:[email protected]]
> Sent: Wednesday, September 14, 2011 6:20 AM
> To: Jim Rees; Peng Tao; Myklebust, Trond
> Cc: [email protected]; 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
Myklebust, Trond wrote:
> -----Original Message-----
> From: Benny Halevy [mailto:[email protected]]
> Sent: Wednesday, September 14, 2011 6:20 AM
> To: Jim Rees; Peng Tao; Myklebust, Trond
> Cc: [email protected]; 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.
On 2011-09-19 05:06, Myklebust, Trond wrote:
>> -----Original Message-----
>> From: Jim Rees [mailto:[email protected]]
>> Sent: Sunday, September 18, 2011 10:05 PM
>> To: Myklebust, Trond
>> Cc: Benny Halevy; Peng Tao; [email protected]; peter honeyman
>> Subject: Re: [PATCH] pnfsblock: add missing rpc_put_mount and path_put
>>
>> Myklebust, Trond wrote:
>>
>> > -----Original Message-----
>> > From: Benny Halevy [mailto:[email protected]]
>> > Sent: Wednesday, September 14, 2011 6:20 AM
>> > To: Jim Rees; Peng Tao; Myklebust, Trond
>> > Cc: [email protected]; 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
On Tue, 13 Sep 2011 09:16:26 -0700
Peng Tao <[email protected]> wrote:
> Reported-by: Jeff Layton <[email protected]>
> Signed-off-by: Peng Tao <[email protected]>
> ---
> 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 <[email protected]>