linux-kernel - Re: [PATCH v2 06/19] iio: chemical: bme680: Fix read/write ops to device by adding mutexes

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: <20240609115628.2beb4cb1@jic23-huawei>
Date: Sun, 9 Jun 2024 11:56:28 +0100
From: Jonathan Cameron <jic23@...nel.org>
To: Vasileios Amoiridis <vassilisamir@...il.com>
Cc: dpfrey@...il.com, himanshujha199640@...il.com, lars@...afoo.de,
 linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org,
 mike.looijmans@...ic.nl
Subject: Re: [PATCH v2 06/19] iio: chemical: bme680: Fix read/write ops to
 device by adding mutexes

On Thu,  6 Jun 2024 23:22:58 +0200
Vasileios Amoiridis <vassilisamir@...il.com> wrote:

> Add mutexes in the {read/write}_raw() functions of the device to
> guard the read/write of data from/to the device. This is necessary
> because for any operation other than temperature, multiple reads
> need to take place from the device. Even though regmap has a locking
> by itself, it won't protect us from multiple applications trying to
> read at the same time temperature and pressure since the pressure
> reading includes an internal temperature reading and there is nothing
> to ensure that this temperature+pressure reading will happen
> sequentially without any other operation interfering in the meantime.
> 
> Fixes: 1b3bd8592780 ("iio: chemical: Add support for Bosch BME680 sensor")
> Signed-off-by: Vasileios Amoiridis <vassilisamir@...il.com>
> ---
>  drivers/iio/chemical/bme680_core.c | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/iio/chemical/bme680_core.c b/drivers/iio/chemical/bme680_core.c
> index 66177f7e94a8..92359032254a 100644
> --- a/drivers/iio/chemical/bme680_core.c
> +++ b/drivers/iio/chemical/bme680_core.c
> @@ -10,6 +10,7 @@
>   */
>  #include <linux/acpi.h>
>  #include <linux/bitfield.h>
> +#include <linux/cleanup.h>
>  #include <linux/delay.h>
>  #include <linux/device.h>
>  #include <linux/module.h>
> @@ -52,6 +53,7 @@ struct bme680_calib {
>  struct bme680_data {
>  	struct regmap *regmap;
>  	struct bme680_calib bme680;

Comment needed here on what data this lock protects.
It is far to easy to make wrong assumptions about locks so convention is
to always document their scope.

Otherwise lgtm (as do patches 1-5)

> +	struct mutex lock;
>  	u8 oversampling_temp;
>  	u8 oversampling_press;
>  	u8 oversampling_humid;
> @@ -827,6 +829,8 @@ static int bme680_read_raw(struct iio_dev *indio_dev,
>  {
>  	struct bme680_data *data = iio_priv(indio_dev);
>  
> +	guard(mutex)(&data->lock);
> +
>  	switch (mask) {
>  	case IIO_CHAN_INFO_PROCESSED:
>  		switch (chan->type) {
> @@ -871,6 +875,8 @@ static int bme680_write_raw(struct iio_dev *indio_dev,
>  {
>  	struct bme680_data *data = iio_priv(indio_dev);
>  
> +	guard(mutex)(&data->lock);
> +
>  	if (val2 != 0)
>  		return -EINVAL;
>  
> @@ -967,6 +973,7 @@ int bme680_core_probe(struct device *dev, struct regmap *regmap,
>  		name = bme680_match_acpi_device(dev);
>  
>  	data = iio_priv(indio_dev);
> +	mutex_init(&data->lock);
>  	dev_set_drvdata(dev, indio_dev);
>  	data->regmap = regmap;
>  	indio_dev->name = name;