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-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
