Re: [PATCH stable/4.0.y] ARM: 8325/1: exynos: move resume code to .text section

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 15, 2015 at 09:04:20AM +0200, Ard Biesheuvel wrote:
> On 15 June 2015 at 01:13, Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote:
> > On Tue, 2015-06-02 at 19:42 -0700, Kevin Hilman wrote:
> >> From: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
> >>
> >> This code calls cpu_resume() using a straight branch (b), so
> >> now that we have moved cpu_resume() back to .text, this should
> >> be moved there as well. Any direct references to symbols that will
> >> remain in the .data section are replaced with explicit PC-relative
> >> references.
> >
> > I don't get it.  cpu_resume() is still in the .data section in 4.0.
> > This appears to depend on:
> >
> > commit d0776aff9a38b1390cc06ffc2c4dcf6ece7c05b9
> > Author: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx>
> > Date:   Wed Mar 25 07:39:21 2015 +0100
> >
> >     ARM: 8324/1: move cpu_resume() to .text section
> >
> 
> You are right. So this patch results in the Exynos resume function to
> call cpu_resume() in .data from the .text section. This turns out to
> work fine for normal configs (exynos_defconfig, multi_v7_defconfig)
> built for ARM since the distance is < 16 MB, and -apparently- fixes an
> issue Kevin spotted with the Thumb build on top of that. Whether
> cpu_resume() may now be out of Thumb range (8 MB) in some configs is
> irrelevant since the Thumb build was broken in the first place.

Err, commit 12833bacf5d904c2dac0c3f52b2ebde5f2c5a2bc should not be
taken into older kernels at all, precisely because 8324/1 is not
backported either.

The whole point of moving it (if you read the commit text) is because
we've moved cpu_resume to .text, which then allows the mach-* asm
which calls cpu_resume to also move.  Without the first, the second
doesn't make sense.

I think the question is - what's caused stable-4.0 to start spitting
these errors?  Presumably, 4.0 didn't, and stable-4.0 has regressed?
Maybe, rather than trying to fix this new regression, the original
cause should be reverted?

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]