Message-ID: <87shavt08c.fsf@xmission.com>
Date:   Wed, 24 Jan 2018 15:28:51 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Russell King - ARM Linux <linux@...linux.org.uk>
Cc:     Dave Martin <Dave.Martin@....com>, linux-arch@...r.kernel.org,
        Arnd Bergmann <arnd@...db.de>, Nicolas Pitre <nico@...aro.org>,
        Tony Lindgren <tony@...mide.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Tyler Baicar <tbaicar@...eaurora.org>,
        Will Deacon <will.deacon@....com>,
        linux-kernel@...r.kernel.org, Oleg Nesterov <oleg@...hat.com>,
        James Morse <james.morse@....com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Olof Johansson <olof@...om.net>,
        Santosh Shilimkar <santosh.shilimkar@...com>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH 07/11] signal/arm64: Document conflicts with SI_USER and SIGFPE, SIGTRAP, SIGBUS

Russell King - ARM Linux <linux@...linux.org.uk> writes:

> On Wed, Jan 17, 2018 at 10:45:10AM -0600, Eric W. Biederman wrote:
>> Russell King - ARM Linux <linux@...linux.org.uk> writes:
>> >From your description there still seems to be an association with an
>> instruction so I don't know if I would really call the signal
>> asynchronous.  It sounds like the exception is delayed and not
>> asynchronous.
>
> Traps can only be passed from ARM coprocessors by a coprocessor refusing
> to execute an instruction.  That's what happens in this case - the VFP
> gets offered an instruction to execute.  It accepts it, and the CPU
> continues, leaving the VFP to execute its instruction independently.  If
> this instruction generates an error, then nothing happens at this point.
>
> That error remains pending until the CPU offers the coprocessor the next
> VFP instruction, which it refuses.  That causes an undefined instruction
> exception, and we trap into the kernel VFP code which reads the VFP
> status and works out what needs to be done.
>
> What this means is that if you execute a VFP instruction, wait 10 minutes
> and then execute another VFP instruction, if the first VFP instruction
> raised an exception, you'll get to hear about it 10 minutes later.
>
> You can use whatever weasel words you want to describe that situation,
> my choice is "asynchronous", your choice is "delayed".  However, it is
> clearly not "synchronous", and arguing that we should report something
> synchronously that is not reported to _us_ synchronously (where
> synchronous means "at the same time") is IMHO daft.
>
> So, let's take an example:
>
> 	installs SIGFPE handler
> 	..fp instructions.. one of which raises an exception
> 	returns to main loop
> 	main loop blocks all signals while it sets stuff up
> 	calls ppoll()
>
> In the synchronous SIGFPE delivery case, the SIGFPE handler will be
> called when the exception is generated in the FP code, and delivered
> at that time.  The fact that the main loop blocks all signals happens
> later, so the users handler gets called as one expects.
>
> In the VFP case, however, the FP instructions towards the end may not
> end up causing the exception to be signalled until sometime later,
> and as I've already explained, that may be the result of a C library
> function accessing the VFP registers.  This could well end up trying
> to deliver the SIGFPE while signals are blocked, and we get
> drastically different behaviour if force_sig_info() is used.
>
> In the VFP case, if force_sig_info() is used, the program gets killed
> at this point.  In the non-VFP case, the program's signal handler was
> called.
>
> Using send_sig_info() results in the already delayed or asynchronous
> signal being held off until ppoll() drops the blocking, at which point
> the signal is delivered, the program handles it in its handler, and
> the program continues to run.
>
> So
> 1. non-VFP case, program doesn't get killed but gets the opportunity
>    to handle the signal.
> 2. VFP case with send_sig_info, program doesn't get killed but gets
>    the opportunity to handle the signal.
> 3. VFP case with force_sig_info, the program gets killed and dumps
>    core.
>
> Which one of these results in a big change of behaviour in your
> opinion?

I want to apologize for the disagreement.  In part of my due diligence
for cleaning up the signal handling I am introducing some helpers for
generating siginfo.  I decided to ask which kind of helpers should I
introduce.

Very basic generic helpers that just wrap the current functionality
today.  Or some slightly smarter helpers that solve some other problems
as well.  After consideration I am shelving the smarter helpers for now,
as the need to introduce the helpers universally is strong, so that I
can guarantee struct siginfo is always fully initialized before being
passed to userspace.

Given the choice between force_sig_info and send_sig_info I agree that
send_sig_info is the right choice for signals that can be ignored.

The problem I was focusing on is the problem where force_sig_info and
send_sig_info can be tricked into causing the instruction pointer to
point to the wrong instruction (even when the signal is not blocked),
due to the delivery of another signal.

So I was wondering if in practice we could introduce a singal delivery
function that would operation synchronously and would solve the
instruction pointer problem.

It looks to me like this location on arm where we are using
send_sig_info is a clear candidate for such a function as long as it has
a mode where you can say deliverly the signal like send_sig_info if the
signal is blocked.

Still like I said such a smarter helper is not the priority and I don't
intend any semantic changes when I introduce helpers into the signal
deliver path.  Just fewer places initializing struct siginfo.

Eric

Powered by blists - more mailing lists