Linux signals

[David Holmes]

On 10/01/2021 7:10 am, Walt Drummond wrote:
> Context: I'm chasing down concerns that increasing the size of the
> kernel's definition of sigset_t would break userspace.  This only
> seems plausible if (1) on receipt of a signal user space tries to
> unwind or directly interpret the program stack frame or (2) the
> application uses a definition of sigset_t that is not derived from
> glibc.  From what I see here, neither of these are the case. The JVM
> inspects the state of the stack by looking at the ucontext_t structure
> passed to it from the kernel and it exclusively uses the POSIX signals
> APIs and the system libc.

Thanks for the info. I think we should be all good on that front.

David

> On Sat, Jan 9, 2021 at 5:10 AM David Holmes <david.holmes at oracle.com> wrote:
>>
>> Hi Walt,
>>
>> On 9/01/2021 2:22 am, Walt Drummond wrote:
>>> Hi David --
>>>
>>> Sorry, I've come to appreciate the confusion this causes; I can't tell
>>> if by 'thread' you mean a java thread or a POSIX thread. :)  To help
>>> punch through some of that, I'm going to be a bit pedantic, apologies
>>> in advance.
>>
>> In hotspot there is a 1:1 correspondence between a Java thread and
>> OS/Posix thread.
>>
>>> When the kernel delivers a signal to a process/thread (in the Linux
>>> sense of the term), it places some data on the process stack.  That
>>> data includes the parameters to the POSIX signal hander (signal
>>> number, a siginfo_t, and a ucontext_t).  Above that in the stack, the
>>> kernel also places FPU state and, on AMD64, extended state
>>> information.  My question is does the JVM directly inspect the JVM
>>> program stack when running the POSIX signal handler(s).  My current
>>> understanding is that it does not and only relies on the POSIX signals
>>> APIs and data structures from libc.
>>
>> As I stated before the JVM signal handler may inspect the stack, or it
>> may not, depending on the nature of the signal it is processing - crash
>> reporting can do a lot of things from the signal handler. You can see
>> the main signal handler here:
>>
>> https://github.com/openjdk/jdk/blob/master/src/hotspot/os/posix/signals_posix.cpp#L525
>>
>> What is the context for asking the question?
>>
>> Cheers,
>> David
>> -----
>>
>>
>>> Thanks, and sorry for the confusion.
>>>
>>> On Thu, Jan 7, 2021 at 8:30 PM David Holmes <david.holmes at oracle.com> wrote:
>>>>
>>>> Hi Walt,
>>>>
>>>> On 8/01/2021 7:18 am, Walt Drummond wrote:
>>>>> Hi --
>>>>>
>>>>> I'm chasing down some information about how the JVM interacts with
>>>>> signals on Linux.  Specifically I need to understand if any of the
>>>>> Java runtime attempts to directly inspect the system stack when in a
>>>>> POSIX signal handler.  My survey of the code doesn't seem to show any
>>>>> such uses, and in fact it looks like the JVM relies only on the POSIX
>>>>> signals API but I figured I'd ask the experts for confirmation.
>>>>
>>>> I'm not quite sure what you are asking with regards to the "system
>>>> stack". The hotspot signal handler does a range of things to try and
>>>> determine what the signal might mean - e.g. whether it is a true error
>>>> or an internal use of signals that we can recover from. That may involve
>>>> examining the thread stack.
>>>>
>>>> Cheers,
>>>> David
>>>> -----
>>>>
>>>>> Thanks.
>>>>> --Walt
>>>>>