Merge tag 'docs-6.4-2' of git://git.lwn.net/linux

Pull more documentation updates from Jonathan Corbet:
 "A handful of late-arriving documentation fixes, plus one Spanish
  translation that has been ready for some time but got applied late"

* tag 'docs-6.4-2' of git://git.lwn.net/linux:
  docs/sp_SP: Add translation of process/adding-syscalls
  CREDITS: Update email address for Mat Martineau
  Documentation: update kernel stack for x86_64
  docs: Remove unnecessary unicode character
  docs: fix "Reviewd" typo
  Documentation: timers: hrtimers: Make hybrid union historical
  docs/admin-guide/mm/ksm.rst fix intraface -> interface typo
  doc:it_IT: fix some typos

Author: torvalds

CREDITS

@@ -2510,8 +2510,8 @@ D: XF86_8514
 D: cfdisk (curses based disk partitioning program)
 
 N: Mat Martineau
-E: mat@martineau.name
-D: MPTCP subsystem co-maintainer 2020-2023
+E: martineau@kernel.org
+D: MPTCP subsystem co-maintainer
 D: Keyctl restricted keyring and Diffie-Hellman UAPI
 D: Bluetooth L2CAP ERTM mode and AMP
 S: USA

Documentation/admin-guide/mm/ksm.rst

