[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/54994: Critical bug in uarea_poolpage_alloc() for archs with __HAVE_CPU_UAREA_ROUTINES
The following reply was made to PR kern/54994; it has been noted by GNATS.
From: Jason Thorpe <thorpej%me.com@localhost>
Subject: Re: kern/54994: Critical bug in uarea_poolpage_alloc() for archs with
Date: Fri, 21 Feb 2020 07:52:45 -0800
> On Feb 21, 2020, at 3:15 AM, rokuyama.rk%gmail.com@localhost wrote:
> Since low-level routines for these archs assume physically contignous
> u-area, this results in a catastrophe; pages happens to follow the 1st
> page of u-area will be randomly overwritten.
I don't have an Alpha handy to run your test case, but I don't think =
this is catastrophic on all platforms. As far as I can recall, the =
Alpha does not actually require a physically contiguous u-area. MIPS is =
the same in this regard (although it probably need to make sure it keeps =
UPAGES wired TLB entries for the u-area when the direct-mapping isn't =
used ... it certainly used to do that). The comment in the Alpha's =
cpu_uarea_alloc() is merely there to call out the requirement in order =
to be able to use the direct-mapped region.
Oh, turns out MIPS already has much more complex rules for when the =
direct-mapped region is used, so I suspect it's fine as well. I haven't =
audited the rest.
In any case, the short answer is: Only an issue if the PA of the u-area =
is provided to the CPU, not an issue if it does everything with the VA =
of the u-area.
Main Index |
Thread Index |