Re: [GIT PULL] siginfo: ABI fixes for v5.13-rc2

ebiederm@xmission.com (Eric W. Biederman) writes:

Linus Torvalds [off-list ref] writes:

quoted

On Thu, May 13, 2021 at 9:55 PM Eric W. Biederman [off-list ref] wrote:

quoted

Please pull the for-v5.13-rc2 branch from the git tree:

I really don't like this tree.

The immediate cause for "no" is the silly

 #if IS_ENABLED(CONFIG_SPARC)

and

 #if IS_ENABLED(CONFIG_ALPHA)

code in kernel/signal.c. It has absolutely zero business being there,
when those architectures have a perfectly fine arch/*/kernel/signal.c
file where that code would make much more sense *WITHOUT* any odd
preprocessor games.

The code is generic it just happens those functions are only used on
sparc and alpha.  Further I really want to make filling out siginfo_t
happen in dedicated functions as much as possible in kernel/signal.c.
The probably of getting it wrong without a helper functions is very
strong.  As the code I am fixing demonstrates.

The IS_ENABLED(arch) is mostly there so we can delete the code if/when
the architectures are retired in another decade or so.

There is also the question of why alpha allows userspace to block
SIGFPE.

If it turns out that alpha is just silly by allowing synchronous
exceptions to be blocked, then the code really becomes generic and
shared shared between sparc and alpha.

Which is really why the code does not make sense in some architecture
specific version of signal.c.  That and the fact the two functions
are almost identical.

If you want I can remove the #ifdefs and we can take up slightly more
space until someone implements -ffunction-sections.

Do you know if alpha will be stuck triggering the same floating point
error if the SIGFPE is blocked or can alpha somehow continue past it?

If alpha using send_sig instead of force_sig is historical and does not
reflect the reality of the hardware alpha can be converted and several
of the send_sig variants can be removed.  Otherwise alpha remains the
odd man out, and the code can remain until all of the alpha hardware
dies.  (I don't think anyone is manufacturing alpha hardware anymore).

I would look it up but I have lost access to whatever alpha
documentation I had.

Eric