From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754249AbcAMSrb (ORCPT ); Wed, 13 Jan 2016 13:47:31 -0500 Received: from foss.arm.com ([217.140.101.70]:42426 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753545AbcAMSr3 (ORCPT ); Wed, 13 Jan 2016 13:47:29 -0500 Date: Wed, 13 Jan 2016 18:47:07 +0000 From: Mark Rutland To: Christopher Covington Cc: Xishi Qiu , zhong jiang , Steve Capper , LKML , "linux-arm-kernel@lists.infradead.org" , catalin.marinas@arm.com Subject: Re: [RFC] arm64: failed when run the command: timedatectl set-timezone Asia/Shanghai Message-ID: <20160113184707.GN23370@leverpostej> References: <56946932.70601@huawei.com> <569473B2.3030909@huawei.com> <5695A57B.1060905@huawei.com> <20160113110900.GA23370@leverpostej> <569682AE.3020300@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <569682AE.3020300@codeaurora.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.