[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8737ahwdgr.fsf@xmission.com>
Date: Fri, 30 Jun 2017 13:13:40 -0500
From: ebiederm@...ssion.com (Eric W. Biederman)
To: David Miller <davem@...emloft.net>
Cc: linux-kernel@...r.kernel.org, luto@...nel.org,
torvalds@...ux-foundation.org, viro@...iv.linux.org.uk,
oleg@...hat.com, avagin@...tuozzo.com, tglx@...utronix.de,
greg@...ah.com, avagin@...nvz.org, serge@...lyn.com,
xemul@...tuozzo.com, gorcunov@...nvz.org, peterz@...radead.org,
w@....eu, linux-arch@...r.kernel.org, linux-api@...r.kernel.org,
containers@...ts.linux-foundation.org, mtk.manpages@...il.com,
sparclinux@...r.kernel.org
Subject: Re: [PATCH 3/8] signal/sparc: Document a conflict with SI_USER with SIGFPE
David Miller <davem@...emloft.net> writes:
> From: "Eric W. Biederman" <ebiederm@...ssion.com>
> Date: Fri, 30 Jun 2017 07:39:01 -0500
>
>> diff --git a/arch/sparc/include/uapi/asm/siginfo.h b/arch/sparc/include/uapi/asm/siginfo.h
>> index 2d9b79ccaa50..6bc5c677e92f 100644
>> --- a/arch/sparc/include/uapi/asm/siginfo.h
>> +++ b/arch/sparc/include/uapi/asm/siginfo.h
>> @@ -17,6 +17,11 @@
>> #define SI_NOINFO 32767 /* no information in siginfo_t */
>>
>> /*
>> + * SIGFPE si_codes
>> + */
>> +#define FPE_FIXME (__SI_FAULT|0) /* Broken dup of SI_USER */
>> +
>> +/*
>> * SIGEMT si_codes
>> */
>> #define EMT_TAGOVF (__SI_FAULT|1) /* tag overflow */
>
> It's one thing to say FIXME in a comment in a kernel local header or
> C file.
>
> It's quite another to put this into the name of a macro which has
> visibility in the global user compilation namespace.
>
> I don't think you should really do that.
Good point.
Sigh. It almost fits because we did do something off in the uapi
exported to userspace and we don't have a header file definition for
that case.
Still. At this point arch/sparc/include/asm/siginfo.h is
a better fit for that definition.
I will respin and fix that.
I wish I knew what would make a better default floating point si_code on
sparc. Using 0 aka SI_USER is doesn't fit at all. Sigh.
Unfortunately I don't know the architecture well enough to even guess
what is going on in do_fpe_common when when no bits in fsr are set.
Any suggests for a better fix than just documenting that linux does
something weird and ill advised here?
Eric
Powered by blists - more mailing lists