[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 4 Jan 2016 22:07:43 +0000
From: Russell King - ARM Linux <linux@....linux.org.uk>
To: Kees Cook <keescook@...omium.org>
Cc: Tony Lindgren <tony@...mide.com>,
Nicolas Pitre <nicolas.pitre@...aro.org>,
Laura Abbott <labbott@...hat.com>, Arnd Bergmann <arnd@...db.de>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
LKML <linux-kernel@...r.kernel.org>, Linux-MM <linux-mm@...ck.org>,
"kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
Laura Abbott <labbott@...oraproject.org>
Subject: Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA
On Mon, Jan 04, 2016 at 12:34:28PM -0800, Kees Cook wrote:
> On Wed, Dec 23, 2015 at 4:34 PM, Russell King - ARM Linux
> <linux@....linux.org.uk> wrote:
> > On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote:
> >> * Nicolas Pitre <nicolas.pitre@...aro.org> [151223 13:45]:
> >> > We fixed a bunch of similar issues where code was located in the .data
> >> > section for ease of use from assembly code. See commit b4e61537 and
> >> > d0776aff for example.
> >>
> >> Thanks hey some assembly fun for the holidays :) I also need to check what
> >> all gets relocated to SRAM here.
> >>
> >> In any case, seems like the $subject patch is too intrusive for v4.5 at
> >> this point.
> >
> > Given Christmas and an unknown time between that and the merge window
> > actually opening, I decided Tuesday would be the last day I take any
> > patches into my tree - and today would be the day that I drop anything
> > that causes problems.
> >
> > So, I've already dropped this, so tomorrow's linux-next should not have
> > this change.
> >
> > You'll still see breakage if people enable RODATA though, but that's no
> > different from previous kernels.
>
> Ugh, sorry for the breakage.
>
> Should this patch stay as-is and people will fix their various RODATA
> failures during the next devel window, or should I remove the "default
> y if CPU_V7"?
I think we'll keep it as-is, and have another go with it at -rc1 time,
when people have ample chance to then queue up fixes.
They'll have had notice of it, so there's no excuse folk can't work on
the problem in the mean time. (But, of course, they won't...)
--
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
