From: ebiederm@xmission.com (Eric W. Biederman)
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Will Deacon <will.deacon@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [REVIEW][PATCH 00/15] signal/arm64: siginfo cleanups
Date: Thu, 27 Sep 2018 11:39:35 +0200 [thread overview]
Message-ID: <87ftxvs2i0.fsf@xmission.com> (raw)
In-Reply-To: <20180926173841.GD175719@arrakis.emea.arm.com> (Catalin Marinas's message of "Wed, 26 Sep 2018 18:38:42 +0100")
Catalin Marinas <catalin.marinas@arm.com> writes:
> Hi Eric,
>
> On Mon, Sep 24, 2018 at 11:07:05AM +0200, Eric W. Biederman wrote:
>> This is the continuation of my work to sort out signaling of exceptions
>> with siginfo. The old signal sending functions by taking a siginfo
>> argument resulted in their callers having to deal with the fiddly nature
>> of siginfo directly. In small numbers of callers this is not a problem
>> but in the number of callers in the kernel this resulted in cases
>> where fields were not initialized or improperly initialized before
>> being passed to userspace.
>>
>> To avoid having to worry about those issues I have added new signal
>> sending functions that each deal wit a different siginfo case. When
>> using these functions there is no room for the fiddly nature of siginfo
>> to cause mistakes.
>>
>> This is my set of changes to update arm64 to use those functions.
>> Along with some refactoring so those functions can be cleanly used.
>>
>> Folks please review and double check me. I think I have kept these
>> changes simple and obviously correct but I am human and mess up
>> sometimes.
>
> Nice clean-up, thanks. I started reviewing the patches, I should finish
> by tomorrow (I also applied them locally to give some testing).
>
>> After these patches have had a chance to be reviewed I plan to merge
>> them by my siginfo tree. If you would rather take them in the arm64
>> tree let me know. All of the prerequisites should have been merged
>> through Linus's tree several releases ago.
>
> Either way works for me. There is a trivial conflict in
> force_signal_inject() with the arm64 for-next/core tree so I could as
> well put them on top of this branch and send them during the 4.20
> merging window.
As long as there is a trivial conflict I would like to keep everything
in one tree.
There is a following patchset that manages to reduce the size of struct
siginfo in the kernel that I have also posted for review. With
everything in one tree I can make that change now, and just cross it off
my list of things to worry about.
Eric
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: linux-arm-kernel@lists.infradead.org
Subject: [REVIEW][PATCH 00/15] signal/arm64: siginfo cleanups
Date: Thu, 27 Sep 2018 11:39:35 +0200 [thread overview]
Message-ID: <87ftxvs2i0.fsf@xmission.com> (raw)
In-Reply-To: <20180926173841.GD175719@arrakis.emea.arm.com> (Catalin Marinas's message of "Wed, 26 Sep 2018 18:38:42 +0100")
Catalin Marinas <catalin.marinas@arm.com> writes:
> Hi Eric,
>
> On Mon, Sep 24, 2018 at 11:07:05AM +0200, Eric W. Biederman wrote:
>> This is the continuation of my work to sort out signaling of exceptions
>> with siginfo. The old signal sending functions by taking a siginfo
>> argument resulted in their callers having to deal with the fiddly nature
>> of siginfo directly. In small numbers of callers this is not a problem
>> but in the number of callers in the kernel this resulted in cases
>> where fields were not initialized or improperly initialized before
>> being passed to userspace.
>>
>> To avoid having to worry about those issues I have added new signal
>> sending functions that each deal wit a different siginfo case. When
>> using these functions there is no room for the fiddly nature of siginfo
>> to cause mistakes.
>>
>> This is my set of changes to update arm64 to use those functions.
>> Along with some refactoring so those functions can be cleanly used.
>>
>> Folks please review and double check me. I think I have kept these
>> changes simple and obviously correct but I am human and mess up
>> sometimes.
>
> Nice clean-up, thanks. I started reviewing the patches, I should finish
> by tomorrow (I also applied them locally to give some testing).
>
>> After these patches have had a chance to be reviewed I plan to merge
>> them by my siginfo tree. If you would rather take them in the arm64
>> tree let me know. All of the prerequisites should have been merged
>> through Linus's tree several releases ago.
>
> Either way works for me. There is a trivial conflict in
> force_signal_inject() with the arm64 for-next/core tree so I could as
> well put them on top of this branch and send them during the 4.20
> merging window.
As long as there is a trivial conflict I would like to keep everything
in one tree.
There is a following patchset that manages to reduce the size of struct
siginfo in the kernel that I have also posted for review. With
everything in one tree I can make that change now, and just cross it off
my list of things to worry about.
Eric
next prev parent reply other threads:[~2018-09-27 9:39 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-24 9:07 [REVIEW][PATCH 00/15] signal/arm64: siginfo cleanups Eric W. Biederman
2018-09-24 9:07 ` Eric W. Biederman
2018-09-24 9:07 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 01/15] signal/arm64: Push siginfo generation into arm64_notify_die Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 02/15] signal/arm64: Remove unneeded tsk parameter from arm64_force_sig_info Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 03/15] signal/arm64: Factor out arm64_show_signal " Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 04/15] signal/arm64: Factor set_thread_esr out of __do_user_fault Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 05/15] signal/arm64: Consolidate the two hwpoison cases in do_page_fault Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 06/15] signal/arm64: For clarity separate the 3 signal sending " Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 07/15] signal/arm64: Expand __do_user_fault and remove it Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 08/15] signal/arm64: Only perform one esr_to_fault_info call in do_page_fault Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 09/15] signal/arm64: Only call set_thread_esr once " Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 10/15] signal/arm64: Add and use arm64_force_sig_fault where appropriate Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 11/15] signal/arm64: Add and use arm64_force_sig_mceerr as appropriate Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 12/15] signal/arm64: Remove arm64_force_sig_info Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 13/15] signal/arm64: In ptrace_hbptriggered name the signal description string Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 14/15] signal/arm64: Add and use arm64_force_sig_ptrace_errno_trap Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-24 9:10 ` [REVIEW][PATCH 15/15] signal/arm64: Use send_sig_fault where appropriate Eric W. Biederman
2018-09-24 9:10 ` Eric W. Biederman
2018-09-26 17:38 ` [REVIEW][PATCH 00/15] signal/arm64: siginfo cleanups Catalin Marinas
2018-09-26 17:38 ` Catalin Marinas
2018-09-27 9:39 ` Eric W. Biederman [this message]
2018-09-27 9:39 ` Eric W. Biederman
2018-09-27 13:50 ` Catalin Marinas
2018-09-27 13:50 ` Catalin Marinas
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=87ftxvs2i0.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=will.deacon@arm.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 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.