NetBSD Problem Report #57138

From www@netbsd.org  Mon Dec 26 19:32:26 2022
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 C51071A921F
	for <gnats-bugs@gnats.NetBSD.org>; Mon, 26 Dec 2022 19:32:25 +0000 (UTC)
Message-Id: <20221226193224.8BDDF1A9239@mollari.NetBSD.org>
Date: Mon, 26 Dec 2022 19:32:24 +0000 (UTC)
From: miod@online.fr
Reply-To: miod@online.fr
To: gnats-bugs@NetBSD.org
Subject: incorrect spl assumption in macppc adb code
X-Send-Pr-Version: www-1.0

>Number:         57138
>Category:       port-macppc
>Synopsis:       incorrect spl assumption in macppc adb code
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-macppc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Dec 26 19:35:01 +0000 2022
>Originator:     Miod Vallat
>Release:        HEAD
>Organization:
>Environment:
>Description:
In sys/arch/macppc/dev/adb_direct.c send_adb_cuda(), the end of the routine decides to perform polling work if either adb_polling is set or the returned value from splhigh() earlier has bit 18 set.

At the time Tsubai Masanari ported the mac68k adb code, this check made sense as the result of the spl functions was the actual interrupt controller mask, with bit 18 being the cuda interrupt. The check was roughly equivalent to "are we at IPL_TTY or higher?".

However, it has been years since the results of the spl functions no longer match interrupt controller masks.
>How-To-Repeat:
Code inspection.
>Fix:
Either replace the test with a proper IPL_TTY check, or remove it altogether, since this condition has been always false in the last 20+ years and it looks noone noticed, thus nothing would get broken removing it.

Home	PR Database Search