This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Tests for res_init
On Sat, Jun 3, 2017 at 5:56 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sat, Jun 3, 2017 at 8:00 AM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Fri, Jun 2, 2017 at 11:43 PM, Florian Weimer <fweimer@redhat.com> wrote:
>>> On 06/03/2017 04:06 AM, H.J. Lu wrote:
>>>> On Fri, Jun 2, 2017 at 1:43 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>>>>> On Fri, Jun 2, 2017 at 1:40 PM, Florian Weimer <fweimer@redhat.com> wrote:
>>>>>> On 06/02/2017 10:19 PM, H.J. Lu wrote:
>>>>>>> On Fri, Jun 2, 2017 at 6:49 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>>>>>>> On 05/18/2017 10:05 PM, Siddhesh Poyarekar wrote:
>>>>>>>>> Why not just have a tst-resolv-res_init.c and
>>>>>>>>> tst-resolv-res_init-thread.c? That's how a lot of the other similar
>>>>>>>>> kinds of tests are rewritten. I don't have a very strong opinion on
>>>>>>>>> this though, you can choose the color of your shed :)
>>>>>>>>
>>>>>>>> I do it this way so that I can use #if instead of #ifdef, following the
>>>>>>>> current guidelines to trigger -Wundef warnings on typos.
>>>>>>>>
>>>>>>>> I'm going to push this without the tests expecting incorrect results.
>>>>>>>>
>>>>>>>
>>>>>>> On Fedora 25/x86-64, I got
>>>>>>>
>>>>>>> [hjl@gnu-6 build-x86_64-linux]$ cat resolv/tst-resolv-res_init.out
>>>>>>> Timed out: killed the child process
>>>>>>> [hjl@gnu-6 build-x86_64-linux]$ cat resolv/tst-resolv-res_init-thread.out
>>>>>>> Timed out: killed the child process
>>>>>>> [hjl@gnu-6 build-x86_64-linux]$
>>>>>>
>>>>>> I see that too, with 4.11.3-200.fc25.x86_64. What's your kernel version?
>>>>>>
>>>>>> I don't see the delay with 4.10.17-100.fc24.x86_64. There, the poll
>>>>>> system calls return immediately. I wonder if it's some sort of
>>>>>> regression in network namespaces.
>>>>>
>>>>> Yes, I am also running 4.11.3-200.fc25.x86_64.
>>>>>
>>>>
>>>> I booted 4.10.16-200.fc25.x86_64 and the test passed. Any ideas?
>>>
>>> I'm going to try to come up with a self-contained reproducer, and then
>>> approach the kernel people if it still looks like a kernel bug.
>>>
>>> Florian
>>
>> Kernel regression was introduced by
>>
>> commit 580bdf5650fff8f66468ce491f8308f1117b7074
>> Merge: e60a426 a249708
>> Author: David S. Miller <davem@davemloft.net>
>> Date: Tue Jan 17 15:19:37 2017 -0500
>>
>> Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
>>
>> But I don't know exactly which commit caused it.
>>
>
> It was caused by:
>
> commit 44bb765cf07ab6622e6fdf4bce546b43bd20faee
> Author: Florian Fainelli <f.fainelli@gmail.com>
> Date: Tue Jan 10 12:32:36 2017 -0800
>
> net: dsa: Implement ndo_get_phys_port_name()
>
> Return the physical port number of a DSA created network device using
> ndo_get_phys_port_name().
>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> Tested-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Reviewed-by: Jiri Pirko <jiri@mellanox.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
>
I was wrong. It isn't the bad one.
--
H.J.