mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chuck Lever <chuck.lever@oracle.com>
To: "Tyler W. Ross" <TWR@tylerwross.com>
Cc: "1120598@bugs.debian.org" <1120598@bugs.debian.org>,
	Jeff Layton <jlayton@kernel.org>, NeilBrown <neil@brown.name>,
	Scott Mayhew <smayhew@redhat.com>,
	Steve Dickson <steved@redhat.com>,
	Salvatore Bonaccorso <carnil@debian.org>,
	Olga Kornievskaia <okorniev@redhat.com>,
	Dai Ngo <Dai.Ngo@oracle.com>, Tom Talpey <tom@talpey.com>,
	Trond Myklebust <trondmy@kernel.org>,
	Anna Schumaker <anna@kernel.org>,
	linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: ls input/output error ("NFS: readdir(/) returns -5") on krb5 NFSv4 client using SHA2
Date: Thu, 13 Nov 2025 13:57:20 -0500	[thread overview]
Message-ID: <943d3e48-9582-4521-9cc8-eb84eb72d788@oracle.com> (raw)
In-Reply-To: <eUtqaTOrHO8Sj-82m04dsCpmYX8bPkr5r9Nla1muHxSnxBYq57wxk7LLf_RuI377WMpUcczBXteWGvF5OfNfe5gwLmfTn_YblJucaF58POo=@tylerwross.com>

On 11/13/25 1:51 PM, Tyler W. Ross wrote:
> On Thursday, November 13th, 2025 at 11:12 AM, Chuck Lever <chuck.lever@oracle.com> wrote:
> 
>> Then I would start looking for differences between the Debian 13 and
>> Fedora 43 kernel code base under net/sunrpc/ .
>>
>> Alternatively, "git bisect first, ask questions later" ... :-)
> 
> This is outside my day-to-day, so I don't have a workflow for this kind of
> testing/debugging, but I'll see what I can do.
> 
> Thanks for the starting place.
> 
>> So I didn't find an indication of whether this was sec=krb5, sec=krb5i,
>> or sec=krb5p. That might narrow down where the code changed.
> 
> I confirmed the issue with all 3 krb5 sec modes, in both the 6.12 kernel
> that ships with Debian 13 and the 6.17 that currently ships with Debian
> Sid/unstable. Similarly, I confirmed NFSv4.2, 4.1 and 4.0 are impacted.
> 
>> Also, the xdr_buf might have a page boundary positioned in the middle of
>> an XDR data item. Knowing which data item is being decoded where the
>> "overflow" occurs might be helpful (I think adding pr_info() call sites
>> or trace_printk() will be adequate to gain some better observability).
> 
> No experience with kernel hacking, so I'm not confident I can locate
> meaningful places to insert those.
> 
> I'll see where some snooping and a bisect gets me. Failing that, if
> anyone has recommendations on where to add those calls, I'd appreciate
> the guidance.

xdr_inline_decode(). Easiest approach (but somewhat noisy) would be to
add a WARN_ON just after each of the trace_rpc_xdr_overflow() call
sites. The stack trace on the failing decode will be dumped into the
system journal.


-- 
Chuck Lever

  reply	other threads:[~2025-11-13 18:57 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <176298368872.955.14091113173156448257.reportbug@nfsclient-sid.ipa.twrlab.net>
2025-11-13  5:00 ` Salvatore Bonaccorso
2025-11-13 14:30   ` Chuck Lever
2025-11-13 17:16     ` Tyler W. Ross
2025-11-13 17:47       ` Chuck Lever
2025-11-13 18:05         ` Tyler W. Ross
2025-11-13 18:12           ` Chuck Lever
2025-11-13 18:51             ` Tyler W. Ross
2025-11-13 18:57               ` Chuck Lever [this message]
2025-11-13 21:21         ` Salvatore Bonaccorso
2025-11-13 21:23           ` Chuck Lever
2025-11-13 22:20             ` Salvatore Bonaccorso
2025-11-13 22:30               ` Chuck Lever
2025-11-14  4:35                 ` Tyler W. Ross
2025-11-14  5:09                   ` Tyler W. Ross
2025-11-14 14:18                     ` Chuck Lever
2025-11-16  0:38                       ` Tyler W. Ross
2025-11-16 16:29                         ` Chuck Lever
2025-11-16 18:21                           ` Trond Myklebust
2025-11-17  5:19                             ` Tyler W. Ross
2025-11-17 13:41                               ` Chuck Lever
2025-11-17 18:38                                 ` Tyler W. Ross
2025-11-17 23:05                               ` Scott Mayhew
2025-11-17 22:54                             ` Scott Mayhew
2025-11-18  4:10                               ` Tyler W. Ross
2025-11-18 17:52                                 ` Scott Mayhew
2025-11-18 23:43                                   ` Tyler W. Ross
2025-11-19  4:50                                     ` Salvatore Bonaccorso
2025-11-19 13:36                                       ` Scott Mayhew
2025-11-19 20:54                                       ` Simon Josefsson
2025-11-18  4:32 Tyler W. Ross
2025-11-19 17:19 Tyler W. Ross

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=943d3e48-9582-4521-9cc8-eb84eb72d788@oracle.com \
    --to=chuck.lever@oracle.com \
    --cc=1120598@bugs.debian.org \
    --cc=Dai.Ngo@oracle.com \
    --cc=TWR@tylerwross.com \
    --cc=anna@kernel.org \
    --cc=carnil@debian.org \
    --cc=jlayton@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nfs@vger.kernel.org \
    --cc=neil@brown.name \
    --cc=okorniev@redhat.com \
    --cc=smayhew@redhat.com \
    --cc=steved@redhat.com \
    --cc=tom@talpey.com \
    --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

all inboxes | Powered by JetHome®