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

torture: Add lock_torture writer_fifo module parameter

2023-11-28T17:15:09+00:00

[ Upstream commit 5d248bb39fe1388943acb6510f8f48fa5570e0ec ]

This commit adds a module parameter that causes the locktorture writer
to run at real-time priority.

To use it:
insmod /lib/modules/torture.ko random_shuffle=1
insmod /lib/modules/locktorture.ko torture_type=mutex_lock rt_boost=1 rt_boost_factor=50 nested_locks=3 writer_fifo=1
													^^^^^^^^^^^^^

A predecessor to this patch has been helpful to uncover issues with the
proxy-execution series.

[ paulmck: Remove locktorture-specific code from kernel/torture.c. ]

Cc: "Paul E. McKenney" 
Cc: Josh Triplett 
Cc: Joel Fernandes 
Cc: Juri Lelli 
Cc: Valentin Schneider 
Cc: kernel-team@android.com
Signed-off-by: Dietmar Eggemann 
[jstultz: Include header change to build, reword commit message]
Signed-off-by: John Stultz 
Acked-by: Davidlohr Bueso 
Signed-off-by: Paul E. McKenney 
Stable-dep-of: cca42bd8eb1b ("rcutorture: Fix stuttering races and other issues")
Signed-off-by: Sasha Levin

smp,csd: Throw an error if a CSD lock is stuck for too long

2023-11-28T17:14:41+00:00

[ Upstream commit 94b3f0b5af2c7af69e3d6e0cdd9b0ea535f22186 ]

The CSD lock seems to get stuck in 2 "modes". When it gets stuck
temporarily, it usually gets released in a few seconds, and sometimes
up to one or two minutes.

If the CSD lock stays stuck for more than several minutes, it never
seems to get unstuck, and gradually more and more things in the system
end up also getting stuck.

In the latter case, we should just give up, so the system can dump out
a little more information about what went wrong, and, with panic_on_oops
and a kdump kernel loaded, dump a whole bunch more information about what
might have gone wrong.  In addition, there is an smp.panic_on_ipistall
kernel boot parameter that by default retains the old behavior, but when
set enables the panic after the CSD lock has been stuck for more than
the specified number of milliseconds, as in 300,000 for five minutes.

[ paulmck: Apply Imran Khan feedback. ]
[ paulmck: Apply Leonardo Bras feedback. ]

Link: https://lore.kernel.org/lkml/bc7cc8b0-f587-4451-8bcd-0daae627bcc7@paulmck-laptop/
Signed-off-by: Rik van Riel 
Signed-off-by: Paul E. McKenney 
Reviewed-by: Imran Khan 
Reviewed-by: Leonardo Bras 
Cc: Peter Zijlstra 
Cc: Valentin Schneider 
Cc: Juergen Gross 
Cc: Jonathan Corbet 
Cc: Randy Dunlap 
Signed-off-by: Sasha Levin

x86/srso: Fix vulnerability reporting for missing microcode

2023-11-20T10:56:43+00:00

[ Upstream commit dc6306ad5b0dda040baf1fde3cfd458e6abfc4da ]

The SRSO default safe-ret mitigation is reported as "mitigated" even if
microcode hasn't been updated.  That's wrong because userspace may still
be vulnerable to SRSO attacks due to IBPB not flushing branch type
predictions.

Report the safe-ret + !microcode case as vulnerable.

Also report the microcode-only case as vulnerable as it leaves the
kernel open to attacks.

Fixes: fb3bd914b3ec ("x86/srso: Add a Speculative RAS Overflow mitigation")
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Signed-off-by: Borislav Petkov (AMD) 
Acked-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/r/a8a14f97d1b0e03ec255c81637afdf4cf0ae9c99.1693889988.git.jpoimboe@kernel.org
Signed-off-by: Sasha Levin

mm, memcg: reconsider kmem.limit_in_bytes deprecation

2023-10-06T11:16:30+00:00

commit 4597648fddeadef5877610d693af11906aa666ac upstream.

