# Re: \[REGRESSION\] testing/selftests/x86/ pkeys build failures

- From: Ingo Molnar \<mingo@kernel.org\>
- Date: 2018-01-16 02:38:03 
- List: linux-api
- Page: https://ratatoskr.run/linux-api/2018/01/6486389
- Thread: https://ratatoskr.run/linux-mm/2018/01/6486321/t.md

```text

* Florian Weimer [ref] wrote:

> On 01/12/2018 01:55 PM, Ingo Molnar wrote:
> > 
> > * Florian Weimer [ref] wrote:
> > 
> > > This patch is based on the previous discussion (pkeys: Support setting
> > > access rights for signal handlers):
> > > 
> > >    https://marc.info/?t=151285426000001
> > > 
> > > It aligns the signal semantics of the x86 implementation with the upcoming
> > > POWER implementation, and defines a new flag, so that applications can
> > > detect which semantics the kernel uses.
> > > 
> > > A change in this area is needed to make memory protection keys usable for
> > > protecting the GOT in the dynamic linker.
> > > 
> > > (Feel free to replace the trigraphs in the commit message before committing,
> > > or to remove the program altogether.)
> > 
> > Could you please send patches not as MIME attachments?
> 
> My mail infrastructure corrupts patches not sent as attachments, sorry.

Your headers suggest the following mail client:

  User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
        Thunderbird/52.5.0

Have you seen the suggestions in Documentation/process/email-clients.rst, which 
lists a handful of Thunderbird tips:

  Thunderbird (GUI)
  *****************

  Thunderbird is an Outlook clone that likes to mangle text, but there are ways
  to coerce it into behaving.

?

> > Also, the protection keys testcase first need to be fixed, before we complicate
> > them - for example on a pretty regular Ubuntu x86-64 installation they fail to
> > build with the build errors attached further below.
> 
> I can fix things up so that they build on Fedora 26, Debian stretch, and Red
> Hat Enterprise Linux 7.  Would that be sufficient?

Yeah, I think so.

> Fedora 23 is out of support and I'd prefer not invest any work into it.
> 
> Note that I find it strange to make this a precondition for even looking at
> the patch.

I wanted to try the patch to give review feedback, but found these annoyances. 
It's customary to make new features dependent on the cleanliness of the underlying 
code.

Thanks,

	Ingo
```