Received-SPF: pass (google.com: domain of linux-nfs+bounces-3251-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Precedence: bulk
MIME-Version: 1.0
From: Olga Kornievskaia <aglo@umich.edu>
Date: Tue, 14 May 2024 16:56:42 -0400
Message-ID: <CAN-5tyFBn3C_CTrsftuYeWJHe7KWxd82YFCyrN9t=az8J4RU0w@mail.gmail.com>
Subject: sm notify (nlm) question
To: linux-nfs <linux-nfs@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"

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. A
NOTIFY message that is sent by an NFS server upon reboot has a monitor
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?

I'd appreciate the feedback.