From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qk1-f171.google.com (mail-qk1-f171.google.com [209.85.222.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D0ED434845D for ; Mon, 5 Jan 2026 15:54:41 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767628484; cv=none; b=amIKSXdi1n37oUw4HEKwtFSmcgMaYByqGMlRGT95PKKOkFC+vPyZvS43y9zXfW8GzjX05YUjnprvTjrk/zf2hq+b5bUYQFDFsyuxJkOpK2w1MlDp/1FrVDPJw7oIDoXWZ91kbgWe8e2aRxkkI4u79HsLz1mafMCFk8Y6KlSR0TU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767628484; c=relaxed/simple; bh=JtFC32xi6j5IfxixNuzP6FWQBzCxLH1+Y75+kOMFwC0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Oz7WeSqEGsSztuFlfUfPKfdcbQay8VMCVuFo5FvUCNazIo1TvSx6VhA5SVdR1hE8fr0oTh7GUzkhVOpjVKREvsABG/CnD7SB6oY4dA1RLb1udiuknL5PuwUePEwyxS6o5e95vkyHkokHuMyDBr+4zKeV2e1CiuRF+txzuHF1lT8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=BzCISz4B; arc=none smtp.client-ip=209.85.222.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="BzCISz4B" Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-8b2d6df99c5so210473885a.1 for ; Mon, 05 Jan 2026 07:54:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1767628481; x=1768233281; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=WqeiK1L0ygc2pzqeCiF6H1L5F3hBzQyLyjzKsWaL6zQ=; b=BzCISz4BLAJEQLOVROpdHYPjSkC+D2AT+CCCCFaLrg1PaqG+gUeQ5BcU1pkC+Qzpa9 eFi5Zji+OtVhNBhFnvpPdgH6l9/mKqfjQtlStyFJMWbAa2CvytHDJQvv5slFz/UxpDZA ZWQZFWZ2fUswu5AMWcGr9jpitIFmUbpTt/2tVsa54LNjQe4yX1eEMJGCgX5EVtOxRU1H vFRfuQh7OKYyfW7ngzDpzhzAKWPAV/fFQhcNcc1Wlg/U+q97LOU4hOaublPUR5ieNZ1C wXolWM0jh/VP7j6bixlKjI0ddK29m1WWD41lRDux4o0b7YpkaTYaxYZVNbEg11lR1qMm js6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767628481; x=1768233281; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=WqeiK1L0ygc2pzqeCiF6H1L5F3hBzQyLyjzKsWaL6zQ=; b=lX+ZGkHf0MHA/3KvaXLPtrc8MZnEUexeIDLVy7f9ZHU5sLksaw8/u27YNDJzL0D3Yj gnhBGMutWQY7RqINndmIOs9YpZUvYh5PVJkatqpWoJpXn/yeP1FmouOm0jqfBs1MakML mdcc2odzbbKp9XNWZsEj5n5CycrbljeK2Yiq3AZy5XudrPlJ92daM/dBtoSMxzAj8bJA yixoBFE8q/UlK5AbeBf3CqOdp+C9iHkxAoRLPEptmULe3TBS46XDaj3MgQipwk62bz9J gdLfc5CiKTJG9kZHLrEjQFDKmZycWYaz2Dp9SvSq3MHiML33DLsSl5MwJpOikOeJuOKv LiTg== X-Forwarded-Encrypted: i=1; AJvYcCUaT1FBbfp63zXM0080qBu02ocwHUqVEMFNI99bXySPjhq4fGG7k+D3Ybqq/c+lqhHe4FVzm+GryhMvzwA=@vger.kernel.org X-Gm-Message-State: AOJu0YzoKpLXBcI05VIuybvED2xBuJUKi5NGGQXTt55dp85TRU+MHtM/ 0xQ8ISkG+nuJJinqtL0e0otpSCeDGXRzy0k7wm4v+RPaaASHX5EQA7NmxJaBgr6Il+c/3MrHZWo mQMgP X-Gm-Gg: AY/fxX5HUsDl3OanLT02jVYcJa+SIRTEwILq0G2BaZZybq3ogiZ5Ivt3lk75RwrNpds RtaNLFEsUZZJWm0vSbD8lQNOZpNK3M9Zddi90/yXav/Iu8+zM3Z2qgalp3t44kw93lR6drQMJPc gRDzybXLnjpGJcd3eBlxw2DQPkX8FNn1QebXxX3RXc8R5xq+uhXokepQBBzxxQLfvFSOE9MdvIK tg2vcB147Od0+Rd+j9SMTaHhcuAVSuLTEF2928R3UL0pF03mSCR7LEPDrdLKFLIwcHdDy9CU1vl tQ2GUFAig5YmObEVvjDOwuGALMbRTLm5LQ4Crl2m7zlArpkbBROyDtOHvuY5f04NrJX4fcuPG4f vnuto77hJGwk77UxO/7XXh1YXYRHZkp4L+CJ79zgqUDKfJUWomN7O7xO3xPE1SkLogjpyuG1+C1 TClhoNI/Evb5xjQp8LxooVsHFQi7TWw02Y6e//HtM8Qm+x0Vmh/NjkP0AG0F8CQIyviTS3BQ== X-Google-Smtp-Source: AGHT+IFjadPoIlIw6SGjI59tZCwclSAcWIXhM7W6liSGa0PXOk8e+eEyYSDeMbDYFUQqM4JsPhO5iA== X-Received: by 2002:a05:620a:44ce:b0:89f:cc73:386 with SMTP id af79cd13be357-8c356acd43dmr1062406285a.13.1767628480647; Mon, 05 Jan 2026 07:54:40 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8c37ea0f713sm5250085a.15.2026.01.05.07.54.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jan 2026 07:54:40 -0800 (PST) Date: Mon, 5 Jan 2026 10:54:05 -0500 From: Gregory Price To: Bing Jiao Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, akpm@linux-foundation.org, longman@redhat.com, hannes@cmpxchg.org, mhocko@kernel.org, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, tj@kernel.org, mkoutny@suse.com, david@kernel.org, zhengqi.arch@bytedance.com, lorenzo.stoakes@oracle.com, axelrasmussen@google.com, chenridong@huaweicloud.com, yuanchu@google.com, weixugc@google.com, cgroups@vger.kernel.org Subject: Re: [PATCH v5] mm/vmscan: fix demotion targets checks in reclaim/demotion Message-ID: References: <20260104085439.4076810-1-bingjiao@google.com> <20260105050203.328095-1-bingjiao@google.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260105050203.328095-1-bingjiao@google.com> On Mon, Jan 05, 2026 at 05:01:52AM +0000, Bing Jiao wrote: ... snip ... > +/** > + * cpuset_nodes_allowed - return mems_allowed mask from a cgroup cpuset. > + * @cgroup: pointer to struct cgroup. > + * @mask: pointer to struct nodemask_t to be returned. > + * > + * Returns mems_allowed mask from a cgroup cpuset if it is cgroup v2 and > + * has cpuset subsys. Otherwise, returns node_states[N_MEMORY]. > + * > + * Returned @mask may be empty, and nodes in @mask are not guaranteed > + * to be online. > + **/ > +void cpuset_nodes_allowed(struct cgroup *cgroup, nodemask_t *mask) > +void cpuset_nodes_allowed(struct cgroup *cgroup, nodemask_t *mask) > { ... snip ... > /* > * Normally, accessing effective_mems would require the cpuset_mutex > - * or callback_lock - but node_isset is atomic and the reference > + * or callback_lock - but not doing so is acceptable and the reference "node_isset is atomic" is an argument that not taking cpuset_mutex is acceptable since it's a singular operation against a nodemask (one bit it checked) - and therefore for a moment in time the node is either allowed or not (and we make no absolute guarantee of corrected when this race occurs, we just note that we're corrected). nodes_copy is not atomic, and in fact this can result in returning an empty nodemask if cs->effective_mems is being recalculated at the time this copy occurs. Rather than just saying "not doing so is acceptable" - can you please change this comment to explain the implications of not acquiring the mutex a little more clearly? Example: ``` We do not acquire cpuset_mutex during this check because the correctness of this information is stale immediately after the query anyway - this saves lock contention in exchange for racing against mems_allowed rebinds. As a result, @mask may be empty because cs->effective_mems can be rebound during this call. Callers must check the mask for validity on return. ``` The rest of the comments in the function explains a about this, but I think with this update the comments need a little more rework. ~Gregory