Opened 6 months ago

Closed 4 months ago

#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 6 months ago.
syslog_BFS (6.8 KB) - added by vidrep 6 months ago.
syslog_FAT (4.6 KB) - added by vidrep 6 months ago.
error.png (80.8 KB) - added by vidrep 6 months ago.

Download all attachments as: .zip

Change History (25)

Changed 6 months ago by vidrep

Attachment: syslog_NTFS added

Changed 6 months ago by vidrep

Attachment: syslog_BFS added

Changed 6 months ago by vidrep

Attachment: syslog_FAT added

Changed 6 months ago by vidrep

Attachment: error.png added

comment:1 Changed 6 months ago by vidrep

I switched to another PC with hrev51986 installed - working

After a pkgman update to hrev52013 - not working

comment:2 Changed 6 months ago by waddlesplash

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 Changed 6 months ago by waddlesplash

Owner: changed from nobody to korli
Status: newassigned

comment:4 Changed 6 months ago by waddlesplash

7:51 PM <Vidrep_gcc2h> hrev52009 not working

comment:5 Changed 6 months ago by 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?

comment:6 Changed 6 months ago by waddlesplash

Vidrep also reports that the system will not shut down.

comment:7 Changed 6 months ago by waddlesplash

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

Guess that belongs in another ticket, then.

comment:8 Changed 6 months ago by 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.

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

comment:9 Changed 6 months ago by vidrep

Narrowed down a bit further.

hrev52009 - working

hrev52012 - not working

comment:10 Changed 6 months ago by waddlesplash

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

comment:11 Changed 6 months ago by vidrep

After updating to hrev52017 NTFS mounting is working again.

comment:12 Changed 6 months ago by cocobean

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

comment:13 Changed 6 months ago by waddlesplash

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 Changed 6 months ago by waddlesplash

Blocking: 14211 added

comment:15 Changed 5 months ago by korli

Real fix applied in hrev52048.

comment:16 Changed 5 months ago by 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.

comment:17 Changed 5 months ago by 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?

comment:18 Changed 5 months ago by pulkomandy

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

comment:19 Changed 5 months ago by 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().

comment:20 Changed 5 months ago by 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.

comment:21 Changed 4 months ago by korli

Resolution: fixed
Status: assignedclosed

Closing.

Note: See TracTickets for help on using tickets.