From owner-freebsd-arm@FreeBSD.ORG Fri Jan 18 01:01:21 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DB09998C for ; Fri, 18 Jan 2013 01:01:21 +0000 (UTC) (envelope-from okuno.kohji@jp.panasonic.com) Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by mx1.freebsd.org (Postfix) with ESMTP id 432CFFB for ; Fri, 18 Jan 2013 01:01:20 +0000 (UTC) Received: from mail-gw.jp.panasonic.com ([157.8.1.157]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile14) with ESMTP id r0I0fLYf000655; Fri, 18 Jan 2013 09:41:21 +0900 (JST) Received: from epochmail.jp.panasonic.com ([157.8.1.130]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili15) with ESMTP id r0I0fLv17345; Fri, 18 Jan 2013 09:41:21 +0900 Received: by epochmail.jp.panasonic.com (8.12.11.20060308/3.7W/lomi17) id r0I0fLCm027089; Fri, 18 Jan 2013 09:41:21 +0900 Received: from localhost by lomi17.jp.panasonic.com (8.12.11.20060308/3.7W) with ESMTP id r0I0fLSR027057; Fri, 18 Jan 2013 09:41:21 +0900 Date: Fri, 18 Jan 2013 09:41:10 +0900 (JST) Message-Id: <20130118.094110.354966604231348329.okuno.kohji@jp.panasonic.com> To: mlfbsd@ci0.org Subject: Re: arm: cpu_switch() has bug? From: Kohji Okuno In-Reply-To: <20130114145051.GA77459@ci0.org> References: <20130109.193945.561808600309975779.okuno.kohji@jp.panasonic.com> <50F1E092.1050905@bluezbox.com> <20130114145051.GA77459@ci0.org> Organization: Panasonic Corporation X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: arm@freebsd.org, okuno.kohji@jp.panasonic.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jan 2013 01:01:21 -0000 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