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.129.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 290E136605C for ; Tue, 10 Feb 2026 14:01:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770732102; cv=none; b=Vl5P8dN8Gp/j4lo0gwNLyZhCxffVTwV50WbHmzIZI0REVwXUIyh1BN7UIt9mkhvpy4XBPIZDwl8s7VntytR9qe5LA9MTjNM1v44GghVWKo7i3/dRTlnAF/gpz3S4UOOkGnt5Vkv0W/80lW7oGCG5CUzzEHdk2Z74uuWgmK0zn5c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770732102; c=relaxed/simple; bh=8jtpoSXYbybLE/xY+++ZpfTrLk7i+XgUcjmGEmd16hk=; h=From:Message-ID:Date:MIME-Version:Subject:To:Cc:References: In-Reply-To:Content-Type; b=CA1E2vqX3B1jjUghVuErMH8aZf0p3Lo/s9wmyoeZ6XHIbsAFhj/+xqmyR4B6Uu2WZFmzJEYdwh19lggz0zO+IKdrkv+AsfrwLGlgKj3IPux9C7xoWT/lO3UQM3Aw03K5C+tze8Cq8cVNZsvKhohj1+lqORHvRwhnsu9b1xpVgWE= 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=iMJnFEaY; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=EGAt55st; arc=none smtp.client-ip=170.10.129.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="iMJnFEaY"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="EGAt55st" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1770732100; 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=Z4inRA1URPkZFbtOlGH7PVCQZlyxkjMU1G2/KzimKDM=; b=iMJnFEaYjUYMHHxSLCnDDAbS216sm6bJqb/xfEcxv6rI5anQJWKy6iFlIv6miNAIIxruBY 81XlY9FnM/8qRuNppss0nSg8PJUMoLr1+kPAh3WjvnT3jx48X9oDLj78M+8n87ctzxfHN/ 1XY4cH1626aJigtu1EIc645QRsdQFFw= Received: from mail-qk1-f199.google.com (mail-qk1-f199.google.com [209.85.222.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-7-mN9-nb5NM_2xHQm6-iYYFw-1; Tue, 10 Feb 2026 09:01:37 -0500 X-MC-Unique: mN9-nb5NM_2xHQm6-iYYFw-1 X-Mimecast-MFC-AGG-ID: mN9-nb5NM_2xHQm6-iYYFw_1770732094 Received: by mail-qk1-f199.google.com with SMTP id af79cd13be357-8c6a291e7faso1921298185a.3 for ; Tue, 10 Feb 2026 06:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1770732094; x=1771336894; 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=Z4inRA1URPkZFbtOlGH7PVCQZlyxkjMU1G2/KzimKDM=; b=EGAt55stvuzxJLnWnG9qId/vP4iNR3vbl/fqeJsdJuj8i3qlPfgHC+Kzu1nguqpFd/ yvEMd2n4um+VTiEyUohWgTaYvjVYid5nYXobEmGV3wrF1+SM0oShbZNGfSJ3OVOd2doa zBCyLP6eFblSOhF42PTMNmMTxQ2IyobCgu07OTb+jtUb0A6wXMPNHqpOGAgMNHZGTtr6 RRXw+3Q5CT7I3oIIGC3CdmULw7g0LdZMDILLn1y1/aJ3jY0LY8WaGe2sOWWN+Co3ZxN/ LRNonOlZsXt1LAYweb86Ns8Q2Gr79tgTDoLWuqM1dZ1GTXGN41gKSO1u3i5XRJD99eC9 AS/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770732094; x=1771336894; 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=Z4inRA1URPkZFbtOlGH7PVCQZlyxkjMU1G2/KzimKDM=; b=iifkyYNs1f05OY9T0HAtxhdzzyPtnlUMgSeuKrLpw+4OKUa8HPKUR3RQSUk1P/EysH rgJXSKESP1XE3AI4506pnLYqL9yJUwkUV1rPmVRh3x5COtw6IpzynMJJzigLu9lcc4QC 9bnYgE8J+S0sVLIvcmViYS5shf1gsRD3hLBHRat/khakoNn5QeeyweWJjYU0XI7F9po2 GYqGrd5Xuz0XT5NGTjdKhU2bWKFr/sOAxY5zYh8okAsgXQ3i9ziRh6F/4tAjujIfrdNB a1e3gs0hbRJxHguM3sGDUdbGoxtfS/Q3vf18PUi35dYZ1XsKJVhrNdoOJLCCKqtSKXCt MmKA== X-Forwarded-Encrypted: i=1; AJvYcCUPfyLtMZd1F0jWgz6PZRefMVFWVOYtH4Mmgko/NbMi89f4Rx+aSOtEXNLVhcmw0ctV37VbmaG3TeTCTlY=@vger.kernel.org X-Gm-Message-State: AOJu0YwNTgs/t7dDZOlsVQW3ZtJMlDH2mAuqbEFWYChqssy8d+7JHXiY sdFKjXpsyzFq1hYEIRKdWVXK1JqdW1TRa8FDfRRuUZZ/QySU/i02SM6yDAng0c4X68O8V7mMdA6 m/V2EqSQhj1hsipl41gCXIP/gSXzfCEANlGXkPirMUPHaQAb8y9R65pYx3g+WtwJT1w== X-Gm-Gg: AZuq6aKc83bkF/ebGjEydZVF4y9h6yQxaD47svHuiMzZQvBAD7YmW1/XirFpbvCSVfT R6yl2oxgjfwpJt+jZq3mfgHxzvyla2rIlmuw8iVxTWgJ1Xifv/nmF0hlQGnQBil3Q32q4yUmWoC BmNu3Rchqj5Pkg1BTwA68Qqzz0EWQ/arqs7IYXAkQZ07EPS4mktRa0rOfmKez55EXt69mjf9aqc 7TfZ4ztcpu7/vlosMef0wHkF8wC3yzzO8Ucxb/ZIEWLOi1vlGt/34g9qShDxzdUom5TVj2pwXuC +TnUyXUYU2OYORitAPcfCo3xVihyUPebms30BnZ4P8S/HDw3ijNVoISqj1/AoKcyAZuJ6tBmUEp qwd6mUVkdpRCoMvFl+FB4vZ1Vp3jnC4l58C44ZWfaYwenBkFi6eMxMDUGymAGaZvuL9jP X-Received: by 2002:a05:620a:bc5:b0:8bb:26db:e22f with SMTP id af79cd13be357-8caef7e1ca2mr1823855085a.30.1770732093692; Tue, 10 Feb 2026 06:01:33 -0800 (PST) X-Received: by 2002:a05:620a:bc5:b0:8bb:26db:e22f with SMTP id af79cd13be357-8caef7e1ca2mr1823851485a.30.1770732093249; Tue, 10 Feb 2026 06:01:33 -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 af79cd13be357-8caf9a15a4dsm1023079185a.25.2026.02.10.06.01.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Feb 2026 06:01:32 -0800 (PST) From: Waiman Long X-Google-Original-From: Waiman Long Message-ID: <6552b863-6d2b-4537-8155-d87985e77628@redhat.com> Date: Tue, 10 Feb 2026 09:01: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/for-next v4 3/4] cgroup/cpuset: Call housekeeping_update() without holding cpus_read_lock To: Chen Ridong , Waiman Long , Tejun Heo , Johannes Weiner , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Ben Segall , Mel Gorman , Valentin Schneider , Anna-Maria Behnsen , Frederic Weisbecker , Thomas Gleixner , Shuah Khan Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org References: <20260206203712.1989610-1-longman@redhat.com> <20260206203712.1989610-4-longman@redhat.com> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/9/26 8:29 PM, Chen Ridong wrote: > > On 2026/2/10 4:29, Waiman Long wrote: >> On 2/9/26 2:12 AM, Chen Ridong wrote: >>>>           return; >>>>       } >>>>   -    WARN_ON_ONCE(housekeeping_update(isolated_cpus) < 0); >>>> -    isolated_cpus_updating = false; >>>> +    /* >>>> +     * update_isolation_cpumasks() may be called more than once in the >>>> +     * same cpuset_mutex critical section. >>>> +     */ >>>> +    lockdep_assert_held(&cpuset_top_mutex); >>>> +    if (isolcpus_twork_queued) >>>> +        return; >>>> + >>>> +    init_task_work(&twork_cb, isolcpus_tworkfn); >>>> +    if (!task_work_add(current, &twork_cb, TWA_RESUME)) >>>> +        isolcpus_twork_queued = true; >>>> +    else >>>> +        WARN_ON_ONCE(1);    /* Current task shouldn't be exiting */ >>>>   } >>>> >>> Timeline: >>> >>> user A            user B >>> write isolated cpus    write isolated cpus >>> isolated_cpus_update >>> update_isolation_cpumasks >>> task_work_add >>> isolcpus_twork_queued =true >>> >>> // before returning userspace >>> // waiting for worker >>>             isolated_cpus_update >>>             if (isolcpus_twork_queued) >>>                 return // Early exit >>>             // return to userspace >>> >>> // workqueue finishes >>> // return to userspace >>> >>> For User B, the isolated_cpus value appears to be set and the syscall returns >>> successfully to userspace. However, because isolcpus_twork_queued was already >>> true (set by User A), User B's call skipped the actual mask update >>> (update_isolation_cpumasks). >>> Thus, the new isolated_cpus value is not yet effective in the kernel, even >>> though User B's write operation returned without error. >>> >>> Is this a valid issue? Should User B's write be blocked? >> It is perfectly possible that isolated_cpus can be modified more than one time >> from different tasks before a work or task_work function is executed. When that >> function is invoked, isolated_cpus should contain changes for both. It will copy >> isolated_cpus to isolated_hk_cpus and pass it to housekeeping_update(). When the > It is clear about isolated_hk_cpus and isolated_cpus. > >> 2nd work or task_work function is invoked, it will see that isolated_cpus match >> isolated_hk_cpus and skip the housekeeping_update() action. There is no need to >> block user B's write as only one task can update isolated_cpus at any time. >> > The main question remains: user B receives a success return even though > isolated_hk_cpus has not yet taken effect (i.e., > /sys/devices/system/cpu/isolated does not reflect the change). In that case, how > can user B confirm whether their configuration is actually applied? task_work function is synchronous. IOW, if a user writes to a cpuset control file to modify an isolated partition, when control is passed back to userspace, it is guaranteed that the task_work function, if queued, would have been executed. wq work function, OTOH, is asynchronous. So if a user brings down an isolated CPU to make an isolated partition invalid, the supposed changes to the sched domains may not be completed by the time the offline operation returns. However this is an operation that normal users shouldn't do in a production system anyway and they are taking their own risk if they try to do it. Cheers, Longman