linux.git/tools/testing/vma/include, branch master

mm: add mmap_action_map_kernel_pages[_full]()

2026-04-05T20:53:45+00:00

A user can invoke mmap_action_map_kernel_pages() to specify that the
mapping should map kernel pages starting from desc->start of a specified
number of pages specified in an array.

In order to implement this, adjust mmap_action_prepare() to be able to
return an error code, as it makes sense to assert that the specified
parameters are valid as quickly as possible as well as updating the VMA
flags to include VMA_MIXEDMAP_BIT as necessary.

This provides an mmap_prepare equivalent of vm_insert_pages().  We
additionally update the existing vm_insert_pages() code to use
range_in_vma() and add a new range_in_vma_desc() helper function for the
mmap_prepare case, sharing the code between the two in range_is_subset().

We add both mmap_action_map_kernel_pages() and
mmap_action_map_kernel_pages_full() to allow for both partial and full VMA
mappings.

We update the documentation to reflect the new features.

Finally, we update the VMA tests accordingly to reflect the changes.

Link: https://lkml.kernel.org/r/926ac961690d856e67ec847bee2370ab3c6b9046.1774045440.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Reviewed-by: Suren Baghdasaryan 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Alexander Shishkin 
Cc: Alexandre Torgue 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Bodo Stroesser 
Cc: Christian Brauner 
Cc: Clemens Ladisch 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jonathan Corbet 
Cc: K. Y. Srinivasan 
Cc: Liam Howlett 
Cc: Long Li 
Cc: Marc Dionne 
Cc: "Martin K. Petersen" 
Cc: Maxime Coquelin 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miquel Raynal 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Ryan Roberts 
Cc: Vignesh Raghavendra 
Cc: Wei Liu 
Signed-off-by: Andrew Morton

mm: allow handling of stacked mmap_prepare hooks in more drivers

2026-04-05T20:53:44+00:00

While the conversion of mmap hooks to mmap_prepare is underway, we will
encounter situations where mmap hooks need to invoke nested mmap_prepare
hooks.

The nesting of mmap hooks is termed 'stacking'.  In order to flexibly
facilitate the conversion of custom mmap hooks in drivers which stack, we
must split up the existing __compat_vma_mmap() function into two separate
functions:

* compat_set_desc_from_vma() - This allows the setting of a vm_area_desc
  object's fields to the relevant fields of a VMA.

* __compat_vma_mmap() - Once an mmap_prepare hook has been executed upon a
  vm_area_desc object, this function performs any mmap actions specified by
  the mmap_prepare hook and then invokes its vm_ops->mapped() hook if any
  were specified.

In ordinary cases, where a file's f_op->mmap_prepare() hook simply needs
to be invoked in a stacked mmap() hook, compat_vma_mmap() can be used.

However some drivers define their own nested hooks, which are invoked in
turn by another hook.

A concrete example is vmbus_channel->mmap_ring_buffer(), which is invoked
in turn by bin_attribute->mmap():

vmbus_channel->mmap_ring_buffer() has a signature of:

int (*mmap_ring_buffer)(struct vmbus_channel *channel,
			struct vm_area_struct *vma);

And bin_attribute->mmap() has a signature of:

	int (*mmap)(struct file *, struct kobject *,
		    const struct bin_attribute *attr,
		    struct vm_area_struct *vma);

And so compat_vma_mmap() cannot be used here for incremental conversion of
hooks from mmap() to mmap_prepare().

There are many such instances like this, where conversion to mmap_prepare
would otherwise cascade to a huge change set due to nesting of this kind.

The changes in this patch mean we could now instead convert
vmbus_channel->mmap_ring_buffer() to
vmbus_channel->mmap_prepare_ring_buffer(), and implement something like:

	struct vm_area_desc desc;
	int err;

	compat_set_desc_from_vma(&desc, file, vma);
	err = channel->mmap_prepare_ring_buffer(channel, &desc);
	if (err)
		return err;

	return __compat_vma_mmap(&desc, vma);

Allowing us to incrementally update this logic, and other logic like it.

Unfortunately, as part of this change, we need to be able to flexibly
assign to the VMA descriptor, so have to remove some of the const
declarations within the structure.

Also update the VMA tests to reflect the changes.

