From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 E6BEB3F58C7 for ; Fri, 26 Jun 2026 13:38:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782481110; cv=none; b=YBtzTqqi+SyGPIursj7h/PK77QcW6wdZYkmiULzh7T5RntOnlYMM3A8TNAw53GoFYxTJVXzO/O/sToF2H6iNtwF9cvXgXvpASwTHS89yyjMhEAPALERg2suENcbMPt9cFeO556tAbDxF82uOGxQ8jXvYEipOdeAgeLLHAoVTMnQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782481110; c=relaxed/simple; bh=+xNQyT1MfidyimKTIhSwOnsZ3AeiFzykZcwLolD/01Q=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=IppgiTmAEMIasw+4qrOeuTXyrWUox2exLd8fLfznZ/KglX7zftIgGeTwzy3TtsUEO7dolfAlx2oNyixh2LVziaxdoxKeSiDX1lAVipiHMPJFXPWPgO5aA7NsqVluPo8Y4fT37mB/6qw8Dp8fTfK6a93l5LucXelWHjcWprhkFlA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=l66HRIoc; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="l66HRIoc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id A0DA41F000E9; Fri, 26 Jun 2026 13:38:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1782481109; bh=SHC3NTk6ag7ZOBBtU8/24jbja6QjbOa0loYL3dYrCGI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=l66HRIocWqGXrGxy1Clv8rbTqmsDhleJk4G3q6qdBjt7LenVNIoomgo+lWxBAB23f R1YTfg7g7LYV75+jtbHg+NHQCh/BtOCqN8C4+aYf0hxdrduQmQ5C/4cmPVop2zPdxX JbUiT9lk9+YNW8wejcEC6fGXjJoMXvoNGZXDRXXqVoIpR5EUf8VyWG8hzBXKsGNijy pstFS/RHrvIO4my2vD4Vkffg82u5uPlw3MTuEB7M7kqfKqh0dXwT2WKAzVNaAcXYSi Tx+G1TMNuvJ++4UO52cP0Pl2FGICj1GBceFpvCUsb0HRF/wDriClwEXaZF/PHG1OlV mmiMQHxMgj5ig== From: Thomas Gleixner To: Chuyi Zhou , mingo@redhat.com, luto@kernel.org, peterz@infradead.org, paulmck@kernel.org, muchun.song@linux.dev, bp@alien8.de, dave.hansen@linux.intel.com, pbonzini@redhat.com, bigeasy@linutronix.de, clrkwllms@kernel.org, rostedt@goodmis.org, nadav.amit@gmail.com, vkuznets@redhat.com Cc: linux-kernel@vger.kernel.org, Chuyi Zhou Subject: Re: [PATCH v8 01/14] smp: Disable preemption explicitly in __csd_lock_wait() In-Reply-To: <20260616111127.966468-2-zhouchuyi@bytedance.com> References: <20260616111127.966468-1-zhouchuyi@bytedance.com> <20260616111127.966468-2-zhouchuyi@bytedance.com> Date: Fri, 26 Jun 2026 15:38:26 +0200 Message-ID: <87a4shjub1.ffs@fw13> 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, Jun 16 2026 at 19:11, Chuyi Zhou wrote: > The latter patches will enable preemption before csd_lock_wait(), which > could break csdlock_debug. Because the slice of other tasks on the CPU may > be accounted between ktime_get_mono_fast_ns() calls, disable preemption > explicitly in __csd_lock_wait(). This is a preparation for the next > patches. This is not really a comprehensible change log. See: https://docs.kernel.org/process/maintainer-tip.html#changelog And if you follow the structure given there, i.e. context, problem, solution then you end up with something like: The CSD debugging code in__csd_lock_wait() must be invoked with preemption disabled. It is invoked from the various smp function call mechanisms which guarantee that. Disabling preemption throughout the smp function call procedure can induce large latencies, which can be avoided for certain scenarios by enabling preemption earlier. But that would invoke __csd_lock_wait() with preemption enabled. To prepare for that explicitly disable preemption in __csd_lock_wait() itself. See? Thanks, tglx