• Milton Miller's avatar
    powerpc: Don't search for paca in freed memory · 768d18ad
    Milton Miller authored
    Starting with 1426d5a3 (powerpc:
    Dynamically allocate pacas) we free the memory for pacas beyond
    cpu_possible, but we failed to update the loop the secondary cpus use
    to find their paca.  If the system has running cpu threads for which
    the kernel did not allocate a paca for they will search the memory that
    was freed.  For instance this could happen when the device tree for
    a kdump kernel was not updated after a cpu hotplug, or the kernel is
    running with more cpus than the kernel was configured.
    
    Since c1854e00 (powerpc: Set nr_cpu_ids
    early and use it to free PACAs) we set nr_cpu_ids before telling the
    cpus to advance, so use that to limit the search.
    
    We can't reference nr_cpu_ids without CONFIG_SMP because it is defined
    as 1 instead of a memory location, but any extra threads should be sent
    to kexec_wait in that case anyways, so make that explicit and remove
    the search loop for UP.
    
    Note to stable: The fix also requires
    c1854e00 (powerpc: Set
    nr_cpu_ids early and use it to free PACAs) to function.  Also
    9d07bc84 (Properly handshake CPUs going
    out of boot spin loop) affects the second chunk, specifically the branch
    target was 3b before and is 4b after that patch, and there was a blank
    line before the #ifdef CONFIG_SMP that was removed
    
    Cc: <stable@kernel.org> # .34.x: c1854e00 powerpc: Set nr_cpu_ids early
    Cc: <stable@kernel.org> # .34.x
    Signed-off-by: default avatarMilton Miller <miltonm@bga.com>
    Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
    768d18ad
head_64.S 19.9 KB