From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (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 F23935478D for ; Wed, 17 Dec 2025 02:03:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765937019; cv=none; b=Wao79G7C6SGy9ww75URZW04hB7Kw7UQHeKHZ5ARjIImkYCQTevZY99A9hBiLVjnBPnI5KPWLZLpy65umm8YDRt81RHedJluLrhJJLP8R03CEMtF16UHd9Dg7q5oH7y7zgrx3xLI0Mv+DyV2y1lWXLLvRozR1Y4JnYTv/3YP8DCQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1765937019; c=relaxed/simple; bh=umxrCUxt7JdhKqPFzL0+FOQ55Wo/7PIYPQB70jttcuM=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=gavVWd611AtOfetfsHHHtV5vxARvOm5PGbTfvwuN2/jlAFw7RumJuGIndVhmjcAUN+dM4oQvTlPUc7h8wcKt43dRDmz4gpod4bnaaTFpCc+XXq0cZkC8cT0F1O8/renQQN9Uc8z+3u1mv0x7wV4dUQywoxk2gubFYWmkm4I1+7A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=S0MBmPcP; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=h+xUiMfE; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="S0MBmPcP"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="h+xUiMfE" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1765937016; 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=r7Zi0lFaT8ketL7r3/3mTmx2Y/75ccXCTRMPiAb0gVA=; b=S0MBmPcPBmDCwqgqapS3SjaSQp2D/9WwNyQwjKTcYrIOMZHPQ+UE/C8LkcJX0ZPGGtbeaI Sx4jBssGYrrleZuRUG0S/b0I6LGEWQY0o14nICosqZ7ejdVugVR1Vn6zGXU1mkDn/ynGZ0 ZMlz7gkXUcMIgRqiqTJC9rAxQgVS7E0= Received: from mail-qk1-f197.google.com (mail-qk1-f197.google.com [209.85.222.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-414-U4BbGgGiN56_Pl3XK37nDg-1; Tue, 16 Dec 2025 21:03:33 -0500 X-MC-Unique: U4BbGgGiN56_Pl3XK37nDg-1 X-Mimecast-MFC-AGG-ID: U4BbGgGiN56_Pl3XK37nDg_1765937013 Received: by mail-qk1-f197.google.com with SMTP id af79cd13be357-8b24a25cff5so1492863485a.2 for ; Tue, 16 Dec 2025 18:03:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1765937012; x=1766541812; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:from:to :cc:subject:date:message-id:reply-to; bh=r7Zi0lFaT8ketL7r3/3mTmx2Y/75ccXCTRMPiAb0gVA=; b=h+xUiMfELO0/T95OZVI2rsNSD+kw0TfTRipeyrFBC5x0N9KAoSgSKivcGcAZtA4Baj RE2Mgk22NHcs/pVHIvkxdGjcHrFlh38iHp+NrIKIfUbMZ/JmMamdNeEcb5G9hhlUmxkD ZZoLgGy3v8BCclvpt/VwPOrZ2YGZgBFuCMpbMQhvMiwMjDDTKMlo9Ep8Hi1hcmRKGJyL 0pyyAjI8KXFzgU7t5RHYHuzmDCI0crDRhwJgf2zqPoBreqHb7/dXiRWrgQD+x6B5mlsj 5Y3K/cz41o4Ar9eMj/RwFaj3jn0lf1BMq0d4utWAlgEvdCFwV1EYPRGuLvOZBwOlU4by RTIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765937012; x=1766541812; h=content-transfer-encoding:in-reply-to:content-language:references :cc:to:subject:user-agent:mime-version:date:message-id:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=r7Zi0lFaT8ketL7r3/3mTmx2Y/75ccXCTRMPiAb0gVA=; b=PTQZrEVExUmlGhDUA7wJh0rJ1OGbcInuIuBsc4koguV3Igk3AETH58mjZPxbzFxscf 5GUeB8xc197/JhCxNLYcBDNDC6LzdZN7+GfpPbwZ0bv+wUmQGD3qkpvKPdiltslhi1YS sUIXVGM9Zl4G0mHrWGC7rJTUQT47d8PXwVLTPhgvDI12ASbWRCijCEO/Yb0ARBwYRNjs 67IWCaniwXKQF47RSxTt/fUH7uoa9iB+a8n8BQ3fkhyhHmKfnpPS1oL+ZnLqRzib8H2v 7ke8ERTyLcCzFD7W4O3ebQvn96Di97aOb+QiiLfxv+2grbbr2qmIFGJCFOYySDx04FrN Qs/Q== X-Forwarded-Encrypted: i=1; AJvYcCWzWmos+u2jGAk3mWJtA4tfLccVxv5l2KX7ra8h3xFa4Z5ZD24XZjgB/GcFJDPRmSFPeosvi1EbCN5z6Bk=@vger.kernel.org X-Gm-Message-State: AOJu0Yzl/qC7dSbz6YpJm30lH3r0sq8emoZyc50KDytjr/nRRO4r8uyh 7F6dSHAQ1mc6cwavH/YZUrWt8ke8ZfTJwWLJBx6bvJNSvmCpA9/omHQTRM/7d5RyVmAq2NS6XXY ABWyO2025WB3OMXDqUThlOt02sGECrPTKWSUIxf1inIL9mSaref3MTA835eac0N3aIw== X-Gm-Gg: AY/fxX7oSceybpJ1LjlOIrvizRZxWCZ9moqcC1bMKjtTCVh92PkchRp+GxlzAix6Ck3 MkLpeziuQdiaJqTvsKV5YAGQKY2cjwbivGkJYwYPdw2KcCv0pEo9XzNAP70RgGO2I8SIZOM2K5V yl80Au91lFVENRnWhxLfBjTfljuSHku2GS2PZLW3QWUvbbxyCI2uj81j/tYVPxWpJLDwuHMlHeE /JzlkULyuJ8wNFTFD4CMKrfs/p9fQEfcdmOWRIEpc9i6qBz4Fo2pLIMHQC7K/yLABDyekxcMJIW PekBtdrCCikmTfG0K/drEqSjRSBjK802T6Xw8Bk8F0dNJFWfYL6J6/8UK2ZBdo5uClnEJPj140V DDXAMWDqyjjIhFdD4TfbAGUuXpU8ZvEq2T7ov5uc35gQrGKmn4pA2ASEe X-Received: by 2002:a05:620a:1917:b0:8b2:e924:4db7 with SMTP id af79cd13be357-8bb3a0be507mr2226271285a.40.1765937012685; Tue, 16 Dec 2025 18:03:32 -0800 (PST) X-Google-Smtp-Source: AGHT+IG/GRjiq7fWsyYciGNqXV9akONIxhexb203orHkTFDHZ/ah/amTqjSGH2E9C1kKyBxZK/ee8A== X-Received: by 2002:a05:620a:1917:b0:8b2:e924:4db7 with SMTP id af79cd13be357-8bb3a0be507mr2226268485a.40.1765937012297; Tue, 16 Dec 2025 18:03:32 -0800 (PST) Received: from ?IPV6:2601:188:c102:b180:1f8b:71d0:77b1:1f6e? ([2601:188:c102:b180:1f8b:71d0:77b1:1f6e]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-88993b43140sm88952526d6.6.2025.12.16.18.03.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 16 Dec 2025 18:03:31 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <032b60c1-4a5d-44e1-be9c-05f84172a8ca@redhat.com> Date: Tue, 16 Dec 2025 21:03:30 -0500 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH -next] cpuset: add cpuset1_online_css helper for v1-specific operations To: Chen Ridong , Waiman Long , =?UTF-8?Q?Michal_Koutn=C3=BD?= Cc: tj@kernel.org, hannes@cmpxchg.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, lujialin4@huawei.com References: <20251216012845.2437419-1-chenridong@huaweicloud.com> <5a35692f-2800-4fd4-9c23-97d0284293df@redhat.com> <3785c9ca-5bdb-4ff2-9c8f-a3515ba58538@huaweicloud.com> Content-Language: en-US In-Reply-To: <3785c9ca-5bdb-4ff2-9c8f-a3515ba58538@huaweicloud.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/16/25 7:53 PM, Chen Ridong wrote: > > On 2025/12/16 22:58, Waiman Long wrote: >> On 12/16/25 9:03 AM, Michal Koutný wrote: >>> On Tue, Dec 16, 2025 at 08:13:53PM +0800, Chen Ridong wrote: >>>> Regarding the lock assertions: cpuset_mutex is defined in cpuset.c and is not visible in >>>> cpuset-v1.c. Given that cpuset v1 is deprecated, would you prefer that we add a helper to assert >>>> cpuset_mutex is locked? Is that worth? >>> It could be un-static'd and defined in cpuset-internal.h. (Hopefully, we >>> should not end up with random callers of the helper but it's IMO worth >>> it for docs and greater safety.) >> I would suggest defining a "assert_cpuset_lock_held(void)" helper function and put the declaration >> in include/linux/cpuset.h together with cpuset_lock/unlock() to complete the full set. This will >> allow other kernel subsystems to acquire the cpuset_mutex and assert that the mutex was held. > Considering potential use by other subsystems, this is worthwhile. I will add the helper. > >>>> Should we guard with !cpuset_v2() or !is_in_v2mode()? >>>> >>>> In cgroup v1, if the cpuset is operating in v2 mode, are these flags still valid? >>> I have no experience with this transitional option so that made me look >>> at the docs and there we specify it only affects behaviors of CPU masks, >>> not the extra flags. So I wanted to suggest !cpuset_v2(), correct? >> The "cpuset_v2_mode" mount flag is used for making the behavior of cpuset.{cpus,mems}.effective in >> v1 behave like in v2. It has no effect on other v1 specific control files. So cpuset1_online_css() >> should only be called if "!cpuset_v2()". >> > If cpuset1_online_css() is only called under the condition !cpuset_v2(), a compile-time option might > suffice? When CONFIG_CPUSETS_V1=n, cpuset1_online_css could be defined as an empty inline function. cpuset_v2() includes "!IS_ENABLED(CONFIG_CPUSETS_V1)", so the compiler should compile out the call to cpuset1_online_css() if CONFIG_CPUSETS_V1 isn't defined. If you want to make cpuset1_online_css() conditional on CONFIG_CPUSETS_V1, I am fine with that too. Cheers, Longman