From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) by kanga.kvack.org (Postfix) with ESMTP id 502BF6B0006 for ; Mon, 4 Jan 2016 15:34:29 -0500 (EST) Received: by mail-ig0-f174.google.com with SMTP id mv3so2723574igc.0 for ; Mon, 04 Jan 2016 12:34:29 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com. [2607:f8b0:4001:c05::22f]) by mx.google.com with ESMTPS id qm11si465860igb.82.2016.01.04.12.34.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jan 2016 12:34:28 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id ik10so2710270igb.1 for ; Mon, 04 Jan 2016 12:34:28 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20151224003406.GA8644@n2100.arm.linux.org.uk> References: <20151202202725.GA794@www.outflux.net> <20151223195129.GP2793@atomide.com> <567B04AB.6010906@redhat.com> <20151223212911.GR2793@atomide.com> <20151224001121.GS2793@atomide.com> <20151224003406.GA8644@n2100.arm.linux.org.uk> Date: Mon, 4 Jan 2016 12:34:28 -0800 Message-ID: Subject: Re: [PATCH v2] ARM: mm: flip priority of CONFIG_DEBUG_RODATA From: Kees Cook Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Russell King - ARM Linux Cc: Tony Lindgren , Nicolas Pitre , Laura Abbott , Arnd Bergmann , Ard Biesheuvel , Catalin Marinas , Will Deacon , LKML , Linux-MM , "kernel-hardening@lists.openwall.com" , "linux-arm-kernel@lists.infradead.org" , Laura Abbott On Wed, Dec 23, 2015 at 4:34 PM, Russell King - ARM Linux wrote: > On Wed, Dec 23, 2015 at 04:11:22PM -0800, Tony Lindgren wrote: >> * Nicolas Pitre [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"? -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org