netdev - Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc

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 for Android: free password hash cracker in your pocket

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

Message-ID: <874lnx2fqj.fsf@concordia.ellerman.id.au>
Date:   Mon, 08 Jan 2018 14:26:12 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     David Miller <davem@...emloft.net>
Cc:     linux@...musvillemoes.dk, michael@...cordia.ellerman.id.au,
        j@...fi, netdev@...r.kernel.org, johannes@...solutions.net,
        linuxppc-dev@...ts.ozlabs.org, johannes.berg@...el.com
Subject: Re: [net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name"

David Miller <davem@...emloft.net> writes:

> From: Michael Ellerman <mpe@...erman.id.au>
> Date: Fri, 22 Dec 2017 15:22:22 +1100
>
>>> On Tue, Dec 19 2017, Michael Ellerman <michael@...cordia.ellerman.id.au> wrote:
>>>> This revert seems to have broken networking on one of my powerpc
>>>> machines, according to git bisect.
>>>>
>>>> The symptom is DHCP fails and I don't get a link, I didn't dig any
>>>> further than that. I can if it's helpful.
>>>>
>>>> I think the problem is that 87c320e51519 ("net: core: dev_get_valid_name
>>>> is now the same as dev_alloc_name_ns") only makes sense while
>>>> d6f295e9def0 remains in the tree.
>>>
>>> I'm sorry about all of this, I really didn't think there would be such
>>> consequences of changing an errno return. Indeed, d6f29 was preparation
>>> for unifying the two functions that do the exact same thing (and how we
>>> ever got into that situation is somewhat unclear), except for
>>> their behaviour in the case the requested name already exists. So one of
>>> the two interfaces had to change its return value, and as I wrote, I
>>> thought EEXIST was the saner choice when an explicit name (no %d) had
>>> been requested.
>> 
>> No worries.
>> 
>>>> ie. before the entire series, dev_get_valid_name() would return EEXIST,
>>>> and that was retained when 87c320e51519 was merged, but now that
>>>> d6f295e9def0 has been reverted dev_get_valid_name() is returning ENFILE.
>>>>
>>>> I can get the network up again if I also revert 87c320e51519 ("net:
>>>> core: dev_get_valid_name is now the same as dev_alloc_name_ns"), or with
>>>> the gross patch below.
>>>
>>> I don't think changing -ENFILE to -EEXIST would be right either, since
>>> dev_get_valid_name() used to be able to return both (-EEXIST in the case
>>> where there's no %d, -ENFILE in the case where we end up calling
>>> dev_alloc_name_ns()). If anything, we could do the check for the old
>>> -EEXIST condition first, and then call dev_alloc_name_ns(). But I'm also
>>> fine with reverting.
>> 
>> Yeah I think a revert would be best, given it's nearly rc5.
>> 
>> My userspace is not exotic AFAIK, just debian something, so presumably
>> this will affect other people too.
>
> I've just queued up the following revert, thanks!

Thanks.

I don't see it in rc7, will it get to Linus sometime before the release?

cheers