Received-SPF: pass (google.com: domain of linux-nfs+bounces-3253-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <CAN-5tyFBn3C_CTrsftuYeWJHe7KWxd82YFCyrN9t=az8J4RU0w@mail.gmail.com>
 <2C80B5BC-AAEC-41F8-BEB6-C920F88C89BB@oracle.com>
In-Reply-To: <2C80B5BC-AAEC-41F8-BEB6-C920F88C89BB@oracle.com>
From: Olga Kornievskaia <aglo@umich.edu>
Date: Tue, 14 May 2024 17:21:40 -0400
Message-ID: <CAN-5tyGxDtO7BuXvU=MQKad3W9+Zsf_9BMB5Hojnyy6bQ6fj0w@mail.gmail.com>
Subject: Re: sm notify (nlm) question
To: Chuck Lever III <chuck.lever@oracle.com>
Cc: Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 14, 2024 at 5:09=E2=80=AFPM Chuck Lever III <chuck.lever@oracle=
.com> wrote:
>
>
>
> > On May 14, 2024, at 2:56=E2=80=AFPM, Olga Kornievskaia <aglo@umich.edu>=
 wrote:
> >
> > Hi folks,
> >
> > Given that not everything for NFSv3 has a specification, I post a
> > question here (as it concerns linux v3 (client) implementation) but I
> > ask a generic question with respect to NOTIFY sent by an NFS server.
>
> There is a standard:
>
> https://pubs.opengroup.org/onlinepubs/9629799/chap11.htm

Thank you Chuck. This too does not give any limits as to the
uniqueness of the state value.

> > A NOTIFY message that is sent by an NFS server upon reboot has a monito=
r
> > name and a state. This "state" is an integer and is modified on each
> > server reboot. My question is: what about state value uniqueness? Is
> > there somewhere some notion that this value has to be unique (as in
> > say a random value).
> >
> > Here's a problem. Say a client has 2 mounts to ip1 and ip2 (both
> > representing the same DNS name) and acquires a lock per mount. Now say
> > each of those servers reboot. Once up they each send a NOTIFY call and
> > each use a timestamp as basis for their "state" value -- which very
> > likely is to produce the same value for 2 servers rebooted at the same
> > time (or for the linux server that looks like a counter). On the
> > client side, once the client processes the 1st NOTIFY call, it updates
> > the "state" for the monitor name (ie a client monitors based on a DNS
> > name which is the same for ip1 and ip2) and then in the current code,
> > because the 2nd NOTIFY has the same "state" value this NOTIFY call
> > would be ignored. The linux client would never reclaim the 2nd lock
> > (but the application obviously would never know it's missing a lock)
> > --- data corruption.
> >
> > Who is to blame: is the server not allowed to send "non-unique" state
> > value? Or is the client at fault here for some reason?
>
> The state value is supposed to be specific to the monitored
> host. If the client is indeed ignoring the second reboot
> notification, that's incorrect behavior, IMO.

State is supposed to help against replays I think. This client is in
its right to update the state value upon processing a reboot
notification.
The fact that another sm_notiffy comes with the same state (and from
the same DNS name monitor name) seems logical that can be a re-try and
thus grounds for ignoring it.


>
>
> --
> Chuck Lever
>
>