All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton via Bugspray Bot <bugbot@kernel.org>
To: jlayton@kernel.org, aglo@umich.edu, linux-nfs@vger.kernel.org,
	 trondmy@kernel.org, anna@kernel.org, cel@kernel.org
Subject: Re: warning in nfsd4_cb_done
Date: Mon, 10 Feb 2025 15:45:13 +0000	[thread overview]
Message-ID: <20250210-b219737c9-d71d16c944ba@bugzilla.kernel.org> (raw)
In-Reply-To: <20250130-b219737c0-091f27de8b7a@bugzilla.kernel.org>

Jeff Layton writes via Kernel.org Bugzilla:

FYI:

521 == EBADHANDLE
10036 == NFS4ERR_BADXDR
3 == CB_GETATTR

The cb_status gets set via decode_cb_op_status() during the decode phase and is not cleared in nfsd4_cb_prepare.

Note that the code will call rpc_restart_call() in the NFS4ERR_DELAY case, which skips the  rpc_call_prepare phase when the task is restarted. So, I think this may go something like this:

Get a NFS4ERR_DELAY in a callback operation, that restarts the call but doesn't clear cb_status. Then on the next attempt, it gets a non-zero tk_status (and probably skips the decode phase). That would cause this warning to pop, I think.

In practice, I'm warming up to the idea that this entire if statement is just bogus:

        if (cb->cb_status) {
                WARN_ONCE(task->tk_status,
                          "cb_status=%d tk_status=%d cb_opcode=%d",
                          cb->cb_status, task->tk_status, cb->cb_ops->opcode);
                task->tk_status = cb->cb_status;
        }

Consider the case where we successfully decode a cb_status value but then some later field in the reply was corrupt. We will have set the cb_status, but the decode will fail which will cause the tk_status to be non-zero, and this warning will pop.

I think we should probably just remove the entire if statement above.

View: https://bugzilla.kernel.org/show_bug.cgi?id=219737#c9
You can reply to this message to join the discussion.
-- 
Deet-doot-dot, I am a bot.
Kernel.org Bugzilla (bugspray 0.1-dev)


  parent reply	other threads:[~2025-02-10 15:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-30 14:05 warning in nfsd4_cb_done rik.theys via Bugspray Bot
2025-01-30 14:10 ` Chuck Lever via Bugspray Bot
2025-01-30 15:08   ` Olga Kornievskaia
2025-01-30 15:20     ` Chuck Lever via Bugspray Bot
2025-01-30 15:20       ` Chuck Lever via Bugspray Bot
2025-01-30 15:55       ` Chuck Lever via Bugspray Bot
2025-01-30 14:20 ` rik.theys via Bugspray Bot
2025-02-04 13:30 ` rik.theys via Bugspray Bot
2025-02-04 13:30   ` Chuck Lever via Bugspray Bot
2025-02-10 15:03     ` Olga Kornievskaia
2025-02-10 16:35     ` Jeff Layton via Bugspray Bot
2025-02-10 15:45 ` Jeff Layton via Bugspray Bot [this message]
2025-02-10 16:45 ` Chuck Lever via Bugspray Bot
2025-02-24 11:55 ` rik.theys via Bugspray Bot
2025-02-24 12:20 ` Jeff Layton via Bugspray Bot

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=20250210-b219737c9-d71d16c944ba@bugzilla.kernel.org \
    --to=bugbot@kernel.org \
    --cc=aglo@umich.edu \
    --cc=anna@kernel.org \
    --cc=cel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.