From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) (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 08AC13B19AC for ; Sun, 2 Aug 2026 12:16:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.189 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785672991; cv=none; b=GhDloxJC5b9JwsU5iEkMYN7T8JaWMGNDSACeei01o6BRIy9OAwk0pI9bNIfTofL8siXPcBORtNbkrBQJ4AHhVxSrI96/g0oMK02kRZodWoLx5GOwWqVAGbVIM0S381WHLIJENzVbX2F+0Z+fYDIHhIXT58XCOnB9pFc5RHlO7bE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785672991; c=relaxed/simple; bh=ScKBauMXPALIVWX1GX1OCN0yQfAIOMgHSGuv9oFskH8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=Hsz3Ei5FqmPq1tCvDLtoj5E9tcgflEry8IiN4PSE/iqiORDt6893dJ7/2dQg8ppwKAjlZS6XbFXCczQFzBpj4nVNe3R1k8bYQLa0TSr8s1sDiry8AjkQlqv/JHileSyI/71Wt5b9h6SLnhGhfDF7feE99h7cs21CTZYC8T/NHCc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=m9RfD4K1; arc=none smtp.client-ip=91.218.175.189 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="m9RfD4K1" X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785672980; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=j3oeIu1NO1s3LH22n1O12mVtuttJMeqOoFdM19I5ia0=; b=m9RfD4K1o5ZHsE+3Sj33aVH5mGou/ZnrDu+jrIoNw6LfiuPjpRUWrO9vlbO8q6fHgSadH8 xPt4D7A0BcDKrfEKpmPi0RVOMcS5nkw9ihECZXvoRJW2Vk4Fg4Z2WuWUuenlXQkLacStHQ wTOwDN+GA7Y7+unHikiw7354IdBKdjM= From: Usama Arif To: Zi Yan Cc: Usama Arif , David Hildenbrand , "Matthew Wilcox (Oracle)" , Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador Subject: Re: [PATCH RFC 05/14] mm/hugetlb: use direct assignment instead of folio_change_private() Date: Sun, 2 Aug 2026 05:16:12 -0700 Message-ID: <20260802121613.1590412-1-usama.arif@linux.dev> In-Reply-To: <20260731-remove-pg_private-v1-5-142c97ba3562@nvidia.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT On Fri, 31 Jul 2026 22:13:28 -0400 Zi Yan wrote: > folio_change_private() should be used along with folio_attach_private() and > folio_detach_private(), where adding and remove ->private content requires > folio refcount change. add_hugetlb_folio() simply sets folio->private to > NULL without refcount manipulation. Change it to direct assignment to avoid > semantic confusion. > > It prepares for a future commit that remove PG_private. > > No funtional change intended. > > Assisted-by: Claude:claude-opus-4-8 > Assisted-by: Codex:gpt-5 > Signed-off-by: Zi Yan > To: Muchun Song > To: Oscar Salvador > To: Andrew Morton > Cc: David Hildenbrand > Cc: linux-mm@kvack.org > Cc: linux-kernel@vger.kernel.org > --- > mm/hugetlb.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index a77c3c1cb8943..0abaeb47890cb 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -1433,10 +1433,10 @@ void add_hugetlb_folio(struct hstate *h, struct folio *folio, > } > > __folio_set_hugetlb(folio); > - folio_change_private(folio, NULL); > + folio->private = NULL; > /* > - * We have to set hugetlb_vmemmap_optimized again as above > - * folio_change_private(folio, NULL) cleared it. > + * We have to set hugetlb_vmemmap_optimized again as hugetlb page flags > + * are all cleared above. > */ The return value of folio_change_private() is never checked so LGTM. In the comment, saying "above" is not very clear. How about something like: /* * The hugetlb flags live in folio->private, so the assignment * above cleared them all; restore hugetlb_vmemmap_optimized. */ With the comment clearer, feel free to add Acked-by: Usama Arif > folio_set_hugetlb_vmemmap_optimized(folio); > > > -- > 2.53.0 > >