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 79EB4370D7D for ; Tue, 3 Mar 2026 22:39:42 +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=1772577585; cv=none; b=LgbM/1YsxPTyBHa1dgRhvZXax2EgLVzFlRJ7Nq5pQ3dlTDMJKpnGaAF2InhIEgumRcq+qiO1fshvneplEA6qABY0VDnCPjsFBavWgwuO/lO5BWdgL2eQRqQaNu2fhOCKM7mtLsQwowWm2/uJkI3aWlmeSJrqQ9FERViDsYPGhBM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772577585; c=relaxed/simple; bh=bO+btGi2WKhjGsSdg+4HIcSzs/cHK11jTLWqUSRbHY8=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=DUiutAHJikI9E6VWkPgtvcROX7FmrDMhJxM67gBFMAR/jkYUNiwM8o6VAvE+sYNB9WW4XqSOABAdGzfQli/bERKoKgwKXI1assSjm5y5rCz+0XqaCK6syunCalc+4wxDojw5EEKr1GUFmY/WOzqL1GmABMqvMKQFdXhneRzYjJs= 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=KxaE7lfa; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=zAdLjNhP; 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="KxaE7lfa"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="zAdLjNhP" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1772577580; 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=7YGmYudKha7mMztduKhnb2PznIEfZ3+rlRtNKu7z6rw=; b=KxaE7lfaC1eZBhXb5gVnbT7LDRg6zn2b3R8MHE/KjVH86R2bq+eAert7aFoWFqfVep+mbb O2/1KrHyRQW6Ns532JSK0RzhEiBaZ7X4J/nCCbvYdxakTAqdtrlCL5wl7OrOAjoZsZiczi QoROMktZ5dS0IqHOMmQI5wCSYIC11nErtje1NptD1s46g5s6aXMASP9a22tMVFaplOIsP5 CkF7D3JzziZhM46EzpoCsuVS2+VIIYLWQgxJRFHxfssGLtHQfCeIH1y8jxSE4Q2AYlx8WU vtuX5inK/wywhkX9UU97Ri7dyEdhpRVny4byJzFkoaBL/KIQWH1t8Xt400RK5Q== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1772577580; 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=7YGmYudKha7mMztduKhnb2PznIEfZ3+rlRtNKu7z6rw=; b=zAdLjNhPuqDzZU6H2k5iWsL2rnXI6EEZygWVRKbyQojBk8h8rujtO9gcI0lApZ3dV2SsJw eK5NWAD6mN56fpBA== To: Peter Zijlstra , "Herton R. Krzesinski" Cc: linux-kernel@vger.kernel.org, frederic@kernel.org, mingo@kernel.org, paulmck@linux.vnet.ibm.com, anna-maria@linutronix.de, kyin@redhat.com, jaeshin@redhat.com Subject: Re: [RFC] Processing of raised_list can stall if an IPI/interrupt is missed In-Reply-To: <20260303192953.GM1395266@noisy.programming.kicks-ass.net> References: <20260303190715.935867-1-herton@redhat.com> <20260303192953.GM1395266@noisy.programming.kicks-ass.net> Date: Tue, 03 Mar 2026 23:39:39 +0100 Message-ID: <878qc8zges.ffs@tglx> 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 Tue, Mar 03 2026 at 20:29, Peter Zijlstra wrote: > On Tue, Mar 03, 2026 at 04:07:15PM -0300, Herton R. Krzesinski wrote: > >> Or may be it's not worth changing this since this is rare and missed self IPI should >> not be expected? > > IPIs going missing is certainly unexpected; although kernel/smp.c has > much debugging crud for similar scenarios (AFAIK all of them related to > virt). > > If IPIs go missing your system *will* go funny in one way or another. > I'm not totally against building in some fallback, but we should > definitely consider it dodgy/buggy if we do detect one has gone > walk-about. Indeed and there is enough code by now which relies on the pristine IPI context when the architecture supports it, so basically reverting this change is going to create a boatload of other hard to debug problems. Thanks tglx