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 DF8643E8352 for ; Mon, 8 Jun 2026 19:59:16 +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=1780948758; cv=none; b=cIqBHICyhnhvQWdtWgyqxHgDGLC7VSMNTXlCCnWQwFrg/V8TmL1fNE/JPXBD0QNV4gQJJDP/54Aa+e/RYL5dqTOGjctcbtwIOyfXi3/h1n/H9e3KQarmbYK+ubbxdoeRnp3WYXba3c6tW0pzjuTiSwfdqCy3NMnYOgGFXshWCeg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780948758; c=relaxed/simple; bh=nC/1q8EJEgXGdRfM0fgAm8GRfOb2Sflm3M+qFkNWGug=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=KsXIVvY9UtOUXJncqdY+uNKY01s0WOcBJZI2Wfu2Ejiheh3K4Efgz7IYtJPhkflsvloCZVTO2oDTtUj+MedmRsAd/O2yl9vm6+9PTpCzUdW9pQMjLMu3wcJd+Yz15w4zVVxmFxP6h5fqLUdOGvyRykj3BzWyI6EHzd5ekA50vEg= 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=QHH90FSc; 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="QHH90FSc" Received: by mail-qk1-f171.google.com with SMTP id af79cd13be357-91578122305so785431685a.0 for ; Mon, 08 Jun 2026 12:59:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1780948756; x=1781553556; 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=7Xwdm1oiBGcy95PBpOYBrMILZr7DavlHrl7pDmQKHX0=; b=QHH90FScfJscWIDUcaIKBJCTq9Y4ZqIOgDoEyRCONrw+UO0XFMFpH7pAojh2L+z4se nxph6p0NserKqhlXv0XoMet404NLYOeZqss+4lzOb/1Nt8RCgdzbJlw/0+zIauFy+TGj eIbKpsvEonKP2EQXWhlCobhlCiclUJiU181Dw8+FC56sofCYlfgki6guUl1xSqoRSKPJ G9et5xMq+gHLpqe3oLFmYAsMbODobrgsmJVA/cs68QrRsBWWxilj6lFE3WlZ1CwLePwg 2Xt7oLS0wA4QKGMa0sFqURtM5W0S1NYM6KmowiH1W8y5WqevHvMc38JrPHBRgdtPzfqQ MF6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780948756; x=1781553556; 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=7Xwdm1oiBGcy95PBpOYBrMILZr7DavlHrl7pDmQKHX0=; b=dzhXozUDH44KFQAb4ipxJ5BcSQLhXyUqdecpkPc6dpMMAt8kAH4Z4AyHmSREIgIosm YQchGwFhLuPKZkliGyQUMpik1jVqOJ84RffIGFdMsNLxHIe2tiBYndsAN1HTMJL0e3T5 s3/+V181fbLiNdHdl4DqSeA/bqEk4MGtYytVKsmjlHLtBzYgTxBCAqqVu/xT92YNdb2+ BAvygifZEKTBsv5YLYpO9yQPJXt/8EiUdAnSLa0k4nceDfE0xNPrEmaRmt86Y+hcRvbu h26onCx87Bkj3hpPVeOIYBJ+KEBq7crSpbb41AOzd7PzIu+PIL3EP+OkL3hk7/5J1pPh OcNw== X-Forwarded-Encrypted: i=1; AFNElJ/GGfTiLj3RW9GvgSI+Z6iOUWXL7snCkjfEUuRO7nhI3duCj3Ik0JSGjQRU3TmwwDbzi+KzxO0JDf7iPYs=@vger.kernel.org X-Gm-Message-State: AOJu0YwdiSOoLxMu0p9KMn8GY0QzaC4otN+n8cxZ0SMsXtA2R97Jf2y3 rjMYWlom3zEOhxRCMs3UftU6VXPymuMPsGihhMO7wGF87z4qmEcJWN5ozfiSXgC/ZMg= X-Gm-Gg: Acq92OGmXyVanZjC6BVuZK4Ufe0w1rEg/F7KVTT+sneDlf/tF8TunA2ONhaX9xPymRc oeGKi4P/GKQBpzKb5MwXUO6pbNnkgZgs3oIOxukXpSd1lNutzJcWqhI/4f7oz1PxBhDZR19NuGD RsDFJSCQ2C2XDk9PT7+1ubvcx4GVMDnrz8uOYHvOFwAYnyjQkjMPv+xsL8enep28vD3viEzhWtc Cl8b5ukl9gN/+YIcxyXpb3RIOvmn3gzoSir8xplr2tO+CF/BnlM4ITNLXzwRbJbImHEYuBaDEts QDG2zsExsxgXDNmtGPSEIRlbGyqS6dwCtfsMybKR0OvQruh+XvQDfpGIKOgZvTtke89jTPgpJLl W7/MbPrTDBxsNrno9Bdt6InnjdqTxYBgIFQmsELRIPlf2RyoV4uWRDUMhhvMf+gC+9f3dcexB6Z xje/Z23d1vt1EtmHjoSAddpiPWS+pD0Mo+Mq4EqNe2blQMJ85NLkx9ZcuuvBre7MoEb9ViMspR4 cU+Q8TTmgN8MGEuiA== X-Received: by 2002:a05:620a:a0c8:10b0:914:babf:9f56 with SMTP id af79cd13be357-915a9d763b4mr1978857285a.39.1780948755844; Mon, 08 Jun 2026 12:59:15 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-173-79-60-52.washdc.fios.verizon.net. [173.79.60.52]) by smtp.gmail.com with ESMTPSA id af79cd13be357-9158a3c2492sm1978154685a.34.2026.06.08.12.59.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 08 Jun 2026 12:59:15 -0700 (PDT) Date: Mon, 8 Jun 2026 15:59:13 -0400 From: Gregory Price To: Matthew Wilcox Cc: Lorenzo Stoakes , "Michael S. Tsirkin" , linux-kernel@vger.kernel.org, "David Hildenbrand (Arm)" , Jason Wang , Xuan Zhuo , Eugenio =?iso-8859-1?Q?P=E9rez?= , Muchun Song , Oscar Salvador , Andrew Morton , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Hugh Dickins , Matthew Brost , Joshua Hahn , Rakie Kim , Byungchul Park , Ying Huang , Alistair Popple , Christoph Lameter , David Rientjes , Roman Gushchin , Harry Yoo , Axel Rasmussen , Yuanchu Xie , Wei Xu , Chris Li , Kairui Song , Kemeng Shi , Nhat Pham , Baoquan He , virtualization@lists.linux.dev, linux-mm@kvack.org, Andrea Arcangeli Subject: Re: [PATCH v10 07/37] mm: thread user_addr through page allocator for cache-friendly zeroing Message-ID: References: <50d410b47fe3f45327783e05bd306d5eaab75e65.1780906288.git.mst@redhat.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: On Mon, Jun 08, 2026 at 02:04:28PM +0100, Matthew Wilcox wrote: > On Mon, Jun 08, 2026 at 12:06:35PM +0100, Lorenzo Stoakes wrote: > > But instead of overloading user_addr to indicate all kinds of things, instead > > make life easier by actually breaking things out. > > > > Like: > > > > enum alloc_context_type { > > KERNEL_ALLOCATION, > > USER_MAPPED_ALLOCATION, > > USER_UNMAPPED_ALLOCATION, // Maybe? Do we ever? > > /* Perhaps some other states we want to encode? */ > > }; > > > > struct alloc_context { > > ... > > > > enum alloc_context_type type; > > unsigned long user_addr; // Only set if type == USER_ALLOCATION > > > > // Maybe something suggesting context or whether we init before in some > > // cases? > > }; > > Ugh, please, no. As I suggested last time I commented on this > trainwreck of a series, lift the zeroing functionality from > alloc_frozen_pages() into its callers. This sort of just implies writing the "alloc_frozen_zeroed_pages()" wrapper that does the zeroing at the end before return, and then killing the post hook nonsense associated with it in the first place. None of this resolves the user address annoyance which is needed on some archs for cache flushing. Whether anyone agrees that the page allocator should be responsible for this particular operation - open debate. ~Gregory