NetBSD Problem Report #56235

From www@netbsd.org  Sat Jun  5 14:35:21 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 765971A9239
	for <gnats-bugs@gnats.NetBSD.org>; Sat,  5 Jun 2021 14:35:21 +0000 (UTC)
Message-Id: <20210605143519.433441A923A@mollari.NetBSD.org>
Date: Sat,  5 Jun 2021 14:35:19 +0000 (UTC)
From: thorpej@me.com
Reply-To: thorpej@me.com
To: gnats-bugs@NetBSD.org
Subject: ti driver creates DMA maps in interrupt context
X-Send-Pr-Version: www-1.0

>Number:         56235
>Category:       kern
>Synopsis:       ti driver creates DMA maps in interrupt context
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    thorpej
>State:          analyzed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jun 05 14:40:00 +0000 2021
>Closed-Date:    
>Last-Modified:  Sat Jun 05 14:43:12 +0000 2021
>Originator:     Jason Thorpe
>Release:        NetBSD 9.99.83
>Organization:
RISCy Business
>Environment:
NetBSD  9.99.83 NetBSD 9.99.83 (GENERIC) #1: Sat Jun  5 07:08:09 PDT 2021  thorpej@the-ripe-vessel:/space/src/sys/arch/cobalt/compile/GENERIC cobalt
>Description:
The ti driver creates DMA maps from interrupt context.  This is not safe to do; it needs to create them from thread context so that they're available in interrupt context.

cobalt# ifconfig ti0 up
[  87.3500146] panic: kernel diagnostic assertion "(!cpu_intr_p() && !cpu_softintr_p())" failed: file "../../../../kern/subr_kmem.c", line 322 kmem(9) should not be used from the interrupt context
[  87.3681102] cpu0: Begin traceback...
[  87.3718216] pid -1886929592 not found
[  87.3718216] cpu0: End traceback...
[  87.3718216] kernel: breakpoint trap
Stopped in pid 631.631 (mdnsd) at       netbsd:cpu_Debugger+0x4:        jr      
ra
                bdslot: nop
db> trace
0x8f87bd70: cpu_Debugger+0x4 (0x3,0x8000,0xc,0x805f2d00) ra 0x80353384 sz 0
0x8f87bd70: vpanic+0x144 (0x3,0x8000,0xc,0x805f2d00) ra 0x804744d8 sz 48
0x8f87bda0: kern_assert+0x38 (0x3,0x805104b8,0x80561b3c,0x80561a4c) ra 0x8034743
c sz 32
0x8f87bdc0: kmem_zalloc+0x4c (0x3,0x805104b8,0x80561b3c,0x80561a4c) ra 0x8000ea9
4 sz 48
0x8f87bdf0: _bus_dmamap_create+0x54 (0x3,0x805104b8,0x80561b3c,0x80561a4c) ra 0x
8004ef3c sz 72
0x8f87be38: ti_newbuf_std+0x12c (0x3,0x805104b8,0x80561b3c,0) ra 0x800528dc sz 5
6
0x8f87be70: ti_intr+0x45c (0x3,0x805104b8,0x80561b3c,0) ra 0x8000bb80 sz 96
0x8f87bed0: icu_intr+0xfc (0x3,0x805104b8,0x80561b3c,0) ra 0x8000c55c sz 64
0x8f87bf10: cpu_intr+0x180 (0x3,0x805104b8,0x80561b3c,0) ra 0x80011a24 sz 56
0x8f87bf48: mips3_user_intr+0xe4 (0x3,0x805104b8,0x80561b3c,0) ra 0 sz 0
User-level: pid 631.631
db> 
>How-To-Repeat:
See above.
>Fix:
N/A

>Release-Note:

>Audit-Trail:

Responsible-Changed-From-To: kern-bug-people->thorpej
Responsible-Changed-By: thorpej@NetBSD.org
Responsible-Changed-When: Sat, 05 Jun 2021 14:43:12 +0000
Responsible-Changed-Why:
Take.


State-Changed-From-To: open->analyzed
State-Changed-By: thorpej@NetBSD.org
State-Changed-When: Sat, 05 Jun 2021 14:43:12 +0000
State-Changed-Why:
This is a well-understood problem.


>Unformatted:

Home	PR Database Search