[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <45E0D3FF-FEC1-4A70-8B2D-A941A35788EB@suse.de>
Date: Thu, 14 Jul 2016 10:01:50 +0200
From: Alexander Graf <agraf@...e.de>
To: Zheng Xu <Zheng.Xu@....com>
Cc: Steve Capper <Steve.Capper@....com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Mark Rutland <Mark.Rutland@....com>,
"mbrugger@...e.com" <mbrugger@...e.com>,
Catalin Marinas <Catalin.Marinas@....com>,
Will Deacon <Will.Deacon@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
Stuart Monteith <Stuart.Monteith@....com>
Subject: Re: [PATCH] arm64: Add config to limit user space to 47bits
> Am 14.07.2016 um 09:49 schrieb Zheng Xu <Zheng.Xu@....com>:
>
> Sorry, I might misunderstand the issue. I thought there are still issues with master.
>
> I saw that you've mentioned there are pointers to .rodata. And I only fixed the heap. So I am just worried if there can be issues with .rodata. If pointers to .rodata are not tagged and used as js objects, it should be fine.
Please don't top post on kernel mailing lists.
The old Spidermonkey (which is used by couchdb) has some string allocation optimization in jsstr.cpp that directly pregenerates js strings in .rodata at compile time. Just try to run couchdb on a 48bit va aarch64 system and it will fall apart.
Fixing mozjs master doesn't really help here, since couchdb requires the ancient spidermonkey 1.8.5. An alternative to fixing that old js implementation would obviously also be to move couchdb to mozjs master.
Alex
Powered by blists - more mailing lists