From: Greg KH <gregkh@linuxfoundation.org>
To: Yicong Yang <yang.yicong@picoheart.com>
Cc: rafael@kernel.org, lenb@kernel.org, tglx@kernel.org,
dakr@kernel.org, akpm@linux-foundation.org,
apatel@ventanamicro.com, pjw@kernel.org, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr, geshijian@picoheart.com,
weidong.wd@picoheart.com, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH 1/2] ACPI: scan: Use async schedule function for acpi_scan_clear_dep_fn
Date: Thu, 22 Jan 2026 11:29:15 +0100 [thread overview]
Message-ID: <2026012214-dinginess-improper-9bc1@gregkh> (raw)
In-Reply-To: <20260122073446.45628-2-yang.yicong@picoheart.com>
On Thu, Jan 22, 2026 at 03:34:45PM +0800, Yicong Yang wrote:
> The device object rescan in acpi_scan_clear_dep_fn is scheduled
> in the system workqueue which is not guaranteed to be finished
> before entering userspace. This will cause the problem that
> some key devices are missed when the init task try to find them,
> e.g. console devices and root devices (PCIe nvme, etc).
> This issues is more possbile to happen on RISCV since these
> devices using GSI interrupt may depend on APLIC and will be
> scanned in acpi_scan_clear_dep_queue() after APLIC initialized.
>
> Fix this by scheduling the acpi_scan_clear_dep_queue() using async
> schedule function rather than the system workqueue. The deferred
> works will be synchronized by async_synchronize_full() before
> entering init task.
>
> Update the comment as well.
>
> Signed-off-by: Yicong Yang <yang.yicong@picoheart.com>
> ---
> drivers/acpi/scan.c | 35 ++++++++++++++++-------------------
> 1 file changed, 16 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 416d87f9bd10..bf0d8ba9ba19 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -5,6 +5,7 @@
>
> #define pr_fmt(fmt) "ACPI: " fmt
>
> +#include <linux/async.h>
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/slab.h>
> @@ -2365,39 +2366,35 @@ struct acpi_scan_clear_dep_work {
> struct acpi_device *adev;
> };
>
> -static void acpi_scan_clear_dep_fn(struct work_struct *work)
> +static void acpi_scan_clear_dep_fn(void *dev, async_cookie_t cookie)
> {
> - struct acpi_scan_clear_dep_work *cdw;
> -
> - cdw = container_of(work, struct acpi_scan_clear_dep_work, work);
> + struct acpi_device *adev = to_acpi_device(dev);
>
> acpi_scan_lock_acquire();
> - acpi_bus_attach(cdw->adev, (void *)true);
> + acpi_bus_attach(adev, (void *)true);
> acpi_scan_lock_release();
>
> - acpi_dev_put(cdw->adev);
> - kfree(cdw);
> + acpi_dev_put(adev);
> }
>
> static bool acpi_scan_clear_dep_queue(struct acpi_device *adev)
> {
> - struct acpi_scan_clear_dep_work *cdw;
> -
> if (adev->dep_unmet)
> return false;
>
> - cdw = kmalloc(sizeof(*cdw), GFP_KERNEL);
> - if (!cdw)
> - return false;
> -
> - cdw->adev = adev;
> - INIT_WORK(&cdw->work, acpi_scan_clear_dep_fn);
> /*
> - * Since the work function may block on the lock until the entire
> - * initial enumeration of devices is complete, put it into the unbound
> - * workqueue.
> + * Async schedule the deferred acpi_scan_clear_dep_fn() since:
> + * - acpi_bus_attach() needs to hold acpi_scan_lock which cannot
> + * be acquired under acpi_dep_list_lock (held here)
> + * - the deferred work at boot stage is ensured to be finished
> + * before entering init task by the async_synchronize_full()
> + * barrier
> + *
> + * Use _nocall variant since it'll return on failure instead of
> + * run the function synchronously.
> */
> - queue_work(system_dfl_wq, &cdw->work);
> + if (!async_schedule_dev_nocall(acpi_scan_clear_dep_fn, &adev->dev))
> + return false;
This really feels wrong to me, you are taking a code path that has been
working for quite a while and changing it. Perhaps your system ACPI
tables are the thing that is incorrect here?
What exactly is the problem that you are seeing? Why not start with
that and then we can work out how to solve that issue?
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Yicong Yang <yang.yicong@picoheart.com>
Cc: rafael@kernel.org, lenb@kernel.org, tglx@kernel.org,
dakr@kernel.org, akpm@linux-foundation.org,
apatel@ventanamicro.com, pjw@kernel.org, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr, geshijian@picoheart.com,
weidong.wd@picoheart.com, linux-acpi@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org
Subject: Re: [PATCH 1/2] ACPI: scan: Use async schedule function for acpi_scan_clear_dep_fn
Date: Thu, 22 Jan 2026 11:29:15 +0100 [thread overview]
Message-ID: <2026012214-dinginess-improper-9bc1@gregkh> (raw)
In-Reply-To: <20260122073446.45628-2-yang.yicong@picoheart.com>
On Thu, Jan 22, 2026 at 03:34:45PM +0800, Yicong Yang wrote:
> The device object rescan in acpi_scan_clear_dep_fn is scheduled
> in the system workqueue which is not guaranteed to be finished
> before entering userspace. This will cause the problem that
> some key devices are missed when the init task try to find them,
> e.g. console devices and root devices (PCIe nvme, etc).
> This issues is more possbile to happen on RISCV since these
> devices using GSI interrupt may depend on APLIC and will be
> scanned in acpi_scan_clear_dep_queue() after APLIC initialized.
>
> Fix this by scheduling the acpi_scan_clear_dep_queue() using async
> schedule function rather than the system workqueue. The deferred
> works will be synchronized by async_synchronize_full() before
> entering init task.
>
> Update the comment as well.
>
> Signed-off-by: Yicong Yang <yang.yicong@picoheart.com>
> ---
> drivers/acpi/scan.c | 35 ++++++++++++++++-------------------
> 1 file changed, 16 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 416d87f9bd10..bf0d8ba9ba19 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -5,6 +5,7 @@
>
> #define pr_fmt(fmt) "ACPI: " fmt
>
> +#include <linux/async.h>
> #include <linux/module.h>
> #include <linux/init.h>
> #include <linux/slab.h>
> @@ -2365,39 +2366,35 @@ struct acpi_scan_clear_dep_work {
> struct acpi_device *adev;
> };
>
> -static void acpi_scan_clear_dep_fn(struct work_struct *work)
> +static void acpi_scan_clear_dep_fn(void *dev, async_cookie_t cookie)
> {
> - struct acpi_scan_clear_dep_work *cdw;
> -
> - cdw = container_of(work, struct acpi_scan_clear_dep_work, work);
> + struct acpi_device *adev = to_acpi_device(dev);
>
> acpi_scan_lock_acquire();
> - acpi_bus_attach(cdw->adev, (void *)true);
> + acpi_bus_attach(adev, (void *)true);
> acpi_scan_lock_release();
>
> - acpi_dev_put(cdw->adev);
> - kfree(cdw);
> + acpi_dev_put(adev);
> }
>
> static bool acpi_scan_clear_dep_queue(struct acpi_device *adev)
> {
> - struct acpi_scan_clear_dep_work *cdw;
> -
> if (adev->dep_unmet)
> return false;
>
> - cdw = kmalloc(sizeof(*cdw), GFP_KERNEL);
> - if (!cdw)
> - return false;
> -
> - cdw->adev = adev;
> - INIT_WORK(&cdw->work, acpi_scan_clear_dep_fn);
> /*
> - * Since the work function may block on the lock until the entire
> - * initial enumeration of devices is complete, put it into the unbound
> - * workqueue.
> + * Async schedule the deferred acpi_scan_clear_dep_fn() since:
> + * - acpi_bus_attach() needs to hold acpi_scan_lock which cannot
> + * be acquired under acpi_dep_list_lock (held here)
> + * - the deferred work at boot stage is ensured to be finished
> + * before entering init task by the async_synchronize_full()
> + * barrier
> + *
> + * Use _nocall variant since it'll return on failure instead of
> + * run the function synchronously.
> */
> - queue_work(system_dfl_wq, &cdw->work);
> + if (!async_schedule_dev_nocall(acpi_scan_clear_dep_fn, &adev->dev))
> + return false;
This really feels wrong to me, you are taking a code path that has been
working for quite a while and changing it. Perhaps your system ACPI
tables are the thing that is incorrect here?
What exactly is the problem that you are seeing? Why not start with
that and then we can work out how to solve that issue?
thanks,
greg k-h
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-01-22 10:29 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-22 7:34 [PATCH 0/2] Ensure some device initialization before init task Yicong Yang
2026-01-22 7:34 ` Yicong Yang
2026-01-22 7:34 ` [PATCH 1/2] ACPI: scan: Use async schedule function for acpi_scan_clear_dep_fn Yicong Yang
2026-01-22 7:34 ` Yicong Yang
2026-01-22 10:29 ` Greg KH [this message]
2026-01-22 10:29 ` Greg KH
2026-01-22 12:43 ` Yicong Yang
2026-01-22 12:43 ` Yicong Yang
2026-01-22 13:21 ` Rafael J. Wysocki
2026-01-22 13:21 ` Rafael J. Wysocki
2026-01-22 13:48 ` Yicong Yang
2026-01-22 13:48 ` Yicong Yang
2026-01-22 13:57 ` Rafael J. Wysocki
2026-01-22 13:57 ` Rafael J. Wysocki
2026-01-22 16:27 ` Yicong Yang
2026-01-22 16:27 ` Yicong Yang
2026-01-22 11:19 ` Rafael J. Wysocki
2026-01-22 11:19 ` Rafael J. Wysocki
2026-01-22 12:50 ` Yicong Yang
2026-01-22 12:50 ` Yicong Yang
2026-01-22 13:22 ` Rafael J. Wysocki
2026-01-22 13:22 ` Rafael J. Wysocki
2026-01-22 7:34 ` [PATCH 2/2] init: Move console_on_rootfs after async_synchronize_full Yicong Yang
2026-01-22 7:34 ` Yicong Yang
2026-01-22 10:27 ` Greg KH
2026-01-22 10:27 ` Greg KH
2026-01-22 13:12 ` Yicong Yang
2026-01-22 13:12 ` Yicong Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026012214-dinginess-improper-9bc1@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=apatel@ventanamicro.com \
--cc=dakr@kernel.org \
--cc=geshijian@picoheart.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=palmer@dabbelt.com \
--cc=pjw@kernel.org \
--cc=rafael@kernel.org \
--cc=tglx@kernel.org \
--cc=weidong.wd@picoheart.com \
--cc=yang.yicong@picoheart.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.