Received: by 2002:ab2:3141:0:b0:1ed:23cc:44d1 with SMTP id i1csp1972054lqg; Mon, 4 Mar 2024 09:02:20 -0800 (PST) X-Forwarded-Encrypted: i=3; AJvYcCW67bVdmZabjee3lckwqDchdsFBpq8SPPNzRiudCvUdmpGlsGiXwHKwnIEiMoWOx9eCVr5TZh9aXug4BdXvKh8QJHoiNma+7Z95TLNJGg== X-Google-Smtp-Source: AGHT+IF8p1zt9Ll9JRWM47c+W2rh13u+b1RPKS8udBjomXwwim4oGyx2SH1qDraC/Ia10fBP8pAH X-Received: by 2002:a6b:6a09:0:b0:7c8:4e78:2429 with SMTP id x9-20020a6b6a09000000b007c84e782429mr4081005iog.2.1709571739916; Mon, 04 Mar 2024 09:02:19 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1709571739; cv=pass; d=google.com; s=arc-20160816; b=AGAHQ3pDPSjeUPJLCLFAXBdOcDQ7Xj2rgGBvzY621L9chNd+43F9pDiKUvEayOjfAW dV8xl7Ryaz1K/9hOgNMV14NvxUJ4NcGTewnY7rVatLRcvDAuVCDFMl+KSsb4lqfxYuXn +fw5/btEaDFiKoaSSfLn28/i5QNXpM+AzMwYIMHhcl+USxzu+PBDRVGkWIITK1RTt9XI POjMI7SwrtJUyR9Cks3KBiNwfeEkcKc00CCqz2Zr2xQER6xYik5v5qy+Hxh7RTzN1Tvh 37rY/BQaV77WmRIhtCBZ/i+zdZ/QmW5YpQXiSapJCtzL8sSFoDnyA0IxNXfB8QcClmvf z/YA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:list-unsubscribe:list-subscribe :list-id:precedence; bh=a+zuvGq2BylT2luj+C31yYI14tYn4jtwnQpoH9GR+z0=; fh=H/QSCuE/HOqfUMgsaH16g176EOXp8xy0f+ynuuEghv0=; b=G7WHpboqkSBKRdGjLwibYrRtChBH8Nl+715ZwRchW9VZhNGMxY65tXFQvIY2F1ASJu qjZNkpJf1jxt0i8F8Qyx5zge54iuVxIbNYEy8gNRVHJTJBTcQ9YTHwsdd9JEdhnMZrIr 9iqb+sqDo4JIZtueBkOR+M2wCSI7xF1KNTgrZB88Xtozbh4X6KMp48FeptlOun+E8YWw VdDJqdAPNmt93c3e5soY3PltiMIioUA5r/3fncNbi9gwP3UyniQXh99h7EbQVeDA3zfA cFudd0oIXDvDFfOEjE6I1luHPsQJ+PUt5Jwb+TnY6uOO2uFH6CjozY/ExI0mHMNGFjvX qpdQ==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=gmail.com); spf=pass (google.com: domain of linux-kernel+bounces-90972-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-90972-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from ny.mirrors.kernel.org (ny.mirrors.kernel.org. [2604:1380:45d1:ec00::1]) by mx.google.com with ESMTPS id u23-20020a02c057000000b00473d772191fsi3081339jam.120.2024.03.04.09.02.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 04 Mar 2024 09:02:19 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-90972-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=gmail.com); spf=pass (google.com: domain of linux-kernel+bounces-90972-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) smtp.mailfrom="linux-kernel+bounces-90972-linux.lists.archive=gmail.com@vger.kernel.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ny.mirrors.kernel.org (Postfix) with ESMTPS id 721951C226E4 for ; Mon, 4 Mar 2024 17:01:11 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 3BB026026A; Mon, 4 Mar 2024 17:00:56 +0000 (UTC) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com [209.85.210.43]) (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 E1B075CDC8; Mon, 4 Mar 2024 17:00:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.43 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709571655; cv=none; b=W/kQV+NjGenVAfqOZL1twVtP2HNAGiEfj8oifM/cf7em7pKIDoaO3m5GxjaFZmTCSDfpVnQgHyEbe4fsRyGc1SLV61PWakW5rfSUbta34kgPvZqTArWjfT+OX0miYoCXfvwYuYUwRC9KqVx+nRuNllsLLADKAnmNLpRpUK53Irw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709571655; c=relaxed/simple; bh=Laz43/toJ+CkA+jWC7gzQOwmXAzKZT27uTX7HYmngHk=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=IXmnpAXIV+tGt+uoP1SNBG8N8OnvkjfniutkmG4iefTKHUXc16RmiQepmqVgo3dYoGA1oTnDTI/QAgh6LcARPJBi2u8A3KIjsVp91fkWqOyhClPcuazJOMLpo/E1/7OP33z7jjnAyoZZk7AB5WgCDcJ/ZGPzUwswcIa74AmT474= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.210.43 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ot1-f43.google.com with SMTP id 46e09a7af769-6e447c39525so1139148a34.0; Mon, 04 Mar 2024 09:00:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709571653; x=1710176453; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=a+zuvGq2BylT2luj+C31yYI14tYn4jtwnQpoH9GR+z0=; b=NOhQftf0MWO2yLWUFPJO+HCoBdMkilyGnobiJ7bszvmd8vsSLssWQGaSvqzfLNs9vH 5WQo6stSSlKvzKikXVV4ptLMwS3c7eP2amdqe+FZmXj7oRtJcVUgw+YxKnNS5gIVRd1q yH+xWidx1z1tsMrw/zuJlnZq1+pQQoNzntxZkNtQqs/LQE4lmoPg8BDY43wRuvuIGK6D i1FdoaldivtODGeU3nWFs3LyactF+AZwQwjZTjb/wt2FbUxRgKre8ncf+rgBz6gaMISo LfTlgdth5GL+WEKBdRkkT+fwPHS7UuvGJv++Sg6lJUJL6v5weX+TDCNw8E4Gi73golTf h31w== X-Forwarded-Encrypted: i=1; AJvYcCUPaY530fBMxgcKm5CYNw2ZSdqkK14+NHGhChvvS0fyjR6oaha1da/HgO2UhZayV+9pQEqIZ1AnVCWyY673Ifkj9INJGv4HjBlS/n39e/ObTCIA1m5C5xtMNhNf9LUWii3uLwefunAht44lc+SYbeyYLbpUpe6yEWbhU6kT6chtwNyw6r3sEJSvVzHboTgfPWbwjM5eHsHNQaABq9xY X-Gm-Message-State: AOJu0YxSvXNV4DrDYnn9vEa4C6VKgvsf+SWi4Y0m/chmZAoFMpF+t8xe QfihEm9m06uwt/nFsYkvALqWMn5IFZPF1UuBave5umMD7+DDFwqOQJTnOUm8FLuLHg/5Z4s8NV+ Uvronl0/qgP15yh+z49WQNEuwpmE= X-Received: by 2002:a05:6870:3913:b0:21e:c50a:5e91 with SMTP id b19-20020a056870391300b0021ec50a5e91mr10750683oap.0.1709571652985; Mon, 04 Mar 2024 09:00:52 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20240304155138.GA482969@bhelgaas> In-Reply-To: From: "Rafael J. Wysocki" Date: Mon, 4 Mar 2024 18:00:41 +0100 Message-ID: Subject: Re: [PATCH v3] driver core: Cancel scheduled pm_runtime_idle() on device removal To: Bjorn Helgaas Cc: Kai-Heng Feng , gregkh@linuxfoundation.org, bhelgaas@google.com, linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org, Ricky Wu , Kees Cook , Tony Luck , "Guilherme G. Piccoli" , linux-hardening@vger.kernel.org, bpf@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 4, 2024 at 5:41=E2=80=AFPM Rafael J. Wysocki wrote: > > On Mon, Mar 4, 2024 at 4:51=E2=80=AFPM Bjorn Helgaas = wrote: > > > > On Mon, Mar 04, 2024 at 03:38:38PM +0100, Rafael J. Wysocki wrote: > > > On Thu, Feb 29, 2024 at 7:23=E2=80=AFAM Kai-Heng Feng > > > wrote: > > > > > > > > When inserting an SD7.0 card to Realtek card reader, the card reade= r > > > > unplugs itself and morph into a NVMe device. The slot Link down on = hot > > > > unplugged can cause the following error: > > > > > > > > pcieport 0000:00:1c.0: pciehp: Slot(8): Link Down > > > > BUG: unable to handle page fault for address: ffffb24d403e5010 > > > > PGD 100000067 P4D 100000067 PUD 1001fe067 PMD 100d97067 PTE 0 > > > > Oops: 0000 [#1] PREEMPT SMP PTI > > > > CPU: 3 PID: 534 Comm: kworker/3:10 Not tainted 6.4.0 #6 > > > > Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./H370M = Pro4, BIOS P3.40 10/25/2018 > > > > Workqueue: pm pm_runtime_work > > > > RIP: 0010:ioread32+0x2e/0x70 > > > ... > > > > Call Trace: > > > > > > > > ? show_regs+0x68/0x70 > > > > ? __die_body+0x20/0x70 > > > > ? __die+0x2b/0x40 > > > > ? page_fault_oops+0x160/0x480 > > > > ? search_bpf_extables+0x63/0x90 > > > > ? ioread32+0x2e/0x70 > > > > ? search_exception_tables+0x5f/0x70 > > > > ? kernelmode_fixup_or_oops+0xa2/0x120 > > > > ? __bad_area_nosemaphore+0x179/0x230 > > > > ? bad_area_nosemaphore+0x16/0x20 > > > > ? do_kern_addr_fault+0x8b/0xa0 > > > > ? exc_page_fault+0xe5/0x180 > > > > ? asm_exc_page_fault+0x27/0x30 > > > > ? ioread32+0x2e/0x70 > > > > ? rtsx_pci_write_register+0x5b/0x90 [rtsx_pci] > > > > rtsx_set_l1off_sub+0x1c/0x30 [rtsx_pci] > > > > rts5261_set_l1off_cfg_sub_d0+0x36/0x40 [rtsx_pci] > > > > rtsx_pci_runtime_idle+0xc7/0x160 [rtsx_pci] > > > > ? __pfx_pci_pm_runtime_idle+0x10/0x10 > > > > pci_pm_runtime_idle+0x34/0x70 > > > > rpm_idle+0xc4/0x2b0 > > > > pm_runtime_work+0x93/0xc0 > > > > process_one_work+0x21a/0x430 > > > > worker_thread+0x4a/0x3c0 > > > ... > > > > > > This happens because scheduled pm_runtime_idle() is not cancelled. > > > > > > But rpm_resume() changes dev->power.request to RPM_REQ_NONE and if > > > pm_runtime_work() sees this, it will not run rpm_idle(). > > > > > > However, rpm_resume() doesn't deactivate the autosuspend timer if it > > > is running (see the comment in rpm_resume() regarding this), so it ma= y > > > queue up a runtime PM work later. > > > > > > If this is not desirable, you need to stop the autosuspend timer > > > explicitly in addition to calling pm_runtime_get_sync(). > > > > I don't quite follow all this. I think the race is between > > rtsx_pci_remove() (not resume) and rtsx_pci_runtime_idle(). > > I think so too and the latter is not expected to run. > > > rtsx_pci_remove() > > { > > pm_runtime_get_sync() > > pm_runtime_forbid() > > ... > > > > If this is an rtsx bug, what exactly should be added to > > rtsx_pci_remove()? > > > > Is there ever a case where we want any runtime PM work to happen > > during or after a driver .remove()? If not, maybe the driver core > > should prevent that, which I think is basically what this patch does. > > No, it is not, because it doesn't actually prevent the race from > occurring, it just narrows the window quite a bit. > > It would be better to call pm_runtime_dont_use_autosuspend() instead > of pm_runtime_barrier(). > > > If this is an rtsx driver bug, I'm concerned there may be many other > > drivers with a similar issue. rtsx exercises this path more than most > > because the device switches between card reader and NVMe SSD using > > hotplug add/remove based on whether an SD card is inserted (see [1]). > > This is a valid concern, so it is mostly a matter of where to disable > autosuspend. > > It may be the driver core in principle, but note that it calls > ->remove() after invoking pm_runtime_put_sync(), so why would it > disable autosuspend when it allows runtime PM to race with device > removal in general? > > Another way might be to add a pm_runtime_dont_use_autosuspend() call > at the beginning of pci_device_remove(). > > Or just remove the optimization in question from rpm_resume() which is > quite confusing and causes people to make assumptions that lead to > incorrect behavior in this particular case. Well, scratch this. If rpm_idle() is already running at the time rpm_resume() is called, the latter may return right away without waiting, which is incorrect. rpm_resume() needs to wait for the "idle" callback to complete, so this (again, modulo GMail-induced whitespace mangling) should help: --- drivers/base/power/runtime.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) Index: linux-pm/drivers/base/power/runtime.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- linux-pm.orig/drivers/base/power/runtime.c +++ linux-pm/drivers/base/power/runtime.c @@ -798,7 +798,8 @@ static int rpm_resume(struct device *dev } if (dev->power.runtime_status =3D=3D RPM_RESUMING || - dev->power.runtime_status =3D=3D RPM_SUSPENDING) { + dev->power.runtime_status =3D=3D RPM_SUSPENDING || + dev->power.idle_notification) { DEFINE_WAIT(wait); if (rpmflags & (RPM_ASYNC | RPM_NOWAIT)) { @@ -826,7 +827,8 @@ static int rpm_resume(struct device *dev prepare_to_wait(&dev->power.wait_queue, &wait, TASK_UNINTERRUPTIBLE); if (dev->power.runtime_status !=3D RPM_RESUMING && - dev->power.runtime_status !=3D RPM_SUSPENDING) + dev->power.runtime_status !=3D RPM_SUSPENDING && + !dev->power.idle_notification) break; spin_unlock_irq(&dev->power.lock);