From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0AC582F12CE for ; Sat, 22 Aug 2026 16:10:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787415037; cv=none; b=rHs9Cv0Nw5noLHMAfiehv5f5p5Iyg8L5Jh0WVXsdOGQDyRo/V5izsPy8EbkI9xLWtQcdt+Ymk42jfeK5M8R2FC74D5Jfxx6W9U4rJcQ+TauGf3Xbz2x7usZWD1EcIIJGzaot2ZQ8eCYtnLE3OdfEEqx82AqLBGe0KRaM0GQ7VvQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787415037; c=relaxed/simple; bh=qAiJAsmRfO58+KywjiPWB3IOjxQ/qckTren1yl7aEHE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tL7FH+ZIeocr6MCP95KMhiyhTHAVz4MaARMQhUcy/gFYd5vS/2PZGbrxRJHuFGmDpleJMJmZ4hRjEHeQC9hWEUoqFOH2pEg3Tyey9ybb0JvlZEhdQWDl+UNNWhnMXwEWfRagmWF9Gpr2D23QeSxfPjXiMWEvs0B/ddiQh7ihlOQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=AKHiZVBR; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="AKHiZVBR" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1D6AD1F000E9; Sat, 22 Aug 2026 16:10:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1787415035; bh=xW1GsIrZ1JtlfbL2pQaGiL3oBgVvRFg1BGonzZc2lKQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=AKHiZVBRfXgxgBfS7AgvvcvVl+TD6hmWsX6w5+qrJHgGctz2uF2/KHaFvoh0KHNV6 MHrrwqAszthKS2Ihlw4HyeFYEqC3rAvj+DPrl/SCr3F3I0nFqj8AYsi1T1yKfJrVcw QAITAE0srPiK6mQvZCOj9AmpyyGRjajiCvR1oLuk= Date: Sat, 22 Aug 2026 18:06:13 +0200 From: Greg KH To: old king Cc: arnd@arndb.de, ralphs@netwinder.org, linux-kernel@vger.kernel.org Subject: Re: nwbutton: lost wakeup in button_read() -- worth fixing, or is this driver done? Message-ID: <2026082245-speak-gurgle-1f66@gregkh> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Sat, Aug 22, 2026 at 11:01:38AM -0500, old king wrote: > Hi, > > button_read() in drivers/char/nwbutton.c sleeps unconditionally: nothing is > tested before schedule(), not even whether the buffer is empty. If > button_sequence_finished() wakes button_wait_queue in the window between > read() being entered and prepare_to_wait() queuing the reader, that wakeup > is lost and the reader sleeps until some later, unrelated button sequence > completes. The race predates commit eb831743f2b4, whose changelog already called > the code "inherently racy". I have reproduced it under QEMU and prepared a fix: > a sequence counter captured before queuing and re-checked after. > > Before I send that: is this driver still worth fixing? footbridge is > deprecated and its Kconfig says support goes away in 2027 unless remaining > users speak up. Every change to nwbutton.c in git history has been a > treewide cleanup rather than anything a user asked for, and > button_add_callback()/button_del_callback() have no callers in the tree. I > have no NetWinder hardware and no way to tell whether anyone else does. If you don't have the hardware to test it, don't worry about the driver at all. thanks, greg k-h