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 CF1D232ABFB for ; Wed, 19 Nov 2025 20:13:22 +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=1763583202; cv=none; b=TCGND7eKpwb/VX/O2G94P+ylWC08UcE5tWclYlrrlYFadtjCuVld6Cb0V50oXiV+9I22zcd29a/Na6kLuLYOYp38GC/D5gN5du3bYTFWNJEvQoCV+/OH9eAZmI1BvttQWgScvFd2R9Fmf+zGt8Tzx42ChMkylslqAzmCV5AsD7k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763583202; c=relaxed/simple; bh=O8UNkWZ+mmURcDoX+C2Hrvs6tWW6xZKb8/BoPMY1KhE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=h0VkLOhqFLIj1pfzPAdmMLwZKhnQsKHA8q6BWJWl8PuBgeYXaqq6DW0Yx+L19gpZaBeti68MxjJu63sij9e23O80x/foDNsIwrp3Lwholb9D33aGnFMiIgjlq/iiMJPyqScNGqtIe37uxAAbNJhoEOcFUqlwoo4Ded1jXDvSn74= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=B9vysfEb; 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="B9vysfEb" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B84B6C4CEF5; Wed, 19 Nov 2025 20:13:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763583202; bh=O8UNkWZ+mmURcDoX+C2Hrvs6tWW6xZKb8/BoPMY1KhE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=B9vysfEbhEsqp3PvO2BwgrIWK+We7PxOhbFv2PbR4rpME4LjRtAFfd+xSavcwhTOM JM2iC+eM2TCuCa8xHD5N0f0vYFS3sjrU0zkVRtWgdJPebn4n7y0/o0fj1teHBX8C46 fCXQTgMwj+8+gJjoZNRkj/hyyovwOM4p9PUeMIgbM4seFZhaJSf9C4dEZWbIabsqCF JRZ8MTYn6bTO4sWpKYUnOkQDg2MdTCtir2z64tXMSrxVHW+plIR0gHMXL0LiTmSWra uR/c2AyNgG0VuYo8jhKq0T4ZknpROrUkEmmQaA17S+gk0IdEe9TdUD+E60EiGbsJeZ WVCP++wEQ+FSw== Date: Wed, 19 Nov 2025 21:13:19 +0100 From: Frederic Weisbecker To: Thomas Gleixner Cc: Gabriele Monaco , linux-kernel@vger.kernel.org, Anna-Maria Behnsen , Waiman Long , "John B. Wyatt IV" , "John B. Wyatt IV" Subject: Re: [PATCH v15 7/7] timers: Exclude isolated cpus from timer migration Message-ID: References: <20251113083324.33490-1-gmonaco@redhat.com> <20251113083324.33490-8-gmonaco@redhat.com> <87pl9eklvc.ffs@tglx> <87jyzllwhd.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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87jyzllwhd.ffs@tglx> Le Wed, Nov 19, 2025 at 07:15:42PM +0100, Thomas Gleixner a écrit : > On Wed, Nov 19 2025 at 18:14, Frederic Weisbecker wrote: > > Le Wed, Nov 19, 2025 at 05:50:15PM +0100, Thomas Gleixner a écrit : > >> But thinking more about it. What's the actual point of moving this 'clear' > >> out instead of just moving it further down? > >> > >> It does not matter at all whether the isol/unisol muck clears an already > >> cleared bit or not. But it would keep the function name comprehensible > >> and avoid all this online/offline wrapper nonsense. > > > > That was my suggestion. > > > > It's because tmigr_clear_cpu_available() and tmigr_set_cpu_available() > > can now all be called concurrently through the workqueues and race and > > mess up the cpumask if they all try to clear/set at the same time... > > Huch? > > cpumask_set_cpu() uses set_bit() and cpumask_clear_cpu() uses > clear_bit(). Both are atomic and nothing gets messed up. Urgh, right... > > The only undefined case would be if you end up setting/clearing the same > bit, which would require that the unisol and isol maps overlap. But that > would be a bug on it's own, no? Ok. But then the "unisolate" works must be flushed before this line: + /* Set up the mask earlier to avoid races with the migrator CPU */ + cpumask_andnot(tmigr_available_cpumask, tmigr_available_cpumask, cpumask_isol); Because that is non-atomic and can race with the cpumask_set_cpu() from the works, right? Thanks. -- Frederic Weisbecker SUSE Labs