linux-kernel - Re: [PATCH v2 13/27] ALSA: hda/cs8409: Dont disable I2C clock between consecutive accesses

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <s5him0ta1sn.wl-tiwai@suse.de>
Date:   Thu, 29 Jul 2021 11:48:24 +0200
From:   Takashi Iwai <tiwai@...e.de>
To:     Vitaly Rodionov <vitalyr@...nsource.cirrus.com>
Cc:     Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
        <alsa-devel@...a-project.org>, <patches@...nsource.cirrus.com>,
        <linux-kernel@...r.kernel.org>,
        Lucas Tanure <tanureal@...nsource.cirrus.com>,
        Stefan Binding <sbinding@...nsource.cirrus.com>
Subject: Re: [PATCH v2 13/27] ALSA: hda/cs8409: Dont disable I2C clock between consecutive accesses

On Wed, 28 Jul 2021 15:43:54 +0200,
Vitaly Rodionov wrote:
> 
> From: Lucas Tanure <tanureal@...nsource.cirrus.com>
> 
> Only disable I2C clock 25 ms after not being used.
> 
> The current implementation enables and disables the I2C clock for each
> I2C transaction. Each enable/disable call requires two verb transactions.
> This means each I2C transaction requires a total of four verb transactions
> to enable and disable the clock.
> However, if there are multiple consecutive I2C transactions, it is not
> necessary to enable and disable the clock each time, instead it is more
> efficient to enable the clock for the first transaction, and disable it
> after the final transaction, which would improve performance.
> This is achieved by using a timeout which disables the clock if no request
> to enable the clock has occurred for 25 ms.
> 
> Signed-off-by: Lucas Tanure <tanureal@...nsource.cirrus.com>
> Signed-off-by: Vitaly Rodionov <vitalyr@...nsource.cirrus.com>
> Signed-off-by: Stefan Binding <sbinding@...nsource.cirrus.com>
> 
> Changes in v2:
> Improved delayed work start/cancel implementation, and re-worked commit message
> adding more explanation why this was required. 
> 
> 
> ---
>  sound/pci/hda/patch_cs8409.c | 56 +++++++++++++++++++++++++-----------
>  sound/pci/hda/patch_cs8409.h |  4 +++
>  2 files changed, 43 insertions(+), 17 deletions(-)
> 
> diff --git a/sound/pci/hda/patch_cs8409.c b/sound/pci/hda/patch_cs8409.c
> index 08205c19698c..fafc0f309e70 100644
> --- a/sound/pci/hda/patch_cs8409.c
> +++ b/sound/pci/hda/patch_cs8409.c
> @@ -53,7 +53,9 @@ static struct cs8409_spec *cs8409_alloc_spec(struct hda_codec *codec)
>  	if (!spec)
>  		return NULL;
>  	codec->spec = spec;
> +	spec->codec = codec;
>  	codec->power_save_node = 1;
> +	INIT_DELAYED_WORK(&spec->i2c_clk_work, cs8409_disable_i2c_clock);
>  	snd_hda_gen_spec_init(&spec->gen);
>  
>  	return spec;
> @@ -72,21 +74,37 @@ static inline void cs8409_vendor_coef_set(struct hda_codec *codec, unsigned int
>  	snd_hda_codec_write(codec, CS8409_PIN_VENDOR_WIDGET, 0, AC_VERB_SET_PROC_COEF, coef);
>  }
>  
> -/**
> +/*
> + * cs8409_disable_i2c_clock - Worker that disable the I2C Clock after 25ms without use
> + */
> +static void cs8409_disable_i2c_clock(struct work_struct *work)
> +{
> +	struct cs8409_spec *spec = container_of(work, struct cs8409_spec, i2c_clk_work.work);
> +
> +	mutex_lock(&spec->cs8409_i2c_mux);
> +	cs8409_vendor_coef_set(spec->codec, 0x0,
> +			       cs8409_vendor_coef_get(spec->codec, 0x0) & 0xfffffff7);
> +	spec->i2c_clck_enabled = 0;
> +	mutex_unlock(&spec->cs8409_i2c_mux);

Here we have a lock in the work, and this would become a problem in
the below...

> +}
> +
> +/*
>   * cs8409_enable_i2c_clock - Enable I2C clocks
>   * @codec: the codec instance
> - * @enable: Enable or disable I2C clocks
> - *
>   * Enable or Disable I2C clocks.
> + * This must be called when the i2c mutex is locked.
>   */
> -static void cs8409_enable_i2c_clock(struct hda_codec *codec, unsigned int enable)
> +static void cs8409_enable_i2c_clock(struct hda_codec *codec)
>  {
> -	unsigned int retval;
> -	unsigned int newval;
> +	struct cs8409_spec *spec = codec->spec;
> +
> +	cancel_delayed_work_sync(&spec->i2c_clk_work);

Here, cancel_delayed_work_sync().  Since it's called inside the mutex
mutex (taken in the caller side), it'll lead to a deadlock.

(I know the i2c mutex lock is moved to this function in a later patch,
but this makes harder to review.  Given that it's only about the
performance, it'd better to apply this kind of change at the end of
series, not in the middle.)

In general, making such an async handling really race-free is not that
trivial.  Even if you call cancel_delayed_work_sync() outside the
mutex, it's possible that another task wedges itself between
cancel_work() and the mutex lock and re-enables the work.

One easier alternative implementation would be rather to allow enable
/ disable clock reentrant with refcounting.  It accepts the function
sequence like:

	enable_clock();
	i2c_write();
	i2c_write();
	...
	disable_clock();

while another thread calls

	enable_clock();
	i2c_write();
	disable_clock();

at the same time.


thanks,

Takashi