-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I'm announcing the release of the 4.14.238 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.14.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Thanks,
Sasha
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAmDcdGkACgkQ3qZv95d3
LNycCg/+KmyrChXSyZIUeUT5UVNeEEaR1zjJLORWvuHehW9Q4hcnvRlXuEGO7q5g
U+8XHm8H+hIjkwfpLmim1Jn6hMTx9P8fZ0t45YXkkXmPBoMCSySEiPpAKMaDQPxs
EU5ULrkNtTXiengdR6w13ayuSMSIacPyXFmY20OdzAnhtiXwgv5s9HgRDkcDZomh
M/Fqux6b16fXDS12qUdI7RbNUyJnWkBOm9KpE/zAzyMQlj0r/NUs1T02JS8/gWww
SfwgECLfvoFPNuxXI2Y9WEKQ40xx6Hb/Fzatvs18WjwLC+SvUfwPKlOyP6sogq+N
2kn7eFygkZzyDCL8GYv3ZVd/O8Km4kMWWthehJ/SD6MEzbIVlZmjCISivYA9fZVf
rLqWAdymiRDhJqak1pwsW8fVOBxJJYLMUJy3tv5Zjcg1bBWPrE4VufsntZt9YVdr
evpLVKeOU8p6aCdy7FwN+b/dBPriZt6oesNkhO3OMfW73FBesp8bgdH4Rhs9ISkv
lXb0mjYmE2ZJ6S+vKnRuHVDoiOc8u9fZnQqrCwNzI0QFltCYU9AZGI3cbmVH5a/h
/1TFCC0uVpwWquFuszkfvyItjFRpZhhjYsMZOB7jzCR/EDJakx2S5qsCMNW3bdQt
W5emHwENNkmlLEuRQwuoAbwfOPqV8IK9nO5goh0Sg4G45OzXU20=
=KrR2
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I'm announcing the release of the 4.19.196 kernel.
All users of the 4.19 kernel series must upgrade.
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.19.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Thanks,
Sasha
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAmDcdF8ACgkQ3qZv95d3
LNyFdxAAnB9VMQ9XCMIW0KFIuc84l34tHe7bexocQHEGxWFhsJEnyNzGGcZxlY7G
XKlHXzh7QWPWuf82jt7fNSrctyAO6Kun3VF5ucGsixgCStb+0byHHL6F4N9eEdPH
v2h8HA46OTGShHBLsMsFsLLVY335WNSz+YnI3tXmHuMcgckUPDYoS2Zh0GFJTrsF
jW4YCheGMtcJHU80D8pUyEucb4GdyasNHkwW2d5vn7PhKNtr4Tv2rRjF2/EHWdog
RZ18hHzJRI/DwGrVwLXy8hcaVG8qp7b1Se5lRIZIFaYxRjXs7vpqFngabXoq8K1l
Q2OaQNvlKVDNBJnnSumu1mFxZgWdixQ3i9qLVhSvS+yAilP45cHZkkGee+6uchJE
vJc4WVV08NTfUTbPBMdCkHCfLRai06qdkOxf9l4YX5Phs86gi6SCbaKZMA5mUpWr
bw9KJi5UgQLYfETzagJmncCm+BqGEnVzMGn98kUgAcxLWIMerEg7AaIL0Jul0Gig
GElwsTo1O4byu8Ee0sF9nppW6iB+FlBqOVepwy+d7RocaihKyssm87Gwvoy+Py8b
4yH1MGFGP2Un0SyKGUz7t3RY/hD8glmILHs/l+1UTeb8RkgZDy3iw+Cbrcu0CWQq
JM86nlanh0UyklQ2lM51DIZqSWs5J6BHyJyuGNs6CrbjltlGbHo=
=TGQ2
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I'm announcing the release of the 5.4.129 kernel.
All users of the 5.4 kernel series must upgrade.
The updated 5.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.4.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Thanks,
Sasha
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAmDcdE8ACgkQ3qZv95d3
LNwMew/9HLxjRRYhe6jCrc66+H2ekkh7TqhkWrgr4zEzYg2k4Xb34MKsq6/jowkw
BuAQdY2R1Hrg3UgjmXMnYw6aCVOyOFbbsmK1A07CjW36a4IFrKaKLmdL0nKJl5Vr
V+y2v8f9uJfJ9ceN6VdUR7hH1bJLRuoTv0klKOBcGEvvInZiZ2qxzLujVCWYD8CF
a8xwvtzt/QWAsPrfMFPa6voLZkLPfNu5sYiqJsboXyt7a9XJYQZ1sJBDfb3HK+uo
c0rPcrbQTthmjYmmfFpU6EfBpRBqHui3aWPOCR4OFRtw/1KcB3NIUqkNyTLXxIWB
7OSfLESDXTKCd+RX+tctOCaIaMtRWT/o7RqQy/knI6VXpJk42o/w9tmMVxIU1zr3
v+kqJd7wQ/B03zei4XhZBTnPhT2tOFNtMFzYvagGyJXR9u0UjDK4Jf8i8ppFOJD5
USkl54p8xzHqnoSHV4SidmiQr6adUlnZhJFcr/0ODTd74+7+08KjhIiNbO+HY0lx
EKrW7lmcXCbr5zvHHJMODbYkgYf0iQ/RawRxU/VZ4GQzFT+92ep0qKENDcDTmE8F
9OBIgdOw6kt7p41LM/H6XxHQMLRnVne/2btUxmg7nWfESTyn+2iPp749X2qhuPeW
ufUQVGqajlQIklGVVcG0sHxfOFjvZEqNQfqEdcP5mK3g0RoIhPw=
=k7Vi
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
I'm announcing the release of the 5.10.47 kernel.
All users of the 5.10 kernel series must upgrade.
The updated 5.10.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-5.10.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Thanks,
Sasha
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE4n5dijQDou9mhzu83qZv95d3LNwFAmDcdEIACgkQ3qZv95d3
LNyCpw/+K96+1ahen7kcs2rt3783nti4S33dpn7vKXeD6B2i5IhdqlFk3aCDqshh
aMoy8kNgtXb90GdgPobfWQGJt+1MMBfgxDd38VhqdBovOM1JNkCrVfrrv1lPmw/C
QUAiwxHeOd7why2UUMJaXb7xsAv/ircK+zi5sVImpf6NCgXeKaJOB74kFYH7VI+R
6LRPBWuOpDc3As1I1MOoC0tIXWI7YCictecr1LTDi75REu58x64ty0HN/b6Gj/Io
Y3EGlTe8GRIsChDAArYScCTYCixyN2pj/Loc7vlZUCHb3puQShO4bSNyPsykYxfR
HMB5F5Jf1HaKN0im5rel1sKd2hn0/tWwla8orRIWubXhBPrSxqsJJn642h2o7ZZN
8axd1K8Gd+zpqHZjjl4mYtcJo3A7Cj71r9XGVmfVMowTLs5wiX/30h98PfevlGGv
mj+ybjue3Gypk3ZTaHRifRLDh5KzTJNSMxm1YJcJ7IhsTBsgQXDMuInSgkSG32yz
Ggk/xj+GU4ob43EU92hSc4Cbh6zSUnQ2ac5vQAeKyYqKtAmEGL+hCf3Mnatk0ItS
UUnwXPflRB1eCbI3JFYZ5A0Igp+60WMARjRWb/MbWX1kwMOKlZKl9fUjfeJV6b3e
xURPJruLnZelsIXS8L9Nx1SWu51HnVhhf7D/58CDByqnBCq6oaQ=
=b4hI
-----END PGP SIGNATURE-----
The tgid_map array records a mapping from pid to tgid, where the index
of an entry within the array is the pid & the value stored at that index
is the tgid.
The saved_tgids_next() function iterates over pointers into the tgid_map
array & dereferences the pointers which results in the tgid, but then it
passes that dereferenced value to trace_find_tgid() which treats it as a
pid & does a further lookup within the tgid_map array. It seems likely
that the intent here was to skip over entries in tgid_map for which the
recorded tgid is zero, but instead we end up skipping over entries for
which the thread group leader hasn't yet had its own tgid recorded in
tgid_map.
A minimal fix would be to remove the call to trace_find_tgid, turning:
if (trace_find_tgid(*ptr))
into:
if (*ptr)
..but it seems like this logic can be much simpler if we simply let
seq_read() iterate over the whole tgid_map array & filter out empty
entries by returning SEQ_SKIP from saved_tgids_show(). Here we take that
approach, removing the incorrect logic here entirely.
Signed-off-by: Paul Burton <paulburton(a)google.com>
Fixes: d914ba37d714 ("tracing: Add support for recording tgid of tasks")
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Joel Fernandes <joelaf(a)google.com>
Cc: <stable(a)vger.kernel.org>
---
kernel/trace/trace.c | 38 +++++++++++++-------------------------
1 file changed, 13 insertions(+), 25 deletions(-)
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index d23a09d3eb37b..9570667310bcc 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -5608,37 +5608,20 @@ static const struct file_operations tracing_readme_fops = {
static void *saved_tgids_next(struct seq_file *m, void *v, loff_t *pos)
{
- int *ptr = v;
+ int pid = ++(*pos);
- if (*pos || m->count)
- ptr++;
-
- (*pos)++;
-
- for (; ptr <= &tgid_map[PID_MAX_DEFAULT]; ptr++) {
- if (trace_find_tgid(*ptr))
- return ptr;
- }
+ if (pid > PID_MAX_DEFAULT)
+ return NULL;
- return NULL;
+ return &tgid_map[pid];
}
static void *saved_tgids_start(struct seq_file *m, loff_t *pos)
{
- void *v;
- loff_t l = 0;
-
- if (!tgid_map)
+ if (!tgid_map || *pos > PID_MAX_DEFAULT)
return NULL;
- v = &tgid_map[0];
- while (l <= *pos) {
- v = saved_tgids_next(m, v, &l);
- if (!v)
- return NULL;
- }
-
- return v;
+ return &tgid_map[*pos];
}
static void saved_tgids_stop(struct seq_file *m, void *v)
@@ -5647,9 +5630,14 @@ static void saved_tgids_stop(struct seq_file *m, void *v)
static int saved_tgids_show(struct seq_file *m, void *v)
{
- int pid = (int *)v - tgid_map;
+ int *entry = (int *)v;
+ int pid = entry - tgid_map;
+ int tgid = *entry;
+
+ if (tgid == 0)
+ return SEQ_SKIP;
- seq_printf(m, "%d %d\n", pid, trace_find_tgid(pid));
+ seq_printf(m, "%d %d\n", pid, tgid);
return 0;
}
base-commit: 62fb9874f5da54fdb243003b386128037319b219
--
2.32.0.93.g670b81a890-goog
Hello,
I am encountering an issue where my system freezes entirely after a
random but short time after boot-up: the computer does not react to any
user input, be it mouse, keyboard or plugging-unplugging peripherals.
The image on screen remains still and does not go black. Any sound that
was playing at the moment of the freeze loops indefinitely with a period
of around 1s. I have the intuition that the issue is sound related
because of that.
Some additional information with this issue
- Only happens only with the latest stable releases of the kernel:
5.12.9 and 5.12.10 . 5.12.8 does not have this issue. I have not
tested other kernel version, e.g. LTS 5.10 , to see if it's a change
that got back-ported.
- Happens in Gentoo and archlinux with their respective official kernel
binary release. But also self built, with Archlinux's upstream .config
file and also stripped down versions (please find an example .config
attached as config-stripped). Happens on Gnome on Wayland and Xorg and
on LXQt (Openbox).
- The output of `journalctl` stops before the freeze happens, I suppose
it's because nothing can be saved in the disk when it happens. Please
find the output of journalctl for a boot where the freeze happens
attached to this mail as `journaloutput`. This should give all the
necessary information about my system. I just realized that I have extra
boot kernel parameters, maybe removing the extra ones works around the
issue and would help pinpoint the issue. I will report back if I have
any extra information
Given the above information I believe this issue is best reported to
you. I unfortunately do not have more information to report for proper
pinpointing and I am willing to work from your directed feedback. My
kernel knowledge is limited but I can probably deal with technical
requests from you given enough time and documentation.
Thank you for your help and I hope I am not wasting your time with
something
Kind regards,
Adel KARA SLIMANE
I noticed that the reverts below were made to the 4.9 and 5.4
branches, but I do not see them elsewhere (other stable branches,
latest, etc). The original commits which were subsequently reverted on
the 4.9 and 5.4 branches were causing our cable-modem drivers memremap
calls to fail so we need these reverted everywhere like they are on
the 4.9 and 5.4 branches. Is that the plan?
-Tim
ommit 6b183fbf18b91bc3c1fd02d5a48f7bc447d900cedrivers/of/fdt.c
Author: Quentin Perret <qperret(a)google.com>
Date: Wed May 12 12:28:53 2021 +0000
Revert "fdt: Properly handle "no-map" field in the memory region"
This reverts commit fb326c6ce0dcbb6273202c6e012759754ec8538d.
It is not really a fix, and the backport misses dependencies, which
breaks existing platforms.
Reported-by: Alexandre TORGUE <alexandre.torgue(a)foss.st.com>
Signed-off-by: Quentin Perret <qperret(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
commit 66b8853dfa3cfbbe6c3ab643b6989377ad16662a
Author: Quentin Perret <qperret(a)google.com>
Date: Wed May 12 12:28:52 2021 +0000
Revert "of/fdt: Make sure no-map does not remove already reserved regions"
This reverts commit 3cbd3038c9155038020560729cde50588311105d.
It is not really a fix, and the backport misses dependencies, which
breaks existing platforms.
Reported-by: Alexandre TORGUE <alexandre.torgue(a)foss.st.com>
Signed-off-by: Quentin Perret <qperret(a)google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
commit 3cbd3038c9155038020560729cde50588311105d
Author: Nicolas Boichat <drinkcat(a)chromium.org>
Date: Fri Jan 15 11:45:44 2021 +0000
of/fdt: Make sure no-map does not remove already reserved regions
[ Upstream commit 8a5a75e5e9e55de1cef5d83ca3589cb4899193ef ]
If the device tree is incorrectly configured, and attempts to
define a "no-map" reserved memory that overlaps with the kernel
data/code, the kernel would crash quickly after boot, with no
obvious clue about the nature of the issue.
For example, this would happen if we have the kernel mapped at
these addresses (from /proc/iomem):
40000000-41ffffff : System RAM
40080000-40dfffff : Kernel code
40e00000-411fffff : reserved
41200000-413e0fff : Kernel data
And we declare a no-map shared-dma-pool region at a fixed address
within that range:
mem_reserved: mem_region {
compatible = "shared-dma-pool";
reg = <0 0x40000000 0 0x01A00000>;
no-map;
};
To fix this, when removing memory regions at early boot (which is
what "no-map" regions do), we need to make sure that the memory
is not already reserved. If we do, __reserved_mem_reserve_reg
will throw an error:
[ 0.000000] OF: fdt: Reserved memory: failed to reserve memory
for node 'mem_region': base 0x0000000040000000, size 26 MiB
and the code that will try to use the region should also fail,
later on.
We do not do anything for non-"no-map" regions, as memblock
explicitly allows reserved regions to overlap, and the commit
that this fixes removed the check for that precise reason.
[ qperret: fixed conflicts caused by the usage of memblock_mark_nomap ]
Fixes: 094cb98179f19b7 ("of/fdt: memblock_reserve /memreserve/
regions in the case of partial overlap")
Signed-off-by: Nicolas Boichat <drinkcat(a)chromium.org>
Reviewed-by: Stephen Boyd <swboyd(a)chromium.org>
Signed-off-by: Quentin Perret <qperret(a)google.com>
Link: https://lore.kernel.org/r/20210115114544.1830068-3-qperret@google.com
Signed-off-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
commit fb326c6ce0dcbb6273202c6e012759754ec8538d
Author: KarimAllah Ahmed <karahmed(a)amazon.de>
Date: Fri Jan 15 11:45:43 2021 +0000
fdt: Properly handle "no-map" field in the memory region
[ Upstream commit 86588296acbfb1591e92ba60221e95677ecadb43 ]
Mark the memory region with NOMAP flag instead of completely removing it
from the memory blocks. That makes the FDT handling consistent with the EFI
memory map handling.
Cc: Rob Herring <robh+dt(a)kernel.org>
Cc: Frank Rowand <frowand.list(a)gmail.com>
Cc: devicetree(a)vger.kernel.org
Cc: linux-kernel(a)vger.kernel.org
Signed-off-by: KarimAllah Ahmed <karahmed(a)amazon.de>
Signed-off-by: Quentin Perret <qperret(a)google.com>
Link: https://lore.kernel.org/r/20210115114544.1830068-2-qperret@google.com
Signed-off-by: Rob Herring <robh(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
--
This electronic communication and the information and any files transmitted
with it, or attached to it, are confidential and are intended solely for
the use of the individual or entity to whom it is addressed and may contain
information that is confidential, legally privileged, protected by privacy
laws, or otherwise restricted from disclosure to anyone else. If you are
not the intended recipient or the person responsible for delivering the
e-mail to the intended recipient, you are hereby notified that any use,
copying, distributing, dissemination, forwarding, printing, or copying of
this e-mail is strictly prohibited. If you received this e-mail in error,
please return the e-mail to the sender, delete it from your computer, and
destroy any printed copy of it.