Link: https://lkml.kernel.org/r/24aac3019dd34740e788d169fccbe3c62781e648.1774045440.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Alexander Shishkin 
Cc: Alexandre Torgue 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Bodo Stroesser 
Cc: Christian Brauner 
Cc: Clemens Ladisch 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jonathan Corbet 
Cc: K. Y. Srinivasan 
Cc: Liam Howlett 
Cc: Long Li 
Cc: Marc Dionne 
Cc: "Martin K. Petersen" 
Cc: Maxime Coquelin 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miquel Raynal 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Ryan Roberts 
Cc: Suren Baghdasaryan 
Cc: Vignesh Raghavendra 
Cc: Wei Liu 
Signed-off-by: Andrew Morton

mm: add mmap_action_simple_ioremap()

2026-04-05T20:53:43+00:00

Currently drivers use vm_iomap_memory() as a simple helper function for
I/O remapping memory over a range starting at a specified physical address
over a specified length.

In order to utilise this from mmap_prepare, separate out the core logic
into __simple_ioremap_prep(), update vm_iomap_memory() to use it, and add
simple_ioremap_prepare() to do the same with a VMA descriptor object.

We also add MMAP_SIMPLE_IO_REMAP and relevant fields to the struct
mmap_action type to permit this operation also.

We use mmap_action_ioremap() to set up the actual I/O remap operation once
we have checked and figured out the parameters, which makes
simple_ioremap_prepare() easy to implement.

We then add mmap_action_simple_ioremap() to allow drivers to make use of
this mode.

We update the mmap_prepare documentation to describe this mode.  Finally,
we update the VMA tests to reflect this change.

Link: https://lkml.kernel.org/r/a08ef1c4542202684da63bb37f459d5dbbeddd91.1774045440.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Reviewed-by: Suren Baghdasaryan 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Alexander Shishkin 
Cc: Alexandre Torgue 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Bodo Stroesser 
Cc: Christian Brauner 
Cc: Clemens Ladisch 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jonathan Corbet 
Cc: K. Y. Srinivasan 
Cc: Liam Howlett 
Cc: Long Li 
Cc: Marc Dionne 
Cc: "Martin K. Petersen" 
Cc: Maxime Coquelin 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miquel Raynal 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Ryan Roberts 
Cc: Vignesh Raghavendra 
Cc: Wei Liu 
Signed-off-by: Andrew Morton

mm: add vm_ops->mapped hook

2026-04-05T20:53:43+00:00

Previously, when a driver needed to do something like establish a
reference count, it could do so in the mmap hook in the knowledge that the
mapping would succeed.

With the introduction of f_op->mmap_prepare this is no longer the case, as
it is invoked prior to actually establishing the mapping.

mmap_prepare is not appropriate for this kind of thing as it is called
before any merge might take place, and after which an error might occur
meaning resources could be leaked.

To take this into account, introduce a new vm_ops->mapped callback which
is invoked when the VMA is first mapped (though notably - not when it is
merged - which is correct and mirrors existing mmap/open/close behaviour).

We do better that vm_ops->open() here, as this callback can return an
error, at which point the VMA will be unmapped.

Note that vm_ops->mapped() is invoked after any mmap action is complete
(such as I/O remapping).

We intentionally do not expose the VMA at this point, exposing only the
fields that could be used, and an output parameter in case the operation
needs to update the vma->vm_private_data field.

In order to deal with stacked filesystems which invoke inner filesystem's
mmap() invocations, add __compat_vma_mapped() and invoke it on vfs_mmap()
(via compat_vma_mmap()) to ensure that the mapped callback is handled when
an mmap() caller invokes a nested filesystem's mmap_prepare() callback.

Update the mmap_prepare documentation to describe the mapped hook and make
it clear what its intended use is.

The vm_ops->mapped() call is handled by the mmap complete logic to ensure
the same code paths are handled by both the compatibility and VMA layers.

Additionally, update VMA userland test headers to reflect the change.

Link: https://lkml.kernel.org/r/4c5e98297eb0aae9565c564e1c296a112702f144.1774045440.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Alexander Shishkin 
Cc: Alexandre Torgue 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Bodo Stroesser 
Cc: Christian Brauner 
Cc: Clemens Ladisch 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jonathan Corbet 
Cc: K. Y. Srinivasan 
Cc: Liam Howlett 
Cc: Long Li 
Cc: Marc Dionne 
Cc: "Martin K. Petersen" 
Cc: Maxime Coquelin 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miquel Raynal 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Ryan Roberts 
Cc: Suren Baghdasaryan 
Cc: Vignesh Raghavendra 
Cc: Wei Liu 
Signed-off-by: Andrew Morton

