From: Nikita Yushchenko <nikita.yushchenko@virtuozzo.com>
To: NeilBrown <neilb@suse.de>, Petr Vorel <pvorel@suse.cz>
Cc: linux-nfs@vger.kernel.org,
"J. Bruce Fields" <bfields@fieldses.org>,
Chuck Lever <chuck.lever@oracle.com>,
Trond Myklebust <trond.myklebust@hammerspace.com>,
Anna Schumaker <anna.schumaker@netapp.com>,
Steve Dickson <SteveD@redhat.com>,
ltp@lists.linux.it, kernel@openvz.org
Subject: Re: LTP nfslock01 test failing on NFS v3 (lockd: cannot monitor 10.0.0.2)
Date: Wed, 19 Jan 2022 08:28:47 +0300 [thread overview]
Message-ID: <30d1626f-b2f3-b1f4-2e85-5ee5b78926f9@virtuozzo.com> (raw)
In-Reply-To: <28b078ad-d69a-4ad7-f2a9-334150a97d18@virtuozzo.com>
19.01.2022 08:26, Nikita Yushchenko wrote:
>> Big picture is - lockd tries to be per-netns, but lockd isn't standalone, it depends on rpcbind, and
>> rpcbind isn't guaranteed to be per-netns.
>>
>> One can argue that it is not kernel's job to provide per-netns rpcbind.
>>
>> Still, the current situation is - by default, doing an nfs mount from within netns B immediately
>> breaks lockd serving nfs mounts exported from different netns A. "By default" = "as long as nfsmount
>> process executed in netns B is also in a different mount namespace that has RPCBIND_SOCK_PATHNAME not
>> pointing to AF_UNIX socket instance owned by rpcbind serving netns A.
>>
>> Although in LTP's 'nfslock01' test the "non working locking" is reproduced on the same mount that
>> triggered the breakage, the breakage is not limited to that mount. Since that mount operation in netns
>> B, any client of nfs exports from netns A will get locking broken - including clients running on
>> different physical hosts.
>>
>> I'd say that using AF_UNIX connection from lockd to rpcbind does not play well with per-netns lockd.
>>
>> Solution to use AF_UNIX connection to rpcbind only for lockd serving root netns, and using AF_INET
>> otherwise - looks more sane.
>
> Btw, not sure (did not test) what will happen if nfs server will be similarly started in netns B. Will
> it hijack requests addressed to nfs server running in netns A?
No it won't "hijack"... because in will still listen inside netns B only. But, if ports in rpcbind get
overwritten in the similar manner, nfs server running in netns A will become no longer reachable.
WARNING: multiple messages have this Message-ID (diff)
From: Nikita Yushchenko via ltp <ltp@lists.linux.it>
To: NeilBrown <neilb@suse.de>, Petr Vorel <pvorel@suse.cz>
Cc: linux-nfs@vger.kernel.org, Steve Dickson <SteveD@redhat.com>,
Anna Schumaker <anna.schumaker@netapp.com>,
"J. Bruce Fields" <bfields@fieldses.org>,
Chuck Lever <chuck.lever@oracle.com>,
kernel@openvz.org,
Trond Myklebust <trond.myklebust@hammerspace.com>,
ltp@lists.linux.it
Subject: Re: [LTP] LTP nfslock01 test failing on NFS v3 (lockd: cannot monitor 10.0.0.2)
Date: Wed, 19 Jan 2022 08:28:47 +0300 [thread overview]
Message-ID: <30d1626f-b2f3-b1f4-2e85-5ee5b78926f9@virtuozzo.com> (raw)
In-Reply-To: <28b078ad-d69a-4ad7-f2a9-334150a97d18@virtuozzo.com>
19.01.2022 08:26, Nikita Yushchenko wrote:
>> Big picture is - lockd tries to be per-netns, but lockd isn't standalone, it depends on rpcbind, and
>> rpcbind isn't guaranteed to be per-netns.
>>
>> One can argue that it is not kernel's job to provide per-netns rpcbind.
>>
>> Still, the current situation is - by default, doing an nfs mount from within netns B immediately
>> breaks lockd serving nfs mounts exported from different netns A. "By default" = "as long as nfsmount
>> process executed in netns B is also in a different mount namespace that has RPCBIND_SOCK_PATHNAME not
>> pointing to AF_UNIX socket instance owned by rpcbind serving netns A.
>>
>> Although in LTP's 'nfslock01' test the "non working locking" is reproduced on the same mount that
>> triggered the breakage, the breakage is not limited to that mount. Since that mount operation in netns
>> B, any client of nfs exports from netns A will get locking broken - including clients running on
>> different physical hosts.
>>
>> I'd say that using AF_UNIX connection from lockd to rpcbind does not play well with per-netns lockd.
>>
>> Solution to use AF_UNIX connection to rpcbind only for lockd serving root netns, and using AF_INET
>> otherwise - looks more sane.
>
> Btw, not sure (did not test) what will happen if nfs server will be similarly started in netns B. Will
> it hijack requests addressed to nfs server running in netns A?
No it won't "hijack"... because in will still listen inside netns B only. But, if ports in rpcbind get
overwritten in the similar manner, nfs server running in netns A will become no longer reachable.
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-01-19 5:28 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-18 15:26 LTP nfslock01 test failing on NFS v3 (lockd: cannot monitor 10.0.0.2) Petr Vorel
2022-01-18 15:26 ` [LTP] " Petr Vorel
2022-01-18 15:51 ` Nikita Yushchenko
2022-01-18 15:51 ` [LTP] " Nikita Yushchenko via ltp
2022-01-18 22:13 ` NeilBrown
2022-01-18 22:13 ` [LTP] " NeilBrown
2022-01-18 22:11 ` NeilBrown
2022-01-18 22:11 ` [LTP] " NeilBrown
2022-01-19 5:17 ` Nikita Yushchenko
2022-01-19 5:17 ` [LTP] " Nikita Yushchenko via ltp
2022-01-19 5:26 ` Nikita Yushchenko
2022-01-19 5:26 ` [LTP] " Nikita Yushchenko via ltp
2022-01-19 5:28 ` Nikita Yushchenko [this message]
2022-01-19 5:28 ` Nikita Yushchenko via ltp
2022-01-20 12:24 ` Petr Vorel
2022-01-20 12:24 ` [LTP] " Petr Vorel
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=30d1626f-b2f3-b1f4-2e85-5ee5b78926f9@virtuozzo.com \
--to=nikita.yushchenko@virtuozzo.com \
--cc=SteveD@redhat.com \
--cc=anna.schumaker@netapp.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=kernel@openvz.org \
--cc=linux-nfs@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=neilb@suse.de \
--cc=pvorel@suse.cz \
--cc=trond.myklebust@hammerspace.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.