[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANpmjNNyifBNdpejc6ofT6+n6FtUw-Cap_z9Z9YCevd7Wf3JYQ@mail.gmail.com>
Date: Sat, 1 May 2021 18:24:24 +0200
From: Marco Elver <elver@...gle.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Arnd Bergmann <arnd@...db.de>, Florian Weimer <fweimer@...hat.com>,
"David S. Miller" <davem@...emloft.net>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Collingbourne <pcc@...gle.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Alexander Potapenko <glider@...gle.com>,
sparclinux <sparclinux@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux API <linux-api@...r.kernel.org>,
kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: [RFC][PATCH 0/3] signal: Move si_trapno into the _si_fault union
On Sat, 1 May 2021 at 17:17, Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> Marco Elver <elver@...gle.com> writes:
>
> > On Sat, 1 May 2021 at 01:48, Eric W. Biederman <ebiederm@...ssion.com> wrote:
> >>
> >> Well with 7 patches instead of 3 that was a little more than I thought
> >> I was going to send.
> >>
> >> However that does demonstrate what I am thinking, and I think most of
> >> the changes are reasonable at this point.
> >>
> >> I am very curious how synchronous this all is, because if this code
> >> is truly synchronous updating signalfd to handle this class of signal
> >> doesn't really make sense.
> >>
> >> If the code is not synchronous using force_sig is questionable.
> >>
> >> Eric W. Biederman (7):
> >> siginfo: Move si_trapno inside the union inside _si_fault
> >> signal: Implement SIL_FAULT_TRAPNO
> >> signal: Use dedicated helpers to send signals with si_trapno set
> >> signal: Remove __ARCH_SI_TRAPNO
> >> signal: Rename SIL_PERF_EVENT SIL_FAULT_PERF_EVENT for consistency
> >> signal: Factor force_sig_perf out of perf_sigtrap
> >> signal: Deliver all of the perf_data in si_perf
> >
> > Thank you for doing this so quickly -- it looks much cleaner. I'll
> > have a more detailed look next week and also run some tests myself.
> >
> > At a first glance, you've broken our tests in
> > tools/testing/selftests/perf_events/ -- needs a
> > s/si_perf/si_perf.data/, s/si_errno/si_perf.type/
>
> Yeah. I figured I did, but I couldn't figure out where the tests were
> and I didn't have a lot of time. I just wanted to get this out so we
> can do as much as reasonable before the ABI starts being actively used
> by userspace and we can't change it.
No worries, and agreed. I've run tools/testing/selftests/perf_events
tests on x86-64 (native + 32-bit compat), and compile-tested x86-32,
arm64, arm (with my static asserts), m68k, and sparc64. Some trivial
breakages, note comments in other patches.
With the trivial fixes this looks good to me. I'll happily retest v2
when you send it.
Thanks,
-- Marco
Powered by blists - more mailing lists