@@ -20,7 +20,7 @@ content which can be replaced by a single write-protected page (which
 is automatically copied if a process later wants to update its
 content). The amount of pages that KSM daemon scans in a single pass
 and the time between the passes are configured using :ref:`sysfs
-intraface <ksm_sysfs>`
+interface <ksm_sysfs>`
 
 KSM only merges anonymous (private) pages, never pagecache (file) pages.
 KSM's merged pages were originally locked into kernel memory, but can now

Documentation/arch/x86/kernel-stacks.rst

@@ -12,7 +12,7 @@ Most of the text from Keith Owens, hacked by AK
 x86_64 page size (PAGE_SIZE) is 4K.
 
 Like all other architectures, x86_64 has a kernel stack for every
-active thread.  These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big.
+active thread.  These thread stacks are THREAD_SIZE (4*PAGE_SIZE) big.
 These stacks contain useful data as long as a thread is alive or a
 zombie. While the thread is in user space the kernel stack is empty
 except for the thread_info structure at the bottom.

Documentation/timers/hrtimers.rst

@@ -123,17 +123,12 @@ equivalent to timer_delete() and timer_delete_sync()] - so there's no direct
 potential for code sharing either.
 
 Basic data types: every time value, absolute or relative, is in a
-special nanosecond-resolution type: ktime_t. The kernel-internal
-representation of ktime_t values and operations is implemented via
-macros and inline functions, and can be switched between a "hybrid
-union" type and a plain "scalar" 64bit nanoseconds representation (at
-compile time). The hybrid union type optimizes time conversions on 32bit
-CPUs. This build-time-selectable ktime_t storage format was implemented
-to avoid the performance impact of 64-bit multiplications and divisions
-on 32bit CPUs. Such operations are frequently necessary to convert
-between the storage formats provided by kernel and userspace interfaces
-and the internal time format. (See include/linux/ktime.h for further
-details.)
+special nanosecond-resolution 64bit type: ktime_t.
+(Originally, the kernel-internal representation of ktime_t values and
+operations was implemented via macros and inline functions, and could be
+switched between a "hybrid union" type and a plain "scalar" 64bit
+nanoseconds representation (at compile time). This was abandoned in the
+context of the Y2038 work.)
 
 hrtimers - rounding of timer values
 -----------------------------------
@@ -148,7 +143,7 @@ a given clock has - be it low-res, high-res, or artificially-low-res.
 hrtimers - testing and verification
 -----------------------------------
 
-We used the high-resolution clock subsystem ontop of hrtimers to verify
+We used the high-resolution clock subsystem on top of hrtimers to verify
 the hrtimer implementation details in praxis, and we also ran the posix
 timer tests in order to ensure specification compliance. We also ran
 tests on low-resolution clocks.

Documentation/translations/it_IT/kernel-hacking/locking.rst

@@ -1030,7 +1030,7 @@ alle corse critiche, dovreste usare timer_delete_sync()
 (``include/linux/timer.h``) per gestire questo caso.
 
 Prima di rilasciare un temporizzatore dovreste chiamare la funzione
-timer_shutdown() o timer_shutdown_sync() di modo che non venga più ricarmato.
+timer_shutdown() o timer_shutdown_sync() di modo che non venga più riarmato.
 Ogni successivo tentativo di riarmare il temporizzatore verrà silenziosamente
 ignorato.
 

Documentation/translations/it_IT/process/deprecated.rst

@@ -386,7 +386,7 @@ combinazione con struct_size() e flex_array_size()::
 Ci sono due casi speciali dove è necessario usare la macro DECLARE_FLEX_ARRAY()
 (da notare che la stessa macro è chiamata __DECLARE_FLEX_ARRAY() nei file di
 intestazione UAPI). Uno è quando l'array flessibile è l'unico elemento di una
-struttura, e l'altro è quando è parti un unione. Per motivi non tecnici, entrambi
+struttura, e l'altro quando è parte di un unione. Per motivi non tecnici, entrambi
 i casi d'uso non sono permessi dalla specifica C99. Per esempio, per
 convertire il seguente codice::
 

Documentation/translations/it_IT/process/submitting-patches.rst

@@ -532,7 +532,7 @@ manutentori che qualche verifica è stata fatta, fornisce un mezzo per trovare
 persone che possano verificare il codice in futuro, e garantisce che queste
 stesse persone ricevano credito per il loro lavoro.
 
-Reviewd-by:, invece, indica che la patch è stata revisionata ed è stata
+Reviewed-by:, invece, indica che la patch è stata revisionata ed è stata
 considerata accettabile in accordo con la dichiarazione dei revisori:
 
 Dichiarazione di svista dei revisori
@@ -563,13 +563,13 @@ una modifica che si ritiene appropriata e senza alcun problema tecnico
 importante.  Qualsiasi revisore interessato (quelli che lo hanno fatto)
 possono offrire il proprio Reviewed-by per la patch.  Questa etichetta serve
 a dare credito ai revisori e a informare i manutentori sul livello di revisione
-che è stato fatto sulla patch.  L'etichetta Reviewd-by, quando fornita da
+che è stato fatto sulla patch.  L'etichetta Reviewed-by, quando fornita da
 revisori conosciuti per la loro conoscenza sulla materia in oggetto e per la
 loro serietà nella revisione, accrescerà le probabilità che la vostra patch
 venga integrate nel kernel.
 
 Quando si riceve una email sulla lista di discussione da un tester o
-un revisore, le etichette Tested-by o Reviewd-by devono essere
+un revisore, le etichette Tested-by o Reviewed-by devono essere
 aggiunte dall'autore quando invierà nuovamente la patch. Tuttavia, se
 la patch è cambiata in modo significativo, queste etichette potrebbero
 non avere più senso e quindi andrebbero rimosse. Solitamente si tiene traccia

Documentation/translations/ja_JP/SubmittingPatches

@@ -450,7 +450,7 @@ Reviewed-by: タグは、それとは異なり、下記のレビューア宣言
             状況においてその宣言した目的や機能が正しく実現することに関して、
             いかなる保証もしない(特にどこかで明示しない限り)。
 
-Reviewd-by タグはそのパッチがカーネルに対して適切な修正であって、深刻な技術的
+Reviewed-by タグはそのパッチがカーネルに対して適切な修正であって、深刻な技術的
 問題を残していないという意見の宣言です。興味のあるレビューアは誰でも(レビュー
 作業を終えたら)パッチに対して Reviewed-by タグを提示できます。このタグは
 レビューアの寄与をクレジットする働き、レビューの進捗の度合いをメンテナに