A handful of late-arriving documentation fixes.

-----BEGIN PGP SIGNATURE-----
 
 iQFDBAABCAAtFiEEIw+MvkEiF49krdp9F0NaE2wMflgFAl+TK60PHGNvcmJldEBs
 d24ubmV0AAoJEBdDWhNsDH5YrTMIAJSEchjBnlWOzvW/YmdhWz8+O3+CDPNIiJ2J
 01tybiOBj64n0zMP7K6bN8IEjyRIed6L3vBsJxyIOGajkjekJZSqpBT9THy+AJnW
 ie72nA7DNYucdik8CWCKjyzylunVGfD/ju5uI4o4yBMTvliDlz9ZWIepF1fprfCb
 rTTyj5o+lsP11EjSSPw7RQIAHYCzFhBRanHqijGQnuEmnNKo+HxULcMwIsAtPjL8
 wAgZyi6sr2kllk5ZsGaU8eSwiM4SCcuvOo9W36Eg0bKQnutUClGbAVL0UKy9yFd+
 jJXTNDHGs/tBewSVyAmNa90WUORvRASdugI0hz1DdPt4qFIDdTQ=
 =+uur
 -----END PGP SIGNATURE-----

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

Pull documentation fixes from Jonathan Corbet:
 "A handful of late-arriving documentation fixes"

* tag 'docs-5.10-2' of git://git.lwn.net/linux:
  docs: Add two missing entries in vm sysctl index
  docs/vm: trivial fixes to several spelling mistakes
  docs: submitting-patches: describe preserving review/test tags
  Documentation: Chinese translation of Documentation/arm64/hugetlbpage.rst
  Documentation: x86: fix a missing word in x86_64/mm.rst.
  docs: driver-api: remove a duplicated index entry
  docs: lkdtm: Modernize and improve details
  docs: deprecated.rst: Expand str*cpy() replacement notes
  docs/cpu-load: format the example code.
This commit is contained in:
Linus Torvalds 2020-10-23 17:13:53 -07:00
commit c80e42a496
14 changed files with 151 additions and 74 deletions

View File

@ -61,43 +61,46 @@ will lead to quite erratic information inside ``/proc/stat``::
static volatile sig_atomic_t stop;
static void sighandler (int signr)
static void sighandler(int signr)
{
(void) signr;
stop = 1;
(void) signr;
stop = 1;
}
static unsigned long hog (unsigned long niters)
{
stop = 0;
while (!stop && --niters);
return niters;
stop = 0;
while (!stop && --niters);
return niters;
}
int main (void)
{
int i;
struct itimerval it = { .it_interval = { .tv_sec = 0, .tv_usec = 1 },
.it_value = { .tv_sec = 0, .tv_usec = 1 } };
sigset_t set;
unsigned long v[HIST];
double tmp = 0.0;
unsigned long n;
signal (SIGALRM, &sighandler);
setitimer (ITIMER_REAL, &it, NULL);
int i;
struct itimerval it = {
.it_interval = { .tv_sec = 0, .tv_usec = 1 },
.it_value = { .tv_sec = 0, .tv_usec = 1 } };
sigset_t set;
unsigned long v[HIST];
double tmp = 0.0;
unsigned long n;
signal(SIGALRM, &sighandler);
setitimer(ITIMER_REAL, &it, NULL);
hog (ULONG_MAX);
for (i = 0; i < HIST; ++i) v[i] = ULONG_MAX - hog (ULONG_MAX);
for (i = 0; i < HIST; ++i) tmp += v[i];
tmp /= HIST;
n = tmp - (tmp / 3.0);
hog (ULONG_MAX);
for (i = 0; i < HIST; ++i) v[i] = ULONG_MAX - hog(ULONG_MAX);
for (i = 0; i < HIST; ++i) tmp += v[i];
tmp /= HIST;
n = tmp - (tmp / 3.0);
sigemptyset (&set);
sigaddset (&set, SIGALRM);
sigemptyset(&set);
sigaddset(&set, SIGALRM);
for (;;) {
hog (n);
sigwait (&set, &i);
}
return 0;
for (;;) {
hog(n);
sigwait(&set, &i);
}
return 0;
}

View File

@ -27,6 +27,7 @@ Currently, these files are in /proc/sys/vm:
- admin_reserve_kbytes
- block_dump
- compact_memory
- compaction_proactiveness
- compact_unevictable_allowed
- dirty_background_bytes
- dirty_background_ratio
@ -37,6 +38,7 @@ Currently, these files are in /proc/sys/vm:
- dirty_writeback_centisecs
- drop_caches
- extfrag_threshold
- highmem_is_dirtyable
- hugetlb_shm_group
- laptop_mode
- legacy_va_layout

View File

@ -1,3 +1,5 @@
.. _hugetlbpage_index:
====================
HugeTLBpage on ARM64
====================

View File

@ -77,7 +77,6 @@ available subsections can be seen below.
console
dcdbas
eisa
ipmb
isa
isapnp
io-mapping

View File

@ -1,16 +1,19 @@
===============
Provoke crashes
===============
.. SPDX-License-Identifier: GPL-2.0
The lkdtm module provides an interface to crash or injure the kernel at
predefined crashpoints to evaluate the reliability of crash dumps obtained
using different dumping solutions. The module uses KPROBEs to instrument
crashing points, but can also crash the kernel directly without KRPOBE
support.
============================================================
Provoking crashes with Linux Kernel Dump Test Module (LKDTM)
============================================================
The lkdtm module provides an interface to disrupt (and usually crash)
the kernel at predefined code locations to evaluate the reliability of
the kernel's exception handling and to test crash dumps obtained using
different dumping solutions. The module uses KPROBEs to instrument the
trigger location, but can also trigger the kernel directly without KPROBE
support via debugfs.
You can provide the way either through module arguments when inserting
the module, or through a debugfs interface.
You can select the location of the trigger ("crash point name") and the
type of action ("crash point type") either through module arguments when
inserting the module, or through the debugfs interface.
Usage::
@ -18,31 +21,38 @@ Usage::
[cpoint_count={>0}]
recur_count
Recursion level for the stack overflow test. Default is 10.
Recursion level for the stack overflow test. By default this is
dynamically calculated based on kernel configuration, with the
goal of being just large enough to exhaust the kernel stack. The
value can be seen at `/sys/module/lkdtm/parameters/recur_count`.
cpoint_name
Crash point where the kernel is to be crashed. It can be
Where in the kernel to trigger the action. It can be
one of INT_HARDWARE_ENTRY, INT_HW_IRQ_EN, INT_TASKLET_ENTRY,
FS_DEVRW, MEM_SWAPOUT, TIMERADD, SCSI_DISPATCH_CMD,
IDE_CORE_CP, DIRECT
IDE_CORE_CP, or DIRECT
cpoint_type
Indicates the action to be taken on hitting the crash point.
It can be one of PANIC, BUG, EXCEPTION, LOOP, OVERFLOW,
CORRUPT_STACK, UNALIGNED_LOAD_STORE_WRITE, OVERWRITE_ALLOCATION,
WRITE_AFTER_FREE,
These are numerous, and best queried directly from debugfs. Some
of the common ones are PANIC, BUG, EXCEPTION, LOOP, and OVERFLOW.
See the contents of `/sys/kernel/debug/provoke-crash/DIRECT` for
a complete list.
cpoint_count
Indicates the number of times the crash point is to be hit
to trigger an action. The default is 10.
before triggering the action. The default is 10 (except for
DIRECT, which always fires immediately).
You can also induce failures by mounting debugfs and writing the type to
<mountpoint>/provoke-crash/<crashpoint>. E.g.::
<debugfs>/provoke-crash/<crashpoint>. E.g.::
mount -t debugfs debugfs /mnt
echo EXCEPTION > /mnt/provoke-crash/INT_HARDWARE_ENTRY
mount -t debugfs debugfs /sys/kernel/debug
echo EXCEPTION > /sys/kernel/debug/provoke-crash/INT_HARDWARE_ENTRY
The special file `DIRECT` will induce the action directly without KPROBE
instrumentation. This mode is the only one available when the module is
built for a kernel without KPROBEs support::
A special file is `DIRECT` which will induce the crash directly without
KPROBE instrumentation. This mode is the only one available when the module
is built on a kernel without KPROBEs support.
# Instead of having a BUG kill your shell, have it kill "cat":
cat <(echo WRITE_RO) >/sys/kernel/debug/provoke-crash/DIRECT

