Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1692302 > unrolled thread
| Started by | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| First post | 2017-07-20 02:20 +0200 |
| Last post | 2017-07-20 02:20 +0200 |
| Articles | 1 — 1 participant |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations "H. Peter Anvin" <hpa@zytor.com> - 2017-07-20 02:20 +0200
| From | "H. Peter Anvin" <hpa@zytor.com> |
|---|---|
| Date | 2017-07-20 02:20 +0200 |
| Subject | Re: [RFC 20/22] x86/relocs: Add option to generate 64-bit relocations |
| Message-ID | <u57ma-7KQ-7@gated-at.bofh.it> |
<cmetcalf@mellanox.com>,"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,Andrew Morton <akpm@linux-foundation.org>,Christopher Li <sparse@chrisli.org>,Dou Liyang <douly.fnst@cn.fujitsu.com>,Masahiro Yamada <yamada.masahiro@socionext.com>,Daniel Borkmann <daniel@iogearbox.net>,Markus Trippelsdorf <markus@trippelsdorf.de>,Peter Foley <pefoley2@pefoley.com>,Steven Rostedt <rostedt@goodmis.org>,Tim Chen <tim.c.chen@linux.intel.com>,Ard Biesheuvel <ard.biesheuvel@linaro.org>,Catalin Marinas <catalin.marinas@arm.com>,Matthew Wilcox <mawilcox@microsoft.com>,Michal Hocko <mhocko@suse.com>,Rob Landley <rob@landley.net>,Jiri Kosina <jkosina@suse.cz>,"H . J . Lu" <hjl.tools@gmail.com>,Paul Bolle <pebolle@tiscali.nl>,Baoquan He <bhe@redhat.com>,Daniel Micay <danielmicay@gmail.com>,the arch/x86 maintainers <x86@kernel.org>,linux-crypto@vger.kernel.org,LKML <linux-kernel@vger.kernel.org>,xen-devel@lists.xenproject.org,kvm list <kvm@vger.kernel.org>,Linux PM list <linux-pm@vger.kernel.org>,linux-arch <linux-arch@vger.kernel.org>,linux-sparse@vger.kernel.org,Kernel Hardening <kernel-hardening@lists.openwall.com> From: hpa@zytor.com Message-ID: <0EF6FAAA-A99C-4F0D-9E4A-AD25E93957FB@zytor.com> On July 19, 2017 4:25:56 PM PDT, Thomas Garnier <thgarnie@google.com> wrote: >On Wed, Jul 19, 2017 at 4:08 PM, H. Peter Anvin <hpa@zytor.com> wrote: >> On 07/19/17 15:47, Thomas Garnier wrote: >>> On Wed, Jul 19, 2017 at 3:33 PM, H. Peter Anvin <hpa@zytor.com> >wrote: >>>> On 07/18/17 15:33, Thomas Garnier wrote: >>>>> The x86 relocation tool generates a list of 32-bit signed >integers. There >>>>> was no need to use 64-bit integers because all addresses where >above the 2G >>>>> top of the memory. >>>>> >>>>> This change add a large-reloc option to generate 64-bit unsigned >integers. >>>>> It can be used when the kernel plan to go below the top 2G and >32-bit >>>>> integers are not enough. >>>> >>>> Why on Earth? This would only be necessary if the *kernel itself* >was >>>> more than 2G, which isn't going to happen for the forseeable >future. >>> >>> Because the relocation integer is an absolute address, not an offset >>> in the binary. Next iteration, I can try using a 32-bit offset for >>> everyone. >> >> It is an absolute address *as the kernel was originally linked*, for >> obvious reasons. > >Sure when the kernel was just above 0xffffffff80000000, it doesn't >work when it goes down to 0xffffffff00000000. That's why using an >offset might make more sense in general. > >> >> -hpa >> What is the motivation for changing the pre linked address at all? -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Back to top | Article view | linux.kernel
csiph-web