[COMPAT MODE] Cannot mount NTFS formatted USB stick

[vidrep]

hrev52013 x86_64 and x86_gcc2h

Inserting any NTFS formatted USB drive will generate a general system error when mounting.

BFS and FAT formatted drives seem to work OK

Syslogs attached for each.

[vidrep]

I switched to another PC with hrev51986 installed - working

After a pkgman update to hrev52013 - not working

[waddlesplash]

Looks like korli's compat mode changes broke something.

7:34 PM <Vidrep_gcc2h> hrev52002 is working

[waddlesplash]

7:51 PM <Vidrep_gcc2h> hrev52009 not working

[waddlesplash]

I was under the impression that the compat-mode code is ifdef'd out on 32-bit, but it looks like in some of those commits that's not the case?

[waddlesplash]

Vidrep also reports that the system will not shut down.

[waddlesplash]

8:30 PM <Vidrep_gcc2h> hrev52009 shuts down cleanly. hrev52013 hangs every time

Guess that belongs in another ticket, then.

[cocobean]

Retested on hrev52014 x86_64 - FAT32/exFAT work, NTFS won't mount giving GSF error. Retested on hrev51986 x86_64 - FAT32/exFAT/NTFS work, no errors.

[vidrep]

Narrowed down a bit further.

hrev52009 - working

hrev52012 - not working

[waddlesplash]

hrev520010 & hrev520011 reverted in hrev52016, please retest after that.

[vidrep]

After updating to hrev52017 NTFS mounting is working again.

[cocobean]

Tested hrev52017 x86_64. NTFS R/W mounts working again. Tested two different vendor NTFS-formatted external USB drives. Confirmed as fixed.

[waddlesplash]

Good. Moving out of beta1 milestone then.

[korli]

Real fix applied in hrev52048.

[waddlesplash]

Nice.

At this point, though, @korli -- perhaps we should wait until after beta1 to merge the patchset; seeing as it may uncover more subtle bugs like these.

[waddlesplash]

I wonder, though: perhaps we should add an ASSERT to user_memcpy to check if it IS_USER_ADDRESS -- or is there some scenario that it would not be, but that would be legal?

[pulkomandy]

An assert? which would, like, trigger a KDL?

[korli]

user_memcpy() has two parameters, source and destination, to rewrite what you said, you would like to assert than one of both is a user address. You could also add the check to the normal memcpy() but it is actually used by user_memcpy().

[waddlesplash]

Yeah, it would trigger a KDL. Essentially this is the reverse of SMAP: SMAP makes sure you don't access user memory through an improper channel. Adding these asserts will prevent using user_memcpyfor copying kernel buffers.

OK, thanks for the tip, I'll try it that way.

[korli]

Closing.