From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 EFDD327E1DC for ; Fri, 30 Jan 2026 10:02:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769767357; cv=none; b=I2H+eumOTl+pNFMQ115PnSpiQkL3XKNpedzzZb9EnqaM2M2h0Ft3UuOx97FJVhVBWV8lutUcuDjABK6fIhslGwCRtX7x3anCVFUh4toKvlcBo2DxzaroQA1la1HzXsUM9JWqkuVE++NMcak+QpgL12x3jphTd+nEYhiVgLfGl0I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769767357; c=relaxed/simple; bh=oL8KtW/OpAChBXY7MNqyy3iaVaJ3mbEm+uEeS+joj2Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=AizjCHiI/DFcrI7hulY/VOlIzpWm/bKYi4kejBAq9oF1olmwJVLkemcv1bL0j5jQMAX3pG3DpsCOWcgF1tdJh9zup5X3OP4KMrgWus+kgqvKwItu6D7G+EOphpmnbcZrSRiB4r0eWzqK2XhvU6b3z3Fqc/eF+Xa9K9vUrQ0XBYo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UmxldM64; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UmxldM64" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B1CA5C4CEF7; Fri, 30 Jan 2026 10:02:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769767356; bh=oL8KtW/OpAChBXY7MNqyy3iaVaJ3mbEm+uEeS+joj2Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=UmxldM64zxqgpKl0CHS/shzY3rOAeILNbAsP587l92VOePjhBfXxgE+5yJlDNOixx imuUW5UIezp03PmbQuj2v/SAsBJ33vVAeLAbEc+F39S+dzXRfr2XJKTdbjOtUtu/xn IOBWba6/JmSD7xRv9jKpJ4ew7e4b5K/IIKI+Tbety9CD//Lo5q6csrETt+f2/pj/io BqU9a0EQ8m07z37SW4S+WwNpTladjf468mZ6b4zmdmT5m4+OGO6nAwVEYrWjsZ5EKi lGroVpmSY/AOCCuVI0y7GqUKG4UkT5V0+A1XXY1wlP+d6SJ5uFtz1jhpEfWxH3BYiJ u/fxlkGwcs/sA== From: Thomas Gleixner To: "Chang S. Bae" , linux-kernel@vger.kernel.org Cc: x86@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, peterz@infradead.org, david.kaplan@amd.com Subject: Re: [PATCH 1/7] stop_machine: Introduce stop_machine_nmi() In-Reply-To: <00ad5958-dc5f-4d18-ad24-9de607912bf8@intel.com> References: <20260125014224.249901-1-chang.seok.bae@intel.com> <20260125014224.249901-2-chang.seok.bae@intel.com> <87o6me9nd0.ffs@tglx> <00ad5958-dc5f-4d18-ad24-9de607912bf8@intel.com> Date: Fri, 30 Jan 2026 11:02:33 +0100 Message-ID: <87wm0zl8p2.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 Thu, Jan 29 2026 at 09:07, Chang S. Bae wrote: > On 1/28/2026 12:02 AM, Thomas Gleixner wrote: >> And this wants to become >> >> if (IS_ENABLED(CONFIG_STOMP_MACHINE_NMI) && msdata->use_nmi) >> err = stop_this_cpu_nmi(msdata); >> else >> err = msdata->fn(msdata->data); > > Although that config option is very clear and makes tons of sense, the > latter reads like a (silent) fallback path for a stop_machine_nmi() > invocation with CONFIG_STOMP_MACHINE_NMI=n. > > Maybe this might be clear to reject the NMI option right away with > something like: > > stop_machine_cpuslocked_nmi(...) > { > if (!IS_ENABLED(CONFIG_STOMP_MACHINE_NMI)) > return -EOPNOTSUPP; > ... > }; That function should not be exposed at all when the config switch is off. Hide it behind #ifdef CONFIG... It really should not be used in generic code at all. Thanks, tglx