From nobody Sun May 24 19:33:38 2026 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 33FBE360ED6 for ; Fri, 22 May 2026 07:34:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.178 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779435297; cv=none; b=IdNUmOEew0M2ctUi+5m0vgrSs5/mq0eb3num4oaltCn/jLXNtQTTEVED6xuEwTIXBHogdHY4lRtv8A+wfgCfbAxWjjJmFMNvHdKCRPv9cmuQOVJXFYKY0E3wjFj14zdIewvtl6r/5QHT5T3H4G+AyNUHBPBTy59goKSGnp+OTEs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779435297; c=relaxed/simple; bh=2MHWNV/j7pfuOPDfeSSVPN9xcAaYvcBRtvdbNj1QhVM=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=GndMb7l6vfVAPrnjOfo9n/oycAtb7dxK5hCO7DKyZTb+osPJsY1HDAj+PNfg0MRrg1CU8YDeAOaRubr+3pI9YCJRjdjtNZw816JrAI90UzklD/yQn3Ggj7mzqvAi/PwsqNcO8UAqX/476AnuamXMS8Gwn3ZN4jrPL/y+VUqbIF4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ITHrzKoW; arc=none smtp.client-ip=209.85.214.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ITHrzKoW" Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-2b9fcf7c91bso75784675ad.0 for ; Fri, 22 May 2026 00:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779435295; x=1780040095; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=cgJ1nepVSDPEnzlAFlnIL/d5rHJZ1TOrfyX+gZ/gV9U=; b=ITHrzKoWxhY8BW6PGj2lTbBQ2cE/TVxIdHB+0gRuA3EkxF5YZs9YPkeMZ1z+zm2/xv S6lzlHy//CNq5WveVKkB+sYiHZMTlr3Arwbyf6wlSkBcnwFojJZfI+iSOHFlhUrU4HiK i6Que80XyFDhAnNISiQfb8Lf2VdbfdGS8Chakwpp7juDhB85vrpiJxdfgyhEoLb5srcA +bb1mEIrgeAQmxBcNIY6jFs+6jY63sGfhBdawVdmcKEvbxg61XB6owDJRKzpCgIZ5C2A mHEpnOd+npzHoH6wTbImt2ewvy6SpXyOnzjrVmwtbbs27/rVpor3xXVOFd6TuW7FhkRl 79gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779435295; x=1780040095; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cgJ1nepVSDPEnzlAFlnIL/d5rHJZ1TOrfyX+gZ/gV9U=; b=a8yaOy/lAJocvQJwy7vbRwATEzsWARGKWztZZ+KzIkNO0Vy3m3Z/GHSyr+jmXHAsjl hQ/hOf+5NQaJO7cp0rwi26Jri3GQKR8rewJs6nxWkfJ6V/dPns6HS8/DTbN9OWLhnXn3 e9EBgTxHNuS1HWYVFwwsMfJoyahyk4oxucqpY70+jjVQ2jiFvr2pYerVkFXO6T/EHMFQ T8tisAXQ7PEnZUmEGfObjPF7WYooYsypATmZGFKFKskiDVC9SfoV9Bm2U9hWl6MbbsMs jrSrRTpTJlHzBAtWLjblxbAD8QIOjDhQB9oBHzp2MQVfcqcaSpTTFm3IJUXi3FhmxaL+ zN+Q== X-Forwarded-Encrypted: i=1; AFNElJ/F6a8ugzLTBG3WOwN8ZjWSVTbH7Xqttgstacgom1PETNgu2i8l7l2dJzmzpPIvkjE2mQsckZ6vAChpvbw=@vger.kernel.org X-Gm-Message-State: AOJu0YwjbrKbR/+u70xxvcsht+lLG4bIbn6IKnm/kDOTdb7rr7mHF5WY 1R/vJE2qAV0UJRQx4cI3UzDLOfSYFW9GfxViCxOyW8FmYDd/N53ZaxBGIbCRZdGA19o= X-Gm-Gg: Acq92OFW5JphAPm2jb7iLVyM/KkI1goT0MLh/l7wfdKIWQA6+6t9MoGSVGq/IXl0AeO 0c6HFgtLXflNSD9RqiJtOItLZYjfRnhTkiz8/RsDy8A4X3Yq4KB75QdZBB8K1zjgPFV3I8ZpDe2 no4YjewdhwFKCj7kqTIC9xiqP30V/oxlxCWQv1Nmq+/hCY70bBuzwY+Vq4ThIw/cI1rdI8PMQ8e vvxvMh4jEgSmkd9dn790xVbvFW8v8a2QZxbVu/g28Itotl3+nJApEipzH1NkbaL4Hq4xNe5P9kF 2F9mRgLAlDXb13ldR6k3e0jJOrehnhCh6TsiB7edFDvL9Qai3s63AoRVkhOFPYtZ6HydehLE5e0 OynakvTI8wNE5adsVQUcIdLYG3GvmoIriDS+mezIG2joccaysXAh45AcSAfN1CWsUAOYhIp15lQ fS6+hVUo8W8/iNQM/6+2oAAmxziIWHbhEe+JqN8XmzpTlpLmcoxOS03pnRTAl5vzA/FvvKA5X7j +TntnufXhuCGs2fE11o9n6JFAbWuAGsYPjktr8kht/7+cEuiqWBNFKwx9UFdqXnsFJmtx/ZlVlq zwZR17Hlft8= X-Received: by 2002:a17:903:2bce:b0:2b0:5923:5194 with SMTP id d9443c01a7336-2beb0681ddbmr27080355ad.27.1779435295456; Fri, 22 May 2026 00:34:55 -0700 (PDT) Received: from bass-virtual-machine.. ([163.61.198.28]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2beb58b2ebcsm7564945ad.49.2026.05.22.00.34.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 22 May 2026 00:34:55 -0700 (PDT) From: Gui-Dong Han To: dpenkler@gmail.com Cc: gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, baijiaju1990@gmail.com Subject: [PATCH] gpib: Move stuck SRQ update under lock Date: Fri, 22 May 2026 15:34:47 +0800 Message-Id: <20260522073447.4117690-1-hanguidong02@gmail.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Move the stuck SRQ state update into autopoll_all_devices() and keep it under big_gpib_mutex. Except for initialization, keep the stuck_srq users under this mutex. autopoll_all_devices() is only called by autospoll_thread(), so there is no need to return to autospoll_thread() and set this state after dropping big_gpib_mutex. Without the mutex, a newly opened device can clear stuck_srq and have that clear overwritten by the previous autospoll result: autospoll: serial_poll_all() returns 0 and unlocks big_gpib_mutex open_dev_ioctl: open new device and clear stuck_srq with big_gpib_mutex held autospoll: set stuck_srq That leaves the board marked stuck again after the new device is opened. autospoll_wait_should_wake_up() then refuses to poll while stuck_srq is set, so later SRQ handling can be mistakenly suppressed. Without the mutex, atomic_set() and set_bit() only make individual updates atomic. They do not order the two updates or make stuck_srq and status visible as a consistent pair. Taking big_gpib_mutex serializes the state transition with the other runtime users. Keep the existing wakeup behavior unchanged and only move the stuck SRQ state update under the mutex. Fixes: 9dde4559e939 ("staging: gpib: Add GPIB common core driver") Signed-off-by: Gui-Dong Han --- Found by auditing atomic operations used for synchronization. A similar fix can be found in 6df8e84aa6b5. --- drivers/gpib/common/gpib_os.c | 21 +++++++++++---------- drivers/gpib/common/iblib.c | 3 --- 2 files changed, 11 insertions(+), 13 deletions(-) diff --git a/drivers/gpib/common/gpib_os.c b/drivers/gpib/common/gpib_os.c index 5909274ddc12..82844eb25917 100644 --- a/drivers/gpib/common/gpib_os.c +++ b/drivers/gpib/common/gpib_os.c @@ -289,18 +289,19 @@ int autopoll_all_devices(struct gpib_board *board) dev_dbg(board->gpib_dev, "autopoll has board lock\n"); =20 retval =3D serial_poll_all(board, serial_timeout); - if (retval < 0) { - mutex_unlock(&board->big_gpib_mutex); - mutex_unlock(&board->user_mutex); - return retval; + if (retval >=3D 0) { + dev_dbg(board->gpib_dev, "complete\n"); + /* + * need to wake wait queue in case someone is + * waiting on RQS + */ + wake_up_interruptible(&board->wait); } =20 - dev_dbg(board->gpib_dev, "complete\n"); - /* - * need to wake wait queue in case someone is - * waiting on RQS - */ - wake_up_interruptible(&board->wait); + if (retval <=3D 0) { + atomic_set(&board->stuck_srq, 1); + set_bit(SRQI_NUM, &board->status); + } mutex_unlock(&board->big_gpib_mutex); mutex_unlock(&board->user_mutex); =20 diff --git a/drivers/gpib/common/iblib.c b/drivers/gpib/common/iblib.c index b672dd6aad25..511e1d61c1fb 100644 --- a/drivers/gpib/common/iblib.c +++ b/drivers/gpib/common/iblib.c @@ -193,9 +193,6 @@ static int autospoll_thread(void *board_void) } if (retval <=3D 0) { dev_err(board->gpib_dev, "stuck SRQ\n"); - - atomic_set(&board->stuck_srq, 1); // XXX could be better - set_bit(SRQI_NUM, &board->status); } } return retval; --=20 2.34.1