From: cov@codeaurora.org (Christopher Covington)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size
Date: Mon, 16 Mar 2015 10:16:37 -0400 [thread overview]
Message-ID: <5506E5C5.3000209@codeaurora.org> (raw)
In-Reply-To: <5396604.TRferrWZgF@wuerfel>
Hi,
On 03/11/2015 08:47 AM, Arnd Bergmann wrote:
> On Wednesday 11 March 2015 06:24:16 Alexander Graf wrote:
>> So after recompiling all of the distribution with newer binutils we now
>> have an openSUSE Factory tree that has 64k aligned 32bit binaries.
>>
>> Unfortunately however, the 32bit glibc has a bogus mmap() implementation
>> that hard codes 4k page size.
>>
>> With the patch below applied to glibc, I can successfully run 32bit user
>> space on Seattle with 64k PAGE_SIZE though. So I guess we'll need to fix
>> up glibc next.
>>
>> Do you know of anyone who's fluent enough in 32bit ARM assembly to
>> convert the hard coded assumptions in there to instead use a variable
>> that takes the actual host page size into account?
>
> I believe this is a kernel bug, and the kernel API for 32-bit emulation
> should always take the pgoff argument in 4KB units instead of PAGE_SIZE
> units, see the implementation of sys_mmap2 in
> arch/powerpc/kernel/sys_ppc32.c.
>
> All user space programs that call mmap2 still need to make sure that
> their arguments are PAGE_SIZE aligned, but the libc need not care
> about this here.
What is the correct behavior for /proc/pid/pagemap, /proc/kpagecount, and
/proc/kpageflags for a AArch32 process running on an AArch64 kernel with
non-4K translation granule? Actual page frame number or units-of-4K frame number?
Thanks,
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
WARNING: multiple messages have this Message-ID (diff)
From: Christopher Covington <cov@codeaurora.org>
To: Arnd Bergmann <arnd@arndb.de>, linux-arm-kernel@lists.infradead.org
Cc: "Catalin Marinas" <Catalin.Marinas@arm.com>,
"Michael Matz" <matz@suse.de>,
"Will Deacon" <will.deacon@arm.com>,
"Alexander Graf" <agraf@suse.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"Dirk Müller" <dmueller@suse.com>,
"Suravee Suthikulanit" <suravee.suthikulpanit@amd.com>,
"Andreas Schwab" <schwab@suse.de>
Subject: Re: [PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size
Date: Mon, 16 Mar 2015 10:16:37 -0400 [thread overview]
Message-ID: <5506E5C5.3000209@codeaurora.org> (raw)
In-Reply-To: <5396604.TRferrWZgF@wuerfel>
Hi,
On 03/11/2015 08:47 AM, Arnd Bergmann wrote:
> On Wednesday 11 March 2015 06:24:16 Alexander Graf wrote:
>> So after recompiling all of the distribution with newer binutils we now
>> have an openSUSE Factory tree that has 64k aligned 32bit binaries.
>>
>> Unfortunately however, the 32bit glibc has a bogus mmap() implementation
>> that hard codes 4k page size.
>>
>> With the patch below applied to glibc, I can successfully run 32bit user
>> space on Seattle with 64k PAGE_SIZE though. So I guess we'll need to fix
>> up glibc next.
>>
>> Do you know of anyone who's fluent enough in 32bit ARM assembly to
>> convert the hard coded assumptions in there to instead use a variable
>> that takes the actual host page size into account?
>
> I believe this is a kernel bug, and the kernel API for 32-bit emulation
> should always take the pgoff argument in 4KB units instead of PAGE_SIZE
> units, see the implementation of sys_mmap2 in
> arch/powerpc/kernel/sys_ppc32.c.
>
> All user space programs that call mmap2 still need to make sure that
> their arguments are PAGE_SIZE aligned, but the libc need not care
> about this here.
What is the correct behavior for /proc/pid/pagemap, /proc/kpagecount, and
/proc/kpageflags for a AArch32 process running on an AArch64 kernel with
non-4K translation granule? Actual page frame number or units-of-4K frame number?
Thanks,
Chris
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
next prev parent reply other threads:[~2015-03-16 14:16 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 15:46 [PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size Alexander Graf
2014-12-04 15:46 ` Alexander Graf
2014-12-04 18:18 ` Laura Abbott
2014-12-04 18:18 ` Laura Abbott
2014-12-04 18:20 ` Will Deacon
2014-12-04 18:20 ` Will Deacon
2014-12-04 23:37 ` Alexander Graf
2014-12-04 23:37 ` Alexander Graf
2014-12-08 13:47 ` Michael Matz
2014-12-08 13:47 ` Michael Matz
2014-12-06 17:23 ` Alexander Graf
2014-12-06 17:23 ` Alexander Graf
2014-12-08 10:10 ` Will Deacon
2014-12-08 10:10 ` Will Deacon
2014-12-08 10:47 ` Alexander Graf
2014-12-08 10:47 ` Alexander Graf
2015-03-11 11:24 ` Alexander Graf
2015-03-11 11:24 ` Alexander Graf
2015-03-11 12:43 ` Andreas Schwab
2015-03-11 12:43 ` Andreas Schwab
2015-03-11 12:47 ` Arnd Bergmann
2015-03-11 12:47 ` Arnd Bergmann
2015-03-11 13:08 ` Alexander Graf
2015-03-11 13:08 ` Alexander Graf
2015-03-11 13:35 ` Andreas Schwab
2015-03-11 13:35 ` Andreas Schwab
2015-03-11 13:51 ` Arnd Bergmann
2015-03-11 13:51 ` Arnd Bergmann
2015-03-11 13:57 ` Andreas Schwab
2015-03-11 13:57 ` Andreas Schwab
2015-03-11 15:44 ` Alexander Graf
2015-03-11 15:44 ` Alexander Graf
2015-03-11 16:09 ` Andreas Schwab
2015-03-11 16:09 ` Andreas Schwab
2015-03-11 18:11 ` Alexander Graf
2015-03-11 18:11 ` Alexander Graf
2015-03-12 9:07 ` [PATCH] arm64: fix implementation of mmap2 compat syscall Andreas Schwab
2015-03-12 9:07 ` Andreas Schwab
2015-03-16 14:16 ` Christopher Covington [this message]
2015-03-16 14:16 ` [PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size Christopher Covington
2015-03-16 14:19 ` Arnd Bergmann
2015-03-16 14:19 ` Arnd Bergmann
2014-12-04 21:15 ` Olof Johansson
2014-12-04 21:15 ` Olof Johansson
2014-12-04 23:41 ` Alexander Graf
2014-12-04 23:41 ` Alexander Graf
2014-12-04 23:48 ` Olof Johansson
2014-12-04 23:48 ` Olof Johansson
2014-12-05 10:39 ` Arnd Bergmann
2014-12-05 10:39 ` Arnd Bergmann
2014-12-05 11:05 ` Catalin Marinas
2014-12-05 11:05 ` Catalin Marinas
2014-12-05 12:24 ` Arnd Bergmann
2014-12-05 12:24 ` Arnd Bergmann
2014-12-05 12:31 ` Catalin Marinas
2014-12-05 12:31 ` Catalin Marinas
2015-02-18 13:40 ` Christopher Covington
2015-02-18 13:40 ` Christopher Covington
2014-12-05 12:06 ` Alexander Graf
2014-12-05 12:06 ` Alexander Graf
2014-12-05 11:14 ` Catalin Marinas
2014-12-05 11:14 ` Catalin Marinas
2014-12-05 11:35 ` Will Deacon
2014-12-05 11:35 ` Will Deacon
2015-03-13 4:44 ` Jon Masters
2015-03-13 4:44 ` Jon Masters
2014-12-05 16:35 ` Liviu Dudau
2014-12-05 16:35 ` Liviu Dudau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5506E5C5.3000209@codeaurora.org \
--to=cov@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.