NetBSD Problem Report #56194

From www@netbsd.org  Fri May 21 15:11:48 2021
Return-Path: <www@netbsd.org>
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))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 0BCF81A9249
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 21 May 2021 15:11:48 +0000 (UTC)
Message-Id: <20210521151146.B20541A925E@mollari.NetBSD.org>
Date: Fri, 21 May 2021 15:11:46 +0000 (UTC)
From: nia@pkgsrc.org
Reply-To: nia@pkgsrc.org
To: gnats-bugs@NetBSD.org
Subject: xhci panic: kernel diagnostic assertion "xs->xs_xr[dci] == NULL" failed
X-Send-Pr-Version: www-1.0

>Number:         56194
>Category:       kern
>Synopsis:       xhci panic: kernel diagnostic assertion "xs->xs_xr[dci] == NULL" failed
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 21 15:15:00 +0000 2021
>Closed-Date:    
>Last-Modified:  Thu Oct 08 19:50:20 +0000 2026
>Originator:     nia
>Release:        current
>Organization:
The NetBSD Foundation
>Environment:
NetBSD amnesia 9.99.82 NetBSD 9.99.82 (NIAAMD64) #2: Tue May 18 12:32:39 CEST 2021  nia@amnesia:/src/obj/sys/arch/amd64/compile/NIAAMD64 amd64
>Description:
The system gradually locked up over a few seconds while using uaudio
for output, then eventually panicked:

System panicked: kernel diagnostic assertion "xs->xs_xr[dci] == NULL" failed: file "/src/src/sys/dev/usb/xhci.c", line 1669

This is an older uaudio device that worked before Isochronous Pipe
support was introduced:

$ dmesg | grep uaudio
[   756.135042] uaudio0 at uhub1 port 2 configuration 1 interface 0
[   756.135042] uaudio0: C-Media Electronics Inc. (0x0d8c) USB Audio Device (0x0014), rev 1.10/1.00, addr 2
[   756.135042] uaudio0: audio rev 1.00
[   756.135042] audio1 at uaudio0: playback, capture, full duplex, independent
$ audiocfg list
0: [*] audio1 @ uaudio0: USB audio
       playback: 2ch, 48000Hz
       record:   1ch, 48000Hz
       (P-) slinear_le 16/16, 2ch, { 48000, 44100 }
       (-R) slinear_le 16/16, 1ch, { 48000, 44100 }


Unfortunately the core dump is invalid and most tools dump themselves
while trying to read it - kernel memory corruption?
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->jdolecek
Responsible-Changed-By: jdolecek@NetBSD.org
Responsible-Changed-When: Fri, 21 May 2021 19:36:46 +0000
Responsible-Changed-Why:
I'm looking on xhci(4), can check this one too.


State-Changed-From-To: open->feedback
State-Changed-By: jdolecek@NetBSD.org
State-Changed-When: Sun, 06 Jun 2021 18:38:08 +0000
State-Changed-Why:
Can you check if the change fixes the problem?


From: "Jaromir Dolecek" <jdolecek@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56194 CVS commit: src/sys/dev/usb
Date: Sun, 6 Jun 2021 18:37:20 +0000

 Module Name:	src
 Committed By:	jdolecek
 Date:		Sun Jun  6 18:37:20 UTC 2021

 Modified Files:
 	src/sys/dev/usb: xhci.c

 Log Message:
 also reset xs->xs_xr[dci] to NULL when closing the pipe

 avoids KASSERT() on next xhci_open()

 should fix PR kern/56194 by nia


 To generate a diff of this commit:
 cvs rdiff -u -r1.143 -r1.144 src/sys/dev/usb/xhci.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: feedback->open
State-Changed-By: nia@NetBSD.org
State-Changed-When: Thu, 15 Jul 2021 08:08:45 +0000
State-Changed-Why:
Problem is still present as of yesterday's HEAD.


Responsible-Changed-From-To: jdolecek->kern-bug-people
Responsible-Changed-By: jdolecek@NetBSD.org
Responsible-Changed-When: Sat, 20 Jan 2024 13:09:28 +0000
Responsible-Changed-Why:
Somebody else needs to investigate.


