Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp6941457imb; Sat, 9 Mar 2019 10:37:45 -0800 (PST) X-Google-Smtp-Source: APXvYqzGu+rPmZwt4tnDXY/wsQWlmPcAtOufzhW+LY8YDvYZtxHv88Rcb5rMxszXJ9gSNyD5wd77 X-Received: by 2002:a62:1bd4:: with SMTP id b203mr24616573pfb.144.1552156665239; Sat, 09 Mar 2019 10:37:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1552156665; cv=none; d=google.com; s=arc-20160816; b=v11XGqZOPuO8MeR0grXMJgfxb/ncP6rI+QBwUIBW7oLZcrEWaSGYCueJmmz2BL4/ml i2sJyAQCBZOkGU9aB7O3ipnjnV9X5Pz/fBXJyv3bboiIuCvyzG1afajkg6oTf317P2Tl 7i+Qar3B9ubMTtjC6jOgPdjEvs7P3tIvcCEKsAZBJcQUFwaS7NnGX0tlonq+ZdGiPT/l Zql4WdUnLObrL3oIUzYzRJuFS8Lx8hxFy9kYOSi5BIeDMgKz731OqInB+mSp2qn2roE+ w/XHb1liGtxGHhAhwPaA535i+U+olpbDoSN4+WLIpYDCZCyIxZfvJ/YqMMYHZw0TGs1q 57MQ== 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:message-id:subject:cc:to:from:date :dkim-signature; bh=1BnZDgNKWiRfeLjz8cnd06l7h5bXhOawwZF/2xKRBnA=; b=AywekIzB6bwTf3PvBGxTvkSBlkkMHxH4AilUBOvelER7+5oMos7pjbB6boTIK38PMO OT3wPjjnSxrWeu7TMeWz5A+fPR+2+nUBKNF1DatvyZpEv60TyHcjiF8fRVvVwccVhG8I aLrr0WhqcdFjOPYHCiCQQT5eoPys7ocisX2Vl9WMXuc9wS7FSeFiMOMSreUdiu1jR7VE OEmvTbGsLNIB+pn1GJv1HjemQ7O8xwlkL/39fjvKfrnscnSBZs5ciXHmTJ+LY3DtzFJp zQSrbwHBLAQoRzSESyCxFlNOxHNcKLkQ4MBp/qRblN2zSXQ718n2ES0zaz+7Q7KdWEzD Z0/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=KSJJWmii; 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c64si914252pfg.36.2019.03.09.10.37.29; Sat, 09 Mar 2019 10:37:45 -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=@kernel.org header.s=default header.b=KSJJWmii; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726419AbfCIShJ (ORCPT + 99 others); Sat, 9 Mar 2019 13:37:09 -0500 Received: from mail.kernel.org ([198.145.29.99]:51558 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726313AbfCIShJ (ORCPT ); Sat, 9 Mar 2019 13:37:09 -0500 Received: from archlinux (cpc91196-cmbg18-2-0-cust659.5-4.cable.virginm.net [81.96.234.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 0A1CE207E0; Sat, 9 Mar 2019 18:37:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1552156627; bh=Nfz403lDd8pt7WEkj5q1Ikgohgob4/USeawIX9xlPmg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=KSJJWmiirvgOuIWEC+pfGANJYcEA/bA9D601nSTx5L+EelcRAJZg4GHN2CtOAFvOc Qq4PCU9jQ+CmchNGx05wSUAGrF94vKbA7i+1A3tsWI5c6wuzwAiAn7fH8URaADDu5c 8l3FqIRrflQ0xlKMvi+Bd+mIVo26xgLV63f2sVSc= Date: Sat, 9 Mar 2019 18:37:01 +0000 From: Jonathan Cameron To: Tomasz Duszynski Cc: justinpopo6@gmail.com, linux-iio@vger.kernel.org, linux-gpio@vger.kernel.org, bcm-kernel-feedback-list@broadcom.com, f.fainelli@gmail.com, bgolaszewski@baylibre.com, linus.walleij@linaro.org, knaack.h@gmx.de, lars@metafoo.de, pmeerw@pmeerw.net, linux-kernel@vger.kernel.org Subject: Re: [PATCH v5 1/2] iio: adc: ti-ads7950: Fix improper use of mlock Message-ID: <20190309183701.03afd62b@archlinux> In-Reply-To: <20190309162935.GC7820@arch> References: <1552082608-42603-1-git-send-email-justinpopo6@gmail.com> <1552082608-42603-2-git-send-email-justinpopo6@gmail.com> <20190309162935.GC7820@arch> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 9 Mar 2019 17:29:36 +0100 Tomasz Duszynski wrote: > On Fri, Mar 08, 2019 at 02:03:27PM -0800, justinpopo6@gmail.com wrote: > > From: Justin Chen > > > > Indio->mlock is used for protecting the different iio device modes. > > It is currently not being used in this way. Replace the lock with > > an internal lock specifically used for protecting the SPI transfer > > buffer. > > > > Signed-off-by: Justin Chen > > --- > > drivers/iio/adc/ti-ads7950.c | 19 +++++++++++++++---- > > 1 file changed, 15 insertions(+), 4 deletions(-) > > > > diff --git a/drivers/iio/adc/ti-ads7950.c b/drivers/iio/adc/ti-ads7950.c > > index 0ad6359..1e47bef 100644 > > --- a/drivers/iio/adc/ti-ads7950.c > > +++ b/drivers/iio/adc/ti-ads7950.c > > @@ -56,6 +56,9 @@ struct ti_ads7950_state { > > struct spi_message ring_msg; > > struct spi_message scan_single_msg; > > > > + /* Lock to protect the spi xfer buffers */ > > + struct mutex slock; > > + > > struct regulator *reg; > > unsigned int vref_mv; > > > > @@ -268,6 +271,7 @@ static irqreturn_t ti_ads7950_trigger_handler(int irq, void *p) > > struct ti_ads7950_state *st = iio_priv(indio_dev); > > int ret; > > > > + mutex_lock(&st->slock); > > ret = spi_sync(st->spi, &st->ring_msg); > > if (ret < 0) > > goto out; > > @@ -276,6 +280,7 @@ static irqreturn_t ti_ads7950_trigger_handler(int irq, void *p) > > iio_get_time_ns(indio_dev)); > > > > out: > > + mutex_unlock(&st->slock); > > iio_trigger_notify_done(indio_dev->trig); > > > > return IRQ_HANDLED; > > @@ -286,7 +291,7 @@ static int ti_ads7950_scan_direct(struct iio_dev *indio_dev, unsigned int ch) > > struct ti_ads7950_state *st = iio_priv(indio_dev); > > int ret, cmd; > > > > - mutex_lock(&indio_dev->mlock); > > + mutex_lock(&st->slock); > > > > cmd = TI_ADS7950_CR_WRITE | TI_ADS7950_CR_CHAN(ch) | st->settings; > > st->single_tx = cmd; > > @@ -298,7 +303,7 @@ static int ti_ads7950_scan_direct(struct iio_dev *indio_dev, unsigned int ch) > > ret = st->single_rx; > > > > out: > > - mutex_unlock(&indio_dev->mlock); > > + mutex_unlock(&st->slock); > > > > return ret; > > } > > @@ -432,16 +437,19 @@ static int ti_ads7950_probe(struct spi_device *spi) > > if (ACPI_COMPANION(&spi->dev)) > > st->vref_mv = TI_ADS7950_VA_MV_ACPI_DEFAULT; > > > > + mutex_init(&st->slock); > > + > > st->reg = devm_regulator_get(&spi->dev, "vref"); > > if (IS_ERR(st->reg)) { > > dev_err(&spi->dev, "Failed get get regulator \"vref\"\n"); > > - return PTR_ERR(st->reg); > > + ret = PTR_ERR(st->reg); > > + goto error_destroy_mutex; > > } > > > > ret = regulator_enable(st->reg); > > if (ret) { > > dev_err(&spi->dev, "Failed to enable regulator \"vref\"\n"); > > - return ret; > > + goto error_destroy_mutex; > > } > > > > ret = iio_triggered_buffer_setup(indio_dev, NULL, > > @@ -463,6 +471,8 @@ static int ti_ads7950_probe(struct spi_device *spi) > > iio_triggered_buffer_cleanup(indio_dev); > > error_disable_reg: > > regulator_disable(st->reg); > > +error_destroy_mutex: > > + mutex_destroy(&st->slock); > > If your intention was to do resources cleanup then this is not > what this api was designed for. This is actually for debugging unwanted > subsequent mutex usage. Yes. In a case like this where it is the last thing in a remove it adds little value as there should be nothing left to take the mutex anyway. This is the reason (I guess) there has never been a devm_mutex_init function to tidy this up automatically... > > > > > return ret; > > } > > @@ -475,6 +485,7 @@ static int ti_ads7950_remove(struct spi_device *spi) > > iio_device_unregister(indio_dev); > > iio_triggered_buffer_cleanup(indio_dev); > > regulator_disable(st->reg); > > + mutex_destroy(&st->slock); > > > > return 0; > > } > > -- > > 2.7.4 > >