[net] Revert "net: core: maybe return -EEXIST in __dev_alloc_name"

Michael Ellerman mpe at ellerman.id.au
Mon Jan 8 14:26:12 AEDT 2018


David Miller <davem at davemloft.net> writes:

> From: Michael Ellerman <mpe at ellerman.id.au>
> Date: Fri, 22 Dec 2017 15:22:22 +1100
>
>>> On Tue, Dec 19 2017, Michael Ellerman <michael at concordia.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


More information about the Linuxppc-dev mailing list