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

[Stefan Liebler <stli at linux dot vnet dot ibm dot 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