linux-kernel - Re: [PATCH 0/7] net: core: devname allocation cleanups

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:   Sun, 12 Nov 2017 16:12:05 -0800
From:   Stephen Hemminger <stephen@...workplumber.org>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     "David S. Miller" <davem@...emloft.net>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/7] net: core: devname allocation cleanups

On Mon, 13 Nov 2017 00:15:03 +0100
Rasmus Villemoes <linux@...musvillemoes.dk> wrote:

> It's somewhat confusing to have both dev_alloc_name and
> dev_get_valid_name. I can't see why the former is less strict than the
> latter, so make them (or rather dev_alloc_name_ns and
> dev_get_valid_name) equivalent, hardening dev_alloc_name() a little.
> 
> Obvious follow-up patches would be to only export one function, and
> make dev_alloc_name a static inline wrapper for that (whichever name
> is chosen for the exported interface). But maybe there is a good
> reason the two exported interfaces do different checking, so I'll
> refrain from including the trivial but tree-wide renaming in this
> series.
> 
> Rasmus Villemoes (7):
>   net: core: improve sanity checking in __dev_alloc_name
>   net: core: move dev_alloc_name_ns a little higher
>   net: core: eliminate dev_alloc_name{,_ns} code duplication
>   net: core: drop pointless check in __dev_alloc_name
>   net: core: check dev_valid_name in __dev_alloc_name
>   net: core: maybe return -EEXIST in __dev_alloc_name
>   net: core: dev_get_valid_name is now the same as dev_alloc_name_ns
> 
>  net/core/dev.c | 62 +++++++++++++++++++++-------------------------------------
>  1 file changed, 22 insertions(+), 40 deletions(-)
> 

Looks good to me. Can't see anything obviously wrong with this.
I think the two functions started out heading in different directions.