Date: Fri, 18 Jan 2013 09:41:10 +0900 (JST) From: Kohji Okuno <okuno.kohji@jp.panasonic.com> To: mlfbsd@ci0.org Cc: arm@freebsd.org, okuno.kohji@jp.panasonic.com Subject: Re: arm: cpu_switch() has bug? Message-ID: <20130118.094110.354966604231348329.okuno.kohji@jp.panasonic.com> In-Reply-To: <20130114145051.GA77459@ci0.org> References: <20130109.193945.561808600309975779.okuno.kohji@jp.panasonic.com> <50F1E092.1050905@bluezbox.com> <20130114145051.GA77459@ci0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi,
I'm sorry for my late response.
> I don't think it can happen, when we reach cpu_switch(), both the
> old thread and the new thread should be swapped in, so the kstack
> for both will be mapped, and we won't get a data abort when trying
> to access it.
I think I encountered that...
(0) Process A had already existed.
(1) Process B executed fork(). Then, the new thread is created.
If the kstack was allocated in new PDE(L1 table), the kstack was
mapped for Process B. But, it was not mapped for Process A.
(2) In this case, if the first access to this area for Process A was
a load from td_pcb in cpu_switch(), data_abort happend, I think.
# Of course, if this data_abort happens in other place, data_abort_handler()
# mapps correctly for Process B.
> I agree however it may come back to hunt us one day, so I'll see if
> I can not easily move that later in the process, after we switched
> the page tables.
Thanks,
Kohji Okuno
> Hi,
>
>> Hi,
>>
>> I have doubt if cpu_switch() of arm has a bug.
>>
>> In swtch.S:L.334, if newtd->td_pcb (this is in stack pointer for
>> kernel) has an address accessed first for the old(current) thread,
>> data_abort_fault may occur.
>>
>> When data_abort_fault occurs, data_abort_handler() tries to solve this
>> address from kernel_map. In this time, curthread and curpcb are
>> already updated in swtch.S:L.223-231. As this result,
>> data_abort_handler() will occur data_abort_fault in trap.c:L.301, again.
>>
>> When I check, in other CPUs, after updating the root pointer of MMU,
>> curthread and curpcb are updated.
>>
>> Would you please check this?
>>
>> Thanks,
>> Kohji Okuno
>
> I don't think it can happen, when we reach cpu_switch(), both the old thread
> and the new thread should be swapped in, so the kstack for both will be mapped,
> and we won't get a data abort when trying to access it.
> I agree however it may come back to hunt us one day, so I'll see if I can not
> easily move that later in the process, after we switched the page tables.
>
> Regards,
>
> Olivier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130118.094110.354966604231348329.okuno.kohji>