From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp1040.oracle.com ([141.146.126.69]:50191 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752590AbcBKNfk (ORCPT ); Thu, 11 Feb 2016 08:35:40 -0500 Subject: Re: [added to the 4.1 stable tree] ARM: OMAP2+: Fix l2_inv_api_params for rodata To: Russell King - ARM Linux , "Woodruff, Richard" References: <1455117136-28870-1-git-send-email-sasha.levin@oracle.com> <1455117136-28870-180-git-send-email-sasha.levin@oracle.com> <20160211104147.GT10826@n2100.arm.linux.org.uk> Cc: "stable@vger.kernel.org" , "stable-commits@vger.kernel.org" , Tony Lindgren , Kees Cook , Laura Abbott , "Menon, Nishanth" , "Kristo, Tero" From: Sasha Levin Message-ID: <56BC8E1C.3030703@oracle.com> Date: Thu, 11 Feb 2016 08:35:24 -0500 MIME-Version: 1.0 In-Reply-To: <20160211104147.GT10826@n2100.arm.linux.org.uk> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 02/11/2016 05:41 AM, Russell King - ARM Linux wrote: > On Thu, Feb 11, 2016 at 04:55:37AM +0000, Woodruff, Richard wrote: >>> > > From: Sasha Levin [mailto:sasha.levin@oracle.com] >>> > > Sent: Wednesday, February 10, 2016 9:11 AM >> > >> > Did you test these changes? >> > >>> > > We don't want to write to .text, so let's move l2_inv_api_params >>> > > to .data and access it via a pointer. >> > >> > At one point in time some of these functions were copied from DRAM load >> > address into SRAM and executed from there. >> > >> > Some of these sections had to be executed outside of DDR due to issues. >> > The copy assumed contagious section. If you move some of the data into >> > a separate section and any copy is still in code the result won't work >> > as expected. If the code has changed then maybe its OK. Back when >> > this code was entered it was hand stepped to ensure correct behavior. > Yes, this isn't going to work if it is copied out of the DDR, because > moving the data to the .data section and introducing a PC relative > access to it will make the code expect to access data at a relative > offset from the SRAM. > > Sascha, please drop this for now. Dropped. Thanks, Sasha