Commit 2324d50d authored by Linus Torvalds's avatar Linus Torvalds

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

Pull documentation updates from Jonathan Corbet:
 "It's been a busy cycle for documentation - hopefully the busiest for a
  while to come. Changes include:

   - Some new Chinese translations

   - Progress on the battle against double words words and non-HTTPS
     URLs

   - Some block-mq documentation

   - More RST conversions from Mauro. At this point, that task is
     essentially complete, so we shouldn't see this kind of churn again
     for a while. Unless we decide to switch to asciidoc or
     something...:)

   - Lots of typo fixes, warning fixes, and more"

* tag 'docs-5.9' of git://git.lwn.net/linux: (195 commits)
  scripts/kernel-doc: optionally treat warnings as errors
  docs: ia64: correct typo
  mailmap: add entry for <alobakin@marvell.com>
  doc/zh_CN: add cpu-load Chinese version
  Documentation/admin-guide: tainted-kernels: fix spelling mistake
  MAINTAINERS: adjust kprobes.rst entry to new location
  devices.txt: document rfkill allocation
  PCI: correct flag name
  docs: filesystems: vfs: correct flag name
  docs: filesystems: vfs: correct sync_mode flag names
  docs: path-lookup: markup fixes for emphasis
  docs: path-lookup: more markup fixes
  docs: path-lookup: fix HTML entity mojibake
  CREDITS: Replace HTTP links with HTTPS ones
  docs: process: Add an example for creating a fixes tag
  doc/zh_CN: add Chinese translation prefer section
  doc/zh_CN: add clearing-warn-once Chinese version
  doc/zh_CN: add admin-guide index
  doc:it_IT: process: coding-style.rst: Correct __maybe_unused compiler label
  futex: MAINTAINERS: Re-add selftests directory
  ...
