Date: Sun, 22 Mar 2015 08:13:49 +0900 (JST) From: Kohji Okuno <okuno.kohji@jp.panasonic.com> To: mlfbsd@ci0.org Cc: freebsd-arm@freebsd.org Subject: Re: pmap-v6.c has a bug? Message-ID: <20150322.081349.1435476998048335214.okuno.kohji@jp.panasonic.com> In-Reply-To: <20150321153322.GA22296@ci0.org> References: <20150321.085807.1477684572929578361.okuno.kohji@jp.panasonic.com> <20150321153322.GA22296@ci0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Olivier, From: Olivier Houchard <mlfbsd@ci0.org> Subject: Re: pmap-v6.c has a bug? Date: Sat, 21 Mar 2015 16:33:22 +0100 > 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 ! Thank you for your comment and commitment. Regards, Kohji Okuno
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150322.081349.1435476998048335214.okuno.kohji>