From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 06655261B8C for ; Thu, 4 Dec 2025 15:35:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764862526; cv=none; b=g/f/SEanCdLPx5Gu06Y7qqWLCiZVzrxbnTebFOR3SaHW7x7EXK25uIDx0yVM4+8iEe63iTepO8mDerl9uFKxlEd1gfksZYkqch4ro4sRcTJ5CELupWB0dnvPINd7EdUjK+ai7ERFvxgibDPr0LLK4HVbYuOnsVu4iIuP7ZWywI4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764862526; c=relaxed/simple; bh=61DFXBAZZo59PtALU+VRJM+cnFnmBMumIy99SGcfLlM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tuj8vyUFlVqCPB2maWft3PjGf5X25aeqj0WjSql+XZEDYIa3maAnPCrvaoZS3VNct8MXj/OoGNkdWdps4Jtz9e0PKHVju7lHXNPUvlo4bKBe1SSUove6MMyuTHniaSuZWZrW4yyo5BIn8fyg9tZMcbKf5ouN2ElOIHeuRlRbExQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b=kmhMDcEQ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.b="kmhMDcEQ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2BAD4C4CEFB; Thu, 4 Dec 2025 15:35:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1764862525; bh=61DFXBAZZo59PtALU+VRJM+cnFnmBMumIy99SGcfLlM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=kmhMDcEQ5d/hkmMo2fQaO0V36pwnkyYGONQTcu3WvqAIQ6Ctrcf7jH/7BgvxTt86k L80k4akDxkjAPc0YnkvA5dHyzo1/7Awc7+OtyvI83H4IcXeZEj3jUkBMsJd7UEw47F PFyiM/PcnD1r0nDmUYaxlKujWdcooiX+t3g6q+tk= Date: Thu, 4 Dec 2025 16:35:22 +0100 From: gregkh To: =?utf-8?B?5p2O5aSp5a6H?= <2200013188@stu.pku.edu.cn> Cc: linux-kernel , rafael , dakr , abbotti , hsweeten , xujiakai2025 , "zhaoruilin22@mails.ucas.ac.cn" Subject: Re: [BUG] WARN "Unexpected driver unregister!" when configuring c6xdigio via COMEDI_DEVCONFIG Message-ID: <2025120427-elves-stinging-843d@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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Thu, Dec 04, 2025 at 11:00:51PM +0800, 李天宇 wrote: > Hello maintainers, > > I encountered a WARN in driver_unregister (drivers/base/driver.c:273) when configuring the c6xdigio COMEDI driver via ioctl(COMEDI_DEVCONFIG). This issue is first found on Linux 6.18-rc6 via a fuzzing framework and later confirmed reproducible on Linux v6.18. > > Based on the call trace and source review, the path appears to be: > > - drivers/comedi/drivers.c:207: dev->driver->detach(dev) (detach is set as c6xdigio_detach in c6xdigio.c:290) > - drivers/comedi/drivers/c6xdigio.c:283: pnp_unregister_driver() > - drivers/pnp/driver.c:286: driver_unregister() > - drivers/base/driver.c:273: WARN triggered > > The WARN occurs because driver_unregister() finds drv->p == NULL and prints: > WARN(1, "Unexpected driver unregister!\n"); > > It seems the attach process fails early (e.g. due to a request-region conflict), but the detach path still calls pnp_unregister_driver() unconditionally. If pnp_register_driver() was never successful, calling unregister on an unregistered driver results in driver_unregister() being invoked with drv->p == NULL, which leads to the warning. > > Related information is listed below: > > Kernel source: https://cdn.kernel.org/pub/linux/kernel/v6.x/linux-6.18.tar.xz > Kernel configuration: https://github.com/j1akai/KConfigFuzz_bug/raw/refs/heads/main/x86/mainline-config > Kernel log: https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/b42a57a980ac99dba76418f8daaa80e2a90831a1/report0 > Reproduction C code: https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/b42a57a980ac99dba76418f8daaa80e2a90831a1/repro.cprog > Syscall sequence for reproduction (more precise): https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/b42a57a980ac99dba76418f8daaa80e2a90831a1/repro.prog > GCC info: https://github.com/Wxm-233/KConfigFuzz_crashes/raw/refs/heads/main/b42a57a980ac99dba76418f8daaa80e2a90831a1/gccinfo > > I hope this report helps in identifying and resolving the issue. Thanks for your time and attention. Can you make up a patch that properly checks the return value of pnp_register_driver() and handles it and submit it to resolve this issue? As you have a reproducer, that's the best way to get this resolved, and you get full credit for fixing the issue. Also, do you really have any pnp hardware? That's some really old stuff, or is this just fuzzing testing? thanks, greg k-h