Date: Sat, 21 Mar 2015 16:33:22 +0100 From: Olivier Houchard <mlfbsd@ci0.org> To: Kohji Okuno <okuno.kohji@jp.panasonic.com> Cc: freebsd-arm@freebsd.org Subject: Re: pmap-v6.c has a bug? Message-ID: <20150321153322.GA22296@ci0.org> In-Reply-To: <20150321.085807.1477684572929578361.okuno.kohji@jp.panasonic.com> References: <20150321.085807.1477684572929578361.okuno.kohji@jp.panasonic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 21, 2015 at 08:58:07AM +0900, Kohji Okuno wrote: > Hi All, > Hi, > We think that pmap_alloc_l2_bucket() in pmap-v6.c has a bug for a > race-condition. > > Would you refer to the following "(***)" lines? > > When a context(called A) decides to allocate pte after A checks l2 > and l2b->kva, A releases locks while A is allocating pte. In this > timing, another context(called B) may free the same l2 from > pmap_free_l2_bucket(). If this situation happens, l2b which is > allocated by A will be lost since this l2b isn't able to trace from > pmap. > > In this result, pmap_get_l2_bucket(pvchunk->pc_pmap, pventry->pv_va) > will return NULL, then it will cause a kernel panic by NULL access. > We saw this kind of panic in pmap_clearbits() and pmap_remove_all(). > > We add count-up l2_occupancy before unloking and count-down it after > locking. We think that this change can prevent wrong release of l2. > > What do you think about this? I think you're right ! I committed a variation of this as r280324. Thanks a lot ! Olivier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150321153322.GA22296>