NetBSD Problem Report #59152

From paul@whooppee.com  Fri Mar  7 22:34:03 2025
Return-Path: <paul@whooppee.com>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 7D5CC1A9239
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  7 Mar 2025 22:34:03 +0000 (UTC)
Message-Id: <20250307223330.2E45149A967@speedy.whooppee.com>
Date: Fri,  7 Mar 2025 14:33:30 -0800 (PST)
From: paul@whooppee.com
Reply-To: paul@whooppee.com
To: gnats-bugs@NetBSD.org
Subject: Panic in genfs(?) onn HEAD amd64
X-Send-Pr-Version: 3.95

>Number:         59152
>Category:       kern
>Synopsis:       kernel panic on current - genfs ?
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Mar 07 22:35:00 +0000 2025
>Last-Modified:  Mon Mar 10 07:55:00 +0000 2025
>Originator:     Paul Goyette
>Release:        NetBSD 10.99.12
>Organization:
+---------------------+--------------------------+----------------------+
| Paul Goyette (.sig) | PGP Key fingerprint:     | E-mail addresses:    |
| (Retired)           | 1B11 1849 721C 56C8 F63A | paul@whooppee.com    |
| Software Developer  | 6E2E 05FD 15CE 9F2D 5102 | pgoyette@netbsd.org  |
| & Network Engineer  |                          | pgoyette99@gmail.com |
+---------------------+--------------------------+----------------------+
>Environment:


System: NetBSD speedy.whooppee.com 10.99.12 NetBSD 10.99.12 (SPEEDY 2025-02-09 23:04:47 UTC) #0: Mon Feb 10 04:36:23 UTC 2025 paul@speedy.whooppee.com:/build/netbsd-local/obj/amd64/sys/arch/amd64/compile/SPEEDY amd64
Architecture: x86_64
Machine: amd64
>Description:
When attempting to audioplay(1) a file located on a ntfs file system, I
get a repeatable crash in genfs. Backtrace is always 

[   260.565864] panic: kernel diagnostic assertion "(flags & UFP_NOBUSY) != 0 || rw_write_held(uobj->vmobjlock)" failed: file "/build/netbsd-local/src_ro/sys/uvm/uvm_vnode.c", line 304 
[   260.565864] cpu1: Begin traceback...
[   260.565864] vpanic() at netbsd:vpanic+0x171
[   260.565864] kern_assert() at netbsd:kern_assert+0x4b
[   260.565864] indpages() at netbsd:uvn_findpages+0xc9
[   260.565864] genfs_com39] VOP_GETPAGES() at netbsd:VOP_GETPAGES+0x80
[   260.565864] uv() at netbsd:uvm_fault_internal+0xcd4
[   260.565864] trap() at n58639] eab89a:
[   260.565864] cpu1: End traceback...
[   260.565864] fatal breakpoint trap in supervisor mode
[   260.565864] trap type 1 code 0 rip 0xffffffff80232825 cs 0x8 rflags 0x202 cr2 0x7c3581c19000 ilevel 0 rsp 0xffffdb240e914940
[   260.565864] curlwp 0xffff9a6077498000 pid 7741.7741 lowest kstack 0xffffdb240e91x5:	leave	
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x171
kern_assert() at netbsd:kern_assert+0x4b
uvn_findpage() at netbsd:uvn_findpage+0x208
uvn_findpages() at netbsd:uvn_findpages+0xc9
genfs_compat_getpages() at netbsd:genfs_compat_getpages+0x1ac
VOP_GETPAGES() at netbsd:VOP_GETPAGES+0x80
uvn_fault_internal+0xcd4
trap() at netbsd:trap+0x3a6
[   260.565864]          1
fs          180
gs          48f0
rdi         0
rsi   0	ostype+0x403a7
rdx         1
rcx         ffffffffffffff
rax   r11         0
r12         ffffdb240e914988
r13         104
r14         ffff9a609f5417c0
r15         ffffdb240e914e50
rip         ffffffff80232825	breakpoint+0x5
cs          8
rflags      202
r	leave	

Sorry, crash dump is not available.  (Separate PR coming)

>How-To-Repeat:
run audioplay on a file located on an ntfs file system.  Note
that mpg123 does not cause the crash.
>Fix:
please


>Audit-Trail:
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/59152: Panic in genfs(?) onn HEAD amd64
Date: Sat, 8 Mar 2025 08:36:19 +0100

 On Fri, Mar 07, 2025 at 10:35:00PM +0000, paul@whooppee.com wrote:
 > run audioplay on a file located on an ntfs file system.  Note
 > that mpg123 does not cause the crash.

 Just to make sure: the filesystem is mounted read-only with the in-tree
 ntfs w/o rump, putter or pffs involved?

 Martin

From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/59152: Panic in genfs(?) onn HEAD amd64
Date: Mon, 10 Mar 2025 07:54:37 +0000 (UTC)

 Looks like bit-rot in genfs_compat_getpages(): NTFS seems to be the
 only user of that function (prolly because NTFS can't use genfs_getpages()
 as it doesn't implement a proper ntfs_bmap() for it...).

 Anyway, the patch below seems to kinda work for me: at least, no panics; but
 some of the files on my Windows 11 NTFS have all '\0' in 'em instead of actual
 contents. But, NTFS-3g from pkgsrc which is pretty old has issues too:


 // NTFS-3g run:
 # ls -l /mnt/Windows/Media/*.wav
 lrwxrwxrwx  3 root  wheel  34 May  7  2022 /mnt/Windows/Media/Alarm01.wav -> unsupported reparse tag 0x80000017
 lrwxrwxrwx  3 root  wheel  34 May  7  2022 /mnt/Windows/Media/Alarm02.wav -> unsupported reparse tag 0x80000017
 lrwxrwxrwx  3 root  wheel  34 May  7  2022 /mnt/Windows/Media/Alarm03.wav -> unsupported reparse tag 0x80000017
 lrwxrwxrwx  3 root  wheel  34 May  7  2022 /mnt/Windows/Media/Alarm04.wav -> unsupported reparse tag 0x80000017

 // mount_ntfs run:
 # ls -l /mnt/Windows/Media/*.wav
 -rwxr-xr-x  3 root  wheel   491516 May  7  2022 /mnt/Windows/Media/Alarm01.wav
 -rwxr-xr-x  3 root  wheel   331108 May  7  2022 /mnt/Windows/Media/Alarm02.wav
 -rwxr-xr-x  3 root  wheel   355588 May  7  2022 /mnt/Windows/Media/Alarm03.wav
 # file /mnt/Windows/Media/Alarm01.wav
 /mnt/Windows/Media/Alarm01.wav: data
 # hexdump -C /mnt/Windows/Media/Alarm01.wav
 00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
 *
 00077ff0  00 00 00 00 00 00 00 00  00 00 00 00              |............|
 00077ffc
 #

 Might just be that Win 11 NTFS has features not supported by current code. Or,
 it's a sign that I have to CHKDSK.exe that filesystem :).

 -RVP

 ---START patch---
 diff -urN a/sys/miscfs/genfs/genfs_io.c b/sys/miscfs/genfs/genfs_io.c
 --- a/sys/miscfs/genfs/genfs_io.c	2024-04-06 01:44:11.101347998 +0000
 +++ b/sys/miscfs/genfs/genfs_io.c	2025-03-10 07:40:37.639359388 +0000
 @@ -1624,7 +1624,7 @@

   	if (ap->a_flags & PGO_LOCKED) {
   		uvn_findpages(uobj, origoffset, ap->a_count, ap->a_m, NULL,
 -		    UFP_NOWAIT|UFP_NOALLOC| (memwrite ? UFP_NORDONLY : 0));
 +		    UFP_NOWAIT|UFP_NOALLOC|UFP_NOBUSY| (memwrite ? UFP_NORDONLY : 0));

   		error = ap->a_m[ap->a_centeridx] == NULL ? EBUSY : 0;
   		return error;
 ---END patch---

>Unformatted:

Home	PR Database Search