fs/ntfs3: Fix memory corruption when page_size changes

[popcornmix]

The rework in fs/ntfs3: Reduce stack usage
changes log->page_size but doesn't change the associated log->page_mask and log->page_bits.

That results in the bytes value in read_log_page
getting a negative value, which is bad when it is
passed to memcpy.

The kernel panic can be observed when connecting an ntfs formatted drive that has previously been connected to a Windows machine to a Raspberry Pi 5, which by defauilt uses a 16K kernel pagesize.

Fixes: 865e7a7 ("fs/ntfs3: Reduce stack usage")

[popcornmix]

Some of the bug reports for this:
#6036
https://forum.libreelec.tv/thread/28620-libreelec-12-0-rpi5-and-ntfs-hdd-problem/?postID=192713#post192713
https://forums.raspberrypi.com/viewtopic.php?p=2203090#p2203090
https://forums.raspberrypi.com/viewtopic.php?t=367545

[6by9]

It'd be worth throwing that patch upstream for review.

[PatrickGlatt]

I’m affected by the issue with my over 35 external NTFS HDDs (my user there is Patrick_G): https://forums.raspberrypi.com/viewtopic.php?p=2218370#p2218370

I could test it with my Pi 5. Please let me know if there is a build I could install, as the user “dom” suggested. It seems like the current pull request is failing? Should I try running “sudo rpi-update pulls/6218”?

[pelwell]

Yes - the checkpatch failure is only advisory.

[PatrickGlatt]

So, this took me some time. I attempted the update three times this evening, and the first attempt failed completely. If your Raspberry Pi has already updated to 6.6 and some disk issues persist, it might be better to downgrade to 6.1.

Here’s the method that worked to get the Pi running:
1.) Shut down the Raspberry Pi 5 and disconnect all disks.
2.) Run sudo rpi-update pulls/6218 and restart the Pi.
3.) Clean the media folder from dead disk folders using sudo rm -rf /media/[username]/*.
4.) Connect all drives to the pi one by one.
5.) Restart the Pi. (Attention mounting the disks takes now some time, for me its over 2 minutes with 30 disks)

BUT! However, one issue still persists. The disks mount very, very slowly with this 6.6 kernel. It takes over 2 minutes to mount my 30 USB HDD drives. With kernel 6.1, it was about 30 seconds. But it seems this updated kernel 6.6 doesn’t freeze anymore.

I will now run the pi with this 6.6 kernel but something is still broken with mounting a lot of ntfs drives. Specially after a reboot.
my kernel Version is now: Linux raspberrypi 6.6.32-v8-16k+ #1 SMP PREEMPT Tue Jun 11 16:25:32 UTC 2024 aarch64 GNU/Linux

[PatrickGlatt]

Update2: After a restart (crash or power loss idk) 3 HDDs are missing again. Seems this fix didnt help :(
Moved back to kernel 6.1 and everything works fine again. HDDs needed to be connected manually again.

[popcornmix]

Post the dmesg output from the 6.6 boot with missing drives.

[popcornmix]

@6by9 submited but no response so far:
https://lore.kernel.org/ntfs3/CAEi1pCSQePMo4X_RvMfYmpxYwmuamhd8=1OXgNCU-N2BBdTXPg@mail.gmail.com/T/#t

[popcornmix]

Two reports of this fixing the issue here

[PatrickGlatt]

Are the logs still available? or only a few hour days?
Any idea why the mounting of ntfs drives is so slow on 6.6 and on 6.1 not?

[popcornmix]

Are the logs still available? or only a few hour days?

dmesg logs are available until they are overwritten.
On a normally working system that should still be there, but you may lose the start if there are many messages.

But you can always reboot and capture a fresh log (I assume the failure is repeatable?)

dmesg | pastebinit and post the url.

Any idea why the mounting of ntfs drives is so slow on 6.6 and on 6.1 not?

No, and that's not going to be related to this issue. You should create a new one.

[popcornmix]

No response after a week from submission upstream.

Suggest we just merge this as it has reports of fixing a clear error.

[lategoodbye]

@6by9 submited but no response so far: https://lore.kernel.org/ntfs3/CAEi1pCSQePMo4X_RvMfYmpxYwmuamhd8=1OXgNCU-N2BBdTXPg@mail.gmail.com/T/#t

Thanks for reporting this upstream. Maybe the maintainer is not comfortable with bug reports from a vendor tree plus a non-recent Kernel version (6.9.x or 6.10-rcX is more welcome). At least the regression is on the tracker list, so in case the maintainer doesn't react this would be escalated.

[popcornmix]

I can confirm that bug is present in our rpi-6.10-y tree, and the fix still works.