Re: [PATCH v2] all arches, signal: Move restart_block to struct task_struct

[Andy Lutomirski]

On Wed, Dec 3, 2014 at 3:53 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> On Wed, 3 Dec 2014 15:38:29 -0800 Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>
>> Yes, exactly.
>>
>> >
>> > Spelling this out in the changelog would be useful for the ignorant and
>> > the forgetful ;)
>>
>> Want a new version, or will you fix it up yourself?
>>
>
> I think I can work that out.
>
> A couple of linux-next things to check:
>
> - arch/arm/include/asm/thread_info.h:arm_restart_block has
>   disappeared from the thread_info.
>
> - the reference to ti->restart_block in arch/arm/kernel/traps.c has
>   vanished.  I couldn't find anywhere where it was moved to.

This looks like it's:

commit 3f4aa45ceea5789a4aade536acc27f2e0d3da5e1
Author: Vladimir Murzin <vladimir.murzin@xxxxxxx>
Date:   Thu Nov 27 11:39:04 2014 +0100

    ARM: 8226/1: cacheflush: get rid of restarting block

    We cannot restart cacheflush safely if a process provides user-defined
    signal handler and signal is pending. In this case -EINTR is returned
    and it is expected that process re-invokes syscall. However, there are
    a few problems with that:
     * looks like nobody bothers checking return value from cacheflush
     * but if it did, we don't provide the restart address for that, so the
       process has to use the same range again
     * ...and again, what might lead to looping forever

    So, remove cacheflush restarting code and terminate cache flushing
    as early as fatal signal is pending.

If you haven't already done the obvious fixup (just drop the offending
hunk), I can send a new version.

-- 
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/