From nobody Mon Aug 24 04:18:41 2026 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (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 892ED3A7F57 for ; Sun, 16 Aug 2026 14:38:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786891130; cv=none; b=uAzGsm2IOzbcbGVJ8iiXCVV58s8LcSN8aXuh/zsGLi7XdYoG8oCI0YRbmJezwYPr3vD8wYYTow6kl9HEKN5c7pifTBf57ON4HSMNKuUT6zLQ7gFIjDjq8bEuekEu9hojxAd1+zJVCRsuC81F7NnzAWky9Q8tKkUUD1+bA5IGepY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786891130; c=relaxed/simple; bh=OSGF5aF4lCng+3oyBXwszL6XCTX6OlO5azK2Q+r7+rc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=vDXUP+E4n+O1Ro5sg+5PPOOZrYyzZc+v4zAtsfv/JDTsRFhmZ7139/1FqppKwO1HZOYo2Kd4gqDyMYowyoAD3GuJ06n3F9OQkEfPyEEnEy/VDptOhvO3p2t0Wko36T/ofKXGSxZ5cHUXipPFg7AReTvaR3HNHLDn4iUwH0h4RWA= 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=nzHNBH+A; arc=none smtp.client-ip=209.85.128.50 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="nzHNBH+A" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4955aa106b1so22185015e9.0 for ; Sun, 16 Aug 2026 07:38:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786891126; x=1787495926; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:sender:from:to:cc:subject:date:message-id:reply-to :content-type; bh=slKPyCDrN2MNA+O23XO0ScfIg+YQ5ZR+PoLwJeEJvyE=; b=nzHNBH+Aua6mL48yxg1hBsv34JEJXS7C87HO/GNe3bGlU7SUg8FjwEOBITq6eMRT3J Ss+B6kq/1iqIwWlU+KUqBwuawpzoMQC82nS6laf+8LHescmimHIr2mXiZGUVlGCNOjig 0fHv6oGyvRvfIJHMeyZYGW55t25Az+LectpI+lKGHqhsPATarnXP6Ws/OQrMgiGfmNTP 0eXNI2lN+R4bAY7DY9RtGEZMQjm/9ydnOmQ1Ybkz6GW/SLv2s6Qz5zNhN0DCKlO7WwEe ogbtpU/lVXgKEroARzzSrdg73SjusqbC6QG+wEkNVxtiQ0YZI+uJip3KISSO2VJuXIS2 NyoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786891126; x=1787495926; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:sender:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=slKPyCDrN2MNA+O23XO0ScfIg+YQ5ZR+PoLwJeEJvyE=; b=Um5dNMYY93XrhOVIPCmy1hZK3VsRXBxJnSLV8RBmtNIDCacsWNlhAGlUz8TUyhipzk 73Lx0R7sFbz/1HdxVpooSGdwyvFqqn2iB+9Nn0cJfP9Z9ZrLhsI5UYnMYqMaEhDjn18W 6BeqnIxVYuOdxd61XI9k0IAdcacBM6oDcrfSQz+Z19TT0jf97nCzOFPyP97ydyECacJl O0vZePeF+D7Sup3bUcUBE3IPN9paQWu1qWtV3wcV1vDjixbkDOtnCLBbl2aNAwdKM8me Jkr2ADtxDv4j1LKxTJMpdVKSD0mNhNgTuNvLpNPsFtMUrF7/DOkQQ9UsTBby+nBHXLkq 08jw== X-Forwarded-Encrypted: i=1; AHgh+Rpi1SFR256sOFSps6cClY6HrdiokAXWyiSXtUdK7D7VJ2QL/P6UInsyfc4p+xikKTO+vvGz9DL1vo5/TEw=@vger.kernel.org X-Gm-Message-State: AOJu0YwVngxGfkZW8CGoC9ZS76r1ObCvO9x/iUI2A59aytZNAoc7Pyxq 36aD4MmF68/mUvjec3CB23rJZWbMVf34rodP3088oku4Se64u4kcVVI1 X-Gm-Gg: AR+sD13fHwyZTr9DBhIPx2qBV4oZlL8cYpT21run8iJG4MrRvZWvjwZDVLliBb58/1j 3E2bXJXldf6mnGbOYCZaf1a50yznyhW4MBf/ZBNHj5a1eocQUMwKC0aifwn2HE96riCdUWXacP6 GBSEH7SImyphykMvB1oPn0YlVKff8OfGoOHmC7nP1KV/D3B5iC9TE02W7a07fUaPEAHSiT0PSkv VYwOP2Je3ht3Pm0Eqs9umpibdA1I+Oa2RTSn8ufwJLvyZU7dOP8vk0ZO+3UH4y1yi+QtsG4a3lk rTDtkDDGk17HgNSwN3Yq+ht+AzWkEPt5THpjR0JBHyE1neJX2PjrgpNRyzn7Up5dBTcp6grx9Ko QMMw03l0qO4S+No2lqUFfLDBT6nGUdgjbZAcguD9C3W+AhTbMiqhB9wx1yxWmepppNdfW5q1kgv IEt308XO2EWuFDPqfEmvxZushMR3eosx5fbAfyNJ8F3T8UM1xNR2ZMbZAEHZIA0zwCOdopdoPn9 lmujJfD/ZMJikMZH3H09CA7o44MU3fLpcOgg7DuH4pcfWbfIqgv X-Received: by 2002:a05:600c:6290:b0:495:4689:1e98 with SMTP id 5b1f17b1804b1-4998e074297mr203471005e9.10.1786891126238; Sun, 16 Aug 2026 07:38:46 -0700 (PDT) Received: from nixos-office (195-23-151-163.net.novis.pt. [195.23.151.163]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4999611b043sm72992295e9.12.2026.08.16.07.38.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 16 Aug 2026 07:38:45 -0700 (PDT) Sender: Julian Braha From: Julian Braha To: richard.henderson@linaro.org, linmag7@gmail.com Cc: qi.zheng@linux.dev, akpm@linux-foundation.org, viro@zeniv.linux.org.uk, geert@linux-m68k.org, catalin.marinas@arm.com, rppt@kernel.org, joao@joaoff.com, linux-alpha@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-janitors@vger.kernel.org, Julian Braha Subject: [PATCH] alpha: cleanup dead ALPHA_LARGE_VMALLOC Date: Sun, 16 Aug 2026 15:38:35 +0100 Message-ID: <20260816143835.1068971-1-julianbraha@gmail.com> X-Mailer: git-send-email 2.55.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Currently, the ALPHA_LARGE_VMALLOC config option can never be enabled, meaning that all references to it are dead code. Let's remove this dead option and its associated code. This dead code was found by kconfirm, a static analysis tool for Kconfig. Signed-off-by: Julian Braha --- arch/alpha/Kconfig | 15 --------------- arch/alpha/include/asm/pgtable.h | 4 ---- arch/alpha/mm/fault.c | 24 ------------------------ arch/alpha/mm/init.c | 10 ++-------- 4 files changed, 2 insertions(+), 51 deletions(-) diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig index 7b7dafe7d9df..fdffcea749ac 100644 --- a/arch/alpha/Kconfig +++ b/arch/alpha/Kconfig @@ -413,21 +413,6 @@ config ALPHA_WTINT =20 If unsure, say N. =20 -# LARGE_VMALLOC is racy, if you *really* need it then fix it first -config ALPHA_LARGE_VMALLOC - bool - help - Process creation and other aspects of virtual memory management can - be streamlined if we restrict the kernel to one PGD for all vmalloc - allocations. This equates to about 8GB. - - Under normal circumstances, this is so far and above what is needed - as to be laughable. However, there are certain applications (such - as benchmark-grade in-kernel web serving) that can make use of as - much vmalloc space as is available. - - Say N unless you know you need gobs and gobs of vmalloc space. - config VERBOSE_MCHECK bool "Verbose Machine Checks" =20 diff --git a/arch/alpha/include/asm/pgtable.h b/arch/alpha/include/asm/pgta= ble.h index 8e00cf9dc39d..3d7c1bab4154 100644 --- a/arch/alpha/include/asm/pgtable.h +++ b/arch/alpha/include/asm/pgtable.h @@ -50,11 +50,7 @@ struct vm_area_struct; /* Number of pointers that fit on a page: this will go away. */ #define PTRS_PER_PAGE (1UL << (PAGE_SHIFT-3)) =20 -#ifdef CONFIG_ALPHA_LARGE_VMALLOC -#define VMALLOC_START 0xfffffe0000000000 -#else #define VMALLOC_START (-2*PGDIR_SIZE) -#endif #define VMALLOC_END (-PGDIR_SIZE) =20 /* diff --git a/arch/alpha/mm/fault.c b/arch/alpha/mm/fault.c index a9816bbc9f34..0bc5fc4d510e 100644 --- a/arch/alpha/mm/fault.c +++ b/arch/alpha/mm/fault.c @@ -111,10 +111,6 @@ do_page_fault(unsigned long address, unsigned long mmc= sr, if (!mm || faulthandler_disabled()) goto no_context; =20 -#ifdef CONFIG_ALPHA_LARGE_VMALLOC - if (address >=3D TASK_SIZE) - goto vmalloc_fault; -#endif if (user_mode(regs)) flags |=3D FAULT_FLAG_USER; perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, address); @@ -225,24 +221,4 @@ do_page_fault(unsigned long address, unsigned long mmc= sr, do_sigsegv: force_sig_fault(SIGSEGV, si_code, (void __user *) address); return; - -#ifdef CONFIG_ALPHA_LARGE_VMALLOC - vmalloc_fault: - if (user_mode(regs)) - goto do_sigsegv; - else { - /* Synchronize this task's top level page-table - with the "reference" page table from init. */ - long index =3D pgd_index(address); - pgd_t *pgd, *pgd_k; - - pgd =3D current->active_mm->pgd + index; - pgd_k =3D swapper_pg_dir + index; - if (!pgd_present(*pgd) && pgd_present(*pgd_k)) { - pgd_val(*pgd) =3D pgd_val(*pgd_k); - return; - } - goto no_context; - } -#endif } diff --git a/arch/alpha/mm/init.c b/arch/alpha/mm/init.c index 9531cbc761c0..a2b4d001cbf2 100644 --- a/arch/alpha/mm/init.c +++ b/arch/alpha/mm/init.c @@ -45,12 +45,7 @@ pgd_alloc(struct mm_struct *mm) ret =3D __pgd_alloc(mm, 0); init =3D pgd_offset(&init_mm, 0UL); if (ret) { -#ifdef CONFIG_ALPHA_LARGE_VMALLOC - memcpy (ret + USER_PTRS_PER_PGD, init + USER_PTRS_PER_PGD, - (PTRS_PER_PGD - USER_PTRS_PER_PGD - 1)*sizeof(pgd_t)); -#else pgd_val(ret[PTRS_PER_PGD-2]) =3D pgd_val(init[PTRS_PER_PGD-2]); -#endif =20 /* The last PGD entry is the VPTB self-map. */ pgd_val(ret[PTRS_PER_PGD-1]) @@ -148,9 +143,8 @@ callback_init(void * kernel_end) On systems with larger consoles, additional pages will be allocated as needed during the mapping process. =20 - In the case of not SRM, but not CONFIG_ALPHA_LARGE_VMALLOC, - we need to allocate the PGD we use for vmalloc before we start - forking other tasks. */ + In the case of not SRM, we need to allocate the PGD we use for vmalloc + before we start forking other tasks. */ =20 two_pages =3D (void *) (((unsigned long)kernel_end + ~PAGE_MASK) & PAGE_MASK); --=20 2.55.0