All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Peter Collingbourne <pcc@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Kostya Serebryany <kcc@google.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Dave Martin <Dave.Martin@arm.com>, Will Deacon <will@kernel.org>,
	Oleg Nesterov <oleg@redhat.com>,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	linux-api@vger.kernel.org, Helge Deller <deller@gmx.de>,
	David Spickett <david.spickett@linaro.org>
Subject: Re: [PATCH v17 0/3] arm64: expose FAR_EL1 tag bits in siginfo
Date: Tue, 17 Nov 2020 12:16:35 -0600	[thread overview]
Message-ID: <87a6vfdf24.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <cover.1605582887.git.pcc@google.com> (Peter Collingbourne's message of "Mon, 16 Nov 2020 19:17:23 -0800")

Peter Collingbourne <pcc@google.com> writes:

> The kernel currently clears the tag bits (i.e. bits 56-63) in the fault
> address exposed via siginfo.si_addr and sigcontext.fault_address. However,
> the tag bits may be needed by tools in order to accurately diagnose
> memory errors, such as HWASan [1] or future tools based on the Memory
> Tagging Extension (MTE).
>
> We should not stop clearing these bits in the existing fault address
> fields, because there may be existing userspace applications that are
> expecting the tag bits to be cleared. Instead, introduce a flag in
> sigaction.sa_flags, SA_EXPOSE_TAGBITS, and only expose the tag bits
> there if the signal handler has this flag set.
>
> In order to allow userspace to determine whether SA_EXPOSE_TAGBITS
> is supported, we first introduce a mechanism for userspace to detect
> kernel support for SA_* flags.
>
> These patches need to be applied on top of:
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git signal-for-v5.11

The first two patches look good and I have applied them.

While I was at it I added Link tags to the LKML postings to the entire
series.  I don't think anyone has merged my branch into another so it
should still be safe.

Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Peter Collingbourne <pcc@google.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Helge Deller <deller@gmx.de>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Oleg Nesterov <oleg@redhat.com>,
	linux-api@vger.kernel.org,
	"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
	Kostya Serebryany <kcc@google.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Andrey Konovalov <andreyknvl@google.com>,
	David Spickett <david.spickett@linaro.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Will Deacon <will@kernel.org>, Dave Martin <Dave.Martin@arm.com>,
	Evgenii Stepanov <eugenis@google.com>
Subject: Re: [PATCH v17 0/3] arm64: expose FAR_EL1 tag bits in siginfo
Date: Tue, 17 Nov 2020 12:16:35 -0600	[thread overview]
Message-ID: <87a6vfdf24.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <cover.1605582887.git.pcc@google.com> (Peter Collingbourne's message of "Mon, 16 Nov 2020 19:17:23 -0800")

Peter Collingbourne <pcc@google.com> writes:

> The kernel currently clears the tag bits (i.e. bits 56-63) in the fault
> address exposed via siginfo.si_addr and sigcontext.fault_address. However,
> the tag bits may be needed by tools in order to accurately diagnose
> memory errors, such as HWASan [1] or future tools based on the Memory
> Tagging Extension (MTE).
>
> We should not stop clearing these bits in the existing fault address
> fields, because there may be existing userspace applications that are
> expecting the tag bits to be cleared. Instead, introduce a flag in
> sigaction.sa_flags, SA_EXPOSE_TAGBITS, and only expose the tag bits
> there if the signal handler has this flag set.
>
> In order to allow userspace to determine whether SA_EXPOSE_TAGBITS
> is supported, we first introduce a mechanism for userspace to detect
> kernel support for SA_* flags.
>
> These patches need to be applied on top of:
> https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git signal-for-v5.11

The first two patches look good and I have applied them.

While I was at it I added Link tags to the LKML postings to the entire
series.  I don't think anyone has merged my branch into another so it
should still be safe.

Eric

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

  parent reply	other threads:[~2020-11-17 18:17 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-17  3:17 [PATCH v17 0/3] arm64: expose FAR_EL1 tag bits in siginfo Peter Collingbourne
2020-11-17  3:17 ` Peter Collingbourne
2020-11-17  3:17 ` [PATCH v17 1/3] arch: provide better documentation for the arch-specific SA_* flags Peter Collingbourne
2020-11-17  3:17   ` Peter Collingbourne
2020-11-17  3:17 ` [PATCH v17 2/3] signal: define the SA_UNSUPPORTED bit in sa_flags Peter Collingbourne
2020-11-17  3:17   ` Peter Collingbourne
2020-11-17  3:17 ` [PATCH v17 3/3] arm64: expose FAR_EL1 tag bits in siginfo Peter Collingbourne
2020-11-17  3:17   ` Peter Collingbourne
2020-11-17 13:39   ` Eric W. Biederman
2020-11-17 13:39     ` Eric W. Biederman
2020-11-17 19:51     ` Peter Collingbourne
2020-11-17 19:51       ` Peter Collingbourne
2020-11-17 18:16 ` Eric W. Biederman [this message]
2020-11-17 18:16   ` [PATCH v17 0/3] " Eric W. Biederman
2020-11-17 19:52   ` Peter Collingbourne
2020-11-17 19:52     ` Peter Collingbourne

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=87a6vfdf24.fsf@x220.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=Dave.Martin@arm.com \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=andreyknvl@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=david.spickett@linaro.org \
    --cc=deller@gmx.de \
    --cc=eugenis@google.com \
    --cc=kcc@google.com \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=oleg@redhat.com \
    --cc=pcc@google.com \
    --cc=vincenzo.frascino@arm.com \
    --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 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.