NetBSD Problem Report #58442

From www@netbsd.org  Thu Jul 18 15:28:04 2024
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)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits)
	 client-signature RSA-PSS (2048 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 461481A9239
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 18 Jul 2024 15:28:04 +0000 (UTC)
Message-Id: <20240718152803.0C0D71A923A@mollari.NetBSD.org>
Date: Thu, 18 Jul 2024 15:28:03 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: kmem_alloc, kmem_free, &c., might not panic under spin locks
X-Send-Pr-Version: www-1.0

>Number:         58442
>Category:       kern
>Synopsis:       kmem_alloc, kmem_free, &c., might not panic under spin locks
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 18 15:30:00 +0000 2024
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The NetBSD Foundalloc in interrupt context
>Environment:
>Description:
It is forbidden to call kmem_alloc, kmem_free, and other such functions in interrupt context.

Since logic in interrupt context may take spin locks, calling kmem_alloc/free under a spin lock is effectively calling them in interrupt context, so it is also forbidden.

kmem_alloc and kmem_free have

	KASSERT(!cpu_intr_p());
	KASSERT(!cpu_softintr_p());

but they don't assert anything about raised IPL or holding spin locks.
>How-To-Repeat:
draft code that calls kmem_alloc/free under a spin lock, e.g. an IPL_VM mutex
>Fix:
1. invent a way to assert IPL is not raised
2. maybe use LOCKDEBUG_BARRIER(NULL, /*slplocksforbidden*/false) in kmem_alloc/free

Home	PR Database Search