[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120527200243.GC30052@kroah.com>
Date: Mon, 28 May 2012 05:02:43 +0900
From: Greg KH <gregkh@...uxfoundation.org>
To: Ben Hutchings <ben@...adent.org.uk>
Cc: "H. Peter Anvin" <hpa@...ux.intel.com>,
Jarkko Sakkinen <jarkko.sakkinen@....fi>,
linux-kernel@...r.kernel.org, stable@...r.kernel.org,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
alan@...rguk.ukuu.org.uk,
Jarkko Sakkinen <jarkko.sakkinen@...el.com>
Subject: Re: [ 76/94] x86, realmode: 16-bit real-mode code support for relocs
tool
On Sun, May 27, 2012 at 05:37:32PM +0100, Ben Hutchings wrote:
> On Sun, 2012-05-27 at 10:05 +0900, Greg KH wrote:
> > 3.3-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: "H. Peter Anvin" <hpa@...ux.intel.com>
> >
> > commit 6520fe5564acf07ade7b18a1272db1184835c487 upstream.
> >
> > A new option is added to the relocs tool called '--realmode'.
> > This option causes the generation of 16-bit segment relocations
> > and 32-bit linear relocations for the real-mode code. When
> > the real-mode code is moved to the low-memory during kernel
> > initialization, these relocation entries can be used to
> > relocate the code properly.
> >
> > In the assembly code 16-bit segment relocations must be relative
> > to the 'real_mode_seg' absolute symbol. Linear relocations must be
> > relative to a symbol prefixed with 'pa_'.
> >
> > 16-bit segment relocation is used to load cs:ip in 16-bit code.
> > Linear relocations are used in the 32-bit code for relocatable
> > data references. They are declared in the linker script of the
> > real-mode code.
> >
> > The relocs tool is moved to arch/x86/tools/relocs.c, and added new
> > target archscripts that can be used to build scripts needed building
> > an architecture. be compiled before building the arch/x86 tree.
> >
> > [ hpa: accelerating this because it detects invalid absolute
> > relocations, a serious bug in binutils 2.22.52.0.x which currently
> > produces bad kernels. ]
> >
> > [ jsakkine: applied against 3.3.7 ]
> [...]
>
> Are these relocs patches worth applying to 3.2.y as well? This one
> needs backporting (see attached). The following 5 can be cleanly
> cherry-picked after that.
I think so, as they have turned up problems in toolchains that people are
using to build the kernel incorrectly. But it's your call to add them
or not because they are pretty big.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists