From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 39975C282DE for ; Mon, 10 Mar 2025 06:22:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id CC1A88130C; Mon, 10 Mar 2025 06:22:46 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id X9CHf3tFqoJz; Mon, 10 Mar 2025 06:22:46 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=140.211.166.142; helo=lists1.osuosl.org; envelope-from=intel-wired-lan-bounces@osuosl.org; receiver= DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 32C7381318 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osuosl.org; s=default; t=1741587766; bh=6SPOYjueMFvQZmC/pBgFgaBsu+5gQe4Fu/YeV9e3h+I=; h=Date:From:To:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Cc:From; b=aiPm15mc7y4Q8kSjLnidM1FNI0J0J8GZuNHT9wrx1mnLZ9ZCWqkiDE6CLIfPg2mFx zouKnbIrlYQ502405G0PuIByAb15kZT9Wq5juMibWSOtbE3bcsnYl8rtypIfohCxPv X4LbukJwZq7j8k0XcURn+ieB3dhYTHmRgxKIcmin0tembWkwsGgdpmiu5xaVtt5dkD FtBGhhGsqhrgW+eoIoN/QEdgqJqPqwCo+0g1hGjFtWmj31t/di3AFBnSZzpdsAF6XK IGvQ28jgl4MAgjgpZ2Q/qOsEEnfxbwUExVSgrYy7974O4yq7ngQNEmH4yZpu74uRy/ mCai4m2lthYpA== Received: from lists1.osuosl.org (lists1.osuosl.org [140.211.166.142]) by smtp1.osuosl.org (Postfix) with ESMTP id 32C7381318; Mon, 10 Mar 2025 06:22:46 +0000 (UTC) Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists1.osuosl.org (Postfix) with ESMTP id 93B971C1 for ; Mon, 10 Mar 2025 06:22:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 81E09606F7 for ; Mon, 10 Mar 2025 06:22:44 +0000 (UTC) X-Virus-Scanned: amavis at osuosl.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavis, port 10024) with ESMTP id JVXq4vwE_qiO for ; Mon, 10 Mar 2025 06:22:44 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2604:1380:45d1:ec00::3; helo=nyc.source.kernel.org; envelope-from=horms@kernel.org; receiver= DMARC-Filter: OpenDMARC Filter v1.4.2 smtp3.osuosl.org D33DE605EE DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org D33DE605EE Received: from nyc.source.kernel.org (nyc.source.kernel.org [IPv6:2604:1380:45d1:ec00::3]) by smtp3.osuosl.org (Postfix) with ESMTPS id D33DE605EE for ; Mon, 10 Mar 2025 06:22:43 +0000 (UTC) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 2E31FA45E5E; Mon, 10 Mar 2025 06:17:12 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80C14C4CEE5; Mon, 10 Mar 2025 06:22:38 +0000 (UTC) Date: Mon, 10 Mar 2025 07:22:29 +0100 From: Simon Horman To: Emil Tantilov Message-ID: <20250310062229.GD4159220@kernel.org> References: <20250307003956.22018-1-emil.s.tantilov@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250307003956.22018-1-emil.s.tantilov@intel.com> X-Mailman-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1741587762; bh=Heq9Vfd9RkINitmBqpLfkAzNT3H2R2CSZ/30mhG0gZU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Xc33tu/AzUZBseja0is+oV6q0OgGC8WHWtgmzkHCCYVOiDa+lGm3vJbEEwALy7nOf fZrjqTlhaOuQVY2vMM2n/ntBpVPFoH97WtrsS3UdBSvF7JtzBEH8n1WgenAHouSfNR 8eo9ixUpeamfmXTgXsIYXYM7adtbJqXbPRbBuLaDvVT+Eu8twLZYkTDUevOU0HOGl1 pxOzrCOmRI9qEp8RWwYeBmTQ8PJ6uk9QUbYv9H7gfo1YGnLHsgKPE0ktQBfgNvi5ap TAGbOVTCiC84rIhfHetBGoUxdUCq/fa9xpJvW6P++CrTLHuNq3XyIRpEmKAn0lM0L5 0rNRBQTIrooTA== X-Mailman-Original-Authentication-Results: smtp3.osuosl.org; dmarc=pass (p=quarantine dis=none) header.from=kernel.org X-Mailman-Original-Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key, unprotected) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20201202 header.b=Xc33tu/A Subject: Re: [Intel-wired-lan] [PATCH iwl-net] idpf: fix adapter NULL pointer dereference on reboot X-BeenThere: intel-wired-lan@osuosl.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Intel Wired Ethernet Linux Kernel Driver Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: willemb@google.com, pabeni@redhat.com, netdev@vger.kernel.org, yuma@redhat.com, Aleksandr.Loktionov@intel.com, edumazet@google.com, madhu.chittim@intel.com, anthony.l.nguyen@intel.com, kuba@kernel.org, intel-wired-lan@lists.osuosl.org, decot@google.com, davem@davemloft.net Errors-To: intel-wired-lan-bounces@osuosl.org Sender: "Intel-wired-lan" On Thu, Mar 06, 2025 at 04:39:56PM -0800, Emil Tantilov wrote: > Driver calls idpf_remove() from idpf_shutdown(), which can end up > calling idpf_remove() again when disabling SRIOV. > > echo 1 > /sys/class/net//device/sriov_numvfs > reboot > > BUG: kernel NULL pointer dereference, address: 0000000000000020 > ... > RIP: 0010:idpf_remove+0x22/0x1f0 [idpf] > ... > ? idpf_remove+0x22/0x1f0 [idpf] > ? idpf_remove+0x1e4/0x1f0 [idpf] > pci_device_remove+0x3f/0xb0 > device_release_driver_internal+0x19f/0x200 > pci_stop_bus_device+0x6d/0x90 > pci_stop_and_remove_bus_device+0x12/0x20 > pci_iov_remove_virtfn+0xbe/0x120 > sriov_disable+0x34/0xe0 > idpf_sriov_configure+0x58/0x140 [idpf] > idpf_remove+0x1b9/0x1f0 [idpf] > idpf_shutdown+0x12/0x30 [idpf] > pci_device_shutdown+0x35/0x60 > device_shutdown+0x156/0x200 > ... > > Replace the direct idpf_remove() call in idpf_shutdown() with > idpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which perform > the bulk of the cleanup, such as stopping the init task, freeing IRQs, > destroying the vports and freeing the mailbox. Hi Emil, I think it would be worth adding some commentary on the rest of the clean-up performed by idpf_remove() and why it is correct to no longer do so directly from a call to idpf_remove() from idpf_shutdown() (IOW, it isn't clear to me :). ... 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 98D321AAC4 for ; Mon, 10 Mar 2025 06:22:42 +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=1741587762; cv=none; b=RTYdo0CwDkFia5rSZlaCaxjwtVO4tt5hwgyJbQWHR14t+ReQbzRvII8jrxSleQF54oshOeSiaiROV9VHTQg3L7Dstzc3aZdDC8V3Ad82Jt5n2v3aMUbW5+646nOr7K2M9ohDkIEAQ27JsIS+Go4UopenJ+1qmuXl8FS2Ri8bovA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1741587762; c=relaxed/simple; bh=Heq9Vfd9RkINitmBqpLfkAzNT3H2R2CSZ/30mhG0gZU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LR9F1dY4S0ewy8gsQdnSpQSsGvjefkV20h87gURJbJZHXFgDmbZjSgpr2w3KRklIsKh0xonJkJfD0gdkozB6Pp8MPaXvRA9BN1V3P1DPqVjFgFLkL9zeGCuStiPBAAxD/JxCtZzsfjjHg8k5y0CLiP7XMGDIOdFyfdcu1n39IGo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Xc33tu/A; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Xc33tu/A" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 80C14C4CEE5; Mon, 10 Mar 2025 06:22:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1741587762; bh=Heq9Vfd9RkINitmBqpLfkAzNT3H2R2CSZ/30mhG0gZU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Xc33tu/AzUZBseja0is+oV6q0OgGC8WHWtgmzkHCCYVOiDa+lGm3vJbEEwALy7nOf fZrjqTlhaOuQVY2vMM2n/ntBpVPFoH97WtrsS3UdBSvF7JtzBEH8n1WgenAHouSfNR 8eo9ixUpeamfmXTgXsIYXYM7adtbJqXbPRbBuLaDvVT+Eu8twLZYkTDUevOU0HOGl1 pxOzrCOmRI9qEp8RWwYeBmTQ8PJ6uk9QUbYv9H7gfo1YGnLHsgKPE0ktQBfgNvi5ap TAGbOVTCiC84rIhfHetBGoUxdUCq/fa9xpJvW6P++CrTLHuNq3XyIRpEmKAn0lM0L5 0rNRBQTIrooTA== Date: Mon, 10 Mar 2025 07:22:29 +0100 From: Simon Horman To: Emil Tantilov Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, decot@google.com, willemb@google.com, anthony.l.nguyen@intel.com, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, madhu.chittim@intel.com, Aleksandr.Loktionov@intel.com, yuma@redhat.com, mschmidt@redhat.com Subject: Re: [PATCH iwl-net] idpf: fix adapter NULL pointer dereference on reboot Message-ID: <20250310062229.GD4159220@kernel.org> References: <20250307003956.22018-1-emil.s.tantilov@intel.com> Precedence: bulk X-Mailing-List: netdev@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: <20250307003956.22018-1-emil.s.tantilov@intel.com> On Thu, Mar 06, 2025 at 04:39:56PM -0800, Emil Tantilov wrote: > Driver calls idpf_remove() from idpf_shutdown(), which can end up > calling idpf_remove() again when disabling SRIOV. > > echo 1 > /sys/class/net//device/sriov_numvfs > reboot > > BUG: kernel NULL pointer dereference, address: 0000000000000020 > ... > RIP: 0010:idpf_remove+0x22/0x1f0 [idpf] > ... > ? idpf_remove+0x22/0x1f0 [idpf] > ? idpf_remove+0x1e4/0x1f0 [idpf] > pci_device_remove+0x3f/0xb0 > device_release_driver_internal+0x19f/0x200 > pci_stop_bus_device+0x6d/0x90 > pci_stop_and_remove_bus_device+0x12/0x20 > pci_iov_remove_virtfn+0xbe/0x120 > sriov_disable+0x34/0xe0 > idpf_sriov_configure+0x58/0x140 [idpf] > idpf_remove+0x1b9/0x1f0 [idpf] > idpf_shutdown+0x12/0x30 [idpf] > pci_device_shutdown+0x35/0x60 > device_shutdown+0x156/0x200 > ... > > Replace the direct idpf_remove() call in idpf_shutdown() with > idpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which perform > the bulk of the cleanup, such as stopping the init task, freeing IRQs, > destroying the vports and freeing the mailbox. Hi Emil, I think it would be worth adding some commentary on the rest of the clean-up performed by idpf_remove() and why it is correct to no longer do so directly from a call to idpf_remove() from idpf_shutdown() (IOW, it isn't clear to me :). ...