Commit 9f6e0559 authored by David S. Miller's avatar David S. Miller
Browse files

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net 



The mptcp conflict was overlapping additions.

The SMC conflict was an additional and removal happening at the same
time.

Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parents ec4a514a 7058b837

.gitignore

+4 −0
Original line number Diff line number Diff line
@@ -100,6 +100,10 @@ modules.order 
/include/ksym/

/arch/*/include/generated/



# Generated lkdtm tests

/tools/testing/selftests/lkdtm/*.sh

!/tools/testing/selftests/lkdtm/run.sh



# stgit generated dirs

patches-*

CREDITS

+5 −0
Original line number Diff line number Diff line
@@ -567,6 +567,11 @@ D: Original author of Amiga FFS filesystem 
S: Orlando, Florida

S: USA



N: Paul Burton

E: paulburton@kernel.org

W: https://pburton.com

D: MIPS maintainer 2018-2020



N: Lennert Buytenhek

E: kernel@wantstofly.org

D: Original (2.4) rewrite of the ethernet bridging code

Documentation/admin-guide/bootconfig.rst

+31 −3
Original line number Diff line number Diff line
@@ -62,6 +62,30 @@ Or more shorter, written as following:: 
In both styles, same key words are automatically merged when parsing it

at boot time. So you can append similar trees or key-values.



Same-key Values

---------------



It is prohibited that two or more values or arrays share a same-key.

For example,::



 foo = bar, baz

 foo = qux  # !ERROR! we can not re-define same key



If you want to append the value to existing key as an array member,

you can use ``+=`` operator. For example::



 foo = bar, baz

 foo += qux



In this case, the key ``foo`` has ``bar``, ``baz`` and ``qux``.



However, a sub-key and a value can not co-exist under a parent key.

For example, following config is NOT allowed.::



 foo = value1

 foo.bar = value2 # !ERROR! subkey "bar" and value "value1" can NOT co-exist





Comments

--------
@@ -102,9 +126,13 @@ Boot Kernel With a Boot Config 
==============================



Since the boot configuration file is loaded with initrd, it will be added

to the end of the initrd (initramfs) image file. The Linux kernel decodes

the last part of the initrd image in memory to get the boot configuration

data.

to the end of the initrd (initramfs) image file with size, checksum and

12-byte magic word as below.



[initrd][bootconfig][size(u32)][checksum(u32)][#BOOTCONFIG\n]



The Linux kernel decodes the last part of the initrd image in memory to

get the boot configuration data.

Because of this "piggyback" method, there is no need to change or

update the boot loader and the kernel image itself.

Documentation/arm64/memory.rst

+1 −1
Original line number Diff line number Diff line
@@ -129,7 +129,7 @@ this logic. 


As a single binary will need to support both 48-bit and 52-bit VA

spaces, the VMEMMAP must be sized large enough for 52-bit VAs and

also must be sized large enought to accommodate a fixed PAGE_OFFSET.

also must be sized large enough to accommodate a fixed PAGE_OFFSET.



Most code in the kernel should not need to consider the VA_BITS, for

code that does need to know the VA size the variables are

Documentation/arm64/tagged-address-abi.rst

+9 −2
Original line number Diff line number Diff line
@@ -44,8 +44,15 @@ The AArch64 Tagged Address ABI has two stages of relaxation depending 
how the user addresses are used by the kernel:



1. User addresses not accessed by the kernel but used for address space

   management (e.g. ``mmap()``, ``mprotect()``, ``madvise()``). The use

   of valid tagged pointers in this context is always allowed.

   management (e.g. ``mprotect()``, ``madvise()``). The use of valid

   tagged pointers in this context is allowed with the exception of

   ``brk()``, ``mmap()`` and the ``new_address`` argument to

   ``mremap()`` as these have the potential to alias with existing

   user addresses.



   NOTE: This behaviour changed in v5.6 and so some earlier kernels may

   incorrectly accept valid tagged pointers for the ``brk()``,

   ``mmap()`` and ``mremap()`` system calls.



2. User addresses accessed by the kernel (e.g. ``write()``). This ABI

   relaxation is disabled by default and the application thread needs to