[RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai

[mark.rutland@arm.com (Mark Rutland)]

On Wed, Jan 13, 2016 at 12:00:30PM -0500, Christopher Covington wrote:
> On 01/13/2016 06:09 AM, Mark Rutland wrote:
> > On Wed, Jan 13, 2016 at 09:16:43AM +0800, Xishi Qiu wrote:
> >> In your issue, Tom Schuster said it sounds like bug 910845
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=910845
> > 
> > Controlled allocation as in this patch is probably a workable approach.
> > 
> > However, the arm64 kernel can be built with a very small VA range, and
> > the base chosen is outside of the minimum range. The kernel currently
> > goes as low as 36 bits (with 16K pages), though the architectural
> > minimum seems to be 24 currently.
> > 
> > To be safe for all configurations, I guess the best option is to
> > allocate as close to zero as possible, or to dynamically choose a base
> > depending on the VA range. I'm not sure how to correctly determine the
> > VA range from userspace, however.
> 
> Below is how I ended up determining TASK_SIZE for Checkpoint/Restore In
> Userspace (CRIU).
> 
> https://github.com/xemul/criu/commit/c0c0546c31e6df4932669f4740197bb830a24c8d

That's very scary. Any pages on a power of two boundary would get
unmapped, silently. That will corrupt data.

As above, the hard-code assumptions of a 39-bit minimum and a 48-bit
maximum are erroneous.

> If this is too hacky, my thought on a more proper interface would be to
> parallel how PAGE_SIZE is communicated. TASK_SIZE could be added to the
> ELF auxiliary vector, such that one could simply run `getconf TASK_SIZE`
> and sysconf(TASK_SIZE).

Assuming we don't have a reliable and safe mechanism already, something
like that sounds sensible to me.

Thanks,
Mark.