Merge tag 'v4.20-rc5' into perf/core, to pick up fixes

S: North Little Rock, Arkansas 72115

S: USA

N: Christopher Li

E: sparse@chrisli.org

D: Sparse maintainer 2009 - 2018

N: Stephan Linz

E: linz@mazet.de

E: Stephan.Linz@gmx.de

			before loading.

			See Documentation/blockdev/ramdisk.txt.

	psi=		[KNL] Enable or disable pressure stall information

			tracking.

			Format: <bool>

	psmouse.proto=	[HW,MOUSE] Highest PS2 mouse protocol extension to

			probe for; one of (bare|imps|exps|lifebook|any).

	psmouse.rate=	[HW,MOUSE] Set desired mouse report rate, in reports

	spectre_v2=	[X86] Control mitigation of Spectre variant 2

			(indirect branch speculation) vulnerability.

			The default operation protects the kernel from

			user space attacks.

			on   - unconditionally enable

			off  - unconditionally disable

			on   - unconditionally enable, implies

			       spectre_v2_user=on

			off  - unconditionally disable, implies

			       spectre_v2_user=off

			auto - kernel detects whether your CPU model is

			       vulnerable

			CONFIG_RETPOLINE configuration option, and the

			compiler with which the kernel was built.

			Selecting 'on' will also enable the mitigation

			against user space to user space task attacks.

			Selecting 'off' will disable both the kernel and

			the user space protections.

			Specific mitigations can also be selected manually:

			retpoline	  - replace indirect branches

			Not specifying this option is equivalent to

			spectre_v2=auto.

	spectre_v2_user=

			[X86] Control mitigation of Spectre variant 2

		        (indirect branch speculation) vulnerability between

		        user space tasks

			on	- Unconditionally enable mitigations. Is

				  enforced by spectre_v2=on

			off     - Unconditionally disable mitigations. Is

				  enforced by spectre_v2=off

			prctl   - Indirect branch speculation is enabled,

				  but mitigation can be enabled via prctl

				  per thread.  The mitigation control state

				  is inherited on fork.

			prctl,ibpb

				- Like "prctl" above, but only STIBP is

				  controlled per thread. IBPB is issued

				  always when switching between different user

				  space processes.

			seccomp

				- Same as "prctl" above, but all seccomp

				  threads will enable the mitigation unless

				  they explicitly opt out.

			seccomp,ibpb

				- Like "seccomp" above, but only STIBP is

				  controlled per thread. IBPB is issued

				  always when switching between different

				  user space processes.

			auto    - Kernel selects the mitigation depending on

				  the available CPU features and vulnerability.

			Default mitigation:

			If CONFIG_SECCOMP=y then "seccomp", otherwise "prctl"

			Not specifying this option is equivalent to

			spectre_v2_user=auto.

	spec_store_bypass_disable=

			[HW] Control Speculative Store Bypass (SSB) Disable mitigation

			(Speculative Store Bypass vulnerability)

					prevent spurious wakeup);

				n = USB_QUIRK_DELAY_CTRL_MSG (Device needs a

					pause after every control message);

				o = USB_QUIRK_HUB_SLOW_RESET (Hub needs extra

					delay after resetting its port);

			Example: quirks=0781:5580:bk,0a5c:5834:gij

	usbhid.mousepoll=

The security list is not a disclosure channel.  For that, see Coordination

below.

Once a robust fix has been developed, our preference is to release the

fix in a timely fashion, treating it no differently than any of the other

thousands of changes and fixes the Linux kernel project releases every

month.

However, at the request of the reporter, we will postpone releasing the

fix for up to 5 business days after the date of the report or after the

embargo has lifted; whichever comes first.  The only exception to that

rule is if the bug is publicly known, in which case the preference is to

release the fix as soon as it's available.

Once a robust fix has been developed, the release process starts.  Fixes

for publicly known bugs are released immediately.

Although our preference is to release fixes for publicly undisclosed bugs

as soon as they become available, this may be postponed at the request of

the reporter or an affected party for up to 7 calendar days from the start

of the release process, with an exceptional extension to 14 calendar days

if it is agreed that the criticality of the bug requires more time.  The

only valid reason for deferring the publication of a fix is to accommodate

the logistics of QA and large scale rollouts which require release

coordination.

Whilst embargoed information may be shared with trusted individuals in

order to develop a fix, such information will not be published alongside

| ARM            | Cortex-A73      | #858921         | ARM64_ERRATUM_858921        |

| ARM            | Cortex-A55      | #1024718        | ARM64_ERRATUM_1024718       |

| ARM            | Cortex-A76      | #1188873        | ARM64_ERRATUM_1188873       |

| ARM            | Cortex-A76      | #1286807        | ARM64_ERRATUM_1286807       |

| ARM            | MMU-500         | #841119,#826419 | N/A                         |

|                |                 |                 |                             |

| Cavium         | ThunderX ITS    | #22375, #24313  | CAVIUM_ERRATUM_22375        |

