[PATCH 1/2] edac: edac_device_sysfs: reject poll_msec value 0

[PATCH 1/2] edac: edac_device_sysfs: reject poll_msec value 0

[Jad Keskes]

The comment says it must be at least 1ms but there was never a check.
Writing 0 sets the workqueue delay to 0 jiffies, which makes it spin.

Signed-off-by: Jad Keskes <inasj268@gmail.com>
---
 drivers/edac/edac_device_sysfs.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/edac/edac_device_sysfs.c b/drivers/edac/edac_device_sysfs.c
index da804ebe3626..3137cf6cf36b 100644
--- a/drivers/edac/edac_device_sysfs.c
+++ b/drivers/edac/edac_device_sysfs.c
@@ -117,6 +117,10 @@ static ssize_t edac_device_ctl_poll_msec_store(struct edac_device_ctl_info
 	ret = kstrtoul(data, 0, &value);
 	if (ret < 0)
 		return ret;
+
+	if (value < 1)
+		return -EINVAL;
+
 	edac_device_reset_delay_period(ctl_info, value);
 
 	return count;
-- 
2.55.0

[PATCH 2/2] edac: edac_device: don't re-arm workqueue during teardown

[Jad Keskes]

edac_device_del_device stops the workqueue then removes the sysfs
attributes.  But the sysfs store for poll_msec calls
edac_device_reset_delay_period which unconditionally re-arms the
workqueue.  If someone writes to poll_msec in that window, the
re-armed work runs after edac_dev is freed.

Check op_state instead.  del_device already sets it to OP_OFFLINE
before tearing down the workqueue, so reset_delay_period will see
it and skip the mod_work call.

Signed-off-by: Jad Keskes <inasj268@gmail.com>
---
 drivers/edac/edac_device.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/edac/edac_device.c b/drivers/edac/edac_device.c
index cf0d3c2dfc04..50ae7f1e5152 100644
--- a/drivers/edac/edac_device.c
+++ b/drivers/edac/edac_device.c
@@ -354,6 +354,10 @@ void edac_device_reset_delay_period(struct edac_device_ctl_info *edac_dev,
 	edac_dev->poll_msec = msec;
 	edac_dev->delay	    = msecs_to_jiffies(msec);
 
+	/* Don't re-arm the workqueue if the device is being torn down */
+	if (edac_dev->op_state == OP_OFFLINE)
+		return;
+
 	/* See comment in edac_device_workq_setup() above */
 	if (edac_dev->poll_msec == DEFAULT_POLL_INTERVAL)
 		edac_mod_work(&edac_dev->work, round_jiffies_relative(edac_dev->delay));
-- 
2.55.0

Re: [PATCH 1/2] edac: edac_device_sysfs: reject poll_msec value 0

[Borislav Petkov]

On Wed, Jul 08, 2026 at 03:09:59PM +0100, Jad Keskes wrote:
> Subject: Re: [PATCH 1/2] edac: edac_device_sysfs: reject poll_msec value 0

Do

$ git log -p drivers/edac/

to get an idea about the commit title and formatting the EDAC tree does. In
this case:

EDAC/device_sysfs: Reject poll_msec value 0

> The comment says it must be at least 1ms but there was never a check.
> Writing 0 sets the workqueue delay to 0 jiffies, which makes it spin.

You might run this through AI to get better/more informative formulations.

Some hints about a good commit message:

https://docs.kernel.org/process/submitting-patches.html

> Signed-off-by: Jad Keskes <inasj268@gmail.com>
> ---
>  drivers/edac/edac_device_sysfs.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/drivers/edac/edac_device_sysfs.c b/drivers/edac/edac_device_sysfs.c
> index da804ebe3626..3137cf6cf36b 100644
> --- a/drivers/edac/edac_device_sysfs.c
> +++ b/drivers/edac/edac_device_sysfs.c
> @@ -117,6 +117,10 @@ static ssize_t edac_device_ctl_poll_msec_store(struct edac_device_ctl_info
>  	ret = kstrtoul(data, 0, &value);

If you do those patches ontop of your previous ones, it doesn't apply:

checking file drivers/edac/edac_device_sysfs.c
Hunk #1 FAILED at 117.
1 out of 1 hunk FAILED

But you need to do those fixes first and then the conversion to kstrtoul()
because the fixes will go to stable while the kstrtoul() conversion is not
stable material.

Which means, you'd need to add a Fixes: tag to those but that's fine if you
can't find which patch causes this - I believe this has always been this way.

So, how about a new patchset with all that review feedback addressed, the
fixes first, the conversion following, all nicely tested, if you don't know
how use this here in a VM:

https://lore.kernel.org/all/20260707215307.396571-1-bp@kernel.org

Thanks.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette