On 19/10/16 11:32, Brian Masney wrote:
> taos_get_lux() calls mutex_trylock(). If the lock could not be acquired,
> then chip->als_cur_info.lux is returned. The issue is that this value
> is updated while the mutex is held and could cause a half written value
> to be returned to the caller. This patch changes the call to
> mutex_trylock() with mutex_lock().
>
> Signed-off-by: Brian Masney <masneyb@xxxxxxxxxxxxx>
I'd go with the simple approach you have here.
If someone cares enough they can figure out the complex solution. Probably
should be pushed off to userspace. It's not unusual for devices to take
'a little while' to respond to sysfs reads.
Jonathan
> ---
> This is the most controversial change in my patch set. There are two
> other possible solutions that I could envision to work around this
> issue:
>
> 1) Return -EBUSY and make the caller responsible for backing off
> 2) Change this driver to use RCU instead of a mutex
>
> drivers/staging/iio/light/tsl2583.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/staging/iio/light/tsl2583.c b/drivers/staging/iio/light/tsl2583.c
> index 47656ae..c4d2e3a 100644
> --- a/drivers/staging/iio/light/tsl2583.c
> +++ b/drivers/staging/iio/light/tsl2583.c
> @@ -206,10 +206,7 @@ static int taos_get_lux(struct iio_dev *indio_dev)
> u32 ch0lux = 0;
> u32 ch1lux = 0;
>
> - if (mutex_trylock(&chip->als_mutex) == 0) {
> - dev_info(&chip->client->dev, "taos_get_lux device is busy\n");
> - return chip->als_cur_info.lux; /* busy, so return LAST VALUE */
> - }
> + mutex_lock(&chip->als_mutex);
>
> if (chip->taos_chip_status != TSL258X_CHIP_WORKING) {
> /* device is not enabled */
>
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