From: "Michael van Elst" <mlelstv@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56194 CVS commit: src/sys/dev/usb
Date: Sat, 10 Jan 2026 08:54:08 +0000

 Module Name:	src
 Committed By:	mlelstv
 Date:		Sat Jan 10 08:54:08 UTC 2026

 Modified Files:
 	src/sys/dev/usb: uaudio.c

 Log Message:
 Also use atomic operation to store pipe pointers, not just to clear them.

 Probably fixes PR 56194.


 To generate a diff of this commit:
 cvs rdiff -u -r1.184 -r1.185 src/sys/dev/usb/uaudio.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->needs-pullups
State-Changed-By: nia@NetBSD.org
State-Changed-When: Sat, 10 Jan 2026 21:44:03 +0000
State-Changed-Why:


From: Taylor R Campbell <riastradh@NetBSD.org>
To: Michael van Elst <mlelstv@NetBSD.org>
Cc: source-changes-d@NetBSD.org, gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org,
	Nick Hudson <skrll@NetBSD.org>
Subject: Re: kern/56194: xhci panic: kernel diagnostic assertion "xs->xs_xr[dci] == NULL" failed
Date: Sun, 11 Jan 2026 16:22:31 +0000

 > Module Name:    src
 > Committed By:   mlelstv
 > Date:           Sat Jan 10 08:54:08 UTC 2026
 > 
 > Modified Files:
 >         src/sys/dev/usb: uaudio.c
 > 
 > Log Message:
 > Also use atomic operation to store pipe pointers, not just to clear them.
 > 
 > Probably fixes PR 56194.
 > 
 > 
 > To generate a diff of this commit:
 > cvs rdiff -u -r1.184 -r1.185 src/sys/dev/usb/uaudio.c

 I think this cannot be correct.

 There are several possible scenarios:

 1. Concurrent calls to uaudio_chan_open and/or uaudio_chan_close with
    the same channel are NOT possible.  I.e., all such calls are
    serialized.

    => In this case, the atomic_swap_ptr can't make any difference, so
       this patch can't fix anything.

 2. Concurrent calls to uaudio_chan_open with the same channel are
    possible.

    => In this case, the following sequence is possible:

         thread0                 thread1
         -------                 -------
         usbd_open_pipe(&pipe0)  usbd_open_pipe(&pipe1)
         pipe0 = atomic_swap_ptr(&ch->pipe, pipe0)
         KASSERT(pipe0 == NULL)
                                 pipe1 = atomic_swap_ptr(&ch->pipe, pipe1)
                                 KASSERT(pipe1 == NULL)

       The KASSERT in thread0 succeeds but the KASSERT in thread1 fails
       (or, in non-DIAGNOSTIC builds, this leaks a pipe).  So this is
       still broken.

 3. A call to uaudio_chan_open can happen concurrently with a call to
    uaudio_chan_close with the same channel.

    => In this case, the following sequence is possible:

         thread0                 thread1
         -------                 -------
                                 uaudio_trigger_input(...)
                                   uaudio_chan_open(sc, ch)
                                     usbd_open_pipe(&pipe)
                                     atomic_swap_ptr(&ch->pipe, pipe)
         uaudio_chan_close(sc, ch)
           pipe = atomic_swap_ptr(&ch->pipe, NULL)
           usbd_close_pipe(pipe)
                                   uaudio_chan_alloc_buffers(sc, ch)
                                     usbd_create_xfer(ch->pipe, ...)

       At this point in thread1, ch->pipe is null, so we have a null
       pointer dereference.  (Another possible ordering is that thread1
       loads ch->pipe before thread0 nulls it out, but then thread0
       closes the pipe before thread1 enters usbd_create_xfer, and so
       it'll be use-after-free instead of null pointer dereference.)
       So again, this is still broken.

 I suspect that both (2) and (3) are true, but that really (1) _ought_
 to be true.

 If so, perhaps we can enforce it by a per-channel mutex taken by

 uaudio_halt_in_dma_unlocked
 uaudio_halt_out_dma_unlocked
 uaudio_trigger_input
 uaudio_trigger_output

 and asserted held by

 uaudio_chan_set_param
 uaudio_chan_open
 uaudio_chan_alloc_buffers
 uaudio_chan_free_buffers
 uaudio_chan_close

 and then dispense with the atomic_swap_ptrs altogether.

State-Changed-From-To: needs-pullups->open
State-Changed-By: riastradh@NetBSD.org
State-Changed-When: Thu, 08 Oct 2026 19:50:20 +0000
State-Changed-Why:
I don't think this problem has been properly fixed.


>Unformatted:

Home	PR Database Search