Re: [PATCH v21 1/2] signal: define the SA_EXPOSE_TAGBITS bit in sa_flags

Catalin Marinas [off-list ref] writes:

On Mon, Nov 23, 2020 at 09:53:13AM -0600, Eric W. Biederman wrote:

quoted

Catalin Marinas [off-list ref] writes:

quoted

On Fri, Nov 20, 2020 at 05:22:58PM -0600, Eric W. Biederman wrote:

quoted

Peter Collingbourne [off-list ref] writes:

quoted

Architectures that support address tagging, such as arm64, may want to
expose fault address tag bits to the signal handler to help diagnose
memory errors. However, these bits have not been previously set,
and their presence may confuse unaware user applications. Therefore,
introduce a SA_EXPOSE_TAGBITS flag bit in sa_flags that a signal
handler may use to explicitly request that the bits are set.

The generic signal handler APIs expect to receive tagged addresses.
Architectures may specify how to untag addresses in the case where
SA_EXPOSE_TAGBITS is clear by defining the arch_untagged_si_addr
function.

Signed-off-by: Peter Collingbourne <redacted>
Acked-by: "Eric W. Biederman" <redacted>
Link: https://linux-review.googlesource.com/id/I16dd0ed2081f091fce97be0190cb8caa874c26cb
---
To be applied on top of:
https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git signal-for-v5.11

I have merged this first patch into signal-for-v5.11 and pushed
everything out to linux-next.

Thank you Eric. Assuming this branch won't be rebased, I'll apply the
arm64 changes on top (well, if you rebase it, just let me know so that
we don't end up with duplicate commits in mainline).

No.  I won't be rebasing it.  Not unless something serious problem shows
up, and at that point I will be more likely to apply a corrective change
on top that you can also grab.

Thanks Eric. During the merging window, I'll probably wait for you to
send the pull request first just to keep the arm64 diffstat simpler.

BTW, did you mean to base them on v5.10-rc3-391-g9cfd9c45994b or just
v5.10-rc3? It doesn't matter much as I'll generate the diffstat manually
anyway in my pull request as I have different bases in other branches.

Crap.  How did that happen?  I thought for certain I had based them on
v5.10-rc3.  Some random git commit is not a good base.  I think the
better part of valor is to just admit I goofed and not rebase even now.

It it would make your life easier I will be happy to rebase (onto
v5.10-rc3?).  I just wanted to get these into my tree so that we could
incremetnally commit to the changes that makes sense and be certain not
to loose them.

Eric

On Mon, Nov 23, 2020 at 10:17:20AM -0600, Eric W. Biederman wrote:

Catalin Marinas [off-list ref] writes:

quoted

On Mon, Nov 23, 2020 at 09:53:13AM -0600, Eric W. Biederman wrote:

quoted

Catalin Marinas [off-list ref] writes:

quoted

On Fri, Nov 20, 2020 at 05:22:58PM -0600, Eric W. Biederman wrote:

quoted

Peter Collingbourne [off-list ref] writes:

quoted

Architectures that support address tagging, such as arm64, may want to
expose fault address tag bits to the signal handler to help diagnose
memory errors. However, these bits have not been previously set,
and their presence may confuse unaware user applications. Therefore,
introduce a SA_EXPOSE_TAGBITS flag bit in sa_flags that a signal
handler may use to explicitly request that the bits are set.

The generic signal handler APIs expect to receive tagged addresses.
Architectures may specify how to untag addresses in the case where
SA_EXPOSE_TAGBITS is clear by defining the arch_untagged_si_addr
function.

Signed-off-by: Peter Collingbourne <redacted>
Acked-by: "Eric W. Biederman" <redacted>
Link: https://linux-review.googlesource.com/id/I16dd0ed2081f091fce97be0190cb8caa874c26cb
---
To be applied on top of:
https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git signal-for-v5.11

I have merged this first patch into signal-for-v5.11 and pushed
everything out to linux-next.

Thank you Eric. Assuming this branch won't be rebased, I'll apply the
arm64 changes on top (well, if you rebase it, just let me know so that
we don't end up with duplicate commits in mainline).

No.  I won't be rebasing it.  Not unless something serious problem shows
up, and at that point I will be more likely to apply a corrective change
on top that you can also grab.

Thanks Eric. During the merging window, I'll probably wait for you to
send the pull request first just to keep the arm64 diffstat simpler.

BTW, did you mean to base them on v5.10-rc3-391-g9cfd9c45994b or just
v5.10-rc3? It doesn't matter much as I'll generate the diffstat manually
anyway in my pull request as I have different bases in other branches.

Crap.  How did that happen?  I thought for certain I had based them on
v5.10-rc3.  Some random git commit is not a good base.  I think the
better part of valor is to just admit I goofed and not rebase even now.

It it would make your life easier I will be happy to rebase (onto
v5.10-rc3?).  I just wanted to get these into my tree so that we could
incremetnally commit to the changes that makes sense and be certain not
to loose them.

Please rebase onto -rc3 if there's not much hassle.

Thanks.

-- 
Catalin