mm: have mmap_action_complete() handle the rmap lock and unmap

2026-04-05T20:53:42+00:00

Rather than have the callers handle this both the rmap lock release and
unmapping the VMA on error, handle it within the mmap_action_complete()
logic where it makes sense to, being careful not to unlock twice.

This simplifies the logic and makes it harder to make mistake with this,
while retaining correct behaviour with regard to avoiding deadlocks.

Also replace the call_action_complete() function with a direct invocation
of mmap_action_complete() as the abstraction is no longer required.

Also update the VMA tests to reflect this change.

Link: https://lkml.kernel.org/r/8d1ee8ebd3542d006a47e8382fb80cf5b57ecf10.1774045440.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Alexander Shishkin 
Cc: Alexandre Torgue 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Bodo Stroesser 
Cc: Christian Brauner 
Cc: Clemens Ladisch 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jonathan Corbet 
Cc: K. Y. Srinivasan 
Cc: Liam Howlett 
Cc: Long Li 
Cc: Marc Dionne 
Cc: "Martin K. Petersen" 
Cc: Maxime Coquelin 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miquel Raynal 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Ryan Roberts 
Cc: Suren Baghdasaryan 
Cc: Vignesh Raghavendra 
Cc: Wei Liu 
Signed-off-by: Andrew Morton

mm: switch the rmap lock held option off in compat layer

2026-04-05T20:53:42+00:00

In the mmap_prepare compatibility layer, we don't need to hold the rmap
lock, as we are being called from an .mmap handler.

The .mmap_prepare hook, when invoked in the VMA logic, is called prior to
the VMA being instantiated, but the completion hook is called after the VMA
is linked into the maple tree, meaning rmap walkers can reach it.

The mmap hook does not link the VMA into the tree, so this cannot happen.

Therefore it's safe to simply disable this in the mmap_prepare
compatibility layer.

Also update VMA tests code to reflect current compatibility layer state.

[akpm@linux-foundation.org: fix comment typo, per Vlastimil]
Link: https://lkml.kernel.org/r/dda74230d26a1fcd79a3efab61fa4101dd1cac64.1774045440.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Alexander Shishkin 
Cc: Alexandre Torgue 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Bodo Stroesser 
Cc: Christian Brauner 
Cc: Clemens Ladisch 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jonathan Corbet 
Cc: K. Y. Srinivasan 
Cc: Liam Howlett 
Cc: Long Li 
Cc: Marc Dionne 
Cc: "Martin K. Petersen" 
Cc: Maxime Coquelin 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miquel Raynal 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Ryan Roberts 
Cc: Suren Baghdasaryan 
Cc: Vignesh Raghavendra 
Cc: Wei Liu 
Signed-off-by: Andrew Morton

mm: document vm_operations_struct->open the same as close()

2026-04-05T20:53:42+00:00

Describe when the operation is invoked and the context in which it is
invoked, matching the description already added for vm_op->close().

While we're here, update all outdated references to an 'area' field for
VMAs to the more consistent 'vma'.

Link: https://lkml.kernel.org/r/7d0ca833c12014320f0fa00f816f95e6e10076f2.1774045440.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Alexander Shishkin 
Cc: Alexandre Torgue 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Bodo Stroesser 
Cc: Christian Brauner 
Cc: Clemens Ladisch 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jonathan Corbet 
Cc: K. Y. Srinivasan 
Cc: Liam Howlett 
Cc: Long Li 
Cc: Marc Dionne 
Cc: "Martin K. Petersen" 
Cc: Maxime Coquelin 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miquel Raynal 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Ryan Roberts 
Cc: Suren Baghdasaryan 
Cc: Vignesh Raghavendra 
Cc: Wei Liu 
Signed-off-by: Andrew Morton

mm: various small mmap_prepare cleanups

2026-04-05T20:53:41+00:00

Patch series "mm: expand mmap_prepare functionality and usage", v4.

This series expands the mmap_prepare functionality, which is intended to
replace the deprecated f_op->mmap hook which has been the source of bugs
and security issues for some time.

