From nobody Tue Feb 10 06:06:21 2026 Received: from mail-pf1-f174.google.com (mail-pf1-f174.google.com [209.85.210.174]) (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 81CDD36BCE2 for ; Mon, 9 Feb 2026 14:56:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.174 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770648987; cv=none; b=enMX54r1kbrhciPIHaa+A1O9GfsHVixqeNldHmDsbm/DcNcjCmU/Awpek3hg0spzkSH4tUJsnqvvnWGzKCNgX8mN5IiD+STlBfYodo020KbRip3ilutsAx6fAxmC012YBHLlVIh91hIkUVV7+MLWkB9ojH0TBJxcgd5gwogC334= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770648987; c=relaxed/simple; bh=w5fg8R5bRexavkpGFdyth/M5t9vS5r8b/nDimyTxroI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=QcoynW8stx+qPX5cPyWTRLrjnfYyfi92G1xRuCb60lZy3G7d0P6ACsTRKPMyicwqWf4Hyu5QSTofU2bQVNrHt7aYtl5V/P+Gd8gkfDvLQPN4d/UzIQP4iHpr8aqRl8jgCOWWQ+cSpqOrp4FCgGLdx6ksPwIEibgtryeoqi8ZpSA= 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=Ca2bFP63; arc=none smtp.client-ip=209.85.210.174 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="Ca2bFP63" Received: by mail-pf1-f174.google.com with SMTP id d2e1a72fcca58-81e8a9d521dso1867473b3a.2 for ; Mon, 09 Feb 2026 06:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770648987; x=1771253787; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=hWcBvSDIuanvdGG8hK0w4PUAsRvRha3/h7urmdr6y1E=; b=Ca2bFP63+bmZERMrNi+YjZxTnYznBMOrLlxPnUTQ83vNS63zDCeDDqkLEqK81Z2Ebe 5Gzy/eb2j9jyW5lbuyaq/Rks/V9gCGlbQtb0aNL7HFLGvnN2fiMBiEI5p70COKSwi+oC 4/nYbSgdsSSQWyENcjaKn3EbIJz/akyBdcD1jD0EmllcTgx5MiUUZ5TZs4LkKHu2AYvD ZmLypqqMSEXcEDkPnR8BSIlh4Wgs6OcoaL5LeqLlFs8km+n0fpeXPr9nSwZh/yYt5e2D d4qvWFTXPWc5HsWfznoaojOFLEcecnBgAla1A1pzmVTeHP5jwCby0yCCpOUDZGaL1Lgi mhYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770648987; x=1771253787; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hWcBvSDIuanvdGG8hK0w4PUAsRvRha3/h7urmdr6y1E=; b=N5Kw5lCT9BmToqD8ozck9gjf4yJRlc0EwEIPenk2BIUcrN1w3a+0Fznp78/AmQ+Es0 4CClnz/9ZzFs2gn84jskRS8mXRQDS55uPwpwlnpn6NdBSQ0w++gZz6Knv5rpVfrXH3Jl BFtG0NPYQEKLtXK056xyWhL+QT2+4xqbfncQNoVftUZnMnXBSxaypQ0vEcxlTaavDPfA JaBNGU42iRoaVCtMohuXWiw6oVrFV3j/qsqqmsPaPF09WgBZliNANd46WxmZcRYE9lM3 aOdtk34mFIfBtu82dZA1orjChVRfcKICHMWRs3vy0Nhlso+kF3HYr/CEvF9j1gA8cVw+ clQA== X-Forwarded-Encrypted: i=1; AJvYcCVSVFkaDiQR7tYoZTL53g2nd7pFaHVjQTcOv8vVzClBWWaPSC4p3dccw2nnjIR2jsnzvIpjAFvCK8gT9pQ=@vger.kernel.org X-Gm-Message-State: AOJu0YwepZbCxvs1qKrPgoiIZoSoOISu+xXA8xojOCBfrgorZCuuMu2Z LkKcIV7Qja6HN+yy4fs2XjAEzAiaIBExTkVFA8pKOlp3oTWI5xzn1qeVGizo/ia4 X-Gm-Gg: AZuq6aJHPqinYNn9M6pH82bHKIbNGeHIBsyc87gYmOaOrFUZhuCgaWVU6SLMCvrtI0W X18NYsxusqVKc1If0+IGjW46xWPJ/R5BrClYjsa1EjTKndJZ6ZESbgikAYEYyqBLg8/ERgKPy/n 0HqoPKXHG5mXyQff3fDJFH2csDygtv3/OpiHuJGktffGJ7p0JV5rwagc1JHeXkBchedS30Vjip9 +9yzFX9dTjdGE3wC4VNYy6+TGjpu3WFLUNfrLqzAc3zNIGI5njs2lsZn7lbBRbgLq+kGivoBkPN CQeabsae/ea1Dj6ti7Ca0kMWNNcnWlk/RNLIPYkMumw/fXVMhVtTgzzzXv6xZyuFnUw2mR0ak4v NmjfySLpZnZojQQ45TtI3+s0IS6jeVV/G8+culJ6Xvvr2Iko2k8cA9i3OM0WQOH+XC3pWLJheyJ x+mZm7Ok8N+AfB3PEs9H8elNFcgmAbhqiKdZBxjKoVbvYxCh80IQhWZXos0hUpanK0L9BMiR9HL A== X-Received: by 2002:a05:6a20:7f8c:b0:35d:e4b2:b389 with SMTP id adf61e73a8af0-393ad366d00mr9773794637.58.1770648986687; Mon, 09 Feb 2026 06:56:26 -0800 (PST) Received: from localhost.localdomain (123-194-188-82.dynamic.kbronet.com.tw. [123.194.188.82]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-c6dcb61e4a1sm9193974a12.27.2026.02.09.06.56.25 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Mon, 09 Feb 2026 06:56:26 -0800 (PST) From: Min-Hsun Chang To: corbet@lwn.net, akpm@linux-foundation.org Cc: linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Min-Hsun Chang Subject: [PATCH v2] Docs/mm: fix typos and grammar in page_tables.rst Date: Mon, 9 Feb 2026 22:56:03 +0800 Message-ID: <20260209145603.96664-1-chmh0624@gmail.com> X-Mailer: git-send-email 2.50.1 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" Correct several spelling and grammatical errors in the page tables documentation. This includes: - Fixing "a address" to "an address" - Fixing "pfs" to "pfns" - Correcting the possessive "Torvald's" to "Torvalds's" - Fixing "instruction that want" to "instruction that wants" - Fixing "code path" to "code paths" Signed-off-by: Min-Hsun Chang Reviewed-by: Linus Walleij Reviewed-by: Matthew Wilcox (Oracle) --- Documentation/mm/page_tables.rst | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/Documentation/mm/page_tables.rst b/Documentation/mm/page_table= s.rst index e7c69cc32493..126c87628250 100644 --- a/Documentation/mm/page_tables.rst +++ b/Documentation/mm/page_tables.rst @@ -26,9 +26,9 @@ Physical memory address 0 will be *pfn 0* and the highest= pfn will be the last page of physical memory the external address bus of the CPU can address. =20 -With a page granularity of 4KB and a address range of 32 bits, pfn 0 is at +With a page granularity of 4KB and an address range of 32 bits, pfn 0 is at address 0x00000000, pfn 1 is at address 0x00001000, pfn 2 is at 0x00002000 -and so on until we reach pfn 0xfffff at 0xfffff000. With 16KB pages pfs are +and so on until we reach pfn 0xfffff at 0xfffff000. With 16KB pages pfns a= re at 0x00004000, 0x00008000 ... 0xffffc000 and pfn goes from 0 to 0x3ffff. =20 As you can see, with 4KB pages the page base address uses bits 12-31 of the @@ -38,8 +38,8 @@ address, and this is why `PAGE_SHIFT` in this case is def= ined as 12 and Over time a deeper hierarchy has been developed in response to increasing = memory sizes. When Linux was created, 4KB pages and a single page table called `swapper_pg_dir` with 1024 entries was used, covering 4MB which coincided = with -the fact that Torvald's first computer had 4MB of physical memory. Entries= in -this single table were referred to as *PTE*:s - page table entries. +the fact that Torvalds's first computer had 4MB of physical memory. Entrie= s in +this single table were referred to as *PTEs* - page table entries. =20 The software page table hierarchy reflects the fact that page table hardwa= re has become hierarchical and that in turn is done to save page table memory and @@ -212,7 +212,7 @@ threshold. Additionally, page faults may be also caused by code bugs or by maliciously crafted addresses that the CPU is instructed to access. A thread of a proc= ess could use instructions to address (non-shared) memory which does not belon= g to -its own address space, or could try to execute an instruction that want to= write +its own address space, or could try to execute an instruction that wants t= o write to a read-only location. =20 If the above-mentioned conditions happen in user-space, the kernel sends a @@ -277,5 +277,5 @@ To conclude this high altitude view of how Linux handle= s page faults, let's add that the page faults handler can be disabled and enabled respectively = with `pagefault_disable()` and `pagefault_enable()`. =20 -Several code path make use of the latter two functions because they need to +Several code paths make use of the latter two functions because they need = to disable traps into the page faults handler, mostly to prevent deadlocks. --=20 2.50.1