Received-SPF: pass (google.com: domain of linux-nfs+bounces-208-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
From: Benjamin Coddington <bcodding@redhat.com>
To: Dan Aloni <dan.aloni@vastdata.com>
Cc: linux-nfs@vger.kernel.org
Subject: Re: mount options not propagating to NFSACL and NSM RPC clients
Date: Thu, 30 Nov 2023 09:30:52 -0500
Message-ID: <8FDECCA5-80E0-4CB4-B790-4039102916F0@redhat.com>
In-Reply-To: <20231129132034.lz3hag5xy2oaojwq@gmail.com>
References: <20231105154857.ryakhmgaptq3hb6b@gmail.com>
 <80B8993C-645D-4748-93B3-88415E165B87@redhat.com>
 <20231129132034.lz3hag5xy2oaojwq@gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain

On 29 Nov 2023, at 8:20, Dan Aloni wrote:

> On 2023-11-07 08:46:54, Benjamin Coddington wrote:
>> Hi Dan,
>>
>> On 5 Nov 2023, at 10:48, Dan Aloni wrote:
>>
>>> Hi,
>>>
>>> On Linux v6.6-14500-g1c41041124bd, I added a sysfs file for debugging
>>> `/sys/kernel/debug/sunrpc/rpc_clnt/*/info`, and noticed that when
>>> passing the following mount options: `soft,timeo=50,retrans=16,vers=3`,
>>> NFSACL and NSM seem to take the defaults from somewhere else (xprt).
>>> Specifically, locking operation behave as if in a hard mount with
>>> these mount options.
>>>
>>> Is it intentional?
>>
>> Yes, it usually is intentional.  The various rpc clients that make parts of
>> NFS work don't all inherit the mount flags due to reasons about how the
>> system should behave as a whole.  I think that you can find usually find the
>> reasoning the git logs around "struct rpc_create_args".
>>
>> Are you getting a system hung up in a lock operation?
>
> Actually my concern is the NFSACL prog. With `cl_softrtrt == 1` and
> `to_initval == to_maxval`, does it mean retires will not happen
> regardless of `to_retries` and `to_increment`?

Possibly?  I'm not exactly certain of what should happen in that case.

> I encountered a situation where the NFSACL program did not retry but
> could have had, whereas NFS3 did successfully. Not sure regarding NSM,
> but it seems to me that it would make sense at least for NFSACL to
> behave the same as NFS3.

I agree, but I could be missing something -- maybe its a bug.  There's the
sunrpc:rpc_timeout_status tracepoint that might be helpful.  If you turn
that up can you see rpc_check_timeout() getting called from
call_transmit_status()?

Sorry, I know this isn't a lot of help so far.

Ben