Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Steve Dickson" <steved@redhat.com>
Cc:     "Chuck Lever III" <chuck.lever@oracle.com>,
        "Benjamin Coddington" <bcodding@redhat.com>,
        "Trond Myklebust" <trondmy@hammerspace.com>,
        "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: Re: [PATCH/RFC] mount.nfs: handle EADDRINUSE from mount(2)
In-reply-to: <852313a3-005e-2771-8be1-888891370533@redhat.com>
References: <164816808982.6096.11435363819568479436@noble.neil.brown.name>,
 <852313a3-005e-2771-8be1-888891370533@redhat.com>
Date:   Thu, 07 Apr 2022 08:51:32 +1000
Message-id: <164928549280.10985.16998885406899511034@noble.neil.brown.name>
Precedence: bulk

On Thu, 07 Apr 2022, Steve Dickson wrote:
> Hey!
>=20
> My apologies for taking so long to get to this....

Better late than never !! :-)

>=20
> On 3/24/22 8:28 PM, NeilBrown wrote:
> >=20
> > [[This is the followup to the kernel patch I recently posted.
> >    It changes the behaviour of incorrectly configured containers to
> >    get unique client identities - so lease stealing doesn't happen
> >    so data corruption is avoided - but does not provide stable
> >    identities, so reboot recovery is not ideal.
> Which patch are you referring to and did it make it in?
>=20

https://lore.kernel.org/all/164816787898.6096.12819715693501838662@noble.neil=
.brown.name/

It hasn't landed, and I didn't expect it to (yet).  It is a basis for
discussion and experimentation.


> >    What is best to do when configuration is wrong?  Provide best service
> >    possible despite it not being perfect, or provide no service so the
> >    config will not get fixed.  I could be swayed either way.
> > ]]
> Maybe a little both? :-) Flag the broken config and continue on
> if possible... but flagging the broken config is more critical... IMHO.

I tend to agree, but it isn't clear how best to flag something in a way
that the flag will actually be seen.

>=20
> >=20
> > When NFS filesystems are mounted in different network namespaces, each
> > network namespace must provide a different hostname (via accompanying
> > UTS namespace) or different identifier (via sysfs).
> >=20
> > If the kernel finds that the identity that it constructs is already in
> > use in a different namespace it will fail the mount with EADDRINUSE.
> >=20
> > This patch catches that error and, if the sysfs identifier is unset,
> > writes a random string and retries.  This allows the mount to complete
> > safely even when misconfigured.  The random string has 128 bits of
> > entropy and so is extremely likely to be globally unique.
> >=20
> > A lock is taken on the identifier file, and it is only updated if no
> > identifier is set.  Thus two concurrent mount attempts will not generate
> > different identities.  The mount is retried in any case as a race may
> > have updated the identifier while waiting for the lock.
> >=20
> > This is not an ideal solution as an unclean restart of the host cannot
> > be detected by the server except by a lease timeout.  If the identifier
> > is configured correctly and is stable across restarts, the server can
> > detect the restart immediately.  Consequently a warning message is
> > generated to encourage correct configuration.
> Just curious... How did you test this patch? I would like
> to build an env to generate this type of error.

ip netns add foo
ip netns exec foo  ip link set dev lo up
ip link add veth0 type veth peer name veth1
ip link set veth1 netns foo

ip netns exec foo ifconfig veth1 10.1.1.1/24 up
ifconfig veth0 10.1.1.2/24 up

ip netns exec foo ip route add default via 10.1.1.2
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -j SNAT --to-source 10.0.2.15 -s 10.1.1.0/24

## At this point we have a separate network namespace which has network
## connectivity to anything the host can reach.
## The "--to-source" address is the IP address of the host - a qemu
## instance in this case.

# mount in the primary namespace
mount -o vers=3D4.1 server:/path /mnt

# attempt to mount in the alternate name space
ip netns exec foo mount -o vers=3D4.1 server:/path /mnt2

Note that "ip netns exec" creates a temporary mount namespace, so when
it exits, /mnt2 will no longer be mounted.  If you want to do more than
one thing you might need to
   ip netns exec foo /bin/sh my-shell-script
or
   ip netns exec foo /bin/bash -i
   # in a separate terminal window.

NeilBrown