linux-kernel - Re: [PATCH v6 1/4] lib: new helper kstrtodev

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 20 Feb 2020 08:49:01 +0100
From:   Uwe Kleine-König 
        <u.kleine-koenig@...gutronix.de>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>, Dan Murphy <dmurphy@...com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Linux LED Subsystem <linux-leds@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Sascha Hauer <kernel@...gutronix.de>,
        "open list:SERIAL DRIVERS" <linux-serial@...r.kernel.org>
Subject: Re: [PATCH v6 1/4] lib: new helper kstrtodev_t()

On Wed, Feb 19, 2020 at 09:50:54PM +0200, Andy Shevchenko wrote:
> On Thu, Feb 13, 2020 at 11:27 AM Uwe Kleine-König <uwe@...ine-koenig.org> wrote:
> >
> > This function is in the same spirit as the other kstrto* functions and
> > uses the same calling convention. It expects the input string to be in
> > the format %u:%u and implements stricter parsing than sscanf as it
> > returns an error on trailing data (other than the usual \n).
> 
> Can we first split the kstrotox* (and simple_strto*) to the separate
> header first?

I don't feel strong here what is right. But I hesitate to create another
pre-condition for this patch set.

> On top of that, why kstrtodev_t is so important? How many users are
> already in the kernel to get an advantage out of it?

Does it need to be important? It matches the other kstrto* functions and
so it seemed more natural to me to put it near the other functions. I'm
not aware of other potential users and surprised you seem to suggest
this as a requirement.

> What to do with all other possible variants ("%d:%d", "%dx%d" and its
> %u variant, etc)?

I don't see how %d:%d is relevant, major and minor cannot be negative
can they? I never saw 'x' as separator between major and minor. I
considered shortly parsing %u, but given that (I think) this is an
internal representation only I chose to not make it more visible than it
already is.

> Why simple_strto*() can't be used?

I didn't really consider it, but looking in more detail I don't like it
much. Without having tried it I think simple_strtoull accepts
"1000000000000000000000000000000000000000000" returning some arbitrary
value without an error indication. And given that I was asked for strict
parsing (i.e. not accepting 2:4:something) I'd say using simple_strto*
is a step backwards. Also simple_strtoul() has "This function is obsolete.
Please use kstrtoul instead." in its docstring which seems to apply to
the other simple_strto*() functions, too.

> >  #include <linux/export.h>
> >  #include <linux/types.h>
> >  #include <linux/uaccess.h>
> 
> > +#include <linux/kdev_t.h>
> 
> Perhaps preserve order?

Can do.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | https://www.pengutronix.de/ |