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: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andy Lutomirski <luto@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Oleg Nesterov <oleg@redhat.com>,
	Andrei Vagin <avagin@virtuozzo.com>,
	Thomas Gleixner <tglx@linutronix.de>, Greg KH <greg@kroah.com>,
	Andrey Vagin <avagin@openvz.org>, Serge Hallyn <serge@hallyn.com>,
	Pavel Emelyanov <xemul@virtuozzo.com>,
	Cyrill Gorcunov <gorcunov@openvz.org>,
	Peter Zijlstra <peterz@infradead.org>, Willy Tarreau <w@1wt.eu>,
	"linux-arch\@vger.kernel.org" <linux-arch@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	Linux Containers <containers@lists.linux-foundation.org>,
	Michael Kerrisk <mtk.manpages@gmail.com>
Subject: Simplfying copy_siginfo_to_user
Date: Sat, 22 Jul 2017 15:25:55 -0500	[thread overview]
Message-ID: <8760ek5ics.fsf_-_@xmission.com> (raw)
In-Reply-To: <878tjlbqpt.fsf@xmission.com> (Eric W. Biederman's message of "Tue, 18 Jul 2017 12:27:26 -0500")

ebiederm@xmission.com (Eric W. Biederman) writes:

> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> On Tue, Jul 18, 2017 at 7:06 AM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>> struct siginfo is a union and the kernel since 2.4 has been hiding a union
>>> tag in the high 16bits of si_code using the values:
>>> __SI_KILL
>>> __SI_TIMER
>>> __SI_POLL
>>> __SI_FAULT
>>> __SI_CHLD
>>> __SI_RT
>>> __SI_MESGQ
>>> __SI_SYS
>>>
>>> While this looks plausible on the surface, in practice this situation has
>>> not worked well.
>>
>> So on the whole I think we just need to do this, but the part I really
>> hate about this series is still this the siginfo_layout() part.
>>
>> I can well believe that it is needed for the compat case. siginfo is a
>> piece of crap crazy type, and re-ordering fields for compat is
>> something we are always going to have to do.
>>
>> But for the native case, the *only* reason we do not just copy the
>> siginfo as-is seems to be that it's just too big, due to other bad
>> design decisions in siginfo ("let's make sure it's big enough by
>> allocating 512 bytes for it).
>>
>> And afaik, absolutely nobody uses more than about 36 bytes of that
>> 512-byte _sifields union (and that one use is SIGILL with three
>> pointers and three integers and some padding.
>>
>> So why don't we just say "screw this idiotic layout crap, and just
>> unconditionally copy that much smaller maximum of bytes"?
>>
>> Leave that layout thing purely for compat handling.
>
> I completely agree.

So I just did some measurements to see what the performance impact is of
doing the simple and obvious thing of always copying the entire siginfo
around.  There is a fair amount of variation in my timings but for
the whole change I see about a 20ns increase in time taken to send
a signal with siginfo from the current process to the current process.
AKA timing kill(getpid(),...). 

I played with some clever changes such as limiting the copy to 48 bytes,
disabling the memset and the like but I could not get a strong enough
signal to say that any one change removed the extra or a clear part of
it 20ns.

Do we care about those 20ns for signal deliver?  I suspect from my
previous numbers that if Andy can get signal delivery to use sysret
it will more than make up for the small increase in cost here.

Eric

  reply	other threads:[~2017-07-22 20:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87lgot2loq.fsf@xmission.com>
     [not found] ` <87zid90vye.fsf_-_@xmission.com>
     [not found]   ` <20170615225426.GP31671@ZenIV.linux.org.uk>
     [not found]     ` <87poe4zrs1.fsf@xmission.com>
     [not found]       ` <CA+55aFxpv+gchzs7AYgSC8feAOV=B6mjFgBVm4Kx+83J2CNE-w@mail.gmail.com>
     [not found]         ` <87poe3vsa9.fsf@xmission.com>
     [not found]           ` <CALCETrX=SquyR8JZqHDNx=_FQKQo-0u9AxfdUwJs_hujVO2A-g@mail.gmail.com>
     [not found]             ` <87h8zfua59.fsf@xmission.com>
     [not found]               ` <CALCETrWPBn31Dye=81r2ZMainNOnDy5c_QxbU2uRjnJs0ie=Zg@mail.gmail.com>
     [not found]                 ` <87r2yjsuwl.fsf@xmission.com>
     [not found]                   ` <20170616191602.GA10675@1wt.eu>
2017-06-30 12:36                     ` [PATCH 0/8] signal: Fix sending signals with siginfo Eric W. Biederman
2017-07-18 14:04                       ` [PATCH v2 0/7] " Eric W. Biederman
2017-07-18 14:06                         ` [PATCH 1/7] signal/alpha: Document a conflict with SI_USER for SIGTRAP Eric W. Biederman
2017-07-18 18:22                           ` Richard Henderson
2017-07-18 14:06                         ` [PATCH 2/7] signal/ia64: Document a conflict with SI_USER with SIGFPE Eric W. Biederman
2017-07-18 14:06                         ` [PATCH 3/7] signal/sparc: " Eric W. Biederman
2017-07-18 14:06                         ` [PATCH 4/7] signal/mips: " Eric W. Biederman
2017-08-07 16:18                           ` Maciej W. Rozycki
2017-08-07 17:41                             ` Linus Torvalds
2017-08-07 19:55                               ` Ralf Baechle
2017-08-08 15:29                             ` Eric W. Biederman
2017-08-08 23:19                               ` Maciej W. Rozycki
2017-07-18 14:06                         ` [PATCH 5/7] signal/testing: Don't look for __SI_FAULT in userspace Eric W. Biederman
2017-07-18 14:06                         ` [PATCH 6/7] fcntl: Don't use ambiguous SIG_POLL si_codes Eric W. Biederman
2017-07-20 16:16                           ` Oleg Nesterov
2017-07-21  2:33                             ` Eric W. Biederman
2017-07-18 14:06                         ` [PATCH 7/7] signal: Remove kernel interal si_code magic Eric W. Biederman
2017-07-18 16:57                           ` Linus Torvalds
2017-07-18 17:27                             ` Eric W. Biederman
2017-07-22 20:25                               ` Eric W. Biederman [this message]
2017-07-24 17:43                                 ` Simplfying copy_siginfo_to_user Linus Torvalds
2017-07-24 19:01                                   ` Eric W. Biederman
2017-07-25  1:37                                   ` Al Viro
2017-07-31 16:37                                     ` Eric W. Biederman

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=8760ek5ics.fsf_-_@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=avagin@openvz.org \
    --cc=avagin@virtuozzo.com \
    --cc=containers@lists.linux-foundation.org \
    --cc=gorcunov@openvz.org \
    --cc=greg@kroah.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mtk.manpages@gmail.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=serge@hallyn.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=w@1wt.eu \
    --cc=xemul@virtuozzo.com \
    /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).