Hello everyone. This is my first patch to linux kernel. Once I get the
hang of this process, I will be sending patches form GSoC 2023 greybus
driver. Feel free to tell me if I am doing something wrong here
Ayush Singh (1):
Remove extra newline
drivers/greybus/es2.c | 1 -
1 file changed, 1 deletion(-)
--
2.41.0
A few ALSA control API helpers like snd_ctl_rename(), snd_ctl_remove()
and snd_ctl_find_*() suppose the callers taking card->controls_rwsem.
But it's error-prone and fragile. This patch set tries to change
those API functions to take the card->controls>rwsem internally by
themselves, so that the drivers don't need to take care of lockings.
After applying this patch set, only a couple of places still touch
card->controls_rwsem (which are OK-ish as they need for traversing the
control linked list).
Takashi
===
Takashi Iwai (11):
ALSA: control: Take card->controls_rwsem in snd_ctl_rename()
staging: greybus: audio_helper: Use snd_ctl_remove_id()
ASoC: atmel: mchp-pdmc: Use snd_ctl_remove_id()
ALSA: control: Take controls_rwsem lock in snd_ctl_remove()
ALSA: control: Add lockdep warning to internal functions
ASoC: sigmadsp: Simplify with snd_ctl_activate_id()
staging: greybus: Avoid abusing controls_rwsem
ALSA: control: Make snd_ctl_find_id() argument const
ALSA: control: Introduce unlocked version for snd_ctl_find_*() helpers
ALSA: control: Take lock in snd_ctl_find_id() and snd_ctl_find_numid()
ALSA: emu10k1: Go back and simplify with snd_ctl_find_id()
drivers/staging/greybus/audio_codec.c | 18 ++--
drivers/staging/greybus/audio_codec.h | 1 +
drivers/staging/greybus/audio_helper.c | 20 +---
include/sound/control.h | 6 +-
sound/core/control.c | 126 ++++++++++++++++++++-----
sound/core/control_compat.c | 2 +-
sound/core/control_led.c | 2 +-
sound/core/jack.c | 2 -
sound/core/oss/mixer_oss.c | 10 +-
sound/core/pcm.c | 2 -
sound/isa/sb/emu8000.c | 2 -
sound/isa/sb/sb16_csp.c | 2 -
sound/pci/emu10k1/emufx.c | 5 -
sound/pci/hda/hda_codec.c | 2 -
sound/soc/atmel/mchp-pdmc.c | 12 +--
sound/soc/codecs/sigmadsp.c | 25 +----
sound/soc/soc-topology.c | 3 -
17 files changed, 129 insertions(+), 111 deletions(-)
--
2.35.3
The variables gb_tty->port.close_delay and gb_tty->port.closing_wait are
ofter accessed together while holding the lock gb_tty->port.mutex. Here is
an example in set_serial_info():
mutex_lock(&gb_tty->port.mutex);
...
gb_tty->port.close_delay = close_delay;
gb_tty->port.closing_wait = closing_wait;
...
mutex_unlock(&gb_tty->port.mutex);
However, they are accessed without holding the lock gb_tty->port.mutex when
are accessed in get_serial_info():
ss->close_delay = jiffies_to_msecs(gb_tty->port.close_delay) / 10;
ss->closing_wait =
gb_tty->port.closing_wait == ASYNC_CLOSING_WAIT_NONE ?
ASYNC_CLOSING_WAIT_NONE :
jiffies_to_msecs(gb_tty->port.closing_wait) / 10;
In my opinion, this may be a harmful race, because ss->close_delay can be
inconsistent with ss->closing_wait if gb_tty->port.close_delay and
gb_tty->port.closing_wait are updated by another thread after the
assignment to ss->close_delay.
Besides, the select operator may return wrong value if
gb_tty->port.closing_wait is updated right after the condition is
calculated.
To fix this possible data-inconsistency caused by data race, a lock and
unlock pair is added when accessing different fields of gb_tty->port.
Reported-by: BassCheck <bass(a)buaa.edu.cn>
Signed-off-by: Tuo Li <islituo(a)gmail.com>
---
drivers/staging/greybus/uart.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/greybus/uart.c b/drivers/staging/greybus/uart.c
index 20a34599859f..b8875517ea6a 100644
--- a/drivers/staging/greybus/uart.c
+++ b/drivers/staging/greybus/uart.c
@@ -596,12 +596,14 @@ static int get_serial_info(struct tty_struct *tty,
{
struct gb_tty *gb_tty = tty->driver_data;
+ mutex_lock(&gb_tty->port.mutex);
ss->line = gb_tty->minor;
ss->close_delay = jiffies_to_msecs(gb_tty->port.close_delay) / 10;
ss->closing_wait =
gb_tty->port.closing_wait == ASYNC_CLOSING_WAIT_NONE ?
ASYNC_CLOSING_WAIT_NONE :
jiffies_to_msecs(gb_tty->port.closing_wait) / 10;
+ mutex_unlock(&gb_tty->port.mutex);
return 0;
}
--
2.34.1