Re: [PATCH v2 1/2] Input: discard pre-registration events before attaching handlers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] input: mixed goto-based error cleanup and scope-based guards
--

commit 4198890f3caadca9048a77f9b7d142bbae15ab35
Author: Karlos Abel <kabel@voidship.net>

Input: discard pre-registration events before attaching handlers

This commit prevents replaying pre-registration events when an input handler
connects. It does this by clearing the pending event count and monotonic
timestamp under event_lock before attaching handlers.

> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 01c91fec9b7eb..d59d62caa2f92 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -2445,6 +2445,12 @@ int input_register_device(struct input_dev *dev)
>  
>  	error = -EINTR;
>  	scoped_cond_guard(mutex_intr, goto err_device_del, &input_mutex) {
> +		/* Keep seeded state, but do not replay pre-registration events. */
> +		scoped_guard(spinlock_irq, &dev->event_lock) {
> +			dev->num_vals = 0;
> +			dev->timestamp[INPUT_CLK_MONO] = ktime_set(0, 0);
> +		}
> +

[Severity: Low]
Does this mix scope-based cleanup with goto-based error handling?

The kernel cleanup guidelines in include/linux/cleanup.h and the subsystem
rules state that we should either convert all resources requiring a "goto"
cleanup to scope-based cleanup, or convert none of them. Mixing both in the
same function creates confusing ownership semantics and increases the risk
of double-free or resource leak bugs.

Because input_register_device() uses manual goto labels (err_device_del,
err_devres_free) for its failure paths, does adding new scope-based cleanup
macros like scoped_guard() here violate the cleanup guidelines?

>  		list_add_tail(&dev->node, &input_dev_list);
>  
>  		list_for_each_entry(handler, &input_handler_list, node)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261010191033.23577-1-kabel@voidship.net?part=1