new entry and return the previous entry stored at that index.  You can

use :c:func:`xa_erase` instead of calling :c:func:`xa_store` with a

``NULL`` entry.  There is no difference between an entry that has never

been stored to and one that has most recently had ``NULL`` stored to it.

been stored to, one that has been erased and one that has most recently

had ``NULL`` stored to it.

You can conditionally replace an entry at an index by using

:c:func:`xa_cmpxchg`.  Like :c:func:`cmpxchg`, it will only succeed if

indices.  Storing into one index may result in the entry retrieved by

some, but not all of the other indices changing.

Sometimes you need to ensure that a subsequent call to :c:func:`xa_store`

will not need to allocate memory.  The :c:func:`xa_reserve` function

will store a reserved entry at the indicated index.  Users of the normal

API will see this entry as containing ``NULL``.  If you do not need to

use the reserved entry, you can call :c:func:`xa_release` to remove the

unused entry.  If another user has stored to the entry in the meantime,

:c:func:`xa_release` will do nothing; if instead you want the entry to

become ``NULL``, you should use :c:func:`xa_erase`.

If all entries in the array are ``NULL``, the :c:func:`xa_empty` function

will return ``true``.

Finally, you can remove all entries from an XArray by calling

:c:func:`xa_destroy`.  If the XArray entries are pointers, you may wish

to free the entries first.  You can do this by iterating over all present

entries in the XArray using the :c:func:`xa_for_each` iterator.

ID assignment

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

Allocating XArrays

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

If you use :c:func:`DEFINE_XARRAY_ALLOC` to define the XArray, or

initialise it by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`,

the XArray changes to track whether entries are in use or not.

You can call :c:func:`xa_alloc` to store the entry at any unused index

in the XArray.  If you need to modify the array from interrupt context,

you can use :c:func:`xa_alloc_bh` or :c:func:`xa_alloc_irq` to disable

interrupts while allocating the ID.  Unlike :c:func:`xa_store`, allocating

a ``NULL`` pointer does not delete an entry.  Instead it reserves an

entry like :c:func:`xa_reserve` and you can release it using either

:c:func:`xa_erase` or :c:func:`xa_release`.  To use ID assignment, the

XArray must be defined with :c:func:`DEFINE_XARRAY_ALLOC`, or initialised

by passing ``XA_FLAGS_ALLOC`` to :c:func:`xa_init_flags`,

interrupts while allocating the ID.

Using :c:func:`xa_store`, :c:func:`xa_cmpxchg` or :c:func:`xa_insert`

will mark the entry as being allocated.  Unlike a normal XArray, storing

``NULL`` will mark the entry as being in use, like :c:func:`xa_reserve`.

To free an entry, use :c:func:`xa_erase` (or :c:func:`xa_release` if

you only want to free the entry if it's ``NULL``).

You cannot use ``XA_MARK_0`` with an allocating XArray as this mark

is used to track whether an entry is free or not.  The other marks are

available for your use.

Memory allocation

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

Takes xa_lock internally:

 * :c:func:`xa_store`

 * :c:func:`xa_store_bh`

 * :c:func:`xa_store_irq`

 * :c:func:`xa_insert`

 * :c:func:`xa_erase`

 * :c:func:`xa_erase_bh`

 * :c:func:`xa_alloc`

 * :c:func:`xa_alloc_bh`

 * :c:func:`xa_alloc_irq`

 * :c:func:`xa_reserve`

 * :c:func:`xa_reserve_bh`

 * :c:func:`xa_reserve_irq`

 * :c:func:`xa_destroy`

 * :c:func:`xa_set_mark`

 * :c:func:`xa_clear_mark`

 * :c:func:`__xa_erase`

 * :c:func:`__xa_cmpxchg`

 * :c:func:`__xa_alloc`

 * :c:func:`__xa_reserve`

 * :c:func:`__xa_set_mark`

 * :c:func:`__xa_clear_mark`

using :c:func:`xa_lock_irqsave` in both the interrupt handler and process

context, or :c:func:`xa_lock_irq` in process context and :c:func:`xa_lock`

in the interrupt handler.  Some of the more common patterns have helper

functions such as :c:func:`xa_erase_bh` and :c:func:`xa_erase_irq`.

functions such as :c:func:`xa_store_bh`, :c:func:`xa_store_irq`,

:c:func:`xa_erase_bh` and :c:func:`xa_erase_irq`.

Sometimes you need to protect access to the XArray with a mutex because

that lock sits above another mutex in the locking hierarchy.  That does

     - :c:func:`xa_is_zero`

     - Zero entries appear as ``NULL`` through the Normal API, but occupy

       an entry in the XArray which can be used to reserve the index for

       future use.

       future use.  This is used by allocating XArrays for allocated entries

       which are ``NULL``.

Other internal entries may be added in the future.  As far as possible, they

will be handled by :c:func:`xas_retry`.