October 2022 - Linux-stable-mirror

Regression: Fwd: Re: [PATCH] riscv: mmap with PROT_WRITE but no PROT_READ is invalid

by Dimitri John Ledkov

#regzbot ^introduced 2139619bcad7ac44cc8f6f749089120594056613 Over at https://lore.kernel.org/linux-riscv/Yz80ewHKTPI5Rvuz@spud/T/#ebde47064434d4… it is reported that 2139619bcad7ac44cc8f6f749089120594056613 regresses userspace (openjdk) on riscv64. This commit has already been released in v6.0 kernel upstream, but has also been included in the stable patch series all the way back to v4.19.y There is a proposed fix for this at https://lore.kernel.org/linux-riscv/20220915193702.2201018-1-abrestic@rivos… which has not yet been merged upstream or in stable series. Please review and merge above proposed fix, or please revert 2139619bcad7ac44cc8f6f749089120594056613 to stop the regression spreading to all the distributions. In Ubuntu this regression will be tracked as https://bugs.launchpad.net/bugs/+bug/1992484 -------- Forwarded Message -------- Subject: Re: [PATCH] riscv: mmap with PROT_WRITE but no PROT_READ is invalid Date: Thu, 6 Oct 2022 22:20:02 +0300 From: Eva Kotova <nyandarknessgirl(a)gmail.com> Reply-To: PH7PR14MB559464DBDD310E755F5B21E8CEDC9(a)PH7PR14MB5594.namprd14.prod.outlook.com To: coelacanthus(a)outlook.com CC: c141028(a)gmail.com, dramforever(a)live.com, linux-riscv(a)lists.infradead.org, palmer(a)dabbelt.com, xc-tan(a)outlook.com On Tue, 31 May 2022 00:56:52 PDT (-0700), coelacanthus(a)outlook.com wrote: > As mentioned in Table 4.5 in RISC-V spec Volume 2 Section 4.3, write > but not read is "Reserved for future use.". For now, they are not valid. > In the current code, -wx is marked as invalid, but -w- is not marked > as invalid. This patch breaks OpenJDK/Java on RISC-V, as it tries to create a w-only protective page: # # There is insufficient memory for the Java Runtime Environment to continue. # Native memory allocation (mmap) failed to map 4096 bytes for failed to allocate memory for PaX check. # An error report file with more information is saved as: # /root/hs_err_pid107.log I bisected to this commit since on Linux 5.19+ java no longer works. Perhaps some fallback should be implemented, to prevent userspace breakage. It is currently documented, that at least on i386 PROT_WRITE mappings imply PROT_READ (See man mmap(2) NOTES), this would be a good place to start. Best regards, Eva _______________________________________________ linux-riscv mailing list linux-riscv(a)lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv

2 years, 1 month

3
3
0 0

Re: [PATCH] mm, compaction: fix fast_isolate_around() to stay within boundaries

by Andrew Morton

On Wed, 26 Oct 2022 20:24:38 +0900 NARIBAYASHI Akira <a.naribayashi(a)fujitsu.com> wrote: > Depending on the memory configuration, isolate_freepages_block() may > scan pages out of the target range and causes panic. > > The problem is that pfn as argument of fast_isolate_around() could > be out of the target range. Therefore we should consider the case > where pfn < start_pfn, and also the case where end_pfn < pfn. > > This problem should have been addressd by the commit 6e2b7044c199 > ("mm, compaction: make fast_isolate_freepages() stay within zone") > but there was an oversight. > > Case1: pfn < start_pfn > > <at memory compaction for node Y> > | node X's zone | node Y's zone > +-----------------+------------------------------... > pageblock ^ ^ ^ > +-----------+-----------+-----------+-----------+... > ^ ^ ^ > ^ ^ end_pfn > ^ start_pfn = cc->zone->zone_start_pfn > pfn > <---------> scanned range by "Scan After" > > Case2: end_pfn < pfn > > <at memory compaction for node X> > | node X's zone | node Y's zone > +-----------------+------------------------------... > pageblock ^ ^ ^ > +-----------+-----------+-----------+-----------+... > ^ ^ ^ > ^ ^ pfn > ^ end_pfn > start_pfn > <---------> scanned range by "Scan Before" > > It seems that there is no good reason to skip nr_isolated pages > just after given pfn. So let perform simple scan from start to end > instead of dividing the scan into "Before" and "After". Under what circumstances will this panic occur? I assume those circumstnces are pretty rare, give that 6e2b7044c1992 was nearly two years ago. Did you consider the desirability of backporting this fix into earlier kernels?

2 years, 1 month

2
1
0 0

[PATCH] clk: tegra: fix HOST1X clock divider on Tegra20 and Tegra30

by luca.ceresoli＠bootlin.com

From: Luca Ceresoli <luca.ceresoli(a)bootlin.com> On Tegra20 and Tegra30 the HOST1X clock is a fractional clock divider with 7 integer bits + 1 decimal bit. This has been verified on both documentation and real hardware for Tegra20 an on the documentation I was able to find for Tegra30. However in the kernel code this clock is declared as an integer divider. A consequence of this is that requesting 144 MHz for HOST1X which is fed by pll_p running at 216 MHz would result in 108 MHz (216 / 2) instead of 144 MHz (216 / 1.5). Fix by replacing the INT() macro with the MUX() macro which, despite the name, defines a fractional divider. The only difference between the two macros is the former does not have the TEGRA_DIVIDER_INT flag. Also move the line together with the other MUX*() ones to keep the existing file organization. Fixes: 76ebc134d45d ("clk: tegra: move periph clocks to common file") Cc: stable(a)vger.kernel.org Cc: Peter De Schrijver <pdeschrijver(a)nvidia.com> Signed-off-by: Luca Ceresoli <luca.ceresoli(a)bootlin.com> --- drivers/clk/tegra/clk-tegra-periph.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/tegra/clk-tegra-periph.c b/drivers/clk/tegra/clk-tegra-periph.c index 4dcf7f7cb8a0..806d835ca0d2 100644 --- a/drivers/clk/tegra/clk-tegra-periph.c +++ b/drivers/clk/tegra/clk-tegra-periph.c @@ -615,7 +615,6 @@ static struct tegra_periph_init_data periph_clks[] = { INT("vde", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_VDE, 61, 0, tegra_clk_vde), INT("vi", mux_pllm_pllc_pllp_plla, CLK_SOURCE_VI, 20, 0, tegra_clk_vi), INT("epp", mux_pllm_pllc_pllp_plla, CLK_SOURCE_EPP, 19, 0, tegra_clk_epp), - INT("host1x", mux_pllm_pllc_pllp_plla, CLK_SOURCE_HOST1X, 28, 0, tegra_clk_host1x), INT("mpe", mux_pllm_pllc_pllp_plla, CLK_SOURCE_MPE, 60, 0, tegra_clk_mpe), INT("2d", mux_pllm_pllc_pllp_plla, CLK_SOURCE_2D, 21, 0, tegra_clk_gr2d), INT("3d", mux_pllm_pllc_pllp_plla, CLK_SOURCE_3D, 24, 0, tegra_clk_gr3d), @@ -664,6 +663,7 @@ static struct tegra_periph_init_data periph_clks[] = { MUX("owr", mux_pllp_pllc_clkm, CLK_SOURCE_OWR, 71, TEGRA_PERIPH_ON_APB, tegra_clk_owr_8), MUX("nor", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_NOR, 42, 0, tegra_clk_nor), MUX("mipi", mux_pllp_pllc_pllm_clkm, CLK_SOURCE_MIPI, 50, TEGRA_PERIPH_ON_APB, tegra_clk_mipi), + MUX("host1x", mux_pllm_pllc_pllp_plla, CLK_SOURCE_HOST1X, 28, 0, tegra_clk_host1x), MUX("vi_sensor", mux_pllm_pllc_pllp_plla, CLK_SOURCE_VI_SENSOR, 20, TEGRA_PERIPH_NO_RESET, tegra_clk_vi_sensor), MUX("vi_sensor", mux_pllc_pllp_plla, CLK_SOURCE_VI_SENSOR, 20, TEGRA_PERIPH_NO_RESET, tegra_clk_vi_sensor_9), MUX("cilab", mux_pllp_pllc_clkm, CLK_SOURCE_CILAB, 144, 0, tegra_clk_cilab), -- 2.34.1

2 years, 1 month

3
4
0 0

[PATCH stable-5.15 0/3] usb: dwc3: 5.15 backports

by Johan Hovold

Here are backports of the three patches that failed to apply to 5.15 due to trivial context conflicts. Hopefully they apply to the older stable trees as well as-is. Note that the last patch depends on features that were not added until 5.9 as mentioned in the commit message. Note that the author of that patch did not add a stable tag for this one, but backporting shouldn't hurt. Johan Johan Hovold (3): usb: dwc3: fix PHY disable sequence usb: dwc3: qcom: fix use-after-free on runtime-PM wakeup usb: dwc3: disable USB core PHY management drivers/usb/dwc3/core.c | 19 ++++++++++--------- drivers/usb/dwc3/dwc3-qcom.c | 14 +++++++++++++- drivers/usb/dwc3/host.c | 11 +++++++++++ 3 files changed, 34 insertions(+), 10 deletions(-) -- 2.35.1

2 years, 1 month

4
19
0 0

[PATCH] virt: sev-guest: fix kconfig warnings

by Randy Dunlap

Fix the SEV_GUEST Kconfig block to eliminate kconfig unmet dependency warnings: WARNING: unmet direct dependencies detected for CRYPTO_GCM Depends on [n]: CRYPTO [=n] Selected by [y]: - SEV_GUEST [=y] && VIRT_DRIVERS [=y] && AMD_MEM_ENCRYPT [=y] WARNING: unmet direct dependencies detected for CRYPTO_AEAD2 Depends on [n]: CRYPTO [=n] Selected by [y]: - SEV_GUEST [=y] && VIRT_DRIVERS [=y] && AMD_MEM_ENCRYPT [=y] Fixes: fce96cf04430 ("virt: Add SEV-SNP guest driver") Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org> Cc: stable(a)vger.kernel.org Cc: Brijesh Singh <brijesh.singh(a)amd.com> Cc: Paul Gazzillo <paul(a)pgazz.com> Cc: Necip Fazil Yildiran <fazilyildiran(a)gmail.com> Cc: Borislav Petkov <bp(a)suse.de> Cc: Tom Lendacky <thomas.lendacky(a)amd.com> Cc: linux-crypto(a)vger.kernel.org --- drivers/virt/coco/sev-guest/Kconfig | 1 + 1 file changed, 1 insertion(+) --- a/drivers/virt/coco/sev-guest/Kconfig +++ b/drivers/virt/coco/sev-guest/Kconfig @@ -2,6 +2,7 @@ config SEV_GUEST tristate "AMD SEV Guest driver" default m depends on AMD_MEM_ENCRYPT + select CRYPTO select CRYPTO_AEAD2 select CRYPTO_GCM help

2 years, 1 month

1
1
0 0

[PATCH 1/2] perf/x86/intel: Fix pebs event constraints for ICL

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> According to the latest event list, update the MEM_INST_RETIRED events which support the DataLA facility. Fixes: 6017608936c1 ("perf/x86/intel: Add Icelake support") Reported-by: Jannis Klinkenberg <jannis.klinkenberg(a)rwth-aachen.de> Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- arch/x86/events/intel/ds.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/x86/events/intel/ds.c b/arch/x86/events/intel/ds.c index f141cc7b8847..26323fea3a65 100644 --- a/arch/x86/events/intel/ds.c +++ b/arch/x86/events/intel/ds.c @@ -982,8 +982,13 @@ struct event_constraint intel_icl_pebs_event_constraints[] = { INTEL_FLAGS_UEVENT_CONSTRAINT(0x0400, 0x800000000ULL), /* SLOTS */ INTEL_PLD_CONSTRAINT(0x1cd, 0xff), /* MEM_TRANS_RETIRED.LOAD_LATENCY */ - INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x1d0, 0xf), /* MEM_INST_RETIRED.LOAD */ - INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_ST(0x2d0, 0xf), /* MEM_INST_RETIRED.STORE */ + INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x11d0, 0xf), /* MEM_INST_RETIRED.STLB_MISS_LOADS */ + INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_ST(0x12d0, 0xf), /* MEM_INST_RETIRED.STLB_MISS_STORES */ + INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x21d0, 0xf), /* MEM_INST_RETIRED.LOCK_LOADS */ + INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x41d0, 0xf), /* MEM_INST_RETIRED.SPLIT_LOADS */ + INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_ST(0x42d0, 0xf), /* MEM_INST_RETIRED.SPLIT_STORES */ + INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_LD(0x81d0, 0xf), /* MEM_INST_RETIRED.ALL_LOADS */ + INTEL_FLAGS_UEVENT_CONSTRAINT_DATALA_ST(0x82d0, 0xf), /* MEM_INST_RETIRED.ALL_STORES */ INTEL_FLAGS_EVENT_CONSTRAINT_DATALA_LD_RANGE(0xd1, 0xd4, 0xf), /* MEM_LOAD_*_RETIRED.* */ -- 2.35.1