This series starts with some cleanup of existing mmap_prepare logic, then
adds documentation for the mmap_prepare call to make it easier for
filesystem and driver writers to understand how it works.

It then importantly adds a vm_ops->mapped hook, a key feature that was
missing from mmap_prepare previously - this is invoked when a driver which
specifies mmap_prepare has successfully been mapped but not merged with
another VMA.

mmap_prepare is invoked prior to a merge being attempted, so you cannot
manipulate state such as reference counts as if it were a new mapping.

The vm_ops->mapped hook allows a driver to perform tasks required at this
stage, and provides symmetry against subsequent vm_ops->open,close calls.

The series uses this to correct the afs implementation which wrongly
manipulated reference count at mmap_prepare time.

It then adds an mmap_prepare equivalent of vm_iomap_memory() -
mmap_action_simple_ioremap(), then uses this to update a number of drivers.

It then splits out the mmap_prepare compatibility layer (which allows for
invocation of mmap_prepare hooks in an mmap() hook) in such a way as to
allow for more incremental implementation of mmap_prepare hooks.

It then uses this to extend mmap_prepare usage in drivers.

Finally it adds an mmap_prepare equivalent of vm_map_pages(), which lays
the foundation for future work which will extend mmap_prepare to DMA
coherent mappings.


This patch (of 21):

Rather than passing arbitrary fields, pass a vm_area_desc pointer to mmap
prepare functions to mmap prepare, and an action and vma pointer to mmap
complete in order to put all the action-specific logic in the function
actually doing the work.

Additionally, allow mmap prepare functions to return an error so we can
error out as soon as possible if there is something logically incorrect in
the input.

Update remap_pfn_range_prepare() to properly check the input range for the
CoW case.

Also remove io_remap_pfn_range_complete(), as we can simply set up the
fields correctly in io_remap_pfn_range_prepare() and use
remap_pfn_range_complete() for this.

While we're here, make remap_pfn_range_prepare_vma() a little neater, and
pass mmap_action directly to call_action_complete().

Then, update compat_vma_mmap() to perform its logic directly, as
__compat_vma_map() is not used by anything so we don't need to export it.

Also update compat_vma_mmap() to use vfs_mmap_prepare() rather than
calling the mmap_prepare op directly.

Finally, update the VMA userland tests to reflect the changes.

Link: https://lkml.kernel.org/r/cover.1774045440.git.ljs@kernel.org
Link: https://lkml.kernel.org/r/99f408e4694f44ab12bdc55fe0bd9685d3bd1117.1774045440.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Alexander Shishkin 
Cc: Alexandre Torgue 
Cc: Al Viro 
Cc: Arnd Bergmann 
Cc: Bodo Stroesser 
Cc: Christian Brauner 
Cc: Clemens Ladisch 
Cc: David Hildenbrand 
Cc: David Howells 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Haiyang Zhang 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Jonathan Corbet 
Cc: K. Y. Srinivasan 
Cc: Liam Howlett 
Cc: Long Li 
Cc: Marc Dionne 
Cc: "Martin K. Petersen" 
Cc: Maxime Coquelin 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Miquel Raynal 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Ryan Roberts 
Cc: Suren Baghdasaryan 
Cc: Vignesh Raghavendra 
Cc: Wei Liu 
Signed-off-by: Andrew Morton

mm/vma: convert __mmap_region() to use vma_flags_t

2026-04-05T20:53:41+00:00

Update the mmap() implementation logic implemented in __mmap_region() and
functions invoked by it.  The mmap_region() function converts its input
vm_flags_t parameter to a vma_flags_t value which it then passes to
__mmap_region() which uses the vma_flags_t value consistently from then
on.

As part of the change, we convert map_deny_write_exec() to using
vma_flags_t (it was incorrectly using unsigned long before), and place it
in vma.h, as it is only used internal to mm.

With this change, we eliminate the legacy is_shared_maywrite_vm_flags()
helper function which is now no longer required.

We are also able to update the MMAP_STATE() and VMG_MMAP_STATE() macros to
use the vma_flags_t value.

Finally, we update the VMA tests to reflect the change.