parents a7542923 2c12c810
......@@ -18,6 +18,9 @@ Aleksey Gorelov <aleksey_gorelov@phoenix.com>
Aleksandar Markovic <aleksandar.markovic@mips.com> <aleksandar.markovic@imgtec.com>
Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@intel.com>
Alex Shi <alex.shi@linux.alibaba.com> <alex.shi@linaro.org>
Alexander Lobakin <alobakin@pm.me> <alobakin@dlink.ru>
Alexander Lobakin <alobakin@pm.me> <alobakin@marvell.com>
Alexander Lobakin <alobakin@pm.me> <bloodyreaper@yandex.ru>
Alexandre Belloni <alexandre.belloni@bootlin.com> <alexandre.belloni@free-electrons.com>
Alexei Starovoitov <ast@kernel.org> <ast@plumgrid.com>
Alexei Starovoitov <ast@kernel.org> <alexei.starovoitov@gmail.com>
......@@ -134,6 +137,11 @@ Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
Jens Axboe <axboe@suse.de>
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
Jiri Slaby <jirislaby@kernel.org> <jirislaby@gmail.com>
Jiri Slaby <jirislaby@kernel.org> <jslaby@novell.com>
Jiri Slaby <jirislaby@kernel.org> <jslaby@suse.com>
Jiri Slaby <jirislaby@kernel.org> <jslaby@suse.cz>
Jiri Slaby <jirislaby@kernel.org> <xslaby@fi.muni.cz>
Johan Hovold <johan@kernel.org> <jhovold@gmail.com>
Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
......@@ -151,6 +159,7 @@ Kamil Konieczny <k.konieczny@samsung.com> <k.konieczny@partner.samsung.com>
Kay Sievers <kay.sievers@vrfy.org>
Kenneth W Chen <kenneth.w.chen@intel.com>
Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>
Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>
Koushik <raghavendra.koushik@neterion.com>
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski@samsung.com>
Krzysztof Kozlowski <krzk@kernel.org> <k.kozlowski.k@gmail.com>
......
......@@ -34,7 +34,7 @@ S: Romania
N: Mark Adler
E: madler@alumni.caltech.edu
W: http://alumnus.caltech.edu/~madler/
W: https://alumnus.caltech.edu/~madler/
D: zlib decompression
N: Monalisa Agrawal
......@@ -62,7 +62,7 @@ S: United Kingdom
N: Werner Almesberger
E: werner@almesberger.net
W: http://www.almesberger.net/
W: https://www.almesberger.net/
D: dosfs, LILO, some fd features, ATM, various other hacks here and there
S: Buenos Aires
S: Argentina
......@@ -96,7 +96,7 @@ S: USA
N: Erik Andersen
E: andersen@codepoet.org
W: http://www.codepoet.org/
W: https://www.codepoet.org/
P: 1024D/30D39057 1BC4 2742 E885 E4DE 9301 0C82 5F9B 643E 30D3 9057
D: Maintainer of ide-cd and Uniform CD-ROM driver,
D: ATAPI CD-Changer support, Major 2.1.x CD-ROM update.
......@@ -114,7 +114,7 @@ S: Canada K2P 0X3
N: H. Peter Anvin
E: hpa@zytor.com
W: http://www.zytor.com/~hpa/
W: https://www.zytor.com/~hpa/
P: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD 1E DF FE 69 EE 35 BD 74
D: Author of the SYSLINUX boot loader, maintainer of the linux.* news
D: hierarchy and the Linux Device List; various kernel hacks
......@@ -124,7 +124,7 @@ S: USA
N: Andrea Arcangeli
E: andrea@suse.de
W: http://www.kernel.org/pub/linux/kernel/people/andrea/
W: https://www.kernel.org/pub/linux/kernel/people/andrea/
P: 1024D/68B9CB43 13D9 8355 295F 4823 7C49 C012 DFA1 686E 68B9 CB43
P: 1024R/CB4660B9 CC A0 71 81 F4 A0 63 AC C0 4B 81 1D 8C 15 C8 E5
D: Parport hacker
......@@ -339,7 +339,7 @@ S: Haifa, Israel
N: Johannes Berg
E: johannes@sipsolutions.net
W: http://johannes.sipsolutions.net/
W: https://johannes.sipsolutions.net/
P: 4096R/7BF9099A C0EB C440 F6DA 091C 884D 8532 E0F3 73F3 7BF9 099A
D: powerpc & 802.11 hacker
......@@ -376,7 +376,7 @@ D: Original author of the Linux networking code
N: Anton Blanchard
E: anton@samba.org
W: http://samba.org/~anton/
W: https://samba.org/~anton/
P: 1024/8462A731 4C 55 86 34 44 59 A7 99 2B 97 88 4A 88 9A 0D 97
D: sun4 port, Sparc hacker
......@@ -509,7 +509,7 @@ S: Sweden
N: Paul Bristow
E: paul@paulbristow.net
W: http://paulbristow.net/linux/idefloppy.html
W: https://paulbristow.net/linux/idefloppy.html
D: Maintainer of IDE/ATAPI floppy driver
N: Stefano Brivio
......@@ -518,7 +518,7 @@ D: Broadcom B43 driver
N: Dominik Brodowski
E: linux@brodo.de
W: http://www.brodo.de/
W: https://www.brodo.de/
P: 1024D/725B37C6 190F 3E77 9C89 3B6D BECD 46EE 67C3 0308 725B 37C6
D: parts of CPUFreq code, ACPI bugfixes, PCMCIA rewrite, cpufrequtils
S: Tuebingen, Germany
......@@ -865,7 +865,7 @@ D: Promise DC4030VL caching HD controller drivers
N: Todd J. Derr
E: tjd@fore.com
W: http://www.wordsmith.org/~tjd
W: https://www.wordsmith.org/~tjd
D: Random console hacks and other miscellaneous stuff
S: 3000 FORE Drive
S: Warrendale, Pennsylvania 15086
......@@ -894,8 +894,8 @@ S: USA
N: Matt Domsch
E: Matt_Domsch@dell.com
W: http://www.dell.com/linux
W: http://domsch.com/linux
W: https://www.dell.com/linux
W: https://domsch.com/linux
D: Linux/IA-64
D: Dell PowerEdge server, SCSI layer, misc drivers, and other patches
S: Dell Inc.
......@@ -992,7 +992,7 @@ S: USA
N: Randy Dunlap
E: rdunlap@infradead.org
W: http://www.infradead.org/~rdunlap/
W: https://www.infradead.org/~rdunlap/
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
D: x86 SMP, ACPI, bootflag hacking
D: documentation, builds
......@@ -1157,7 +1157,7 @@ S: Germany
N: Jeremy Fitzhardinge
E: jeremy@goop.org
W: http://www.goop.org/~jeremy
W: https://www.goop.org/~jeremy
D: author of userfs filesystem
D: Improved mmap and munmap handling
D: General mm minor tidyups
......@@ -1460,7 +1460,7 @@ S: The Netherlands
N: Oliver Hartkopp
E: oliver.hartkopp@volkswagen.de
W: http://www.volkswagen.de
W: https://www.volkswagen.de
D: Controller Area Network (network layer core)
S: Brieffach 1776
S: 38436 Wolfsburg
......@@ -1599,13 +1599,13 @@ S: Germany
N: Kenji Hollis
E: kenji@bitgate.com
W: http://www.bitgate.com/
W: https://www.bitgate.com/
D: Berkshire PC Watchdog Driver
D: Small/Industrial Driver Project
N: Nick Holloway
E: Nick.Holloway@pyrites.org.uk
W: http://www.pyrites.org.uk/
W: https://www.pyrites.org.uk/
P: 1024/36115A04 F4E1 3384 FCFD C055 15D6 BA4C AB03 FBF8 3611 5A04
D: Occasional Linux hacker...
S: (ask for current address)
......@@ -1655,7 +1655,7 @@ S: USA
N: Harald Hoyer
E: harald@redhat.com
W: http://www.harald-hoyer.de
W: https://www.harald-hoyer.de
D: ip_masq_quake
D: md boot support
S: Am Strand 5
......@@ -1856,7 +1856,7 @@ E: kas@fi.muni.cz
D: Author of the COSA/SRP sync serial board driver.
D: Port of the syncppp.c from the 2.0 to the 2.1 kernel.
P: 1024/D3498839 0D 99 A7 FB 20 66 05 D7 8B 35 FC DE 05 B1 8A 5E
W: http://www.fi.muni.cz/~kas/
W: https://www.fi.muni.cz/~kas/
S: c/o Faculty of Informatics, Masaryk University
S: Botanicka' 68a
S: 602 00 Brno
......@@ -2017,7 +2017,7 @@ S: Prague, Czech Republic
N: Gene Kozin
E: 74604.152@compuserve.com
W: http://www.sangoma.com
W: https://www.sangoma.com
D: WAN Router & Sangoma WAN drivers
S: Sangoma Technologies Inc.
S: 7170 Warden Avenue, Unit 2
......@@ -2112,7 +2112,7 @@ D: Original author of software suspend
N: Jaroslav Kysela
E: perex@perex.cz
W: http://www.perex.cz
W: https://www.perex.cz
D: Original Author and Maintainer for HP 10/100 Mbit Network Adapters
D: ISA PnP
S: Sindlovy Dvory 117
......@@ -2316,7 +2316,7 @@ S: Finland
N: Daniel J. Maas
E: dmaas@dcine.com
W: http://www.maasdigital.com
W: https://www.maasdigital.com
D: dv1394
N: Hamish Macdonald
......@@ -2647,7 +2647,7 @@ D: bug fixes, documentation, minor hackery
N: Paul Moore
E: paul@paul-moore.com
W: http://www.paul-moore.com
W: https://www.paul-moore.com
D: NetLabel, SELinux, audit
N: James Morris
......@@ -2786,7 +2786,7 @@ N: David C. Niemi
E: niemi@tux.org
W: http://www.tux.org/~niemi/
D: Assistant maintainer of Mtools, fdutils, and floppy driver
D: Administrator of Tux.Org Linux Server, http://www.tux.org
D: Administrator of Tux.Org Linux Server, https://www.tux.org
S: 2364 Old Trail Drive
S: Reston, Virginia 20191
S: USA
......@@ -2850,7 +2850,7 @@ S: USA
N: Mikulas Patocka
E: mikulas@artax.karlin.mff.cuni.cz
W: http://artax.karlin.mff.cuni.cz/~mikulas/
W: https://artax.karlin.mff.cuni.cz/~mikulas/
P: 1024/BB11D2D5 A0 F1 28 4A C4 14 1E CF 92 58 7A 8F 69 BC A4 D3
D: Read/write HPFS filesystem
S: Weissova 8
......@@ -2872,7 +2872,7 @@ D: RFC2385 Support for TCP
N: Barak A. Pearlmutter
E: bap@cs.unm.edu
W: http://www.cs.unm.edu/~bap/
W: https://www.cs.unm.edu/~bap/
P: 512/602D785D 9B A1 83 CD EE CB AD 93 20 C6 4C B7 F5 E9 60 D4
D: Author of mark-and-sweep GC integrated by Alan Cox
S: Computer Science Department
......@@ -3035,7 +3035,7 @@ S: United Kingdom
N: Daniel Quinlan
E: quinlan@pathname.com
W: http://www.pathname.com/~quinlan/
W: https://www.pathname.com/~quinlan/
D: FSSTND coordinator; FHS editor
D: random Linux documentation, patches, and hacks
S: 4390 Albany Drive #41A
......@@ -3130,7 +3130,7 @@ S: France
N: Rik van Riel
E: riel@redhat.com
W: http://www.surriel.com/
W: https://www.surriel.com/
D: Linux-MM site, Documentation/admin-guide/sysctl/*, swap/mm readaround
D: kswapd fixes, random kernel hacker, rmap VM,
D: nl.linux.org administrator, minor scheduler additions
......@@ -3246,7 +3246,7 @@ S: Germany
N: Paul `Rusty' Russell
E: rusty@rustcorp.com.au
W: http://ozlabs.org/~rusty
W: https://ozlabs.org/~rusty
D: Ruggedly handsome.
D: netfilter, ipchains with Michael Neuling.
S: 52 Moore St
......@@ -3369,7 +3369,7 @@ S: Germany
N: Robert Schwebel
E: robert@schwebel.de
W: http://www.schwebel.de
W: https://www.schwebel.de
D: Embedded hacker and book author,
D: AMD Elan support for Linux
S: Pengutronix
......@@ -3545,7 +3545,7 @@ S: Australia
N: Henrik Storner
E: storner@image.dk
W: http://www.image.dk/~storner/
W: http://www.sslug.dk/
W: https://www.sslug.dk/
D: Configure script: Invented tristate for module-configuration
D: vfat/msdos integration, kerneld docs, Linux promotion
D: Miscellaneous bug-fixes
......@@ -3579,7 +3579,7 @@ S: USA
N: Eugene Surovegin
E: ebs@ebshome.net
W: http://kernel.ebshome.net/
W: https://kernel.ebshome.net/
P: 1024D/AE5467F1 FF22 39F1 6728 89F6 6E6C 2365 7602 F33D AE54 67F1
D: Embedded PowerPC 4xx: EMAC, I2C, PIC and random hacks/fixes
S: Sunnyvale, California 94085
......@@ -3609,7 +3609,7 @@ S: France
N: Urs Thuermann
E: urs.thuermann@volkswagen.de
W: http://www.volkswagen.de
W: https://www.volkswagen.de
D: Controller Area Network (network layer core)
S: Brieffach 1776
S: 38436 Wolfsburg
......@@ -3656,7 +3656,7 @@ S: Canada K2L 1S2
N: Andrew Tridgell
E: tridge@samba.org
W: http://samba.org/tridge/
W: https://samba.org/tridge/
D: dosemu, networking, samba
S: 3 Ballow Crescent
S: MacGregor A.C.T 2615
......@@ -3894,7 +3894,7 @@ D: The Linux Support Team Erlangen
N: David Weinehall
E: tao@acc.umu.se
P: 1024D/DC47CA16 7ACE 0FB0 7A74 F994 9B36 E1D1 D14E 8526 DC47 CA16
W: http://www.acc.umu.se/~tao/
W: https://www.acc.umu.se/~tao/
D: v2.0 kernel maintainer
D: Fixes for the NE/2-driver
D: Miscellaneous MCA-support
......@@ -3919,7 +3919,7 @@ S: USA
N: Harald Welte
E: laforge@netfilter.org
P: 1024D/30F48BFF DBDE 6912 8831 9A53 879B 9190 5DA5 C655 30F4 8BFF
W: http://gnumonks.org/users/laforge
W: https://gnumonks.org/users/laforge
D: netfilter: new nat helper infrastructure
D: netfilter: ULOG, ECN, DSCP target
D: netfilter: TTL match
......
......@@ -8,7 +8,7 @@ Description:
to device min/max capabilities. Values are integer as they are
stored in a 8bit register in the device. Lowest value is
automatically put to TL. Once set, alarms could be search at
master level, refer to Documentation/w1/w1_generic.rst for
master level, refer to Documentation/w1/w1-generic.rst for
detailed information
Users: any user space application which wants to communicate with
w1_term device
......
.. SPDX-License-Identifier: GPL-2.0
==========================
PCI Test Endpoint Function
==========================
name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
Configurable Fields:
================ ===========================================================
vendorid should be 0x104c
deviceid should be 0xb500 for DRA74x and 0xb501 for DRA72x
revid don't care
progif_code don't care
subclass_code don't care
baseclass_code should be 0xff
cache_line_size don't care
subsys_vendor_id don't care
subsys_id don't care
interrupt_pin Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
msi_interrupts Should be 1 to 32 depending on the number of MSI interrupts
to test
msix_interrupts Should be 1 to 2048 depending on the number of MSI-X
interrupts to test
================ ===========================================================
PCI TEST ENDPOINT FUNCTION
name: Should be "pci_epf_test" to bind to the pci_epf_test driver.
Configurable Fields:
vendorid : should be 0x104c
deviceid : should be 0xb500 for DRA74x and 0xb501 for DRA72x
revid : don't care
progif_code : don't care
subclass_code : don't care
baseclass_code : should be 0xff
cache_line_size : don't care
subsys_vendor_id : don't care
subsys_id : don't care
interrupt_pin : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
msi_interrupts : Should be 1 to 32 depending on the number of MSI interrupts
to test
msix_interrupts : Should be 1 to 2048 depending on the number of MSI-X
interrupts to test
......@@ -11,3 +11,5 @@ PCI Endpoint Framework
pci-endpoint-cfs
pci-test-function
pci-test-howto
function/binding/pci-test
......@@ -24,7 +24,7 @@ Directory Structure
The pci_ep configfs has two directories at its root: controllers and
functions. Every EPC device present in the system will have an entry in
the *controllers* directory and and every EPF driver present in the system
the *controllers* directory and every EPF driver present in the system
will have an entry in the *functions* directory.
::
......
......@@ -214,7 +214,7 @@ pci-ep-cfs.c can be used as reference for using these APIs.
* pci_epf_create()
Create a new PCI EPF device by passing the name of the PCI EPF device.
This name will be used to bind the the EPF device to a EPF driver.
This name will be used to bind the EPF device to a EPF driver.
* pci_epf_destroy()
......
......@@ -248,7 +248,7 @@ STEP 4: Slot Reset
------------------
In response to a return value of PCI_ERS_RESULT_NEED_RESET, the
the platform will perform a slot reset on the requesting PCI device(s).
platform will perform a slot reset on the requesting PCI device(s).
The actual steps taken by a platform to perform a slot reset
will be platform-dependent. Upon completion of slot reset, the
platform will call the device slot_reset() callback.
......
......@@ -209,7 +209,7 @@ the PCI device by calling pci_enable_device(). This will:
OS BUG: we don't check resource allocations before enabling those
resources. The sequence would make more sense if we called
pci_request_resources() before calling pci_enable_device().
Currently, the device drivers can't detect the bug when when two
Currently, the device drivers can't detect the bug when two
devices have been allocated the same range. This is not a common
problem and unlikely to get fixed soon.
......@@ -265,7 +265,7 @@ Set the DMA mask size
---------------------
.. note::
If anything below doesn't make sense, please refer to
Documentation/DMA-API.txt. This section is just a reminder that
:doc:`/core-api/dma-api`. This section is just a reminder that
drivers need to indicate DMA capabilities of the device and is not
an authoritative source for DMA interfaces.
......@@ -291,7 +291,7 @@ Many 64-bit "PCI" devices (before PCI-X) and some PCI-X devices are
Setup shared control data
-------------------------
Once the DMA masks are set, the driver can allocate "consistent" (a.k.a. shared)
memory. See Documentation/DMA-API.txt for a full description of
memory. See :doc:`/core-api/dma-api` for a full description of
the DMA APIs. This section is just a reminder that it needs to be done
before enabling DMA on the device.
......@@ -421,7 +421,7 @@ owners if there is one.
Then clean up "consistent" buffers which contain the control data.
See Documentation/DMA-API.txt for details on unmapping interfaces.
See :doc:`/core-api/dma-api` for details on unmapping interfaces.
Unregister from other subsystems
......
......@@ -19,9 +19,10 @@ attach to other running processes (e.g. Firefox, SSH sessions, GPG agent,
etc) to extract additional credentials and continue to expand the scope
of their attack without resorting to user-assisted phishing.
This is not a theoretical problem. SSH session hijacking
(http://www.storm.net.nz/projects/7) and arbitrary code injection
(http://c-skills.blogspot.com/2007/05/injectso.html) attacks already
This is not a theoretical problem. `SSH session hijacking
<https://www.blackhat.com/presentations/bh-usa-05/bh-us-05-boileau.pdf>`_
and `arbitrary code injection
<https://c-skills.blogspot.com/2007/05/injectso.html>`_ attacks already
exist and remain possible if ptrace is allowed to operate as before.
Since ptrace is not commonly used by non-developers and non-admins, system
builders should be allowed the option to disable this debugging system.
......
......@@ -10,7 +10,7 @@ Description
clusters and in this context, is a "drop-in" replacement for shared
storage. Simplistically, you could see it as a network RAID 1.
Please visit http://www.drbd.org to find out more.
Please visit https://www.drbd.org to find out more.
.. toctree::
:maxdepth: 1
......
......@@ -6,7 +6,7 @@ FAQ list:
=========
A FAQ list may be found in the fdutils package (see below), and also
at <http://fdutils.linux.lu/faq.html>.
at <https://fdutils.linux.lu/faq.html>.
LILO configuration options (Thinkpad users, read this)
......@@ -220,11 +220,11 @@ It also contains additional documentation about the floppy driver.
The latest version can be found at fdutils homepage:
http://fdutils.linux.lu
https://fdutils.linux.lu
The fdutils releases can be found at:
http://fdutils.linux.lu/download.html
https://fdutils.linux.lu/download.html
http://www.tux.org/pub/knaff/fdutils/
......
......@@ -114,4 +114,4 @@ Following resources can be accounted by rdma controller.
(d) Delete resource limit::
echo echo mlx4_0 hca_handle=max hca_object=max > /sys/fs/cgroup/rdma/1/rdma.max
echo mlx4_0 hca_handle=max hca_object=max > /sys/fs/cgroup/rdma/1/rdma.max
......@@ -1683,9 +1683,9 @@ per-cgroup dirty memory states are examined and the more restrictive
of the two is enforced.
cgroup writeback requires explicit support from the underlying
filesystem. Currently, cgroup writeback is implemented on ext2, ext4
and btrfs. On other filesystems, all writeback IOs are attributed to
the root cgroup.
filesystem. Currently, cgroup writeback is implemented on ext2, ext4,
btrfs, f2fs, and xfs. On other filesystems, all writeback IOs are
attributed to the root cgroup.
There are inherent differences in memory and writeback management
which affects how cgroup ownership is tracked. Memory is tracked per
......@@ -2042,7 +2042,7 @@ RDMA
----
The "rdma" controller regulates the distribution and accounting of
of RDMA resources.
RDMA resources.
RDMA Interface Files
~~~~~~~~~~~~~~~~~~~~
......
......@@ -98,7 +98,7 @@ x) Finish support for SMB3.1.1 compression
Known Bugs
==========
See http://bugzilla.samba.org - search on product "CifsVFS" for
See https://bugzilla.samba.org - search on product "CifsVFS" for
current bug list. Also check http://bugzilla.kernel.org (Product = File System, Component = CIFS)
1) existing symbolic links (Windows reparse points) are recognized but
......
......@@ -16,8 +16,7 @@ standard for interoperating between Macs and Windows and major NAS appliances.
Please see
MS-SMB2 (for detailed SMB2/SMB3/SMB3.1.1 protocol specification)
http://protocolfreedom.org/ and
http://samba.org/samba/PFIF/
or https://samba.org/samba/PFIF/
for more details.
......@@ -32,7 +31,7 @@ Build instructions
For Linux:
1) Download the kernel (e.g. from http://www.kernel.org)
1) Download the kernel (e.g. from https://www.kernel.org)
and change directory into the top of the kernel directory tree
(e.g. /usr/src/linux-2.5.73)
2) make menuconfig (or make xconfig)
......@@ -831,7 +830,7 @@ the active sessions and the shares that are mounted.
Enabling Kerberos (extended security) works but requires version 1.2 or later
of the helper program cifs.upcall to be present and to be configured in the
/etc/request-key.conf file. The cifs.upcall helper program is from the Samba
project(http://www.samba.org). NTLM and NTLMv2 and LANMAN support do not
project(https://www.samba.org). NTLM and NTLMv2 and LANMAN support do not
require this helper. Note that NTLMv2 security (which does not require the
cifs.upcall helper program), instead of using Kerberos, is sufficient for
some use cases.
......
......@@ -16,7 +16,7 @@
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
# along with this program. If not, see <https://www.gnu.org/licenses/>.
#
while(<>) {
......
......@@ -26,7 +26,7 @@ Please go to http://support.dell.com register and you can find info on
OpenManage and Dell Update packages (DUP).
Libsmbios can also be used to update BIOS on Dell systems go to
http://linux.dell.com/libsmbios/ for details.
https://linux.dell.com/libsmbios/ for details.
Dell_RBU driver supports BIOS update using the monolithic image and packetized
image methods. In case of monolithic the driver allocates a contiguous chunk
......
......@@ -45,7 +45,7 @@ To use the target for the first time:
will format the device
3. unload the dm-integrity target
4. read the "provided_data_sectors" value from the superblock
5. load the dm-integrity target with the the target size
5. load the dm-integrity target with the target size
"provided_data_sectors"
6. if you want to use dm-integrity with dm-crypt, load the dm-crypt target
with the size "provided_data_sectors"
......@@ -99,7 +99,7 @@ interleave_sectors:number
the superblock is used.
meta_device:device
Don't interleave the data and metadata on on device. Use a
Don't interleave the data and metadata on the device. Use a
separate device for metadata.
buffer_sectors:number
......
......@@ -71,7 +71,7 @@ The target is named "raid" and it accepts the following parameters::
============= ===============================================================
Reference: Chapter 4 of
http://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
https://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
<#raid_params>: The number of parameters that follow.
......
......@@ -14,7 +14,7 @@ host-aware zoned block devices.
For a more detailed description of the zoned block device models and
their constraints see (for SCSI devices):
http://www.t10.org/drafts.htm#ZBC_Family
https://www.t10.org/drafts.htm#ZBC_Family
and (for ATA devices):
......
......@@ -375,8 +375,9 @@
239 = /dev/uhid User-space I/O driver support for HID subsystem
240 = /dev/userio Serio driver testing device
241 = /dev/vhost-vsock Host kernel driver for virtio vsock
242 = /dev/rfkill Turning off radio transmissions (rfkill)
242-254 Reserved for local use
243-254 Reserved for local use
255 Reserved for MISC_DYNAMIC_MINOR
11 char Raw keyboard device (Linux/SPARC only)
......@@ -1442,7 +1443,7 @@
...
The driver and documentation may be obtained from
http://www.winradio.com/
https://www.winradio.com/
82 block I2O hard disk
0 = /dev/i2o/hdag 33rd I2O hard disk, whole disk
......@@ -1656,7 +1657,7 @@
dynamically, so there is no fixed mapping from subdevice
pathnames to minor numbers.
See http://www.comedi.org/ for information about the Comedi
See https://www.comedi.org/ for information about the Comedi
project.
98 block User-mode virtual block device
......@@ -1723,7 +1724,7 @@
implementations a kernel presence for caching and easy
mounting. For more information about the project,
write to <arla-drinkers@stacken.kth.se> or see
http://www.stacken.kth.se/project/arla/
https://www.stacken.kth.se/project/arla/
103 block Audit device
0 = /dev/audit Audit device
......
......@@ -618,7 +618,7 @@ kernel source: <file:fs/ext4/>
programs: http://e2fsprogs.sourceforge.net/
useful links: http://fedoraproject.org/wiki/ext3-devel
useful links: https://fedoraproject.org/wiki/ext3-devel
http://www.bullopensource.org/ext4/
http://ext4.wiki.kernel.org/index.php/Main_Page
http://fedoraproject.org/wiki/Features/Ext4
https://fedoraproject.org/wiki/Features/Ext4
......@@ -14,7 +14,7 @@ to the core through the special register mechanism that is susceptible
to MDS attacks.
Affected processors
--------------------
-------------------
Core models (desktop, mobile, Xeon-E3) that implement RDRAND and/or RDSEED may
be affected.
......@@ -59,7 +59,7 @@ executed on another core or sibling thread using MDS techniques.
Mitigation mechanism
-------------------
--------------------
Intel will release microcode updates that modify the RDRAND, RDSEED, and
EGETKEY instructions to overwrite secret special register data in the shared
staging buffer before the secret data can be accessed by another logical
......@@ -118,7 +118,7 @@ with the option "srbds=". The option for this is:
============= =============================================================
SRBDS System Information
-----------------------
------------------------
The Linux kernel provides vulnerability status information through sysfs. For
SRBDS this can be accessed by the following sysfs file:
/sys/devices/system/cpu/vulnerabilities/srbds
......
......@@ -41,6 +41,7 @@ problems and bugs in particular.
init
kdump/index
perf/index
pstore-blk
This is the beginning of a section with information of interest to
application developers. Documents covering various aspects of the kernel
......
......@@ -1212,26 +1212,28 @@
Format: {"off" | "on" | "skip[mbr]"}
efi= [EFI]
Format: { "old_map", "nochunk", "noruntime", "debug",
"nosoftreserve", "disable_early_pci_dma",
"no_disable_early_pci_dma" }
old_map [X86-64]: switch to the old ioremap-based EFI
runtime services mapping. [Needs CONFIG_X86_UV=y]
Format: { "debug", "disable_early_pci_dma",
"nochunk", "noruntime", "nosoftreserve",
"novamap", "no_disable_early_pci_dma",
"old_map" }
debug: enable misc debug output.
disable_early_pci_dma: disable the busmaster bit on all
PCI bridges while in the EFI boot stub.
nochunk: disable reading files in "chunks" in the EFI
boot stub, as chunking can cause problems with some
firmware implementations.
noruntime : disable EFI runtime services support
debug: enable misc debug output
nosoftreserve: The EFI_MEMORY_SP (Specific Purpose)
attribute may cause the kernel to reserve the
memory range for a memory mapping driver to
claim. Specify efi=nosoftreserve to disable this
reservation and treat the memory by its base type
(i.e. EFI_CONVENTIONAL_MEMORY / "System RAM").
disable_early_pci_dma: Disable the busmaster bit on all
PCI bridges while in the EFI boot stub
novamap: do not call SetVirtualAddressMap().
no_disable_early_pci_dma: Leave the busmaster bit set
on all PCI bridges while in the EFI boot stub
old_map [X86-64]: switch to the old ioremap-based EFI
runtime services mapping. [Needs CONFIG_X86_UV=y]
efi_no_storage_paranoia [EFI; X86]
Using this parameter you can use more than 50% of
......@@ -2791,7 +2793,7 @@
touchscreen support is not enabled in the mainstream
kernel as of 2.6.30, a preliminary port can be found
in the "bleeding edge" mini2440 support kernel at
http://repo.or.cz/w/linux-2.6/mini2440.git
https://repo.or.cz/w/linux-2.6/mini2440.git
mitigations=
[X86,PPC,S390,ARM64] Control optional mitigations for
......
......@@ -135,7 +135,7 @@ single project which, although still considered experimental, is fit
for use. Please feel free to add projects that have been the victims
of my ignorance.
- http://www.thinkwiki.org/wiki/HDAPS
- https://www.thinkwiki.org/wiki/HDAPS
See this page for information about Linux support of the hard disk
active protection system as implemented in IBM/Lenovo Thinkpads.
......
......@@ -151,7 +151,7 @@ Bugs:
different way to adjust the backlighting of the screen. There
is a userspace utility to adjust the brightness on those models,
which can be downloaded from
http://www.acc.umu.se/~erikw/program/smartdimmer-0.1.tar.bz2
https://www.acc.umu.se/~erikw/program/smartdimmer-0.1.tar.bz2
- since all development was done by reverse engineering, there is
*absolutely no guarantee* that this driver will not crash your
......
......@@ -905,7 +905,7 @@ temperatures:
The mapping of thermal sensors to physical locations varies depending on
system-board model (and thus, on ThinkPad model).
http://thinkwiki.org/wiki/Thermal_Sensors is a public wiki page that
https://thinkwiki.org/wiki/Thermal_Sensors is a public wiki page that
tries to track down these locations for various models.
Most (newer?) models seem to follow this pattern:
......@@ -926,7 +926,7 @@ For the R51 (source: Thomas Gruber):
- 3: Internal HDD
For the T43, T43/p (source: Shmidoax/Thinkwiki.org)
http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p
https://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p
- 2: System board, left side (near PCMCIA slot), reported as HDAPS temp
- 3: PCMCIA slot
......@@ -936,7 +936,7 @@ http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_T43.2C_T43p
- 11: Power regulator, underside of system board, below F2 key
The A31 has a very atypical layout for the thermal sensors
(source: Milos Popovic, http://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_A31)
(source: Milos Popovic, https://thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_A31)
- 1: CPU
- 2: Main Battery: main sensor
......
......@@ -90,7 +90,7 @@ built as modules.
Those GPU-specific drivers are selected via the ``Graphics support``
menu, under ``Device Drivers``.
When a GPU driver supports supports HDMI CEC, it will automatically
When a GPU driver supports HDMI CEC, it will automatically
enable the CEC core support at the media subsystem.
Media dependencies
......@@ -244,7 +244,7 @@ functionality.
If you have an hybrid card, you may need to enable both ``Analog TV``
and ``Digital TV`` at the menu.
When using this option, the defaults for the the media support core
When using this option, the defaults for the media support core
functionality are usually good enough to provide the basic functionality
for the driver. Yet, you could manually enable some desired extra (optional)
functionality using the settings under each of the following
......
......@@ -35,7 +35,7 @@ physical memory (demand paging) and provides a mechanism for the
protection and controlled sharing of data between processes.
With virtual memory, each and every memory access uses a virtual
address. When the CPU decodes the an instruction that reads (or
address. When the CPU decodes an instruction that reads (or
writes) from (or to) the system memory, it translates the `virtual`
address encoded in that instruction to a `physical` address that the
memory controller can understand.
......
......@@ -101,37 +101,48 @@ be specified in bytes with optional scale suffix [kKmMgG]. The default huge
page size may be selected with the "default_hugepagesz=<size>" boot parameter.
Hugetlb boot command line parameter semantics
hugepagesz - Specify a huge page size. Used in conjunction with hugepages
hugepagesz
Specify a huge page size. Used in conjunction with hugepages
parameter to preallocate a number of huge pages of the specified
size. Hence, hugepagesz and hugepages are typically specified in
pairs such as:
pairs such as::
hugepagesz=2M hugepages=512
hugepagesz can only be specified once on the command line for a
specific huge page size. Valid huge page sizes are architecture
dependent.
hugepages - Specify the number of huge pages to preallocate. This typically
hugepages
Specify the number of huge pages to preallocate. This typically
follows a valid hugepagesz or default_hugepagesz parameter. However,
if hugepages is the first or only hugetlb command line parameter it
implicitly specifies the number of huge pages of default size to
allocate. If the number of huge pages of default size is implicitly
specified, it can not be overwritten by a hugepagesz,hugepages
parameter pair for the default size.
For example, on an architecture with 2M default huge page size:
For example, on an architecture with 2M default huge page size::
hugepages=256 hugepagesz=2M hugepages=512
will result in 256 2M huge pages being allocated and a warning message
indicating that the hugepages=512 parameter is ignored. If a hugepages
parameter is preceded by an invalid hugepagesz parameter, it will
be ignored.
default_hugepagesz - Specify the default huge page size. This parameter can
default_hugepagesz
pecify the default huge page size. This parameter can
only be specified once on the command line. default_hugepagesz can
optionally be followed by the hugepages parameter to preallocate a
specific number of huge pages of default size. The number of default
sized huge pages to preallocate can also be implicitly specified as
mentioned in the hugepages section above. Therefore, on an
architecture with 2M default huge page size:
architecture with 2M default huge page size::
hugepages=256
default_hugepagesz=2M hugepages=256
hugepages=256 default_hugepagesz=2M
will all result in 256 2M huge pages being allocated. Valid default
huge page size is architecture dependent.
......
......@@ -31,6 +31,7 @@ the Linux memory management.
idle_page_tracking
ksm
memory-hotplug
nommu-mmap
numa_memory_policy
numaperf
pagemap
......
......@@ -9,7 +9,7 @@ Overview
KSM is a memory-saving de-duplication feature, enabled by CONFIG_KSM=y,
added to the Linux kernel in 2.6.32. See ``mm/ksm.c`` for its implementation,
and http://lwn.net/Articles/306704/ and http://lwn.net/Articles/330589/
and http://lwn.net/Articles/306704/ and https://lwn.net/Articles/330589/
KSM was originally developed for use with KVM (where it was known as
Kernel Shared Memory), to fit more virtual machines into physical memory,
......@@ -52,7 +52,7 @@ with EAGAIN, but more probably arousing the Out-Of-Memory killer.
If KSM is not configured into the running kernel, madvise MADV_MERGEABLE
and MADV_UNMERGEABLE simply fail with EINVAL. If the running kernel was
built with CONFIG_KSM=y, those calls will normally succeed: even if the
the KSM daemon is not currently running, MADV_MERGEABLE still registers
KSM daemon is not currently running, MADV_MERGEABLE still registers
the range for whenever the KSM daemon is started; even if the range
cannot contain any pages which KSM could actually merge; even if
MADV_UNMERGEABLE is applied to a range which was never MADV_MERGEABLE.
......
......@@ -129,7 +129,7 @@ will create the following directory::
/sys/devices/system/node/nodeX/memory_side_cache/
If that directory is not present, the system either does not not provide
If that directory is not present, the system either does not provide
a memory-side cache, or that information is not accessible to the kernel.
The attributes for each level of cache is provided under its cache
......
......@@ -65,8 +65,8 @@ migrated onto another server by means of the special "fs_locations"
attribute. See `RFC3530 Section 6: Filesystem Migration and Replication`_ and
`Implementation Guide for Referrals in NFSv4`_.
.. _RFC3530 Section 6\: Filesystem Migration and Replication: http://tools.ietf.org/html/rfc3530#section-6
.. _Implementation Guide for Referrals in NFSv4: http://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00
.. _RFC3530 Section 6\: Filesystem Migration and Replication: https://tools.ietf.org/html/rfc3530#section-6
.. _Implementation Guide for Referrals in NFSv4: https://tools.ietf.org/html/draft-ietf-nfsv4-referrals-00
The fs_locations information can take the form of either an ip address and
a path, or a DNS hostname and a path. The latter requires the NFS client to
......
......@@ -65,7 +65,7 @@ use with NFS/RDMA.
If the version is less than 1.1.2 or the command does not exist,
you should install the latest version of nfs-utils.
Download the latest package from: http://www.kernel.org/pub/linux/utils/nfs
Download the latest package from: https://www.kernel.org/pub/linux/utils/nfs
Uncompress the package and follow the installation instructions.
......
......@@ -264,7 +264,7 @@ They depend on various facilities being available:
access to the floppy drive device, /dev/fd0
For more information on syslinux, including how to create bootdisks
for prebuilt kernels, see http://syslinux.zytor.com/
for prebuilt kernels, see https://syslinux.zytor.com/
.. note::
Previously it was possible to write a kernel directly to
......@@ -292,7 +292,7 @@ They depend on various facilities being available:
cdrecord dev=ATAPI:1,0,0 arch/x86/boot/image.iso
For more information on isolinux, including how to create bootdisks
for prebuilt kernels, see http://syslinux.zytor.com/
for prebuilt kernels, see https://syslinux.zytor.com/
- Using LILO
......@@ -346,7 +346,7 @@ They depend on various facilities being available:
see Documentation/admin-guide/serial-console.rst for more information.
For more information on isolinux, including how to create bootdisks
for prebuilt kernels, see http://syslinux.zytor.com/
for prebuilt kernels, see https://syslinux.zytor.com/
......
......@@ -8,7 +8,7 @@ to handling all the metadata access to the NFS export also hands out layouts
to the clients to directly access the underlying block devices that are
shared with the client.
To use pNFS block layouts with with the Linux NFS server the exported file
To use pNFS block layouts with the Linux NFS server the exported file
system needs to support the pNFS block layouts (currently just XFS), and the
file system must sit on shared storage (typically iSCSI) that is accessible
to the clients in addition to the MDS. As of now the file system needs to
......
......@@ -9,7 +9,7 @@ which in addition to handling all the metadata access to the NFS export,
also hands out layouts to the clients so that they can directly access the
underlying SCSI LUNs that are shared with the client.
To use pNFS SCSI layouts with with the Linux NFS server, the exported file
To use pNFS SCSI layouts with the Linux NFS server, the exported file
system needs to support the pNFS SCSI layouts (currently just XFS), and the
file system must sit on a SCSI LUN that is accessible to the clients in
addition to the MDS. As of now the file system needs to sit directly on the
......
......@@ -27,7 +27,7 @@ Crosspoint PMU events require "xp" (index), "bus" (bus number)
and "vc" (virtual channel ID).
Crosspoint watchpoint-based events (special "event" value 0xfe)
require "xp" and "vc" as as above plus "port" (device port index),
require "xp" and "vc" as above plus "port" (device port index),
"dir" (transmit/receive direction), comparator values ("cmp_l"
and "cmp_h") and "mask", being index of the comparator mask.
......
......@@ -114,7 +114,7 @@ base performance profile (which is performance level 0).
Lock/Unlock status
~~~~~~~~~~~~~~~~~~
Even if there are multiple performance profiles, it is possible that that they
Even if there are multiple performance profiles, it is possible that they
are locked. If they are locked, users cannot issue a command to change the
performance state. It is possible that there is a BIOS setup to unlock or check
with your system vendor.
......@@ -883,7 +883,7 @@ To enable Intel(R) SST-TF, execute::
enable:success
In this case, the option "-a" is optional. If set, it enables Intel(R) SST-TF
feature and also sets the CPUs to high and and low priority using Intel Speed
feature and also sets the CPUs to high and low priority using Intel Speed
Select Technology Core Power (Intel(R) SST-CP) features. The CPU numbers passed
with "-c" arguments are marked as high priority, including its siblings.
......
......@@ -723,7 +723,7 @@ core (for the policies with other scaling governors).
The ``ftrace`` interface can be used for low-level diagnostics of
``intel_pstate``. For example, to check how often the function to set a
P-state is called, the ``ftrace`` filter can be set to to
P-state is called, the ``ftrace`` filter can be set to
:c:func:`intel_pstate_set_pstate`::
# cd /sys/kernel/debug/tracing/
......
......@@ -21,11 +21,18 @@ understand and fix the security vulnerability.
As it is with any bug, the more information provided the easier it
will be to diagnose and fix. Please review the procedure outlined in
admin-guide/reporting-bugs.rst if you are unclear about what
:doc:`reporting-bugs` if you are unclear about what
information is helpful. Any exploit code is very helpful and will not
be released without consent from the reporter unless it has already been
made public.
Please send plain text emails without attachments where possible.
It is much harder to have a context-quoted discussion about a complex
issue if all the details are hidden away in attachments. Think of it like a
:doc:`regular patch submission <../process/submitting-patches>`
(even if you don't have a patch yet): describe the problem and impact, list
reproduction steps, and follow it with a proposed fix, all in plain text.
Disclosure and embargoed information
------------------------------------
......
......@@ -261,7 +261,7 @@ directories like /tmp. The common method of exploitation of this flaw
is to cross privilege boundaries when following a given symlink (i.e. a
root process follows a symlink belonging to another user). For a likely
incomplete list of hundreds of examples across the years, please see:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp
When set to "0", symlink following behavior is unrestricted.
......
......@@ -235,7 +235,7 @@ This toggle indicates whether unprivileged users are prevented
from using ``dmesg(8)`` to view messages from the kernel's log
buffer.
When ``dmesg_restrict`` is set to 0 there are no restrictions.
When ``dmesg_restrict`` is set set to 1, users must have
When ``dmesg_restrict`` is set to 1, users must have
``CAP_SYSLOG`` to use ``dmesg(8)``.
The kernel config option ``CONFIG_SECURITY_DMESG_RESTRICT`` sets the
......@@ -335,8 +335,8 @@ Path for the hotplug policy agent.
Default value is "``/sbin/hotplug``".
hung_task_all_cpu_backtrace:
================
hung_task_all_cpu_backtrace
===========================
If this option is set, the kernel will send an NMI to all CPUs to dump
their backtraces when a hung task is detected. This file shows up if
......@@ -646,8 +646,8 @@ rate for each task.
scanned for a given scan.
oops_all_cpu_backtrace:
================
oops_all_cpu_backtrace
======================
If this option is set, the kernel will send an NMI to all CPUs to dump
their backtraces when an oops event occurs. It should be used as a last
......@@ -996,6 +996,38 @@ pty
See Documentation/filesystems/devpts.rst.
random
======
This is a directory, with the following entries:
* ``boot_id``: a UUID generated the first time this is retrieved, and
unvarying after that;
* ``entropy_avail``: the pool's entropy count, in bits;
* ``poolsize``: the entropy pool size, in bits;
* ``urandom_min_reseed_secs``: obsolete (used to determine the minimum
number of seconds between urandom pool reseeding).
* ``uuid``: a UUID generated every time this is retrieved (this can
thus be used to generate UUIDs at will);
* ``write_wakeup_threshold``: when the entropy count drops below this
(as a number of bits), processes waiting to write to ``/dev/random``
are woken up.
If ``drivers/char/random.c`` is built with ``ADD_INTERRUPT_BENCH``
defined, these additional entries are present:
* ``add_interrupt_avg_cycles``: the average number of cycles between
interrupts used to feed the pool;
* ``add_interrupt_avg_deviation``: the standard deviation seen on the
number of cycles between interrupts used to feed the pool.
randomize_va_space
==================
......
......@@ -583,7 +583,7 @@ trimming of allocations is initiated.
The default value is 1.
See Documentation/nommu-mmap.txt for more information.
See Documentation/admin-guide/mm/nommu-mmap.rst for more information.
numa_zonelist_order
......
......@@ -38,7 +38,7 @@ either letters or blanks. In above example it looks like this::
Tainted: P W O
The meaning of those characters is explained in the table below. In tis case
The meaning of those characters is explained in the table below. In this case
the kernel got tainted earlier because a proprietary Module (``P``) was loaded,
a warning occurred (``W``), and an externally-built module was loaded (``O``).
To decode other letters use the table below.
......@@ -61,7 +61,7 @@ this on the machine that had the statements in the logs that were quoted earlier
* Proprietary module was loaded (#0)
* Kernel issued warning (#9)
* Externally-built ('out-of-tree') module was loaded (#12)
See Documentation/admin-guide/tainted-kernels.rst in the the Linux kernel or
See Documentation/admin-guide/tainted-kernels.rst in the Linux kernel or
https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html for
a more details explanation of the various taint flags.
Raw taint value as int/string: 4609/'P W O '
......
......@@ -133,7 +133,7 @@ When mounting an XFS filesystem, the following options are accepted.
logbsize must be an integer multiple of the log
stripe unit configured at **mkfs(8)** time.
The default value for for version 1 logs is 32768, while the
The default value for version 1 logs is 32768, while the
default value for version 2 logs is MAX(32768, log_sunit).
logdev=device and rtdev=device
......
......@@ -128,7 +128,7 @@ it. The recommended placement is in the first 16KiB of RAM.
The boot loader must load a device tree image (dtb) into system ram
at a 64bit aligned address and initialize it with the boot data. The
dtb format is documented in Documentation/devicetree/booting-without-of.txt.
dtb format is documented in Documentation/devicetree/booting-without-of.rst.
The kernel will look for the dtb magic value of 0xd00dfeed at the dtb
physical address to determine if a dtb has been passed instead of a
tagged list.
......
......@@ -220,7 +220,7 @@ LPIT Signature Reserved (signature == "LPIT")
x86 only table as of ACPI 5.1; starting with ACPI 6.0, processor
descriptions and power states on ARM platforms should use the DSDT
and define processor container devices (_HID ACPI0010, Section 8.4,
and more specifically 8.4.3 and and 8.4.4).
and more specifically 8.4.3 and 8.4.4).
MADT Section 5.2.12 (signature == "APIC")
......
......@@ -273,7 +273,7 @@ only use the _DSD Device Properties UUID [5]:
- UUID: daffd814-6eba-4d8c-8a91-bc9bbf4aa301
- http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
- https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf
The UEFI Forum provides a mechanism for registering device properties [4]
so that they may be used across all operating systems supporting ACPI.
......@@ -470,7 +470,7 @@ likely be willing to assist in submitting ECRs.
Linux Code
----------
Individual items specific to Linux on ARM, contained in the the Linux
Individual items specific to Linux on ARM, contained in the Linux
source code, are in the list that follows:
ACPI_OS_NAME
......
......@@ -14,6 +14,7 @@ ARM64 Architecture
hugetlbpage
legacy_instructions
memory
perf
pointer-authentication
silicon-errata
sve
......
.. SPDX-License-Identifier: GPL-2.0
=====================
Perf Event Attributes
=====================
Author: Andrew Murray <andrew.murray@arm.com>
Date: 2019-03-06
:Author: Andrew Murray <andrew.murray@arm.com>
:Date: 2019-03-06
exclude_user
------------
......
......@@ -494,7 +494,7 @@ Appendix B. ARMv8-A FP/SIMD programmer's model
Note: This section is for information only and not intended to be complete or
to replace any architectural specification.
Refer to [4] for for more information.
Refer to [4] for more information.
ARMv8-A defines the following floating-point / SIMD register state:
......
......@@ -196,7 +196,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address
do not have a corresponding kernel virtual address space mapping) and
low-memory pages.
Note: Please refer to Documentation/DMA-API-HOWTO.txt for a discussion
Note: Please refer to :doc:`/core-api/dma-api-howto` for a discussion
on PCI high mem DMA aspects and mapping of scatter gather lists, and support
for 64 bit PCI.
......
.. SPDX-License-Identifier: GPL-2.0
================================================
Multi-Queue Block IO Queueing Mechanism (blk-mq)
================================================
The Multi-Queue Block IO Queueing Mechanism is an API to enable fast storage
devices to achieve a huge number of input/output operations per second (IOPS)
through queueing and submitting IO requests to block devices simultaneously,
benefiting from the parallelism offered by modern storage devices.
Introduction
============
Background
----------
Magnetic hard disks have been the de facto standard from the beginning of the
development of the kernel. The Block IO subsystem aimed to achieve the best
performance possible for those devices with a high penalty when doing random
access, and the bottleneck was the mechanical moving parts, a lot slower than
any layer on the storage stack. One example of such optimization technique
involves ordering read/write requests according to the current position of the
hard disk head.
However, with the development of Solid State Drives and Non-Volatile Memories
without mechanical parts nor random access penalty and capable of performing
high parallel access, the bottleneck of the stack had moved from the storage
device to the operating system. In order to take advantage of the parallelism
in those devices' design, the multi-queue mechanism was introduced.
The former design had a single queue to store block IO requests with a single
lock. That did not scale well in SMP systems due to dirty data in cache and the
bottleneck of having a single lock for multiple processors. This setup also
suffered with congestion when different processes (or the same process, moving
to different CPUs) wanted to perform block IO. Instead of this, the blk-mq API
spawns multiple queues with individual entry points local to the CPU, removing
the need for a lock. A deeper explanation on how this works is covered in the
following section (`Operation`_).
Operation
---------
When the userspace performs IO to a block device (reading or writing a file,
for instance), blk-mq takes action: it will store and manage IO requests to
the block device, acting as middleware between the userspace (and a file
system, if present) and the block device driver.
blk-mq has two group of queues: software staging queues and hardware dispatch
queues. When the request arrives at the block layer, it will try the shortest
path possible: send it directly to the hardware queue. However, there are two
cases that it might not do that: if there's an IO scheduler attached at the
layer or if we want to try to merge requests. In both cases, requests will be
sent to the software queue.
Then, after the requests are processed by software queues, they will be placed
at the hardware queue, a second stage queue were the hardware has direct access
to process those requests. However, if the hardware does not have enough
resources to accept more requests, blk-mq will places requests on a temporary
queue, to be sent in the future, when the hardware is able.
Software staging queues
~~~~~~~~~~~~~~~~~~~~~~~
The block IO subsystem adds requests in the software staging queues
(represented by struct :c:type:`blk_mq_ctx`) in case that they weren't sent
directly to the driver. A request is one or more BIOs. They arrived at the
block layer through the data structure struct :c:type:`bio`. The block layer
will then build a new structure from it, the struct :c:type:`request` that will
be used to communicate with the device driver. Each queue has its own lock and
the number of queues is defined by a per-CPU or per-node basis.
The staging queue can be used to merge requests for adjacent sectors. For
instance, requests for sector 3-6, 6-7, 7-9 can become one request for 3-9.
Even if random access to SSDs and NVMs have the same time of response compared
to sequential access, grouped requests for sequential access decreases the
number of individual requests. This technique of merging requests is called
plugging.
Along with that, the requests can be reordered to ensure fairness of system
resources (e.g. to ensure that no application suffers from starvation) and/or to
improve IO performance, by an IO scheduler.
IO Schedulers
^^^^^^^^^^^^^
There are several schedulers implemented by the block layer, each one following
a heuristic to improve the IO performance. They are "pluggable" (as in plug
and play), in the sense of they can be selected at run time using sysfs. You
can read more about Linux's IO schedulers `here
<https://www.kernel.org/doc/html/latest/block/index.html>`_. The scheduling
happens only between requests in the same queue, so it is not possible to merge
requests from different queues, otherwise there would be cache trashing and a
need to have a lock for each queue. After the scheduling, the requests are
eligible to be sent to the hardware. One of the possible schedulers to be
selected is the NONE scheduler, the most straightforward one. It will just
place requests on whatever software queue the process is running on, without
any reordering. When the device starts processing requests in the hardware
queue (a.k.a. run the hardware queue), the software queues mapped to that
hardware queue will be drained in sequence according to their mapping.
Hardware dispatch queues
~~~~~~~~~~~~~~~~~~~~~~~~
The hardware queue (represented by struct :c:type:`blk_mq_hw_ctx`) is a struct
used by device drivers to map the device submission queues (or device DMA ring
buffer), and are the last step of the block layer submission code before the
low level device driver taking ownership of the request. To run this queue, the
block layer removes requests from the associated software queues and tries to
dispatch to the hardware.
If it's not possible to send the requests directly to hardware, they will be
added to a linked list (:c:type:`hctx->dispatch`) of requests. Then,
next time the block layer runs a queue, it will send the requests laying at the
:c:type:`dispatch` list first, to ensure a fairness dispatch with those
requests that were ready to be sent first. The number of hardware queues
depends on the number of hardware contexts supported by the hardware and its
device driver, but it will not be more than the number of cores of the system.
There is no reordering at this stage, and each software queue has a set of
hardware queues to send requests for.
.. note::
Neither the block layer nor the device protocols guarantee
the order of completion of requests. This must be handled by
higher layers, like the filesystem.
Tag-based completion
~~~~~~~~~~~~~~~~~~~~
In order to indicate which request has been completed, every request is
identified by an integer, ranging from 0 to the dispatch queue size. This tag
is generated by the block layer and later reused by the device driver, removing
the need to create a redundant identifier. When a request is completed in the
drive, the tag is sent back to the block layer to notify it of the finalization.
This removes the need to do a linear search to find out which IO has been
completed.
Further reading
---------------
- `Linux Block IO: Introducing Multi-queue SSD Access on Multi-core Systems <http://kernel.dk/blk-mq.pdf>`_
- `NOOP scheduler <https://en.wikipedia.org/wiki/Noop_scheduler>`_
- `Null block device driver <https://www.kernel.org/doc/html/latest/block/null_blk.html>`_
Source code documentation
=========================
.. kernel-doc:: include/linux/blk-mq.h
.. kernel-doc:: block/blk-mq.c
......@@ -10,6 +10,7 @@ Block
bfq-iosched
biodoc
biovecs
blk-mq
capability
cmdline-partition
data-integrity
......
......@@ -9,7 +9,7 @@ access to block devices to specific initiators in a shared storage
setup.
This document gives a general overview of the support ioctl commands.
For a more detailed reference please refer the the SCSI Primary
For a more detailed reference please refer to the SCSI Primary
Commands standard, specifically the section on Reservations and the
"PERSISTENT RESERVE IN" and "PERSISTENT RESERVE OUT" commands.
......
......@@ -643,5 +643,6 @@ when:
.. _selftests: ../../tools/testing/selftests/bpf/
.. _Documentation/dev-tools/kselftest.rst:
https://www.kernel.org/doc/html/latest/dev-tools/kselftest.html
.. _Documentation/bpf/btf.rst: btf.rst
Happy BPF hacking!
......@@ -58,6 +58,14 @@ Testing and debugging BPF
s390
Other
=====
.. toctree::
:maxdepth: 1
ringbuf
.. Links:
.. _Documentation/networking/filter.rst: ../networking/filter.txt
.. _man-pages: https://www.kernel.org/doc/man-pages/
......
......@@ -8,7 +8,7 @@ How to access I/O mapped memory from within device drivers
The virt_to_bus() and bus_to_virt() functions have been
superseded by the functionality provided by the PCI DMA interface
(see Documentation/DMA-API-HOWTO.txt). They continue
(see :doc:`/core-api/dma-api-howto`). They continue
to be documented below for historical purposes, but new code
must not use them. --davidm 00/12/12
......
......@@ -35,8 +35,8 @@ Command Line Switches
other CPUs later online.
``nr_cpus=n``
Restrict the total amount CPUs the kernel will support. If the number
supplied here is lower than the number of physically available CPUs than
Restrict the total amount of CPUs the kernel will support. If the number
supplied here is lower than the number of physically available CPUs, then
those CPUs can not be brought online later.
``additional_cpus=n``
......
......@@ -5,7 +5,7 @@ Dynamic DMA mapping using the generic device
:Author: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
This document describes the DMA API. For a more gentle introduction
of the API (and actual examples), see Documentation/DMA-API-HOWTO.txt.
of the API (and actual examples), see :doc:`/core-api/dma-api-howto`.
This API is split into two pieces. Part I describes the basic API.
Part II describes extensions for supporting non-consistent memory
......@@ -479,7 +479,7 @@ without the _attrs suffixes, except that they pass an optional
dma_attrs.
The interpretation of DMA attributes is architecture-specific, and
each attribute should be documented in Documentation/DMA-attributes.txt.
each attribute should be documented in :doc:`/core-api/dma-attributes`.
If dma_attrs are 0, the semantics of each of these functions
is identical to those of the corresponding function
......@@ -492,7 +492,7 @@ for DMA::
#include <linux/dma-mapping.h>
/* DMA_ATTR_FOO should be defined in linux/dma-mapping.h and
* documented in Documentation/DMA-attributes.txt */
* documented in Documentation/core-api/dma-attributes.rst */
...
unsigned long attr;
......
......@@ -17,7 +17,7 @@ To do ISA style DMA you need to include two headers::
#include <asm/dma.h>
The first is the generic DMA API used to convert virtual addresses to
bus addresses (see Documentation/DMA-API.txt for details).
bus addresses (see :doc:`/core-api/dma-api` for details).
The second contains the routines specific to ISA DMA transfers. Since
this is not present on all platforms make sure you construct your
......
......@@ -39,6 +39,8 @@ Library functionality that is used throughout the kernel.
rbtree
generic-radix-tree
packing
bus-virt-phys-mapping
this_cpu_ops
timekeeping
errseq
......@@ -82,6 +84,7 @@ more memory-management documentation in :doc:`/vm/index`.
:maxdepth: 1
memory-allocation
unaligned-memory-access
dma-api
dma-api-howto
dma-attributes
......
......@@ -6,7 +6,7 @@ Everything you never wanted to know about kobjects, ksets, and ktypes
:Last updated: December 19, 2007
Based on an original article by Jon Corbet for lwn.net written October 1,
2003 and located at http://lwn.net/Articles/51437/
2003 and located at https://lwn.net/Articles/51437/
Part of the difficulty in understanding the driver model - and the kobject
abstraction upon which it is built - is that there is no obvious starting
......
......@@ -84,6 +84,50 @@ driver for a device with such restrictions, avoid using these flags.
And even with hardware with restrictions it is preferable to use
`dma_alloc*` APIs.
GFP flags and reclaim behavior
------------------------------
Memory allocations may trigger direct or background reclaim and it is
useful to understand how hard the page allocator will try to satisfy that
or another request.
* ``GFP_KERNEL & ~__GFP_RECLAIM`` - optimistic allocation without _any_
attempt to free memory at all. The most light weight mode which even
doesn't kick the background reclaim. Should be used carefully because it
might deplete the memory and the next user might hit the more aggressive
reclaim.
* ``GFP_KERNEL & ~__GFP_DIRECT_RECLAIM`` (or ``GFP_NOWAIT``)- optimistic
allocation without any attempt to free memory from the current
context but can wake kswapd to reclaim memory if the zone is below
the low watermark. Can be used from either atomic contexts or when
the request is a performance optimization and there is another
fallback for a slow path.
* ``(GFP_KERNEL|__GFP_HIGH) & ~__GFP_DIRECT_RECLAIM`` (aka ``GFP_ATOMIC``) -
non sleeping allocation with an expensive fallback so it can access
some portion of memory reserves. Usually used from interrupt/bottom-half
context with an expensive slow path fallback.
* ``GFP_KERNEL`` - both background and direct reclaim are allowed and the
**default** page allocator behavior is used. That means that not costly
allocation requests are basically no-fail but there is no guarantee of
that behavior so failures have to be checked properly by callers
(e.g. OOM killer victim is allowed to fail currently).
* ``GFP_KERNEL | __GFP_NORETRY`` - overrides the default allocator behavior
and all allocation requests fail early rather than cause disruptive
reclaim (one round of reclaim in this implementation). The OOM killer
is not invoked.
* ``GFP_KERNEL | __GFP_RETRY_MAYFAIL`` - overrides the default allocator
behavior and all allocation requests try really hard. The request
will fail if the reclaim cannot make any progress. The OOM killer
won't be triggered.
* ``GFP_KERNEL | __GFP_NOFAIL`` - overrides the default allocator behavior
and all allocation requests will loop endlessly until they succeed.
This might be really dangerous especially for larger orders.
Selecting memory allocator
==========================
......
......@@ -69,7 +69,7 @@ You can check the current *console_loglevel* with::
The result shows the *current*, *default*, *minimum* and *boot-time-default* log
levels.
To change the current console_loglevel simply write the the desired level to
To change the current console_loglevel simply write the desired level to
``/proc/sys/kernel/printk``. For example, to print all messages to the console::
# echo 8 > /proc/sys/kernel/printk
......
......@@ -494,9 +494,11 @@ Time and date
%pt[RT]t HH:MM:SS
%pt[RT][dt][r]
For printing date and time as represented by
For printing date and time as represented by::
R struct rtc_time structure
T time64_t type
in human readable format.
By default year will be incremented by 1900 and month by 1.
......
.. SPDX-License-Identifier: GPL-2.0
Scatterlist Cryptographic API
=============================
Scatterlist Cryptographic API
=============================
INTRODUCTION
Introduction
============
The Scatterlist Crypto API takes page vectors (scatterlists) as
arguments, and works directly on pages. In some cases (e.g. ECB
......@@ -13,7 +17,8 @@ so that processing can be applied to paged skb's without the need
for linearization.
DETAILS
Details
=======
At the lowest level are algorithms, which register dynamically with the
API.
......@@ -23,7 +28,7 @@ of the implementation logic (e.g. manipulating page vectors) and provide an
abstraction to the underlying algorithms. However, at the user
level they are very simple.
Conceptually, the API layering looks like this:
Conceptually, the API layering looks like this::
[transform api] (user interface)
[transform ops] (per-type logic glue e.g. cipher.c, compress.c)
......@@ -44,7 +49,7 @@ one block while the former can operate on an arbitrary amount of data,
subject to block size requirements (i.e., non-stream ciphers can only
process multiples of blocks).
Here's an example of how to use the API:
Here's an example of how to use the API::
#include <crypto/hash.h>
#include <linux/err.h>
......@@ -78,7 +83,8 @@ Here's an example of how to use the API:
Many real examples are available in the regression test module (tcrypt.c).
DEVELOPER NOTES
Developer Notes
===============
Transforms may only be allocated in user context, and cryptographic
methods may only be called from softirq and user contexts. For
......@@ -91,7 +97,8 @@ size (typically 8 bytes). This prevents having to do any copying
across non-aligned page fragment boundaries.
ADDING NEW ALGORITHMS
Adding New Algorithms
=====================
When submitting a new algorithm for inclusion, a mandatory requirement
is that at least a few test vectors from known sources (preferably
......@@ -119,132 +126,137 @@ Also check the TODO list at the web site listed below to see what people
might already be working on.
BUGS
Bugs
====
Send bug reports to:
linux-crypto@vger.kernel.org
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
linux-crypto@vger.kernel.org
Cc:
Herbert Xu <herbert@gondor.apana.org.au>,
David S. Miller <davem@redhat.com>
FURTHER INFORMATION
Further Information
===================
For further patches and various updates, including the current TODO
list, see:
http://gondor.apana.org.au/~herbert/crypto/
AUTHORS
Authors
=======
James Morris
David S. Miller
Herbert Xu
- James Morris
- David S. Miller
- Herbert Xu
CREDITS
Credits
=======
The following people provided invaluable feedback during the development
of the API:
Alexey Kuznetzov
Rusty Russell
Herbert Valerio Riedel
Jeff Garzik
Michael Richardson
Andrew Morton
Ingo Oeser
Christoph Hellwig
- Alexey Kuznetzov
- Rusty Russell
- Herbert Valerio Riedel
- Jeff Garzik
- Michael Richardson
- Andrew Morton
- Ingo Oeser
- Christoph Hellwig
Portions of this API were derived from the following projects:
Kerneli Cryptoapi (http://www.kerneli.org/)
Alexander Kjeldaas
Herbert Valerio Riedel
Kyle McMartin
Jean-Luc Cooke
David Bryson
Clemens Fruhwirth
Tobias Ringstrom
Harald Welte
- Alexander Kjeldaas
- Herbert Valerio Riedel
- Kyle McMartin
- Jean-Luc Cooke
- David Bryson
- Clemens Fruhwirth
- Tobias Ringstrom
- Harald Welte
and;
Nettle (https://www.lysator.liu.se/~nisse/nettle/)
Niels Möller
- Niels Möller
Original developers of the crypto algorithms:
Dana L. How (DES)
Andrew Tridgell and Steve French (MD4)
Colin Plumb (MD5)
Steve Reid (SHA1)
Jean-Luc Cooke (SHA256, SHA384, SHA512)
Kazunori Miyazawa / USAGI (HMAC)
Matthew Skala (Twofish)
Dag Arne Osvik (Serpent)
Brian Gladman (AES)
Kartikey Mahendra Bhatt (CAST6)
Jon Oberheide (ARC4)
Jouni Malinen (Michael MIC)
NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
- Dana L. How (DES)
- Andrew Tridgell and Steve French (MD4)
- Colin Plumb (MD5)
- Steve Reid (SHA1)
- Jean-Luc Cooke (SHA256, SHA384, SHA512)
- Kazunori Miyazawa / USAGI (HMAC)
- Matthew Skala (Twofish)
- Dag Arne Osvik (Serpent)
- Brian Gladman (AES)
- Kartikey Mahendra Bhatt (CAST6)
- Jon Oberheide (ARC4)
- Jouni Malinen (Michael MIC)
- NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
SHA1 algorithm contributors:
Jean-Francois Dive
- Jean-Francois Dive
DES algorithm contributors:
Raimar Falke
Gisle Sælensminde
Niels Möller
- Raimar Falke
- Gisle Sælensminde
- Niels Möller
Blowfish algorithm contributors:
Herbert Valerio Riedel
Kyle McMartin
- Herbert Valerio Riedel
- Kyle McMartin
Twofish algorithm contributors:
Werner Koch
Marc Mutz
- Werner Koch
- Marc Mutz
SHA256/384/512 algorithm contributors:
Andrew McDonald
Kyle McMartin
Herbert Valerio Riedel
- Andrew McDonald
- Kyle McMartin
- Herbert Valerio Riedel
AES algorithm contributors:
Alexander Kjeldaas
Herbert Valerio Riedel
Kyle McMartin
Adam J. Richter
Fruhwirth Clemens (i586)
Linus Torvalds (i586)
- Alexander Kjeldaas
- Herbert Valerio Riedel
- Kyle McMartin
- Adam J. Richter
- Fruhwirth Clemens (i586)
- Linus Torvalds (i586)
CAST5 algorithm contributors:
Kartikey Mahendra Bhatt (original developers unknown, FSF copyright).
- Kartikey Mahendra Bhatt (original developers unknown, FSF copyright).
TEA/XTEA algorithm contributors:
Aaron Grothe
Michael Ringe
- Aaron Grothe
- Michael Ringe
Khazad algorithm contributors:
Aaron Grothe
- Aaron Grothe
Whirlpool algorithm contributors:
Aaron Grothe
Jean-Luc Cooke
- Aaron Grothe
- Jean-Luc Cooke
Anubis algorithm contributors:
Aaron Grothe
- Aaron Grothe
Tiger algorithm contributors:
Aaron Grothe
- Aaron Grothe
VIA PadLock contributors:
Michal Ludvig
- Michal Ludvig
Camellia algorithm contributors:
NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
- NTT(Nippon Telegraph and Telephone Corporation) (Camellia)
Generic scatterwalk code by Adam J. Richter <adam@yggdrasil.com>
Please send any credits updates or corrections to:
Herbert Xu <herbert@gondor.apana.org.au>
......@@ -17,9 +17,14 @@ for cryptographic use cases, as well as programming examples.
:maxdepth: 2
intro
api-intro
architecture
async-tx-api
asymmetric-keys
devel-algos
userspace-if
crypto_engine
api
api-samples
descore-readme
......@@ -85,7 +85,7 @@ Four basic modes are defined: ``patch``, ``report``, ``context``, and
file:line:column-column: message
- ``context`` highlights lines of interest and their context in a
diff-like style.Lines of interest are indicated with ``-``.
diff-like style. Lines of interest are indicated with ``-``.
- ``org`` generates a report in the Org mode format of Emacs.
......@@ -119,7 +119,7 @@ For each semantic patch, a commit message is proposed. It gives a
description of the problem being checked by the semantic patch, and
includes a reference to Coccinelle.
As any static code analyzer, Coccinelle produces false
As with any static code analyzer, Coccinelle produces false
positives. Thus, reports must be carefully checked, and patches
reviewed.
......@@ -135,18 +135,18 @@ the parallelism, set the J= variable. For example, to run across 4 CPUs::
make coccicheck MODE=report J=4
As of Coccinelle 1.0.2 Coccinelle uses Ocaml parmap for parallelization,
As of Coccinelle 1.0.2 Coccinelle uses Ocaml parmap for parallelization;
if support for this is detected you will benefit from parmap parallelization.
When parmap is enabled coccicheck will enable dynamic load balancing by using
``--chunksize 1`` argument, this ensures we keep feeding threads with work
``--chunksize 1`` argument. This ensures we keep feeding threads with work
one by one, so that we avoid the situation where most work gets done by only
a few threads. With dynamic load balancing, if a thread finishes early we keep
feeding it more work.
When parmap is enabled, if an error occurs in Coccinelle, this error
value is propagated back, the return value of the ``make coccicheck``
captures this return value.
value is propagated back, and the return value of the ``make coccicheck``
command captures this return value.
Using Coccinelle with a single semantic patch
---------------------------------------------
......@@ -183,7 +183,7 @@ To check only newly edited code, use the value 2 for the C flag, i.e.::
make C=2 CHECK="scripts/coccicheck"
In these modes, which works on a file basis, there is no information
In these modes, which work on a file basis, there is no information
about semantic patches displayed, and no commit message proposed.
This runs every semantic patch in scripts/coccinelle by default. The
......@@ -198,12 +198,12 @@ Debugging Coccinelle SmPL patches
Using coccicheck is best as it provides in the spatch command line
include options matching the options used when we compile the kernel.
You can learn what these options are by using V=1, you could then
You can learn what these options are by using V=1; you could then
manually run Coccinelle with debug options added.
Alternatively you can debug running Coccinelle against SmPL patches
by asking for stderr to be redirected to stderr, by default stderr
is redirected to /dev/null, if you'd like to capture stderr you
by asking for stderr to be redirected to stderr. By default stderr
is redirected to /dev/null; if you'd like to capture stderr you
can specify the ``DEBUG_FILE="file.txt"`` option to coccicheck. For
instance::
......@@ -211,8 +211,8 @@ instance::
make coccicheck COCCI=scripts/coccinelle/free/kfree.cocci MODE=report DEBUG_FILE=cocci.err
cat cocci.err
You can use SPFLAGS to add debugging flags, for instance you may want to
add both --profile --show-trying to SPFLAGS when debugging. For instance
You can use SPFLAGS to add debugging flags; for instance you may want to
add both --profile --show-trying to SPFLAGS when debugging. For example
you may want to use::
rm -f err.log
......@@ -229,7 +229,7 @@ DEBUG_FILE support is only supported when using coccinelle >= 1.0.2.
--------------------
Coccinelle supports reading .cocciconfig for default Coccinelle options that
should be used every time spatch is spawned, the order of precedence for
should be used every time spatch is spawned. The order of precedence for
variables for .cocciconfig is as follows:
- Your current user's home directory is processed first
......@@ -237,7 +237,7 @@ variables for .cocciconfig is as follows:
- The directory provided with the --dir option is processed last, if used
Since coccicheck runs through make, it naturally runs from the kernel
proper dir, as such the second rule above would be implied for picking up a
proper dir; as such the second rule above would be implied for picking up a
.cocciconfig when using ``make coccicheck``.
``make coccicheck`` also supports using M= targets. If you do not supply
......@@ -260,13 +260,13 @@ If not using the kernel's coccicheck target, keep the above precedence
order logic of .cocciconfig reading. If using the kernel's coccicheck target,
override any of the kernel's .coccicheck's settings using SPFLAGS.
We help Coccinelle when used against Linux with a set of sensible defaults
We help Coccinelle when used against Linux with a set of sensible default
options for Linux with our own Linux .cocciconfig. This hints to coccinelle
git can be used for ``git grep`` queries over coccigrep. A timeout of 200
that git can be used for ``git grep`` queries over coccigrep. A timeout of 200
seconds should suffice for now.
The options picked up by coccinelle when reading a .cocciconfig do not appear
as arguments to spatch processes running on your system, to confirm what
as arguments to spatch processes running on your system. To confirm what
options will be used by Coccinelle run::
spatch --print-options-only
......@@ -290,7 +290,7 @@ given to it when options are in conflict. ::
Coccinelle supports idutils as well but requires coccinelle >= 1.0.6.
When no ID file is specified coccinelle assumes your ID database file
is in the file .id-utils.index on the top level of the kernel, coccinelle
is in the file .id-utils.index on the top level of the kernel. Coccinelle
carries a script scripts/idutils_index.sh which creates the database with::
mkid -i C --output .id-utils.index
......@@ -317,7 +317,7 @@ SmPL patch specific options
---------------------------
SmPL patches can have their own requirements for options passed
to Coccinelle. SmPL patch specific options can be provided by
to Coccinelle. SmPL patch-specific options can be provided by
providing them at the top of the SmPL patch, for instance::
// Options: --no-includes --include-headers
......@@ -327,7 +327,7 @@ SmPL patch Coccinelle requirements
As Coccinelle features get added some more advanced SmPL patches
may require newer versions of Coccinelle. If an SmPL patch requires
at least a version of Coccinelle, this can be specified as follows,
a minimum version of Coccinelle, this can be specified as follows,
as an example if requiring at least Coccinelle >= 1.0.5::
// Requires: 1.0.5
......
......@@ -22,7 +22,7 @@ Possible uses:
* minimizing kernel configurations (do I need this option if the
associated code is never run?)
.. _gcov: http://gcc.gnu.org/onlinedocs/gcc/Gcov.html
.. _gcov: https://gcc.gnu.org/onlinedocs/gcc/Gcov.html
.. _lcov: http://ltp.sourceforge.net/coverage/lcov.php
......@@ -171,7 +171,7 @@ Note on compilers
GCC and LLVM gcov tools are not necessarily compatible. Use gcov_ to work with
GCC-generated .gcno and .gcda files, and use llvm-cov_ for Clang.
.. _gcov: http://gcc.gnu.org/onlinedocs/gcc/Gcov.html
.. _gcov: https://gcc.gnu.org/onlinedocs/gcc/Gcov.html
.. _llvm-cov: https://llvm.org/docs/CommandGuide/llvm-cov.html
Build differences between GCC and Clang gcov are handled by Kconfig. It
......
......@@ -872,7 +872,7 @@ The kgdboc driver contains logic to configure communications with an
attached keyboard. The keyboard infrastructure is only compiled into the
kernel when ``CONFIG_KDB_KEYBOARD=y`` is set in the kernel configuration.
The core polled keyboard driver driver for PS/2 type keyboards is in
The core polled keyboard driver for PS/2 type keyboards is in
``drivers/char/kdb_keyboard.c``. This driver is hooked into the debug core
when kgdboc populates the callback in the array called
:c:type:`kdb_poll_funcs[]`. The :c:func:`kdb_get_kbd_char` is the top-level
......
......@@ -8,8 +8,6 @@ with the difference that the orphan objects are not freed but only
reported via /sys/kernel/debug/kmemleak. A similar method is used by the
Valgrind tool (``memcheck --leak-check``) to detect the memory leaks in
user-space applications.
Kmemleak is supported on x86, arm, arm64, powerpc, sparc, sh, microblaze, mips,
s390, nds32, arc and xtensa.
Usage
-----
......
......@@ -9,6 +9,8 @@ Sparse is a semantic checker for C programs; it can be used to find a
number of potential problems with kernel code. See
https://lwn.net/Articles/689907/ for an overview of sparse; this document
contains some kernel-specific sparse information.
More information on sparse, mainly about its internals, can be found in
its official pages at https://sparse.docs.kernel.org.
Using sparse for typechecking
......@@ -73,8 +75,8 @@ sparse would otherwise report a context imbalance.
Getting sparse
--------------
You can get latest released versions from the Sparse homepage at
https://sparse.wiki.kernel.org/index.php/Main_Page
You can get tarballs of the latest released versions from:
https://www.kernel.org/pub/software/devel/sparse/dist/
Alternatively, you can get snapshots of the latest development version
of sparse using git to clone::
......
......@@ -15,3 +15,4 @@ Open Firmware and Device Tree
overlay-notes
bindings/index
booting-without-of
......@@ -26,7 +26,7 @@ netlink based networking for inter-process communication in a significantly
easier way::
int cn_add_callback(struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *));
void cn_netlink_send_multi(struct cn_msg *msg, u16 len, u32 portid, u32 __group, int gfp_mask);
void cn_netlink_send_mult(struct cn_msg *msg, u16 len, u32 portid, u32 __group, int gfp_mask);
void cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __group, int gfp_mask);
struct cb_id
......@@ -48,7 +48,8 @@ be dereferenced to `struct cn_msg *`::
__u32 seq;
__u32 ack;
__u32 len; /* Length of the following data */
__u16 len; /* Length of the following data */
__u16 flags;
__u8 data[0];
};
......
......@@ -36,14 +36,14 @@ are starting with one. Physical addresses are of type unsigned long.
This address should not be used directly. Instead, to get an address
suitable for passing to the accessor functions described below, you
should call :c:func:`ioremap()`. An address suitable for accessing
should call ioremap(). An address suitable for accessing
the device will be returned to you.
After you've finished using the device (say, in your module's exit
routine), call :c:func:`iounmap()` in order to return the address
routine), call iounmap() in order to return the address
space to the kernel. Most architectures allocate new address space each
time you call :c:func:`ioremap()`, and they can run out unless you
call :c:func:`iounmap()`.
time you call ioremap(), and they can run out unless you
call iounmap().
Accessing the device
--------------------
......@@ -60,8 +60,8 @@ readb_relaxed(), readw_relaxed(), readl_relaxed(), readq_relaxed(),
writeb(), writew(), writel() and writeq().
Some devices (such as framebuffers) would like to use larger transfers than
8 bytes at a time. For these devices, the :c:func:`memcpy_toio()`,
:c:func:`memcpy_fromio()` and :c:func:`memset_io()` functions are
8 bytes at a time. For these devices, the memcpy_toio(),
memcpy_fromio() and memset_io() functions are
provided. Do not use memset or memcpy on IO addresses; they are not
guaranteed to copy data in order.
......@@ -135,15 +135,15 @@ Accessing Port Space
Accesses to this space are provided through a set of functions which
allow 8-bit, 16-bit and 32-bit accesses; also known as byte, word and
long. These functions are :c:func:`inb()`, :c:func:`inw()`,
:c:func:`inl()`, :c:func:`outb()`, :c:func:`outw()` and
:c:func:`outl()`.
long. These functions are inb(), inw(),
inl(), outb(), outw() and
outl().
Some variants are provided for these functions. Some devices require
that accesses to their ports are slowed down. This functionality is
provided by appending a ``_p`` to the end of the function.
There are also equivalents to memcpy. The :c:func:`ins()` and
:c:func:`outs()` functions copy bytes, words or longs to the given
There are also equivalents to memcpy. The ins() and
outs() functions copy bytes, words or longs to the given
port.
Public Functions Provided
......
......@@ -5,7 +5,7 @@ DMA Engine API Guide
Vinod Koul <vinod dot koul at intel.com>
.. note:: For DMA Engine usage in async_tx please see:
``Documentation/crypto/async-tx-api.txt``
``Documentation/crypto/async-tx-api.rst``
Below is a guide to device driver writers on how to use the Slave-DMA API of the
......
......@@ -95,7 +95,7 @@ accommodates that API in some cases, and made some design choices to
ensure that it stayed compatible.
For more information on the Async TX API, please look the relevant
documentation file in Documentation/crypto/async-tx-api.txt.
documentation file in Documentation/crypto/async-tx-api.rst.
DMAEngine APIs
==============
......
......@@ -228,8 +228,6 @@ over management of devices from the bootloader, the usage of sync_state() is
not restricted to that. Use it whenever it makes sense to take an action after
all the consumers of a device have probed::
::
int (*remove) (struct device *dev);
remove is called to unbind a driver from a device. This may be
......
......@@ -92,7 +92,7 @@ You can obtain somewhat infrequent snapshots of klibc from
https://www.kernel.org/pub/linux/libs/klibc/
For active users, you are better off using the klibc git
repository, at http://git.kernel.org/?p=libs/klibc/klibc.git
repository, at https://git.kernel.org/?p=libs/klibc/klibc.git
The standalone klibc distribution currently provides three components,
in addition to the klibc library:
......@@ -122,7 +122,7 @@ and a number of other utilities, so you can replace kinit and build
custom initramfs images that meet your needs exactly.
For questions and help, you can sign up for the early userspace
mailing list at http://www.zytor.com/mailman/listinfo/klibc
mailing list at https://www.zytor.com/mailman/listinfo/klibc
How does it work?
=================
......
......@@ -14,7 +14,7 @@ collisions are prevented, ...) please have a look at the I3C specification.
This document is just a brief introduction to the I3C protocol and the concepts
it brings to the table. If you need more information, please refer to the MIPI
I3C specification (can be downloaded here
http://resources.mipi.org/mipi-i3c-v1-download).
https://resources.mipi.org/mipi-i3c-v1-download).
Introduction
============
......
......@@ -48,6 +48,7 @@ available subsections can be seen below.
scsi
libata
target
mailbox
mtdnand
miscellaneous
mei/index
......
......@@ -18,7 +18,7 @@ management software that can use the IPMI system.
This document describes how to use the IPMI driver for Linux. If you
are not familiar with IPMI itself, see the web site at
http://www.intel.com/design/servers/ipmi/index.htm. IPMI is a big
https://www.intel.com/design/servers/ipmi/index.htm. IPMI is a big
subject and I can't cover it all here!
Configuration
......
......@@ -14,7 +14,7 @@ memory devices like
* Pseudo-SRAM devices
GPMC is found on Texas Instruments SoC's (OMAP based)
IP details: http://www.ti.com/lit/pdf/spruh73 section 7.1
IP details: https://www.ti.com/lit/pdf/spruh73 section 7.1
GPMC generic timing calculation:
......
......@@ -5,7 +5,7 @@ MMC tools introduction
There is one MMC test tools called mmc-utils, which is maintained by Chris Ball,
you can find it at the below public git repository:
http://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/
https://git.kernel.org/cgit/linux/kernel/git/cjb/mmc-utils.git/
Functions
=========
......
......@@ -9,7 +9,7 @@ registers and memory translation windows, as well as non common features like
scratchpad and message registers. Scratchpad registers are read-and-writable
registers that are accessible from either side of the device, so that peers can
exchange a small amount of information at a fixed address. Message registers can
be utilized for the same purpose. Additionally they are provided with with
be utilized for the same purpose. Additionally they are provided with
special status bits to make sure the information isn't rewritten by another
peer. Doorbell registers provide a way for peers to send interrupt events.
Memory windows allow translated read and write access to the peer memory.
......
......@@ -73,7 +73,7 @@ DAX:
process address space.
DSM:
Device Specific Method: ACPI method to to control specific
Device Specific Method: ACPI method to control specific
device - in this case the firmware.
DCR:
......@@ -113,13 +113,13 @@ Supporting Documents
--------------------
ACPI 6:
http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
https://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf
NVDIMM Namespace:
http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf
https://pmem.io/documents/NVDIMM_Namespace_Spec.pdf
DSM Interface Example:
http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
https://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
Driver Writer's Guide:
http://pmem.io/documents/NVDIMM_Driver_Writers_Guide.pdf
https://pmem.io/documents/NVDIMM_Driver_Writers_Guide.pdf
Git Trees
---------
......@@ -778,7 +778,7 @@ Why the Term "namespace"?
2. The term originated to describe the sub-devices that can be created
within a NVME controller (see the nvme specification:
http://www.nvmexpress.org/specifications/), and NFIT namespaces are
https://www.nvmexpress.org/specifications/), and NFIT namespaces are
meant to parallel the capabilities and configurability of
NVME-namespaces.
......@@ -786,7 +786,7 @@ Why the Term "namespace"?
LIBNVDIMM/LIBNDCTL: Block Translation Table "btt"
-------------------------------------------------
A BTT (design document: http://pmem.io/2014/09/23/btt.html) is a stacked
A BTT (design document: https://pmem.io/2014/09/23/btt.html) is a stacked
block device driver that fronts either the whole block device or a
partition of a block device emitted by either a PMEM or BLK NAMESPACE.
......
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment