linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Dave Martin <Dave.Martin@arm.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	"Dmitry V. Levin" <ldv@altlinux.org>,
	sparclinux <sparclinux@vger.kernel.org>,
	ppc-dev <linuxppc-dev@lists.ozlabs.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Russell King - ARM Linux <linux@armlinux.org.uk>,
	linux-arch <linux-arch@vger.kernel.org>
Subject: Re: [RFC PATCH 0/3] Dealing with the aliases of SI_USER
Date: Sun, 15 Apr 2018 21:03:32 -0500	[thread overview]
Message-ID: <87tvsb29hn.fsf@xmission.com> (raw)
In-Reply-To: <CA+55aFw1gmfFH1o+oWMo4TnU5hEczAOiY1g=eMxqYZmy9JqDYw@mail.gmail.com> (Linus Torvalds's message of "Sun, 15 Apr 2018 11:16:04 -0700")

Linus Torvalds <torvalds@linux-foundation.org> writes:

> (
>
> On Sun, Apr 15, 2018 at 8:56 AM, Eric W. Biederman
> <ebiederm@xmission.com> wrote:
>>
>> Would you consider the patchset below for -rc2?
>
> Ugh.

The point of this series is to squash the potential for regressions even
from the weird broken code that fills in fields for si_code 0 that do
not match SI_USER.

The copy_siginfo_to_user32 never handled that so we don't need to worry
about that.  All of the signals that abuse si_code 0 go through
force_sig_info so signalfd can not catch them.  Which means that only
copy_siginfo_to_user needs to be worried about.

Last time I was benchmarking I could not see a difference between
copying the entire siginfo and only a small part so I don't see
the point of optimizing now.

For an actual cleanup I intend to go farther than you are proposing and
convert everthing to the set of helper functions I have added to
kernel/signal.c force_sig_fault, force_sig_mceerr, force_sig_bnderr,
force_sig_pkuerr.

When I am done there will be maybe 5 instances of clear_siginfo outside
of those helper functions.  At which point I won't care if we remove
clear_siginfo and just use memset.  That is a real improvement
that looks something like: "105 files changed, 933 insertions(+), 1698 deletions(-)"
That is my end goal with all of this.

You complained to me about regressions and you are right with the
current handling of FPE_FIXME TRAP_FIXME the code is not bug compatible
with old versions of linux, and people have noticed.

What this patchset represents is the bare minimum needed to convert
copy_siginfo_to_user to a copy_to_user, and remove the possibility
of regressions.

To that end I need to ensure every struct siginfo in the entire
kernel is memset to 0.  A structure initializer is absolutely
not enough.  So I don't mind people thinking clear_siginfo is necessary.


To that end clear_siginfo where it does not take the size of
struct siginfo as a parameter is much less suceptible to typos,
and allows me to ensure every instance of struct siginfo is fully
initialized.

I fully intend to remove practically every instance of struct siginfo
from the architecture specific code, and use the aforementioned helpers.
The trouble is that some of the architecture code need refactoring
for that to happen.  Even your proposed init_siginfo can't be widely
used as a common pattern is to fill in siginfo partially in the
code with si_code and si_signo being filled in almost last.

So in short.  I intend to remove most of these clear_siginfo calls when
I remove the siginfos later.  This series is focused on making
copy_siginfo_to_user simple enough we don't need to use siginfo_layout,
and thus can be fully backwards compatibile with ourselves and we won't
need to worry about regressions.  I have aimed to keep this simple
enough we can merge this after -rc1 because we don't want regressions.

Eric

ps.  I intend to place this change first in my series wether or not it makes
it into -rc2 so that I can be certain we remove any possible regressions
in behavior on the buggy architectures.  Then I can take my time and
ensure the non-trivial changes of refactoring etc are done carefully so
I don't introduce other bugs.  I need that so I can sleep at night.

pps.  I can look at some of your other suggestions but cleverness leads
to regressions, and if you are going to complain at me harshly when I
have been being careful and taking things seriously I am not
particularly willing to take unnecessary chances.

  reply	other threads:[~2018-04-16  2:04 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-09 15:22 ppc compat v4.16 regression: sending SIGTRAP or SIGFPE via kill() returns wrong values in si_pid and si_uid Dmitry V. Levin
2018-04-12  1:34 ` sparc/ppc/arm compat siginfo ABI regressions: sending " Dmitry V. Levin
2018-04-12  1:45   ` Linus Torvalds
2018-04-12  9:58   ` Russell King - ARM Linux
2018-04-12 11:03     ` Dmitry V. Levin
2018-04-12 12:19       ` Russell King - ARM Linux
2018-04-12 12:49         ` Dmitry V. Levin
2018-04-12 13:14           ` Russell King - ARM Linux
2018-04-12 16:50             ` Linus Torvalds
2018-04-12 17:20               ` Russell King - ARM Linux
2018-04-12 17:22                 ` Linus Torvalds
2018-04-13  9:42                   ` Russell King - ARM Linux
2018-04-13 16:33                     ` Linus Torvalds
2018-04-13 17:08                       ` Dave Martin
2018-04-13 17:54                         ` Russell King - ARM Linux
2018-04-13 18:23                           ` Linus Torvalds
2018-04-13 18:45                             ` Dave Martin
2018-04-13 19:53                               ` Linus Torvalds
2018-04-15 13:12                                 ` Russell King - ARM Linux
2018-04-15 15:22                                   ` Eric W. Biederman
2018-04-15 15:56                                   ` [RFC PATCH 0/3] Dealing with the aliases of SI_USER Eric W. Biederman
2018-04-15 15:57                                     ` [RFC PATCH 1/3] signal: Ensure every siginfo we send has all bits initialized Eric W. Biederman
2018-04-17 13:23                                       ` Dave Martin
2018-04-17 19:37                                         ` Eric W. Biederman
2018-04-18 12:47                                           ` Dave Martin
2018-04-18 14:22                                             ` Eric W. Biederman
2018-04-19  8:26                                               ` Dave Martin
2018-04-15 15:58                                     ` [RFC PATCH 2/3] signal: Reduce copy_siginfo_to_user to just copy_to_user Eric W. Biederman
2018-04-15 15:59                                     ` [RFC PATCH 3/3] signal: Stop special casing TRAP_FIXME and FPE_FIXME in siginfo_layout Eric W. Biederman
2018-04-15 18:16                                     ` [RFC PATCH 0/3] Dealing with the aliases of SI_USER Linus Torvalds
2018-04-16  2:03                                       ` Eric W. Biederman [this message]
2018-04-18 17:58                                       ` Eric W. Biederman
2018-04-19  9:28                                       ` Dave Martin
2018-04-19 14:40                                         ` Eric W. Biederman
2018-04-13 18:35                           ` sparc/ppc/arm compat siginfo ABI regressions: sending SIGFPE via kill() returns wrong values in si_pid and si_uid Dave Martin
2018-04-13 18:50                             ` Russell King - ARM Linux
2018-04-13 18:56                               ` Dave Martin
2018-04-12 17:35               ` Dmitry V. Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87tvsb29hn.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=Dave.Martin@arm.com \
    --cc=ldv@altlinux.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).