On Tue, Jun 21, 2011 at 14:45, Russell King - ARM Linux
wrote:
> On Tue, Jun 21, 2011 at 04:31:19PM +0800, TAO HU wrote:
>> We got an issue on our OMAP4 SMP system.
>> Looks like __und_user(), which was triggered by a user space
>> exception, got a page fault hence lead to might_sleep() failure.
>
On Tue, Jun 21, 2011 at 05:37:31PM +0800, TAO HU wrote:
> Hi, Russell
>
> Wouldn't it lead to oops with your patch?
The might_sleep() occurs because its trying to process the page fault.
We shouldn't be trying to do that with IRQs disabled - instead, we
should try to fix up the fault from kernel
Hi, Russell
Wouldn't it lead to oops with your patch?
We're trying avoid oops actually.
On Tue, Jun 21, 2011 at 5:15 PM, Russell King - ARM Linux
wrote:
> On Tue, Jun 21, 2011 at 04:31:19PM +0800, TAO HU wrote:
>> Hi, All
>>
>> We got an issue on our OMAP4 SMP system.
>> Looks like __und_user(),
On Tue, Jun 21, 2011 at 04:31:19PM +0800, TAO HU wrote:
> Hi, All
>
> We got an issue on our OMAP4 SMP system.
> Looks like __und_user(), which was triggered by a user space
> exception, got a page fault hence lead to might_sleep() failure.
Could you see whether this patch prevents the warning pl
Hi, All
We got an issue on our OMAP4 SMP system.
Looks like __und_user(), which was triggered by a user space
exception, got a page fault hence lead to might_sleep() failure.
Is it an race condition for dual-core system?
E.g. CPU0 exception->CPU0 __und_user()->CPU1 change MMU->CPU0 data abort
An
