Received: by 10.223.176.5 with SMTP id f5csp1823600wra; Sun, 4 Feb 2018 13:04:04 -0800 (PST) X-Google-Smtp-Source: AH8x225li+OBObDUUM7nz8V5PLVqu2W5JjaoYAXSfkYIYvNLN/Qgy/D9t1iR7aNE13GyXbvQaEjD X-Received: by 2002:a17:902:b7c3:: with SMTP id v3-v6mr32390553plz.307.1517778244563; Sun, 04 Feb 2018 13:04:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517778244; cv=none; d=google.com; s=arc-20160816; b=UbgEbnAZsppb6g2ETqM+KPeMpqbt5ULxe8fZVXvBysF6HASkJiMXz4GgetKH3T/sFv BdXykvMYR/h40nzl3Z+7lchEpiJPkJ1RVExeiZ+FxFz0FVc9jZoZlTZQO5f+ipU/Ubt3 4u6HxgXep5VNB5qawJB5A9ZB0ZkaNIq7Ve19pj4d74GEqQ0urpw/hI6jqkhR/yGYO0S+ y4eolWwLt/5pmTHyrDsLf/iteLZKP5tN/ucUtOoiSZVIYMvad7XsrdkRbkQVJwtlkkzH VMfCMP52kFU7pgFAJ0KN1JwKETcYzJH5YPk9RpB5+iDLcYpoiua5JHJf7R4u3sU7z47w MeRw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id :dkim-signature:arc-authentication-results; bh=9otoEkTYw9qlbV/PPrr0ZDV+2/VTDttSgTSm+OHhE1A=; b=jYKgHalcdrGQGyiZOonE/TnWMiEHrn6ZgPClIGkFe6Lm0AHuPJrcaeeI4EpOmmGs2N Db72xf4VWkM84SRwysgzFY8gtiY7bY1Cl3IqT8p9NmbnsHSeUXmvZlku+tHITL6JtVwC dIlrdmxwERtHoLJLs3X6MiPQuDHOsarDjGP8jWFeQtnJ4dfMl/DdMXIq853FFMGHEmOI qrUfyl9GHzAafY8BZYX6oKLbebh+8ylzLh8DJKhrBHen0bbgR9QHv3TgBl/bDd5X07xv +LmT0Ot4nYc8h6y0CihnqTh9UH2Hz6TiXtyGweL9DDnq/OsKbu35zFftyxCrJ2CXAjT8 iYwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XXXVaMCZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p11-v6si4097845pls.826.2018.02.04.13.03.50; Sun, 04 Feb 2018 13:04:04 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XXXVaMCZ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752536AbeBDVDR (ORCPT + 99 others); Sun, 4 Feb 2018 16:03:17 -0500 Received: from mail-pg0-f66.google.com ([74.125.83.66]:34048 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752100AbeBDVDM (ORCPT ); Sun, 4 Feb 2018 16:03:12 -0500 Received: by mail-pg0-f66.google.com with SMTP id s73so2424750pgc.1; Sun, 04 Feb 2018 13:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=message-id:subject:from:to:cc:date:in-reply-to:references :mime-version:content-transfer-encoding; bh=9otoEkTYw9qlbV/PPrr0ZDV+2/VTDttSgTSm+OHhE1A=; b=XXXVaMCZkFPBa7ZrcG1r7kw2mzw67exYv2w2+rM8kdUKIgSUXB48OOkDA4hJHb5JwM yAf+vScy+tytFErc2wwGzSnY1mNMyIswoJdBdpf/fHd+FnrQb5HDSMjb1+6Mtj81BLOP t/i50x505f+u6Qsw62Vo1ZnpppyhdgkBf9RS/4XzLLmcwwVyHwkDlfrFWpON4++8CYTO JeACaLPzuPdI5Op4Q5gMmWFqP5q1Va/P2H4YLkNQyhSrfXhuXZjrCB/EbEMPhGd96+Nc SVqL7IeerKTgB7vz40z4xUcvauRixD5LF3/bRKidZ1ZGVO7dMGWfmYSkXO36noxF10kO /WqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=9otoEkTYw9qlbV/PPrr0ZDV+2/VTDttSgTSm+OHhE1A=; b=V78ny+EtuzL9VOu554ttEoUTchKQpR+PvfXj7v0qlD/NtRKM8mV6NNEQ4EX3peGqP+ sqYiXhqAkLArxaGGixxb4rZ5ef8lBZcZGZQlgmZ3RZEBv8C1M2gBjyYIR0+Qc9LPktM4 yjcwkd+I563AY7H1SdrTVQTidDgSyeaQyEOffd/dadOqv+sF0oCtVlQgs3jen/M5nYfu UI7sAZ3+cC5bJX4vFx7Dx7FjEO2u7EnmsNcHyiBiEfIwCDeXXpNPuvJt5gOG8kAV6RFI O3i2OlnOM40dzZclrblQiMjmg8pstw9NunTR/b9FHcqxGW3jW06dEbFv8aJO3qgDZ+Rx oXog== X-Gm-Message-State: AKwxyteoIIUT1gSwkfvNkAvg9iqtJRg//PBn3HJQrPonYvFnJeOsZ178 t5JVX1K2OfSZQJ9s283G/T8= X-Received: by 10.98.11.17 with SMTP id t17mr46817228pfi.201.1517778191727; Sun, 04 Feb 2018 13:03:11 -0800 (PST) Received: from [10.0.2.15] ([103.212.140.133]) by smtp.googlemail.com with ESMTPSA id y1sm11044104pge.78.2018.02.04.13.03.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Feb 2018 13:03:10 -0800 (PST) Message-ID: <1517778185.2292.10.camel@gmail.com> Subject: Re: [PATCH v4] Staging: iio: ade7758: Expand buf_lock to cover both buffer and state protection From: Shreeya Patel To: Jonathan Cameron Cc: lars@metafoo.de, Michael.Hennerich@analog.com, knaack.h@gmx.de, pmeerw@pmeerw.net, gregkh@linuxfoundation.org, linux-iio@vger.kernel.org, devel@driverdev.osuosl.org, linux-kernel@vger.kernel.org Date: Mon, 05 Feb 2018 02:33:05 +0530 In-Reply-To: <20180204111022.0e6d08f6@archlinux> References: <1517671892-4045-1-git-send-email-shreeya.patel23498@gmail.com> <20180204111022.0e6d08f6@archlinux> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.18.5.2-0ubuntu3.2 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, 2018-02-04 at 11:10 +0000, Jonathan Cameron wrote: > On Sat,  3 Feb 2018 21:01:32 +0530 > Shreeya Patel wrote: > > > > > iio_dev->mlock is to be used only by the IIO core for protecting > > device mode changes between INDIO_DIRECT and INDIO_BUFFER. > > > > This patch replaces the use of mlock with the already established > > buf_lock mutex. > > > > Introducing 'unlocked' forms of read and write registers. The > > read/write frequency functions now require buf_lock to be held. > > That's not obvious so avoid this but moving the locking inside > > the functions where it is then clear that they are taking the > > unlocked forms of the register read/write. > > > > It isn't readily apparent that write frequency function requires > > the locks to be taken, so move it inside the function to where it > > is required to protect. > > > > Signed-off-by: Shreeya Patel > Hi Shreeya, > Hello sir, > Unfortunately this introduces a new bug - you end up unlocking > a mutex that you never locked in one of the error paths. > See inline. I'll make this change. > > We are also still taking the mlock around the read of the > frequency which doesn't make any sense given there is > no reason to protect that against state changes. > Arguably fixing that could be a separate patch as it never > made much sense, but it should probably be in this same series > at least.  I would have no real problem with it being in it this > same patch as long as the description above mentions it. > > Thanks, > > Jonathan > > > > > --- > > > > Changes in v2 > >   -Add static keyword to newly introduced functions and remove some > > added comments which are not required. > > > > Changes in v3 > >   -Remove some useless mlocks and send it as another patch. > > Also make the necessary change in the current patch associated > > with  > > the new patch with commit id 88eba33. Make commit message more  > > appropriate. > > > > Changes in v4 > >   -Write frequency function do not require lock so move it inside > > the function to where it is required to protect. > > > > > >  drivers/staging/iio/meter/ade7758.h      |  2 +- > >  drivers/staging/iio/meter/ade7758_core.c | 49 > > ++++++++++++++++++++++++-------- > >  2 files changed, 38 insertions(+), 13 deletions(-) > > > > diff --git a/drivers/staging/iio/meter/ade7758.h > > b/drivers/staging/iio/meter/ade7758.h > > index 6ae78d8..2de81b5 100644 > > --- a/drivers/staging/iio/meter/ade7758.h > > +++ b/drivers/staging/iio/meter/ade7758.h > > @@ -111,7 +111,7 @@ > >   * @trig: data ready trigger registered with iio > >   * @tx: transmit buffer > >   * @rx: receive buffer > > - * @buf_lock: mutex to protect tx and rx > > + * @buf_lock: mutex to protect tx, rx, read and > > write frequency > >   **/ > >  struct ade7758_state { > >   struct spi_device *us; > > diff --git a/drivers/staging/iio/meter/ade7758_core.c > > b/drivers/staging/iio/meter/ade7758_core.c > > index 227dbfc..ff19d46 100644 > > --- a/drivers/staging/iio/meter/ade7758_core.c > > +++ b/drivers/staging/iio/meter/ade7758_core.c > > @@ -24,17 +24,25 @@ > >  #include "meter.h" > >  #include "ade7758.h" > >   > > -int ade7758_spi_write_reg_8(struct device *dev, u8 reg_address, u8 > > val) > > +static int __ade7758_spi_write_reg_8(struct device *dev, u8 > > reg_address, u8 val) > >  { > > - int ret; > >   struct iio_dev *indio_dev = dev_to_iio_dev(dev); > >   struct ade7758_state *st = iio_priv(indio_dev); > >   > > - mutex_lock(&st->buf_lock); > >   st->tx[0] = ADE7758_WRITE_REG(reg_address); > >   st->tx[1] = val; > >   > > - ret = spi_write(st->us, st->tx, 2); > > + return spi_write(st->us, st->tx, 2); > > +} > > + > > +int ade7758_spi_write_reg_8(struct device *dev, u8 reg_address, u8 > > val) > > +{ > > + int ret; > > + struct iio_dev *indio_dev = dev_to_iio_dev(dev); > > + struct ade7758_state *st = iio_priv(indio_dev); > > + > > + mutex_lock(&st->buf_lock); > > + ret = __ade7758_spi_write_reg_8(dev, reg_address, val); > >   mutex_unlock(&st->buf_lock); > >   > >   return ret; > > @@ -91,7 +99,7 @@ static int ade7758_spi_write_reg_24(struct device > > *dev, u8 reg_address, > >   return ret; > >  } > >   > > -int ade7758_spi_read_reg_8(struct device *dev, u8 reg_address, u8 > > *val) > > +static int __ade7758_spi_read_reg_8(struct device *dev, u8 > > reg_address, u8 *val) > >  { > >   struct iio_dev *indio_dev = dev_to_iio_dev(dev); > >   struct ade7758_state *st = iio_priv(indio_dev); > > @@ -111,7 +119,6 @@ int ade7758_spi_read_reg_8(struct device *dev, > > u8 reg_address, u8 *val) > >   }, > >   }; > >   > > - mutex_lock(&st->buf_lock); > >   st->tx[0] = ADE7758_READ_REG(reg_address); > >   st->tx[1] = 0; > >   > > @@ -124,7 +131,19 @@ int ade7758_spi_read_reg_8(struct device *dev, > > u8 reg_address, u8 *val) > >   *val = st->rx[0]; > >   > >  error_ret: > > + return ret; > > +} > > + > > +int ade7758_spi_read_reg_8(struct device *dev, u8 reg_address, u8 > > *val) > > +{ > > + struct iio_dev *indio_dev = dev_to_iio_dev(dev); > > + struct ade7758_state *st = iio_priv(indio_dev); > > + int ret; > > + > > + mutex_lock(&st->buf_lock); > > + ret = __ade7758_spi_read_reg_8(dev, reg_address, val); > >   mutex_unlock(&st->buf_lock); > > + > >   return ret; > >  } > >   > > @@ -480,10 +499,12 @@ static int ade7758_read_samp_freq(struct > > device *dev, int *val) > >   return 0; > >  } > >   > > -static int ade7758_write_samp_freq(struct device *dev, int val) > > +static int ade7758_write_samp_freq(struct iio_dev *indio_dev, int > > val) > >  { > >   int ret; > >   u8 reg, t; > > + struct ade7758_state *st = iio_priv(indio_dev); > > + struct device *dev = &indio_dev->dev; > >   > >   switch (val) { > >   case 26040: > > @@ -503,16 +524,20 @@ static int ade7758_write_samp_freq(struct > > device *dev, int val) > >   goto out; > This goto out results in an unlock but the lock hasn't been locked > for a few more lines... > > Change this to a direct return here rather than a goto to fix this. > return -EINVAL; > > > > >   } > >   > > - ret = ade7758_spi_read_reg_8(dev, ADE7758_WAVMODE, ®); > > + mutex_lock(&st->buf_lock); > > + > > + ret = __ade7758_spi_read_reg_8(dev, ADE7758_WAVMODE, > > ®); > >   if (ret) > >   goto out; Here, can I move the above lock after the calling of the read register but before the if(ret) statement? With this we can avoid locks over the read cases. Mostly, this shouldn't create any problem but yet I thought of first confirming it from you. Thank you  > >   > >   reg &= ~(5 << 3); > >   reg |= t << 5; > >   > > - ret = ade7758_spi_write_reg_8(dev, ADE7758_WAVMODE, reg); > > + ret = __ade7758_spi_write_reg_8(dev, ADE7758_WAVMODE, > > reg); > >   > >  out: > > + mutex_unlock(&st->buf_lock); > > + > >   return ret; > >  } > >   > > @@ -545,9 +570,9 @@ static int ade7758_write_raw(struct iio_dev > > *indio_dev, > >   case IIO_CHAN_INFO_SAMP_FREQ: > >   if (val2) > >   return -EINVAL; > > - mutex_lock(&indio_dev->mlock); > > - ret = ade7758_write_samp_freq(&indio_dev->dev, > > val); > > - mutex_unlock(&indio_dev->mlock); > > + > > + ret = ade7758_write_samp_freq(indio_dev, val); > > + > >   return ret; > >   default: > >   return -EINVAL;