From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754426AbcDYKrw (ORCPT ); Mon, 25 Apr 2016 06:47:52 -0400 Received: from foss.arm.com ([217.140.101.70]:44903 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754377AbcDYKrv (ORCPT ); Mon, 25 Apr 2016 06:47:51 -0400 Subject: Re: [PATCH V3 10/18] coresight: tmc: getting the right read_count on tmc_open() To: Mathieu Poirier , linux-arm-kernel@lists.infradead.org References: <1461345255-11758-1-git-send-email-mathieu.poirier@linaro.org> <1461345255-11758-11-git-send-email-mathieu.poirier@linaro.org> Cc: linux-kernel@vger.kernel.org From: Suzuki K Poulose Message-ID: <571DF5D4.8070300@arm.com> Date: Mon, 25 Apr 2016 11:47:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <1461345255-11758-11-git-send-email-mathieu.poirier@linaro.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 22/04/16 18:14, Mathieu Poirier wrote: > In function tmc_open(), if tmc_read_prepare() fails variable > drvdata->read_count is not decremented, causing unwanted > access to drvdata->buf and very likely, a crash dump. > > By moving the incrementation to a place where we know things > are stable this kind of situation is avoided. > > Signed-off-by: Mathieu Poirier > Reviewed-by: Suzuki K Poulose > --- > drivers/hwtracing/coresight/coresight-tmc.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/hwtracing/coresight/coresight-tmc.c b/drivers/hwtracing/coresight/coresight-tmc.c > index e8e12a9b917a..55806352b1f1 100644 > --- a/drivers/hwtracing/coresight/coresight-tmc.c > +++ b/drivers/hwtracing/coresight/coresight-tmc.c > @@ -121,13 +121,14 @@ static int tmc_open(struct inode *inode, struct file *file) > struct tmc_drvdata, miscdev); > int ret = 0; > On a second thought, I think there could be a race here. > - if (drvdata->read_count++) > + if (drvdata->read_count) > goto out; > > ret = tmc_read_prepare(drvdata); > if (ret) > return ret; > out: What prevents someone else doing a release() on the file when we get here, without incrementing the read_count ? Also, read_count accesses are not protected. Either should be covered by the drvdata->spinlock or convert it to atomic. > + drvdata->read_count++; > nonseekable_open(inode, file); Cheers Suzuki