All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org
Subject: Re: [REVIEW][PATCH 00/20] siginfo cleanups for x86
Date: Tue, 18 Sep 2018 23:10:06 +0200	[thread overview]
Message-ID: <87zhweh5qp.fsf@xmission.com> (raw)
In-Reply-To: <alpine.DEB.2.21.1809182253220.1468@nanos.tec.linutronix.de> (Thomas Gleixner's message of "Tue, 18 Sep 2018 22:55:08 +0200 (CEST)")

Thomas Gleixner <tglx@linutronix.de> writes:

> On Tue, 18 Sep 2018, Eric W. Biederman wrote:
>> I have been slowly going thought and reworking the arch specific
>> functions that generate siginfo.  The problems I have been addressing
>> is that using siginfo directly is error prone.  Using siginfo directly
>> makes it easy to leave fields initialized, and get confused about
>> which fields need to be filled in.
>> 
>> To address this I have added a series of helper functions to
>> kernel/signal.c, that are specific to exactly one use of struct siginfo
>> and take the parameters they need.
>> 
>> To use these functions the x86 signal handling needs some cleanups but
>> the net result appears to be less code that is easier to follow.
>> 
>> If while looking over these patches you see anything please let me know.
>
> Only nitpicks.
>
>> I don't think I missed something but to err is human.
>
> I went through the changes a couple of times, but failed to spot
> something. Was pleasure to read that set!
>
>> Likewise if you would like to merge these patches via the tip tree
>> let me know.  Otherwise after the review is complete I plan on merging
>> these into my siginfo tree.  At this point I believe all of the
>> prerequisite patches are merged so it should not make a difference.
>
> Works either way. Ingo?

If I manage to get through all of the architecture specific code I can
shrink the in-kernel version of struct siginfo.    So there is a slight
advantage to having it all in my tree.  But worst case I just have to
wait another cycle which doesn't look like a particularly long wait at
this point.

Eric

      reply	other threads:[~2018-09-18 21:10 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-18  0:03 [REVIEW][PATCH 00/20] siginfo cleanups for x86 Eric W. Biederman
2018-09-18  0:03 ` Eric W. Biederman
2018-09-18  0:05 ` [REVIEW][PATCH 01/20] signal: Simplify tracehook_report_syscall_exit Eric W. Biederman
2018-09-18 20:15   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 02/20] signal/x86: Inline fill_sigtrap_info in it's only caller send_sigtrap Eric W. Biederman
2018-09-18 20:16   ` Thomas Gleixner
2018-09-19  5:46   ` Christoph Hellwig
2018-09-19  6:46     ` Eric W. Biederman
2018-09-18  0:05 ` [REVIEW][PATCH 03/20] signal/x86: Move MCE error reporting out of force_sig_info_fault Eric W. Biederman
2018-09-18 20:19   ` Thomas Gleixner
2018-09-19 13:49     ` Eric W. Biederman
2018-09-18  0:05 ` [REVIEW][PATCH 04/20] signal/x86: Use send_sig_mceerr as apropriate Eric W. Biederman
2018-09-18 20:21   ` Thomas Gleixner
2018-10-01 13:04     ` Paolo Bonzini
2018-09-18  0:05 ` [REVIEW][PATCH 05/20] signal/x86: In trace_mpx_bounds_register_exception add __user annotations Eric W. Biederman
2018-09-18 20:22   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 06/20] signal/x86: Move mpx siginfo generation into do_bounds Eric W. Biederman
2018-09-18 20:25   ` Thomas Gleixner
2018-09-19  5:48   ` Christoph Hellwig
2018-09-19 13:52     ` Eric W. Biederman
2018-09-18  0:05 ` [REVIEW][PATCH 07/20] signal/x86/traps: Factor out show_signal Eric W. Biederman
2018-09-18 20:28   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 08/20] signal/x86/traps: Move setting error_code and trap_nr into do_trap_no_signal Eric W. Biederman
2018-09-18 20:33   ` Thomas Gleixner
2018-09-18 20:37     ` Thomas Gleixner
2018-09-21 12:45     ` Eric W. Biederman
2018-09-21 13:39       ` Eric W. Biederman
2018-09-18  0:05 ` [REVIEW][PATCH 09/20] signal/x86/traps: Use force_sig_bnderr Eric W. Biederman
2018-09-18 20:34   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 10/20] signal/x86/traps: Use force_sig instead of open coding it Eric W. Biederman
2018-09-18 20:34   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 11/20] signal/x86/traps: Simplify trap generation Eric W. Biederman
2018-09-18 20:37   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 12/20] signal/x86: Remove pkey parameter from bad_area_nosemaphore Eric W. Biederman
2018-09-18 20:44   ` Thomas Gleixner
2018-09-19 16:33     ` Dave Hansen
2018-09-21 12:34       ` Eric W. Biederman
2018-09-18  0:05 ` [REVIEW][PATCH 13/20] signal/x86: Remove the pkey parameter from do_sigbus Eric W. Biederman
2018-09-18 20:45   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 14/20] signal/x86: Remove pkey parameter from mm_fault_error Eric W. Biederman
2018-09-18 20:46   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 15/20] signal/x86: Don't compute pkey in __do_page_fault Eric W. Biederman
2018-09-18 20:46   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 16/20] signal/x86: Pass pkey not vma into __bad_area Eric W. Biederman
2018-09-18 20:48   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 17/20] signal/x86: Call force_sig_pkuerr from __bad_area_nosemaphore Eric W. Biederman
2018-09-18 20:50   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 18/20] signal/x86: Replace force_sig_info_fault with force_sig_fault Eric W. Biederman
2018-09-18 20:51   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 19/20] signal/x86: Pass pkey by value Eric W. Biederman
2018-09-18 20:52   ` Thomas Gleixner
2018-09-18  0:05 ` [REVIEW][PATCH 20/20] signal/x86: Use force_sig_fault where appropriate Eric W. Biederman
2018-09-18 20:53   ` Thomas Gleixner
2018-09-18 20:55 ` [REVIEW][PATCH 00/20] siginfo cleanups for x86 Thomas Gleixner
2018-09-18 21:10   ` Eric W. Biederman [this message]

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=87zhweh5qp.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.