From: sashiko-bot@kernel.org
To: "Eliav Farber" <farbere@amazon.com>
Cc: dmitry.torokhov@gmail.com, linux-input@vger.kernel.org
Subject: Re: [PATCH v5 01/13] notifier: add device-managed registration APIs
Date: Sun, 16 Aug 2026 06:19:06 +0000 [thread overview]
Message-ID: <20260816061906.915E61F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260816060648.4030-2-farbere@amazon.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] The patch omits explicitly callable devm_*_unregister() functions, preventing safe early unregistration in drivers.
- [Medium] devm_atomic_notifier_chain_register() is implicitly restricted to process context but its documentation does not state this.
- [Low] Device-managed registration for SRCU notifiers is omitted without justification.
--
--- Patch [1]: [PATCH v5 01/13] notifier: add device-managed registration APIs ---
commit 123931abf8d80f91fce35443259e0df9e2736a4e
Author: Eliav Farber <farbere@amazon.com>
notifier: add device-managed registration APIs
This patch adds devm_atomic_notifier_chain_register() and
devm_blocking_notifier_chain_register() that automatically unregister
the notifier when the device is unbound. This reduces boilerplate in
drivers by eliminating per-driver unregister callbacks.
> diff --git a/include/linux/notifier.h b/include/linux/notifier.h
> index 01b6c9d9956f9..4eeae9741a6e8 100644
> --- a/include/linux/notifier.h
> +++ b/include/linux/notifier.h
[ ... ]
> @@ -145,8 +146,14 @@ extern void srcu_init_notifier_head(struct srcu_notifier_head *nh);
>
> extern int atomic_notifier_chain_register(struct atomic_notifier_head *nh,
> struct notifier_block *nb);
> +int devm_atomic_notifier_chain_register(struct device *dev,
> + struct atomic_notifier_head *nh,
> + struct notifier_block *nb);
[Severity: Medium]
Should there be corresponding devm_atomic_notifier_chain_unregister() and
devm_blocking_notifier_chain_unregister() functions provided?
If a driver needs to unregister early to quiesce hardware, manually calling
the non-devm unregister function leaves a stale devres action. This performs
a useless double-unregister during devres_release_all(), which
unconditionally hits the slow synchronize_rcu() and delays unbind.
> extern int blocking_notifier_chain_register(struct blocking_notifier_head *nh,
> struct notifier_block *nb);
> +int devm_blocking_notifier_chain_register(struct device *dev,
> + struct blocking_notifier_head *nh,
> + struct notifier_block *nb);
> extern int raw_notifier_chain_register(struct raw_notifier_head *nh,
> struct notifier_block *nb);
> extern int srcu_notifier_chain_register(struct srcu_notifier_head *nh,
[Severity: Low]
Is there a reason the devm variant for SRCU notifiers was omitted?
The commit message justifies omitting raw notifiers due to locking
constraints, but SRCU notifiers manage their own internal mutex which should
be safe to lock in the devres teardown context.
> diff --git a/kernel/notifier.c b/kernel/notifier.c
> index 2f9fe7c30287f..0c39627ea69c5 100644
> --- a/kernel/notifier.c
> +++ b/kernel/notifier.c
[ ... ]
> @@ -197,6 +198,56 @@ int atomic_notifier_chain_unregister(struct atomic_notifier_head *nh,
> }
> EXPORT_SYMBOL_GPL(atomic_notifier_chain_unregister);
>
> +struct atomic_notifier_chain_devres {
> + struct atomic_notifier_head *nh;
> + struct notifier_block *nb;
> +};
> +
> +static void devm_atomic_notifier_chain_unregister(struct device *dev, void *res)
> +{
> + struct atomic_notifier_chain_devres *dr = res;
> +
> + atomic_notifier_chain_unregister(dr->nh, dr->nb);
> +}
> +
> +/**
> + * devm_atomic_notifier_chain_register - Device-managed atomic notifier registration
> + * @dev: Device to tie the notifier lifetime to
> + * @nh: Pointer to head of the atomic notifier chain
> + * @nb: New entry in notifier chain
> + *
> + * Adds a notifier to an atomic notifier chain and registers a cleanup
> + * action to automatically unregister it when @dev is unbound.
> + *
> + * Return:
> + * 0 on success, negative errno on error.
> + */
[Severity: Medium]
Should this kerneldoc include a context warning like "Must be called in
process context."?
Unlike atomic_notifier_chain_register() which is safe in atomic context,
this function uses devres_alloc() with GFP_KERNEL which can sleep, making it
unsafe to call from atomic context.
> +int devm_atomic_notifier_chain_register(struct device *dev,
> + struct atomic_notifier_head *nh,
> + struct notifier_block *nb)
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260816060648.4030-1-farbere@amazon.com?part=1
next prev parent reply other threads:[~2026-08-16 6:19 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-16 6:05 [PATCH v5 00/13] notifier: add device-managed registration APIs and convert drivers Eliav Farber
2026-08-16 6:06 ` [PATCH v5 01/13] notifier: add device-managed registration APIs Eliav Farber
2026-08-16 6:19 ` sashiko-bot [this message]
2026-08-16 7:00 ` Uwe Kleine-König
2026-08-16 7:04 ` Uwe Kleine-König
2026-08-16 6:06 ` [PATCH v5 02/13] pwm: iqs620a: use devm_blocking_notifier_chain_register() Eliav Farber
2026-08-16 6:06 ` [PATCH v5 03/13] iio: light: iqs621-als: " Eliav Farber
2026-08-16 6:06 ` [PATCH v5 04/13] iio: position: iqs624: " Eliav Farber
2026-08-16 6:06 ` [PATCH v5 05/13] gpio: adp5585: " Eliav Farber
2026-08-16 6:14 ` sashiko-bot
2026-08-16 6:06 ` [PATCH v5 06/13] platform/x86: bitland-mifs-wmi: " Eliav Farber
2026-08-16 6:06 ` [PATCH v5 07/13] Input: adp5585: " Eliav Farber
2026-08-16 6:14 ` sashiko-bot
2026-08-16 6:06 ` [PATCH v5 08/13] ACPI: APEI: GHES: remove unused ghes_{,un}register_vendor_record_notifier() Eliav Farber
2026-08-16 6:06 ` [PATCH v5 09/13] ACPI: APEI: GHES: use devm_blocking_notifier_chain_register() Eliav Farber
2026-08-16 6:06 ` [PATCH v5 10/13] platform/x86: uniwill-wmi: " Eliav Farber
2026-08-16 6:06 ` [PATCH v5 11/13] gpio: eic-sprd: use devm_atomic_notifier_chain_register() Eliav Farber
2026-08-16 6:06 ` [PATCH v5 12/13] gpio: gpiolib-kunit: use devm_blocking_notifier_chain_register() Eliav Farber
2026-08-16 6:06 ` [PATCH v5 13/13] reboot: " Eliav Farber
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=20260816061906.915E61F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=farbere@amazon.com \
--cc=linux-input@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.