From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1FEE23B994A for ; Thu, 23 Jul 2026 11:52:45 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784807570; cv=none; b=CTiMYP5jlCX7Ywp2AfQPxFx538Uuaq2sTNXpdpKJC7/+6zH2f8zWjPnAZbHSDEoWuqics5gb/RQZNowBZVsxNJkth3e4E/5O70HafQB5erl2hhFi3zYvHspiH883rxWLHb+NMDLjKdkytcZ3k6amXj9y7lqNcq+dZ7zXvzZMTr8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784807570; c=relaxed/simple; bh=885sX3e5/hzproFUoE9fSzzz+ue5ifd6wR6EIezHdaM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=sywTzccjRssfnGuIHQVfA1TXQ2nZmhb7bLoBw1T0Eh/DfflN/eVscZsfcdfMGUWYymaF9cKirqDWbzQnEzBJaNynBPXQsgcpUoso+vetPGNXRlyiHxFqpW6Sx0ZtfWwfyO4huDvdc4BLVIP/oE/xBbPDKwO78oTXalkfo7K7+M8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=pLbeLY7f; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=Fa5fKgOi; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="pLbeLY7f"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="Fa5fKgOi" From: John Ogness DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1784807559; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QmXY88KWedCv3LgNMTTpRBbPejN5wfvGcvmWOTilvG0=; b=pLbeLY7ftasf5v/3N2fbp3kzHhWikfUL5UjHjg9X6G4idARRQQZJ0xrcQW0Nz4oGBssk3W i0nK5LT8UCrHDHsPi6VHpJ32yglb0SkcTnegqxDuMcnOGjEHCo4Bn38CbFqiDYZz1V+wGz t5ANMX5z4Onf077mmoZFJ6EBjUkw0Ez3e5S4qZnksV0JzStN+uLZlgmRKw1j6DcjDpYuc4 CNH6cC04ygsGkIbhsmYeKlx3U4H2b8yTPN1YfSYLtxs8OBudfSwXDvsnw+IvflG7e0Ar21 /4oxOyuokuGuea4wv3qwU1OYQwP83VUdL9q0XMgCtYDWfmuXrdytzCa9mvRv2Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1784807559; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QmXY88KWedCv3LgNMTTpRBbPejN5wfvGcvmWOTilvG0=; b=Fa5fKgOi4cavQvrj3OSEmlriU+6oB43AauIJos28z7uDpB9DAqg0tELJjqZk+KP0szNuE/ IYCbP9/o/B0jJhBg== To: "Mukesh Kumar Chaurasiya (IBM)" , maddy@linux.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com, chleroy@kernel.org, sshegde@linux.ibm.com, mchauras@linux.ibm.com, mkchauras@gmail.com, ruanjinjie@huawei.com, thuth@redhat.com, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Cc: Andreas Schwab Subject: Re: [PATCH] powerpc/970: fix nap return address corruption on async interrupt exit In-Reply-To: <87fr1iq4fu.fsf@jogness.linutronix.de> References: <20260707172430.790040-1-mkchauras@gmail.com> <87fr1iq4fu.fsf@jogness.linutronix.de> Date: Thu, 23 Jul 2026 13:58:39 +0206 Message-ID: <87h5lpq5x4.fsf@jogness.linutronix.de> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On 2026-07-16, John Ogness wrote: > On 2026-07-07, "Mukesh Kumar Chaurasiya (IBM)" wrote: >> On PowerMac G5 (PPC970, CONFIG_PPC_970_NAP) the system panics shortly >> after boot with symptoms including instruction fetch faults, kernel data >> access faults, and stack corruption, predominantly on SMP and always >> somewhere inside softirq processing. >> >> The PPC970 idle path works by setting _TLF_NAPPING in the current >> thread's local flags before entering the MSR_POW nap loop. When any >> async interrupt wakes the CPU, nap_adjust_return() is expected to detect >> _TLF_NAPPING, clear it, and rewrite regs->NIP to power4_idle_nap_return >> so that the interrupt returns cleanly to the caller of power4_idle_nap() >> rather than back into the nap spin loop. >> >> DEFINE_INTERRUPT_HANDLER_ASYNC generates the following sequence: >> >> irq_enter_rcu(); >> ____func(regs); /* timer_interrupt / do_IRQ body */ >> irq_exit_rcu(); /* softirqs run here, irqs re-enabled */ >> arch_interrupt_async_exit_prepare(regs); /* nap_adjust_return was here */ >> irqentry_exit(regs, state); >> >> irq_exit_rcu() calls invoke_softirq() -> do_softirq_own_stack(), which >> runs softirqs with hardware interrupts re-enabled. A nested async >> interrupt can therefore arrive while _TLF_NAPPING is still set. That >> nested interrupt reaches nap_adjust_return() in its own >> arch_interrupt_async_exit_prepare() call, finds _TLF_NAPPING set, and >> redirects *its own* regs->NIP to power4_idle_nap_return. Returning via >> that blr with an unrelated LR on the softirq stack jumps to a garbage >> address, causing the observed crashes. >> >> The comment that previously lived in arch_interrupt_async_exit_prepare() >> even described this exact hazard ("must come before irq_exit()"), but >> nap_adjust_return() was placed after irq_exit_rcu() in the macro, so >> the protection was never effective. >> >> Fix this by calling nap_adjust_return() inside DEFINE_INTERRUPT_HANDLER_ASYNC >> immediately before irq_exit_rcu(), ensuring _TLF_NAPPING is cleared and >> regs->NIP is adjusted before any code that can re-enable interrupts or >> invoke softirqs runs. Move the explanatory comment into >> nap_adjust_return() itself and remove it from arch_interrupt_async_exit_prepare(). >> >> Fixes: bee25f97ad24 ("powerpc: Enable GENERIC_ENTRY feature") >> Closes: https://lore.kernel.org/all/87wlvazrdy.fsf@igel.home/ >> Reported-by: Andreas Schwab >> Signed-off-by: Mukesh Kumar Chaurasiya (IBM) > > Tested-by: John Ogness Is there a reason this is not being queued for 7.2? Without this fix, PPC970 machines cannot boot 7.2. John Ogness