Re: 5.12-rc1 regression: freezing iou-mgr/wrk failed
I tried 29be7fc03d ("io_uring: ensure that threads freeze on suspend")
and it seems to work OK. The system suspends fine and no errors are
printed to the kernel log.
I am using Gentoo on the machine in question.
I didn't test the other patches you supplied. Let me know if there's
anything you would like me to test.
Thanks,
Alex.
5.12-rc1 regression: freezing iou-mgr/wrk failed
Hi,
On Linux 5.12-rc1, I am unable to suspend to RAM. The system freezes for
about 40 seconds and then continues operation. The following messages
are printed to the kernel log:
[ 240.650300] PM: suspend entry (deep)
[ 240.650748] Filesystems sync: 0.000 seconds
[ 240.725605] Freezing user space processes ...
[ 260.739483] Freezing of tasks failed after 20.013 seconds (3 tasks refusing
to freeze, wq_busy=0):
[ 260.739497] task:iou-mgr-446 state:S stack:0 pid: 516 ppid: 439
flags:0x4224
[ 260.739504] Call Trace:
[ 260.739507] ? sysvec_apic_timer_interrupt+0xb/0x81
[ 260.739515] ? pick_next_task_fair+0x197/0x1cde
[ 260.739519] ? sysvec_reschedule_ipi+0x2f/0x6a
[ 260.739522] ? asm_sysvec_reschedule_ipi+0x12/0x20
[ 260.739525] ? __schedule+0x57/0x6d6
[ 260.739529] ? del_timer_sync+0xb9/0x115
[ 260.739533] ? schedule+0x63/0xd5
[ 260.739536] ? schedule_timeout+0x219/0x356
[ 260.739540] ? __next_timer_interrupt+0xf1/0xf1
[ 260.739544] ? io_wq_manager+0x73/0xb1
[ 260.739549] ? io_wq_create+0x262/0x262
[ 260.739553] ? ret_from_fork+0x22/0x30
[ 260.739557] task:iou-mgr-517 state:S stack:0 pid: 522 ppid: 439
flags:0x4224
[ 260.739561] Call Trace:
[ 260.739563] ? sysvec_apic_timer_interrupt+0xb/0x81
[ 260.739566] ? pick_next_task_fair+0x16f/0x1cde
[ 260.739569] ? sysvec_apic_timer_interrupt+0xb/0x81
[ 260.739571] ? asm_sysvec_apic_timer_interrupt+0x12/0x20
[ 260.739574] ? __schedule+0x5b7/0x6d6
[ 260.739578] ? del_timer_sync+0x70/0x115
[ 260.739581] ? schedule_timeout+0x211/0x356
[ 260.739585] ? __next_timer_interrupt+0xf1/0xf1
[ 260.739588] ? io_wq_check_workers+0x15/0x11f
[ 260.739592] ? io_wq_manager+0x69/0xb1
[ 260.739596] ? io_wq_create+0x262/0x262
[ 260.739600] ? ret_from_fork+0x22/0x30
[ 260.739603] task:iou-wrk-517 state:S stack:0 pid: 523 ppid: 439
flags:0x4224
[ 260.739607] Call Trace:
[ 260.739609] ? __schedule+0x5b7/0x6d6
[ 260.739614] ? schedule+0x63/0xd5
[ 260.739617] ? schedule_timeout+0x219/0x356
[ 260.739621] ? __next_timer_interrupt+0xf1/0xf1
[ 260.739624] ? task_thread.isra.0+0x148/0x3af
[ 260.739628] ? task_thread_unbound+0xa/0xa
[ 260.739632] ? task_thread_bound+0x7/0x7
[ 260.739636] ? ret_from_fork+0x22/0x30
[ 260.739647] OOM killer enabled.
[ 260.739648] Restarting tasks ... done.
[ 260.740077] PM: suspend exit
and then a set of similar messages except with s2idle instead of deep.
Reverting 5695e51619 ("Merge tag 'io_uring-worker.v3-2021-02-25' of
git://git.kernel.dk/linux-block") appears to resolve the issue. I have
not yet bisected further. Let me know which troubleshooting steps I
should perform next.
Thanks,
Alex.
Re: [PATCH] proc_sysctl: clamp sizes using table->maxlen
Excerpts from Christoph Hellwig's message of February 16, 2021 3:47 am: > How do these maxlen = 0 entries even survive the sysctl_check_table > check? maxlen!=0 is only checked for "default" handlers, e.g. proc_dostring, proc_dointvec. it is not checked for non-default handlers, because some of them use fixed lengths. my patch is not correct though because some drivers neither set proper maxlen nor use memcpy themselves; instead, they construct a ctl_table on the stack and call proc_*. > Please split this into one patch each each subsystem that sets maxlen > to 0 and the actual change to proc_sysctl.c. I will do this with a new patch version once I figure out a way to comprehensively fix all the drivers setting bogus values for maxlen (sometimes maxlen=0 is valid if only blank writes are permitted, and some drivers set random values which have no relation to the actual read size). Thank you for the review.
Re: [PATCH] proc_sysctl: clamp sizes using table->maxlen
Excerpts from Alex Xu (Hello71)'s message of February 15, 2021 9:53 am:
> This issue was discussed at [0] and following, and the solution was to
> clamp the size at KMALLOC_MAX_LEN. However, KMALLOC_MAX_LEN is a maximum
> allocation, and may be difficult to allocate in low memory conditions.
>
> Since maxlen is already exposed, we can allocate approximately the right
> amount directly, fixing up those drivers which set a bogus maxlen. These
> drivers were located based on those which had copy_x_user replaced in
> 32927393dc1c, on the basis that other drivers either use builtin proc_*
> handlers, or do not access the data pointer. The latter is OK because
> maxlen only needs to be an upper limit.
>
> [0]
> https://lore.kernel.org/lkml/1fc7ce08-26a7-59ff-e580-4e6c22554...@oracle.com/
>
> Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
> Signed-off-by: Alex Xu (Hello71)
Yeah, no, this doesn't work. A bunch of functions call proc_* but don't
set maxlen, and it's annoying to check this statically. Also causes
weird failures elsewhere. May need to think of a better solution here
(kvzalloc?).
[PATCH] proc_sysctl: clamp sizes using table->maxlen
This issue was discussed at [0] and following, and the solution was to
clamp the size at KMALLOC_MAX_LEN. However, KMALLOC_MAX_LEN is a maximum
allocation, and may be difficult to allocate in low memory conditions.
Since maxlen is already exposed, we can allocate approximately the right
amount directly, fixing up those drivers which set a bogus maxlen. These
drivers were located based on those which had copy_x_user replaced in
32927393dc1c, on the basis that other drivers either use builtin proc_*
handlers, or do not access the data pointer. The latter is OK because
maxlen only needs to be an upper limit.
[0]
https://lore.kernel.org/lkml/1fc7ce08-26a7-59ff-e580-4e6c22554...@oracle.com/
Fixes: 32927393dc1c ("sysctl: pass kernel pointers to ->proc_handler")
Signed-off-by: Alex Xu (Hello71)
---
drivers/parport/procfs.c | 20 ++--
fs/proc/proc_sysctl.c | 13 -
include/linux/sysctl.h | 2 +-
net/core/sysctl_net_core.c | 1 +
net/decnet/sysctl_net_decnet.c | 4 ++--
net/sunrpc/xprtrdma/svc_rdma.c | 18 +-
6 files changed, 31 insertions(+), 27 deletions(-)
diff --git a/drivers/parport/procfs.c b/drivers/parport/procfs.c
index d740eba3c099..a2eeae73f9fa 100644
--- a/drivers/parport/procfs.c
+++ b/drivers/parport/procfs.c
@@ -280,28 +280,28 @@ static const struct parport_sysctl_table
parport_sysctl_template = {
{
.procname = "base-addr",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 20,
.mode = 0444,
.proc_handler = do_hardware_base_addr
},
{
.procname = "irq",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 20,
.mode = 0444,
.proc_handler = do_hardware_irq
},
{
.procname = "dma",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 20,
.mode = 0444,
.proc_handler = do_hardware_dma
},
{
.procname = "modes",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 40,
.mode = 0444,
.proc_handler = do_hardware_modes
},
@@ -310,35 +310,35 @@ static const struct parport_sysctl_table
parport_sysctl_template = {
{
.procname = "autoprobe",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 256,
.mode = 0444,
.proc_handler = do_autoprobe
},
{
.procname = "autoprobe0",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 256,
.mode = 0444,
.proc_handler = do_autoprobe
},
{
.procname = "autoprobe1",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 256,
.mode = 0444,
.proc_handler = do_autoprobe
},
{
.procname = "autoprobe2",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 256,
.mode = 0444,
.proc_handler = do_autoprobe
},
{
.procname = "autoprobe3",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 256,
.mode = 0444,
.proc_handler = do_autoprobe
},
@@ -349,7 +349,7 @@ static const struct parport_sysctl_table
parport_sysctl_template = {
{
.procname = "active",
.data = NULL,
- .maxlen = 0,
+ .maxlen = 256,
.mode = 0444,
Re: [RFC PATCH] treewide: remove bzip2 compression support
Excerpts from Alex Xu (Hello71)'s message of December 15, 2020 2:03 pm: > bzip2 is either slower or larger than every other supported algorithm, > according to benchmarks at [0]. It is far slower to decompress than any > other algorithm, and still larger than lzma, xz, and zstd. > > [0] https://lore.kernel.org/lkml/1588791882.08g1378g67.none@localhost/ > > Signed-off-by: Alex Xu (Hello71) Upon further research, I found that bzip2 removal was already implemented as part of zstd addition, but were apparently abandoned in an effort to get zstd in. I will check those patches and try sending those instead. Thanks to all reviewers for comments on this patch.
[RFC PATCH] treewide: remove bzip2 compression support
bzip2 is either slower or larger than every other supported algorithm,
according to benchmarks at [0]. It is far slower to decompress than any
other algorithm, and still larger than lzma, xz, and zstd.
[0] https://lore.kernel.org/lkml/1588791882.08g1378g67.none@localhost/
Signed-off-by: Alex Xu (Hello71)
---
Documentation/x86/boot.rst | 8 +-
arch/arm/configs/aspeed_g4_defconfig | 1 -
arch/arm/configs/aspeed_g5_defconfig | 1 -
arch/arm/configs/ezx_defconfig | 1 -
arch/arm/configs/imote2_defconfig | 1 -
arch/arm/configs/lpc18xx_defconfig | 1 -
arch/arm/configs/vf610m4_defconfig | 1 -
arch/arm64/boot/Makefile | 5 +-
arch/mips/Kconfig | 1 -
arch/mips/Makefile | 3 -
arch/mips/boot/Makefile| 14 -
arch/mips/boot/compressed/Makefile | 1 -
arch/mips/boot/compressed/decompress.c | 4 -
arch/mips/configs/ath25_defconfig | 1 -
arch/mips/configs/pistachio_defconfig | 1 -
arch/openrisc/configs/simple_smp_defconfig | 1 -
arch/parisc/Kconfig| 1 -
arch/parisc/boot/compressed/Makefile | 5 +-
arch/parisc/boot/compressed/misc.c | 4 -
arch/powerpc/configs/skiroot_defconfig | 1 -
arch/riscv/boot/Makefile | 3 -
arch/riscv/configs/nommu_k210_defconfig| 1 -
arch/riscv/configs/nommu_virt_defconfig| 1 -
arch/s390/Kconfig | 1 -
arch/s390/boot/compressed/Makefile | 5 +-
arch/s390/boot/compressed/decompressor.c | 8 -
arch/sh/Kconfig| 1 -
arch/sh/Makefile | 3 +-
arch/sh/boot/Makefile | 11 +-
arch/sh/boot/compressed/Makefile | 5 +-
arch/sh/boot/compressed/misc.c | 8 -
arch/sh/configs/sdk7786_defconfig | 1 -
arch/x86/Kconfig | 1 -
arch/x86/boot/compressed/Makefile | 9 +-
arch/x86/boot/compressed/misc.c| 4 -
arch/x86/include/asm/boot.h| 4 +-
arch/xtensa/configs/cadence_csp_defconfig | 1 -
arch/xtensa/configs/nommu_kc705_defconfig | 1 -
include/linux/decompress/bunzip2.h | 11 -
init/Kconfig | 22 +-
init/do_mounts_rd.c| 1 -
kernel/configs/tiny.config | 1 -
lib/Kconfig| 3 -
lib/Makefile | 1 -
lib/decompress.c | 5 -
lib/decompress_bunzip2.c | 756 -
scripts/Makefile.lib | 8 +-
scripts/Makefile.package | 1 -
scripts/package/buildtar | 2 +-
usr/Kconfig| 26 +-
usr/Makefile | 3 +-
51 files changed, 22 insertions(+), 942 deletions(-)
delete mode 100644 include/linux/decompress/bunzip2.h
delete mode 100644 lib/decompress_bunzip2.c
diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index abb9fc164657..741eebc10140 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -781,10 +781,10 @@ Protocol: 2.08+
The payload may be compressed. The format of both the compressed and
uncompressed data should be determined using the standard magic
numbers. The currently supported compression formats are gzip
- (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
- (magic number 5D 00), XZ (magic number FD 37), LZ4 (magic number
- 02 21) and ZSTD (magic number 28 B5). The uncompressed payload is
- currently always ELF (magic number 7F 45 4C 46).
+ (magic numbers 1F 8B or 1F 9E), LZMA (magic number 5D 00), XZ (magic
+ number FD 37), LZ4 (magic number 02 21) and ZSTD (magic number 28 B5).
+ Formerly supported was bzip2 (magic number 42 5A). The uncompressed
+ payload is currently always ELF (magic number 7F 45 4C 46).
==
Field name:payload_length
diff --git a/arch/arm/configs/aspeed_g4_defconfig
b/arch/arm/configs/aspeed_g4_defconfig
index 58d293b63581..f2f5dcd0e59c 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -8,7 +8,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_UID16 is not set
diff --git a/arch/arm/configs/aspeed_g5_defconfig
b/arch/arm/configs/aspeed_g5_defconfig
index 047975eccefb..5d045b2902d6 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -8,7 +8,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZO is not set
[PATCH 3/3] init: remove root_device_name
root_device_name has gone through many iterations, but is now solely
used for removing a /dev/ prefix off root= parameter. It's time for it
to be removed.
Signed-off-by: Alex Xu (Hello71)
---
init/do_mounts.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index a2a273b9866f..544614279281 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -29,7 +29,6 @@
#include "do_mounts.h"
int root_mountflags = MS_RDONLY | MS_SILENT;
-static char * __initdata root_device_name;
static char __initdata saved_root_name[64];
static int root_wait;
@@ -449,7 +448,7 @@ void __init mount_block_root(char *name, int flags)
* and give them a list of the available devices
*/
printk("VFS: Cannot open root device \"%s\" or %s: error %d\n",
- root_device_name, b, err);
+ saved_root_name, b, err);
printk("Please append a correct \"root=\" boot option; here are
the available partitions:\n");
printk_all_partitions();
@@ -602,10 +601,7 @@ void __init prepare_namespace(void)
md_run_setup();
if (saved_root_name[0]) {
- root_device_name = saved_root_name;
- ROOT_DEV = name_to_dev_t(root_device_name);
- if (strncmp(root_device_name, "/dev/", 5) == 0)
- root_device_name += 5;
+ ROOT_DEV = name_to_dev_t(saved_root_name);
}
if (initrd_load())
--
2.29.2
[PATCH 2/3] init: remove special-case for mtd/ubi
This should be handled by the fallback after trying to resolve it.
Signed-off-by: Alex Xu (Hello71)
---
init/do_mounts.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index 8aa38ec0bfec..a2a273b9866f 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -603,11 +603,6 @@ void __init prepare_namespace(void)
if (saved_root_name[0]) {
root_device_name = saved_root_name;
- if (!strncmp(root_device_name, "mtd", 3) ||
- !strncmp(root_device_name, "ubi", 3)) {
- mount_block_root(root_device_name, root_mountflags);
- goto out;
- }
ROOT_DEV = name_to_dev_t(root_device_name);
if (strncmp(root_device_name, "/dev/", 5) == 0)
root_device_name += 5;
--
2.29.2
[PATCH 1/3] init: fall back on mounting raw root
9p/virtio, virtiofs, and others can be mounted with no block device or
userspace helpers.
Signed-off-by: Alex Xu (Hello71)
---
init/do_mounts.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/init/do_mounts.c b/init/do_mounts.c
index b5f9604d0c98..8aa38ec0bfec 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -568,7 +568,7 @@ void __init mount_root(void)
}
#endif
#ifdef CONFIG_BLOCK
- {
+ if (ROOT_DEV != 0) {
int err = create_dev("/dev/root", ROOT_DEV);
if (err < 0)
@@ -576,6 +576,7 @@ void __init mount_root(void)
mount_block_root("/dev/root", root_mountflags);
}
#endif
+ mount_block_root(saved_root_name, root_mountflags);
}
/*
--
2.29.2
[RFC PATCH] treewide: remove bzip2 compression support
bzip2 is either slower or larger than every other supported algorithm,
according to benchmarks at [0]. It is far slower to decompress than any
other algorithm, and still larger than lzma, xz, and zstd.
[0] https://lore.kernel.org/lkml/1588791882.08g1378g67.none@localhost/
Signed-off-by: Alex Xu (Hello71)
---
Documentation/x86/boot.rst | 8 +-
arch/arm/configs/aspeed_g4_defconfig | 1 -
arch/arm/configs/aspeed_g5_defconfig | 1 -
arch/arm/configs/ezx_defconfig | 1 -
arch/arm/configs/imote2_defconfig | 1 -
arch/arm/configs/lpc18xx_defconfig | 1 -
arch/arm/configs/vf610m4_defconfig | 1 -
arch/arm64/boot/Makefile | 5 +-
arch/mips/Kconfig | 1 -
arch/mips/Makefile | 3 -
arch/mips/boot/Makefile| 14 -
arch/mips/boot/compressed/Makefile | 1 -
arch/mips/boot/compressed/decompress.c | 4 -
arch/mips/configs/ath25_defconfig | 1 -
arch/mips/configs/pistachio_defconfig | 1 -
arch/openrisc/configs/simple_smp_defconfig | 1 -
arch/parisc/Kconfig| 1 -
arch/parisc/boot/compressed/Makefile | 5 +-
arch/parisc/boot/compressed/misc.c | 4 -
arch/powerpc/configs/skiroot_defconfig | 1 -
arch/riscv/boot/Makefile | 3 -
arch/riscv/configs/nommu_k210_defconfig| 1 -
arch/riscv/configs/nommu_virt_defconfig| 1 -
arch/s390/Kconfig | 1 -
arch/s390/boot/compressed/Makefile | 5 +-
arch/s390/boot/compressed/decompressor.c | 8 -
arch/sh/Kconfig| 1 -
arch/sh/Makefile | 3 +-
arch/sh/boot/Makefile | 11 +-
arch/sh/boot/compressed/Makefile | 5 +-
arch/sh/boot/compressed/misc.c | 8 -
arch/sh/configs/sdk7786_defconfig | 1 -
arch/x86/Kconfig | 1 -
arch/x86/boot/compressed/Makefile | 9 +-
arch/x86/boot/compressed/misc.c| 4 -
arch/x86/include/asm/boot.h| 4 +-
arch/xtensa/configs/cadence_csp_defconfig | 1 -
arch/xtensa/configs/nommu_kc705_defconfig | 1 -
include/linux/decompress/bunzip2.h | 11 -
init/Kconfig | 22 +-
init/do_mounts_rd.c| 1 -
kernel/configs/tiny.config | 1 -
lib/Kconfig| 3 -
lib/Makefile | 1 -
lib/decompress.c | 5 -
lib/decompress_bunzip2.c | 756 -
scripts/Makefile.lib | 8 +-
scripts/Makefile.package | 1 -
scripts/package/buildtar | 2 +-
usr/Kconfig| 26 +-
usr/Makefile | 3 +-
51 files changed, 22 insertions(+), 942 deletions(-)
delete mode 100644 include/linux/decompress/bunzip2.h
delete mode 100644 lib/decompress_bunzip2.c
diff --git a/Documentation/x86/boot.rst b/Documentation/x86/boot.rst
index abb9fc164657..b74d14caabe6 100644
--- a/Documentation/x86/boot.rst
+++ b/Documentation/x86/boot.rst
@@ -781,10 +781,10 @@ Protocol: 2.08+
The payload may be compressed. The format of both the compressed and
uncompressed data should be determined using the standard magic
numbers. The currently supported compression formats are gzip
- (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
- (magic number 5D 00), XZ (magic number FD 37), LZ4 (magic number
- 02 21) and ZSTD (magic number 28 B5). The uncompressed payload is
- currently always ELF (magic number 7F 45 4C 46).
+ (magic numbers 1F 8B or 1F 9E), LZMA (magic number 5D 00), XZ (magic
+ number FD 37), LZ4 (magic number 02 21) and ZSTD (magic number 28
+ B5). The uncompressed payload is currently always ELF (magic number
+ 7F 45 4C 46).
==
Field name:payload_length
diff --git a/arch/arm/configs/aspeed_g4_defconfig
b/arch/arm/configs/aspeed_g4_defconfig
index 58d293b63581..f2f5dcd0e59c 100644
--- a/arch/arm/configs/aspeed_g4_defconfig
+++ b/arch/arm/configs/aspeed_g4_defconfig
@@ -8,7 +8,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_UID16 is not set
diff --git a/arch/arm/configs/aspeed_g5_defconfig
b/arch/arm/configs/aspeed_g5_defconfig
index 047975eccefb..5d045b2902d6 100644
--- a/arch/arm/configs/aspeed_g5_defconfig
+++ b/arch/arm/configs/aspeed_g5_defconfig
@@ -8,7 +8,6 @@ CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
CONFIG_CGROUPS=y
CONFIG_BLK_DEV_INITRD=y
-# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_UID16 is not set
diff
RE: amdgpu crashes on OOM
Excerpts from Deucher, Alexander's message of October 26, 2020 10:34 am: > It was using kvzalloc, but was accidently dropped when that code was > refactored. I just sent a patch to fix it. Ah, that explains why I wasn't seeing it before. I was only looking at changes in amdgpu_dm_atomic_commit_tail, not dc_create_state. Thanks, Alex.
amdgpu crashes on OOM
Hi, I frequently encounter OOM on my system, mostly due to my own fault. Recently, I noticed that not only does a swap storm happen and OOM killer gets invoked, but the graphics output freezes permanently. Checking the kernel messages, I see: kworker/u24:4: page allocation failure: order:5, mode:0x40dc0(GFP_KERNEL|__GFP_COMP|__GFP_ZERO), nodemask=(null) CPU: 6 PID: 279469 Comm: kworker/u24:4 Tainted: GW 5.9.0-14732-g20b1adb60cf6 #2 Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450 Pro4, BIOS P4.20 06/18/2020 Workqueue: events_unbound commit_work Call Trace: ? dump_stack+0x57/0x6a ? warn_alloc.cold+0x69/0xcd ? __alloc_pages_direct_compact+0xfb/0x116 ? __alloc_pages_slowpath.constprop.0+0x9c2/0xc14 ? __alloc_pages_nodemask+0x143/0x167 ? kmalloc_order+0x24/0x64 ? dc_create_state+0x1a/0x4d ? amdgpu_dm_atomic_commit_tail+0x1b19/0x227d followed by: WARNING: CPU: 6 PID: 279469 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:7511 amdgpu_dm_atomic_commit_tail+0x217c/0x227d followed by: BUG: unable to handle page fault for address: 00012480 #PF: supervisor read access in kernel mode #PF: error_code(0x) - not-present page [ ... ] RIP: 0010:dc_resource_state_copy_construct+0x10/0x455 [ ... ] Call Trace: ? amdgpu_dm_atomic_commit_tail+0x2193/0x227 This area of code is quite odd: dc_state_temp = dc_create_state(dm->dc); ASSERT(dc_state_temp); dc_state = dc_state_temp; dc_resource_state_copy_construct_current(dm->dc, dc_state); This ASSERT macro is misleading: unless CONFIG_DEBUG_KERNEL_DC is set, it is actually WARN_ON_ONCE(!(expr)). Therefore, this code fails to allocate memory (causing a warning to be printed), prints another warning that it failed, then proceeds to immediately dereference it, crashing the thread (and the kernel if panic_on_oops is set). While I am not by any means a graphics or kernel expert, it seems to me like there should be a better solution than crashing. If nothing else, the OOM killer should be invoked and the operation retried. We may lose some frames or see some corruption, but that's far better than totally breaking. Thanks, Alex.
Re: wine fails to start with seccomp updates for v5.9-rc1
Excerpts from Thadeu Lima de Souza Cascardo's message of August 7, 2020 1:36 pm:
> On Fri, Aug 07, 2020 at 08:48:46AM -0700, Linus Torvalds wrote:
>> On Fri, Aug 7, 2020 at 8:19 AM Alex Xu (Hello71) wrote:
>> >
>> > On Linus' master, wine fails to start with the following error:
>> >
>> > wine client error:0: write: Bad file descriptor
>> >
>> > This issue is not present on 5.8. It appears to be caused by failure to
>> > write to a pipe FD received via SCM_RIGHTS. Therefore, I tried reverting
>> > 9ecc6ea491f0, which resolved the issue.
>>
>> Would you mind trying to bisect exactly where it happens?
>>
>
> This report [1] seemed related and pointed out at c0029de50982 ("net/scm:
> Regularize compat handling of scm_detach_fds()"). The use of CMSG_USER_DATA
> instead of CMSG_COMPAT_DATA seems fishy.
>
> Alex, can you try applying the patch below?
>
> Cascardo.
>
> [1] https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-August/216156.html
>
>> I don't think any of the commits in that pull are supposed to change
>> semantics, and while reverting the whole merge shows that yes, that's
>> what brought in the problems, it would be good to pinpoint just which
>> change breaks so that we can fix just that thing.
>>
>> Kees, ideas?
>>
>> Linus
>
> ---
> diff --git a/net/compat.c b/net/compat.c
> index 703acb51c698..95ce707a30a3 100644
> --- a/net/compat.c
> +++ b/net/compat.c
> @@ -294,7 +294,7 @@ void scm_detach_fds_compat(struct msghdr *msg, struct
> scm_cookie *scm)
> (struct compat_cmsghdr __user *)msg->msg_control;
> unsigned int o_flags = (msg->msg_flags & MSG_CMSG_CLOEXEC) ? O_CLOEXEC
> : 0;
> int fdmax = min_t(int, scm_max_fds_compat(msg), scm->fp->count);
> - int __user *cmsg_data = CMSG_USER_DATA(cm);
> + int __user *cmsg_data = CMSG_COMPAT_DATA(cm);
> int err = 0, i;
>
> for (i = 0; i < fdmax; i++) {
>
Yes, this seems to work.
Tested-by: Alex Xu (Hello71)
Thanks!
wine fails to start with seccomp updates for v5.9-rc1
Hi, On Linus' master, wine fails to start with the following error: wine client error:0: write: Bad file descriptor This issue is not present on 5.8. It appears to be caused by failure to write to a pipe FD received via SCM_RIGHTS. Therefore, I tried reverting 9ecc6ea491f0, which resolved the issue. Thanks, Alex.
Re: Kernel compression benchmarks
Excerpts from Gao Xiang's message of July 1, 2020 11:50 am: > Anyway, I think LZMA (xz) is still useful and which is more > friendly to fixed-sized output compression than Zstd yet (But > yeah, I'm not familar with all ZSTD internals. I will dig > into that if I've more extra time). Yes, I agree. If you look at the graphs, LZMA2 (xz/7zip) still produces smaller results, even compared to zstd maximum settings, so definitely LZMA2 should be kept, at least for now. I am only suggesting removing LZMA, since it has no benefits over xz and zstd combination (bigger than xz, slower than zstd). >> - modern compressors (xz, lz4, zstd) decompress about as fast for each >> compression level, only requiring more memory > > lz4 has fixed sliding window (dictionary, 64k), so it won't > require more memory among different compression level when > decompressing. Yes, this is true. I tried to simplify among all compressors, but I think I simplified too much. Thanks for clarifying. Cheers, Alex.
Kernel compression benchmarks
Hi all, ZSTD compression patches have been sent in a number of times over the past few years. Every time, someone asks for benchmarks. Every time, someone is concerned about compression time. Sometimes, someone provides benchmarks. But, as far as I can tell, nobody considered the compression parameters, which have a significant impact on compression time and ratio. So, I did some benchmarks myself, including all the compression levels for each compressor. Results: The results are attached as SVG graphs and CSV data. Summary: - compression level, predictably, has a huge impact on compression time. - compression level has virtually no impact on decompression time for lz4, zstd, and some effect on others. interestingly, xz decompresses slightly faster at higher compression levels (perhaps cache-related). - gzip compresses slightly faster than zstd at medium compression levels. - bzip2 sucks: slow compression, very slow decompression, poor ratio. - lzma decompresses slightly faster than xz, but is also slightly larger. - xz is smallest but with very slow compression and decompression. - lz4 decompresses fastest. - zstd is a good balanced default. - 7z is much faster than xz, even with wine overhead. Files: For the kernel, I did "make allmodconfig; sed -i -e '/=m$/d' .config" with a 5.6 kernel and gcc 9.3.0 on x86_64, then concatenated vmlinux.bin and vmlinux.relocs. For the initramfs, I used the Arch Linux fallback initramfs with default hooks. Versions: gzip 1.10 bzip2, a block-sorting file compressor. Version 1.0.8, 13-Jul-2019. xz (XZ Utils) 5.2.5 *** LZ4 command line interface 64-bits v1.9.2, by Yann Collet *** lzop 1.04 LZO library 2.10 *** zstd command line interface 64-bits v1.4.4, by Yann Collet *** 7-Zip 19.00 (x64) : Copyright (c) 1999-2018 Igor Pavlov : 2019-02-21 Notes: I used the userspace versions of the decompressors, not the kernel version. This is particularly relevant for xz, as the kernel xzminidec is significantly slower than xz. pigz is faster than gzip, but I used gzip as a common baseline. 7-Zip was run through wine with a persistent wineserver. I ran the benchmark on a Ryzen 1600, with turbo boost turned off. Each test was run only once, on the basis that any noise wouldn't disrupt the overall curve, and also I don't want to spend hours waiting for the results. The current compression level defaults are: - gzip -9 - bzip2 -9 - lzma -9 - xz --check=crc32 --x86 --lzma2=,dict=32MiB # except on ppc - lzop -9 - lz4 -l -1 My conclusions: - zstd is an improvement on almost all metrics. - bzip2 and lzma should be removed post-haste. - lzo should be removed once zstd is merged. - compression level is important to consider for compression speed: the default lz4 -1 compresses very fast but has a very poor compression ratio. zstd -19 compresses barely better than zstd -18, but takes significantly longer to compress. - compression level should be configurable: lz4 -1 is useful, but so is lz4 -9. zstd -1 is useful, but so is zstd -19. zstd -1 is useful for developers who want kernel builds as fast as possible, zstd -19 for everybody else. - gzip is by far not the fastest compressor (even excluding cat) - modern compressors (xz, lz4, zstd) decompress about as fast for each compression level, only requiring more memory - 7-Zip is much faster than xz, needs more research - 7-Zip BCJ2 is slightly better than xz/BCJ. probably better filters for all archs would be a good area of research, as apparently BCJ/BCJ2 are intended only for 32-bit x86. Thanks, Alex. kernel-compression-benchmarks.tar.gz Description: application/compressed-tar
Re: AMD IOMMU + SME + amdgpu regression
Excerpts from Joerg Roedel's message of June 22, 2020 6:02 am:
> Hi Alex,
>
> On Thu, Jun 11, 2020 at 07:05:21PM -0400, Alex Xu (Hello71) wrote:
>> I am using an ASRock B450 Pro4 with Ryzen 1600 and ASUS RX 480. I don't
>> understand this code at all, but let me know what I can do to
>> troubleshoot.
>
> Does it boot without SME enabled?
>
>
> Regards,
>
> Joerg
>
Yes, it works with SME off with dbed452a078 ("dma-pool: decouple
DMA_REMAP from DMA_COHERENT_POOL") applied.
Re: next-0519 on thinkpad x60: sound related? window manager crash
Excerpts from Takashi Iwai's message of June 14, 2020 5:54 am:
> On Sat, 13 Jun 2020 18:25:22 +0200,
> Alex Xu (Hello71) wrote:
>>
>> Excerpts from Takashi Iwai's message of June 11, 2020 1:11 pm:
>> > Thanks, so something still missing in the mmap handling, I guess.
>> >
>> > I've worked on two different branches for potential fixes of your
>> > problems. Could you test topic/dma-fix and topic/dma-fix2 branches?
>> > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
>> > Just pull one of them onto Linus' git HEAD.
>> >
>> > I guess we'll go with David's new patch, but still it's interesting
>> > whether my changes do anything good actually.
>> >
>> >
>> > Takashi
>> >
>>
>> On torvalds 623f6dc593, topic/dma-fix causes sound to be output as
>> alternating half-second bursts of noise and a few seconds of silence.
>> topic/dma-fix2 appears to work properly.
>
> OK, thanks for the feedback! Just to make sure, you're using
> PulseAudio, right?
> If so, it was still something wrong about mmap, and the secondary
> method (the fallback to the continuous page) looks like a safer
> approach in the end.
>
> I suppose that David's fix will be merged sooner or later. Meanwhile
> I'll work on the change in the sound driver side to make things a bit
> more robust. They don't conflict and both good applicable.
>
>
> thanks,
>
> Takashi
>
Ah, no, I think that wasn't clear. I use ALSA directly with mostly
default configuration, except an asym sets separate default playback and
record devices.
asound.conf:
defaults.pcm.card 1
defaults.ctl.card 1
pcm.!default {
type asym
playback.pcm
{
type plug
slave.pcm "dmix"
}
capture.pcm
{
type plug
slave.pcm {
type dsnoop
ipc_key 6793
slave.pcm "hw:U0x46d0x81d"
}
}
}
I think I wasn't able to set defaults.pcm.dmix.card and
defaults.pcm.dsnoop.card for some reason, not sure why. I can try that,
but I don't think it will affect this mmap issue.
Thanks,
Alex.
Re: next-0519 on thinkpad x60: sound related? window manager crash
Excerpts from Takashi Iwai's message of June 11, 2020 1:11 pm: > Thanks, so something still missing in the mmap handling, I guess. > > I've worked on two different branches for potential fixes of your > problems. Could you test topic/dma-fix and topic/dma-fix2 branches? > git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git > Just pull one of them onto Linus' git HEAD. > > I guess we'll go with David's new patch, but still it's interesting > whether my changes do anything good actually. > > > Takashi > On torvalds 623f6dc593, topic/dma-fix causes sound to be output as alternating half-second bursts of noise and a few seconds of silence. topic/dma-fix2 appears to work properly. Thanks, Alex.
AMD IOMMU + SME + amdgpu regression
Hi, amdgpu + IOMMU + SME is now working for me on 5.7, yay! But, it is broken on torvalds master, boo. On boot, depending on which exact commit I test, it either hangs immediately (with built-in driver, before starting initramfs), displays some errors then hangs, or spams the screen with many amdgpu errors. I bisected the black screen hang to: commit dce8d6964ebdb83bacf5e7ab8c27df151218 Author: Joerg Roedel Date: Wed Apr 29 15:36:53 2020 +0200 iommu/amd: Convert to probe/release_device() call-backs Convert the AMD IOMMU Driver to use the probe_device() and release_device() call-backs of iommu_ops, so that the iommu core code does the group and sysfs setup. Signed-off-by: Joerg Roedel Link: https://lore.kernel.org/r/20200429133712.31431-16-j...@8bytes.org Signed-off-by: Joerg Roedel Testing torvalds master (623f6dc593) with the containing merge (98bdc74b36) plus the DMA mapping merge (4e94d08734) reverted allows amdgpu + IOMMU + SME to once again work. I think that nobody is really working on amdgpu + SME, but it would be a shame if it was supported and then incidentally broken by a small change. I am using an ASRock B450 Pro4 with Ryzen 1600 and ASUS RX 480. I don't understand this code at all, but let me know what I can do to troubleshoot. Thanks, Alex.
Re: [patch for-5.8] dma-pool: decouple DMA_REMAP from DMA_COHERENT_POOL
Excerpts from David Rientjes's message of June 11, 2020 3:25 am:
> DMA_REMAP is an unnecessary requirement for AMD SEV, which requires
> DMA_COHERENT_POOL, so avoid selecting it when it is otherwise unnecessary.
>
> The only other requirement for DMA coherent pools is DMA_DIRECT_REMAP, so
> ensure that properly selects the config option when needed.
>
> Fixes: 82fef0ad811f ("x86/mm: unencrypted non-blocking DMA allocations use
> coherent pools")
> Suggested-by: Christoph Hellwig
> Signed-off-by: David Rientjes
> ---
> kernel/dma/Kconfig | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
Works for me with SME on or off with af7b480103, and with SME off in
abfbb29297. There is some regression with amdgpu and SME between those
two points, I need to check that out too. I haven't tested either before
or after with SEV (which I'm not even sure my system supports).
Regardless, this is a definite improvement.
Tested-by: Alex Xu (Hello71)
Thanks,
Alex.
Re: next-0519 on thinkpad x60: sound related? window manager crash
Excerpts from Takashi Iwai's message of June 9, 2020 11:12 am: > On Tue, 09 Jun 2020 13:47:33 +0200, > Christoph Hellwig wrote: >> >> Alex, can you try this patch? > > Also could you check whether just papering over the memset() call > alone avoids the crash like below? For PulseAudio and dmix/dsnoop, > it's the only code path that accesses the vmapped buffer, I believe. > > If this works more or less, I'll cook a more comprehensive fix. > > > thanks, > > Takashi > > --- a/sound/core/pcm_native.c > +++ b/sound/core/pcm_native.c > @@ -754,9 +754,11 @@ static int snd_pcm_hw_params(struct snd_pcm_substream > *substream, > while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size) > runtime->boundary *= 2; > > +#if 0 > /* clear the buffer for avoiding possible kernel info leaks */ > if (runtime->dma_area && !substream->ops->copy_user) > memset(runtime->dma_area, 0, runtime->dma_bytes); > +#endif > > snd_pcm_timer_resolution_change(substream); > snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP); > Sorry, this patch doesn't work for me with SME off using abfbb29297c2. David's newest submitted patch works for me, which I already replied to separately. Thanks, Alex.
Re: next-0519 on thinkpad x60: sound related? window manager crash
Excerpts from Christoph Hellwig's message of June 9, 2020 7:47 am: > Alex, can you try this patch? > > diff --git a/sound/core/Kconfig b/sound/core/Kconfig > index d4554f376160a9..10b06e575a7fc5 100644 > --- a/sound/core/Kconfig > +++ b/sound/core/Kconfig > @@ -192,6 +192,6 @@ config SND_VMASTER > > config SND_DMA_SGBUF > def_bool y > - depends on X86 > + depends on BROKEN > > source "sound/core/seq/Kconfig" > Sorry, this patch doesn't work for me with SME off using abfbb29297c2. David's newest submitted patch works for me, which I already replied to separately. Thanks, Alex.
Re: next-0519 on thinkpad x60: sound related? window manager crash
Excerpts from Christoph Hellwig's message of June 8, 2020 2:19 am: > Can you do a listing using gdb where this happens? > > gdb vmlinux > > l *(snd_pcm_hw_params+0x3f3) > > ? > (gdb) l *(snd_pcm_hw_params+0x3f3) 0x817efc85 is in snd_pcm_hw_params (.../linux/sound/core/pcm_native.c:749). 744 while (runtime->boundary * 2 <= LONG_MAX - runtime->buffer_size) 745 runtime->boundary *= 2; 746 747 /* clear the buffer for avoiding possible kernel info leaks */ 748 if (runtime->dma_area && !substream->ops->copy_user) 749 memset(runtime->dma_area, 0, runtime->dma_bytes); 750 751 snd_pcm_timer_resolution_change(substream); 752 snd_pcm_set_state(substream, SNDRV_PCM_STATE_SETUP); 753
Re: 82fef0ad811f "x86/mm: unencrypted non-blocking DMA allocations use coherent pools" was Re: next-0519 on thinkpad x60: sound related? window manager crash
Excerpts from David Rientjes's message of June 7, 2020 8:57 pm:
> Thanks for trying it out, Alex. Would you mind sending your .config and
> command line? I assume either mem_encrypt=on or
> CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT is enabled.
>
> Could you also give this a try?
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -99,10 +99,11 @@ static inline bool dma_should_alloc_from_pool(struct
> device *dev, gfp_t gfp,
> static inline bool dma_should_free_from_pool(struct device *dev,
>unsigned long attrs)
> {
> - if (IS_ENABLED(CONFIG_DMA_COHERENT_POOL))
> + if (!IS_ENABLED(CONFIG_DMA_COHERENT_POOL))
> + return false;
> + if (force_dma_unencrypted(dev))
> return true;
> - if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> - !force_dma_unencrypted(dev))
> + if (attrs & DMA_ATTR_NO_KERNEL_MAPPING)
> return false;
> if (IS_ENABLED(CONFIG_DMA_DIRECT_REMAP))
> return true;
>
This patch doesn't work for me either. It has since occurred to me that
while I do have CONFIG_AMD_MEM_ENCYRPT=y, I have
CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT=n, because it was broken with
amdgpu (unfortunately a downgrade from radeon in this respect). Tried it
again just now and it looks like it's now able to enable KMS, but all it
displays is serious-looking errors.
Sorry for not mentioning that earlier. I'll send you my .config and
command line off-list.
Thanks,
Alex.
Re: 82fef0ad811f "x86/mm: unencrypted non-blocking DMA allocations use coherent pools" was Re: next-0519 on thinkpad x60: sound related? window manager crash
Excerpts from David Rientjes's message of June 7, 2020 3:41 pm:
> On Sun, 7 Jun 2020, Pavel Machek wrote:
>
>> > I have a similar issue, caused between aaa2faab4ed8 and b170290c2836.
>> >
>> > [ 20.263098] BUG: unable to handle page fault for address:
>> > b2b582cc2000
>> > [ 20.263104] #PF: supervisor write access in kernel mode
>> > [ 20.263105] #PF: error_code(0x000b) - reserved bit violation
>> > [ 20.263107] PGD 3fd03b067 P4D 3fd03b067 PUD 3fd03c067 PMD 3f8822067 PTE
>> > 8000273942ab2163
>> > [ 20.263113] Oops: 000b [#1] PREEMPT SMP
>> > [ 20.263117] CPU: 3 PID: 691 Comm: mpv Not tainted
>> > 5.7.0-11262-gb170290c2836 #1
>> > [ 20.263119] Hardware name: To Be Filled By O.E.M. To Be Filled By
>> > O.E.M./B450 Pro4, BIOS P4.10 03/05/2020
>> > [ 20.263125] RIP: 0010:__memset+0x24/0x30
>> > [ 20.263128] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83
>> > e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6
>> > 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
>> > [ 20.263131] RSP: 0018:b2b583d07e10 EFLAGS: 00010216
>> > [ 20.263133] RAX: RBX: 8b8000102c00 RCX:
>> > 4000
>> > [ 20.263134] RDX: RSI: RDI:
>> > b2b582cc2000
>> > [ 20.263136] RBP: 8b8000101000 R08: R09:
>> > b2b582cc2000
>> > [ 20.263137] R10: 5356 R11: 8b8000102c18 R12:
>> >
>> > [ 20.263139] R13: R14: 8b8039944200 R15:
>> > 9794daa0
>> > [ 20.263141] FS: 7f41aa4b4200() GS:8b803ecc()
>> > knlGS:
>> > [ 20.263143] CS: 0010 DS: ES: CR0: 80050033
>> > [ 20.263144] CR2: b2b582cc2000 CR3: 0003b6731000 CR4:
>> > 003406e0
>> > [ 20.263146] Call Trace:
>> > [ 20.263151] ? snd_pcm_hw_params+0x3f3/0x47a
>> > [ 20.263154] ? snd_pcm_common_ioctl+0xf2/0xf73
>> > [ 20.263158] ? snd_pcm_ioctl+0x1e/0x29
>> > [ 20.263161] ? ksys_ioctl+0x77/0x91
>> > [ 20.263163] ? __x64_sys_ioctl+0x11/0x14
>> > [ 20.263166] ? do_syscall_64+0x3d/0xf5
>> > [ 20.263170] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> > [ 20.263173] Modules linked in: uvcvideo videobuf2_vmalloc
>> > videobuf2_memops videobuf2_v4l2 videodev snd_usb_audio videobuf2_common
>> > snd_hwdep snd_usbmidi_lib input_leds snd_rawmidi led_class
>> > [ 20.263182] CR2: b2b582cc2000
>> > [ 20.263184] ---[ end trace c6b47a774b91f0a0 ]---
>> > [ 20.263187] RIP: 0010:__memset+0x24/0x30
>> > [ 20.263190] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83
>> > e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6
>> > 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3
>> > [ 20.263192] RSP: 0018:b2b583d07e10 EFLAGS: 00010216
>> > [ 20.263193] RAX: RBX: 8b8000102c00 RCX:
>> > 4000
>> > [ 20.263195] RDX: RSI: RDI:
>> > b2b582cc2000
>> > [ 20.263196] RBP: 8b8000101000 R08: R09:
>> > b2b582cc2000
>> > [ 20.263197] R10: 5356 R11: 8b8000102c18 R12:
>> >
>> > [ 20.263199] R13: R14: 8b8039944200 R15:
>> > 9794daa0
>> > [ 20.263201] FS: 7f41aa4b4200() GS:8b803ecc()
>> > knlGS:
>> > [ 20.263202] CS: 0010 DS: ES: CR0: 80050033
>> > [ 20.263204] CR2: b2b582cc2000 CR3: 0003b6731000 CR4:
>> > 003406e0
>> >
>> > I bisected this to 82fef0ad811f "x86/mm: unencrypted non-blocking DMA
>> > allocations use coherent pools". Reverting 1ee18de92927 resolves the
>> > issue.
>> >
>> > Looks like Thinkpad X60 doesn't have VT-d, but could still be DMA
>> > related.
>>
>> Note that newer -next releases seem to behave okay for me. The commit
>> pointed out by siection is really simple:
>>
>> AFAIK you could verify it is responsible by turning off
>> CONFIG_AMD_MEM_ENCRYPT on latest kernel...
>>
>> Best regards,
>> Pavel
>>
>> index 1d6104ea8af0..2bf819d3 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1520,6 +1520,7 @@ config X86_CPA_STATISTICS
>> config AMD_MEM_ENCRYPT
>> bool "AMD Secure Memory Encryption (SME) support"
>> depends on X86_64 && CPU_SUP_AMD
>> + select DMA_COHERENT_POOL
>> select DYNAMIC_PHYSICAL_MASK
>> select ARCH_USE_MEMREMAP_PROT
>> select ARCH_HAS_FORCE_DMA_UNENCRYPTED
>
> Thanks for the report!
>
> Besides CONFIG_AMD_MEM_ENCRYPT, do you have CONFIG_DMA_DIRECT_REMAP
> enabled? If so, it may be caused by the virtual address passed to the
> set_memory_{decrypted,encrypted}() functions.
>
> And I assume you are enabling SME by using mem_encrypt=on on the kernel
> command line or CONFIG_AMD_MEM_ENCRYPT_ACTIVE_BY_DEFAULT
Re: next-0519 on thinkpad x60: sound related? window manager crash
I have a similar issue, caused between aaa2faab4ed8 and b170290c2836. [ 20.263098] BUG: unable to handle page fault for address: b2b582cc2000 [ 20.263104] #PF: supervisor write access in kernel mode [ 20.263105] #PF: error_code(0x000b) - reserved bit violation [ 20.263107] PGD 3fd03b067 P4D 3fd03b067 PUD 3fd03c067 PMD 3f8822067 PTE 8000273942ab2163 [ 20.263113] Oops: 000b [#1] PREEMPT SMP [ 20.263117] CPU: 3 PID: 691 Comm: mpv Not tainted 5.7.0-11262-gb170290c2836 #1 [ 20.263119] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./B450 Pro4, BIOS P4.10 03/05/2020 [ 20.263125] RIP: 0010:__memset+0x24/0x30 [ 20.263128] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3 [ 20.263131] RSP: 0018:b2b583d07e10 EFLAGS: 00010216 [ 20.263133] RAX: RBX: 8b8000102c00 RCX: 4000 [ 20.263134] RDX: RSI: RDI: b2b582cc2000 [ 20.263136] RBP: 8b8000101000 R08: R09: b2b582cc2000 [ 20.263137] R10: 5356 R11: 8b8000102c18 R12: [ 20.263139] R13: R14: 8b8039944200 R15: 9794daa0 [ 20.263141] FS: 7f41aa4b4200() GS:8b803ecc() knlGS: [ 20.263143] CS: 0010 DS: ES: CR0: 80050033 [ 20.263144] CR2: b2b582cc2000 CR3: 0003b6731000 CR4: 003406e0 [ 20.263146] Call Trace: [ 20.263151] ? snd_pcm_hw_params+0x3f3/0x47a [ 20.263154] ? snd_pcm_common_ioctl+0xf2/0xf73 [ 20.263158] ? snd_pcm_ioctl+0x1e/0x29 [ 20.263161] ? ksys_ioctl+0x77/0x91 [ 20.263163] ? __x64_sys_ioctl+0x11/0x14 [ 20.263166] ? do_syscall_64+0x3d/0xf5 [ 20.263170] ? entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 20.263173] Modules linked in: uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videodev snd_usb_audio videobuf2_common snd_hwdep snd_usbmidi_lib input_leds snd_rawmidi led_class [ 20.263182] CR2: b2b582cc2000 [ 20.263184] ---[ end trace c6b47a774b91f0a0 ]--- [ 20.263187] RIP: 0010:__memset+0x24/0x30 [ 20.263190] Code: cc cc cc cc cc cc 0f 1f 44 00 00 49 89 f9 48 89 d1 83 e2 07 48 c1 e9 03 40 0f b6 f6 48 b8 01 01 01 01 01 01 01 01 48 0f af c6 48 ab 89 d1 f3 aa 4c 89 c8 c3 90 49 89 f9 40 88 f0 48 89 d1 f3 [ 20.263192] RSP: 0018:b2b583d07e10 EFLAGS: 00010216 [ 20.263193] RAX: RBX: 8b8000102c00 RCX: 4000 [ 20.263195] RDX: RSI: RDI: b2b582cc2000 [ 20.263196] RBP: 8b8000101000 R08: R09: b2b582cc2000 [ 20.263197] R10: 5356 R11: 8b8000102c18 R12: [ 20.263199] R13: R14: 8b8039944200 R15: 9794daa0 [ 20.263201] FS: 7f41aa4b4200() GS:8b803ecc() knlGS: [ 20.263202] CS: 0010 DS: ES: CR0: 80050033 [ 20.263204] CR2: b2b582cc2000 CR3: 0003b6731000 CR4: 003406e0 I bisected this to 82fef0ad811f "x86/mm: unencrypted non-blocking DMA allocations use coherent pools". Reverting 1ee18de92927 resolves the issue. Looks like Thinkpad X60 doesn't have VT-d, but could still be DMA related.
[PATCH] random: print a message when waiting for random
- many programs now use getrandom on startup, including for cases which
may not be security-sensitive (e.g. hash tables)
- boot times are faster than ever with the widespread use of high-speed
SSD storage
- no major distributions currently use RNDADDENTROPY ioctl when
restoring the random seed, including systemd and OpenRC. systemd may
add this functionality soon
(https://github.com/systemd/systemd/pull/13137) but it seems to have
some special requirements (systemd-boot) and/or require special
opt-in.
- despite the availability of virtio-rng, many hosts do not offer it,
and many/most distributions do not configure rngd by default
in combination, many programs (e.g. sshd, gdm) now block on startup,
sometimes for many minutes. in the kernel, we can't fix this easily, but
we should at least notify users why their program is stuck.
Signed-off-by: Alex Xu (Hello71)
---
drivers/char/random.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 5d5ea4ce1442..e4490c6c9c84 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -511,6 +511,8 @@ static struct ratelimit_state unseeded_warning =
RATELIMIT_STATE_INIT("warn_unseeded_randomness", HZ, 3);
static struct ratelimit_state urandom_warning =
RATELIMIT_STATE_INIT("warn_urandom_randomness", HZ, 3);
+static struct ratelimit_state wait_for_random_warning =
+ RATELIMIT_STATE_INIT("warn_wait_for_random", HZ, 3);
static int ratelimit_disable __read_mostly;
@@ -1745,6 +1747,9 @@ int wait_for_random_bytes(void)
{
if (likely(crng_ready()))
return 0;
+ if (__ratelimit(_for_random_warning))
+ pr_info("random: %s: waiting for randomness\n",
+ current->comm);
return wait_event_interruptible(crng_init_wait, crng_ready());
}
EXPORT_SYMBOL(wait_for_random_bytes);
@@ -1901,6 +1906,7 @@ int __init rand_initialize(void)
if (ratelimit_disable) {
urandom_warning.interval = 0;
unseeded_warning.interval = 0;
+ wait_for_random_warning.interval = 0;
}
return 0;
}
--
2.22.0
[PATCH] treewide: fix awk regexp over-escaping
Fix "warning: regexp escape sequence is not a known regexp operator" on
gawk 5.0.0.
Results found by:
- grepping '\\[^\[\\^$.|?*+()a-z]' on *.awk
- grepping 'awk.*\\[^\[\\^$.|?*+()a-z]'
- running awk --lint -f /dev/null on *.awk
Signed-off-by: Alex Xu (Hello71)
---
Documentation/arm/Samsung/clksrc-change-registers.awk | 2 +-
arch/x86/tools/gen-insn-attr-x86.awk | 4 ++--
lib/raid6/unroll.awk | 2 +-
tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk | 4 ++--
tools/perf/arch/x86/tests/gen-insn-x86-dat.awk | 2 +-
tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk | 4 ++--
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/arm/Samsung/clksrc-change-registers.awk
b/Documentation/arm/Samsung/clksrc-change-registers.awk
index 7be1b8aa7cd9..d853f750c861 100755
--- a/Documentation/arm/Samsung/clksrc-change-registers.awk
+++ b/Documentation/arm/Samsung/clksrc-change-registers.awk
@@ -67,7 +67,7 @@ BEGIN {
# to replace and create an associative array of values
while (getline line < ARGV[1] > 0) {
- if (line ~ /\#define.*_MASK/ &&
+ if (line ~ /#define.*_MASK/ &&
!(line ~ /USB_SIG_MASK/)) {
splitdefine(line, fields)
name = fields[0]
diff --git a/arch/x86/tools/gen-insn-attr-x86.awk
b/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\)\\)"
+ lprefix3_expr = "\\((F2|!F3|66)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
diff --git a/lib/raid6/unroll.awk b/lib/raid6/unroll.awk
index c6aa03631df8..0809805a7e23 100644
--- a/lib/raid6/unroll.awk
+++ b/lib/raid6/unroll.awk
@@ -13,7 +13,7 @@ BEGIN {
for (i = 0; i < rep; ++i) {
tmp = $0
gsub(/\$\$/, i, tmp)
- gsub(/\$\#/, n, tmp)
+ gsub(/\$#/, n, tmp)
gsub(/\$\*/, "$", tmp)
print tmp
}
diff --git a/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
b/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\)\\)"
+ lprefix3_expr = "\\((F2|!F3|66)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
diff --git a/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
b/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
index a21454835cd4..27585d032ee6 100644
--- a/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
+++ b/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
@@ -31,7 +31,7 @@ BEGIN {
going = 0
}
-/^\s*[0-9a-fA-F]+\:/ {
+/^\s*[0-9a-fA-F]+:/ {
if (going) {
colon_pos = index($0, ":")
useful_line = substr($0, colon_pos + 1)
diff --git a/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
b/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
index ddd5c4c21129..606ccd154392 100644
--- a/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
+++ b/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\)\\)"
+ lprefix3_expr = "\\((F2|!F3|66)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
--
2.21.0
Re: [bugreport] kernel 5.2 pblk bad header/extent: invalid extent entries
Excerpts from Mikhail Gavrilov's message of May 18, 2019 7:07 am: > On Sat, 18 May 2019 at 11:44, Mikhail Gavrilov > wrote: >> [28616.429757] EXT4-fs error (device nvme0n1p2): ext4_find_extent:908: >> inode #8: comm jbd2/nvme0n1p2-: pblk 23101439 bad header/extent: >> invalid extent entries - magic f30a, entries 8, max 340(340), depth >> 0(0) I had a similar problem today: EXT4-fs error (device dm-0): ext4_find_extent:908: inode #8: comm jbd2/dm-0-8: pblk 117997567 bad header/extent: invalid extent entries - magic f30a, entries 8, max 340(340), depth 0(0) I am using dm-crypt on SATA disk.
[REGRESSION] ptrace broken from "cgroup: cgroup v2 freezer" (76f969e)
Hi,
I was trying to use strace recently and found that it exhibited some
strange behavior. I produced this minimal test case:
#include
int main() {
write(1, "a", 1);
return 0;
}
which, when run using "gcc test.c && strace ./a.out" produces this
strace output:
[ pre-main omitted ]
write(1, "a", 1)= ? ERESTARTSYS (To be restarted if
SA_RESTART is set)
write(1, "a", 1)= ? ERESTARTSYS (To be restarted if
SA_RESTART is set)
write(1, "a", 1)= ? ERESTARTSYS (To be restarted if
SA_RESTART is set)
write(1, "a", 1)= ? ERESTARTSYS (To be restarted if
SA_RESTART is set)
write(1, "a", 1)= ? ERESTARTSYS (To be restarted if
SA_RESTART is set)
write(1, "a", 1)= ? ERESTARTSYS (To be restarted if
SA_RESTART is set)
[ repeats forever ]
The correct result is of course:
[ pre-main omitted ]
write(1, "a", 1)= 1
exit_group(0) = ?
+++ exited with 0 +++
Strangely, this only occurs when outputting to a tty-like output.
Running "strace ./a.out" from a native Linux x86 console or a terminal
emulator causes the abnormal behavior. However, the following commands
work correctly:
- strace ./a.out >/dev/null
- strace ./a.out >/tmp/a # /tmp is a standard tmpfs
- strace ./a.out >&- # causes -1 EBADF (Bad file descriptor)
"strace -o /tmp/a ./a.out" hangs and produces the above (infinite)
output to /tmp/a.
I bisected this to 76f969e, "cgroup: cgroup v2 freezer". I reverted the
entire patchset (reverting only that one caused a conflict), which
resolved the issue. I skimmed the patch and came up with this
workaround, which also resolves the issue. I am not at all clear on the
technical workings of the patchset, but it seems to me like a process's
frozen status is supposed to be "suspended" when a frozen process is
ptraced, and "unsuspended" when ptracing ends. Therefore, it seems
suspicious to always "enter frozen" whether or not the cgroup is
actually frozen. It seems like the code should instead check if the
cgroup is actually frozen, and if so, restore the frozen status.
I am using systemd but not any other cgroup features. I tried in an
initramfs environment (no systemd, /init -> shell script) and reproduced
the failing test case.
Please CC me on replies.
Thanks,
Alex.
---
kernel/signal.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/signal.c b/kernel/signal.c
index 62f9aea4a15a..47145d9d89ca 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2110,7 +2110,7 @@ static void ptrace_stop(int exit_code, int why, int
clear_code, kernel_siginfo_t
preempt_disable();
read_unlock(_lock);
preempt_enable_no_resched();
- cgroup_enter_frozen();
+ //cgroup_enter_frozen();
freezable_schedule();
} else {
/*
@@ -2289,7 +2289,7 @@ static bool do_signal_stop(int signr)
}
/* Now we don't run again until woken by SIGCONT or SIGKILL */
- cgroup_enter_frozen();
+ //cgroup_enter_frozen();
freezable_schedule();
return true;
} else {
--
2.21.0
[PATCH] treewide: fix awk regexp over-escaping
Fix "warning: regexp escape sequence is not a known regexp operator" on
gawk 5.0.0.
Results found by:
- grepping '\\[^\[\\^$.|?*+()a-z]' on *.awk
- grepping 'awk.*\\[^\[\\^$.|?*+()a-z]'
- running awk --lint -f /dev/null on *.awk
Signed-off-by: Alex Xu (Hello71)
---
Documentation/arm/Samsung/clksrc-change-registers.awk | 2 +-
arch/x86/tools/gen-insn-attr-x86.awk | 4 ++--
lib/raid6/unroll.awk | 2 +-
tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk | 4 ++--
tools/perf/arch/x86/tests/gen-insn-x86-dat.awk | 2 +-
tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk | 4 ++--
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/Documentation/arm/Samsung/clksrc-change-registers.awk
b/Documentation/arm/Samsung/clksrc-change-registers.awk
index 7be1b8aa7cd9..d853f750c861 100755
--- a/Documentation/arm/Samsung/clksrc-change-registers.awk
+++ b/Documentation/arm/Samsung/clksrc-change-registers.awk
@@ -67,7 +67,7 @@ BEGIN {
# to replace and create an associative array of values
while (getline line < ARGV[1] > 0) {
- if (line ~ /\#define.*_MASK/ &&
+ if (line ~ /#define.*_MASK/ &&
!(line ~ /USB_SIG_MASK/)) {
splitdefine(line, fields)
name = fields[0]
diff --git a/arch/x86/tools/gen-insn-attr-x86.awk
b/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\)\\)"
+ lprefix3_expr = "\\((F2|!F3|66)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
diff --git a/lib/raid6/unroll.awk b/lib/raid6/unroll.awk
index c6aa03631df8..0809805a7e23 100644
--- a/lib/raid6/unroll.awk
+++ b/lib/raid6/unroll.awk
@@ -13,7 +13,7 @@ BEGIN {
for (i = 0; i < rep; ++i) {
tmp = $0
gsub(/\$\$/, i, tmp)
- gsub(/\$\#/, n, tmp)
+ gsub(/\$#/, n, tmp)
gsub(/\$\*/, "$", tmp)
print tmp
}
diff --git a/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
b/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
index b02a36b2c14f..a42015b305f4 100644
--- a/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
+++ b/tools/objtool/arch/x86/tools/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\)\\)"
+ lprefix3_expr = "\\((F2|!F3|66)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
diff --git a/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
b/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
index a21454835cd4..27585d032ee6 100644
--- a/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
+++ b/tools/perf/arch/x86/tests/gen-insn-x86-dat.awk
@@ -31,7 +31,7 @@ BEGIN {
going = 0
}
-/^\s*[0-9a-fA-F]+\:/ {
+/^\s*[0-9a-fA-F]+:/ {
if (going) {
colon_pos = index($0, ":")
useful_line = substr($0, colon_pos + 1)
diff --git a/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
b/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
index ddd5c4c21129..606ccd154392 100644
--- a/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
+++ b/tools/perf/util/intel-pt-decoder/gen-insn-attr-x86.awk
@@ -69,7 +69,7 @@ BEGIN {
lprefix1_expr = "\\((66|!F3)\\)"
lprefix2_expr = "\\(F3\\)"
- lprefix3_expr = "\\((F2|!F3|66\\)\\)"
+ lprefix3_expr = "\\((F2|!F3|66)\\)"
lprefix_expr = "\\((66|F2|F3)\\)"
max_lprefix = 4
@@ -257,7 +257,7 @@ function convert_operands(count,opnd, i,j,imm,mod)
return add_flags(imm, mod)
}
-/^[0-9a-f]+\:/ {
+/^[0-9a-f]+:/ {
if (NR == 1)
next
# get index
--
2.21.0
Re: shmem_recalc_inode: unable to handle kernel NULL pointer dereference
Excerpts from Vineeth Pillai's message of March 25, 2019 6:08 pm: > On Sun, Mar 24, 2019 at 11:30 AM Alex Xu (Hello71) wrote: >> >> I get this BUG in 5.1-rc1 sometimes when powering off the machine. I >> suspect my setup erroneously executes two swapoff+cryptsetup close >> operations simultaneously, so a race condition is triggered. >> >> I am using a single swap on a plain dm-crypt device on a MBR partition >> on a SATA drive. >> >> I think the problem is probably related to >> b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people. >> > Could you please provide more information on this - stack trace, dmesg etc? > Is it easily reproducible? If yes, please detail the steps so that I > can try it inhouse. > > Thanks, > Vineeth > Some info from the BUG entry (I didn't bother to type it all, low-quality image available upon request): BUG: unable to handle kernel NULL pointer dereference at #PF error: [normal kernel read fault] PGD 0 P4D 0 Oops: [#1] SMP CPU: 0 Comm: swapoff Not tainted 5.1.0-rc1+ #2 RIP: 0010:shmem_recalc_inode+0x41/0x90 Call Trace: ? shmem_undo_range ? rb_erase_cached ? set_next_entity ? __inode_wait_for_writeback ? shmem_truncate_range ? shmem_evict_inode ? evict ? shmem_unuse ? try_to_unuse ? swapcache_free_entries ? _cond_resched ? __se_sys_swapoff ? do_syscall_64 ? entry_SYSCALL_64_after_hwframe As I said, it only occurs occasionally on shutdown. I think it is a safe guess that it can only occur when the swap is not empty, but possibly other conditions are necessary, so I will test further.
shmem_recalc_inode: unable to handle kernel NULL pointer dereference
I get this BUG in 5.1-rc1 sometimes when powering off the machine. I suspect my setup erroneously executes two swapoff+cryptsetup close operations simultaneously, so a race condition is triggered. I am using a single swap on a plain dm-crypt device on a MBR partition on a SATA drive. I think the problem is probably related to b56a2d8af9147a4efe4011b60d93779c0461ca97, so CCing the related people. Thanks, Alex.
r8169 only works in promisc mode
After suspending, my r8169 (not actually 8169, just that driver) only receives packets when in promiscuous mode. I have tried disabling all offload features except highdma [fixed], and it doesn't fix the issue. I am using torvalds/linux, compiled about two days ago (not sure which commit). I think this happened after a recent upgrade (some time in the past week). Given the long testing cycle, I don't really want to bisect; I am hoping someone has some idea of where the issue could be. Please CC me on replies. Thanks, Alex.
[PATCH net] r8169: always autoneg on resume
This affects at least versions 25 and 33, so assume all cards are broken
and just renegotiate by default.
Fixes: a2965f12fde6 ("r8169: remove rtl8169_set_speed_xmii")
Signed-off-by: Alex Xu (Hello71)
---
drivers/net/ethernet/realtek/r8169.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index ab30aaeac6d3..db2f347c1463 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4072,13 +4072,12 @@ static void rtl8169_init_phy(struct net_device *dev,
struct rtl8169_private *tp)
genphy_soft_reset(dev->phydev);
- /* It was reported that chip version 33 ends up with 10MBit/Half on a
+ /* It was reported that several chips end up with 10MBit/Half on a
* 1GBit link after resuming from S3. For whatever reason the PHY on
-* this chip doesn't properly start a renegotiation when soft-reset.
+* these chips doesn't properly start a renegotiation when soft-reset.
* Explicitly requesting a renegotiation fixes this.
*/
- if (tp->mac_version == RTL_GIGA_MAC_VER_33 &&
- dev->phydev->autoneg == AUTONEG_ENABLE)
+ if (dev->phydev->autoneg == AUTONEG_ENABLE)
phy_restart_aneg(dev->phydev);
}
--
2.19.0
[PATCH net] r8169: always autoneg on resume
This affects at least versions 25 and 33, so assume all cards are broken
and just renegotiate by default.
Fixes: a2965f12fde6 ("r8169: remove rtl8169_set_speed_xmii")
Signed-off-by: Alex Xu (Hello71)
---
drivers/net/ethernet/realtek/r8169.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c
b/drivers/net/ethernet/realtek/r8169.c
index ab30aaeac6d3..db2f347c1463 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4072,13 +4072,12 @@ static void rtl8169_init_phy(struct net_device *dev,
struct rtl8169_private *tp)
genphy_soft_reset(dev->phydev);
- /* It was reported that chip version 33 ends up with 10MBit/Half on a
+ /* It was reported that several chips end up with 10MBit/Half on a
* 1GBit link after resuming from S3. For whatever reason the PHY on
-* this chip doesn't properly start a renegotiation when soft-reset.
+* these chips doesn't properly start a renegotiation when soft-reset.
* Explicitly requesting a renegotiation fixes this.
*/
- if (tp->mac_version == RTL_GIGA_MAC_VER_33 &&
- dev->phydev->autoneg == AUTONEG_ENABLE)
+ if (dev->phydev->autoneg == AUTONEG_ENABLE)
phy_restart_aneg(dev->phydev);
}
--
2.19.0
[PATCH v2] mm: fix z3fold warnings on CONFIG_SMP=n
Spinlocks are always lockable on UP systems, even if they were just
locked.
Cc: Dan Streetman
Signed-off-by: Alex Xu (Hello71)
---
mm/z3fold.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 4b366d181..2e8d268ac 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -277,7 +277,7 @@ static void release_z3fold_page_locked(struct kref *ref)
{
struct z3fold_header *zhdr = container_of(ref, struct z3fold_header,
refcount);
- WARN_ON(z3fold_page_trylock(zhdr));
+ WARN_ON_SMP(z3fold_page_trylock(zhdr));
__release_z3fold_page(zhdr, true);
}
@@ -289,7 +289,7 @@ static void release_z3fold_page_locked_list(struct kref
*ref)
list_del_init(>buddy);
spin_unlock(>pool->lock);
- WARN_ON(z3fold_page_trylock(zhdr));
+ WARN_ON_SMP(z3fold_page_trylock(zhdr));
__release_z3fold_page(zhdr, true);
}
@@ -403,7 +403,7 @@ static void do_compact_page(struct z3fold_header *zhdr,
bool locked)
page = virt_to_page(zhdr);
if (locked)
- WARN_ON(z3fold_page_trylock(zhdr));
+ WARN_ON_SMP(z3fold_page_trylock(zhdr));
else
z3fold_page_lock(zhdr);
if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, >private))) {
--
2.19.0
[PATCH v2] mm: fix z3fold warnings on CONFIG_SMP=n
Spinlocks are always lockable on UP systems, even if they were just
locked.
Cc: Dan Streetman
Signed-off-by: Alex Xu (Hello71)
---
mm/z3fold.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 4b366d181..2e8d268ac 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -277,7 +277,7 @@ static void release_z3fold_page_locked(struct kref *ref)
{
struct z3fold_header *zhdr = container_of(ref, struct z3fold_header,
refcount);
- WARN_ON(z3fold_page_trylock(zhdr));
+ WARN_ON_SMP(z3fold_page_trylock(zhdr));
__release_z3fold_page(zhdr, true);
}
@@ -289,7 +289,7 @@ static void release_z3fold_page_locked_list(struct kref
*ref)
list_del_init(>buddy);
spin_unlock(>pool->lock);
- WARN_ON(z3fold_page_trylock(zhdr));
+ WARN_ON_SMP(z3fold_page_trylock(zhdr));
__release_z3fold_page(zhdr, true);
}
@@ -403,7 +403,7 @@ static void do_compact_page(struct z3fold_header *zhdr,
bool locked)
page = virt_to_page(zhdr);
if (locked)
- WARN_ON(z3fold_page_trylock(zhdr));
+ WARN_ON_SMP(z3fold_page_trylock(zhdr));
else
z3fold_page_lock(zhdr);
if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, >private))) {
--
2.19.0
[PATCH] mm: fix z3fold warnings on CONFIG_SMP=n
Spinlocks are always lockable on UP systems, even if they were just
locked.
Cc: Dan Streetman
Signed-off-by: Alex Xu (Hello71)
---
mm/z3fold.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 4b366d181..4e6ad2de4 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -202,6 +202,13 @@ static inline void z3fold_page_lock(struct z3fold_header
*zhdr)
spin_lock(>page_lock);
}
+static inline void z3fold_page_ensure_locked(struct z3fold_header *zhdr)
+{
+#ifdef CONFIG_SMP
+ WARN_ON(z3fold_page_trylock(zhdr));
+#endif
+}
+
/* Try to lock a z3fold page */
static inline int z3fold_page_trylock(struct z3fold_header *zhdr)
{
@@ -277,7 +284,7 @@ static void release_z3fold_page_locked(struct kref *ref)
{
struct z3fold_header *zhdr = container_of(ref, struct z3fold_header,
refcount);
- WARN_ON(z3fold_page_trylock(zhdr));
+ z3fold_page_ensure_locked(zhdr);
__release_z3fold_page(zhdr, true);
}
@@ -289,7 +296,7 @@ static void release_z3fold_page_locked_list(struct kref
*ref)
list_del_init(>buddy);
spin_unlock(>pool->lock);
- WARN_ON(z3fold_page_trylock(zhdr));
+ z3fold_page_ensure_locked(zhdr);
__release_z3fold_page(zhdr, true);
}
@@ -403,7 +410,7 @@ static void do_compact_page(struct z3fold_header *zhdr,
bool locked)
page = virt_to_page(zhdr);
if (locked)
- WARN_ON(z3fold_page_trylock(zhdr));
+ z3fold_page_ensure_locked(zhdr);
else
z3fold_page_lock(zhdr);
if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, >private))) {
--
2.19.0
[PATCH] mm: fix z3fold warnings on CONFIG_SMP=n
Spinlocks are always lockable on UP systems, even if they were just
locked.
Cc: Dan Streetman
Signed-off-by: Alex Xu (Hello71)
---
mm/z3fold.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/mm/z3fold.c b/mm/z3fold.c
index 4b366d181..4e6ad2de4 100644
--- a/mm/z3fold.c
+++ b/mm/z3fold.c
@@ -202,6 +202,13 @@ static inline void z3fold_page_lock(struct z3fold_header
*zhdr)
spin_lock(>page_lock);
}
+static inline void z3fold_page_ensure_locked(struct z3fold_header *zhdr)
+{
+#ifdef CONFIG_SMP
+ WARN_ON(z3fold_page_trylock(zhdr));
+#endif
+}
+
/* Try to lock a z3fold page */
static inline int z3fold_page_trylock(struct z3fold_header *zhdr)
{
@@ -277,7 +284,7 @@ static void release_z3fold_page_locked(struct kref *ref)
{
struct z3fold_header *zhdr = container_of(ref, struct z3fold_header,
refcount);
- WARN_ON(z3fold_page_trylock(zhdr));
+ z3fold_page_ensure_locked(zhdr);
__release_z3fold_page(zhdr, true);
}
@@ -289,7 +296,7 @@ static void release_z3fold_page_locked_list(struct kref
*ref)
list_del_init(>buddy);
spin_unlock(>pool->lock);
- WARN_ON(z3fold_page_trylock(zhdr));
+ z3fold_page_ensure_locked(zhdr);
__release_z3fold_page(zhdr, true);
}
@@ -403,7 +410,7 @@ static void do_compact_page(struct z3fold_header *zhdr,
bool locked)
page = virt_to_page(zhdr);
if (locked)
- WARN_ON(z3fold_page_trylock(zhdr));
+ z3fold_page_ensure_locked(zhdr);
else
z3fold_page_lock(zhdr);
if (WARN_ON(!test_and_clear_bit(NEEDS_COMPACTING, >private))) {
--
2.19.0
