Re: [PATCH v2] all arches, signal: Move restart_block to struct task_struct
From: Andy Lutomirski
Date: Wed Dec 03 2014 - 19:01:58 EST
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:
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.
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/