2 years, 1 month

2
3
0 0

[PATCH] perf/x86/intel: Add Cooper Lake stepping to isolation_ucodes[]

by kan.liang＠linux.intel.com

From: Kan Liang <kan.liang(a)linux.intel.com> The intel_pebs_isolation quirk checks both model number and stepping. Cooper Lake has a different stepping (11) than the other Skylake Xeon. It cannot benefit from the optimization in commit 9b545c04abd4f ("perf/x86/kvm: Avoid unnecessary work in guest filtering"). Add the stepping of Cooper Lake into the isolation_ucodes[] table. Signed-off-by: Kan Liang <kan.liang(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- arch/x86/events/intel/core.c | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index d8af75466ee9..dfd2c124cdf8 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4908,6 +4908,7 @@ static const struct x86_cpu_desc isolation_ucodes[] = { INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 5, 0x00000000), INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 6, 0x00000000), INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 7, 0x00000000), + INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_X, 11, 0x00000000), INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE_L, 3, 0x0000007c), INTEL_CPU_DESC(INTEL_FAM6_SKYLAKE, 3, 0x0000007c), INTEL_CPU_DESC(INTEL_FAM6_KABYLAKE, 9, 0x0000004e), -- 2.35.1

2 years, 1 month

2
1
0 0