View File

@ -106,23 +106,29 @@ NUL or newline terminated.
strcpy()
--------
strcpy() performs no bounds checking on the destination
buffer. This could result in linear overflows beyond the
end of the buffer, leading to all kinds of misbehaviors. While
`CONFIG_FORTIFY_SOURCE=y` and various compiler flags help reduce the
risk of using this function, there is no good reason to add new uses of
this function. The safe replacement is strscpy().
strcpy() performs no bounds checking on the destination buffer. This
could result in linear overflows beyond the end of the buffer, leading to
all kinds of misbehaviors. While `CONFIG_FORTIFY_SOURCE=y` and various
compiler flags help reduce the risk of using this function, there is
no good reason to add new uses of this function. The safe replacement
is strscpy(), though care must be given to any cases where the return
value of strcpy() was used, since strscpy() does not return a pointer to
the destination, but rather a count of non-NUL bytes copied (or negative
errno when it truncates).
strncpy() on NUL-terminated strings
-----------------------------------
Use of strncpy() does not guarantee that the destination buffer
will be NUL terminated. This can lead to various linear read overflows
and other misbehavior due to the missing termination. It also NUL-pads the
destination buffer if the source contents are shorter than the destination
buffer size, which may be a needless performance penalty for callers using
only NUL-terminated strings. The safe replacement is strscpy().
(Users of strscpy() still needing NUL-padding should instead
use strscpy_pad().)
Use of strncpy() does not guarantee that the destination buffer will
be NUL terminated. This can lead to various linear read overflows and
other misbehavior due to the missing termination. It also NUL-pads
the destination buffer if the source contents are shorter than the
destination buffer size, which may be a needless performance penalty
for callers using only NUL-terminated strings. The safe replacement is
strscpy(), though care must be given to any cases where the return value
of strncpy() was used, since strscpy() does not return a pointer to the
destination, but rather a count of non-NUL bytes copied (or negative
errno when it truncates). Any cases still needing NUL-padding should
instead use strscpy_pad().
If a caller is using non-NUL-terminated strings, strncpy() can
still be used, but destinations should be marked with the `__nonstring
@ -131,10 +137,12 @@ attribute to avoid future compiler warnings.
strlcpy()
---------
strlcpy() reads the entire source buffer first, possibly exceeding
the given limit of bytes to copy. This is inefficient and can lead to
linear read overflows if a source string is not NUL-terminated. The
safe replacement is strscpy().
strlcpy() reads the entire source buffer first (since the return value
is meant to match that of strlen()). This read may exceed the destination
size limit. This is both inefficient and can lead to linear read overflows
if a source string is not NUL-terminated. The safe replacement is strscpy(),
though care must be given to any cases where the return value of strlcpy()
is used, since strscpy() will return negative errno values when it truncates.
%p format specifier
-------------------

View File

@ -527,6 +527,13 @@ done on the patch. Reviewed-by: tags, when supplied by reviewers known to
understand the subject area and to perform thorough reviews, will normally
increase the likelihood of your patch getting into the kernel.
Both Tested-by and Reviewed-by tags, once received on mailing list from tester
or reviewer, should be added by author to the applicable patches when sending
next versions. However if the patch has changed substantially in following
version, these tags might not be applicable anymore and thus should be removed.
Usually removal of someone's Tested-by or Reviewed-by tags should be mentioned
in the patch changelog (after the '---' separator).
A Suggested-by: tag indicates that the patch idea is suggested by the person
named and ensures credit to the person for the idea. Please note that this
tag should not be added without the reporter's permission, especially if the

View File

@ -0,0 +1,45 @@
.. include:: ../disclaimer-zh_CN.rst
:Original: :ref:`Documentation/arm64/hugetlbpage.rst <hugetlbpage_index>`
Translator: Bailu Lin <bailu.lin@vivo.com>
=====================
ARM64中的 HugeTLBpage
=====================
大页依靠有效利用 TLBs 来提高地址翻译的性能。这取决于以下
两点 -
- 大页的大小
- TLBs 支持的条目大小
ARM64 接口支持2种大页方式。
1) pud/pmd 级别的块映射
-----------------------
这是常规大页,他们的 pmd 或 pud 页面表条目指向一个内存块。
不管 TLB 中支持的条目大小如何,块映射可以减少翻译大页地址
所需遍历的页表深度。
2) 使用连续位
-------------
架构中转换页表条目(D4.5.3, ARM DDI 0487C.a)中提供一个连续
位告诉 MMU 这个条目是一个连续条目集的一员,它可以被缓存在单
个 TLB 条目中。
在 Linux 中连续位用来增加 pmd 和 pte(最后一级)级别映射的大
小。受支持的连续页表条目数量因页面大小和页表级别而异。
支持以下大页尺寸配置 -
====== ======== ==== ======== ===
- CONT PTE PMD CONT PMD PUD
====== ======== ==== ======== ===
4K: 64K 2M 32M 1G
16K: 2M 32M 1G
64K: 2M 512M 16G
====== ======== ==== ======== ===

View File

@ -14,3 +14,4 @@ ARM64 架构
:maxdepth: 2
amu
hugetlbpage

View File

@ -89,7 +89,7 @@ they are write protected for COW (other case of B apply too).
So here because at time N+2 the clear page table entry was not pair with a
notification to invalidate the secondary TLB, the device see the new value for
addrB before seing the new value for addrA. This break total memory ordering
addrB before seeing the new value for addrA. This break total memory ordering
for the device.
When changing a pte to write protect or to point to a new write protected page

View File

@ -99,7 +99,7 @@ Steps:
2. Ensure that writeback is complete.
3. Lock the new page that we want to move to. It is locked so that accesses to
this (not yet uptodate) page immediately block while the move is in progress.
this (not yet up-to-date) page immediately block while the move is in progress.
4. All the page table references to the page are converted to migration
entries. This decreases the mapcount of a page. If the resulting

View File

@ -18,7 +18,7 @@ Although we already have tracepoint for tracing page allocation/free,
using it for analyzing who allocate each page is rather complex. We need
to enlarge the trace buffer for preventing overlapping until userspace
program launched. And, launched program continually dump out the trace
buffer for later analysis and it would change system behviour with more
buffer for later analysis and it would change system behaviour with more
possibility rather than just keeping it in memory, so bad for debugging.
page owner can also be used for various purposes. For example, accurate

View File

@ -378,7 +378,7 @@ c) Execute ``slabinfo-gnuplot.sh`` in '-t' mode, passing all of the
can go unnoticed. To deal with that, ``slabinfo-gnuplot.sh`` has two
options to 'zoom-in'/'zoom-out':
a) ``-s %d,%d`` -- overwrites the default image width and heigh
a) ``-s %d,%d`` -- overwrites the default image width and height
b) ``-r %d,%d`` -- specifies a range of samples to use (for example,
in ``slabinfo -X >> FOO_STATS; sleep 1;`` case, using a ``-r
40,60`` range will plot only samples collected between 40th and

View File

@ -19,7 +19,7 @@ Complete virtual memory map with 4-level page tables
Note that as we get closer to the top of the address space, the notation changes
from TB to GB and then MB/KB.
- "16M TB" might look weird at first sight, but it's an easier to visualize size
- "16M TB" might look weird at first sight, but it's an easier way to visualize size
notation than "16 EB", which few will recognize at first sight as 16 exabytes.
It also shows it nicely how incredibly large 64-bit address space is.