Re: kern/59497: Panic in ucompoll

["Christoph Badura via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/59497; it has been noted by GNATS.

From: Christoph Badura <bad%bsd.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/59497: Panic in ucompoll
Date: Wed, 2 Jul 2025 00:47:37 +0200

 On Tue, Jul 01, 2025 at 09:20:00AM +0000, stix%stix.id.au@localhost wrote:
 > Crash appears due to intermittent disconnect/reconnect of a uplcom device while open.
 
 Are you sure this is a genuine Prolific device?  I've tried to get some
 Prolific USB serial fobs at the start of the year and found that the market
 is swamped with buggy fake prolific chips.  Even supposedly reputable
 manufacturers had fake chips on the fobs that claimed to be PL2303HX /
 PL2303HXD.  In the end i managed to get some fobs with genuine Prolific
 chips for some USD 20 per fob.  The fake ones all sold for about USD 3-4 and
 were easily identifiable by the missing part number and Prolific logo on the
 SSOP chip.
 
 The real ones also don't periodically disconnect/reconnect. :-)
 
 Of course, using the fake chips shouldn't crash the system.
 
 Obviously you were running a process that had the corresponding ttyUX open
 when the crash happened.  Otherwise it wouldn't have been triggered from
 the select(2) code.  Can you please describe what command exactly you were
 running and what its command line options and other configuration settings
 were.  I'd like to try to reproduce this locally.
 
 > crash> bt
 > __kernel_end() at 0
 > kern_reboot() at sys_reboot
 > vpanic() at vpanic+0x18d
 > panic() at vprintf
 > trap() at startlwp
 > --- trap (number 6) ---
 > ucompoll() at ucompoll+0x2a
 > cdev_poll() at cdev_poll+0x87
 > spec_poll() at spec_poll+0x6a
 > VOP_POLL() at VOP_POLL+0x5d
 > sel_do_scan() at sel_do_scan+0x3ba
 > selcommon() at selcommon+0x309
 > sys___select50() at sys___select50+0x75
 > syscall() at syscall+0x1fc
 > --- syscall (number 417) ---
 > syscall+0x1fc:
 > 
 > Have core and kernel with symbols.
 
 Could you try to disassemble the ucompoll() until the offending
 instruction?
 
 Could you try to find out if TS_CANCEL is set in tp->t_state?
 
 > >How-To-Repeat:
 > 
 > >Fix:
 
 This might be relatively easy to work around.
 
 ucycom(4) has (https://nxr.netbsd.org/xref/src/sys/dev/usb/ucycom.c#897):
 
 	if (sc->sc_dying)
 		return EIO;
 
 of course, it should return POLLHUP.
 
 uhso has (https://nxr.netbsd.org/xref/src/sys/dev/usb/uhso.c#1791):
 
 	if (!device_is_active(sc->sc_dev))
 		return POLLHUP;
 
 So apparently there is no agreement how this should be handled.
 
 Could you try adding
 
 	if (sc->sc_dying)
 		return POLLHUP;
 
 before line 853 in ucom.c and see if that makes the symtomps go away?
 
 But maybe the right fix would be to make ttycancel() deal with any pending
 select()s too?  Or something similar that ties in with the d_cancel
 framework?
 
 --chris