From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id B6C352D7DEF for ; Tue, 23 Jun 2026 10:01:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782208876; cv=none; b=ZL6yxybreyzUZNk17uQm9nCkO9x1kuTp+dDl6UqK5JKFju2xdKWwNF4jwLE5uenRKn/0wVLwvTjmUZw6Jv7gPEXmoPwVE3OcbAIMi01dZk7DShJbjd/UXeIfsA7YN+b7vTykfU4PjRV+t+py+1MtjYB1vwKMtGkC12Ru4tzIj9o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782208876; c=relaxed/simple; bh=QssQ3X75aCKMuuN/Bl2WLW7c+ks6QkBQHUfIQL/PJF4=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=QkkVAp+1muhJ8Y5A2e7YqDO0N07vwgPX/M6V9R1MJIklryNzHJTkZuNgnL9OGtM5jBriS/uKOJcpnuOQwEirK09nybqTZBE0E8EoYF8MLY9OJWKk6zT/Gzqa+bHh2BU7tcyVTlEiT/f9lTQBTYbEm6mnWZjeczTBnA6ZTcDAfjs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=O9UNZuuX; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="O9UNZuuX" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 51A151A25; Tue, 23 Jun 2026 03:01:09 -0700 (PDT) Received: from [10.164.19.14] (unknown [10.164.19.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 69BFC3F62B; Tue, 23 Jun 2026 03:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1782208873; bh=QssQ3X75aCKMuuN/Bl2WLW7c+ks6QkBQHUfIQL/PJF4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=O9UNZuuX24DFwpJHUI1a0hPd4j3c6Il2S23sHHX82IZjgGUkk2gO4w7np0CzUh4sJ i/DVZ3/0pBa+MIDakGjwPobFD07nVtPAcd9xtsqhdb5avace5qOXKG3ZdCNgz3Umr+ o4F8nElCEKvwtiSdC7hPyN4dNn9JetgS95I2rZgM= Message-ID: <562addc1-b334-4258-b0d2-0154ffed061b@arm.com> Date: Tue, 23 Jun 2026 15:31:03 +0530 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 v4 04/12] mm/memory: Batch set uffd-wp markers during zapping To: "David Hildenbrand (Arm)" , akpm@linux-foundation.org, ljs@kernel.org, chrisl@kernel.org, kasong@tencent.com, hughd@google.com, liam@infradead.org Cc: riel@surriel.com, vbabka@kernel.org, harry@kernel.org, jannh@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, qi.zheng@linux.dev, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com, baolin.wang@linux.alibaba.com, pfalcato@suse.de, ryan.roberts@arm.com, anshuman.khandual@arm.com References: <20260526063635.61721-1-dev.jain@arm.com> <20260526063635.61721-5-dev.jain@arm.com> Content-Language: en-US From: Dev Jain In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 16/06/26 7:13 pm, David Hildenbrand (Arm) wrote: > On 5/26/26 08:36, Dev Jain wrote: >> In preparation for the next patch, enable batch setting of uffd-wp ptes. > > Avoid talking about "next patch". Phrase it as "In preparation for batching...". > >> >> The code paths passing nr > 1 to zap_install_uffd_wp_if_needed() produce >> that nr through either folio_pte_batch or swap_pte_batch, therefore >> batching is correct: >> >> 1) all ptes belong to the same type of VMA (anonymous or non-anonymous, >> wp-armed or non-wp-armed) >> >> 2) all ptes being marked with uffd-wp or all being not marked (same is the >> case with the pte_swp_uffd_wp_any check) >> >> 3) uffd_supports_wp_marker() is independent of the function parameters >> >> Note that we will have to use set_pte_at() in a loop instead of set_ptes() >> since the latter cannot handle present->non-present conversion for >> nr_pages > 1. > > Below you have > >> + /* The current status of the pte should be "cleared" before calling */ >> + WARN_ON_ONCE(!pte_none(ptep_get(ptep))); > > Could we easily extend set_ptes() to allow for non-present -> non-present with > nr > 1? We could have a set_nonpresent_ptes() in general, but then for some non-present configs like in this patch, we don't need to change the pfn, while in some configs like setting swp ptes in one go (like I do in later patches) we have an underlying pfn. So I don't see an obvious simplification with a common helper for non-present -> non-present for nr > 1. > >> >> Rename the function to cond_install_uffd_wp_ptes, and convert the >> documentation to kerneldoc format. >> >> Move the function to memory.c since this has grown too long to be kept >> in mm_inline.h, while retaining the inline hint. > > Well, for functions in the header you really need "static inline", so it's not a > hint and I would just drop that comment. Ok. > > However, the move while modifying a larger function is rather suboptimal for > reviewing (more like "spot the difference between these two pictures"). I'd > suggest moving it in one patch, and thenb modifying it in a second (this) patch > instead. You can perform the rename already while moving I think. So I'll move the function, do the renaming of pte and pteval, do the kerneldoc conversion change in one patch. Then batch and rename in the next. > > > Nothing else jumped at me. >