[PATCH] arm: add support for TIF_NOTIFY_SIGNAL

[Jens Axboe]

On 10/29/20 10:29 AM, Russell King - ARM Linux admin wrote:
> On Thu, Oct 29, 2020 at 10:11:07AM -0600, Jens Axboe wrote:
>> Wire up TIF_NOTIFY_SIGNAL handling for arm.
>>
>> Cc: linux-arm-kernel at lists.infradead.org
>> Signed-off-by: Jens Axboe <axboe at kernel.dk>
>> ---
>>
>> 5.11 has support queued up for TIF_NOTIFY_SIGNAL, see this posting
>> for details:
>>
>> https://lore.kernel.org/io-uring/20201026203230.386348-1-axboe@kernel.dk/
>>
>> As part of that work, I'm adding TIF_NOTIFY_SIGNAL support to all archs,
>> as that will enable a set of cleanups once all of them support it.
>>
>> This needs a bit of asm help, immediate doesn't like anything outside
>> of 1 byte, it seems. Any clues?
> 
> Correct - immediates take an 8 bit value shifted by an even number of
> bits.
> 
> I'm tempted to suggest that we simplify things by making TIF bits 0..15
> invoke do_work_pending() no matter what - which will require a comment
> in thread_info.h that all those bits will have that effect. The
> resulting assembly would be:
> 
>  	ldr	r1, [tsk, #TI_FLAGS]		@ re-check for syscall tracing
> -	tst	r1, #_TIF_SYSCALL_WORK | _TIF_WORK_MASK
> +	movs	r1, r1, lsl #16
> 
> which avoids the additional load caused by "ldr r2, =..."
> 
> It's not like we're desperate for bits here.

So renumber TIF bits that don't need to worry about do_work_pending() >
15 then? I agree, there's plenty of bits available, so seems reasonable
to me. But probably more work in terms of other bits being tested with
tstcurrently - at least when I looked, I could not find any of them I
could successfully remap from < 8 to > 8.

Any chance I can talk you into hacking that up?

> Further comments below if we don't decide on that approach...

Totally up to you, of course. I'm fine with shifting the bits around.

-- 
Jens Axboe