From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f42.google.com (mail-pj1-f42.google.com [209.85.216.42]) (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 E323E370AD6 for ; Wed, 8 Jul 2026 15:33:57 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783524839; cv=none; b=q8oRBSdVCHJXyeJmYV9bM1kYqtSq6btLG/GYxxDM6TCTO/shFUBUn0K+Jc+x8lIWINmm0RZW+kZyZzZQaAGdryYatzG3uim04vxc2srTKAhTfcjmaJnYKZFVDjaw3m9XgmVsKZl6KOkCxn2069F6rdj91VrDMWaLu+t/t8xJ2HM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783524839; c=relaxed/simple; bh=mkADVnDhMMm3YMo67bXOuBFfTV0XX2DbTVMhyLxkf+E=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References; b=SjovQInLDvckElmsrOI6R9A6AxybfTCBYXwJUFfd72luBkXGxHHK4gOaZHPLk93x2rLDclnDsmfbh04LpJ6BYDSHn8TwrXGIkVf32K4jPrUzvOR56qt2JQIIHZzlbhveRlIY99ziRm6l8HM4oyVBXyWJ9NCWPFk/n8tRKIQ7QBE= 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=CQV5agXL; arc=none smtp.client-ip=209.85.216.42 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="CQV5agXL" Received: by mail-pj1-f42.google.com with SMTP id 98e67ed59e1d1-381c51fde6bso948361a91.2 for ; Wed, 08 Jul 2026 08:33:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1783524837; x=1784129637; darn=vger.kernel.org; h=references:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to:content-type; bh=XDL9stQ6rVAcSA7/i4i+07LdgRqlKw4+pd+ABKQXEmc=; b=CQV5agXLGn0+0gbn0cT18jP3mgDOffMn1rc48qYsVZWYdUIA1DjLAtouHJue26FmUa hqheygsaSdOPsGKvX/wHCYFNx4DK5KQ5CTKptetto7PxdDeGiyFQcooWEq7TaQlL9FsL cvXdU9ejd+pFPFu+SAekjMpIiIoXvU6iYD8lzvbESjIbUOCzho2RkgtbjHZ+r2Z8gwBF nSSM6cz74KUgobODyby4kTwlCXuZ5WZJ+lJR/JHcWD1vuexowbwUsUvlcsyhoFneCMkS AW36bbXgSYmxupbN8ivakW2B/7IxHXOzuxEinj3O2OZ41M9RrZDNq6MUlBdZcJ1JmEbk 7F2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783524837; x=1784129637; h=references:message-id:date:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=XDL9stQ6rVAcSA7/i4i+07LdgRqlKw4+pd+ABKQXEmc=; b=X+fwTaOtIbKPHu3OZH8JfAiGPGGIp9PTy7iv6kVSuhiJ7hlgfsDa50w0ml1M4ZHz32 0k0qSgqdAwgYq9Gw0gWeW/FWqyzACmbAOtnoxp40PDGL/iPp2MtW76OyQpOPELWBefoG pjWY0Fl+vqEJDeT6QOif9V+YzaBI2to2tKWHzMownBD9tEIodFNyULGWDgG2HLXXxYJS Iji44uIQLYjUuCNyyFwVdWKEcbiC53dZHDAPXcOwDPqL39R7CzesQ3P8GbGld3zK0WqK HIEUPu7lfkAtTV9rKyPcJc5YZs43zDuiQFFribnCHbyB0OyH/1Hktvkobq2CZQDmRxiH elkg== X-Forwarded-Encrypted: i=1; AHgh+RoI5mIDnlZ/TT/+2Yza8cDBT3jAgqGDpwYAE9KQdMwpUq9hccgymMokqciI0f2VqN2kcbWHsElb+jIsZmo=@vger.kernel.org X-Gm-Message-State: AOJu0Ywc0ltJyjfobaXk7YmdJJB6K0tMM+6hD0MS9pc2sp29TTAtdKKz 3kfeXUmWgqeUmYow0oUFpBLMFompI8KyRLEeuRAkVJdQd4PKxIheDAM5vb3t7g== X-Gm-Gg: AfdE7ckWBuyBU8sTwDRGvfu5rztwxzOGGTZYWENjnDFyPdrrTHH4qxbE+GL7vSOXsSp GQKF4bNu4OShqXcZf71t0eNbdc5slnOf6uUIZiTdU0EP+QOUgxYfp0t3BrioXEsVrHmtfca/jpI GZw4hqUz2BswWGBFc/WtR2mnipwcihvtjaxeE0KTRmYHinpeq1lS6KoEkgxJWYAp271Nf2Y2yIb T3PgHH5dMtmtee5FEA9q5F7xqdlxlzI/6K212GFXlM0aK8gr873T05gb0tZlC3cueeOW8J5ZtRi BSCWCh8KBXMrswy8vs965sbxXXiMpIrx/UmRPP3+APbmaHdcAjFzM71zmrqBBDCtLdq6eR/3pLw XUrEi7AaWTzFhjEwNWvtDnK264UAMKS5d6yZfnoGiPZC/DXjaoi6HIbQYPB6YdJzExqWv7qqhbb oVAmSOcPTjToU= X-Received: by 2002:a05:6a20:158e:b0:3bf:ee42:195 with SMTP id adf61e73a8af0-3c0bc90146amr3718965637.11.1783524837094; Wed, 08 Jul 2026 08:33:57 -0700 (PDT) Received: from pve-server ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-31174a8f521sm20950984eec.22.2026.07.08.08.33.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 08:33:56 -0700 (PDT) From: Ritesh Harjani (IBM) To: Shivaprasad G Bhat , maddy@linux.ibm.com, linuxppc-dev@lists.ozlabs.org Cc: mpe@ellerman.id.au, npiggin@gmail.com, chleroy@kernel.org, sbhat@linux.ibm.com, linux-kernel@vger.kernel.org Subject: Re: [PATCH] powerpc/eeh: Fix recursive locking on devices without EEH sensitive driver In-Reply-To: <177725885065.13410.12259326756082237538.stgit@linux.ibm.com> Date: Wed, 08 Jul 2026 20:36:55 +0530 Message-ID: References: <177725885065.13410.12259326756082237538.stgit@linux.ibm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Shivaprasad G Bhat writes: hey, sorry looks like this fall through the cracks. > The commit 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug > safe") refactored the EEH code such that the pci_rescan_remove_lock is > held at the beginning of eeh_handle_normal_event() and the > eeh_reset_device() is called with that lock being held. Looks like the > commit missed to remove the existing lock/unlock inside eeh_rmv_device() > which is no longer necessary. This is causing the eehd to hang on the > lock which it actually holds when that code path is taken. > > [<0>] 0xc00000011c78f870 > [<0>] __switch_to+0xfc/0x1a0 > [<0>] pci_lock_rescan_remove+0x30/0x44 > [<0>] eeh_rmv_device+0x290/0x2e0 > [<0>] eeh_pe_dev_traverse+0x80/0x130 > [<0>] eeh_reset_device+0xcc/0x23c > [<0>] eeh_handle_normal_event+0x830/0xa80 > [<0>] eeh_event_handler+0xf8/0x190 > [<0>] kthread+0x194/0x1b0 > [<0>] start_kernel_thread+0x14/0x18 > yup. I see eeh_handle_normal_event(), already holds this lock, pci_lock_rescan_remove(). And eeh_rmv_device() only ever gets called from eeh_handle_normal_event() eeh_reset_device() eeh_pe_dev_traverse(pe, eeh_rmv_device,...) OR eeh_handle_normal_event()), eeh_pe_dev_traverse(pe, eeh_rmv_device,...) In both the paths, eeh_handle_normal_event() holds this lock. Although I am not an expert in eeh area - but looking at the relevant code paths, the race looks real and this patch fixes that. So feel free to add: Reviewed-by: Ritesh Harjani (IBM) I wonder whether clang context analyzer [1] could catch this. This is a good candidate to try that out. [1]: https://lore.kernel.org/lkml/20251219154418.3592607-1-elver@google.com/ > The issue is seen for cases where the errors are detected on the PHB > directly AND|OR for devices where the driver error_detected() returns > PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no > error handlers like slot_reset(), resume() etc defined). > I am just wondering how did we catch this issue and whether we have some ways to test eeh scenarios. Although the patch looks good to me. > Fixes: 1010b4c012b0 ("powerpc/eeh: Make EEH driver device hotplug safe") Cc: stable@vger.kernel.org Let's add the above tag so that this also goes to stable trees. Since it's been sometime since this was last posted - maybe we should rebase and resend this with the above tag. -ritesh > Signed-off-by: Shivaprasad G Bhat > --- > arch/powerpc/kernel/eeh_driver.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/powerpc/kernel/eeh_driver.c b/arch/powerpc/kernel/eeh_driver.c > index 028f69158532..d64cce17a4e0 100644 > --- a/arch/powerpc/kernel/eeh_driver.c > +++ b/arch/powerpc/kernel/eeh_driver.c > @@ -533,9 +533,7 @@ static void eeh_rmv_device(struct eeh_dev *edev, void *userdata) > if (rmv_data) > list_add(&edev->rmv_entry, &rmv_data->removed_vf_list); > } else { > - pci_lock_rescan_remove(); > pci_stop_and_remove_bus_device(dev); > - pci_unlock_rescan_remove(); > } > } >