Re: [PATCH] S390: Sync ptrace.h with kernel. [BZ #21539]

[Stefan Liebler <stli@linux.vnet.ibm.com>]

On 07/18/2017 04:11 PM, Carlos O'Donell wrote:
> On 07/18/2017 09:39 AM, Dmitry V. Levin wrote:
>> On Tue, Jul 18, 2017 at 09:31:49AM -0400, Carlos O'Donell wrote:
>>> On 07/18/2017 06:20 AM, Dmitry V. Levin wrote:
>>>> Mark Wielaard has spotted [1] a regression that I missed during review.
>>>> After this change, this test case fails to compile with the following
>>>> diagnostics:
>>>>
>>>> $ gcc -c -xc -o/dev/null - <<'EOF'
>>>> #include <asm/ptrace.h>
>>>> #include <sys/ptrace.h>
>>>> EOF
>>>
>>> This is a linux/glibc header coordination issue.
>>
>> Not really, this is a new issue since glibc-2.25.
> 
> It is both a new issue and a header coordination issue, the two are not
> mutually exclusive.
> 
>>> https://sourceware.org/glibc/wiki/Synchronizing_Headers
>>
>> This project doesn't appear to be alive, unfortunately.
> 
> The project is alive. We are the project. We need to send patches upstream
> to the Linux kernel to keep fixing inclusion ordering issues where we need
> them fixed.
> 
> When 2.27 opens I have a pile of header inclusion ordering fixes I want to
> propose along with tests for them, but I haven't had a chance to submit. So
> we can discuss this in a few weeks.
> 
>>>> The following change fixes this and similar compilation issues that arise
>>>> when sys/ptrace.h is included after linux/ptrace.h:
>>>   
>>> This is a known conflict, and needs to be fixed properly using libc-compat.h
>>> on the kernel side and the appropriate defines on the glibc side.
>>
>> No, there was no conflict between asm/ptrace.h and sys/ptrace.h on s390
>> in glibc-2.25, and we should avoid introducing new conflicts.
> 
> I have not verified that inclusion worked on both orders, if it did, then
> this is indeed a regression.
Before my commit "S390: Sync ptrace.h with kernel. [BZ #21539]",
both orders compiled without a failure:

#include <asm/ptrace.h>
#include <sys/ptrace.h>
=> okay (but fails after my commit)


#include <sys/ptrace.h>
#include <asm/ptrace.h>
=> okay


However if somebody used linux/ptrace.h instead of asm/ptrace.h:

#include <linux/ptrace.h>
#include <sys/ptrace.h>
=> fail


#include <sys/ptrace.h>
#include <linux/ptrace.h>
=> okay


With Dimitry's patch, all four cases are okay.

> 
> However, I would like to take a step back:
> 
> * Why is this issue a blocker? What software does it stop from building?
> 
> * Can we delay the fix until after the release and fix it properly?
> 
> Mark, Is this a problem for Valgrind?
> 

Carlos, shall we commit Dimitry's patch before the release?
Then we don't have this regression compared to glibc 2.25 release.

Bye.
Stefan