* [PATCH 0/4] Fix oops about sleeping in led_trigger_blink()
@ 2023-04-12 21:58 Hans de Goede
2023-04-12 21:58 ` [PATCH 1/4] leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-value Hans de Goede
` (5 more replies)
0 siblings, 6 replies; 15+ messages in thread
From: Hans de Goede @ 2023-04-12 21:58 UTC (permalink / raw)
To: Pavel Machek, Lee Jones; +Cc: Hans de Goede, Johannes Berg, linux-leds
Hi All,
Here is a patch series to fix an oops about sleeping in led_trigger_blink()
+ one other small bugfix.
Patches 1-3 should arguably have a:
Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
tag, but Fixes tags tend to lead to patches getting automatically added
to the stable series and I would prefer to see this series get some
significant testing time in mainline first, so I have chosen to omit
the tag.
Regards,
Hans
Hans de Goede (4):
leds: Change led_trigger_blink[_oneshot]() delay parameters to
pass-by-value
leds: Fix set_brightness_delayed() race
leds: Fix oops about sleeping in led_trigger_blink()
leds: Clear LED_INIT_DEFAULT_TRIGGER when clearing current trigger
drivers/leds/led-core.c | 81 ++++++++++++++++++++----
drivers/leds/led-triggers.c | 17 ++---
drivers/leds/trigger/ledtrig-disk.c | 9 +--
drivers/leds/trigger/ledtrig-mtd.c | 8 +--
drivers/net/arcnet/arcnet.c | 8 +--
drivers/power/supply/power_supply_leds.c | 5 +-
drivers/usb/common/led.c | 4 +-
include/linux/leds.h | 43 ++++++++++---
net/mac80211/led.c | 2 +-
net/mac80211/led.h | 8 +--
net/netfilter/xt_LED.c | 3 +-
11 files changed, 125 insertions(+), 63 deletions(-)
--
2.39.1
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH 1/4] leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-value
2023-04-12 21:58 [PATCH 0/4] Fix oops about sleeping in led_trigger_blink() Hans de Goede
@ 2023-04-12 21:58 ` Hans de Goede
2023-05-10 11:57 ` Lee Jones
2023-04-12 21:58 ` [PATCH 2/4] leds: Fix set_brightness_delayed() race Hans de Goede
` (4 subsequent siblings)
5 siblings, 1 reply; 15+ messages in thread
From: Hans de Goede @ 2023-04-12 21:58 UTC (permalink / raw)
To: Pavel Machek, Lee Jones; +Cc: Hans de Goede, Johannes Berg, linux-leds
led_blink_set[_oneshot]()'s delay_on and delay_off function parameters
are pass by reference, so that hw-blink implementations can report
back the actual achieved delays when the values have been rounded
to something the hw supports.
This is really only interesting for the sysfs API / the timer trigger.
Other triggers don't really care about this and none of the callers of
led_trigger_blink[_oneshot]() do anything with the returned delay values.
Change the led_trigger_blink[_oneshot]() delay parameters to pass-by-value,
there are 2 reasons for this:
1. led_cdev->blink_set() may sleep, while led_trigger_blink() may not.
So on hw where led_cdev->blink_set() sleeps the call needs to be deferred
to a workqueue, in which case the actual achieved delays are unknown
(this is a preparation patch for the deferring).
2. Since the callers don't care about the actual achieved delays, allowing
callers to directly pass a value leads to simpler code for most callers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/leds/led-triggers.c | 16 ++++++++--------
drivers/leds/trigger/ledtrig-disk.c | 9 +++------
drivers/leds/trigger/ledtrig-mtd.c | 8 ++------
drivers/net/arcnet/arcnet.c | 8 ++------
drivers/power/supply/power_supply_leds.c | 5 +----
drivers/usb/common/led.c | 4 +---
include/linux/leds.h | 16 ++++++++--------
net/mac80211/led.c | 2 +-
net/mac80211/led.h | 8 ++------
net/netfilter/xt_LED.c | 3 +--
10 files changed, 29 insertions(+), 50 deletions(-)
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 072491d3e17b..e06361165e9b 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -393,8 +393,8 @@ void led_trigger_event(struct led_trigger *trig,
EXPORT_SYMBOL_GPL(led_trigger_event);
static void led_trigger_blink_setup(struct led_trigger *trig,
- unsigned long *delay_on,
- unsigned long *delay_off,
+ unsigned long delay_on,
+ unsigned long delay_off,
int oneshot,
int invert)
{
@@ -406,25 +406,25 @@ static void led_trigger_blink_setup(struct led_trigger *trig,
rcu_read_lock();
list_for_each_entry_rcu(led_cdev, &trig->led_cdevs, trig_list) {
if (oneshot)
- led_blink_set_oneshot(led_cdev, delay_on, delay_off,
+ led_blink_set_oneshot(led_cdev, &delay_on, &delay_off,
invert);
else
- led_blink_set(led_cdev, delay_on, delay_off);
+ led_blink_set(led_cdev, &delay_on, &delay_off);
}
rcu_read_unlock();
}
void led_trigger_blink(struct led_trigger *trig,
- unsigned long *delay_on,
- unsigned long *delay_off)
+ unsigned long delay_on,
+ unsigned long delay_off)
{
led_trigger_blink_setup(trig, delay_on, delay_off, 0, 0);
}
EXPORT_SYMBOL_GPL(led_trigger_blink);
void led_trigger_blink_oneshot(struct led_trigger *trig,
- unsigned long *delay_on,
- unsigned long *delay_off,
+ unsigned long delay_on,
+ unsigned long delay_off,
int invert)
{
led_trigger_blink_setup(trig, delay_on, delay_off, 1, invert);
diff --git a/drivers/leds/trigger/ledtrig-disk.c b/drivers/leds/trigger/ledtrig-disk.c
index 0b7dfbd04273..e9b87ee944f2 100644
--- a/drivers/leds/trigger/ledtrig-disk.c
+++ b/drivers/leds/trigger/ledtrig-disk.c
@@ -19,16 +19,13 @@ DEFINE_LED_TRIGGER(ledtrig_disk_write);
void ledtrig_disk_activity(bool write)
{
- unsigned long blink_delay = BLINK_DELAY;
-
- led_trigger_blink_oneshot(ledtrig_disk,
- &blink_delay, &blink_delay, 0);
+ led_trigger_blink_oneshot(ledtrig_disk, BLINK_DELAY, BLINK_DELAY, 0);
if (write)
led_trigger_blink_oneshot(ledtrig_disk_write,
- &blink_delay, &blink_delay, 0);
+ BLINK_DELAY, BLINK_DELAY, 0);
else
led_trigger_blink_oneshot(ledtrig_disk_read,
- &blink_delay, &blink_delay, 0);
+ BLINK_DELAY, BLINK_DELAY, 0);
}
EXPORT_SYMBOL(ledtrig_disk_activity);
diff --git a/drivers/leds/trigger/ledtrig-mtd.c b/drivers/leds/trigger/ledtrig-mtd.c
index 8fa763c2269b..bbe6876a249d 100644
--- a/drivers/leds/trigger/ledtrig-mtd.c
+++ b/drivers/leds/trigger/ledtrig-mtd.c
@@ -22,12 +22,8 @@ DEFINE_LED_TRIGGER(ledtrig_nand);
void ledtrig_mtd_activity(void)
{
- unsigned long blink_delay = BLINK_DELAY;
-
- led_trigger_blink_oneshot(ledtrig_mtd,
- &blink_delay, &blink_delay, 0);
- led_trigger_blink_oneshot(ledtrig_nand,
- &blink_delay, &blink_delay, 0);
+ led_trigger_blink_oneshot(ledtrig_mtd, BLINK_DELAY, BLINK_DELAY, 0);
+ led_trigger_blink_oneshot(ledtrig_nand, BLINK_DELAY, BLINK_DELAY, 0);
}
EXPORT_SYMBOL(ledtrig_mtd_activity);
diff --git a/drivers/net/arcnet/arcnet.c b/drivers/net/arcnet/arcnet.c
index 1bad1866ae46..99265667538c 100644
--- a/drivers/net/arcnet/arcnet.c
+++ b/drivers/net/arcnet/arcnet.c
@@ -196,13 +196,10 @@ static void arcnet_dump_packet(struct net_device *dev, int bufnum,
void arcnet_led_event(struct net_device *dev, enum arcnet_led_event event)
{
struct arcnet_local *lp = netdev_priv(dev);
- unsigned long led_delay = 350;
- unsigned long tx_delay = 50;
switch (event) {
case ARCNET_LED_EVENT_RECON:
- led_trigger_blink_oneshot(lp->recon_led_trig,
- &led_delay, &led_delay, 0);
+ led_trigger_blink_oneshot(lp->recon_led_trig, 350, 350, 0);
break;
case ARCNET_LED_EVENT_OPEN:
led_trigger_event(lp->tx_led_trig, LED_OFF);
@@ -213,8 +210,7 @@ void arcnet_led_event(struct net_device *dev, enum arcnet_led_event event)
led_trigger_event(lp->recon_led_trig, LED_OFF);
break;
case ARCNET_LED_EVENT_TX:
- led_trigger_blink_oneshot(lp->tx_led_trig,
- &tx_delay, &tx_delay, 0);
+ led_trigger_blink_oneshot(lp->tx_led_trig, 50, 50, 0);
break;
}
}
diff --git a/drivers/power/supply/power_supply_leds.c b/drivers/power/supply/power_supply_leds.c
index 702bf83f6e6d..e2f554e4e4e6 100644
--- a/drivers/power/supply/power_supply_leds.c
+++ b/drivers/power/supply/power_supply_leds.c
@@ -22,8 +22,6 @@
static void power_supply_update_bat_leds(struct power_supply *psy)
{
union power_supply_propval status;
- unsigned long delay_on = 0;
- unsigned long delay_off = 0;
if (power_supply_get_property(psy, POWER_SUPPLY_PROP_STATUS, &status))
return;
@@ -42,8 +40,7 @@ static void power_supply_update_bat_leds(struct power_supply *psy)
led_trigger_event(psy->charging_full_trig, LED_FULL);
led_trigger_event(psy->charging_trig, LED_FULL);
led_trigger_event(psy->full_trig, LED_OFF);
- led_trigger_blink(psy->charging_blink_full_solid_trig,
- &delay_on, &delay_off);
+ led_trigger_blink(psy->charging_blink_full_solid_trig, 0, 0);
break;
default:
led_trigger_event(psy->charging_full_trig, LED_OFF);
diff --git a/drivers/usb/common/led.c b/drivers/usb/common/led.c
index 0865dd44a80a..1de18d90b134 100644
--- a/drivers/usb/common/led.c
+++ b/drivers/usb/common/led.c
@@ -14,8 +14,6 @@
#define BLINK_DELAY 30
-static unsigned long usb_blink_delay = BLINK_DELAY;
-
DEFINE_LED_TRIGGER(ledtrig_usb_gadget);
DEFINE_LED_TRIGGER(ledtrig_usb_host);
@@ -32,7 +30,7 @@ void usb_led_activity(enum usb_led_event ev)
break;
}
/* led_trigger_blink_oneshot() handles trig == NULL gracefully */
- led_trigger_blink_oneshot(trig, &usb_blink_delay, &usb_blink_delay, 0);
+ led_trigger_blink_oneshot(trig, BLINK_DELAY, BLINK_DELAY, 0);
}
EXPORT_SYMBOL_GPL(usb_led_activity);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index d71201a968b6..6006786cafdc 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -415,11 +415,11 @@ void led_trigger_register_simple(const char *name,
struct led_trigger **trigger);
void led_trigger_unregister_simple(struct led_trigger *trigger);
void led_trigger_event(struct led_trigger *trigger, enum led_brightness event);
-void led_trigger_blink(struct led_trigger *trigger, unsigned long *delay_on,
- unsigned long *delay_off);
+void led_trigger_blink(struct led_trigger *trigger, unsigned long delay_on,
+ unsigned long delay_off);
void led_trigger_blink_oneshot(struct led_trigger *trigger,
- unsigned long *delay_on,
- unsigned long *delay_off,
+ unsigned long delay_on,
+ unsigned long delay_off,
int invert);
void led_trigger_set_default(struct led_classdev *led_cdev);
int led_trigger_set(struct led_classdev *led_cdev, struct led_trigger *trigger);
@@ -469,11 +469,11 @@ static inline void led_trigger_unregister_simple(struct led_trigger *trigger) {}
static inline void led_trigger_event(struct led_trigger *trigger,
enum led_brightness event) {}
static inline void led_trigger_blink(struct led_trigger *trigger,
- unsigned long *delay_on,
- unsigned long *delay_off) {}
+ unsigned long delay_on,
+ unsigned long delay_off) {}
static inline void led_trigger_blink_oneshot(struct led_trigger *trigger,
- unsigned long *delay_on,
- unsigned long *delay_off,
+ unsigned long delay_on,
+ unsigned long delay_off,
int invert) {}
static inline void led_trigger_set_default(struct led_classdev *led_cdev) {}
static inline int led_trigger_set(struct led_classdev *led_cdev,
diff --git a/net/mac80211/led.c b/net/mac80211/led.c
index 6de8d0ad5497..2dc732147e85 100644
--- a/net/mac80211/led.c
+++ b/net/mac80211/led.c
@@ -282,7 +282,7 @@ static void tpt_trig_timer(struct timer_list *t)
}
}
- led_trigger_blink(&local->tpt_led, &on, &off);
+ led_trigger_blink(&local->tpt_led, on, off);
}
const char *
diff --git a/net/mac80211/led.h b/net/mac80211/led.h
index b71a1428d883..d25f13346b82 100644
--- a/net/mac80211/led.h
+++ b/net/mac80211/led.h
@@ -13,22 +13,18 @@
static inline void ieee80211_led_rx(struct ieee80211_local *local)
{
#ifdef CONFIG_MAC80211_LEDS
- unsigned long led_delay = MAC80211_BLINK_DELAY;
-
if (!atomic_read(&local->rx_led_active))
return;
- led_trigger_blink_oneshot(&local->rx_led, &led_delay, &led_delay, 0);
+ led_trigger_blink_oneshot(&local->rx_led, MAC80211_BLINK_DELAY, MAC80211_BLINK_DELAY, 0);
#endif
}
static inline void ieee80211_led_tx(struct ieee80211_local *local)
{
#ifdef CONFIG_MAC80211_LEDS
- unsigned long led_delay = MAC80211_BLINK_DELAY;
-
if (!atomic_read(&local->tx_led_active))
return;
- led_trigger_blink_oneshot(&local->tx_led, &led_delay, &led_delay, 0);
+ led_trigger_blink_oneshot(&local->tx_led, MAC80211_BLINK_DELAY, MAC80211_BLINK_DELAY, 0);
#endif
}
diff --git a/net/netfilter/xt_LED.c b/net/netfilter/xt_LED.c
index 66b0f941d8fb..36c9720ad8d6 100644
--- a/net/netfilter/xt_LED.c
+++ b/net/netfilter/xt_LED.c
@@ -43,7 +43,6 @@ led_tg(struct sk_buff *skb, const struct xt_action_param *par)
{
const struct xt_led_info *ledinfo = par->targinfo;
struct xt_led_info_internal *ledinternal = ledinfo->internal_data;
- unsigned long led_delay = XT_LED_BLINK_DELAY;
/*
* If "always blink" is enabled, and there's still some time until the
@@ -52,7 +51,7 @@ led_tg(struct sk_buff *skb, const struct xt_action_param *par)
if ((ledinfo->delay > 0) && ledinfo->always_blink &&
timer_pending(&ledinternal->timer))
led_trigger_blink_oneshot(&ledinternal->netfilter_led_trigger,
- &led_delay, &led_delay, 1);
+ XT_LED_BLINK_DELAY, XT_LED_BLINK_DELAY, 1);
else
led_trigger_event(&ledinternal->netfilter_led_trigger, LED_FULL);
--
2.39.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 2/4] leds: Fix set_brightness_delayed() race
2023-04-12 21:58 [PATCH 0/4] Fix oops about sleeping in led_trigger_blink() Hans de Goede
2023-04-12 21:58 ` [PATCH 1/4] leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-value Hans de Goede
@ 2023-04-12 21:58 ` Hans de Goede
2023-04-12 21:58 ` [PATCH 3/4] leds: Fix oops about sleeping in led_trigger_blink() Hans de Goede
` (3 subsequent siblings)
5 siblings, 0 replies; 15+ messages in thread
From: Hans de Goede @ 2023-04-12 21:58 UTC (permalink / raw)
To: Pavel Machek, Lee Jones; +Cc: Hans de Goede, Johannes Berg, linux-leds
When a trigger wants to switch from blinking to LED on it needs to call:
led_set_brightness(LED_OFF);
led_set_brightness(LED_FULL);
To first call disables blinking and the second then turns the LED on
(the power-supply charging-blink-full-solid triggers do this).
These calls happen immediately after each other, so it is possible
that set_brightness_delayed() from the first call has not run yet
when the led_set_brightness(LED_FULL) call finishes.
If this race hits then this is causing problems for both
sw- and hw-blinking:
For sw-blinking set_brightness_delayed() clears delayed_set_value
when LED_BLINK_DISABLE is set causing the led_set_brightness(LED_FULL)
call effects to get lost when hitting the race, resulting in the LED
turning off instead of on.
For hw-blinking if the race hits delayed_set_value has been
set to LED_FULL by the time set_brightness_delayed() runs.
So led_cdev->brightness_set_blocking() is never called with
LED_OFF as argument and the hw-blinking is never disabled leaving
the LED blinking instead of on.
Fix both issues by adding LED_SET_BRIGHTNESS and LED_SET_BRIGHTNESS_OFF
work_flags making this 2 separate actions to be run by
set_brightness_delayed().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/leds/led-core.c | 57 +++++++++++++++++++++++++++++++----------
include/linux/leds.h | 3 +++
2 files changed, 47 insertions(+), 13 deletions(-)
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index 4a97cb745788..e61acc785410 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -114,21 +114,14 @@ static void led_timer_function(struct timer_list *t)
mod_timer(&led_cdev->blink_timer, jiffies + msecs_to_jiffies(delay));
}
-static void set_brightness_delayed(struct work_struct *ws)
+static void set_brightness_delayed_set_brightness(struct led_classdev *led_cdev,
+ unsigned int value)
{
- struct led_classdev *led_cdev =
- container_of(ws, struct led_classdev, set_brightness_work);
int ret = 0;
- if (test_and_clear_bit(LED_BLINK_DISABLE, &led_cdev->work_flags)) {
- led_cdev->delayed_set_value = LED_OFF;
- led_stop_software_blink(led_cdev);
- }
-
- ret = __led_set_brightness(led_cdev, led_cdev->delayed_set_value);
+ ret = __led_set_brightness(led_cdev, value);
if (ret == -ENOTSUPP)
- ret = __led_set_brightness_blocking(led_cdev,
- led_cdev->delayed_set_value);
+ ret = __led_set_brightness_blocking(led_cdev, value);
if (ret < 0 &&
/* LED HW might have been unplugged, therefore don't warn */
!(ret == -ENODEV && (led_cdev->flags & LED_UNREGISTERING) &&
@@ -137,6 +130,30 @@ static void set_brightness_delayed(struct work_struct *ws)
"Setting an LED's brightness failed (%d)\n", ret);
}
+static void set_brightness_delayed(struct work_struct *ws)
+{
+ struct led_classdev *led_cdev =
+ container_of(ws, struct led_classdev, set_brightness_work);
+
+ if (test_and_clear_bit(LED_BLINK_DISABLE, &led_cdev->work_flags)) {
+ led_stop_software_blink(led_cdev);
+ set_bit(LED_SET_BRIGHTNESS_OFF, &led_cdev->work_flags);
+ }
+
+ /*
+ * Triggers may call led_set_brightness(LED_OFF),
+ * led_set_brightness(LED_FULL) in quick succession to disable blinking
+ * and turn the LED on. Both actions may have been scheduled to run
+ * before this work item runs once. To make sure this works properly
+ * handle LED_SET_BRIGHTNESS_OFF first.
+ */
+ if (test_and_clear_bit(LED_SET_BRIGHTNESS_OFF, &led_cdev->work_flags))
+ set_brightness_delayed_set_brightness(led_cdev, LED_OFF);
+
+ if (test_and_clear_bit(LED_SET_BRIGHTNESS, &led_cdev->work_flags))
+ set_brightness_delayed_set_brightness(led_cdev, led_cdev->delayed_set_value);
+}
+
static void led_set_software_blink(struct led_classdev *led_cdev,
unsigned long delay_on,
unsigned long delay_off)
@@ -271,8 +288,22 @@ void led_set_brightness_nopm(struct led_classdev *led_cdev, unsigned int value)
if (!__led_set_brightness(led_cdev, value))
return;
- /* If brightness setting can sleep, delegate it to a work queue task */
- led_cdev->delayed_set_value = value;
+ /*
+ * Brightness setting can sleep, delegate it to a work queue task.
+ * value 0 / LED_OFF is special, since it also disables hw-blinking
+ * (sw-blink disable is handled in led_set_brightness()).
+ * To avoid a hw-blink-disable getting lost when a second brightness
+ * change is done immediately afterwards (before the work runs),
+ * it uses a separate work_flag.
+ */
+ if (value) {
+ led_cdev->delayed_set_value = value;
+ set_bit(LED_SET_BRIGHTNESS, &led_cdev->work_flags);
+ } else {
+ clear_bit(LED_SET_BRIGHTNESS, &led_cdev->work_flags);
+ set_bit(LED_SET_BRIGHTNESS_OFF, &led_cdev->work_flags);
+ }
+
schedule_work(&led_cdev->set_brightness_work);
}
EXPORT_SYMBOL_GPL(led_set_brightness_nopm);
diff --git a/include/linux/leds.h b/include/linux/leds.h
index 6006786cafdc..eb68aea79c6d 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -116,6 +116,9 @@ struct led_classdev {
#define LED_BLINK_INVERT 3
#define LED_BLINK_BRIGHTNESS_CHANGE 4
#define LED_BLINK_DISABLE 5
+ /* Brightness off also disables hw-blinking so it is a separate action */
+#define LED_SET_BRIGHTNESS_OFF 6
+#define LED_SET_BRIGHTNESS 7
/* Set LED brightness level
* Must not sleep. Use brightness_set_blocking for drivers
--
2.39.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 3/4] leds: Fix oops about sleeping in led_trigger_blink()
2023-04-12 21:58 [PATCH 0/4] Fix oops about sleeping in led_trigger_blink() Hans de Goede
2023-04-12 21:58 ` [PATCH 1/4] leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-value Hans de Goede
2023-04-12 21:58 ` [PATCH 2/4] leds: Fix set_brightness_delayed() race Hans de Goede
@ 2023-04-12 21:58 ` Hans de Goede
2023-04-12 21:58 ` [PATCH 4/4] leds: Clear LED_INIT_DEFAULT_TRIGGER when clearing current trigger Hans de Goede
` (2 subsequent siblings)
5 siblings, 0 replies; 15+ messages in thread
From: Hans de Goede @ 2023-04-12 21:58 UTC (permalink / raw)
To: Pavel Machek, Lee Jones; +Cc: Hans de Goede, Johannes Berg, linux-leds
led_trigger_blink() calls led_blink_set() from a RCU read-side critical
section so led_blink_set() must not sleep. Note sleeping was not allowed
before the switch to RCU either because a spinlock was held before.
led_blink_set() does not sleep when sw-blinking is used, but
many LED controller drivers with hw blink support have a blink_set
function which may sleep, leading to an oops like this one:
[ 832.605062] ------------[ cut here ]------------
[ 832.605085] Voluntary context switch within RCU read-side critical section!
[ 832.605119] WARNING: CPU: 2 PID: 370 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x4ee/0x690
<snip>
[ 832.606453] Call Trace:
[ 832.606466] <TASK>
[ 832.606487] __schedule+0x9f/0x1480
[ 832.606527] schedule+0x5d/0xe0
[ 832.606549] schedule_timeout+0x79/0x140
[ 832.606572] ? __pfx_process_timeout+0x10/0x10
[ 832.606599] wait_for_completion_timeout+0x6f/0x140
[ 832.606627] i2c_dw_xfer+0x101/0x460
[ 832.606659] ? psi_group_change+0x168/0x400
[ 832.606680] __i2c_transfer+0x172/0x6d0
[ 832.606709] i2c_smbus_xfer_emulated+0x27d/0x9c0
[ 832.606732] ? __schedule+0x430/0x1480
[ 832.606753] ? preempt_count_add+0x6a/0xa0
[ 832.606778] ? get_nohz_timer_target+0x18/0x190
[ 832.606796] ? lock_timer_base+0x61/0x80
[ 832.606817] ? preempt_count_add+0x6a/0xa0
[ 832.606842] __i2c_smbus_xfer+0xa2/0x3f0
[ 832.606862] i2c_smbus_xfer+0x66/0xf0
[ 832.606882] i2c_smbus_read_byte_data+0x41/0x70
[ 832.606901] ? _raw_spin_unlock_irqrestore+0x23/0x40
[ 832.606922] ? __pm_runtime_suspend+0x46/0xc0
[ 832.606946] cht_wc_byte_reg_read+0x2e/0x60
[ 832.606972] _regmap_read+0x5c/0x120
[ 832.606997] _regmap_update_bits+0x96/0xc0
[ 832.607023] regmap_update_bits_base+0x5b/0x90
[ 832.607053] cht_wc_leds_brightness_get+0x412/0x910 [leds_cht_wcove]
[ 832.607094] led_blink_setup+0x28/0x100
[ 832.607119] led_trigger_blink+0x40/0x70
[ 832.607145] power_supply_update_leds+0x1b7/0x1c0
[ 832.607174] power_supply_changed_work+0x67/0xe0
[ 832.607198] process_one_work+0x1c8/0x3c0
[ 832.607222] worker_thread+0x4d/0x380
[ 832.607243] ? __pfx_worker_thread+0x10/0x10
[ 832.607258] kthread+0xe9/0x110
[ 832.607279] ? __pfx_kthread+0x10/0x10
[ 832.607300] ret_from_fork+0x2c/0x50
[ 832.607337] </TASK>
[ 832.607344] ---[ end trace 0000000000000000 ]---
Add a new led_blink_set_nosleep() function which defers the actual
led_blink_set() call to a workqueue when necessary to fix this.
This also fixes an existing race where a pending led_set_brightness() has
been deferred to set_brightness_work and might then race with a later
led_cdev->blink_set() call. Note this race is only an issue with triggers
mixing led_trigger_event() and led_trigger_blink() calls, sysfs API
calls and led_trigger_blink_oneshot() are not affected.
Note rather then adding a separate blink_set_blocking callback this uses
the presence of the already existing brightness_set_blocking callback to
detect if the blinking call should be deferred to set_brightness_work.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/leds/led-core.c | 24 ++++++++++++++++++++++++
drivers/leds/led-triggers.c | 2 +-
include/linux/leds.h | 24 ++++++++++++++++++++++++
3 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/leds/led-core.c b/drivers/leds/led-core.c
index e61acc785410..b9b1295833c9 100644
--- a/drivers/leds/led-core.c
+++ b/drivers/leds/led-core.c
@@ -152,6 +152,13 @@ static void set_brightness_delayed(struct work_struct *ws)
if (test_and_clear_bit(LED_SET_BRIGHTNESS, &led_cdev->work_flags))
set_brightness_delayed_set_brightness(led_cdev, led_cdev->delayed_set_value);
+
+ if (test_and_clear_bit(LED_SET_BLINK, &led_cdev->work_flags)) {
+ unsigned long delay_on = led_cdev->delayed_delay_on;
+ unsigned long delay_off = led_cdev->delayed_delay_off;
+
+ led_blink_set(led_cdev, &delay_on, &delay_off);
+ }
}
static void led_set_software_blink(struct led_classdev *led_cdev,
@@ -246,6 +253,22 @@ void led_blink_set_oneshot(struct led_classdev *led_cdev,
}
EXPORT_SYMBOL_GPL(led_blink_set_oneshot);
+void led_blink_set_nosleep(struct led_classdev *led_cdev, unsigned long delay_on,
+ unsigned long delay_off)
+{
+ /* If necessary delegate to a work queue task. */
+ if (led_cdev->blink_set && led_cdev->brightness_set_blocking) {
+ led_cdev->delayed_delay_on = delay_on;
+ led_cdev->delayed_delay_off = delay_off;
+ set_bit(LED_SET_BLINK, &led_cdev->work_flags);
+ schedule_work(&led_cdev->set_brightness_work);
+ return;
+ }
+
+ led_blink_set(led_cdev, &delay_on, &delay_off);
+}
+EXPORT_SYMBOL_GPL(led_blink_set_nosleep);
+
void led_stop_software_blink(struct led_classdev *led_cdev)
{
del_timer_sync(&led_cdev->blink_timer);
@@ -301,6 +324,7 @@ void led_set_brightness_nopm(struct led_classdev *led_cdev, unsigned int value)
set_bit(LED_SET_BRIGHTNESS, &led_cdev->work_flags);
} else {
clear_bit(LED_SET_BRIGHTNESS, &led_cdev->work_flags);
+ clear_bit(LED_SET_BLINK, &led_cdev->work_flags);
set_bit(LED_SET_BRIGHTNESS_OFF, &led_cdev->work_flags);
}
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index e06361165e9b..8214d3f7bc5f 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -409,7 +409,7 @@ static void led_trigger_blink_setup(struct led_trigger *trig,
led_blink_set_oneshot(led_cdev, &delay_on, &delay_off,
invert);
else
- led_blink_set(led_cdev, &delay_on, &delay_off);
+ led_blink_set_nosleep(led_cdev, delay_on, delay_off);
}
rcu_read_unlock();
}
diff --git a/include/linux/leds.h b/include/linux/leds.h
index eb68aea79c6d..3c93dec3f4e2 100644
--- a/include/linux/leds.h
+++ b/include/linux/leds.h
@@ -119,6 +119,7 @@ struct led_classdev {
/* Brightness off also disables hw-blinking so it is a separate action */
#define LED_SET_BRIGHTNESS_OFF 6
#define LED_SET_BRIGHTNESS 7
+#define LED_SET_BLINK 8
/* Set LED brightness level
* Must not sleep. Use brightness_set_blocking for drivers
@@ -142,6 +143,10 @@ struct led_classdev {
* match the values specified exactly.
* Deactivate blinking again when the brightness is set to LED_OFF
* via the brightness_set() callback.
+ * For led_blink_set_nosleep() the LED core assumes that blink_set
+ * implementations, of drivers which do not use brightness_set_blocking,
+ * will not sleep. Therefor if brightness_set_blocking is not set
+ * this function must not sleep!
*/
int (*blink_set)(struct led_classdev *led_cdev,
unsigned long *delay_on,
@@ -165,6 +170,8 @@ struct led_classdev {
struct work_struct set_brightness_work;
int delayed_set_value;
+ unsigned long delayed_delay_on;
+ unsigned long delayed_delay_off;
#ifdef CONFIG_LEDS_TRIGGERS
/* Protects the trigger data below */
@@ -257,12 +264,27 @@ struct led_classdev *__must_check devm_of_led_get(struct device *dev,
* software blinking if there is no hardware blinking or if
* the LED refuses the passed values.
*
+ * This function may sleep!
+ *
* Note that if software blinking is active, simply calling
* led_cdev->brightness_set() will not stop the blinking,
* use led_classdev_brightness_set() instead.
*/
void led_blink_set(struct led_classdev *led_cdev, unsigned long *delay_on,
unsigned long *delay_off);
+
+/**
+ * led_blink_set_nosleep - set blinking, guaranteed to not sleep
+ * @led_cdev: the LED to start blinking
+ * @delay_on: the time it should be on (in ms)
+ * @delay_off: the time it should ble off (in ms)
+ *
+ * This function makes the LED blink and is guaranteed to not sleep. Otherwise
+ * this is the same as led_blink_set(), see led_blink_set() for details.
+ */
+void led_blink_set_nosleep(struct led_classdev *led_cdev, unsigned long delay_on,
+ unsigned long delay_off);
+
/**
* led_blink_set_oneshot - do a oneshot software blink
* @led_cdev: the LED to start blinking
@@ -276,6 +298,8 @@ void led_blink_set(struct led_classdev *led_cdev, unsigned long *delay_on,
*
* If invert is set, led blinks for delay_off first, then for
* delay_on and leave the led on after the on-off cycle.
+ *
+ * This function is guaranteed not to sleep.
*/
void led_blink_set_oneshot(struct led_classdev *led_cdev,
unsigned long *delay_on, unsigned long *delay_off,
--
2.39.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH 4/4] leds: Clear LED_INIT_DEFAULT_TRIGGER when clearing current trigger
2023-04-12 21:58 [PATCH 0/4] Fix oops about sleeping in led_trigger_blink() Hans de Goede
` (2 preceding siblings ...)
2023-04-12 21:58 ` [PATCH 3/4] leds: Fix oops about sleeping in led_trigger_blink() Hans de Goede
@ 2023-04-12 21:58 ` Hans de Goede
2023-04-16 15:36 ` [PATCH 0/4] Fix oops about sleeping in led_trigger_blink() Jacek Anaszewski
2023-04-20 11:36 ` Lee Jones
5 siblings, 0 replies; 15+ messages in thread
From: Hans de Goede @ 2023-04-12 21:58 UTC (permalink / raw)
To: Pavel Machek, Lee Jones; +Cc: Hans de Goede, Johannes Berg, linux-leds
Not all triggers use LED_INIT_DEFAULT_TRIGGER, which means that it
will not get cleared when the default trigger is a trigger which
does not use it such as "default-on".
If the default trigger then later gets replaced by a trigger which
does check LED_INIT_DEFAULT_TRIGGER, such as "timer" then that trigger
will behave as if it is the default trigger which it should not do.
To fix this clear the LED_INIT_DEFAULT_TRIGGER flag when clearing
the current trigger, so that it will not be set for any subsequently
set (non default) triggers.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/leds/led-triggers.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
index 8214d3f7bc5f..6a5e1f41f9a4 100644
--- a/drivers/leds/led-triggers.c
+++ b/drivers/leds/led-triggers.c
@@ -185,6 +185,7 @@ int led_trigger_set(struct led_classdev *led_cdev, struct led_trigger *trig)
led_cdev->trigger = NULL;
led_cdev->trigger_data = NULL;
led_cdev->activated = false;
+ led_cdev->flags &= ~LED_INIT_DEFAULT_TRIGGER;
led_set_brightness(led_cdev, LED_OFF);
}
if (trig) {
--
2.39.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH 0/4] Fix oops about sleeping in led_trigger_blink()
2023-04-12 21:58 [PATCH 0/4] Fix oops about sleeping in led_trigger_blink() Hans de Goede
` (3 preceding siblings ...)
2023-04-12 21:58 ` [PATCH 4/4] leds: Clear LED_INIT_DEFAULT_TRIGGER when clearing current trigger Hans de Goede
@ 2023-04-16 15:36 ` Jacek Anaszewski
2023-04-20 11:36 ` Lee Jones
5 siblings, 0 replies; 15+ messages in thread
From: Jacek Anaszewski @ 2023-04-16 15:36 UTC (permalink / raw)
To: Hans de Goede, Pavel Machek, Lee Jones; +Cc: Johannes Berg, linux-leds
Hi Hans,
Generally the series looks good to me, but it would be good
to get some Tested-by(s).
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
On 4/12/23 23:58, Hans de Goede wrote:
> Hi All,
>
> Here is a patch series to fix an oops about sleeping in led_trigger_blink()
> + one other small bugfix.
>
> Patches 1-3 should arguably have a:
>
> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
>
> tag, but Fixes tags tend to lead to patches getting automatically added
> to the stable series and I would prefer to see this series get some
> significant testing time in mainline first, so I have chosen to omit
> the tag.
>
> Regards,
>
> Hans
>
>
> Hans de Goede (4):
> leds: Change led_trigger_blink[_oneshot]() delay parameters to
> pass-by-value
> leds: Fix set_brightness_delayed() race
> leds: Fix oops about sleeping in led_trigger_blink()
> leds: Clear LED_INIT_DEFAULT_TRIGGER when clearing current trigger
>
> drivers/leds/led-core.c | 81 ++++++++++++++++++++----
> drivers/leds/led-triggers.c | 17 ++---
> drivers/leds/trigger/ledtrig-disk.c | 9 +--
> drivers/leds/trigger/ledtrig-mtd.c | 8 +--
> drivers/net/arcnet/arcnet.c | 8 +--
> drivers/power/supply/power_supply_leds.c | 5 +-
> drivers/usb/common/led.c | 4 +-
> include/linux/leds.h | 43 ++++++++++---
> net/mac80211/led.c | 2 +-
> net/mac80211/led.h | 8 +--
> net/netfilter/xt_LED.c | 3 +-
> 11 files changed, 125 insertions(+), 63 deletions(-)
>
--
Best regards,
Jacek Anaszewski
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 0/4] Fix oops about sleeping in led_trigger_blink()
2023-04-12 21:58 [PATCH 0/4] Fix oops about sleeping in led_trigger_blink() Hans de Goede
` (4 preceding siblings ...)
2023-04-16 15:36 ` [PATCH 0/4] Fix oops about sleeping in led_trigger_blink() Jacek Anaszewski
@ 2023-04-20 11:36 ` Lee Jones
2023-04-20 12:04 ` Hans de Goede
5 siblings, 1 reply; 15+ messages in thread
From: Lee Jones @ 2023-04-20 11:36 UTC (permalink / raw)
To: Hans de Goede; +Cc: Pavel Machek, Johannes Berg, linux-leds
On Wed, 12 Apr 2023, Hans de Goede wrote:
> Hi All,
>
> Here is a patch series to fix an oops about sleeping in led_trigger_blink()
> + one other small bugfix.
>
> Patches 1-3 should arguably have a:
>
> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
>
> tag, but Fixes tags tend to lead to patches getting automatically added
> to the stable series and I would prefer to see this series get some
> significant testing time in mainline first, so I have chosen to omit
> the tag.
With subjects with the word "fix" in it, they will be hoovered up by the
Stable auto-picker anyway.
> Hans de Goede (4):
> leds: Change led_trigger_blink[_oneshot]() delay parameters to
> pass-by-value
> leds: Fix set_brightness_delayed() race
> leds: Fix oops about sleeping in led_trigger_blink()
> leds: Clear LED_INIT_DEFAULT_TRIGGER when clearing current trigger
>
> drivers/leds/led-core.c | 81 ++++++++++++++++++++----
> drivers/leds/led-triggers.c | 17 ++---
> drivers/leds/trigger/ledtrig-disk.c | 9 +--
> drivers/leds/trigger/ledtrig-mtd.c | 8 +--
> drivers/net/arcnet/arcnet.c | 8 +--
> drivers/power/supply/power_supply_leds.c | 5 +-
> drivers/usb/common/led.c | 4 +-
> include/linux/leds.h | 43 ++++++++++---
> net/mac80211/led.c | 2 +-
> net/mac80211/led.h | 8 +--
> net/netfilter/xt_LED.c | 3 +-
> 11 files changed, 125 insertions(+), 63 deletions(-)
>
> --
> 2.39.1
>
--
Lee Jones [李琼斯]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 0/4] Fix oops about sleeping in led_trigger_blink()
2023-04-20 11:36 ` Lee Jones
@ 2023-04-20 12:04 ` Hans de Goede
2023-04-20 13:56 ` Lee Jones
0 siblings, 1 reply; 15+ messages in thread
From: Hans de Goede @ 2023-04-20 12:04 UTC (permalink / raw)
To: Lee Jones; +Cc: Pavel Machek, Johannes Berg, linux-leds
Hi Lee,
On 4/20/23 13:36, Lee Jones wrote:
> On Wed, 12 Apr 2023, Hans de Goede wrote:
>
>> Hi All,
>>
>> Here is a patch series to fix an oops about sleeping in led_trigger_blink()
>> + one other small bugfix.
>>
>> Patches 1-3 should arguably have a:
>>
>> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
>>
>> tag, but Fixes tags tend to lead to patches getting automatically added
>> to the stable series and I would prefer to see this series get some
>> significant testing time in mainline first, so I have chosen to omit
>> the tag.
>
> With subjects with the word "fix" in it, they will be hoovered up by the
> Stable auto-picker anyway.
Ok, in that case patch 3 should have:
Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
Patches 1-2 are more preparation patches for this. Patch 2 does
fix another race, but I'm not sure we ever hit that.
Can you add the fixes tag while merging these, or do you
want a v2 of this series ?
Regards,
Hans
>
>> Hans de Goede (4):
>> leds: Change led_trigger_blink[_oneshot]() delay parameters to
>> pass-by-value
>> leds: Fix set_brightness_delayed() race
>> leds: Fix oops about sleeping in led_trigger_blink()
>> leds: Clear LED_INIT_DEFAULT_TRIGGER when clearing current trigger
>>
>> drivers/leds/led-core.c | 81 ++++++++++++++++++++----
>> drivers/leds/led-triggers.c | 17 ++---
>> drivers/leds/trigger/ledtrig-disk.c | 9 +--
>> drivers/leds/trigger/ledtrig-mtd.c | 8 +--
>> drivers/net/arcnet/arcnet.c | 8 +--
>> drivers/power/supply/power_supply_leds.c | 5 +-
>> drivers/usb/common/led.c | 4 +-
>> include/linux/leds.h | 43 ++++++++++---
>> net/mac80211/led.c | 2 +-
>> net/mac80211/led.h | 8 +--
>> net/netfilter/xt_LED.c | 3 +-
>> 11 files changed, 125 insertions(+), 63 deletions(-)
>>
>> --
>> 2.39.1
>>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 0/4] Fix oops about sleeping in led_trigger_blink()
2023-04-20 12:04 ` Hans de Goede
@ 2023-04-20 13:56 ` Lee Jones
2023-04-25 14:03 ` Hans de Goede
0 siblings, 1 reply; 15+ messages in thread
From: Lee Jones @ 2023-04-20 13:56 UTC (permalink / raw)
To: Hans de Goede; +Cc: Pavel Machek, Johannes Berg, linux-leds
On Thu, 20 Apr 2023, Hans de Goede wrote:
> Hi Lee,
>
> On 4/20/23 13:36, Lee Jones wrote:
> > On Wed, 12 Apr 2023, Hans de Goede wrote:
> >
> >> Hi All,
> >>
> >> Here is a patch series to fix an oops about sleeping in led_trigger_blink()
> >> + one other small bugfix.
> >>
> >> Patches 1-3 should arguably have a:
> >>
> >> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
> >>
> >> tag, but Fixes tags tend to lead to patches getting automatically added
> >> to the stable series and I would prefer to see this series get some
> >> significant testing time in mainline first, so I have chosen to omit
> >> the tag.
> >
> > With subjects with the word "fix" in it, they will be hoovered up by the
> > Stable auto-picker anyway.
>
> Ok, in that case patch 3 should have:
>
> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
>
> Patches 1-2 are more preparation patches for this. Patch 2 does
> fix another race, but I'm not sure we ever hit that.
>
> Can you add the fixes tag while merging these, or do you
> want a v2 of this series ?
I'm holding out for either a Pavel review or some Tested-by's suggested
by Jacek.
--
Lee Jones [李琼斯]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 0/4] Fix oops about sleeping in led_trigger_blink()
2023-04-20 13:56 ` Lee Jones
@ 2023-04-25 14:03 ` Hans de Goede
2023-04-26 14:34 ` Lee Jones
0 siblings, 1 reply; 15+ messages in thread
From: Hans de Goede @ 2023-04-25 14:03 UTC (permalink / raw)
To: Lee Jones; +Cc: Pavel Machek, Johannes Berg, linux-leds, Yauhen Kharuzhy
Hi Lee,
On 4/20/23 15:56, Lee Jones wrote:
> On Thu, 20 Apr 2023, Hans de Goede wrote:
>
>> Hi Lee,
>>
>> On 4/20/23 13:36, Lee Jones wrote:
>>> On Wed, 12 Apr 2023, Hans de Goede wrote:
>>>
>>>> Hi All,
>>>>
>>>> Here is a patch series to fix an oops about sleeping in led_trigger_blink()
>>>> + one other small bugfix.
>>>>
>>>> Patches 1-3 should arguably have a:
>>>>
>>>> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
>>>>
>>>> tag, but Fixes tags tend to lead to patches getting automatically added
>>>> to the stable series and I would prefer to see this series get some
>>>> significant testing time in mainline first, so I have chosen to omit
>>>> the tag.
>>>
>>> With subjects with the word "fix" in it, they will be hoovered up by the
>>> Stable auto-picker anyway.
>>
>> Ok, in that case patch 3 should have:
>>
>> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
>>
>> Patches 1-2 are more preparation patches for this. Patch 2 does
>> fix another race, but I'm not sure we ever hit that.
>>
>> Can you add the fixes tag while merging these, or do you
>> want a v2 of this series ?
>
> I'm holding out for either a Pavel review or some Tested-by's suggested
> by Jacek.
Hmm, ok. I have asked Yauhen to give this a test since they have hit
the oops/backtrace fixed by path 3/4 while testing the new leds-cht-wcove
driver too.
But Yauhen has the same hw as me (I have already tested this on
3 different laptop models).
Note that Jacek did already give his Reviewed-by:
Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
I think the bug this fixes was never an issue before because only
very few triggers use regular blinking (rather then one-shot
blinking which always uses the sw-blink implementation).
To hit this you need to use one of the few triggers which
actually use regular-blinking in combination with a
driver which supports hw-blinking and where its blink_set
callbavck may sleep. It looks to me like no-one has hit
this combination before. Which is why there are no bug reports
for the issue and which also is why finding testers is going
to be tricky.
I think that the best thing to do here is add this series to -next
early in the upcoming cycle, so that it gets the maximum testing
time possible in -next.
Regards,
Hans
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 0/4] Fix oops about sleeping in led_trigger_blink()
2023-04-25 14:03 ` Hans de Goede
@ 2023-04-26 14:34 ` Lee Jones
2023-05-04 13:08 ` Yauhen Kharuzhy
2023-05-09 8:58 ` Hans de Goede
0 siblings, 2 replies; 15+ messages in thread
From: Lee Jones @ 2023-04-26 14:34 UTC (permalink / raw)
To: Hans de Goede; +Cc: Pavel Machek, Johannes Berg, linux-leds, Yauhen Kharuzhy
On Tue, 25 Apr 2023, Hans de Goede wrote:
> Hi Lee,
>
> On 4/20/23 15:56, Lee Jones wrote:
> > On Thu, 20 Apr 2023, Hans de Goede wrote:
> >
> >> Hi Lee,
> >>
> >> On 4/20/23 13:36, Lee Jones wrote:
> >>> On Wed, 12 Apr 2023, Hans de Goede wrote:
> >>>
> >>>> Hi All,
> >>>>
> >>>> Here is a patch series to fix an oops about sleeping in led_trigger_blink()
> >>>> + one other small bugfix.
> >>>>
> >>>> Patches 1-3 should arguably have a:
> >>>>
> >>>> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
> >>>>
> >>>> tag, but Fixes tags tend to lead to patches getting automatically added
> >>>> to the stable series and I would prefer to see this series get some
> >>>> significant testing time in mainline first, so I have chosen to omit
> >>>> the tag.
> >>>
> >>> With subjects with the word "fix" in it, they will be hoovered up by the
> >>> Stable auto-picker anyway.
> >>
> >> Ok, in that case patch 3 should have:
> >>
> >> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
> >>
> >> Patches 1-2 are more preparation patches for this. Patch 2 does
> >> fix another race, but I'm not sure we ever hit that.
> >>
> >> Can you add the fixes tag while merging these, or do you
> >> want a v2 of this series ?
> >
> > I'm holding out for either a Pavel review or some Tested-by's suggested
> > by Jacek.
>
> Hmm, ok. I have asked Yauhen to give this a test since they have hit
> the oops/backtrace fixed by path 3/4 while testing the new leds-cht-wcove
> driver too.
>
> But Yauhen has the same hw as me (I have already tested this on
> 3 different laptop models).
>
> Note that Jacek did already give his Reviewed-by:
>
> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
>
> I think the bug this fixes was never an issue before because only
> very few triggers use regular blinking (rather then one-shot
> blinking which always uses the sw-blink implementation).
>
> To hit this you need to use one of the few triggers which
> actually use regular-blinking in combination with a
> driver which supports hw-blinking and where its blink_set
> callbavck may sleep. It looks to me like no-one has hit
> this combination before. Which is why there are no bug reports
> for the issue and which also is why finding testers is going
> to be tricky.
>
> I think that the best thing to do here is add this series to -next
> early in the upcoming cycle, so that it gets the maximum testing
> time possible in -next.
Agree. Let's revisit this once the merge-window closes.
--
Lee Jones [李琼斯]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 0/4] Fix oops about sleeping in led_trigger_blink()
2023-04-26 14:34 ` Lee Jones
@ 2023-05-04 13:08 ` Yauhen Kharuzhy
2023-05-09 8:58 ` Hans de Goede
1 sibling, 0 replies; 15+ messages in thread
From: Yauhen Kharuzhy @ 2023-05-04 13:08 UTC (permalink / raw)
To: Lee Jones; +Cc: Hans de Goede, Pavel Machek, Johannes Berg, linux-leds
On Wed, Apr 26, 2023 at 03:34:39PM +0100, Lee Jones wrote:
> On Tue, 25 Apr 2023, Hans de Goede wrote:
>
> > Hi Lee,
> >
> > On 4/20/23 15:56, Lee Jones wrote:
> > > On Thu, 20 Apr 2023, Hans de Goede wrote:
> > >
> > >> Hi Lee,
> > >>
> > >> On 4/20/23 13:36, Lee Jones wrote:
> > >>> On Wed, 12 Apr 2023, Hans de Goede wrote:
> > >>>
> > >>>> Hi All,
> > >>>>
> > >>>> Here is a patch series to fix an oops about sleeping in led_trigger_blink()
> > >>>> + one other small bugfix.
> > >>>>
> > >>>> Patches 1-3 should arguably have a:
> > >>>>
> > >>>> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
> > >>>>
> > >>>> tag, but Fixes tags tend to lead to patches getting automatically added
> > >>>> to the stable series and I would prefer to see this series get some
> > >>>> significant testing time in mainline first, so I have chosen to omit
> > >>>> the tag.
> > >>>
> > >>> With subjects with the word "fix" in it, they will be hoovered up by the
> > >>> Stable auto-picker anyway.
> > >>
> > >> Ok, in that case patch 3 should have:
> > >>
> > >> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
> > >>
> > >> Patches 1-2 are more preparation patches for this. Patch 2 does
> > >> fix another race, but I'm not sure we ever hit that.
> > >>
> > >> Can you add the fixes tag while merging these, or do you
> > >> want a v2 of this series ?
> > >
> > > I'm holding out for either a Pavel review or some Tested-by's suggested
> > > by Jacek.
> >
> > Hmm, ok. I have asked Yauhen to give this a test since they have hit
> > the oops/backtrace fixed by path 3/4 while testing the new leds-cht-wcove
> > driver too.
> >
> > But Yauhen has the same hw as me (I have already tested this on
> > 3 different laptop models).
> >
> > Note that Jacek did already give his Reviewed-by:
> >
> > Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
> >
> > I think the bug this fixes was never an issue before because only
> > very few triggers use regular blinking (rather then one-shot
> > blinking which always uses the sw-blink implementation).
> >
> > To hit this you need to use one of the few triggers which
> > actually use regular-blinking in combination with a
> > driver which supports hw-blinking and where its blink_set
> > callbavck may sleep. It looks to me like no-one has hit
> > this combination before. Which is why there are no bug reports
> > for the issue and which also is why finding testers is going
> > to be tricky.
> >
> > I think that the best thing to do here is add this series to -next
> > early in the upcoming cycle, so that it gets the maximum testing
> > time possible in -next.
>
> Agree. Let's revisit this once the merge-window closes.
Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
For entire series.
--
Yauhen Kharuzhy
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 0/4] Fix oops about sleeping in led_trigger_blink()
2023-04-26 14:34 ` Lee Jones
2023-05-04 13:08 ` Yauhen Kharuzhy
@ 2023-05-09 8:58 ` Hans de Goede
1 sibling, 0 replies; 15+ messages in thread
From: Hans de Goede @ 2023-05-09 8:58 UTC (permalink / raw)
To: Lee Jones; +Cc: Pavel Machek, Johannes Berg, linux-leds, Yauhen Kharuzhy
Hi Lee,
On 4/26/23 16:34, Lee Jones wrote:
> On Tue, 25 Apr 2023, Hans de Goede wrote:
>
>> Hi Lee,
>>
>> On 4/20/23 15:56, Lee Jones wrote:
>>> On Thu, 20 Apr 2023, Hans de Goede wrote:
>>>
>>>> Hi Lee,
>>>>
>>>> On 4/20/23 13:36, Lee Jones wrote:
>>>>> On Wed, 12 Apr 2023, Hans de Goede wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Here is a patch series to fix an oops about sleeping in led_trigger_blink()
>>>>>> + one other small bugfix.
>>>>>>
>>>>>> Patches 1-3 should arguably have a:
>>>>>>
>>>>>> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
>>>>>>
>>>>>> tag, but Fixes tags tend to lead to patches getting automatically added
>>>>>> to the stable series and I would prefer to see this series get some
>>>>>> significant testing time in mainline first, so I have chosen to omit
>>>>>> the tag.
>>>>>
>>>>> With subjects with the word "fix" in it, they will be hoovered up by the
>>>>> Stable auto-picker anyway.
>>>>
>>>> Ok, in that case patch 3 should have:
>>>>
>>>> Fixes: 0b9536c95709 ("leds: Add ability to blink via simple trigger")
>>>>
>>>> Patches 1-2 are more preparation patches for this. Patch 2 does
>>>> fix another race, but I'm not sure we ever hit that.
>>>>
>>>> Can you add the fixes tag while merging these, or do you
>>>> want a v2 of this series ?
>>>
>>> I'm holding out for either a Pavel review or some Tested-by's suggested
>>> by Jacek.
>>
>> Hmm, ok. I have asked Yauhen to give this a test since they have hit
>> the oops/backtrace fixed by path 3/4 while testing the new leds-cht-wcove
>> driver too.
>>
>> But Yauhen has the same hw as me (I have already tested this on
>> 3 different laptop models).
>>
>> Note that Jacek did already give his Reviewed-by:
>>
>> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
>>
>> I think the bug this fixes was never an issue before because only
>> very few triggers use regular blinking (rather then one-shot
>> blinking which always uses the sw-blink implementation).
>>
>> To hit this you need to use one of the few triggers which
>> actually use regular-blinking in combination with a
>> driver which supports hw-blinking and where its blink_set
>> callbavck may sleep. It looks to me like no-one has hit
>> this combination before. Which is why there are no bug reports
>> for the issue and which also is why finding testers is going
>> to be tricky.
>>
>> I think that the best thing to do here is add this series to -next
>> early in the upcoming cycle, so that it gets the maximum testing
>> time possible in -next.
>
> Agree. Let's revisit this once the merge-window closes.
The merge-window has closed now, and Yauhen has given their tested-by:
Tested-by: Yauhen Kharuzhy <jekhor@gmail.com>
Lee, can you merge this now please so that this gets the maximum
possible time for testing in linux-next ?
Regards,
Hans
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/4] leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-value
2023-04-12 21:58 ` [PATCH 1/4] leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-value Hans de Goede
@ 2023-05-10 11:57 ` Lee Jones
2023-05-10 15:32 ` Hans de Goede
0 siblings, 1 reply; 15+ messages in thread
From: Lee Jones @ 2023-05-10 11:57 UTC (permalink / raw)
To: Hans de Goede; +Cc: Pavel Machek, Johannes Berg, linux-leds
On Wed, 12 Apr 2023, Hans de Goede wrote:
> led_blink_set[_oneshot]()'s delay_on and delay_off function parameters
> are pass by reference, so that hw-blink implementations can report
> back the actual achieved delays when the values have been rounded
> to something the hw supports.
>
> This is really only interesting for the sysfs API / the timer trigger.
> Other triggers don't really care about this and none of the callers of
> led_trigger_blink[_oneshot]() do anything with the returned delay values.
>
> Change the led_trigger_blink[_oneshot]() delay parameters to pass-by-value,
> there are 2 reasons for this:
>
> 1. led_cdev->blink_set() may sleep, while led_trigger_blink() may not.
> So on hw where led_cdev->blink_set() sleeps the call needs to be deferred
> to a workqueue, in which case the actual achieved delays are unknown
> (this is a preparation patch for the deferring).
>
> 2. Since the callers don't care about the actual achieved delays, allowing
> callers to directly pass a value leads to simpler code for most callers.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/leds/led-triggers.c | 16 ++++++++--------
> drivers/leds/trigger/ledtrig-disk.c | 9 +++------
> drivers/leds/trigger/ledtrig-mtd.c | 8 ++------
> drivers/net/arcnet/arcnet.c | 8 ++------
> drivers/power/supply/power_supply_leds.c | 5 +----
> drivers/usb/common/led.c | 4 +---
> include/linux/leds.h | 16 ++++++++--------
> net/mac80211/led.c | 2 +-
> net/mac80211/led.h | 8 ++------
> net/netfilter/xt_LED.c | 3 +--
> 10 files changed, 29 insertions(+), 50 deletions(-)
Just came to apply this and realised that you have touched other
subsystems without Cc'ing the appropriate maintainers.
Please can you [RESEND] this set and include them please?
--
Lee Jones [李琼斯]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH 1/4] leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-value
2023-05-10 11:57 ` Lee Jones
@ 2023-05-10 15:32 ` Hans de Goede
0 siblings, 0 replies; 15+ messages in thread
From: Hans de Goede @ 2023-05-10 15:32 UTC (permalink / raw)
To: Lee Jones; +Cc: Pavel Machek, Johannes Berg, linux-leds
Hi,
On 5/10/23 13:57, Lee Jones wrote:
> On Wed, 12 Apr 2023, Hans de Goede wrote:
>
>> led_blink_set[_oneshot]()'s delay_on and delay_off function parameters
>> are pass by reference, so that hw-blink implementations can report
>> back the actual achieved delays when the values have been rounded
>> to something the hw supports.
>>
>> This is really only interesting for the sysfs API / the timer trigger.
>> Other triggers don't really care about this and none of the callers of
>> led_trigger_blink[_oneshot]() do anything with the returned delay values.
>>
>> Change the led_trigger_blink[_oneshot]() delay parameters to pass-by-value,
>> there are 2 reasons for this:
>>
>> 1. led_cdev->blink_set() may sleep, while led_trigger_blink() may not.
>> So on hw where led_cdev->blink_set() sleeps the call needs to be deferred
>> to a workqueue, in which case the actual achieved delays are unknown
>> (this is a preparation patch for the deferring).
>>
>> 2. Since the callers don't care about the actual achieved delays, allowing
>> callers to directly pass a value leads to simpler code for most callers.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/leds/led-triggers.c | 16 ++++++++--------
>> drivers/leds/trigger/ledtrig-disk.c | 9 +++------
>> drivers/leds/trigger/ledtrig-mtd.c | 8 ++------
>> drivers/net/arcnet/arcnet.c | 8 ++------
>> drivers/power/supply/power_supply_leds.c | 5 +----
>> drivers/usb/common/led.c | 4 +---
>> include/linux/leds.h | 16 ++++++++--------
>> net/mac80211/led.c | 2 +-
>> net/mac80211/led.h | 8 ++------
>> net/netfilter/xt_LED.c | 3 +--
>> 10 files changed, 29 insertions(+), 50 deletions(-)
>
> Just came to apply this and realised that you have touched other
> subsystems without Cc'ing the appropriate maintainers.
Good point, sorry about that.
> Please can you [RESEND] this set and include them please?
Ack, I'm rebasing them on 6.4-rc1, checking no new
users of led_trigger_blink() / led_trigger_blink_oneshot()
(which this set changes the prototype of) have shown up
and then I'll do a resend.
(if I have to make any changes other then the plain rebase
I'll make it a version 2 set instead.)
Regards,
Hans
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2023-05-10 15:33 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-12 21:58 [PATCH 0/4] Fix oops about sleeping in led_trigger_blink() Hans de Goede
2023-04-12 21:58 ` [PATCH 1/4] leds: Change led_trigger_blink[_oneshot]() delay parameters to pass-by-value Hans de Goede
2023-05-10 11:57 ` Lee Jones
2023-05-10 15:32 ` Hans de Goede
2023-04-12 21:58 ` [PATCH 2/4] leds: Fix set_brightness_delayed() race Hans de Goede
2023-04-12 21:58 ` [PATCH 3/4] leds: Fix oops about sleeping in led_trigger_blink() Hans de Goede
2023-04-12 21:58 ` [PATCH 4/4] leds: Clear LED_INIT_DEFAULT_TRIGGER when clearing current trigger Hans de Goede
2023-04-16 15:36 ` [PATCH 0/4] Fix oops about sleeping in led_trigger_blink() Jacek Anaszewski
2023-04-20 11:36 ` Lee Jones
2023-04-20 12:04 ` Hans de Goede
2023-04-20 13:56 ` Lee Jones
2023-04-25 14:03 ` Hans de Goede
2023-04-26 14:34 ` Lee Jones
2023-05-04 13:08 ` Yauhen Kharuzhy
2023-05-09 8:58 ` Hans de Goede
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).