#14204 closed bug (fixed)

[COMPAT MODE] Cannot mount NTFS formatted USB stick

Reported by: vidrep Owned by: korli
Priority: normal Milestone: Unscheduled
Component: System/Kernel Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #14211
Has a Patch: no Platform: All

Description

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.

Attachments (4)

syslog_NTFS (4.3 KB ) - added by vidrep 15 months ago.
syslog_BFS (6.8 KB ) - added by vidrep 15 months ago.
syslog_FAT (4.6 KB ) - added by vidrep 15 months ago.
error.png (80.8 KB ) - added by vidrep 15 months ago.

Download all attachments as: .zip

Change History (25)

by vidrep, 15 months ago

Attachment: syslog_NTFS added

by vidrep, 15 months ago

Attachment: syslog_BFS added

by vidrep, 15 months ago

Attachment: syslog_FAT added

by vidrep, 15 months ago

Attachment: error.png added

comment:1 by vidrep, 15 months ago

I switched to another PC with hrev51986 installed - working

After a pkgman update to hrev52013 - not working

comment:2 by waddlesplash, 15 months ago

Component: - GeneralSystem/Kernel
Milestone: UnscheduledR1/beta1
Priority: normalblocker

Looks like korli's compat mode changes broke something.

7:34 PM <Vidrep_gcc2h> hrev52002 is working

comment:3 by waddlesplash, 15 months ago

Owner: changed from nobody to korli
Status: newassigned

comment:4 by waddlesplash, 15 months ago

7:51 PM <Vidrep_gcc2h> hrev52009 not working

comment:5 by waddlesplash, 15 months ago

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?

comment:6 by waddlesplash, 15 months ago

Vidrep also reports that the system will not shut down.

comment:7 by waddlesplash, 15 months ago

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

Guess that belongs in another ticket, then.

comment:8 by cocobean, 15 months ago

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.

Last edited 15 months ago by cocobean (previous) (diff)

comment:9 by vidrep, 15 months ago

Narrowed down a bit further.

hrev52009 - working

hrev52012 - not working

comment:10 by waddlesplash, 15 months ago

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

comment:11 by vidrep, 15 months ago

After updating to hrev52017 NTFS mounting is working again.

comment:12 by cocobean, 15 months ago

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

comment:13 by waddlesplash, 14 months ago

Milestone: R1/beta1Unscheduled
Priority: blockernormal
Summary: Cannot mount NTFS formatted USB stick[COMPAT MODE] Cannot mount NTFS formatted USB stick

Good. Moving out of beta1 milestone then.

comment:14 by waddlesplash, 14 months ago

Blocking: 14211 added

comment:15 by korli, 14 months ago

Real fix applied in hrev52048.

comment:16 by waddlesplash, 14 months ago

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.

comment:17 by waddlesplash, 13 months ago

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?

comment:18 by pulkomandy, 13 months ago

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

comment:19 by korli, 13 months ago

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().

comment:20 by waddlesplash, 13 months ago

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.

comment:21 by korli, 13 months ago

Resolution: fixed
Status: assignedclosed

Closing.

Note: See TracTickets for help on using tickets.