Linux NFS development
 help / color / mirror / Atom feed
From: Benjamin Coddington <bcodding@redhat.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Trond Myklebust <trondmy@kernel.org>,
	Anna Schumaker <anna@kernel.org>,
	linux-nfs@vger.kernel.org
Subject: Re: [PATCH 1/2] NFSv4: Ensure test_and_free_stateid callers use private memory
Date: Wed, 23 Apr 2025 18:04:37 -0400	[thread overview]
Message-ID: <85735CF0-FB7E-4B76-AABA-770D199D435A@redhat.com> (raw)
In-Reply-To: <851b8c0884038fd496517cce61ef2c53b41ed8a2.camel@kernel.org>

On 23 Apr 2025, at 16:35, Jeff Layton wrote:

> On Wed, 2025-04-23 at 13:59 -0400, Benjamin Coddington wrote:
>> A follow-up patch intends to signal the success or failure of FREE_STATEID
>> by modifying the nfs4_stateid's type which requires the const qualifier for
>> the nfs4_stateid to be dropped.  Since it will no longer safe to operate
>> directly on shared stateid objects in this path, ensure that callers send a
>> copy.
>>
>> Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
>> ---
>>  fs/nfs/nfs4proc.c | 12 +++++++-----
>>  1 file changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
>> index 6e95db6c17e9..bfb9e980d662 100644
>> --- a/fs/nfs/nfs4proc.c
>> +++ b/fs/nfs/nfs4proc.c
>> @@ -2990,6 +2990,7 @@ static void nfs41_delegation_recover_stateid(struct nfs4_state *state)
>>  static int nfs41_check_expired_locks(struct nfs4_state *state)
>>  {
>>  	int status, ret = NFS_OK;
>> +	nfs4_stateid stateid;
>>  	struct nfs4_lock_state *lsp, *prev = NULL;
>>  	struct nfs_server *server = NFS_SERVER(state->inode);
>>
>> @@ -3007,9 +3008,9 @@ static int nfs41_check_expired_locks(struct nfs4_state *state)
>>  			nfs4_put_lock_state(prev);
>>  			prev = lsp;
>>
>> +			nfs4_stateid_copy(&stateid, &lsp->ls_stateid);
>>  			status = nfs41_test_and_free_expired_stateid(server,
>> -					&lsp->ls_stateid,
>> -					cred);
>> +					&stateid, cred);
>>  			trace_nfs4_test_lock_stateid(state, lsp, status);
>>  			if (status == -NFS4ERR_EXPIRED ||
>>  			    status == -NFS4ERR_BAD_STATEID) {
>> @@ -3042,17 +3043,18 @@ static int nfs41_check_expired_locks(struct nfs4_state *state)
>>  static int nfs41_check_open_stateid(struct nfs4_state *state)
>>  {
>>  	struct nfs_server *server = NFS_SERVER(state->inode);
>> -	nfs4_stateid *stateid = &state->open_stateid;
>> +	nfs4_stateid stateid;
>>  	const struct cred *cred = state->owner->so_cred;
>>  	int status;
>>
>>  	if (test_bit(NFS_OPEN_STATE, &state->flags) == 0)
>>  		return -NFS4ERR_BAD_STATEID;
>> -	status = nfs41_test_and_free_expired_stateid(server, stateid, cred);
>> +	nfs4_stateid_copy(&stateid, &state->open_stateid);
>> +	status = nfs41_test_and_free_expired_stateid(server, &stateid, cred);
>>  	trace_nfs4_test_open_stateid(state, NULL, status);
>>  	if (status == -NFS4ERR_EXPIRED || status == -NFS4ERR_BAD_STATEID) {
>>  		nfs_state_clear_open_state_flags(state);
>> -		stateid->type = NFS4_INVALID_STATEID_TYPE;
>> +		state->open_stateid.type = NFS4_INVALID_STATEID_TYPE;
>>  		return status;
>>  	}
>>  	if (nfs_open_stateid_recover_openmode(state))
>
> I don't know that you really need to do this. In the cases where you
> end up setting the type to FREED, you will also return NFS4ERR_EXPIRED,
> which will make the callers set the type to INVALID.
>
> There will be a brief window where the type will be set to FREED, but
> that should be no big deal.

Definitely playing it safe here, I think I have to worry about concurrency -
who else might be simultaneously looking at that nfs4_state->open_stateid.type?
I really don't want to introduce a regression because we knew we weren't
modifying that stateid before.

I suppose I can dive into an audit and see if that can actually happen.

Thanks for looking at this,

Ben


  reply	other threads:[~2025-04-23 22:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-23 17:59 [PATCH 0/2] Allow FREE_STATEID to free delegations Benjamin Coddington
2025-04-23 17:59 ` [PATCH 1/2] NFSv4: Ensure test_and_free_stateid callers use private memory Benjamin Coddington
2025-04-23 20:35   ` Jeff Layton
2025-04-23 22:04     ` Benjamin Coddington [this message]
2025-04-29 14:01       ` Benjamin Coddington
2025-04-23 17:59 ` [PATCH 2/2] NFSv4: Allow FREE_STATEID to clean up delegations Benjamin Coddington
2025-04-23 19:41   ` Jeff Layton
2025-04-23 19:59     ` Benjamin Coddington
2025-04-23 20:37       ` Jeff Layton
2025-04-23 22:12         ` Benjamin Coddington

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=85735CF0-FB7E-4B76-AABA-770D199D435A@redhat.com \
    --to=bcodding@redhat.com \
    --cc=anna@kernel.org \
    --cc=jlayton@kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=trondmy@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox