From: Petr Vorel <pvorel@suse.cz>
To: NeilBrown <neilb@suse.de>
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>,
Nikita Yushchenko <nikita.yushchenko@virtuozzo.com>,
ltp@lists.linux.it
Subject: Re: LTP nfslock01 test failing on NFS v3 (lockd: cannot monitor 10.0.0.2)
Date: Thu, 20 Jan 2022 13:24:09 +0100 [thread overview]
Message-ID: <YelUaQHlCp8FHAeQ@pevik> (raw)
In-Reply-To: <164254391708.24166.6930987548904227011@noble.neil.brown.name>
Hi Neil, all,
> On Wed, 19 Jan 2022, Petr Vorel wrote:
> > Hi all,
> > this is a test failure posted by Nikita Yushchenko [1]. LTP NFS test nfslock01
> > looks to be failing on NFS v3:
> > "not unsharing /var makes AF_UNIX socket for host's rpcbind to become available
> > inside ltpns. Then, at nfs3 mount time, kernel creates an instance of lockd for
> > ltpns, and ports for that instance leak to host's rpcbind and overwrite ports
> > for lockd already active for root namespace. This breaks nfs3 file locking."
> "not unsharing /var" .... can this be fixed by simply unsharing /var?
> Or is that not simple?
> On could easily argue that RPCBIND_SOCK_PATHNAME in the kernel should be
> changed to "/run/rpcbind.sock". Does this test suite unshare /run ??
> BTW, your email contains [1], [2], etc which suggests there are links
> somewhere - but there aren't.
I'm sorry, here they are:
[1] https://lore.kernel.org/ltp/590378ee-71af-deb6-6c03-1d2af459ed63@virtuozzo.com/
(the report)
[2] https://lore.kernel.org/ltp/20220112161942.4065665-1-nikita.yushchenko@virtuozzo.com/
(the not yet merged LTP Nikita's patch)
[3] https://github.com/pevik/ltp/commits/nfs_flock/fail-on-error
(my LTP fork with Nikita's patch [2] + strace debugging - with this code I post
the report)
Kind regards,
Petr
> NeilBrown
WARNING: multiple messages have this Message-ID (diff)
From: Petr Vorel <pvorel@suse.cz>
To: NeilBrown <neilb@suse.de>
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>,
Trond Myklebust <trond.myklebust@hammerspace.com>,
ltp@lists.linux.it,
Nikita Yushchenko <nikita.yushchenko@virtuozzo.com>
Subject: Re: [LTP] LTP nfslock01 test failing on NFS v3 (lockd: cannot monitor 10.0.0.2)
Date: Thu, 20 Jan 2022 13:24:09 +0100 [thread overview]
Message-ID: <YelUaQHlCp8FHAeQ@pevik> (raw)
In-Reply-To: <164254391708.24166.6930987548904227011@noble.neil.brown.name>
Hi Neil, all,
> On Wed, 19 Jan 2022, Petr Vorel wrote:
> > Hi all,
> > this is a test failure posted by Nikita Yushchenko [1]. LTP NFS test nfslock01
> > looks to be failing on NFS v3:
> > "not unsharing /var makes AF_UNIX socket for host's rpcbind to become available
> > inside ltpns. Then, at nfs3 mount time, kernel creates an instance of lockd for
> > ltpns, and ports for that instance leak to host's rpcbind and overwrite ports
> > for lockd already active for root namespace. This breaks nfs3 file locking."
> "not unsharing /var" .... can this be fixed by simply unsharing /var?
> Or is that not simple?
> On could easily argue that RPCBIND_SOCK_PATHNAME in the kernel should be
> changed to "/run/rpcbind.sock". Does this test suite unshare /run ??
> BTW, your email contains [1], [2], etc which suggests there are links
> somewhere - but there aren't.
I'm sorry, here they are:
[1] https://lore.kernel.org/ltp/590378ee-71af-deb6-6c03-1d2af459ed63@virtuozzo.com/
(the report)
[2] https://lore.kernel.org/ltp/20220112161942.4065665-1-nikita.yushchenko@virtuozzo.com/
(the not yet merged LTP Nikita's patch)
[3] https://github.com/pevik/ltp/commits/nfs_flock/fail-on-error
(my LTP fork with Nikita's patch [2] + strace debugging - with this code I post
the report)
Kind regards,
Petr
> NeilBrown
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2022-01-20 12:24 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
2022-01-19 5:28 ` [LTP] " Nikita Yushchenko via ltp
2022-01-20 12:24 ` Petr Vorel [this message]
2022-01-20 12:24 ` 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=YelUaQHlCp8FHAeQ@pevik \
--to=pvorel@suse.cz \
--cc=SteveD@redhat.com \
--cc=anna.schumaker@netapp.com \
--cc=bfields@fieldses.org \
--cc=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=ltp@lists.linux.it \
--cc=neilb@suse.de \
--cc=nikita.yushchenko@virtuozzo.com \
--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.