linux-stable.git/Documentation/admin-guide, branch linux-5.11.y

iommu/dma: Resurrect the "forcedac" option

2021-05-14T08:50:00+00:00

[ Upstream commit 3542dcb15cef66c0b9e6c3b33168eb657e0d9520 ]

In converting intel-iommu over to the common IOMMU DMA ops, it quietly
lost the functionality of its "forcedac" option. Since this is a handy
thing both for testing and for performance optimisation on certain
platforms, reimplement it under the common IOMMU parameter namespace.

For the sake of fixing the inadvertent breakage of the Intel-specific
parameter, remove the dmar_forcedac remnants and hook it up as an alias
while documenting the transition to the new common parameter.

Fixes: c588072bba6b ("iommu/vt-d: Convert intel iommu driver to the iommu ops")
Signed-off-by: Robin Murphy 
Acked-by: Lu Baolu 
Reviewed-by: John Garry 
Link: https://lore.kernel.org/r/7eece8e0ea7bfbe2cd0e30789e0d46df573af9b0.1614961776.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel 
Signed-off-by: Sasha Levin

drivers/base/memory: don't store phys_device in memory blocks

2021-03-17T16:11:33+00:00

[ Upstream commit e9a2e48e8704c9d20a625c6f2357147d03ea7b97 ]

No need to store the value for each and every memory block, as we can
easily query the value at runtime.  Reshuffle the members to optimize the
memory layout.  Also, let's clarify what the interface once was used for
and why it's legacy nowadays.

"phys_device" was used on s390x in older versions of lsmem[2]/chmem[3],
back when they were still part of s390x-tools.  They were later replaced
by the variants in linux-utils.  For example, RHEL6 and RHEL7 contain
lsmem/chmem from s390-utils.  RHEL8 switched to versions from util-linux
on s390x [4].

"phys_device" was added with sysfs support for memory hotplug in commit
3947be1969a9 ("[PATCH] memory hotplug: sysfs and add/remove functions") in
2005.  It always returned 0.

