Merge branch 'linus' into x86/boot, to resolve conflict

Kenneth Westfield <quic_kwestfie@quicinc.com> <kwestfie@codeaurora.org>

Kiran Gunda <quic_kgunda@quicinc.com> <kgunda@codeaurora.org>

Kirill Tkhai <tkhai@ya.ru> <ktkhai@virtuozzo.com>

Kishon Vijay Abraham I <kishon@kernel.org> <kishon@ti.com>

Konstantin Khlebnikov <koct9i@gmail.com> <khlebnikov@yandex-team.ru>

Konstantin Khlebnikov <koct9i@gmail.com> <k.khlebnikov@samsung.com>

Koushik <raghavendra.koushik@neterion.com>

TripleX Chung <xxx.phy@gmail.com> <zhongyu@18mail.cn>

Tsuneo Yoshioka <Tsuneo.Yoshioka@f-secure.com>

Tudor Ambarus <tudor.ambarus@linaro.org> <tudor.ambarus@microchip.com>

Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@intel.com>

Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@linux.intel.com>

Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@sophos.com>

Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko.ursulin@onelan.co.uk>

Tvrtko Ursulin <tursulin@ursulin.net> <tvrtko@ursulin.net>

Tycho Andersen <tycho@tycho.pizza> <tycho@tycho.ws>

Tzung-Bi Shih <tzungbi@kernel.org> <tzungbi@google.com>

Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>

S: Buenos Aires

S: Argentina

NTFS FILESYSTEM

N: Anton Altaparmakov

E: anton@tuxera.com

D: NTFS filesystem

N: Tim Alpaerts

E: tim_alpaerts@toyota-motor-europe.com

D: 802.2 class II logical link control layer,

	rcu_read_lock_sched(), or by the appropriate update-side lock.

	Explicit disabling of preemption (preempt_disable(), for example)

	can serve as rcu_read_lock_sched(), but is less readable and

	prevents lockdep from detecting locking issues.

	prevents lockdep from detecting locking issues.  Acquiring a

	spinlock also enters an RCU read-side critical section.

	Please note that you *cannot* rely on code known to be built

	only in non-preemptible kernels.  Such code can and will break,

	must use whatever locking or other synchronization is required

	to safely access and/or modify that data structure.

	Do not assume that RCU callbacks will be executed on the same

	CPU that executed the corresponding call_rcu() or call_srcu().

	For example, if a given CPU goes offline while having an RCU

	callback pending, then that RCU callback will execute on some

	surviving CPU.	(If this was not the case, a self-spawning RCU

	callback would prevent the victim CPU from ever going offline.)

	Furthermore, CPUs designated by rcu_nocbs= might well *always*

	have their RCU callbacks executed on some other CPUs, in fact,

	for some  real-time workloads, this is the whole point of using

	the rcu_nocbs= kernel boot parameter.

	Do not assume that RCU callbacks will be executed on

	the same CPU that executed the corresponding call_rcu(),

	call_srcu(), call_rcu_tasks(), call_rcu_tasks_rude(), or

	call_rcu_tasks_trace().  For example, if a given CPU goes offline

	while having an RCU callback pending, then that RCU callback

	will execute on some surviving CPU.  (If this was not the case,

	a self-spawning RCU callback would prevent the victim CPU from

	ever going offline.)  Furthermore, CPUs designated by rcu_nocbs=

	might well *always* have their RCU callbacks executed on some

	other CPUs, in fact, for some  real-time workloads, this is the

	whole point of using the rcu_nocbs= kernel boot parameter.

	In addition, do not assume that callbacks queued in a given order

	will be invoked in that order, even if they all are queued on the

	real-time workloads than is synchronize_rcu_expedited().

	It is also permissible to sleep in RCU Tasks Trace read-side

	critical, which are delimited by rcu_read_lock_trace() and

	critical section, which are delimited by rcu_read_lock_trace() and

	rcu_read_unlock_trace().  However, this is a specialized flavor

	of RCU, and you should not use it without first checking with

	its current users.  In most cases, you should instead use SRCU.

		since the last time that you passed that same object to

		call_rcu() (or friends).

	CONFIG_RCU_STRICT_GRACE_PERIOD:

		combine with KASAN to check for pointers leaked out

		of RCU read-side critical sections.  This Kconfig

		option is tough on both performance and scalability,

		and so is limited to four-CPU systems.

	__rcu sparse checks:

		tag the pointer to the RCU-protected data structure

		with __rcu, and sparse will warn you if you access that

	RCU flavors, an RCU read-side critical section is entered

	using rcu_read_lock(), anything that disables bottom halves,

	anything that disables interrupts, or anything that disables

	preemption.

	preemption.  Please note that spinlock critical sections

	are also implied RCU read-side critical sections, even when

	they are preemptible, as they are in kernels built with

	CONFIG_PREEMPT_RT=y.

2.	If the access might be within an RCU read-side critical section

	on the one hand, or protected by (say) my_lock on the other,

	critical section.  Reference counts may be used in conjunction

	with RCU to maintain longer-term references to data structures.

	Note that anything that disables bottom halves, preemption,

	or interrupts also enters an RCU read-side critical section.

	Acquiring a spinlock also enters an RCU read-side critical

	sections, even for spinlocks that do not disable preemption,

	as is the case in kernels built with CONFIG_PREEMPT_RT=y.

	Sleeplocks do *not* enter RCU read-side critical sections.

rcu_read_unlock()

^^^^^^^^^^^^^^^^^

	void rcu_read_unlock(void);

	This temporal primitives is used by a reader to inform the

	reclaimer that the reader is exiting an RCU read-side critical

	section.  Note that RCU read-side critical sections may be nested

	and/or overlapping.

	section.  Anything that enables bottom halves, preemption,

	or interrupts also exits an RCU read-side critical section.

	Releasing a spinlock also exits an RCU read-side critical section.

	Note that RCU read-side critical sections may be nested and/or

	overlapping.

synchronize_rcu()

^^^^^^^^^^^^^^^^^

initialized after each and every call to kmem_cache_alloc(), which renders

reference-free spinlock acquisition completely unsafe.  Therefore, when

using ``SLAB_TYPESAFE_BY_RCU``, make proper use of a reference counter.

(Those willing to use a kmem_cache constructor may also use locking,

including cache-friendly sequence locking.)

(Those willing to initialize their locks in a kmem_cache constructor

may also use locking, including cache-friendly sequence locking.)

With traditional reference counting -- such as that implemented by the

kref library in Linux -- there is typically code that runs when the last