This reverts commits 86327e8eb94c ("memcg: drop kmem.limit_in_bytes") and
partially reverts 58056f77502f ("memcg, kmem: further deprecate
kmem.limit_in_bytes") which have incrementally removed support for the
kernel memory accounting hard limit.  Unfortunately it has turned out that
there is still userspace depending on the existence of
memory.kmem.limit_in_bytes [1].  The underlying functionality is not
really required but the non-existent file just confuses the userspace
which fails in the result.  The patch to fix this on the userspace side
has been submitted but it is hard to predict how it will propagate through
the maze of 3rd party consumers of the software.

Now, reverting alone 86327e8eb94c is not an option because there is
another set of userspace which cannot cope with ENOTSUPP returned when
writing to the file.  Therefore we have to go and revisit 58056f77502f as
well.  There are two ways to go ahead.  Either we give up on the
deprecation and fully revert 58056f77502f as well or we can keep
kmem.limit_in_bytes but make the write a noop and warn about the fact.
This should work for both known breaking workloads which depend on the
existence but do not depend on the hard limit enforcement.

Note to backporters to stable trees.  a8c49af3be5f ("memcg: add per-memcg
total kernel memory stat") introduced in 4.18 has added memcg_account_kmem
so the accounting is not done by obj_cgroup_charge_pages directly for v1
anymore.  Prior kernels need to add it explicitly (thanks to Johannes for
pointing this out).

[akpm@linux-foundation.org: fix build - remove unused local]
Link: http://lkml.kernel.org/r/20230920081101.GA12096@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net [1]
Link: https://lkml.kernel.org/r/ZRE5VJozPZt9bRPy@dhcp22.suse.cz
Fixes: 86327e8eb94c ("memcg: drop kmem.limit_in_bytes")
Fixes: 58056f77502f ("memcg, kmem: further deprecate kmem.limit_in_bytes")
Signed-off-by: Michal Hocko 
Acked-by: Shakeel Butt 
Acked-by: Johannes Weiner 
Cc: Greg Kroah-Hartman 
Cc: Jeremi Piotrowski 
Cc: Muchun Song 
Cc: Roman Gushchin 
Cc: Tejun heo 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

memcg: drop kmem.limit_in_bytes

2023-10-06T11:16:30+00:00

commit 86327e8eb94c52eca4f93cfece2e29d1bf52acbf upstream.

kmem.limit_in_bytes (v1 way to limit kernel memory usage) has been
deprecated since 58056f77502f ("memcg, kmem: further deprecate
kmem.limit_in_bytes") merged in 5.16.  We haven't heard about any serious
users since then but it seems that the mere presence of the file is
causing more harm thatn good.  We (SUSE) have had several bug reports from
customers where Docker based containers started to fail because a write to
kmem.limit_in_bytes has failed.

This was unexpected because runc code only expects ENOENT (kmem disabled)
or EBUSY (tasks already running within cgroup).  So a new error code was
unexpected and the whole container startup failed.  This has been later
addressed by
https://github.com/opencontainers/runc/commit/52390d68040637dfc77f9fda6bbe70952423d380
so current Docker runtimes do not suffer from the problem anymore.  There
are still older version of Docker in use and likely hard to get rid of
completely.

Address this by wiping out the file completely and effectively get back to
pre 4.5 era and CONFIG_MEMCG_KMEM=n configuration.

I would recommend backporting to stable trees which have picked up
58056f77502f ("memcg, kmem: further deprecate kmem.limit_in_bytes").

[mhocko@suse.com: restore _KMEM switch case]
  Link: https://lkml.kernel.org/r/ZKe5wxdbvPi5Cwd7@dhcp22.suse.cz
Link: https://lkml.kernel.org/r/20230704115240.14672-1-mhocko@kernel.org
Signed-off-by: Michal Hocko 
Acked-by: Shakeel Butt 
Acked-by: Johannes Weiner 
Acked-by: Roman Gushchin 
Cc: Muchun Song 
Cc: Tejun Heo 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

Revert "memcg: drop kmem.limit_in_bytes"

2023-09-23T09:14:38+00:00

This reverts commit 75bb29b6c44f486e9bd048759669c205dccb2048 which is
commit 86327e8eb94c52eca4f93cfece2e29d1bf52acbf upstream.

It breaks existing runc systems, as the tool always thinks the file
should be present.

Reported-by: Jeremi Piotrowski 
Link: https://lore.kernel.org/r/20230920081101.GA12096@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net
Cc: Michal Hocko 
Cc: Shakeel Butt 
Cc: Johannes Weiner 
Cc: Roman Gushchin 
Cc: Muchun Song 
Cc: Tejun Heo 
Cc: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

memcg: drop kmem.limit_in_bytes

2023-09-19T10:30:11+00:00

commit 86327e8eb94c52eca4f93cfece2e29d1bf52acbf upstream.

kmem.limit_in_bytes (v1 way to limit kernel memory usage) has been
deprecated since 58056f77502f ("memcg, kmem: further deprecate
kmem.limit_in_bytes") merged in 5.16.  We haven't heard about any serious
users since then but it seems that the mere presence of the file is
causing more harm thatn good.  We (SUSE) have had several bug reports from
customers where Docker based containers started to fail because a write to
kmem.limit_in_bytes has failed.

This was unexpected because runc code only expects ENOENT (kmem disabled)
or EBUSY (tasks already running within cgroup).  So a new error code was
unexpected and the whole container startup failed.  This has been later
addressed by
https://github.com/opencontainers/runc/commit/52390d68040637dfc77f9fda6bbe70952423d380
so current Docker runtimes do not suffer from the problem anymore.  There
are still older version of Docker in use and likely hard to get rid of
completely.

Address this by wiping out the file completely and effectively get back to
pre 4.5 era and CONFIG_MEMCG_KMEM=n configuration.

I would recommend backporting to stable trees which have picked up
58056f77502f ("memcg, kmem: further deprecate kmem.limit_in_bytes").

[mhocko@suse.com: restore _KMEM switch case]
  Link: https://lkml.kernel.org/r/ZKe5wxdbvPi5Cwd7@dhcp22.suse.cz
Link: https://lkml.kernel.org/r/20230704115240.14672-1-mhocko@kernel.org
Signed-off-by: Michal Hocko 
Acked-by: Shakeel Butt 
Acked-by: Johannes Weiner 
Acked-by: Roman Gushchin 
Cc: Muchun Song 
Cc: Tejun Heo 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Greg Kroah-Hartman

Documentation: devices.txt: Fix minors for ttyCPM*

2023-09-13T07:53:44+00:00

[ Upstream commit 4b91dcc2f601cc2098b5fead71344704ddcff8b7 ]

ttyCPM* devices belong to CPM_UART driver at the first place
and that driver provides 6 ports.

Fixes: e29c3f81eb89 ("Documentation: devices.txt: reconcile serial/ucc_uart minor numers")
Cc: Randy Dunlap 
Signed-off-by: Christophe Leroy 
Reviewed-by: Randy Dunlap 
Link: https://lore.kernel.org/r/27d7124cf86157e2a27c2b039e769041994d3f22.1691992627.git.christophe.leroy@csgroup.eu
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Documentation: devices.txt: Remove ttySIOC*

2023-09-13T07:53:44+00:00

[ Upstream commit 27681960f05515555441d7bf58d565cbc68137f3 ]

IOC3 serial driver was removed, remove associated devices
from documentation.

Fixes: 9c860e4cf708 ("tty/serial: remove the ioc3_serial driver")
Cc: Christoph Hellwig 
Signed-off-by: Christophe Leroy 
Link: https://lore.kernel.org/r/f13b5c64f8cb6d8f2357d7be14397676b27ac2a2.1691992627.git.christophe.leroy@csgroup.eu
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin

Documentation: devices.txt: Remove ttyIOC*

2023-09-13T07:53:44+00:00

[ Upstream commit e327fdc262345ca37b358a51ff0c0046ab1b8d15 ]

IOC4 serial driver was removed, remove associated devices
from documentation.

Fixes: a017ef17cfd8 ("tty/serial: remove the ioc4_serial driver")
Cc: Christoph Hellwig 
Signed-off-by: Christophe Leroy 
Link: https://lore.kernel.org/r/b5deb1222eb92017f0efe5b5cae127ac11983b3d.1691992627.git.christophe.leroy@csgroup.eu
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Sasha Levin