LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Alexander Graf <agraf@suse.de>
To: Will Deacon <will.deacon@arm.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	"Catalin Marinas" <Catalin.Marinas@arm.com>,
	"Michael Matz" <matz@suse.de>, "Andreas Schwab" <schwab@suse.de>,
	"Suravee Suthikulanit" <suravee.suthikulpanit@amd.com>,
	"Dirk Müller" <dmueller@suse.com>
Subject: Re: [PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size
Date: Wed, 11 Mar 2015 06:24:16 -0500	[thread overview]
Message-ID: <550025E0.7030008@suse.de> (raw)
In-Reply-To: <20141208101026.GD27367@arm.com>



On 08.12.14 04:10, Will Deacon wrote:
> On Sat, Dec 06, 2014 at 05:23:59PM +0000, Alexander Graf wrote:
>> On 04.12.14 19:20, Will Deacon wrote:
>>> On Thu, Dec 04, 2014 at 03:46:33PM +0000, Alexander Graf wrote:
>>>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>>>> have everything 64k aligned. Armv7 binaries built with this binutils version
>>>> run successfully on an arm64 system.
>>>>
>>>> Since effectively there is now the chance to run armv7 code on arm64 even
>>>> with 64k page size, it doesn't make sense to block people from enabling
>>>> CONFIG_COMPAT on those configurations.
>>>
>>> Is there a distro available that is built with a recent enough binutils for
>>> this? I'd really like to run our regression tests to check that page-size
>>> assumptions don't exist for things like shm.
>>
>> So how much of a distro do you need? I could probably assemble a simple
>> very minimalistic rootfs with only bash if that helps.
> 
> I'd like to run LTP, so I'd probably need slightly more than that but I
> certainly don't need the whole world.

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?


Alex


Index: glibc-2.21/sysdeps/unix/sysv/linux/arm/mmap.S
===================================================================
--- glibc-2.21.orig/sysdeps/unix/sysv/linux/arm/mmap.S
+++ glibc-2.21/sysdeps/unix/sysv/linux/arm/mmap.S
@@ -36,7 +36,7 @@ ENTRY (__mmap)
 	/* convert offset to pages */
 	movs	ip, r5, lsl #20
 	bne	.Linval
-	mov	r5, r5, lsr #12
+	mov	r5, r5, lsr #16

 	/* do the syscall */
 	DO_CALL (mmap2, 0)
Index: glibc-2.21/sysdeps/unix/sysv/linux/arm/mmap64.S
===================================================================
--- glibc-2.21.orig/sysdeps/unix/sysv/linux/arm/mmap64.S
+++ glibc-2.21/sysdeps/unix/sysv/linux/arm/mmap64.S
@@ -43,9 +43,9 @@ ENTRY (__mmap64)
 	cfi_rel_offset (r4, 0)
 	cfi_remember_state
 	movs	r4, ip, lsl $20		@ check that offset is page-aligned
-	mov	ip, ip, lsr $12
+	mov	ip, ip, lsr $16
 	it	eq
-	movseq	r4, r5, lsr $12		@ check for overflow
+	movseq	r4, r5, lsr $16		@ check for overflow
 	bne	.Linval
 	ldr	r4, [sp, $8]		@ load fd
 	orr	r5, ip, r5, lsl $20	@ compose page offset

  parent reply	other threads:[~2015-03-11 11:24 UTC|newest]

Thread overview: 34+ 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 18:18 ` Laura Abbott
2014-12-04 18:20 ` Will Deacon
2014-12-04 23:37   ` Alexander Graf
2014-12-08 13:47     ` Michael Matz
2014-12-06 17:23   ` Alexander Graf
2014-12-08 10:10     ` Will Deacon
2014-12-08 10:47       ` Alexander Graf
2015-03-11 11:24       ` Alexander Graf [this message]
2015-03-11 12:43         ` Andreas Schwab
2015-03-11 12:47         ` Arnd Bergmann
2015-03-11 13:08           ` Alexander Graf
2015-03-11 13:35             ` Andreas Schwab
2015-03-11 13:51               ` Arnd Bergmann
2015-03-11 13:57                 ` Andreas Schwab
2015-03-11 15:44                   ` Alexander Graf
2015-03-11 16:09                     ` Andreas Schwab
2015-03-11 18:11                       ` Alexander Graf
2015-03-12  9:07                         ` [PATCH] arm64: fix implementation of mmap2 compat syscall Andreas Schwab
2015-03-16 14:16           ` [PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size Christopher Covington
2015-03-16 14:19             ` Arnd Bergmann
2014-12-04 21:15 ` Olof Johansson
2014-12-04 23:41   ` Alexander Graf
2014-12-04 23:48     ` Olof Johansson
2014-12-05 10:39       ` Arnd Bergmann
2014-12-05 11:05         ` Catalin Marinas
2014-12-05 12:24           ` Arnd Bergmann
2014-12-05 12:31             ` Catalin Marinas
2015-02-18 13:40           ` Christopher Covington
2014-12-05 12:06         ` Alexander Graf
2014-12-05 11:14   ` Catalin Marinas
2014-12-05 11:35     ` Will Deacon
2015-03-13  4:44     ` Jon Masters
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=550025E0.7030008@suse.de \
    --to=agraf@suse.de \
    --cc=Catalin.Marinas@arm.com \
    --cc=dmueller@suse.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matz@suse.de \
    --cc=schwab@suse.de \
    --cc=suravee.suthikulpanit@amd.com \
    --cc=will.deacon@arm.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).