From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f177.google.com (mail-pl1-f177.google.com [209.85.214.177]) (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 AB1F73093BC for ; Fri, 28 Nov 2025 10:13:47 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764324829; cv=none; b=VUi1kS1Q8PGMkk3LKDdKPxYvO8o3fNpLNBJD1jTRZ15/EiTykngqCKHFfy+M74+EDOYRy0eEN28nHoWV266DURHb4/r7Sk42VnlGzsF7uS5kfUsEuYQ5nq37ASMhKvCzb1wRvYciM5KqcDF7YGXKLFakoNsDFUfFDTuEtNQq2Ds= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764324829; c=relaxed/simple; bh=HM41ISNrJltYhygabv7j4e2EYctmwOaf1ns2APiRXMU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=CKrIJHnbohZSOxsaB2VCJlYUJmHRCWOiWmgeCLN4m8J45UGIXA2MOWGbWLDsArJ48ZZc6ZaGyuDptIOxm2WmvlMWpoO/guDEiiwwKjn9mgnBT3/SjgAORxgtoiGp0UXUqsReZa1dmBOgani1uJ5G5OYDS8JXd8dc0QkVQ6xUaRs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=nUVgXkmE; arc=none smtp.client-ip=209.85.214.177 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nUVgXkmE" Received: by mail-pl1-f177.google.com with SMTP id d9443c01a7336-29812589890so20720205ad.3 for ; Fri, 28 Nov 2025 02:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764324827; x=1764929627; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=TF1TVmEV96HQsz0MmZJVIJp9RiSijpMUr1apSsU5F/E=; b=nUVgXkmEK0tmch/wFM1oPoxQcsvRF+INLaLSa+5PHCbuEm5hbM3f0OnqBY/ktCoLQm 0ddKjkTxekFHjfUnG8KiPDDbd+TTGgTbTqv9cXqlQlc62udUfmjALgKclfNnZAeBflPW TJokXePBvjHmYxA90oWnWScosTLrZCQpq42Nk0iKizi5STUYg3EcsNvXFvJRm+lWnnU4 8Y6HDdj5IpISiwqhoT+7z7dU0dxGBYimlSXqICLiPppS2AbG3eePutHHXzrWdmgdLY6c 0RETPDA2slwLoMGcUoQhX2MTGijX0SxuDwPrQBCDxLd52pwiTnGLIv4DsEQ0eit1psLJ DiVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764324827; x=1764929627; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=TF1TVmEV96HQsz0MmZJVIJp9RiSijpMUr1apSsU5F/E=; b=KDLWND9m5HRe2DCu5uiCDrVioksa0nqGSp0Xq7grZpjry1JbC9jCtzAtAyJgSQtPEO bHhfJgLZGxLAkxQLhXhpATYGvZf6hNqn3teCbCIaFHnVlG0/+lv4WYCJ9MeJ+LpG5/xM U+mscAiYpEooaA6bY02Kh9RYYK3AMDL03Ipxy9JVuRQ0QliKBPSo3WVk0dmwSMM7CdJ0 2IT+2TgfVByU0R3OsRYVYLunFO2JjZasUXobRVB2OXQly43SKr7CHrr961kJI/GjJUah MrIe2ufB70MmbjIfh3LyVTUsEM8FBG845LVMxDwpYMgmfk/SdX4wtb6PllFre+6NH62v lRWg== X-Forwarded-Encrypted: i=1; AJvYcCWeRe7BQa6aobZ84XGnlPAZOioCJfLuotvupbgtcCI5sAYkdfIW/3JBzLbDYlazUBjPiuoXBt8gZA+NJcY=@vger.kernel.org X-Gm-Message-State: AOJu0YzutT7owKiS35AjQANIlI7WVAZtHPfdJKH3klKyI4hjNCOz2EO2 oAZ3SbZU0sfVrNPEFdVIhVEySBky1m9Ut2FPnhrOghEMpnCUi1ahkGsI X-Gm-Gg: ASbGncsY2s7W/2dzar6d43VLlJD4/UUys10SeAueMSuUzMBU0JxNYWgP9JjIeV3MHXk ihlaTcn7QaFJpkVfp02f8gn33XBi2kmHY3iYOoZd/uzl3Az6o77fs6kV5RzfumYda2mriakI8ZQ qxq32F1hbA8iaOmaOdGyVaH+gYVrFNJ33T6agKLYa2qDlyOg8T6/3lagnFTYX2uxdsQby6AVdN0 UPUPLxWADeveQAPlv4tMsOljuA8Z53LRDclqAD4rKFxR6dx5GbEBZ05uqMdmegVb0V+u3QXMnBZ at6kAOZnwYlb7PL2jvV0+r14UBd7nVnvGLAhWqZZjq7sAGtfQ1Bt9G+tiUJ62Kn/CGFSVu4lXDi 0BIdoFgdiHGb22PrI7QEayJgS9UuYMBTqqx2LbUcQhq0/kZf3V3ikBaDCPgOES+QeoQNPE2oBVx xffg== X-Google-Smtp-Source: AGHT+IFfPZt6tf+2hnPx4fpBVD/lhnrTvIZnWVU86KRnNT0ZMPToT4zwqgBG/WyBvvA9f2XZf9zocA== X-Received: by 2002:a17:903:947:b0:28e:a70f:e879 with SMTP id d9443c01a7336-29b6be8cb2dmr298158685ad.1.1764324826660; Fri, 28 Nov 2025 02:13:46 -0800 (PST) Received: from EBJ9932692.tcent.cn ([2403:2c80:17::10:4007]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-29bce41afe1sm41236035ad.1.2025.11.28.02.13.36 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Fri, 28 Nov 2025 02:13:46 -0800 (PST) From: Lance Yang To: david@kernel.org Cc: akpm@linux-foundation.org, ankur.a.arora@oracle.com, boris.ostrovsky@oracle.com, bp@alien8.de, chleroy@kernel.org, dave.hansen@linux.intel.com, hpa@zytor.com, konrad.wilk@oracle.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, luto@kernel.org, mingo@redhat.com, mjguzik@gmail.com, peterz@infradead.org, raghavendra.kt@amd.com, tglx@linutronix.de, willy@infradead.org, x86@kernel.org, Lance Yang Subject: Re: [PATCH v9 2/7] mm: introduce clear_pages() and clear_user_pages() Date: Fri, 28 Nov 2025 18:13:29 +0800 Message-ID: <20251128101329.86934-1-ioworker0@gmail.com> X-Mailer: git-send-email 2.49.0 In-Reply-To: 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 From: Lance Yang On Mon, 24 Nov 2025 11:26:56 +0100, David Hildenbrand (Red Hat) wrote: > Replying here while I am already at it. > > >> +#ifndef clear_pages > >> +/** > >> + * clear_pages() - clear a page range for kernel-internal use. > >> + * @addr: start address > >> + * @npages: number of pages > >> + * > >> + * Use clear_user_pages() instead when clearing a page range to be > >> + * mapped to user space. > >> + * > >> + * Does absolutely no exception handling. > >> + */ > >> +static inline void clear_pages(void *addr, unsigned int npages) > >> +{ > >> + do { > >> + clear_page(addr); > >> + addr += PAGE_SIZE; > >> + } while (--npages); > > > > Why a 'do while' instead of a 'while' ? > > More efficient when we know that npages > 0. > > > > > Are you certain that this function will never ever be called with a nul > > npages ? > > That is the expectation here, yes. We should probably document that > expectation. > > > > >> +} > >> +#endif > >> + > >> #ifndef clear_user_page > >> /** > >> * clear_user_page() - clear a page to be mapped to user space > >> @@ -3901,6 +3921,27 @@ static inline void clear_user_page(void *addr, unsigned long vaddr, struct page > >> } > >> #endif > >> > >> +/** > >> + * clear_user_pages() - clear a page range to be mapped to user space > >> + * @addr: start address > >> + * @vaddr: start address of the user mapping > >> + * @page: start page > >> + * @npages: number of pages > >> + * > >> + * Assumes that the region (@addr, +@npages) has been validated > >> + * already so this does no exception handling. > >> + */ > >> +#ifdef clear_user_pages > >> +void clear_user_pages(void *addr, unsigned long vaddr, > >> + struct page *page, unsigned int npages); > > > > By doing this you forbid architectures to define it as a static inline, > > is that wanted ? > > Note that this is not the intention. The intention is to either use a > direct mapping to clear_pages(), or fallback to the variant in mm/util.c. > > The architecture is currently never expected to provide clear_user_pages(). > > Wondering if we can make that cleaner. > > I'm wondering if the dependency on highmem.h here in mm.h is rather the > problem. > > How I hate this macro crap with arch overrides. > > > > >> +#else > >> +static inline void clear_user_pages(void *addr, unsigned long vaddr, > >> + struct page *page, unsigned int npages) > >> +{ > >> + clear_pages(addr, npages); > >> +} > >> +#endif > >> + > >> #ifdef __HAVE_ARCH_GATE_AREA > >> extern struct vm_area_struct *get_gate_vma(struct mm_struct *mm); > >> extern int in_gate_area_no_mm(unsigned long addr); > >> diff --git a/mm/util.c b/mm/util.c > >> index 8989d5767528..3c6cd44db1bd 100644 > >> --- a/mm/util.c > >> +++ b/mm/util.c > >> @@ -1344,3 +1344,16 @@ bool page_range_contiguous(const struct page *page, unsigned long nr_pages) > >> } > >> EXPORT_SYMBOL(page_range_contiguous); > >> #endif > >> + > >> +#ifdef clear_user_page > >> +void clear_user_pages(void *addr, > > > > What happens if clear_user_page is defined but not clear_user_pages ? In > > that case it seems like the definition in linux/mm.h will conflict. > > The generic mm.h variant will not set clear_user_page() and consequently > we map directly to clear_pages(). Hmm, I suspect there might be a subtle issue with the build flow on SPARC ... Inside include/linux/mm.h, the guard checks for clear_user_pages (plural). Since SPARC doesn't define that, the header provides the static inline fallback. However, mm/util.c includes that header. And since SPARC does define clear_user_page (singular), the .c file proceeds to compile the non-static definition as well. Wouldn't that result in the compiler seeing both a static inline and a non-static definition in the same translation unit? It seems like this would trigger a redefinition error ... Thanks, Lance