Link: https://lkml.kernel.org/r/1fc33a404c962f02da778da100387cc19bd62153.1774034900.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Albert Ou 
Cc: Alexander Gordeev 
Cc: Alexandre Ghiti 
Cc: Al Viro 
Cc: Anton Ivanov 
Cc: "Borislav Petkov (AMD)" 
Cc: Catalin Marinas 
Cc: Chengming Zhou 
Cc: Christian Borntraeger 
Cc: Christian Brauner 
Cc: David Hildenbrand 
Cc: Dinh Nguyen 
Cc: Heiko Carstens 
Cc: "H. Peter Anvin" 
Cc: Huacai Chen 
Cc: Ingo Molnar 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Johannes Berg 
Cc: Kees Cook 
Cc: Liam Howlett 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Nicholas Piggin 
Cc: Ondrej Mosnacek 
Cc: Palmer Dabbelt 
Cc: Paul Moore 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Russell King 
Cc: Stephen Smalley 
Cc: Suren Baghdasaryan 
Cc: Sven Schnelle 
Cc: Thomas Bogendoerfer 
Cc: Vasily Gorbik 
Cc: Vineet Gupta 
Cc: WANG Xuerui 
Cc: Will Deacon 
Cc: xu xin 
Signed-off-by: Andrew Morton

mm/vma: convert vma_modify_flags[_uffd]() to use vma_flags_t

2026-04-05T20:53:41+00:00

Update the vma_modify_flags() and vma_modify_flags_uffd() functions to
accept a vma_flags_t parameter rather than a vm_flags_t one, and propagate
the changes as needed to implement this change.

Also add vma_flags_reset_once() in replacement of vm_flags_reset_once(). We
still need to be careful here because we need to avoid tearing, so maintain
the assumption that the first system word set of flags are the only ones
that require protection from tearing, and retain this functionality.

We can copy the remainder of VMA flags above 64 bits normally. But
hopefully by the time that happens, we will have replaced the logic that
requires these WRITE_ONCE()'s with something else.

We also replace instances of vm_flags_reset() with a simple write of VMA
flags. We are no longer perform a number of checks, most notable of all the
VMA flags asserts becase:

1. We might be operating on a VMA that is not yet added to the tree.

2. We might be operating on a VMA that is now detached.

3. Really in all but core code, you should be using vma_desc_xxx().

4. Other VMA fields are manipulated with no such checks.

5. It'd be egregious to have to add variants of flag functions just to
   account for cases such as the above, especially when we don't do so for
   other VMA fields. Drivers are the problematic cases and why it was
   especially important (and also for debug as VMA locks were introduced),
   the mmap_prepare work is solving this generally.

Additionally, we can fairly safely assume by this point the soft dirty
flags are being set correctly, so it's reasonable to drop this also.

Finally, update the VMA tests to reflect this.

Link: https://lkml.kernel.org/r/51afbb2b8c3681003cc7926647e37335d793836e.1774034900.git.ljs@kernel.org
Signed-off-by: Lorenzo Stoakes (Oracle) 
Acked-by: Vlastimil Babka (SUSE) 
Cc: Albert Ou 
Cc: Alexander Gordeev 
Cc: Alexandre Ghiti 
Cc: Al Viro 
Cc: Anton Ivanov 
Cc: "Borislav Petkov (AMD)" 
Cc: Catalin Marinas 
Cc: Chengming Zhou 
Cc: Christian Borntraeger 
Cc: Christian Brauner 
Cc: David Hildenbrand 
Cc: Dinh Nguyen 
Cc: Heiko Carstens 
Cc: "H. Peter Anvin" 
Cc: Huacai Chen 
Cc: Ingo Molnar 
Cc: Jan Kara 
Cc: Jann Horn 
Cc: Johannes Berg 
Cc: Kees Cook 
Cc: Liam Howlett 
Cc: Madhavan Srinivasan 
Cc: Michael Ellerman 
Cc: Michal Hocko 
Cc: Mike Rapoport 
Cc: Nicholas Piggin 
Cc: Ondrej Mosnacek 
Cc: Palmer Dabbelt 
Cc: Paul Moore 
Cc: Pedro Falcato 
Cc: Richard Weinberger 
Cc: Russell King 
Cc: Stephen Smalley 
Cc: Suren Baghdasaryan 
Cc: Sven Schnelle 
Cc: Thomas Bogendoerfer 
Cc: Vasily Gorbik 
Cc: Vineet Gupta 
Cc: WANG Xuerui 
Cc: Will Deacon 
Cc: xu xin 
Signed-off-by: Andrew Morton