Re: [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description.

Started by Yu, Yu-cheng on Mar 8, 2021 · 2 messages from 2 authors · Last reply Mar 9, 2021

open the first message on its own page

Message details and related content
On 3/8/2021 1:30 PM, Borislav Petkov wrote:
On Fri, Feb 26, 2021 at 09:26:34AM -0800, Yu-cheng Yu wrote:
quoted
SIGSEGV fills si_addr only for memory access faults.  Add a note to clarify.

Signed-off-by: Yu-cheng Yu <redacted>
Cc: Alejandro Colomar <redacted>
Cc: Michael Kerrisk <redacted>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Florian Weimer <redacted>
Cc: "H.J. Lu" <redacted>
Cc: <redacted>
Cc: <redacted>
Link: https://lore.kernel.org/linux-api/20210217222730.15819-7-yu-cheng.yu@intel.com/
---
  man2/sigaction.2 | 7 ++++++-
  1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/man2/sigaction.2 b/man2/sigaction.2
index 49a30f11e..bea884a23 100644
--- a/man2/sigaction.2
+++ b/man2/sigaction.2
@@ -467,7 +467,7 @@ and
  .BR SIGTRAP
  fill in
  .I si_addr
-with the address of the fault.
+with the address of the fault (see notes).
  On some architectures,
  these signals also fill in the
  .I si_trapno
@@ -955,6 +955,11 @@ It is not possible to block
  .IR sa_mask ).
  Attempts to do so are silently ignored.
  .PP
+In a
+.B SIGSEGV,
+if the fault is a memory access fault, si_addr is filled with the address
+causing the fault, otherwise it is not filled.

11 more quoted lines

I think the sentence above is vague, but probably for the reason that each arch is different.  Maybe this patch is unnecessary and can be dropped?
If so, did you audit all architectures whether si_addr is populated only
on memory access faults or is this something POSIX dictates or what's
up? Because the sigaction(2) manpage is arch-agnostic and this is a
rather strong assertion.

What am I missing?

Thx.
Message details and related content
On Mon, Mar 08, 2021 at 01:46:07PM -0800, Yu, Yu-cheng wrote:
I think the sentence above is vague, but probably for the reason that each
arch is different.  Maybe this patch is unnecessary and can be dropped?
Maybe.

If you want to clarify it, you should audit every arch. But what
would that bring? IOW, is it that important to specify when si_addr
is populated and when not...? I don't know of an example but I'm
no userspace programmer anyway, to know when this info would be
beneficial...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help