s390x started returning something != 0 on some setups (if sclp.rzm is set
by HW) in 2010 via commit 57b552ba0b2f ("memory hotplug/s390: set
phys_device").

For s390x, it allowed for identifying which memory block devices belong to
the same storage increment (RZM).  Only if all memory block devices
comprising a single storage increment were offline, the memory could
actually be removed in the hypervisor.

Since commit e5d709bb5fb7 ("s390/memory hotplug: provide
memory_block_size_bytes() function") in 2013 a memory block device spans
at least one storage increment - which is why the interface isn't really
helpful/used anymore (except by old lsmem/chmem tools).

There were once RFC patches to make use of "phys_device" in ACPI context;
however, the underlying problem could be solved using different interfaces
[1].

[1] https://patchwork.kernel.org/patch/2163871/
[2] https://github.com/ibm-s390-tools/s390-tools/blob/v2.1.0/zconf/lsmem
[3] https://github.com/ibm-s390-tools/s390-tools/blob/v2.1.0/zconf/chmem
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1504134

Link: https://lkml.kernel.org/r/20210201181347.13262-2-david@redhat.com
Signed-off-by: David Hildenbrand 
Acked-by: Michal Hocko 
Reviewed-by: Oscar Salvador 
Cc: Dave Hansen 
Cc: Greg Kroah-Hartman 
Cc: Gerald Schaefer 
Cc: Jonathan Corbet 
Cc: "Rafael J. Wysocki" 
Cc: Mauro Carvalho Chehab 
Cc: Ilya Dryomov 
Cc: Vaibhav Jain 
Cc: Tom Rix 
Cc: Geert Uytterhoeven 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Sasha Levin

mm/vmscan: restore zone_reclaim_mode ABI

2021-03-04T11:15:35+00:00

commit 519983645a9f2ec339cabfa0c6ef7b09be985dd0 upstream.

I went to go add a new RECLAIM_* mode for the zone_reclaim_mode sysctl.
Like a good kernel developer, I also went to go update the
documentation.  I noticed that the bits in the documentation didn't
match the bits in the #defines.

The VM never explicitly checks the RECLAIM_ZONE bit.  The bit is,
however implicitly checked when checking 'node_reclaim_mode==0'.  The
RECLAIM_ZONE #define was removed in a cleanup.  That, by itself is fine.

But, when the bit was removed (bit 0) the _other_ bit locations also got
changed.  That's not OK because the bit values are documented to mean
one specific thing.  Users surely do not expect the meaning to change
from kernel to kernel.

The end result is that if someone had a script that did:

	sysctl vm.zone_reclaim_mode=1

it would have gone from enabling node reclaim for clean unmapped pages
to writing out pages during node reclaim after the commit in question.
That's not great.

Put the bits back the way they were and add a comment so something like
this is a bit harder to do again.  Update the documentation to make it
clear that the first bit is ignored.

Link: https://lkml.kernel.org/r/20210219172555.FF0CDF23@viggo.jf.intel.com
Signed-off-by: Dave Hansen 
Fixes: 648b5cf368e0 ("mm/vmscan: remove unused RECLAIM_OFF/RECLAIM_ZONE")
Reviewed-by: Ben Widawsky 
Reviewed-by: Oscar Salvador 
Acked-by: David Rientjes 
Acked-by: Christoph Lameter 
Cc: Alex Shi 
Cc: Daniel Wagner 
Cc: "Tobin C. Harding" 
Cc: Christoph Lameter 
Cc: Andrew Morton 
Cc: Huang Ying 
Cc: Dan Williams 
Cc: Qian Cai 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

perf/arm-cmn: Fix PMU instance naming

2021-03-04T11:14:18+00:00

[ Upstream commit 79d7c3dca99fa96033695ddf5d495b775a3a137b ]

Although it's neat to avoid the suffix for the typical case of a
single PMU, it means systems with multiple CMN instances end up with
inconsistent naming. I think it also breaks perf tool's "uncore alias"
logic if the common instance prefix is also the full name of one.

Avoid any surprises by not trying to be clever and simply numbering
every instance, even when it might technically prove redundant.

Fixes: 0ba64770a2f2 ("perf: Add Arm CMN-600 PMU driver")
Signed-off-by: Robin Murphy 
Link: https://lore.kernel.org/r/649a2281233f193d59240b13ed91b57337c77b32.1611839564.git.robin.murphy@arm.com
Signed-off-by: Will Deacon 
Signed-off-by: Sasha Levin

Merge branch 'for-5.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup

2021-02-13T20:25:42+00:00

Pull cgroup fixes from Tejun Heo:
 "Two cgroup fixes:

   - fix a NULL deref when trying to poll PSI in the root cgroup

   - fix confusing controller parsing corner case when mounting cgroup
     v1 hierarchies

  And doc / maintainer file updates"

* 'for-5.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cgroup: update PSI file description in docs
  cgroup: fix psi monitor for root cgroup
  MAINTAINERS: Update my email address
  MAINTAINERS: Remove stale URLs for cpuset
  cgroup-v1: add disabled controller check in cgroup1_parse_param()

Merge tag 'core_urgent_for_v5.11_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2021-02-07T18:16:24+00:00

Pull syscall entry fixes from Borislav Petkov:

 - For syscall user dispatch, separate prctl operation from syscall
   redirection range specification before the API has been made official
   in 5.11.

 - Ensure tasks using the generic syscall code do trap after returning
   from a syscall when single-stepping is requested.

* tag 'core_urgent_for_v5.11_rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  entry: Use different define for selector variable in SUD
  entry: Ensure trap after single-step on system call return

entry: Use different define for selector variable in SUD

2021-02-05T23:21:42+00:00

Michael Kerrisk suggested that, from an API perspective, it is a bad
idea to share the PR_SYS_DISPATCH_ defines between the prctl operation
and the selector variable.

Therefore, define two new constants to be used by SUD's selector variable
and update the corresponding documentation and test cases.

While this changes the API syscall user dispatch has never been part of a
Linux release, it will show up for the first time in 5.11.

Suggested-by: Michael Kerrisk (man-pages) 
Signed-off-by: Gabriel Krisman Bertazi 
Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/20210205184321.2062251-1-krisman@collabora.com

Merge tag 'media/v5.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media

2021-02-01T19:15:57+00:00

Pull media fixes from Mauro Carvalho Chehab:
 "The rockship rkisp1 driver will be promoted from staging in 5.11.

  While not too late, do a few uAPI changes which are needed to better
  support its functionalities"

* tag 'media/v5.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  media: rockchip: rkisp1: extend uapi array sizes
  media: rockchip: rkisp1: carry ip version information
  media: rockchip: rkisp1: reduce number of histogram grid elements in uapi
  media: rkisp1: stats: mask the hist_bins values
  media: rkisp1: stats: remove a wrong cast to u8
  media: rkisp1: uapi: change hist_bins array type from __u16 to __u32

media: rockchip: rkisp1: carry ip version information

2021-01-28T10:31:08+00:00

The IP block evolved from its rk3288/rk3399 base and the vendor
designates them with a numerical version. rk3399 for example
is designated V10 probably meaning V1.0.

There doesn't seem to be an actual version register we could read that
information from, so allow the match_data to carry that information
for future differentiation.

Also carry that information in the hw_revision field of the media-
controller API, so that userspace also has access to that.

The added versions are:
- V10: at least rk3288 + rk3399
- V11: seemingly unused as of now, but probably appeared in some soc
- V12: at least rk3326 + px30
- V13: at least rk1808

[fix checkpatch warning don't use multiple blank lines]

Signed-off-by: Heiko Stuebner 
Signed-off-by: Dafna Hirschfeld 
Reviewed-by: Ezequiel Garcia 
Acked-by: Helen Koike 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab

dm integrity: conditionally disable "recalculate" feature

2021-01-21T20:05:21+00:00

Otherwise a malicious user could (ab)use the "recalculate" feature
that makes dm-integrity calculate the checksums in the background
while the device is already usable. When the system restarts before all
checksums have been calculated, the calculation continues where it was
interrupted even if the recalculate feature is not requested the next
time the dm device is set up.

Disable recalculating if we use internal_hash or journal_hash with a
key (e.g. HMAC) and we don't have the "legacy_recalculate" flag.

This may break activation of a volume, created by an older kernel,
that is not yet fully recalculated -- if this happens, the user should
add the "legacy_recalculate" flag to constructor parameters.

Cc: stable@vger.kernel.org
Signed-off-by: Mikulas Patocka 
Reported-by: Daniel Glockner 
Signed-off-by: Mike Snitzer