From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 988F2C369AB for ; Wed, 16 Apr 2025 01:34:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 052706B00A1; Tue, 15 Apr 2025 21:34:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0001E6B00A2; Tue, 15 Apr 2025 21:34:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DE29B28000E; Tue, 15 Apr 2025 21:34:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id BDE416B00A1 for ; Tue, 15 Apr 2025 21:34:47 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 052AD1CF0E0 for ; Wed, 16 Apr 2025 01:34:48 +0000 (UTC) X-FDA: 83338187856.09.1D3E1D7 Received: from out-184.mta0.migadu.com (out-184.mta0.migadu.com [91.218.175.184]) by imf04.hostedemail.com (Postfix) with ESMTP id 17AD440004 for ; Wed, 16 Apr 2025 01:34:45 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=q2Y4RuaI; spf=pass (imf04.hostedemail.com: domain of ye.liu@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=ye.liu@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1744767286; h=from:from:sender: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:dkim-signature; bh=G7qJ+O6AudU15nAQNGAyxHo/Rn7ubP77f07kony7XBE=; b=eV+iKC6iWwSYsulKcvsEMfYuKhcIlry3gYUDrOgcNOwTXirvyKPqKVxcW7ybNxSdiZCBFE OY3zZf61wxrR1X/aram8/2qSyj0E85xkUlDZujneYkGHq4PXiWAzLl/gF20YtDf4npkuTX RrzusI35XRTIjLw6xU85TOeFOcR6oxw= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=q2Y4RuaI; spf=pass (imf04.hostedemail.com: domain of ye.liu@linux.dev designates 91.218.175.184 as permitted sender) smtp.mailfrom=ye.liu@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744767286; a=rsa-sha256; cv=none; b=kixTJNOYjzvUKWqYYWyjHyz4nw1M4Ho5W4zMJFhIvL1KuW4tx3Xgq83LVlnrHpplRGaLr0 oMJG9N8lJXM3Xb30cGxC1237yQ0kJvAVPgX9gPxhazGq7iEeBWB4zqOuQgeLGEP5qDn72b jZZdDzSitj/7EprhmXeFDHzI8nHbVaA= Message-ID: <0696eaac-943f-4116-b682-f9b15de6aeaf@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1744767283; 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=G7qJ+O6AudU15nAQNGAyxHo/Rn7ubP77f07kony7XBE=; b=q2Y4RuaI3nFA3ccoh2YiR/vE3O+lp7fMvmRU+IQuehiurj350KmQnc7L7x5TmIWyOiJwH6 ia1SczifUTw+LEi2T8vdfPJSn72x+Dc80MWoTwzrgJo9I5LG491N6/mjbGyUl6wke32sYJ xmKCTr1lfqi0lp2cJhwYJsweIUqeQTE= Date: Wed, 16 Apr 2025 09:34:30 +0800 MIME-Version: 1.0 Subject: Re: [PATCH] mm/rmap: Move anon_vma initialization to anon_vma_ctor() To: Harry Yoo Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ye Liu References: <20250415092548.271718-1-ye.liu@linux.dev> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ye Liu In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 17AD440004 X-Stat-Signature: oneifki6u46rnm6rcq6asck8fxbyjeii X-HE-Tag: 1744767285-236083 X-HE-Meta: U2FsdGVkX1+ccKBclsKEZZGuAR3HjinA04zFFYU5/Ewc4A1RqHHcIK34c7FqAgWE1Nrusp40pRmQJ6fHNNHlnzerjhTtxxQGFwPwZjDoEfVI72SAMnEMbsbJNhgdbypQtLOKEkKg3V/2SsMvZrE1eVfidVMtnn8LOu8OkF0sTmrypQ0uCm9J8AuJQLhEi0Nj9nw/ZUwimaaWe/mMgesmsCj9/tJnU4vlChbE6goF0FRfksSxSeaqdwvNLQpIHBQa31i8K+5sCBQVFkFPLda3Cl2E+v4QwnlABVvc5jwcsxbK2EmaRMaQBg0mXayZzpyVM7DHQHXMVVzrvSV5zf5yoWL3OlNDNZR8jyIFUVZhhpqYfFbY8yw72/ooWIiCdaUSmq65nlYqT5hl9NlyBTouMqMMDYYvEvMM9LPY56MRXmSAQ+YWSB61tStGWnDCqWiFxX63wlQ2UvVgxbW+J9mizNR2ml6GFFJcUCVZzazjPVkxqYzi+5TBv51I4Xz5nefuZbvOVzp7klqclQnDDEDTS8lGHP8Fs7rXJFwL/Opq2Z3AaSPFXNAfqYwuOHjqGQSiMiUdfUeohJYujMh+t/thQMgVu6KQ56JZnnWG16TMRGk8rojKxQBKByy8JMFnHxUe3UkqH4zidKFfZcBL5zBPsLqvNjWB6vPAtptganiq2qDA9QRegStqc9NobGhSVIPPOTpdgYe4/Yemj6g8zA096MeEtDCPIMGh72nmcQITZTA9krifCmkGFRiyWxxOkxD+ou2xryoDzI8BBxgspgVX7WPT45xFM/g4iFyfJuY9i7DPXLNb+OVVOpnx+w2gxDaGDLow45X9ZIL59/Ws1r/3QapxYxNmEyAnY8Dr5SJrw3P4CwcwskKDJUUGEnelRNO/uYGzHZTvQtscjK3osUtzvHZucAOKQj8sMB+l4HszOXWAsVVliLpuW9vjfdn2rVb9jSNFyf37kK9OaNg6pfD xlc+piqr vQDdWAZapHuQqz5junim+cKORQ7CXKDFMXwPt/VomPwWiGO/WFSDsMzT9JEG53vj+K5kuGtDKRSeXH5Emz8ie6zMOjWA2O99T4ngsSTxuFAP7tzZ3n2JeruKIqUM6xWdO2n6nQn7Lot8arNGwchqRL2/b2hy4RkeHHSXaMn/UTvpExmjxp1U4THuThjqGG+tzJ9ua4qo9auYsZKkzSdMT9o2+r5lo8OHrNK1Dt0wkJ/FvSQcNlqEiaq4MWdL6mCOG4U6P X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: 在 2025/4/15 19:28, Harry Yoo 写道: > On Tue, Apr 15, 2025 at 05:25:48PM +0800, Ye Liu wrote: >> From: Ye Liu >> >> Currently, some initialization of anon_vma is performed in >> anon_vma_alloc(). Move the initialization to anon_vma_ctor() >> so that all object setup is handled in one place. >> >> Signed-off-by: Ye Liu >> --- > NACK unless the patch explains how the object's initial state > ('constructed state') is preserved between uses. > > anon_vma_ctor() is a slab constructor. That means it is called only once > when a slab (folio) is allocated, and not called again when an anon_vma > is allocated from an existing slab (folio). In other words it is not called > everytime an object allocated via kmem_cache_alloc() interface. Thank you for the feedback. You're absolutely right — I misunderstood how the slab constructor (ctor) works. I had assumed it would be called every time an object is allocated via kmem_cache_alloc(), but I now realize it is only called once when a new slab is initialized, not on every object allocation. > This patch looks very dangerous to me and makes me question whether you > tested it before submission. > Appreciate you catching this — and yes, I'll test it more thoroughly before submitting other patches. Drop it. Thanks, Ye