Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference fromblocklayout routines

[Peng Tao]

On Tue, Nov 29, 2011 at 9:13 PM, Stanislav Kinsbursky
<skinsbursky@xxxxxxxxxxxxx> wrote:
> 29.11.2011 16:40, tao.peng@xxxxxxx ÐÐÑÐÑ:
>
>>> -----Original Message-----
>>> From: Stanislav Kinsbursky [mailto:skinsbursky@xxxxxxxxxxxxx]
>>> Sent: Tuesday, November 29, 2011 8:19 PM
>>> To: Peng, Tao
>>> Cc: Trond.Myklebust@xxxxxxxxxx; linux-nfs@xxxxxxxxxxxxxxx; Pavel
>>> Emelianov; neilb@xxxxxxx;
>>> netdev@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; James Bottomley;
>>> bfields@xxxxxxxxxxxx;
>>> davem@xxxxxxxxxxxxx; devel@xxxxxxxxxx
>>> Subject: Re: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference
>>> from blocklayout routines
>>>
>>> 29.11.2011 16:00, tao.peng@xxxxxxx ÐÐÑÐÑ:
>>>>>
>>>>> -----Original Message-----
>>>>> From: linux-nfs-owner@xxxxxxxxxxxxxxx
>>>>> [mailto:linux-nfs-owner@xxxxxxxxxxxxxxx] On Behalf Of
>>>
>>> Stanislav
>>>>>
>>>>> Kinsbursky
>>>>> Sent: Tuesday, November 29, 2011 6:11 PM
>>>>> To: Trond.Myklebust@xxxxxxxxxx
>>>>> Cc: linux-nfs@xxxxxxxxxxxxxxx; xemul@xxxxxxxxxxxxx; neilb@xxxxxxx;
>>>>> netdev@xxxxxxxxxxxxxxx; linux-
>>>>> kernel@xxxxxxxxxxxxxxx; jbottomley@xxxxxxxxxxxxx; bfields@xxxxxxxxxxxx;
>>>>> davem@xxxxxxxxxxxxx;
>>>>> devel@xxxxxxxxxx
>>>>> Subject: [PATCH 4/5] NFS: remove RPC PipeFS mount point reference from
>>>>> blocklayout routines
>>>>>
>>>>> This is a cleanup patch. We don't need this reference anymore, because
>>>>> blocklayout pipes dentries now creates and destroys in per-net
>>>>> operations and
>>>>> on PipeFS mount/umount notification.
>>>>> Note that nfs4blocklayout_register_net() now returns 0 instead of
>>>>> -ENOENT in
>>>>> case of PipeFS superblock absence. This is ok, because blocklayout pipe
>>>>> dentry
>>>>> will be created on PipeFS mount event.
>>>>
>>>> When is the "pipefs mount event" going to happen? When inserting kernel
>>>> modules or when user issues
>>>
>>> mount command?
>>>>
>>>>
>>>
>>> When user issues mount command.
>>> Kernel mounts of PipeFS has been removed with all these patch sets I've
>>> sent
>>> already.
>>
>> Then it is going to break blocklayout user space program blkmapd, which is
>> stared before mounting any file system and it tries to open the pipe file
>> when started.
>
>
> Sorry, but I don't get it. Probably we have misunderstanding here.
> You said, that "blkmapd ... tries to open the pipe file when started". This
> pipe file is located on PipeFS, isn't it?
> If yes, then PipeFS have to be mounted already in user-space. And if it has
> been mounted - then pipe dentry is present.
> IOW, pipe (without dentry) will be created on module load. Pipe dentry will
> be created right after that (like it was before) if PipeFS was mounted from
> user-space. If not - then pipe dentry will be created Âon PipeFS (!) mount
> (not NFS or pNFS mount) from user-space.
Sorry, I misunderstood. I was thinking about mounting NFS or pNFS when
you say "when user issues mount command". Thanks for the explanation.

Regards,
Tao
>
> Or I'm missing something in your reply?
>
>
>> Not sure if you implement the same logic on nfs pipe as well. But if you
>> do, then nfs client user space program idmapd will fail to start for the
>> same reason.
>>
>
> The same logic here.
>
>
>> Why not just fail to load module if you fail to initialize pipefs? When is
>> rpc_get_sb_net() going to fail?
>>
>
> Sorry, but I don't understand, what is your idea. And why do we need to fail
> at all.
> BTW, rpc_get_sb_net() just checks, was PipeFS mounted in passed net, or not.
> If not - not a problem. Dentries will be created on mount event. If yes,
> then it returns locked PipeFS sb and the next step is dentry creation.
>
>
>>>
>>>
>>>> Thanks,
>>>> Tao
>>>>
>>>>>
>>>>> Signed-off-by: Stanislav Kinsbursky<skinsbursky@xxxxxxxxxxxxx>
>>>>>
>>>>> ---
>>>>> Â fs/nfs/blocklayout/blocklayout.c | Â Â9 +--------
>>>>> Â 1 files changed, 1 insertions(+), 8 deletions(-)
>>>>>
>>>>> diff --git a/fs/nfs/blocklayout/blocklayout.c
>>>>> b/fs/nfs/blocklayout/blocklayout.c
>>>>> index acf7ac9..8211ffd 100644
>>>>> --- a/fs/nfs/blocklayout/blocklayout.c
>>>>> +++ b/fs/nfs/blocklayout/blocklayout.c
>>>>> @@ -1032,7 +1032,7 @@ static struct dentry
>>>>> *nfs4blocklayout_register_net(struct net *net,
>>>>>
>>>>> Â Â Â Âpipefs_sb = rpc_get_sb_net(net);
>>>>> Â Â Â Âif (!pipefs_sb)
>>>>> - Â Â Â Â Â Â Â return ERR_PTR(-ENOENT);
>>>>> + Â Â Â Â Â Â Â return 0;
>>>>> Â Â Â Âdentry = nfs4blocklayout_register_sb(pipefs_sb, pipe);
>>>>> Â Â Â Ârpc_put_sb_net(net);
>>>>> Â Â Â Âreturn dentry;
>>>>> @@ -1083,7 +1083,6 @@ static struct pernet_operations
>>>>> nfs4blocklayout_net_ops = {
>>>>>
>>>>> Â static int __init nfs4blocklayout_init(void)
>>>>> Â {
>>>>> - Â Â Â struct vfsmount *mnt;
>>>>> Â Â Â Âint ret;
>>>>>
>>>>> Â Â Â Âdprintk("%s: NFSv4 Block Layout Driver Registering...\n",
>>>>> __func__);
>>>>> @@ -1093,12 +1092,6 @@ static int __init nfs4blocklayout_init(void)
>>>>> Â Â Â Â Â Â Â Âgoto out;
>>>>>
>>>>> Â Â Â Âinit_waitqueue_head(&bl_wq);
>>>>> -
>>>>> - Â Â Â mnt = rpc_get_mount();
>>>>> - Â Â Â if (IS_ERR(mnt)) {
>>>>> - Â Â Â Â Â Â Â ret = PTR_ERR(mnt);
>>>>> - Â Â Â Â Â Â Â goto out_remove;
>>>>> - Â Â Â }
>>>>> Â Â Â Âret = rpc_pipefs_notifier_register(&nfs4blocklayout_block);
>>>>> Â Â Â Âif (ret)
>>>>> Â Â Â Â Â Â Â Âgoto out_remove;
>>>>>
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>>>>> the body of a message to majordomo@xxxxxxxxxxxxxxx
>>>>> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Stanislav Kinsbursky
>>
>>
>
>
> --
> Best regards,
> Stanislav Kinsbursky
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at Âhttp://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/