All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "A. Sverdlin" <alexander.sverdlin@siemens.com>
Cc: linux-leds@vger.kernel.org, lee@kernel.org
Subject: Re: [PATCH v4 4/4] leds: trigger: netdev: Serialize mode/interval stores with trigger lock
Date: Thu, 01 Oct 2026 13:20:45 +0000	[thread overview]
Message-ID: <20261001132046.4FE221F00898@smtp.kernel.org> (raw)
In-Reply-To: <20261001131206.2513248-5-alexander.sverdlin@siemens.com>

> From: Alexander Sverdlin <alexander.sverdlin@siemens.com>
> 
> netdev_led_attr_store() and interval_store() update ->mode and run
> set_baseline_state() without trigger_data->lock.  kernfs only serializes
> writes to the same file, so two attribute writes race on the non-atomic
> read-modify-write of ->mode:
> 
>   CPU0 (echo 1 > link_10)       CPU1 (echo 1 > link_100)
>   -----------------------       ------------------------
>   mode = trigger_data->mode;
>                                 mode = trigger_data->mode;
>   set_bit(LINK_10, &mode);
>                                 set_bit(LINK_100, &mode);
>   trigger_data->mode = mode;
>                                 trigger_data->mode = mode;  // LINK_10 lost
> 
> They also race the notifier's link-state and ->hw_control updates.
> 
> Take trigger_data->lock in both stores. netdev_trig_work() also holds it,
> so use the async cancel_delayed_work().
> 
> The async cancel cannot stop a worker already blocked on the lock: it may
> resume after a store enabled hw_control and keep software-blinking and
> rescheduling itself. Gate the worker and its arming in set_baseline_state()
> on a shared netdev_trig_sw_blink() helper, so it stops once offload is
> active or RX/TX monitoring is off.
> 
> Cc: stable@vger.kernel.org
> Fixes: d5e01266e7f5 ("leds: trigger: netdev: add additional specific link speed mode")
> Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261001131206.2513248-1-alexander.sverdlin@siemens.com?part=4


      reply	other threads:[~2026-10-01 13:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-01 13:11 [PATCH v4 0/4] leds: trigger: netdev: fix sysfs_update_group() races A. Sverdlin
2026-10-01 13:12 ` [PATCH v4 1/4] leds: trigger: netdev: Put netdev on activate error path A. Sverdlin
2026-10-01 13:22   ` sashiko-bot
2026-10-01 13:12 ` [PATCH v4 2/4] leds: trigger: netdev: Access net_dev under trigger_data->lock in the worker A. Sverdlin
2026-10-01 13:20   ` sashiko-bot
2026-10-01 13:12 ` [PATCH v4 3/4] leds: trigger: netdev: Fix sysfs_update_group() races A. Sverdlin
2026-10-01 13:22   ` sashiko-bot
2026-10-01 13:12 ` [PATCH v4 4/4] leds: trigger: netdev: Serialize mode/interval stores with trigger lock A. Sverdlin
2026-10-01 13:20   ` sashiko-bot [this message]

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=20261001132046.4FE221F00898@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=alexander.sverdlin@siemens.com \
    --cc=lee@kernel.org \
    --cc=linux-leds@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.