[PATCH AUTOSEL 5.19 01/10] signal: break out of wait loops on kthread_stop()

by Sasha Levin

From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> [ Upstream commit a7c01fa93aeb03ab76cd3cb2107990dd160498e6 ] I was recently surprised to learn that msleep_interruptible(), wait_for_completion_interruptible_timeout(), and related functions simply hung when I called kthread_stop() on kthreads using them. The solution to fixing the case with msleep_interruptible() was more simply to move to schedule_timeout_interruptible(). Why? The reason is that msleep_interruptible(), and many functions just like it, has a loop like this: while (timeout && !signal_pending(current)) timeout = schedule_timeout_interruptible(timeout); The call to kthread_stop() woke up the thread, so schedule_timeout_ interruptible() returned early, but because signal_pending() returned true, it went back into another timeout, which was never woken up. This wait loop pattern is common to various pieces of code, and I suspect that the subtle misuse in a kthread that caused a deadlock in the code I looked at last week is also found elsewhere. So this commit causes signal_pending() to return true when kthread_stop() is called, by setting TIF_NOTIFY_SIGNAL. The same also probably applies to the similar kthread_park() functionality, but that can be addressed later, as its semantics are slightly different. Cc: Eric W. Biederman <ebiederm(a)xmission.com> Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> v1: https://lkml.kernel.org/r/20220627120020.608117-1-Jason@zx2c4.com v2: https://lkml.kernel.org/r/20220627145716.641185-1-Jason@zx2c4.com v3: https://lkml.kernel.org/r/20220628161441.892925-1-Jason@zx2c4.com v4: https://lkml.kernel.org/r/20220711202136.64458-1-Jason@zx2c4.com v5: https://lkml.kernel.org/r/20220711232123.136330-1-Jason@zx2c4.com Signed-off-by: Eric W. Biederman <ebiederm(a)xmission.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- kernel/kthread.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/kthread.c b/kernel/kthread.c index 3c677918d8f2..7243a010f433 100644 --- a/kernel/kthread.c +++ b/kernel/kthread.c @@ -704,6 +704,7 @@ int kthread_stop(struct task_struct *k) kthread = to_kthread(k); set_bit(KTHREAD_SHOULD_STOP, &kthread->flags); kthread_unpark(k); + set_tsk_thread_flag(k, TIF_NOTIFY_SIGNAL); wake_up_process(k); wait_for_completion(&kthread->exited); ret = kthread->result; -- 2.35.1

2 years, 1 month

2
10
0 0

[PATCH AUTOSEL 6.0 01/11] signal: break out of wait loops on kthread_stop()

by Sasha Levin

