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 E838E22A7F6 for ; Thu, 16 Jan 2025 13:30:19 +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=1737034222; cv=none; b=iBDl79bPgRk/Chkt5cWS7rkSftY6QwHHFp06A/ziSzxwANgr2Z1Hmnt1rwPHr/nc007LOHWtwe+h6BrtMd8nt6XH1RdLYairxEscwkIGjBijcsv/GD581cepW3aXnyG+kFtevi06XpXvwOFy5xLb1P16hsZ9UAioIob0nJbH/gQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1737034222; c=relaxed/simple; bh=sSG7QRrMaDJug2P1c1yGD4ebtcIOTPYornbs4DmFCeU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=RBlu8a+eqOMDxPUqqtiQZLFpKVWEFdFzw2Puig9/rytYH3LOpLNIWGtE8hLp+kSGPNWsGGW9yp1m/hypPcRZltBaXOWOb3wSWoaBQyCbzqluX8CiLgKKVWkRQBqb4kSh8KeifqPvoFbLYVfL5v46hF7ZtSOQnrQJYwI91LTgdyc= 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=ZVmgG7e3; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=ZNrI3giC; 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="ZVmgG7e3"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="ZNrI3giC" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1737034218; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RP3bgSfxhvQBfMsuI1cBusNMwpEHbzVTKrkE/2HvSmo=; b=ZVmgG7e3YAQvt3UBc4uKNNuTxjLC7txWXFq4XbIGUoUQ0VxNmqa48UnkMO+BD/QkbI1PMO XZmi6X7cLWJR5Qo7X/+6o7dOqLMzvTNLd1S5wRIVnqRNewpkmpKazrEnrQF2LdCddRjsub Uc+/mhRpDQbeKtVX10kRGbzZHUhQ5u1Qpf1TnHNwtLJ/w6I+Wc0MZ1xAoyMfQygTkVnJ/r jwzG4QeKtybEjnv2qg0CpgLyCeBhjMjs1Iba5eyT+QDol1Zhx/jMJcYfnS/1mXi3COoAhs rZTQNC+0ZDXSORSwRi00AgGVwVtyeZ/+izHIYXmxtCq6/9zaGo7ZFabGhf0Uig== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1737034218; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RP3bgSfxhvQBfMsuI1cBusNMwpEHbzVTKrkE/2HvSmo=; b=ZNrI3giCGYSeIjsF73NagjZUdaZQJe+VCzoY2frFBveA0wYVso0TaTZW7PyFw+p8S2nDE9 kQu21qbuZgTLxvCg== To: paulmck@kernel.org, quic_mojha@quicinc.com, vschneid@redhat.com, neeraj.upadhyay@kernel.org, frederic@kernel.org Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH stop-machine] Fix rcu_momentary_eqs() call in multi_cpu_stop() In-Reply-To: <689a793b-6931-42e1-afbe-d920e1b39228@paulmck-laptop> References: <689a793b-6931-42e1-afbe-d920e1b39228@paulmck-laptop> Date: Thu, 16 Jan 2025 14:30:17 +0100 Message-ID: <87wmeuanti.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; charset=utf-8 Content-Transfer-Encoding: quoted-printable $Subject: [PATCH stop-machine] Fix rcu_momentary_eqs() call in multi_cpu_st= op() [PATCH prefix] Shortlog - That's not a valid subject line. [PATCH] prefix: Shortlog - Is what's expected, no? On Thu, Dec 12 2024 at 11:00, Paul E. McKenney wrote: As this patch is from Mukesh, this want's a From: Mukesh .... line right here. > The multi_cpu_stop() contains a loop that can initially be executed > with s/The// > interrupts enabled (in the MULTI_STOP_NONE and MULTI_STOP_PREPARE states). > Interrupts are guaranteed to be once the MULTI_STOP_DISABLE_IRQ state > is reached. That's not a parseable sentence. > Unfortunately, the rcu_momentary_eqs() function that is currently > invoked on each pass through this loop requires that interrupts be > disabled. What's unfortunate about that? It's a face rcu_momentary_eqs() requires to be invoked with interrupts disabled. > This commit therefore moves this call to rcu_momentary_eqs() to the body 'This commit' is equally pointless as 'This patch'. git grep 'This patch' Documentation/process > of the "else if (curstate > MULTI_STOP_PREPARE)" portion of the loop, thus > guaranteeing that interrupts will be disabled on each call, as > required. Something like this perhaps: Move the invocation of rcu_momentary_eqs() into the interrupt disabled section of the loop. Hmm? > Kudos to =E6=9C=B1=E6=81=BA=E4=B9=BE (Kaiqian) for noting that this had n= ot made it to mainline. > > [ paulmck: Update from rcu_momentary_dyntick_idle() to rcu_momentary_eqs(= ). ] > > Link: https://lore.kernel.org/all/1712649736-27058-1-git-send-email-quic_= mojha@quicinc.com/ Link below the SOBs please. > Signed-off-by: Mukesh Ojha > Signed-off-by: Paul E. McKenney > > diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c > index da821ce258ea7..8896d844d738f 100644 > --- a/kernel/stop_machine.c > +++ b/kernel/stop_machine.c > @@ -250,8 +250,8 @@ static int multi_cpu_stop(void *data) > * be detected and reported on their side. > */ > touch_nmi_watchdog(); > + rcu_momentary_eqs(); Can we please have a comment why this call is actually there and what it does, similar to the one for touch_nmi_watchdog()? Thanks, tglx