linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Liam Howlett <liam.howlett@oracle.com>
Cc: Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Julien Grall <julien.grall@arm.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	"linux-arm-kernel\@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"netdev\@vger.kernel.org" <netdev@vger.kernel.org>,
	"bpf\@vger.kernel.org" <bpf@vger.kernel.org>
Subject: Re: [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn() sometime returns the wrong signals
Date: Thu, 29 Apr 2021 12:52:31 -0500	[thread overview]
Message-ID: <m1czud6krk.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20210423200126.otleormmjh22joj3@revolver> (Liam Howlett's message of "Fri, 23 Apr 2021 20:03:17 +0000")


This entire discussion seems to come down to what are the expected
semantics of arm64_notify_segfault.  The use of this helper in
swp_handler and user_cache_main_handler is clearly for the purposes of
instruction emulation.  With instruction emulation it is a bug if the
emulated instruction behaves differently than a real instruction in
the same circumstances.

To properly fix the instruction emulation in arm64_notify_segfault it
looks to me that the proper solution is to call __do_page_fault or
handle_mm_fault the way do_page_fault does and them parse the VM_FAULT
code for which signal to generate.

I would probably rename arm64_notify_segfault to arm64_emulate_fault, or
possibly arm64_notify_fault while fixing the emulation so that it
can return different signals and so that people don't have to guess
what the function is supposed to do.

For the specific case of sigreturn and rt_sigreturn it looks sufficient
to use the fixed arm64_notify_segfault.  As it appears the that the code
is attempting to act like it is emulating an instruction that does not
exist.


There is an argument that sigreturn and rt_sigreturn do a poor enough
job of acting like the fault was caused by an instruction, as well
as failing for other reasons it might make more sense to just have
sigreturn and rt_sigreturn call "force_sig(SIGSEGV);"  But that seems
out of scope of what you are trying to fix right now so I would not
worry about it.

Eric

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2021-04-29 17:54 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20 16:50 [PATCH 1/3] arm64: armv8_deprecated: Fix swp_handler() signal generation Liam Howlett
2021-04-20 16:50 ` [PATCH 2/3] arm64: signal: sigreturn() and rt_sigreturn() sometime returns the wrong signals Liam Howlett
2021-04-22 12:48   ` Will Deacon
2021-04-22 18:22     ` Eric W. Biederman
2021-04-22 19:24       ` Liam Howlett
2021-04-23 18:17         ` Eric W. Biederman
2021-04-23 20:03           ` Liam Howlett
2021-04-29 17:52             ` Eric W. Biederman [this message]
2021-04-30 18:48               ` Liam Howlett
2021-04-30 19:57                 ` Eric W. Biederman
2021-04-30 20:31                   ` Liam Howlett
2021-04-20 16:50 ` [PATCH 3/3] arch/arm64/kernel/traps: Use find_vma_intersection() in traps for setting si_code Liam Howlett
2021-04-22 12:53   ` Will Deacon
2021-04-22 18:56     ` Liam Howlett
     [not found] ` <202104210515.VoF3YT1J-lkp@intel.com>
2021-04-21 15:47   ` [PATCH 1/3] arm64: armv8_deprecated: Fix swp_handler() signal generation Liam Howlett
2021-04-22 12:59 ` Will Deacon
2021-04-23  1:00   ` Liam Howlett

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=m1czud6krk.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=daniel@iogearbox.net \
    --cc=julien.grall@arm.com \
    --cc=liam.howlett@oracle.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=will@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 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).