Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 17 Feb 2021 11:18:26 +0300
From:   Dan Carpenter <dan.carpenter@oracle.com>
To:     Drew Fustini <drew@beagleboard.org>
Cc:     Joe Perches <joe@perches.com>,
        Linus Walleij <linus.walleij@linaro.org>,
        linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
        Tony Lindgren <tony@atomide.com>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        Alexandre Belloni <alexandre.belloni@bootlin.com>,
        Geert Uytterhoeven <geert@linux-m68k.org>,
        Pantelis Antoniou <pantelis.antoniou@konsulko.com>,
        Jason Kridner <jkridner@beagleboard.org>,
        Robert Nelson <robertcnelson@beagleboard.org>
Subject: Re: [PATCH v4 2/2] pinctrl: pinmux: Add pinmux-select debugfs file
Message-ID: <20210217081826.GJ2222@kadam>
References: <20210210222851.232374-1-drew@beagleboard.org>
 <20210210222851.232374-3-drew@beagleboard.org>
 <20210211071153.GJ20820@kadam>
 <7b4105ca8671a2962910deb5418a934bf07d1458.camel@perches.com>
 <20210211073938.GL20820@kadam>
 <20210212033533.GA347396@x1>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20210212033533.GA347396@x1>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

On Thu, Feb 11, 2021 at 07:35:33PM -0800, Drew Fustini wrote:
> On Thu, Feb 11, 2021 at 10:39:38AM +0300, Dan Carpenter wrote:
> > On Wed, Feb 10, 2021 at 11:24:23PM -0800, Joe Perches wrote:
> > > On Thu, 2021-02-11 at 10:11 +0300, Dan Carpenter wrote:
> > > > On Wed, Feb 10, 2021 at 02:28:54PM -0800, Drew Fustini wrote:
> > > > > +	ret = strncpy_from_user(buf, user_buf, PINMUX_MAX_NAME * 2);
> > > > > +	if (ret < 0) {
> > > > > +		dev_err(pctldev->dev, "failed to copy buffer from userspace");
> > > > > +		goto free_gname;
> > > > > +	}
> > > > > +	buf[len-1] = '\0';
> > > > > +
> > > > > +	ret = sscanf(buf, "%s %s", fname, gname);
> > > > > +	if (ret != 2) {
> > > > > +		dev_err(pctldev->dev, "expected format: <function-name> <group-name>");
> > > > > +		goto free_gname;
> > > > 
> > > > We need a "ret = -EINVAL;" before the goto.  sscanf doesn't return error
> > > > codes.  Normally we would write it like so:
> > > > 
> > > > 	if (sscanf(buf, "%s %s", fname, gname) != 2) {
> > > > 		dev_err(pctldev->dev, "expected format: <function-name> <group-name>");
> > > > 		ret = -EINVAL;
> > > > 		goto free_gname;
> > > > 	}
> > > > 
> > > > I'm going to write a Smatch check for this today.
> > > 
> > > It's a pretty frequently used style:
> > > 
> > > $ git grep -P '\w+\s*=\s+sscanf\b' | wc -l
> > > 327
> > 
> > Yeah.  That's true.  I looked through a couple of those and they were
> > fine.  (Sample size 2)  But the other format is more common.
> > 
> > $ git grep sscanf | grep = | wc -l
> > 803
> > 
> > I have written a Smatch check to complain whenever we propogate the
> > return value from sscanf.  I'll let you know tomorrow how that goes.
> > 
> > I should write another check which says "On this error path, we know
> > sscanf was not equal to the value we wanted but we are still returning
> > success".
> > 
> > regards,
> > dan carpenter
> > 
> 
> Thank you for comments regarding sscanf().  And also thank you for the
> LF mentorship session on smatch this morning.  It helped me understand
> it much better.

Good deal!

The warning about propagating errors from sscanf caught a couple bugs.
The one about returning success if sscanf failed didn't catch anything.

The sscanf overflow patch didn't find anything either, but I think we've
had those bugs in the past and so I expect some in the future so I will
keep that one in my private tests without pushing it.

regards,
dan carpenter