Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
Message-ID: <ac51e942-7348-411d-8532-99fe0101df2b@leemhuis.info>
Date:   Wed, 27 Sep 2023 15:30:20 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Reply-To: Linux regressions mailing list <regressions@lists.linux.dev>
Subject: Re: Data corruption with 5.10.x client -> 6.5.x server
Content-Language: en-US, de-DE
To:     =?UTF-8?Q?Mantas_Mikul=C4=97nas?= <grawity@gmail.com>,
        linux-nfs@vger.kernel.org,
        Linux kernel regressions list <regressions@lists.linux.dev>
References: <f1d0b234-e650-0f6e-0f5d-126b3d51d1eb@gmail.com>
From:   "Linux regression tracking #adding (Thorsten Leemhuis)" 
        <regressions@leemhuis.info>
In-Reply-To: <f1d0b234-e650-0f6e-0f5d-126b3d51d1eb@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Precedence: bulk

[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]

[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]

On 24.09.23 15:07, Mantas Mikulėnas wrote:
> I've recently upgraded my home NFS server from 6.4.12 to 6.5.4 (running
> Arch Linux x86_64).
> 
> Now, when I'm accessing the server over NFSv4.2 from a client that's
> running 5.10.0 (32-bit x86, Debian 11), if the mount is using sec=krb5i
> or sec=krb5p, trying to read a file that's <= 4092 bytes in size will
> return all-zero data. (That is, `hexdump -C file` shows "00 00 00...")
> Files that are 4093 bytes or larger seem to be unaffected.
> 
> Only sec=krb5i/krb5p are affected by this – plain sec=krb5 (or sec=sys
> for that matter) seems to work without any problems.
> 
> Newer clients (like 6.1.x or 6.4.x) don't seem to have any issues, it's
> only 5.10.0 that does... though it might also be that the client is
> 32-bit, but the same client did work previously when the server was
> running older kernels, so I still suspect 6.5.x on the server being the
> problem.
> 
> Upgrading to 6.6.0-rc2 on the server hasn't changed anything.
> The server is using Btrfs but I've tested with tmpfs as well.

Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:

#regzbot ^introduced 703d7521555504b3a316b105b4806d641
#regzbot title nfs: Data corruption with 5.10.x client -> 6.5.x server
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.

Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.