From 296ab4986347fdd64d510a224ecc1ac4935b2ea0 Mon Sep 17 00:00:00 2001 From: Justas Brazauskas Date: Mon, 14 Dec 2015 17:39:54 +0200 Subject: [PATCH] Fix few typos in ./Documentation folder --- Documentation/DMA-API.txt | 8 +- Documentation/DMA-ISA-LPC.txt | 2 +- Documentation/IRQ-domain.txt | 4 +- Documentation/SM501.txt | 6 +- Documentation/adding-syscalls.txt | 2 +- Documentation/assoc_array.txt | 6 +- Documentation/atomic_ops.txt | 2 +- Documentation/bcache.txt | 2 +- Documentation/binfmt_misc.txt | 10 +- Documentation/circular-buffers.txt | 2 +- Documentation/clk.txt | 2 +- Documentation/cpu-hotplug.txt | 2 +- Documentation/cpu-load.txt | 2 +- Documentation/devices.txt | 4 +- Documentation/dma-buf-sharing.txt | 2 +- Documentation/dynamic-debug-howto.txt | 8 +- Documentation/edac.txt | 2 +- Documentation/email-clients.txt | 2 +- Documentation/hsi.txt | 4 +- Documentation/kasan.txt | 2 +- Documentation/kernel-parameters.txt | 22 +- Documentation/kmemcheck.txt | 2 +- Documentation/kmemleak.txt | 2 +- Documentation/ldm.txt | 2 +- Documentation/lzo.txt | 6 +- Documentation/mailbox.txt | 2 +- Documentation/md.txt | 30 +- Documentation/media-framework.txt | 2 +- Documentation/memory-barriers.txt | 12 +- Documentation/module-signing.txt | 2 +- Documentation/nommu-mmap.txt | 24 +- Documentation/oops-tracing.txt | 80 ++--- Documentation/parport-lowlevel.txt | 4 +- Documentation/parport.txt | 2 +- Documentation/pinctrl.txt | 2 +- Documentation/printk-formats.txt | 4 +- Documentation/ramoops.txt | 2 +- Documentation/robust-futexes.txt | 4 +- Documentation/static-keys.txt | 2 +- Documentation/svga.txt | 2 +- Documentation/sysrq.txt | 6 +- Documentation/unaligned-memory-access.txt | 5 +- Documentation/xillybus.txt | 2 +- net/netfilter/xt_TCPMSS.c | 380 ++++------------------ net/netfilter/xt_tcpmss.c | 110 ------- 45 files changed, 217 insertions(+), 568 deletions(-) delete mode 100644 net/netfilter/xt_tcpmss.c diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 1e98a7e6bccc44..cd54664634147c 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -234,14 +234,14 @@ don't take special care to determine the cache line size at run time only map virtual regions that begin and end on page boundaries (which are guaranteed also to be cache line boundaries). -DMA_TO_DEVICE synchronisation must be done after the last modification +DMA_TO_DEVICE synchronization must be done after the last modification of the memory region by the software and before it is handed off to the driver. Once this primitive is used, memory covered by this primitive should be treated as read-only by the device. If the device may write to it at any point, it should be DMA_BIDIRECTIONAL (see below). -DMA_FROM_DEVICE synchronisation must be done before the driver +DMA_FROM_DEVICE synchronization must be done before the driver accesses data that may be changed by the device. This memory should be treated as read-only by the driver. If the driver needs to write to it at any point, it should be DMA_BIDIRECTIONAL (see below). @@ -349,7 +349,7 @@ void dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nents, enum dma_data_direction direction) -Synchronise a single contiguous or scatter/gather mapping for the CPU +Synchronize a single contiguous or scatter/gather mapping for the CPU and device. With the sync_sg API, all the parameters must be the same as those passed into the single mapping API. With the sync_single API, you can use dma_handle and size parameters that aren't identical to @@ -521,7 +521,7 @@ DMA_MEMORY_INCLUDES_CHILDREN - make the declared memory be allocated by dma_alloc_coherent of any child devices of this one (for memory residing on a bridge). -DMA_MEMORY_EXCLUSIVE - only allocate memory from the declared regions. +DMA_MEMORY_EXCLUSIVE - only allocate memory from the declared regions. Do not allow dma_alloc_coherent() to fall back to system memory when it's out of memory in the declared region. diff --git a/Documentation/DMA-ISA-LPC.txt b/Documentation/DMA-ISA-LPC.txt index b1a19835e9070d..c413313987521f 100644 --- a/Documentation/DMA-ISA-LPC.txt +++ b/Documentation/DMA-ISA-LPC.txt @@ -42,7 +42,7 @@ requirements you pass the flag GFP_DMA to kmalloc. Unfortunately the memory available for ISA DMA is scarce so unless you allocate the memory during boot-up it's a good idea to also pass -__GFP_REPEAT and __GFP_NOWARN to make the allocater try a bit harder. +__GFP_REPEAT and __GFP_NOWARN to make the allocator try a bit harder. (This scarcity also means that you should allocate the buffer as early as possible and not release it until the driver is unloaded.) diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt index 8d990bde8693fd..e947bdce228c47 100644 --- a/Documentation/IRQ-domain.txt +++ b/Documentation/IRQ-domain.txt @@ -10,13 +10,13 @@ IRQ numbers. The number of interrupt controllers registered as unique irqchips show a rising tendency: for example subdrivers of different kinds such as GPIO controllers avoid reimplementing identical callback -mechanisms as the IRQ core system by modelling their interrupt +mechanisms as the IRQ core system by modeling their interrupt handlers as irqchips, i.e. in effect cascading interrupt controllers. Here the interrupt number loose all kind of correspondence to hardware interrupt numbers: whereas in the past, IRQ numbers could be chosen so they matched the hardware IRQ line into the root -interrupt controller (i.e. the component actually fireing the +interrupt controller (i.e. the component actually firing the interrupt line to the CPU) nowadays this number is just a number. For this reason we need a mechanism to separate controller-local diff --git a/Documentation/SM501.txt b/Documentation/SM501.txt index 561826f8209357..3ed9460c136c88 100644 --- a/Documentation/SM501.txt +++ b/Documentation/SM501.txt @@ -19,7 +19,7 @@ management. The core registers drivers for both PCI and generic bus based chips via the platform device and driver system. -On detection of a device, the core initialises the chip (which may +On detection of a device, the core initializes the chip (which may be specified by the platform data) and then exports the selected peripheral set as platform devices for the specific drivers. @@ -35,7 +35,7 @@ Each peripheral has a view of the device which is implicitly narrowed to the specific set of resources that peripheral requires in order to function correctly. -The centralised memory allocation allows the driver to ensure that the +The centralized memory allocation allows the driver to ensure that the maximum possible resource allocation can be made to the video subsystem as this is by-far the most resource-sensitive of the on-chip functions. @@ -45,7 +45,7 @@ occurs the memory footprint of the video subsystem changes. Since video memory is difficult to move without changing the display (unless sufficient contiguous memory can be provided for the old and new -modes simultaneously) the video driver fully utilises the memory area +modes simultaneously) the video driver fully utilizes the memory area given to it by aligning fb0 to the start of the area and fb1 to the end of it. Any memory left over in the middle is used for the acceleration functions, which are transient and thus their location is less critical diff --git a/Documentation/adding-syscalls.txt b/Documentation/adding-syscalls.txt index cc2d4ac4f4042b..cb4729725512f1 100644 --- a/Documentation/adding-syscalls.txt +++ b/Documentation/adding-syscalls.txt @@ -82,7 +82,7 @@ by including a size argument in the structure: }; As long as any subsequently added field, say param_4, is designed so that a -zero value gives the previous behaviour, then this allows both directions of +zero value gives the previous behavior, then this allows both directions of version mismatch: - To cope with a later userspace program calling an older kernel, the kernel diff --git a/Documentation/assoc_array.txt b/Documentation/assoc_array.txt index 2f2c6cdd73c0c2..8715535cae488a 100644 --- a/Documentation/assoc_array.txt +++ b/Documentation/assoc_array.txt @@ -184,11 +184,11 @@ MANIPULATION FUNCTIONS There are a number of functions for manipulating an associative array: - (1) Initialise an associative array. + (1) Initialize an associative array. void assoc_array_init(struct assoc_array *array); - This initialises the base structure for an associative array. It can't + This initializes the base structure for an associative array. It can't fail. @@ -350,7 +350,7 @@ This will cause leaves with different length keys to scatter away from each other - and those with the same length keys to cluster together. It is also recommended that the index key begin with a hash of the rest of the -key to maximise scattering throughout keyspace. +key to maximize scattering throughout keyspace. The better the scattering, the wider and lower the internal tree will be. diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt index c9d1cacb439590..10f94491d0f3e8 100644 --- a/Documentation/atomic_ops.txt +++ b/Documentation/atomic_ops.txt @@ -373,7 +373,7 @@ void obj_timeout(struct obj *obj) } (This is a simplification of the ARP queue management in the - generic neighbour discover code of the networking. Olaf Kirch + generic neighbor discover code of the networking. Olaf Kirch found a bug wrt. memory barriers in kfree_skb() that exposed the atomic_t memory barrier requirements quite clearly.) diff --git a/Documentation/bcache.txt b/Documentation/bcache.txt index 32b6c3189d9826..03033790072900 100644 --- a/Documentation/bcache.txt +++ b/Documentation/bcache.txt @@ -8,7 +8,7 @@ Wiki and git repositories are at: It's designed around the performance characteristics of SSDs - it only allocates in erase block sized buckets, and it uses a hybrid btree/log to track cached -extants (which can be anywhere from a single sector to the bucket size). It's +extents (which can be anywhere from a single sector to the bucket size). It's designed to avoid random writes at all costs; it fills up an erase block sequentially, then issues a discard before reusing it. diff --git a/Documentation/binfmt_misc.txt b/Documentation/binfmt_misc.txt index 6b1de70583715d..7efe38c9376063 100644 --- a/Documentation/binfmt_misc.txt +++ b/Documentation/binfmt_misc.txt @@ -1,4 +1,4 @@ - Kernel Support for miscellaneous (your favourite) Binary Formats v1.1 + Kernel Support for miscellaneous (your favorite) Binary Formats v1.1 ===================================================================== This Kernel feature allows you to invoke almost (for restrictions see below) @@ -6,9 +6,9 @@ every program by simply typing its name in the shell. This includes for example compiled Java(TM), Python or Emacs programs. To achieve this you must tell binfmt_misc which interpreter has to be invoked -with which binary. Binfmt_misc recognises the binary-type by matching some bytes +with which binary. Binfmt_misc recognizes the binary-type by matching some bytes at the beginning of the file with a magic byte sequence (masking out specified -bits) you have supplied. Binfmt_misc can also recognise a filename extension +bits) you have supplied. Binfmt_misc can also recognize a filename extension aka '.com' or '.exe'. First you must mount binfmt_misc: @@ -31,7 +31,7 @@ Here is what the fields mean: escape any NUL bytes; parsing halts at the first one. In a shell environment you might have to write \\x0a to prevent the shell from eating your \. If you chose filename extension matching, this is the extension to be - recognised (without the '.', the \x0a specials are not allowed). Extension + recognized (without the '.', the \x0a specials are not allowed). Extension matching is case sensitive, and slashes '/' are not allowed! - 'mask' is an (optional, defaults to all 0xff) mask. You can mask out some bits from matching by supplying a string like magic and as long as magic. @@ -118,7 +118,7 @@ example. Your interpreter should NOT look in the PATH for the filename; the kernel passes it the full filename (or the file descriptor) to use. Using $PATH can -cause unexpected behaviour and can be a security hazard. +cause unexpected behavior and can be a security hazard. Richard Günther diff --git a/Documentation/circular-buffers.txt b/Documentation/circular-buffers.txt index 88951b179262a9..dd21d899a828da 100644 --- a/Documentation/circular-buffers.txt +++ b/Documentation/circular-buffers.txt @@ -17,7 +17,7 @@ buffering. There are two sets of such features: To use these facilities, as discussed below, there needs to be just one producer and just one consumer. It is possible to handle multiple producers by -serialising them, and to handle multiple consumers by serialising them. +serializing them, and to handle multiple consumers by serializing them. Contents: diff --git a/Documentation/clk.txt b/Documentation/clk.txt index 5c4bc4d01d0c32..20d0b2a1baadab 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -1,7 +1,7 @@ The Common Clk Framework Mike Turquette -This document endeavours to explain the common clk framework details, +This document endeavors to explain the common clk framework details, and how to port a platform over to this framework. It is not yet a detailed explanation of the clock api in include/linux/clk.h, but perhaps someday it will include that information. diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt index f9ad5e048b1112..bcae03dfff03d2 100644 --- a/Documentation/cpu-hotplug.txt +++ b/Documentation/cpu-hotplug.txt @@ -97,7 +97,7 @@ from the map depending on the event is hot-add/hot-remove. There are currently no locking rules as of now. Typical usage is to init topology during boot, at which time hotplug is disabled. -You really dont need to manipulate any of the system cpu maps. They should +You really don't need to manipulate any of the system cpu maps. They should be read-only for most use. When setting up per-cpu resources almost always use cpu_possible_mask/for_each_possible_cpu() to iterate. diff --git a/Documentation/cpu-load.txt b/Documentation/cpu-load.txt index 287224e57cfc5d..ed6faecbaef7da 100644 --- a/Documentation/cpu-load.txt +++ b/Documentation/cpu-load.txt @@ -22,7 +22,7 @@ closely, however due to the nature of how/when the kernel collects this data sometimes it can not be trusted at all. So how is this information collected? Whenever timer interrupt is -signalled the kernel looks what kind of task was running at this +signaled the kernel looks what kind of task was running at this moment and increments the counter that corresponds to this tasks kind/state. The problem with this is that the system could have switched between various states multiple times between two timer diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 87b4c5e82d3902..e036e4f73b04b2 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -400,7 +400,7 @@ Your cooperation is appreciated. 182 = /dev/perfctr Performance-monitoring counters 183 = /dev/hwrng Generic random number generator 184 = /dev/cpu/microcode CPU microcode update interface - 186 = /dev/atomicps Atomic shapshot of process state data + 186 = /dev/atomicps Atomic snapshot of process state data 187 = /dev/irnet IrNET device 188 = /dev/smbusbios SMBus BIOS 189 = /dev/ussp_ctl User space serial port control @@ -2947,7 +2947,7 @@ Your cooperation is appreciated. 2 = /dev/dvb/adapter0/sec0 (obsolete/unused) 3 = /dev/dvb/adapter0/frontend0 first frontend device of first card 4 = /dev/dvb/adapter0/demux0 first demux device of first card - 5 = /dev/dvb/adapter0/dvr0 first digital video recoder device of first card + 5 = /dev/dvb/adapter0/dvr0 first digital video recorder device of first card 6 = /dev/dvb/adapter0/ca0 first common access port of first card 7 = /dev/dvb/adapter0/net0 first network device of first card 8 = /dev/dvb/adapter0/osd0 first on-screen-display device of first card diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 480c8de3c2c447..05a7bfd3b148e2 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -213,7 +213,7 @@ NOTES: In case it is allowed by the exporter: if the new buffer-user has stricter 'backing-storage constraints', and the exporter can handle these constraints, the exporter can just stall on the - map_dma_buf until all outstanding access is completed (as signalled by + map_dma_buf until all outstanding access is completed (as signaled by unmap_dma_buf). Once all users have finished accessing and have unmapped this buffer, the exporter could potentially move the buffer to the stricter backing-storage, diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt index 9417871b8758f2..f8b151d183a992 100644 --- a/Documentation/dynamic-debug-howto.txt +++ b/Documentation/dynamic-debug-howto.txt @@ -32,10 +32,10 @@ Dynamic debug has even more useful features: which can be read to display the complete list of known debug statements, to help guide you -Controlling dynamic debug Behaviour +Controlling dynamic debug Behavior =================================== -The behaviour of pr_debug()/dev_dbg()s are controlled via writing to a +The behavior of pr_debug()/dev_dbg()s are controlled via writing to a control file in the 'debugfs' filesystem. Thus, you must first mount the debugfs filesystem, in order to make use of this feature. Subsequently, we refer to the control file as: @@ -51,10 +51,10 @@ nullarbor:~ # echo 'file svcsock.c wtf 1 +p' > /dynamic_debug/control -bash: echo: write error: Invalid argument -Viewing Dynamic Debug Behaviour +Viewing Dynamic Debug Behavior =========================== -You can view the currently configured behaviour of all the debug +You can view the currently configured behavior of all the debug statements via: nullarbor:~ # cat /dynamic_debug/control diff --git a/Documentation/edac.txt b/Documentation/edac.txt index 80841a2d640cf5..c89d8bae54d7a6 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt @@ -658,7 +658,7 @@ exports one echo 2 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm echo 1 >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank - To return to the default behaviour of matching any, you can do: + To return to the default behavior of matching any, you can do: echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/dimm echo any >/sys/devices/system/edac/mc/mc0/inject_addrmatch/rank diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt index 2d485dea8cece7..37ea6fb22d23ef 100644 --- a/Documentation/email-clients.txt +++ b/Documentation/email-clients.txt @@ -123,7 +123,7 @@ At the bottom of your email, put the commonly-used patch delimiter before inserting your patch: three hyphens (---). Then from the "Message" menu item, select insert file and choose your patch. -As an added bonus you can customise the message creation toolbar menu +As an added bonus you can customize the message creation toolbar menu and put the "insert file" icon there. Make the composer window wide enough so that no lines wrap. As of diff --git a/Documentation/hsi.txt b/Documentation/hsi.txt index 6ac6cd51852af5..e5e5283c34fd6a 100644 --- a/Documentation/hsi.txt +++ b/Documentation/hsi.txt @@ -3,7 +3,7 @@ HSI - High-speed Synchronous Serial Interface 1. Introduction ~~~~~~~~~~~~~~~ -High Speed Syncronous Interface (HSI) is a fullduplex, low latency protocol, +High Speed Synchronous Interface (HSI) is a fullduplex, low latency protocol, that is optimized for die-level interconnect between an Application Processor and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and implemented by multiple vendors since then. @@ -49,7 +49,7 @@ use an arbitrary number of channels. ~~~~~~~~~~~~~~~~~~ Each port automatically registers a generic client driver called hsi_char, -which provides a charecter device for userspace representing the HSI port. +which provides a character device for userspace representing the HSI port. It can be used to communicate via HSI from userspace. Userspace may configure the hsi_char device using the following ioctl commands: diff --git a/Documentation/kasan.txt b/Documentation/kasan.txt index aa1e0c91e36888..6956fd9284e574 100644 --- a/Documentation/kasan.txt +++ b/Documentation/kasan.txt @@ -117,7 +117,7 @@ Memory state around the buggy address: ffff8800693bc800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ================================================================== -The header of the report discribe what kind of bug happened and what kind of +The header of the report describes what kind of bug happened and what kind of access caused it. It's followed by the description of the accessed slub object (see 'SLUB Debug output' section in Documentation/vm/slub.txt for details) and the description of the accessed memory page. diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 742f69d18fc898..eb111a1bd17b45 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -38,7 +38,7 @@ This document may not be entirely up to date and comprehensive. The command module. Loadable modules, after being loaded into the running kernel, also reveal their parameters in /sys/module/${modulename}/parameters/. Some of these parameters may be changed at runtime by the command -"echo -n ${value} > /sys/module/${modulename}/parameters/${parm}". +"echo -n ${value} > /sys/module/${modulename}/parameters/${param}". The parameters listed below are only valid if certain kernel build options were enabled and if respective hardware is present. The text in square brackets at @@ -405,7 +405,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. alignment= [KNL,ARM] Allow the default userspace alignment fault handler - behaviour to be specified. Bit 0 enables warnings, + behavior to be specified. Bit 0 enables warnings, bit 1 enables fixups, and bit 2 sends a segfault. align_va_addr= [X86-64] @@ -470,7 +470,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Change the output verbosity whilst booting Format: { quiet (default) | verbose | debug } Change the amount of debugging information output - when initialising the APIC and IO-APIC components. + when initializing the APIC and IO-APIC components. autoconf= [IPV6] See Documentation/networking/ipv6.txt. @@ -1370,7 +1370,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. controller i8042.nopnp [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX controllers - i8042.notimeout [HW] Ignore timeout condition signalled by controller + i8042.notimeout [HW] Ignore timeout condition singled by controller i8042.reset [HW] Reset the controller during init and cleanup i8042.unlock [HW] Unlock (ignore) the keylock i8042.kbdreset [HW] Reset device connected to KBD port @@ -1464,7 +1464,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. ima_policy= [IMA] The builtin measurement policy to load during IMA - setup. Specyfing "tcb" as the value, measures all + setup. Specifying "tcb" as the value, measures all programs exec'd, files mmap'd for exec, and all files opened with the read mode bit set by either the effective uid (euid=0) or uid=0. @@ -2146,7 +2146,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. mminit_loglevel= [KNL] When CONFIG_DEBUG_MEMORY_INIT is set, this parameter allows control of the logging verbosity for - the additional memory initialisation checks. A value + the additional memory initialization checks. A value of 0 disables mminit logging and a level of 4 will log everything. Information is printed at KERN_DEBUG so loglevel=8 may also need to be specified. @@ -2296,7 +2296,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Servers that do not support this mode of operation will be autodetected by the client, and it will fall back to using the idmapper. - To turn off this behaviour, set the value to '0'. + To turn off this behavior, set the value to '0'. nfs.nfs4_unique_id= [NFS4] Specify an additional fixed unique ident- ification string that NFSv4 clients can insert into @@ -2317,7 +2317,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. doing this risks data corruption, since there are no guarantees that the file will remain unchanged after the locks are lost. - If you want to enable the kernel legacy behaviour of + If you want to enable the kernel legacy behavior of attempting to recover these locks, then set this parameter to '1'. The default parameter value of '0' causes the kernel @@ -2517,7 +2517,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. no-steal-acc [X86,KVM] Disable paravirtualized steal time accounting. steal time is computed, but won't influence scheduler - behaviour + behavior nolapic [X86-32,APIC] Do not enable or use the local APIC. @@ -2665,7 +2665,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. we can turn it on. on: enable the feature - panic= [KNL] Kernel behaviour on panic: delay + panic= [KNL] Kernel behavior on panic: delay timeout > 0: seconds before rebooting timeout = 0: wait forever timeout < 0: reboot immediately @@ -3841,7 +3841,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. See also Documentation/input/joystick-parport.txt udbg-immortal [PPC] When debugging early kernel crashes that - happen after console_init() and before a proper + happen after console_init() and before a proper console driver takes over, this boot options might help "seeing" what's going on. diff --git a/Documentation/kmemcheck.txt b/Documentation/kmemcheck.txt index 80aae85d8da6c1..29f04fcac7df05 100644 --- a/Documentation/kmemcheck.txt +++ b/Documentation/kmemcheck.txt @@ -366,7 +366,7 @@ addresses). This becomes obvious when we look at the code for line 446: 438 * attacks in the high resolution timer case. This is 439 * compliant with the old way of self restarting 440 * itimers, as the SIGALRM is a legacy signal and only -441 * queued once. Changing the restart behaviour to +441 * queued once. Changing the restart behavior to 442 * restart the timer in the signal dequeue path is 443 * reducing the timer noise on heavy loaded !highres 444 * systems too. diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt index 18e24abb3ecf61..bb79991b8c6e9d 100644 --- a/Documentation/kmemleak.txt +++ b/Documentation/kmemleak.txt @@ -58,7 +58,7 @@ Memory scanning parameters can be modified at run-time by writing to the Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on the kernel command line. -Memory may be allocated or freed before kmemleak is initialised and +Memory may be allocated or freed before kmemleak is initialized and these actions are stored in an early log buffer. The size of this buffer is configured via the CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE option. diff --git a/Documentation/ldm.txt b/Documentation/ldm.txt index 4f80edd14d0a68..2b1d2a79329100 100644 --- a/Documentation/ldm.txt +++ b/Documentation/ldm.txt @@ -10,7 +10,7 @@ Overview Windows 2000, XP, and Vista use a new partitioning scheme. It is a complete replacement for the MSDOS style partitions. It stores its information in a -1MiB journalled database at the end of the physical disk. The size of +1MiB journaled database at the end of the physical disk. The size of partitions is limited only by disk space. The maximum number of partitions is nearly 2000. diff --git a/Documentation/lzo.txt b/Documentation/lzo.txt index ea45dd3901e3bf..f9d6931dae5836 100644 --- a/Documentation/lzo.txt +++ b/Documentation/lzo.txt @@ -56,7 +56,7 @@ Description After any instruction except the large literal copy, 0, 1, 2 or 3 literals are copied before starting the next instruction. The number of literals that - were copied may change the meaning and behaviour of the next instruction. In + were copied may change the meaning and behavior of the next instruction. In practice, only one instruction needs to know whether 0, less than 4, or more literals were copied. This is the information stored in the variable in this implementation. This number of immediate literals to be copied is @@ -69,9 +69,9 @@ Description IMPORTANT NOTE : in the code some length checks are missing because certain instructions are called under the assumption that a certain number of bytes - follow because it has already been garanteed before parsing the instructions. + follow because it has already been guaranteed before parsing the instructions. They just have to "refill" this credit if they consume extra bytes. This is - an implementation design choice independant on the algorithm or encoding. + an implementation design choice independent on the algorithm or encoding. Byte sequences diff --git a/Documentation/mailbox.txt b/Documentation/mailbox.txt index 7ed371c852046b..f48205d649ca84 100644 --- a/Documentation/mailbox.txt +++ b/Documentation/mailbox.txt @@ -46,7 +46,7 @@ struct demo_client { }; /* - * This is the handler for data received from remote. The behaviour is purely + * This is the handler for data received from remote. The behavior is purely * dependent upon the protocol. This is just an example. */ static void message_from_remote(struct mbox_client *cl, void *mssg) diff --git a/Documentation/md.txt b/Documentation/md.txt index 1a2ada46aaedae..45cad93a4f877f 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -1,5 +1,5 @@ Tools that manage md devices can be found at - http://www.kernel.org/pub/linux/utils/raid/ + http://www.kernel.org/pub/linux/utils/raid/ Boot time assembly of RAID arrays @@ -15,9 +15,9 @@ for raid arrays with persistent superblocks md=,dev0,dev1,...,devn or, to assemble a partitionable array: md=d,dev0,dev1,...,devn - -md device no. = the number of the md device ... - 0 means md0, + +md device no. = the number of the md device ... + 0 means md0, 1 md1, 2 md2, 3 md3, @@ -29,11 +29,11 @@ raid level = -1 linear mode chunk size factor = (raid-0 and raid-1 only) Set the chunk size as 4k << n. - + fault level = totally ignored - + dev0-devn: e.g. /dev/hda1,/dev/hdc1,/dev/sda1,/dev/sdb1 - + A possible loadlin line (Harald Hoyer ) looks like this: e:\loadlin\loadlin e:\zimage root=/dev/md0 md=0,0,4,0,/dev/hdb2,/dev/hdc3 ro @@ -178,13 +178,13 @@ All md devices contain: This is the size in bytes for 'chunks' and is only relevant to raid levels that involve striping (0,4,5,6,10). The address space of the array is conceptually divided into chunks and consecutive - chunks are striped onto neighbouring devices. + chunks are striped onto neighboring devices. The size should be at least PAGE_SIZE (4k) and should be a power of 2. This can only be set while assembling an array layout The "layout" for the array for the particular level. This is - simply a number that is interpretted differently by different + simply a number that is interpreted differently by different levels. It can be written while assembling an array. array_size @@ -273,7 +273,7 @@ All md devices contain: When written, doesn't tear down array, but just stops it suspended (not supported yet) All IO requests will block. The array can be reconfigured. - Writing this, if accepted, will block until array is quiessent + Writing this, if accepted, will block until array is quiescent readonly no resync can happen. no superblocks get written. write requests fail @@ -338,9 +338,9 @@ All md devices contain: When metadata is managed externally, it should be set to true once the array becomes non-degraded, and this fact has been recorded in the metadata. - - - + + + As component devices are added to an md array, they appear in the 'md' directory as new directories named @@ -451,7 +451,7 @@ Each directory contains: Setting this to 'none' is equivalent to setting 'in_sync'. Setting to any other value also clears the 'in_sync' flag. - + bad_blocks This gives the list of all known bad blocks in the form of start address and length (in sectors respectively). If output @@ -500,7 +500,7 @@ also have repair - A full check and repair is happening. This is similar to 'resync', but was requested by the user, and the write-intent bitmap is NOT used to - optimise the process. + optimize the process. This file is writable, and each of the strings that could be read are meaningful for writing. diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index f552a75c0e70b2..3702eff30db3dd 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -18,7 +18,7 @@ Abstract media device model Discovering a device internal topology, and configuring it at runtime, is one of the goals of the media framework. To achieve this, hardware devices are -modelled as an oriented graph of building blocks called entities connected +modeled as an oriented graph of building blocks called entities connected through pads. An entity is a basic media hardware building block. It can correspond to diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index aef9487303d023..4f9e37db7ec8eb 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -536,7 +536,7 @@ leading to the following situation: (Q == &B) and (D == 2) ???? Whilst this may seem like a failure of coherency or causality maintenance, it -isn't, and this behaviour can be observed on certain real CPUs (such as the DEC +isn't, and this behavior can be observed on certain real CPUs (such as the DEC Alpha). To deal with this, a data dependency barrier or better must be inserted @@ -2218,7 +2218,7 @@ INTERPROCESSOR INTERACTION When there's a system with more than one processor, more than one CPU in the system may be working on the same data set at the same time. This can cause -synchronisation problems, and the usual way of dealing with them is to use +synchronization problems, and the usual way of dealing with them is to use locks. Locks, however, are quite expensive, and so it may be preferable to operate without the use of a lock if at all possible. In such a case operations that affect both CPUs may have to be carefully ordered to prevent @@ -2396,7 +2396,7 @@ The following operations are special locking primitives: These implement ACQUIRE-class and RELEASE-class operations. These should be used in preference to other operations when implementing locking primitives, because -their implementations can be optimised on many architectures. +their implementations can be optimized on many architectures. [!] Note that special memory barrier primitives are available for these situations because on some CPUs the atomic instructions used imply full memory @@ -2506,7 +2506,7 @@ functions: spaces. Accesses to this space may be fully synchronous (as on i386), but - intermediary bridges (such as the PCI host bridge) may not fully honour + intermediary bridges (such as the PCI host bridge) may not fully honor that. They are guaranteed to be fully ordered with respect to each other. @@ -2940,7 +2940,7 @@ AND THEN THERE'S THE ALPHA The DEC Alpha CPU is one of the most relaxed CPUs there is. Not only that, some versions of the Alpha CPU have a split data cache, permitting them to have two semantically-related cache lines updated at separate times. This is where -the data dependency barrier really becomes necessary as this synchronises both +the data dependency barrier really becomes necessary as this synchronizes both caches with the memory coherence system, thus making it seem like pointer changes vs new data occur in the right order. @@ -2957,7 +2957,7 @@ CIRCULAR BUFFERS ---------------- Memory barriers can be used to implement circular buffering without the need -of a lock to serialise the producer with the consumer. See: +of a lock to serialize the producer with the consumer. See: Documentation/circular-buffers.txt diff --git a/Documentation/module-signing.txt b/Documentation/module-signing.txt index a78bf1ffa68cb4..341fb8db95fbd3 100644 --- a/Documentation/module-signing.txt +++ b/Documentation/module-signing.txt @@ -101,7 +101,7 @@ This has a number of options available: certificate and a private key. If the PEM file containing the private key is encrypted, or if the - PKCS#11 token requries a PIN, this can be provided at build time by + PKCS#11 token requires a PIN, this can be provided at build time by means of the KBUILD_SIGN_PIN variable. diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt index ae57b9ea0d4169..15e627cf55209f 100644 --- a/Documentation/nommu-mmap.txt +++ b/Documentation/nommu-mmap.txt @@ -9,11 +9,11 @@ call and the execve() system call. From the kernel's point of view, execve() mapping is actually performed by the binfmt drivers, which call back into the mmap() routines to do the actual work. -Memory mapping behaviour also involves the way fork(), vfork(), clone() and +Memory mapping behavior also involves the way fork(), vfork(), clone() and ptrace() work. Under uClinux there is no fork(), and clone() must be supplied the CLONE_VM flag. -The behaviour is similar between the MMU and no-MMU cases, but not identical; +The behavior is similar between the MMU and no-MMU cases, but not identical; and it's also much more restricted in the latter case: (*) Anonymous mapping, MAP_PRIVATE @@ -28,7 +28,7 @@ and it's also much more restricted in the latter case: These behave very much like private mappings, except that they're shared across fork() or clone() without CLONE_VM in the MMU case. Since - the no-MMU case doesn't support these, behaviour is identical to + the no-MMU case doesn't support these, behavior is identical to MAP_PRIVATE there. (*) File, MAP_PRIVATE, PROT_READ / PROT_EXEC, !PROT_WRITE @@ -79,7 +79,7 @@ and it's also much more restricted in the latter case: In the MMU case: As for ordinary regular files. In the no-MMU case: The filesystem providing the memory-backed file - (such as ramfs or tmpfs) may choose to honour an open, truncate, mmap + (such as ramfs or tmpfs) may choose to honor an open, truncate, mmap sequence by providing a contiguous sequence of pages to map. In that case, a shared-writable memory mapping will be possible. It will work as for the MMU case. If the filesystem does not provide any such @@ -98,7 +98,7 @@ and it's also much more restricted in the latter case: In the MMU case: As for ordinary regular files. - In the no-MMU case: The character device driver may choose to honour + In the no-MMU case: The character device driver may choose to honor the mmap() by providing direct access to the underlying device if it provides memory or quasi-memory that can be accessed directly. Examples of such are frame buffers and flash devices. If the driver does not @@ -210,7 +210,7 @@ PROVIDING SHAREABLE CHARACTER DEVICE SUPPORT To provide shareable character device support, a driver must provide a file->f_op->get_unmapped_area() operation. The mmap() routines will call this to get a proposed address for the mapping. This may return an error if it -doesn't wish to honour the mapping because it's too long, at a weird offset, +doesn't wish to honor the mapping because it's too long, at a weird offset, under some unsupported combination of flags or whatever. The driver should also provide backing device information with capabilities set @@ -260,7 +260,7 @@ of pages and permit mappings to be made on that. It is recommended that a truncate operation applied to such a file that increases the file size, if that file is empty, be taken as a request to gather -enough pages to honour a mapping. This is required to support POSIX shared +enough pages to honor a mapping. This is required to support POSIX shared memory. Memory backed devices are indicated by the mapping's backing device info having @@ -273,19 +273,19 @@ PROVIDING SHAREABLE BLOCK DEVICE SUPPORT Provision of shared mappings on block device files is exactly the same as for character devices. If there isn't a real device underneath, then the driver -should allocate sufficient contiguous memory to honour any supported mapping. +should allocate sufficient contiguous memory to honor any supported mapping. ================================= -ADJUSTING PAGE TRIMMING BEHAVIOUR +ADJUSTING PAGE TRIMMING BEHAVIOR ================================= NOMMU mmap automatically rounds up to the nearest power-of-2 number of pages when performing an allocation. This can have adverse effects on memory -fragmentation, and as such, is left configurable. The default behaviour is to +fragmentation, and as such, is left configurable. The default behavior is to aggressively trim allocations and discard any excess pages back in to the page allocator. In order to retain finer-grained control over fragmentation, this -behaviour can either be disabled completely, or bumped up to a higher page +behavior can either be disabled completely, or bumped up to a higher page watermark where trimming begins. -Page trimming behaviour is configurable via the sysctl `vm.nr_trim_pages'. +Page trimming behavior is configurable via the sysctl `vm.nr_trim_pages'. diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt index f3ac05cc23e4ab..cac5d4a92a8462 100644 --- a/Documentation/oops-tracing.txt +++ b/Documentation/oops-tracing.txt @@ -12,7 +12,7 @@ If you are unsure send it to the person responsible for the code relevant to what you were doing. If it occurs repeatably try and describe how to recreate it. That's worth even more than the oops. -If you are totally stumped as to whom to send the report, send it to +If you are totally stumped as to whom to send the report, send it to linux-kernel@vger.kernel.org. Thanks for your help in making Linux as stable as humanly possible. @@ -39,7 +39,7 @@ the disk is not available then you have three options :- (2) Boot with a serial console (see Documentation/serial-console.txt), run a null modem to a second machine and capture the output there - using your favourite communication program. Minicom works well. + using your favorite communication program. Minicom works well. (3) Use Kdump (see Documentation/kdump/kdump.txt), extract the kernel ring buffer from old memory with using dmesg @@ -51,39 +51,39 @@ Full Information NOTE: the message from Linus below applies to 2.4 kernel. I have preserved it for historical reasons, and because some of the information in it still -applies. Especially, please ignore any references to ksymoops. +applies. Especially, please ignore any references to ksymoops. From: Linus Torvalds How to track down an Oops.. [originally a mail to linux-kernel] -The main trick is having 5 years of experience with those pesky oops +The main trick is having 5 years of experience with those pesky oops messages ;-) -Actually, there are things you can do that make this easier. I have two +Actually, there are things you can do that make this easier. I have two separate approaches: gdb /usr/src/linux/vmlinux gdb> disassemble -That's the easy way to find the problem, at least if the bug-report is -well made (like this one was - run through ksymoops to get the -information of which function and the offset in the function that it +That's the easy way to find the problem, at least if the bug-report is +well made (like this one was - run through ksymoops to get the +information of which function and the offset in the function that it happened in). -Oh, it helps if the report happens on a kernel that is compiled with the +Oh, it helps if the report happens on a kernel that is compiled with the same compiler and similar setups. -The other thing to do is disassemble the "Code:" part of the bug report: +The other thing to do is disassemble the "Code:" part of the bug report: ksymoops will do this too with the correct tools, but if you don't have the tools you can just do a silly program: char str[] = "\xXX\xXX\xXX..."; main(){} -and compile it with gcc -g and then do "disassemble str" (where the "XX" -stuff are the values reported by the Oops - you can just cut-and-paste -and do a replace of spaces to "\x" - that's what I do, as I'm too lazy +and compile it with gcc -g and then do "disassemble str" (where the "XX" +stuff are the values reported by the Oops - you can just cut-and-paste +and do a replace of spaces to "\x" - that's what I do, as I'm too lazy to write a program to automate this all). Alternatively, you can use the shell script in scripts/decodecode. @@ -105,35 +105,35 @@ Finally, if you want to see where the code comes from, you can do cd /usr/src/linux make fs/buffer.s # or whatever file the bug happened in -and then you get a better idea of what happens than with the gdb +and then you get a better idea of what happens than with the gdb disassembly. -Now, the trick is just then to combine all the data you have: the C -sources (and general knowledge of what it _should_ do), the assembly -listing and the code disassembly (and additionally the register dump you -also get from the "oops" message - that can be useful to see _what_ the -corrupted pointers were, and when you have the assembler listing you can -also match the other registers to whatever C expressions they were used +Now, the trick is just then to combine all the data you have: the C +sources (and general knowledge of what it _should_ do), the assembly +listing and the code disassembly (and additionally the register dump you +also get from the "oops" message - that can be useful to see _what_ the +corrupted pointers were, and when you have the assembler listing you can +also match the other registers to whatever C expressions they were used for). -Essentially, you just look at what doesn't match (in this case it was the -"Code" disassembly that didn't match with what the compiler generated). -Then you need to find out _why_ they don't match. Often it's simple - you -see that the code uses a NULL pointer and then you look at the code and -wonder how the NULL pointer got there, and if it's a valid thing to do +Essentially, you just look at what doesn't match (in this case it was the +"Code" disassembly that didn't match with what the compiler generated). +Then you need to find out _why_ they don't match. Often it's simple - you +see that the code uses a NULL pointer and then you look at the code and +wonder how the NULL pointer got there, and if it's a valid thing to do you just check against it.. -Now, if somebody gets the idea that this is time-consuming and requires -some small amount of concentration, you're right. Which is why I will -mostly just ignore any panic reports that don't have the symbol table -info etc looked up: it simply gets too hard to look it up (I have some -programs to search for specific patterns in the kernel code segment, and -sometimes I have been able to look up those kinds of panics too, but -that really requires pretty good knowledge of the kernel just to be able +Now, if somebody gets the idea that this is time-consuming and requires +some small amount of concentration, you're right. Which is why I will +mostly just ignore any panic reports that don't have the symbol table +info etc looked up: it simply gets too hard to look it up (I have some +programs to search for specific patterns in the kernel code segment, and +sometimes I have been able to look up those kinds of panics too, but +that really requires pretty good knowledge of the kernel just to be able to pick out the right sequences etc..) -_Sometimes_ it happens that I just see the disassembled code sequence -from the panic, and I know immediately where it's coming from. That's when +_Sometimes_ it happens that I just see the disassembled code sequence +from the panic, and I know immediately where it's coming from. That's when I get worried that I've been doing this for too long ;-) Linus @@ -204,11 +204,11 @@ Aug 29 09:51:01 blizard kernel: eax: 315e97cc ebx: 003a6f80 ecx: 001be77b Aug 29 09:51:01 blizard kernel: esi: 00000000 edi: bffffdb3 ebp: 00589f90 esp: 00589f8c Aug 29 09:51:01 blizard kernel: ds: 0018 es: 0018 fs: 002b gs: 002b ss: 0018 Aug 29 09:51:01 blizard kernel: Process oops_test (pid: 3374, process nr: 21, stackpage=00589000) -Aug 29 09:51:01 blizard kernel: Stack: 315e97cc 00589f98 0100b0b4 bffffed4 0012e38e 00240c64 003a6f80 00000001 -Aug 29 09:51:01 blizard kernel: 00000000 00237810 bfffff00 0010a7fa 00000003 00000001 00000000 bfffff00 -Aug 29 09:51:01 blizard kernel: bffffdb3 bffffed4 ffffffda 0000002b 0007002b 0000002b 0000002b 00000036 -Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128] -Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3 +Aug 29 09:51:01 blizard kernel: Stack: 315e97cc 00589f98 0100b0b4 bffffed4 0012e38e 00240c64 003a6f80 00000001 +Aug 29 09:51:01 blizard kernel: 00000000 00237810 bfffff00 0010a7fa 00000003 00000001 00000000 bfffff00 +Aug 29 09:51:01 blizard kernel: bffffdb3 bffffed4 ffffffda 0000002b 0007002b 0000002b 0000002b 00000036 +Aug 29 09:51:01 blizard kernel: Call Trace: [oops:_oops_ioctl+48/80] [_sys_ioctl+254/272] [_system_call+82/128] +Aug 29 09:51:01 blizard kernel: Code: c7 00 05 00 00 00 eb 08 90 90 90 90 90 90 90 90 89 ec 5d c3 --------------------------------------------------------------------------- Dr. G.W. Wettstein Oncology Research Div. Computing Facility @@ -228,7 +228,7 @@ characters, each representing a particular tainted value. 1: 'G' if all modules loaded have a GPL or compatible license, 'P' if any proprietary module has been loaded. Modules without a - MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by + MODULE_LICENSE or with a MODULE_LICENSE that is not recognized by insmod as GPL compatible are assumed to be proprietary. 2: 'F' if any module was force loaded by "insmod -f", ' ' if all diff --git a/Documentation/parport-lowlevel.txt b/Documentation/parport-lowlevel.txt index 120eb20dbb0919..1a5da6420ef964 100644 --- a/Documentation/parport-lowlevel.txt +++ b/Documentation/parport-lowlevel.txt @@ -80,7 +80,7 @@ The port functions can be split into three groups: SPP, EPP, and ECP. SPP (Standard Parallel Port) functions modify so-called 'SPP' registers: data, status, and control. The hardware may not actually have registers exactly like that, but the PC does and this interface is -modelled after common PC implementations. Other low-level drivers may +modeled after common PC implementations. Other low-level drivers may be able to emulate most of the functionality. EPP (Enhanced Parallel Port) functions are provided for reading and @@ -144,7 +144,7 @@ struct parport There are other members of the structure, but they should not be touched. -The 'modes' member summarises the capabilities of the underlying +The 'modes' member summarizes the capabilities of the underlying hardware. It consists of flags which may be bitwise-ored together: PARPORT_MODE_PCSPP IBM PC registers are available, diff --git a/Documentation/parport.txt b/Documentation/parport.txt index c208e4366c033d..45ccc5e7b60389 100644 --- a/Documentation/parport.txt +++ b/Documentation/parport.txt @@ -59,7 +59,7 @@ Parport probe [optional] In 2.2 kernels there was a module called parport_probe, which was used for collecting IEEE 1284 device ID information. This has now been enhanced and now lives with the IEEE 1284 support. When a parallel -port is detected, the devices that are connected to it are analysed, +port is detected, the devices that are connected to it are analyzed, and information is logged like this: parport0: Printer, BJC-210 (Canon) diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 4976389e432d4d..5a137fb608de65 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -290,7 +290,7 @@ Since the pin controller subsystem have its pinspace local to the pin controller we need a mapping so that the pin control subsystem can figure out which pin controller handles control of a certain GPIO pin. Since a single pin controller may be muxing several GPIO ranges (typically SoCs that have -one set of pins, but internally several GPIO silicon blocks, each modelled as +one set of pins, but internally several GPIO silicon blocks, each modeled as a struct gpio_chip) any number of GPIO ranges can be added to a pin controller instance like this: diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index b784c270105f40..3db4436647c772 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt @@ -48,7 +48,7 @@ Symbols/Function Pointers: The 'B' specifier results in the symbol name with offsets and should be used when printing stack backtraces. The specifier takes into - consideration the effect of compiler optimisations which may occur + consideration the effect of compiler optimizations which may occur when tail-call's are used and marked with the noreturn GCC attribute. On ia64, ppc64 and parisc64 architectures function pointers are @@ -61,7 +61,7 @@ Kernel Pointers: %pK 0x01234567 or 0x0123456789abcdef For printing kernel pointers which should be hidden from unprivileged - users. The behaviour of %pK depends on the kptr_restrict sysctl - see + users. The behavior of %pK depends on the kptr_restrict sysctl - see Documentation/sysctl/kernel.txt for more details. Struct Resources: diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt index 5d8675615e59c4..dca9c61637a9ce 100644 --- a/Documentation/ramoops.txt +++ b/Documentation/ramoops.txt @@ -19,7 +19,7 @@ and type of the memory area are set using three variables: * "mem_address" for the start * "mem_size" for the size. The memory size will be rounded down to a power of two. - * "mem_type" to specifiy if the memory type (default is pgprot_writecombine). + * "mem_type" to specify if the memory type (default is pgprot_writecombine). Typically the default value of mem_type=0 should be used as that sets the pstore mapping to pgprot_writecombine. Setting mem_type=1 attempts to use diff --git a/Documentation/robust-futexes.txt b/Documentation/robust-futexes.txt index af6fce23e48477..31f68b8c047cba 100644 --- a/Documentation/robust-futexes.txt +++ b/Documentation/robust-futexes.txt @@ -126,9 +126,9 @@ vma based method: - no VM changes are needed - 'struct address_space' is left alone. - - no registration of individual locks is needed: robust mutexes dont + - no registration of individual locks is needed: robust mutexes don't need any extra per-lock syscalls. Robust mutexes thus become a very - lightweight primitive - so they dont force the application designer + lightweight primitive - so they don't force the application designer to do a hard choice between performance and robustness - robust mutexes are just as fast. diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt index 477927becacba6..f73a43ddedc12f 100644 --- a/Documentation/static-keys.txt +++ b/Documentation/static-keys.txt @@ -116,7 +116,7 @@ Or: Keys defined via DEFINE_STATIC_KEY_TRUE(), or DEFINE_STATIC_KEY_FALSE, may be used in either static_branch_likely() or static_branch_unlikely() -statemnts. +statements. Branch(es) can be set true via: diff --git a/Documentation/svga.txt b/Documentation/svga.txt index cd66ec836e4f45..f0f44e88e2745b 100644 --- a/Documentation/svga.txt +++ b/Documentation/svga.txt @@ -204,7 +204,7 @@ the configuration options listed in section 4. If it fails, you can still use your kernel with the video mode set directly via the kernel parameter. In either case, please send me a bug report containing what _exactly_ -happens and how do the configuration switches affect the behaviour of the bug. +happens and how do the configuration switches affect the behavior of the bug. If you start Linux from M$-DOS, you might also use some DOS tools for video mode setting. In this case, you must specify the 0x0f04 mode ("leave diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index 13f5619b2203e6..5529e4daaee261 100644 --- a/Documentation/sysrq.txt +++ b/Documentation/sysrq.txt @@ -23,7 +23,7 @@ to 1. Here is the list of possible values in /proc/sys/kernel/sysrq: 8 = 0x8 - enable debugging dumps of processes etc. 16 = 0x10 - enable sync command 32 = 0x20 - enable remount read-only - 64 = 0x40 - enable signalling of processes (term, kill, oom-kill) + 64 = 0x40 - enable signaling of processes (term, kill, oom-kill) 128 = 0x80 - allow reboot/poweroff 256 = 0x100 - allow nicing of all RT tasks @@ -53,7 +53,7 @@ On the serial console (PC style standard serial ports only) - You send a BREAK, then within 5 seconds a command key. Sending BREAK twice is interpreted as a normal BREAK. -On PowerPC - Press 'ALT - Print Screen (or F13) - , +On PowerPC - Press 'ALT - Print Screen (or F13) - , Print Screen (or F13) - may suffice. On other - If you know of the key combos for other architectures, please @@ -116,7 +116,7 @@ On all - write a character to /proc/sysrq-trigger. e.g.: 'v' - Forcefully restores framebuffer console 'v' - Causes ETM buffer dump [ARM-specific] -'w' - Dumps tasks that are in uninterruptable (blocked) state. +'w' - Dumps tasks that are in uninterruptible (blocked) state. 'x' - Used by xmon interface on ppc/powerpc platforms. Show global PMU Registers on sparc64. diff --git a/Documentation/unaligned-memory-access.txt b/Documentation/unaligned-memory-access.txt index a445da098bc6e5..cb4f035980c256 100644 --- a/Documentation/unaligned-memory-access.txt +++ b/Documentation/unaligned-memory-access.txt @@ -1,7 +1,7 @@ UNALIGNED MEMORY ACCESSES ========================= -Linux runs on a wide variety of architectures which have varying behaviour +Linux runs on a wide variety of architectures which have varying behavior when it comes to memory access. This document presents some details about unaligned accesses, why you need to write code that doesn't cause them, and how to write such code! @@ -233,7 +233,7 @@ Alignment vs. Networking ======================== On architectures that require aligned loads, networking requires that the IP -header is aligned on a four-byte boundary to optimise the IP stack. For +header is aligned on a four-byte boundary to optimize the IP stack. For regular ethernet hardware, the constant NET_IP_ALIGN is used. On most architectures this constant has the value 2 because the normal ethernet header is 14 bytes long, so in order to get proper alignment one needs to @@ -259,4 +259,3 @@ Authors: Daniel Drake , With help from: Alan Cox, Avuton Olrich, Heikki Orsila, Jan Engelhardt, Kyle McMartin, Kyle Moffett, Randy Dunlap, Robert Hancock, Uli Kunitz, Vadim Lobanov - diff --git a/Documentation/xillybus.txt b/Documentation/xillybus.txt index 81d111b4dc28e1..1660145b9969f3 100644 --- a/Documentation/xillybus.txt +++ b/Documentation/xillybus.txt @@ -215,7 +215,7 @@ in xillybus_core.c as follows: choice is a non-zero value, to match standard UNIX behavior. * synchronous: A non-zero value means that the pipe is synchronous. See - Syncronization above. + Synchronization above. * bufsize: Each DMA buffer's size. Always a power of two. diff --git a/net/netfilter/xt_TCPMSS.c b/net/netfilter/xt_TCPMSS.c index b7c43def0dc69e..c53d4d18eadf71 100644 --- a/net/netfilter/xt_TCPMSS.c +++ b/net/netfilter/xt_TCPMSS.c @@ -1,350 +1,110 @@ -/* - * This is a module which is used for setting the MSS option in TCP packets. - * - * Copyright (C) 2000 Marc Boucher - * Copyright (C) 2007 Patrick McHardy +/* Kernel module to match TCP MSS values. */ + +/* Copyright (C) 2000 Marc Boucher + * Portions (C) 2005 by Harald Welte * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. */ -#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt + #include #include -#include -#include -#include -#include -#include -#include -#include -#include #include +#include +#include + #include #include -#include -#include -#include MODULE_LICENSE("GPL"); MODULE_AUTHOR("Marc Boucher "); -MODULE_DESCRIPTION("Xtables: TCP Maximum Segment Size (MSS) adjustment"); -MODULE_ALIAS("ipt_TCPMSS"); -MODULE_ALIAS("ip6t_TCPMSS"); - -static inline unsigned int -optlen(const u_int8_t *opt, unsigned int offset) -{ - /* Beware zero-length options: make finite progress */ - if (opt[offset] <= TCPOPT_NOP || opt[offset+1] == 0) - return 1; - else - return opt[offset+1]; -} - -static u_int32_t tcpmss_reverse_mtu(struct net *net, - const struct sk_buff *skb, - unsigned int family) -{ - struct flowi fl; - const struct nf_afinfo *ai; - struct rtable *rt = NULL; - u_int32_t mtu = ~0U; - - if (family == PF_INET) { - struct flowi4 *fl4 = &fl.u.ip4; - memset(fl4, 0, sizeof(*fl4)); - fl4->daddr = ip_hdr(skb)->saddr; - } else { - struct flowi6 *fl6 = &fl.u.ip6; - - memset(fl6, 0, sizeof(*fl6)); - fl6->daddr = ipv6_hdr(skb)->saddr; - } - rcu_read_lock(); - ai = nf_get_afinfo(family); - if (ai != NULL) - ai->route(net, (struct dst_entry **)&rt, &fl, false); - rcu_read_unlock(); - - if (rt != NULL) { - mtu = dst_mtu(&rt->dst); - dst_release(&rt->dst); - } - return mtu; -} +MODULE_DESCRIPTION("Xtables: TCP MSS match"); +MODULE_ALIAS("ipt_tcpmss"); +MODULE_ALIAS("ip6t_tcpmss"); -static int -tcpmss_mangle_packet(struct sk_buff *skb, - const struct xt_action_param *par, - unsigned int family, - unsigned int tcphoff, - unsigned int minlen) +static bool +tcpmss_mt(const struct sk_buff *skb, struct xt_action_param *par) { - const struct xt_tcpmss_info *info = par->targinfo; - struct tcphdr *tcph; - int len, tcp_hdrlen; - unsigned int i; - __be16 oldval; - u16 newmss; - u8 *opt; - - /* This is a fragment, no TCP header is available */ - if (par->fragoff != 0) - return 0; - - if (!skb_make_writable(skb, skb->len)) - return -1; - - len = skb->len - tcphoff; - if (len < (int)sizeof(struct tcphdr)) - return -1; - - tcph = (struct tcphdr *)(skb_network_header(skb) + tcphoff); - tcp_hdrlen = tcph->doff * 4; - - if (len < tcp_hdrlen) - return -1; - - if (info->mss == XT_TCPMSS_CLAMP_PMTU) { - struct net *net = par->net; - unsigned int in_mtu = tcpmss_reverse_mtu(net, skb, family); - - if (dst_mtu(skb_dst(skb)) <= minlen) { - net_err_ratelimited("unknown or invalid path-MTU (%u)\n", - dst_mtu(skb_dst(skb))); - return -1; - } - if (in_mtu <= minlen) { - net_err_ratelimited("unknown or invalid path-MTU (%u)\n", - in_mtu); - return -1; + const struct xt_tcpmss_match_info *info = par->matchinfo; + const struct tcphdr *th; + struct tcphdr _tcph; + /* tcp.doff is only 4 bits, ie. max 15 * 4 bytes */ + const u_int8_t *op; + u8 _opt[15 * 4 - sizeof(_tcph)]; + unsigned int i, optlen; + + /* If we don't have the whole header, drop packet. */ + th = skb_header_pointer(skb, par->thoff, sizeof(_tcph), &_tcph); + if (th == NULL) + goto dropit; + + /* Malformed. */ + if (th->doff*4 < sizeof(*th)) + goto dropit; + + optlen = th->doff*4 - sizeof(*th); + if (!optlen) + goto out; + + /* Truncated options. */ + op = skb_header_pointer(skb, par->thoff + sizeof(*th), optlen, _opt); + if (op == NULL) + goto dropit; + + for (i = 0; i < optlen; ) { + if (op[i] == TCPOPT_MSS + && (optlen - i) >= TCPOLEN_MSS + && op[i+1] == TCPOLEN_MSS) { + u_int16_t mssval; + + mssval = (op[i+2] << 8) | op[i+3]; + + return (mssval >= info->mss_min && + mssval <= info->mss_max) ^ info->invert; } - newmss = min(dst_mtu(skb_dst(skb)), in_mtu) - minlen; - } else - newmss = info->mss; - - opt = (u_int8_t *)tcph; - for (i = sizeof(struct tcphdr); i <= tcp_hdrlen - TCPOLEN_MSS; i += optlen(opt, i)) { - if (opt[i] == TCPOPT_MSS && opt[i+1] == TCPOLEN_MSS) { - u_int16_t oldmss; - - oldmss = (opt[i+2] << 8) | opt[i+3]; - - /* Never increase MSS, even when setting it, as - * doing so results in problems for hosts that rely - * on MSS being set correctly. - */ - if (oldmss <= newmss) - return 0; - - opt[i+2] = (newmss & 0xff00) >> 8; - opt[i+3] = newmss & 0x00ff; - - inet_proto_csum_replace2(&tcph->check, skb, - htons(oldmss), htons(newmss), - false); - return 0; - } - } - - /* There is data after the header so the option can't be added - * without moving it, and doing so may make the SYN packet - * itself too large. Accept the packet unmodified instead. - */ - if (len > tcp_hdrlen) - return 0; - - /* - * MSS Option not found ?! add it.. - */ - if (skb_tailroom(skb) < TCPOLEN_MSS) { - if (pskb_expand_head(skb, 0, - TCPOLEN_MSS - skb_tailroom(skb), - GFP_ATOMIC)) - return -1; - tcph = (struct tcphdr *)(skb_network_header(skb) + tcphoff); + if (op[i] < 2) + i++; + else + i += op[i+1] ? : 1; } +out: + return info->invert; - skb_put(skb, TCPOLEN_MSS); - - /* - * IPv4: RFC 1122 states "If an MSS option is not received at - * connection setup, TCP MUST assume a default send MSS of 536". - * IPv6: RFC 2460 states IPv6 has a minimum MTU of 1280 and a minimum - * length IPv6 header of 60, ergo the default MSS value is 1220 - * Since no MSS was provided, we must use the default values - */ - if (par->family == NFPROTO_IPV4) - newmss = min(newmss, (u16)536); - else - newmss = min(newmss, (u16)1220); - - opt = (u_int8_t *)tcph + sizeof(struct tcphdr); - memmove(opt + TCPOLEN_MSS, opt, len - sizeof(struct tcphdr)); - - inet_proto_csum_replace2(&tcph->check, skb, - htons(len), htons(len + TCPOLEN_MSS), true); - opt[0] = TCPOPT_MSS; - opt[1] = TCPOLEN_MSS; - opt[2] = (newmss & 0xff00) >> 8; - opt[3] = newmss & 0x00ff; - - inet_proto_csum_replace4(&tcph->check, skb, 0, *((__be32 *)opt), false); - - oldval = ((__be16 *)tcph)[6]; - tcph->doff += TCPOLEN_MSS/4; - inet_proto_csum_replace2(&tcph->check, skb, - oldval, ((__be16 *)tcph)[6], false); - return TCPOLEN_MSS; -} - -static unsigned int -tcpmss_tg4(struct sk_buff *skb, const struct xt_action_param *par) -{ - struct iphdr *iph = ip_hdr(skb); - __be16 newlen; - int ret; - - ret = tcpmss_mangle_packet(skb, par, - PF_INET, - iph->ihl * 4, - sizeof(*iph) + sizeof(struct tcphdr)); - if (ret < 0) - return NF_DROP; - if (ret > 0) { - iph = ip_hdr(skb); - newlen = htons(ntohs(iph->tot_len) + ret); - csum_replace2(&iph->check, iph->tot_len, newlen); - iph->tot_len = newlen; - } - return XT_CONTINUE; -} - -#if IS_ENABLED(CONFIG_IP6_NF_IPTABLES) -static unsigned int -tcpmss_tg6(struct sk_buff *skb, const struct xt_action_param *par) -{ - struct ipv6hdr *ipv6h = ipv6_hdr(skb); - u8 nexthdr; - __be16 frag_off; - int tcphoff; - int ret; - - nexthdr = ipv6h->nexthdr; - tcphoff = ipv6_skip_exthdr(skb, sizeof(*ipv6h), &nexthdr, &frag_off); - if (tcphoff < 0) - return NF_DROP; - ret = tcpmss_mangle_packet(skb, par, - PF_INET6, - tcphoff, - sizeof(*ipv6h) + sizeof(struct tcphdr)); - if (ret < 0) - return NF_DROP; - if (ret > 0) { - ipv6h = ipv6_hdr(skb); - ipv6h->payload_len = htons(ntohs(ipv6h->payload_len) + ret); - } - return XT_CONTINUE; -} -#endif - -/* Must specify -p tcp --syn */ -static inline bool find_syn_match(const struct xt_entry_match *m) -{ - const struct xt_tcp *tcpinfo = (const struct xt_tcp *)m->data; - - if (strcmp(m->u.kernel.match->name, "tcp") == 0 && - tcpinfo->flg_cmp & TCPHDR_SYN && - !(tcpinfo->invflags & XT_TCP_INV_FLAGS)) - return true; - +dropit: + par->hotdrop = true; return false; } -static int tcpmss_tg4_check(const struct xt_tgchk_param *par) -{ - const struct xt_tcpmss_info *info = par->targinfo; - const struct ipt_entry *e = par->entryinfo; - const struct xt_entry_match *ematch; - - if (info->mss == XT_TCPMSS_CLAMP_PMTU && - (par->hook_mask & ~((1 << NF_INET_FORWARD) | - (1 << NF_INET_LOCAL_OUT) | - (1 << NF_INET_POST_ROUTING))) != 0) { - pr_info("path-MTU clamping only supported in " - "FORWARD, OUTPUT and POSTROUTING hooks\n"); - return -EINVAL; - } - if (par->nft_compat) - return 0; - - xt_ematch_foreach(ematch, e) - if (find_syn_match(ematch)) - return 0; - pr_info("Only works on TCP SYN packets\n"); - return -EINVAL; -} - -#if IS_ENABLED(CONFIG_IP6_NF_IPTABLES) -static int tcpmss_tg6_check(const struct xt_tgchk_param *par) -{ - const struct xt_tcpmss_info *info = par->targinfo; - const struct ip6t_entry *e = par->entryinfo; - const struct xt_entry_match *ematch; - - if (info->mss == XT_TCPMSS_CLAMP_PMTU && - (par->hook_mask & ~((1 << NF_INET_FORWARD) | - (1 << NF_INET_LOCAL_OUT) | - (1 << NF_INET_POST_ROUTING))) != 0) { - pr_info("path-MTU clamping only supported in " - "FORWARD, OUTPUT and POSTROUTING hooks\n"); - return -EINVAL; - } - if (par->nft_compat) - return 0; - - xt_ematch_foreach(ematch, e) - if (find_syn_match(ematch)) - return 0; - pr_info("Only works on TCP SYN packets\n"); - return -EINVAL; -} -#endif - -static struct xt_target tcpmss_tg_reg[] __read_mostly = { +static struct xt_match tcpmss_mt_reg[] __read_mostly = { { + .name = "tcpmss", .family = NFPROTO_IPV4, - .name = "TCPMSS", - .checkentry = tcpmss_tg4_check, - .target = tcpmss_tg4, - .targetsize = sizeof(struct xt_tcpmss_info), + .match = tcpmss_mt, + .matchsize = sizeof(struct xt_tcpmss_match_info), .proto = IPPROTO_TCP, .me = THIS_MODULE, }, -#if IS_ENABLED(CONFIG_IP6_NF_IPTABLES) { + .name = "tcpmss", .family = NFPROTO_IPV6, - .name = "TCPMSS", - .checkentry = tcpmss_tg6_check, - .target = tcpmss_tg6, - .targetsize = sizeof(struct xt_tcpmss_info), + .match = tcpmss_mt, + .matchsize = sizeof(struct xt_tcpmss_match_info), .proto = IPPROTO_TCP, .me = THIS_MODULE, }, -#endif }; -static int __init tcpmss_tg_init(void) +static int __init tcpmss_mt_init(void) { - return xt_register_targets(tcpmss_tg_reg, ARRAY_SIZE(tcpmss_tg_reg)); + return xt_register_matches(tcpmss_mt_reg, ARRAY_SIZE(tcpmss_mt_reg)); } -static void __exit tcpmss_tg_exit(void) +static void __exit tcpmss_mt_exit(void) { - xt_unregister_targets(tcpmss_tg_reg, ARRAY_SIZE(tcpmss_tg_reg)); + xt_unregister_matches(tcpmss_mt_reg, ARRAY_SIZE(tcpmss_mt_reg)); } -module_init(tcpmss_tg_init); -module_exit(tcpmss_tg_exit); +module_init(tcpmss_mt_init); +module_exit(tcpmss_mt_exit); diff --git a/net/netfilter/xt_tcpmss.c b/net/netfilter/xt_tcpmss.c deleted file mode 100644 index c53d4d18eadf71..00000000000000 --- a/net/netfilter/xt_tcpmss.c +++ /dev/null @@ -1,110 +0,0 @@ -/* Kernel module to match TCP MSS values. */ - -/* Copyright (C) 2000 Marc Boucher - * Portions (C) 2005 by Harald Welte - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 as - * published by the Free Software Foundation. - */ - -#include -#include -#include - -#include -#include - -#include -#include - -MODULE_LICENSE("GPL"); -MODULE_AUTHOR("Marc Boucher "); -MODULE_DESCRIPTION("Xtables: TCP MSS match"); -MODULE_ALIAS("ipt_tcpmss"); -MODULE_ALIAS("ip6t_tcpmss"); - -static bool -tcpmss_mt(const struct sk_buff *skb, struct xt_action_param *par) -{ - const struct xt_tcpmss_match_info *info = par->matchinfo; - const struct tcphdr *th; - struct tcphdr _tcph; - /* tcp.doff is only 4 bits, ie. max 15 * 4 bytes */ - const u_int8_t *op; - u8 _opt[15 * 4 - sizeof(_tcph)]; - unsigned int i, optlen; - - /* If we don't have the whole header, drop packet. */ - th = skb_header_pointer(skb, par->thoff, sizeof(_tcph), &_tcph); - if (th == NULL) - goto dropit; - - /* Malformed. */ - if (th->doff*4 < sizeof(*th)) - goto dropit; - - optlen = th->doff*4 - sizeof(*th); - if (!optlen) - goto out; - - /* Truncated options. */ - op = skb_header_pointer(skb, par->thoff + sizeof(*th), optlen, _opt); - if (op == NULL) - goto dropit; - - for (i = 0; i < optlen; ) { - if (op[i] == TCPOPT_MSS - && (optlen - i) >= TCPOLEN_MSS - && op[i+1] == TCPOLEN_MSS) { - u_int16_t mssval; - - mssval = (op[i+2] << 8) | op[i+3]; - - return (mssval >= info->mss_min && - mssval <= info->mss_max) ^ info->invert; - } - if (op[i] < 2) - i++; - else - i += op[i+1] ? : 1; - } -out: - return info->invert; - -dropit: - par->hotdrop = true; - return false; -} - -static struct xt_match tcpmss_mt_reg[] __read_mostly = { - { - .name = "tcpmss", - .family = NFPROTO_IPV4, - .match = tcpmss_mt, - .matchsize = sizeof(struct xt_tcpmss_match_info), - .proto = IPPROTO_TCP, - .me = THIS_MODULE, - }, - { - .name = "tcpmss", - .family = NFPROTO_IPV6, - .match = tcpmss_mt, - .matchsize = sizeof(struct xt_tcpmss_match_info), - .proto = IPPROTO_TCP, - .me = THIS_MODULE, - }, -}; - -static int __init tcpmss_mt_init(void) -{ - return xt_register_matches(tcpmss_mt_reg, ARRAY_SIZE(tcpmss_mt_reg)); -} - -static void __exit tcpmss_mt_exit(void) -{ - xt_unregister_matches(tcpmss_mt_reg, ARRAY_SIZE(tcpmss_mt_reg)); -} - -module_init(tcpmss_mt_init); -module_exit(tcpmss_mt_exit);