From: Anna Schumaker <[email protected]>
This reverts commit 7fd461c47c6cfab4ca4d003790ec276209e52978.
Unfortunately, it has come to our attention that there is still a bug
somewhere in the READ_PLUS code that can result in nfsroot systems on
ARM to crash during boot.
Let's do the right thing and revert this change so we don't break
people's nfsroot setups.
Signed-off-by: Anna Schumaker <[email protected]>
---
fs/nfs/Kconfig | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/fs/nfs/Kconfig b/fs/nfs/Kconfig
index 1ead5bd740c2..14a72224b657 100644
--- a/fs/nfs/Kconfig
+++ b/fs/nfs/Kconfig
@@ -209,8 +209,8 @@ config NFS_DISABLE_UDP_SUPPORT
config NFS_V4_2_READ_PLUS
bool "NFS: Enable support for the NFSv4.2 READ_PLUS operation"
depends on NFS_V4_2
- default y
+ default n
help
- Choose Y here to enable the use of READ_PLUS over NFS v4.2. READ_PLUS
- attempts to improve read performance by compressing out sparse holes
- in the file contents.
+ This is intended for developers only. The READ_PLUS operation has
+ been shown to have issues under specific conditions and should not
+ be used in production.
--
2.39.1
On 15.02.23 22:49, Anna Schumaker wrote:
> From: Anna Schumaker <[email protected]>
>
> This reverts commit 7fd461c47c6cfab4ca4d003790ec276209e52978.
>
> Unfortunately, it has come to our attention that there is still a bug
> somewhere in the READ_PLUS code that can result in nfsroot systems on
> ARM to crash during boot.
>
> Let's do the right thing and revert this change so we don't break
> people's nfsroot setups.
Many thx for taking care of this.
Do you plan to send this to Linus before he releases the final? Or
should I point him to this patch (or a later version) in my weekly
report so that he can decide himself if he wants to pick it up?
There is afaics also one small thing to improve, please add the
following tags to make things easier for future code archaeologists:
Reported-by: Krzysztof Kozlowski <[email protected]>
Link:
https://lore.kernel.org/all/[email protected]/
To explain: Linus[1] and others considered proper link tags with the URL
to the report important, as they allow anyone to look into the backstory
of a fix weeks or years later. That's nothing new, the documentation[2]
for some time says to place such tags in cases like this. I care
personally (and made it a bit more explicit in the docs a while ago),
because these tags make my regression tracking efforts a whole lot
easier, as they allow my tracking bot 'regzbot' to automatically connect
reports with patches posted or committed to fix tracked regressions.
Apropos regzbot, let me tell regzbot to monitor this thread:
#regzbot ^backmonitor:
https://lore.kernel.org/all/[email protected]/
> Signed-off-by: Anna Schumaker <[email protected]>
> [...]
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
[1] for details, see:
https://lore.kernel.org/all/CAHk-=wjMmSZzMJ3Xnskdg4+GGz=5p5p+GSYyFBTh0f-DgvdBWg@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wgs38ZrfPvy=nOwVkVzjpM3VFU1zobP37Fwd_h9iAD5JQ@mail.gmail.com/
https://lore.kernel.org/all/CAHk-=wjxzafG-=J8oT30s7upn4RhBs6TX-uVFZ5rME+L5_DoJA@mail.gmail.com/
[2] see Documentation/process/submitting-patches.rst
(http://docs.kernel.org/process/submitting-patches.html) and
Documentation/process/5.Posting.rst
(https://docs.kernel.org/process/5.Posting.html)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.