Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp2079924pxb; Mon, 8 Mar 2021 13:38:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJy1Rz9seeidAfInx6vAeDcvV9F/jWMXhbJ0w0zX/0Qf98qMEE5ISVGNERBXcUGA1TLC4rS+ X-Received: by 2002:aa7:cc94:: with SMTP id p20mr575535edt.353.1615239520668; Mon, 08 Mar 2021 13:38:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615239520; cv=none; d=google.com; s=arc-20160816; b=JN9w7rHvNT6coq5K9Sf9IECWczYtkLZ1NTAp8oHiIh8EvSbF5KyjvT3e15qxClhNeB Sp8PUrWaxwBuiaRpfUIvMRz+CQHwYEEQGYN6dnD+hqa6SbV2GFB+0lnlaA/A7VPhtyuh oKG30MjOS6OJwkg4FS+1KdpZ1A7UrUVMJp5XLxDO6FKAKRgC5git6kiFWjLiU7AAq6rU ZPUSl6zMwg5QM1u4bo8VCAsBKr+oNzWrTONs3HXHX5pePnV8rs+EAMzubO6wKUUo1gjp WaBXVJZnRscqL7yd+JPVYmbltL/Ry493jVnV7ZM3YTfMUd62kzbvgAreeobNyCs0JW6o /BQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=bz3zJSgx6mmXPFggnxmj99xFMiqQYB7dti5cBYcE25I=; b=lCoJ3arxYhTAR2tjsjcLXcojoRptK34J39MD8czsBbpNWf0Hhj5bue9tcTKoCL7TlO uvZVtWQUDLm481SnDxhj8oC3bJDwKnYQfdEJwTOAaHX7qTRlS7nhPTIXMZSItjXqUNQU JV61omKjKemC+/0l5biPLerba7hvrZo/fU9hGtW6ldhFb15kEpec+aaLM0Ofemb8I5pL PsDDwHHHl/pvj08sUC3V1We0LNY5IhPVpHcbsMGVqnShg+esoerE911FM1bGZ7WEHLty 6i3OMO9olusIhH5RzPXr40MRUxG2FQMOu6dFmNR6IoXhULTRUiKj/9XFXRm9Ysem0Ygr UjrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=P1Pjxowd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y23si7795864eds.278.2021.03.08.13.38.18; Mon, 08 Mar 2021 13:38:40 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@alien8.de header.s=dkim header.b=P1Pjxowd; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=alien8.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231542AbhCHVa7 (ORCPT + 99 others); Mon, 8 Mar 2021 16:30:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35988 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231129AbhCHVaq (ORCPT ); Mon, 8 Mar 2021 16:30:46 -0500 Received: from mail.skyhub.de (mail.skyhub.de [IPv6:2a01:4f8:190:11c2::b:1457]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 67CCBC06174A; Mon, 8 Mar 2021 13:30:46 -0800 (PST) Received: from zn.tnic (p200300ec2f05ab009ff41a2f0cc105b9.dip0.t-ipconnect.de [IPv6:2003:ec:2f05:ab00:9ff4:1a2f:cc1:5b9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id BA2ED1EC04DB; Mon, 8 Mar 2021 22:30:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1615239044; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=bz3zJSgx6mmXPFggnxmj99xFMiqQYB7dti5cBYcE25I=; b=P1PjxowdOmG2BuLcvLPuIOxwExwM12pTg1OrD853MltdrswmO/v/wBJ9GEMZNM8cv8IgMb 9ufjhFItbad1cN5WbN8t3AtDfW3cvnJfklnpG8Hy7siJwM2munjIQtxGCTD+R4ldPRIZW1 Ij7sqk7HpSlvmLKskAUeKwchbV0nLo8= Date: Mon, 8 Mar 2021 22:30:40 +0100 From: Borislav Petkov To: Yu-cheng Yu Cc: linux-man@vger.kernel.org, Alejandro Colomar , Michael Kerrisk , Andy Lutomirski , Dave Hansen , Florian Weimer , "H.J. Lu" , linux-kernel@vger.kernel.org, linux-api@vger.kenel.org Subject: Re: [PATCH 2/2] sigaction.2: wfix - Clarify si_addr description. Message-ID: <20210308212936.GD12548@zn.tnic> References: <20210226172634.26905-1-yu-cheng.yu@intel.com> <20210226172634.26905-3-yu-cheng.yu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210226172634.26905-3-yu-cheng.yu@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 26, 2021 at 09:26:34AM -0800, Yu-cheng Yu wrote: > SIGSEGV fills si_addr only for memory access faults. Add a note to clarify. > > Signed-off-by: Yu-cheng Yu > Cc: Alejandro Colomar > Cc: Michael Kerrisk > Cc: Andy Lutomirski > Cc: Borislav Petkov > Cc: Dave Hansen > Cc: Florian Weimer > Cc: "H.J. Lu" > Cc: linux-kernel@vger.kernel.org > Cc: linux-api@vger.kenel.org > 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. "... otherwise it is uninitialized." or "zeroed" or whatever... And I'm having trouble figuring out why do you need to clarify this? Because of this sentence: * SIGILL, SIGFPE, SIGSEGV, SIGBUS, and SIGTRAP fill in si_addr with the address of the fault. On some architectures, these signals also fill in the si_trapno field. ? 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. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette