NetBSD Problem Report #57372

From www@netbsd.org  Thu Apr 20 13:10:36 2023
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 184091A9239
	for <gnats-bugs@gnats.NetBSD.org>; Thu, 20 Apr 2023 13:10:36 +0000 (UTC)
Message-Id: <20230420131004.93C3D1A923A@mollari.NetBSD.org>
Date: Thu, 20 Apr 2023 13:10:04 +0000 (UTC)
From: campbell+netbsd@mumble.net
Reply-To: campbell+netbsd@mumble.net
To: gnats-bugs@NetBSD.org
Subject: bufq_drain should cause subsequent bufq_put to crash
X-Send-Pr-Version: www-1.0

>Number:         57372
>Category:       kern
>Synopsis:       bufq_drain should cause subsequent bufq_put to crash
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Apr 20 13:15:00 +0000 2023
>Originator:     Taylor R Campbell
>Release:        current
>Organization:
the netbsdk(4) foundation
>Environment:
>Description:
After bufq_drain, it is already forbidden for any additional buffers to be queued on entry to bufq_free -- the latter does KASSERT(bufq_peek(bufq) == NULL).

As an improved diagnostic, bufq_drain should cause any attempt at bufq_put to crash with a similar assertion, so we can diagnose where such buffers are coming from at the moment they are submitted, not retrospectively when it's too late to discover that.
>How-To-Repeat:

>Fix:
Yes, please!

Home	PR Database Search