From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f54.google.com (mail-wm1-f54.google.com [209.85.128.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 50BEC44212E for ; Wed, 8 Jul 2026 12:44:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783514654; cv=none; b=LqVYWlYx7sqNtoFcGGu5ZOPO636LGLkR5A+AlKeTXf7M3bNokyUaqxfaLkYyb7DVwIAlB6amsEq6z2Bmgss1D671PVrtXYbggPRUyr5ApziLCIUtIYAKbIG0DkRcUh7jw1EsOzn7SLGpX7ilqQjY+PWblmwNqi6L5QoYDhBgkas= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783514654; c=relaxed/simple; bh=PjwusBUVK7BVTHudAhJS6kwqf5aGdPDs9CvoLH1KgQE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=SBh9X4v97umy//cVWnVEhSkWCpE4VSOP5LTKcGtjeDH6zVz0/oKbjAxUKKK9rIS1MshR4BzIlazs5eNfwOwEezb4HwddeGMlPm/f/uTtvslVPOTkCqus91kQCUuMFA2A0vo3r35z40ySSTQGShHUaExY59bVdYYDfhiFKR6wyd4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com; spf=pass smtp.mailfrom=suse.com; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b=I4xMj5kY; arc=none smtp.client-ip=209.85.128.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=suse.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=suse.com header.i=@suse.com header.b="I4xMj5kY" Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-493bb510ce4so4254735e9.1 for ; Wed, 08 Jul 2026 05:44:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1783514652; x=1784119452; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=NHdvaYblCO9gySWGuyLbcYtosxqz/6ReS++EfWgluak=; b=I4xMj5kY/sC1hjep2QGFFG6O/N9+zCXylMi299XSCB/KHmmSecN1AzL8OpKnegxrrC KLFkt2yiQJRCIEskXISaIrbwLy6fIWIm6xpqTKqGFZJBJqH/EmYUsYitYjAM6m+tgoI8 jRqrpKoSgJhMDUh7wBzI5BbLcO8A44sUOJZIr4JJ+PcS+zI1ea/CcBcOFGqjKhRBVYh8 y3oLA4TCaSj6QngtLIzEB/iB4MnVpinLGiQrigGWsnAr5Y/rB7yuxLFC0fiRlgDgo+YA vitITN60DkD6nJ06wqtBxAOlYNUWnEd2cxwvyYBgvxGQP7lswXgSnFcVU380G1PIPlIh wrQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783514652; x=1784119452; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NHdvaYblCO9gySWGuyLbcYtosxqz/6ReS++EfWgluak=; b=iXQuz5XwiFjdzarlnp6sp7xLYe2zs0C7mlw120jxrha7GE0QM52BaAVZdX28Tu3XNb 7bMjyV4lfGf/mN9q0PWhNu8gC6RHERU9YVxZdYMz1q9XM7T9v3VffKJ1TqtGeboEjIuu BU/9f6ngy5HNkpSi8+/VQNy9X9gbOk2WifvEJRnvm1IOUqd4Tv+qeVGyOBznG48TWtfV jmQW3RPzIsfaXwViiGz8M5i2hZ5hSgbkkj7T6qt6qqisYZYFNqP65TvHwKGmpfagYrI5 0FXSubvaRuTF8e7vdJHpot0sIIAclWt9LfejbfbgqNabUl6DrI6UHxchffLzpHtd/+2t 2wmQ== X-Forwarded-Encrypted: i=1; AHgh+RrQuLR9j2DFZ76LxEy9rUPhvaviNGMQK8PfT6rPI9ph8jtXGhExydrOT2GPjJ5dNeKjVqPOROhcABx35Us=@vger.kernel.org X-Gm-Message-State: AOJu0YyvYzlyAjQiS2UvsbeoHzDD7OjmdAc8ki80Kn6zC7rgdT78RdJd awsJqpkb3XLb9v1AoJ1nhQgIYUU82VdMImFUAXT/QTR5nubnwBEUZXomDfzaVsQqH0A= X-Gm-Gg: AfdE7cmynh9u0G2xbyCJc4OuQ+wKWwrzHNlljzyTfRwK82UotOLHpg64qujtmxA6rob WoHl+opbC3/FMuva72u0eOA5mXXPn7twGtH0SUCcHevyc6Kx2cjyla5u9hyWKR+MmeC2cdFgI12 jpnTOReHAvnNLlwgFUl6bZUaoUf3i0PynUzqnwmJaE1/DWczP13V52YXUCGZZs6/uh6RFX8jrZB oxqch7gdJFXUIFuHI94AU6ZNg1JBua0FgDz+/kpRkfoPnUOvV73beQz8XhS2LV75ViZeLWft+1D LJfPIN8AOm7nLVQ4EigGEUk2PdDiI04H25RjhszOwY1V2Zl2qEaVlIFdiE0Hc7qj/ypz7BTz5fL MO1CjRooQf/eBp6YxDQJsMhJ3CUfv/ZAtiwUm1yKfnIV4cMncQkN9QB0ST6dqNUjO2OGGoCoxMY 3IxcwcNm0KH8BvnTQ= X-Received: by 2002:a05:6000:4203:b0:47d:d812:e067 with SMTP id ffacd0b85a97d-47df075e2femr2447949f8f.29.1783514651660; Wed, 08 Jul 2026 05:44:11 -0700 (PDT) Received: from pathway.suse.cz ([176.114.240.130]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47aa039af67sm48872969f8f.17.2026.07.08.05.44.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 05:44:11 -0700 (PDT) Date: Wed, 8 Jul 2026 14:44:09 +0200 From: Petr Mladek To: Bradley Morgan Cc: akpm@linux-foundation.org, feng.tang@linux.alibaba.com, Steven Rostedt , Peter Zijlstra , Thomas Gleixner , linux-kernel@vger.kernel.org Subject: Re: [PATCH] panic: make force_cpu redirect work from an NMI Message-ID: References: <20260707205921.15247-1-include@grrlz.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260707205921.15247-1-include@grrlz.net> Adding more people into Cc. I wonder if smp_call_function_single_async() can be called safely from NMI. Maybe, we should skip the redirection completely in this case. On Tue 2026-07-07 20:59:21, Bradley Morgan wrote: > nmi_panic sets panic_cpu first. Bail only on a different > owner, and hand panic_cpu to the target after the IPI. This is quite cryptic. Who should bail? What is target? What IPI? Please, do more descriptive commit messages and better explain the problematic situation. > Found by sashiko [1]. Better to use: Reported-by: Sashiko > [1] > https://sashiko.dev/#/patchset/20260707183253.9793-1-include@grrlz.net Closes: https://sashiko.dev/#/patchset/20260707183253.9793-1-include@grrlz.net > Signed-off-by: Bradley Morgan > --- a/kernel/panic.c > +++ b/kernel/panic.c > @@ -396,8 +396,8 @@ static bool panic_try_force_cpu(const char *fmt, va_list args) > return false; > } > > - /* Another panic already in progress */ > - if (panic_in_progress()) > + /* Bail only if a different CPU is already handling it. */ > + if (panic_in_progress() && atomic_read(&panic_cpu) != this_cpu) There already exist panic_on_other_cpu()... > return false; This looks strange. "return false" means that vpanic() will continue with panic. I would expect that this CPU should end up offline. It would actually work because vpanic() continues with: if (panic_try_start()) { /* go ahead */ } else if (panic_on_other_cpu()) panic_smp_self_stop(); And panic_try_start() would obviously fail while panic_on_other_cpu() succeed. But still, it would be more straightforward to do here: /* Stop this CPU when the panic is already proceed elsewhere. */ if (panic_on_other_cpu()) return true; > - /* Another panic already in progress */ > - if (panic_in_progress()) > + /* Bail only if a different CPU is already handling it. */ > + if (panic_in_progress() && atomic_read(&panic_cpu) != this_cpu) > > /* Which CPU won the race? */ > @@ -440,6 +440,9 @@ static bool panic_try_force_cpu(const char *fmt, va_list args) > return false; > } > > + /* Hand panic_cpu to the target so it wins its own panic_try_start. */ > + atomic_set(&panic_cpu, panic_force_cpu); As I already mentioned, this is too late. The panic_force_cpu might already be offline because it called panic_try_start() earlier it it failed. The main question is whether we could safely call smp_call_function_single_async() from NMI at all. If not then we will need to proceed panic() on this CPU. If yes then we need to fix this in nmi_panic(). It should call panic_try_force_cpu() first. It should call panic_try_start() only when panic_try_force_cpu() returns false, like when it did not forced another CPU. r > /* IPI/NMI sent, this CPU should stop */ > return true; Best Regards, Petr