Re: [PATCH] [1/4] Document hwpoison signal extensions

[Michael Kerrisk <mtk.manpages-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>]

Hi Andi,

On Mon, Jun 14, 2010 at 10:20 AM, Andi Kleen <andi-Vw/NltI1exuRpAAqCnN02g@public.gmane.org> wrote:
> On Mon, Jun 14, 2010 at 07:10:06AM +0200, Michael Kerrisk wrote:
>> >> * It's incomplete. If you compare against the corresponding
>> >> information in sigaction(2) [better pull the latest page from git for
>> >> this comparison], there is more information about which fields are set
>> >> by the various signals. Also, various siginfo_t fields (si_signo) are
>> >> missing from your table.
>> >
>> > Ok it could be listed.
>>
>> This was an example. I didn't check for all incomplete pieces.
>
> What else should be missing?

I'm not sure. si_signo was one that immediately jumped out at me. I
didn't exhaustively check. Another quick scan doesn't show anything
else obviously missing.

> I generated the table by looking at the trap handlers.
>
>> >> Likewise, it suggests that there is useful info in si_trapno, but
>> >> usually there is not. The entry for SIGKILL also seems strange.
>> >
>> > There is useful information in trapno for the signals where
>> > I listed it.
>>
>> So, there may be a problem here. sigaction.2 currently states
>>
>>                int      si_trapno;   /* Trap number that caused
>>                                         hardware-generated signal
>>                                         (unused on most architectures) */
>>
>> Is the last line true? Checking this, my reading of the source is that
>
> It's not true.
>
> I think it's also needed in some cases to figure out what exactly
> happened, although in most cases code gives this information.
>
>> si_trapno is only used on SPARC/MIPS/Alpha. (These are the
>> architectures that define __ARCH_SI_TRAPNO) Is that wrong? In
>> particular, x86 doesn't generally seem to set si_trapno, right?
>
> arch/x86/kernel/signal.c:162:             put_user_ex(current->thread.trap_no, &sc->trapno);

Okay -- so at this point I plead ignorance/blindness. These are the
things that confuse me (and I admit not being able to follow all the
kernel code convolutions here):

1. It's not clear to me how the information in sc->trapno then gets
into siginfo_t.si_trapno. The line you quote above appears to me to
result in a change in the ucontext structure given as the third
argument of the handler (but that's partly a guess).

2. In kernel/signal.c, we have:

#ifdef __ARCH_SI_TRAPNO
                err |= __put_user(from->si_trapno, &to->si_trapno);
#endif

But __ARCH_SI_TRAPNO appears not to be set on x86. In fact, only
SPARC, MIPS, and Alpha seem to set it.

3. In the siginfo_t structure that glibc provides to userspace, there
is the following:

#ifdef __ARCH_SI_TRAPNO
#define si_trapno       _sifields._sigfault._trapno
#endif

And on x86, this means that si_trapno is not in the structure.

What have I missed?

>> > Why is SIGKILL strange?
>>
>> I suspect that this should be a more general statement about signals
>> sent with kill(2), right? There's nothing special about SIGKILL in
>> this respect, AFAIK. By the way, the sigaction.2 page, has a statement
>> that covers this.
>
> It was more a comparison to non KILL signals, but ok
> you're right RT signals would need to be listed too.

In principle, I'd accept a patch like you suggest for sigaction.2 --
probably by the time we finish this discussion, I'll be able to write
it myself ;-).

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Author of "The Linux Programming Interface" http://blog.man7.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html