From: "Jason A. Donenfeld" <Jason(a)zx2c4.com> [ Upstream commit a7c01fa93aeb03ab76cd3cb2107990dd160498e6 ] I was recently surprised to learn that msleep_interruptible(), wait_for_completion_interruptible_timeout(), and related functions simply hung when I called kthread_stop() on kthreads using them. The solution to fixing the case with msleep_interruptible() was more simply to move to schedule_timeout_interruptible(). Why? The reason is that msleep_interruptible(), and many functions just like it, has a loop like this: while (timeout && !signal_pending(current)) timeout = schedule_timeout_interruptible(timeout); The call to kthread_stop() woke up the thread, so schedule_timeout_ interruptible() returned early, but because signal_pending() returned true, it went back into another timeout, which was never woken up. This wait loop pattern is common to various pieces of code, and I suspect that the subtle misuse in a kthread that caused a deadlock in the code I looked at last week is also found elsewhere. So this commit causes signal_pending() to return true when kthread_stop() is called, by setting TIF_NOTIFY_SIGNAL. The same also probably applies to the similar kthread_park() functionality, but that can be addressed later, as its semantics are slightly different. Cc: Eric W. Biederman <ebiederm(a)xmission.com> Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> v1: https://lkml.kernel.org/r/20220627120020.608117-1-Jason@zx2c4.com v2: https://lkml.kernel.org/r/20220627145716.641185-1-Jason@zx2c4.com v3: https://lkml.kernel.org/r/20220628161441.892925-1-Jason@zx2c4.com v4: https://lkml.kernel.org/r/20220711202136.64458-1-Jason@zx2c4.com v5: https://lkml.kernel.org/r/20220711232123.136330-1-Jason@zx2c4.com Signed-off-by: Eric W. Biederman <ebiederm(a)xmission.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- kernel/kthread.c | 1 + 1 file changed, 1 insertion(+) diff --git a/kernel/kthread.c b/kernel/kthread.c index 3c677918d8f2..7243a010f433 100644 --- a/kernel/kthread.c +++ b/kernel/kthread.c @@ -704,6 +704,7 @@ int kthread_stop(struct task_struct *k) kthread = to_kthread(k); set_bit(KTHREAD_SHOULD_STOP, &kthread->flags); kthread_unpark(k); + set_tsk_thread_flag(k, TIF_NOTIFY_SIGNAL); wake_up_process(k); wait_for_completion(&kthread->exited); ret = kthread->result; -- 2.35.1

2 years, 1 month

2
11
0 0

[PATCH] soc: ux500: do not directly dereference __iomem

by Jason A. Donenfeld

Sparse reports that calling add_device_randomness() on `uid` is a violation of address spaces. And indeed the next usage uses readl() properly, but that was left out when passing it toadd_device_ randomness(). So instead copy the whole thing to the stack first. Fixes: 4040d10a3d44 ("ARM: ux500: add DB serial number to entropy pool") Cc: Linus Walleij <linus.walleij(a)linaro.org> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/202210230819.loF90KDh-lkp@intel.com/ Reported-by: kernel test robot <lkp(a)intel.com> Signed-off-by: Jason A. Donenfeld <Jason(a)zx2c4.com> --- Untested, but hopefully correct. drivers/soc/ux500/ux500-soc-id.c | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/drivers/soc/ux500/ux500-soc-id.c b/drivers/soc/ux500/ux500-soc-id.c index a9472e0e5d61..27d6e25a0115 100644 --- a/drivers/soc/ux500/ux500-soc-id.c +++ b/drivers/soc/ux500/ux500-soc-id.c @@ -167,20 +167,18 @@ ATTRIBUTE_GROUPS(ux500_soc); static const char *db8500_read_soc_id(struct device_node *backupram) { void __iomem *base; - void __iomem *uid; const char *retstr; + u32 uid[5]; base = of_iomap(backupram, 0); if (!base) return NULL; - uid = base + 0x1fc0; + memcpy_fromio(uid, base + 0x1fc0, sizeof(uid)); /* Throw these device-specific numbers into the entropy pool */ - add_device_randomness(uid, 0x14); + add_device_randomness(uid, sizeof(uid)); retstr = kasprintf(GFP_KERNEL, "%08x%08x%08x%08x%08x", - readl((u32 *)uid+0), - readl((u32 *)uid+1), readl((u32 *)uid+2), - readl((u32 *)uid+3), readl((u32 *)uid+4)); + uid[0], uid[1], uid[2], uid[3], uid[4]); iounmap(base); return retstr; } -- 2.38.1

2 years, 1 month

1
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2022