May 2020 - Linux-stable-mirror

[RFC] power: supply: bq27xxx_battery: Fix polling interval after re-bind

by Krzysztof Kozlowski

This reverts commit 8cfaaa811894a3ae2d7360a15a6cfccff3ebc7db. If device was unbound and bound, the polling interval would be set to 0. This is both unexpected and messes up with other bq27xxx devices (if more than one battery device is used). This reset of polling interval was added in commit 8cfaaa811894 ("bq27x00_battery: Fix OOPS caused by unregistring bq27x00 driver") stating that power_supply_unregister() calls get_property(). However in Linux kernel v3.1 and newer, such call trace does not exist. Unregistering power supply does not call get_property() on unregistered power supply. Fixes: 8cfaaa811894 ("bq27x00_battery: Fix OOPS caused by unregistring bq27x00 driver") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzk(a)kernel.org> --- I really could not identify the issue being fixed in offending commit 8cfaaa811894 ("bq27x00_battery: Fix OOPS caused by unregistring bq27x00 driver"), therefore maybe I missed here something important. Please share your thoughts on this. --- drivers/power/supply/bq27xxx_battery.c | 8 -------- 1 file changed, 8 deletions(-) diff --git a/drivers/power/supply/bq27xxx_battery.c b/drivers/power/supply/bq27xxx_battery.c index 942c92127b6d..4c94ee72de95 100644 --- a/drivers/power/supply/bq27xxx_battery.c +++ b/drivers/power/supply/bq27xxx_battery.c @@ -1905,14 +1905,6 @@ EXPORT_SYMBOL_GPL(bq27xxx_battery_setup); void bq27xxx_battery_teardown(struct bq27xxx_device_info *di) { - /* - * power_supply_unregister call bq27xxx_battery_get_property which - * call bq27xxx_battery_poll. - * Make sure that bq27xxx_battery_poll will not call - * schedule_delayed_work again after unregister (which cause OOPS). - */ - poll_interval = 0; - cancel_delayed_work_sync(&di->work); power_supply_unregister(di->bat); -- 2.17.1

4 years, 6 months

5
8
0 0

[PATCH v2] tty: xilinx_uartps: Fix missing id assignment to the console

by Michal Simek

From: Shubhrajyoti Datta <shubhrajyoti.datta(a)xilinx.com> When serial console has been assigned to ttyPS1 (which is serial1 alias) console index is not updated property and pointing to index -1 (statically initialized) which ends up in situation where nothing has been printed on the port. The commit 18cc7ac8a28e ("Revert "serial: uartps: Register own uart console and driver structures"") didn't contain this line which was removed by accident. Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta(a)xilinx.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- Changes in v2: - Do better commit description - Origin subject was "tty: xilinx_uartps: Add the id to the console" Greg: Would be good if you can take this patch to 5.7 and also to stable trees. --- drivers/tty/serial/xilinx_uartps.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c index 672cfa075e28..b9d672af8b65 100644 --- a/drivers/tty/serial/xilinx_uartps.c +++ b/drivers/tty/serial/xilinx_uartps.c @@ -1465,6 +1465,7 @@ static int cdns_uart_probe(struct platform_device *pdev) cdns_uart_uart_driver.nr = CDNS_UART_NR_PORTS; #ifdef CONFIG_SERIAL_XILINX_PS_UART_CONSOLE cdns_uart_uart_driver.cons = &cdns_uart_console; + cdns_uart_console.index = id; #endif rc = uart_register_driver(&cdns_uart_uart_driver); -- 2.26.2

4 years, 6 months

3
4
0 0

patch "serial: imx: Initialize lock for non-registered console" added to tty-next

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled serial: imx: Initialize lock for non-registered console to my tty git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git in the tty-next branch. The patch will show up in the next release of the linux-next tree (usually sometime within the next 24 hours during the week.) The patch will also be merged in the next major kernel release during the merge window. If you have any questions about this process, please let me know. >From 8f065acec7573672dd15916e31d1e9b2e785566c Mon Sep 17 00:00:00 2001 From: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Date: Mon, 25 May 2020 13:59:52 +0300 Subject: serial: imx: Initialize lock for non-registered console The commit a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") changed a bit logic behind lock initialization since for most of the console driver it's supposed to have lock already initialized even if console is not enabled. However, it's not the case for Freescale IMX console. Initialize lock explicitly in the ->probe(). Note, there is still an open question should or shouldn't not this driver register console properly. Fixes: a3cb39d258ef ("serial: core: Allow detach and attach serial device for console") Reported-by: Guenter Roeck <linux(a)roeck-us.net> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Link: https://lore.kernel.org/r/20200525105952.13744-1-andriy.shevchenko@linux.in… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/tty/serial/imx.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 986d902fb7fe..6b078e395931 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -2404,6 +2404,9 @@ static int imx_uart_probe(struct platform_device *pdev) } } + /* We need to initialize lock even for non-registered console */ + spin_lock_init(&sport->port.lock); + imx_uart_ports[sport->port.line] = sport; platform_set_drvdata(pdev, sport); -- 2.26.2

4 years, 6 months

4
4
0 0

[PATCH 1/2] e1000e: Do not wake up the system via WOL if device wakeup is disabled

by Chen Yu

Currently the system will be woken up via WOL(Wake On Lan) even if the device wakeup ability has been disabled via sysfs: cat /sys/devices/pci0000:00/0000:00:1f.6/power/wakeup disabled The system should not be woken up if the user has explicitly disabled the wake up ability for this device. This patch clears the WOL ability of this network device if the user has disabled the wake up ability in sysfs. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver") Reported-by: Rafael J. Wysocki <rafael.j.wysocki(a)intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko(a)linux.intel.com> Cc: <Stable(a)vger.kernel.org> Signed-off-by: Chen Yu <yu.c.chen(a)intel.com> --- drivers/net/ethernet/intel/e1000e/netdev.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c index 177c6da80c57..f6f730388705 100644 --- a/drivers/net/ethernet/intel/e1000e/netdev.c +++ b/drivers/net/ethernet/intel/e1000e/netdev.c @@ -6516,11 +6516,17 @@ static int __e1000_shutdown(struct pci_dev *pdev, bool runtime) struct net_device *netdev = pci_get_drvdata(pdev); struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; - u32 ctrl, ctrl_ext, rctl, status; - /* Runtime suspend should only enable wakeup for link changes */ - u32 wufc = runtime ? E1000_WUFC_LNKC : adapter->wol; + u32 ctrl, ctrl_ext, rctl, status, wufc; int retval = 0; + /* Runtime suspend should only enable wakeup for link changes */ + if (runtime) + wufc = E1000_WUFC_LNKC; + else if (device_may_wakeup(&pdev->dev)) + wufc = adapter->wol; + else + wufc = 0; + status = er32(STATUS); if (status & E1000_STATUS_LU) wufc &= ~E1000_WUFC_LNKC; @@ -6577,7 +6583,7 @@ static int __e1000_shutdown(struct pci_dev *pdev, bool runtime) if (adapter->hw.phy.type == e1000_phy_igp_3) { e1000e_igp3_phy_powerdown_workaround_ich8lan(&adapter->hw); } else if (hw->mac.type >= e1000_pch_lpt) { - if (!(wufc & (E1000_WUFC_EX | E1000_WUFC_MC | E1000_WUFC_BC))) + if (wufc && !(wufc & (E1000_WUFC_EX | E1000_WUFC_MC | E1000_WUFC_BC))) /* ULP does not support wake from unicast, multicast * or broadcast. */ -- 2.17.1

4 years, 6 months

3
4
0 0

[PATCH] ARM: tegra: Fix restoration of PLLM when exiting suspend

by Jon Hunter

The suspend entry and exit code for 32-bit Tegra devices assumes that the PLLM (which is used to provide the clock for external memory) is always enabled on entry to suspend. Hence, the current code always disables the PLLM on entry to suspend and re-enables the PLLM on exit from suspend. Since the introduction of the Tegra124 EMC driver by commit 73a7f0a90641 ("memory: tegra: Add EMC (external memory controller) driver"), which is used to scale the EMC frequency, PLLM may not be the current clock source for the EMC on entry to suspend and hence may not be enabled. Always enabling the PLLM on exit from suspend can cause the actual status on the PLL to be different from that reported by the common clock framework. On kernels prior to v4.5, the code to set the rate of the PLLM had a test to verify if the PLL was enabled and if the PLL was enabled, setting the rate would fail. Since commit 267b62a96951 ("clk: tegra: pll: Update PLLM handling") the test to see if PLLM is enabled was removed. With these earlier kernels, if the PLLM is disabled on entering suspend and the EMC driver attempts to set the parent of the EMC clock to the PLLM on exiting suspend, then the set rate for the PLLM will fail and in turn cause the resume to fail. We should not be re-enabling the PLLM on resume from suspend unless it was enabled on entry to suspend. Therefore, fix this by saving the state of PLLM on entry to suspend and only re-enable it, if it was already enabled. Fixes: 73a7f0a90641 ("memory: tegra: Add EMC (external memory controller) driver") Cc: stable(a)vger.kernel.org Signed-off-by: Jon Hunter <jonathanh(a)nvidia.com> --- arch/arm/mach-tegra/sleep-tegra30.S | 33 +++++++++++++++++++++++------ 1 file changed, 27 insertions(+), 6 deletions(-) diff --git a/arch/arm/mach-tegra/sleep-tegra30.S b/arch/arm/mach-tegra/sleep-tegra30.S index 3341a12bbb9c..c2f0793a424f 100644 --- a/arch/arm/mach-tegra/sleep-tegra30.S +++ b/arch/arm/mach-tegra/sleep-tegra30.S @@ -337,26 +337,42 @@ ENTRY(tegra30_lp1_reset) add r1, r1, #2 wait_until r1, r7, r3 - /* enable PLLM via PMC */ + /* restore PLLM state */ mov32 r2, TEGRA_PMC_BASE + adr r7, tegra_pllm_status + ldr r1, [r7] + cmp r2, #(1 << 12) + bne _skip_pllm + ldr r1, [r2, #PMC_PLLP_WB0_OVERRIDE] orr r1, r1, #(1 << 12) str r1, [r2, #PMC_PLLP_WB0_OVERRIDE] pll_enable r1, r0, CLK_RESET_PLLM_BASE, 0 + pll_locked r1, r0, CLK_RESET_PLLM_BASE + +_skip_pllm: pll_enable r1, r0, CLK_RESET_PLLC_BASE, 0 pll_enable r1, r0, CLK_RESET_PLLX_BASE, 0 b _pll_m_c_x_done _no_pll_iddq_exit: - /* enable PLLM via PMC */ + /* restore PLLM state */ mov32 r2, TEGRA_PMC_BASE + adr r7, tegra_pllm_status + ldr r1, [r7] + cmp r2, #(1 << 12) + bne _skip_pllm_no_iddq + ldr r1, [r2, #PMC_PLLP_WB0_OVERRIDE] orr r1, r1, #(1 << 12) str r1, [r2, #PMC_PLLP_WB0_OVERRIDE] pll_enable r1, r0, CLK_RESET_PLLM_BASE, CLK_RESET_PLLM_MISC + pll_locked r1, r0, CLK_RESET_PLLM_BASE + +_skip_pllm_no_iddq: pll_enable r1, r0, CLK_RESET_PLLC_BASE, CLK_RESET_PLLC_MISC pll_enable r1, r0, CLK_RESET_PLLX_BASE, CLK_RESET_PLLX_MISC @@ -364,7 +380,6 @@ _pll_m_c_x_done: pll_enable r1, r0, CLK_RESET_PLLP_BASE, CLK_RESET_PLLP_MISC pll_enable r1, r0, CLK_RESET_PLLA_BASE, CLK_RESET_PLLA_MISC - pll_locked r1, r0, CLK_RESET_PLLM_BASE pll_locked r1, r0, CLK_RESET_PLLP_BASE pll_locked r1, r0, CLK_RESET_PLLA_BASE pll_locked r1, r0, CLK_RESET_PLLC_BASE @@ -526,6 +541,8 @@ __no_dual_emc_chanl: ENDPROC(tegra30_lp1_reset) .align L1_CACHE_SHIFT +tegra_pllm_status: + .word 0 tegra30_sdram_pad_address: .word TEGRA_EMC_BASE + EMC_CFG @0x0 .word TEGRA_EMC_BASE + EMC_ZCAL_INTERVAL @0x4 @@ -624,10 +641,14 @@ tegra30_switch_cpu_to_clk32k: add r1, r1, #2 wait_until r1, r7, r9 - /* disable PLLM via PMC in LP1 */ + /* disable PLLM, if enabled, via PMC in LP1 */ + adr r1, tegra_pllm_status ldr r0, [r4, #PMC_PLLP_WB0_OVERRIDE] - bic r0, r0, #(1 << 12) - str r0, [r4, #PMC_PLLP_WB0_OVERRIDE] + and r2, r0, #(1 << 12) + str r2, [r1] + cmp r2, #(1 << 12) + biceq r0, r0, #(1 << 12) + streq r0, [r4, #PMC_PLLP_WB0_OVERRIDE] /* disable PLLP, PLLA, PLLC and PLLX */ ldr r0, [r5, #CLK_RESET_PLLP_BASE] -- 2.17.1

4 years, 6 months

4
10
0 0

[PATCH v2] KVM: x86: respect singlestep when emulating instruction

by Felipe Franciosi

When userspace configures KVM_GUESTDBG_SINGLESTEP, KVM will manage the presence of X86_EFLAGS_TF via kvm_set/get_rflags on vcpus. The actual rflag bit is therefore hidden from callers. That includes init_emulate_ctxt() which uses the value returned from kvm_get_flags() to set ctxt->tf. As a result, x86_emulate_instruction() will skip a single step, leaving singlestep_rip stale and not returning to userspace. This resolves the issue by observing the vcpu guest_debug configuration alongside ctxt->tf in x86_emulate_instruction(), performing the single step if set. Signed-off-by: Felipe Franciosi <felipe(a)nutanix.com> --- arch/x86/kvm/x86.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index c17e6eb9ad43..64cb183636da 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -6919,7 +6919,7 @@ int x86_emulate_instruction(struct kvm_vcpu *vcpu, gpa_t cr2_or_gpa, if (!ctxt->have_exception || exception_type(ctxt->exception.vector) == EXCPT_TRAP) { kvm_rip_write(vcpu, ctxt->eip); - if (r && ctxt->tf) + if (r && (ctxt->tf || (vcpu->guest_debug & KVM_GUESTDBG_SINGLESTEP))) r = kvm_vcpu_do_singlestep(vcpu); if (kvm_x86_ops.update_emulated_instruction) kvm_x86_ops.update_emulated_instruction(vcpu); -- 2.20.1

4 years, 6 months

2
1
0 0

[PATCH 4.19.y] selftests: bpf: fix use of undeclared RET_IF macro

by Lorenz Bauer

commit 634efb750435 ("selftests: bpf: Reset global state between reuseport test runs") uses a macro RET_IF which doesn't exist in the v4.19 tree. It is defined as follows: #define RET_IF(condition, tag, format...) ({ if (CHECK_FAIL(condition)) { printf(tag " " format); return; } }) CHECK_FAIL in turn is defined as: #define CHECK_FAIL(condition) ({ int __ret = !!(condition); int __save_errno = errno; if (__ret) { test__fail(); fprintf(stdout, "%s:FAIL:%d\n", __func__, __LINE__); } errno = __save_errno; __ret; }) Replace occurences of RET_IF with CHECK. This will abort the test binary if clearing the intermediate state fails. Fixes: 634efb750435 ("selftests: bpf: Reset global state between reuseport test runs") Reported-by: kernel test robot <rong.a.chen(a)intel.com> Signed-off-by: Lorenz Bauer <lmb(a)cloudflare.com> --- tools/testing/selftests/bpf/test_select_reuseport.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/testing/selftests/bpf/test_select_reuseport.c b/tools/testing/selftests/bpf/test_select_reuseport.c index cdbbdab2725f..b14d25bfa830 100644 --- a/tools/testing/selftests/bpf/test_select_reuseport.c +++ b/tools/testing/selftests/bpf/test_select_reuseport.c @@ -616,13 +616,13 @@ static void cleanup_per_test(void) for (i = 0; i < NR_RESULTS; i++) { err = bpf_map_update_elem(result_map, &i, &zero, BPF_ANY); - RET_IF(err, "reset elem in result_map", - "i:%u err:%d errno:%d\n", i, err, errno); + CHECK(err, "reset elem in result_map", + "i:%u err:%d errno:%d\n", i, err, errno); } err = bpf_map_update_elem(linum_map, &zero, &zero, BPF_ANY); - RET_IF(err, "reset line number in linum_map", "err:%d errno:%d\n", - err, errno); + CHECK(err, "reset line number in linum_map", "err:%d errno:%d\n", + err, errno); for (i = 0; i < REUSEPORT_ARRAY_SIZE; i++) close(sk_fds[i]); -- 2.20.1

4 years, 6 months

3
7
0 0

stable-rc 5.4: libhugetlbfs fallocate_stress.sh: Unable to handle kernel paging request at virtual address ffff00006772f000

by Naresh Kamboju

While running libhugetlbfs fallocate_stress.sh on stable-rc 5.4 branch kernel on arm64 hikey device. The following kernel Internal error: Oops: crash dump noticed. fallocate_stress.sh (2M: 64): [ 129.706506] Unable to handle kernel paging request at virtual address ffff00006772f000 [ 129.714638] Mem abort info: [ 129.717553] ESR = 0x96000047 [ 129.720726] EC = 0x25: DABT (current EL), IL = 32 bits [ 129.726188] SET = 0, FnV = 0 [ 129.729338] EA = 0, S1PTW = 0 [ 129.732573] Data abort info: [ 129.735546] ISV = 0, ISS = 0x00000047 [ 129.739493] CM = 0, WnR = 1 [ 129.742534] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000013ad000 [ 129.749409] [ffff00006772f000] pgd=0000000077ff7003, pud=0000000077e0d003, pmd=0000000077cd1003, pte=006800006772f713 [ 129.760294] Internal error: Oops: 96000047 [#1] PREEMPT SMP [ 129.765988] Modules linked in: wl18xx wlcore mac80211 cfg80211 hci_uart snd_soc_audio_graph_card adv7511 crct10dif_ce wlcore_sdio btbcm snd_soc_simple_card_utils cec kirin_drm bluetooth drm_kms_helper dw_drm_dsi rfkill drm fuse [ 129.786626] CPU: 1 PID: 1263 Comm: fallocate_stres Not tainted 5.4.41-rc1-00091-g132220af41e6 #1 [ 129.795601] Hardware name: HiKey Development Board (DT) [ 129.800940] pstate: 80000005 (Nzcv daif -PAN -UAO) [ 129.805847] pc : clear_page+0x10/0x24 [ 129.809594] lr : __cpu_clear_user_page+0xc/0x18 [ 129.814225] sp : ffff800012a1bbe0 [ 129.817609] x29: ffff800012a1bbe0 x28: fffffe00017d8000 [ 129.823039] x27: ffff000073070268 x26: ffff800011adf000 [ 129.828466] x25: ffff800011ae06c8 x24: 0000000000001000 [ 129.833893] x23: 0000000000000000 x22: fffffe00017d8000 [ 129.839320] x21: 0000000000000000 x20: 0000000006a00000 [ 129.844747] x19: ffff000037945400 x18: 0000000000000000 [ 129.850174] x17: 0000000000000000 x16: 0000000000000000 [ 129.855602] x15: 0000000000000000 x14: 0000000000000000 [ 129.861031] x13: 0000000000000000 x12: 0000000000000000 [ 129.866458] x11: 0000000000000000 x10: ffff800012a1bbd0 [ 129.871886] x9 : 0000000000000200 x8 : 0ffff00000010000 [ 129.877314] x7 : 0000000000000000 x6 : 0000000000000080 [ 129.882741] x5 : 0000000000000036 x4 : 0000020000200000 [ 129.888170] x3 : 0000000000004bc0 x2 : 0000000000000004 [ 129.893597] x1 : 0000000000000040 x0 : ffff00006772f000 [ 129.899025] Call trace: [ 129.901530] clear_page+0x10/0x24 [ 129.904926] clear_subpage+0x54/0x90 [ 129.908580] clear_huge_page+0x6c/0x208 [ 129.912503] hugetlbfs_fallocate+0x2e0/0x4a0 [ 129.916869] vfs_fallocate+0x1b8/0x2e0 [ 129.920699] ksys_fallocate+0x44/0x90 [ 129.924446] __arm64_sys_fallocate+0x1c/0x28 [ 129.928811] el0_svc_common.constprop.0+0x68/0x160 [ 129.933708] el0_svc_handler+0x20/0x80 [ 129.937539] el0_svc+0x8/0xc [ 129.940488] Code: d53b00e1 12000c21 d2800082 9ac12041 (d50b7420) [ 129.946719] ---[ end trace df98e92a449be749 ]--- [ 129.959274] note: fallocate_stres[1263] exited with preempt_count 1 ref: https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.40-91-… https://qa-reports.linaro.org/lkft/linux-stable-rc-5.4-oe/build/v5.4.40-91-… kernel config: https://builds.tuxbuild.com/SqvcoklXmvQsC70j6rfcgA/kernel.config -- Linaro LKFT https://lkft.linaro.org

4 years, 6 months

3
3
0 0

[PATCH] x86_64: fix jiffies ODR violation

by Bob Haarman

`jiffies` and `jiffies_64` are meant to alias (two different symbols that share the same address). Most architectures make the symbols alias to the same address via linker script assignment in their arch/<arch>/kernel/vmlinux.lds.S: jiffies = jiffies_64; which is effectively a definition of jiffies. jiffies and jiffies_64 are both forward declared for all arch's in: include/linux/jiffies.h. jiffies_64 is defined in kernel/time/timer.c for all arch's. x86_64 was peculiar in that it wasn't doing the above linker script assignment, but rather was: 1. defining jiffies in arch/x86/kernel/time.c instead via linker script. 2. overriding the symbol jiffies_64 from kernel/time/timer.c in arch/x86/kernel/vmlinux.lds.s via `jiffies_64 = jiffies;`. As Fangrui notes: ``` In LLD, symbol assignments in linker scripts override definitions in object files. GNU ld appears to have the same behavior. It would probably make sense for LLD to error "duplicate symbol" but GNU ld is unlikely to adopt for compatibility reasons. ``` So we have an ODR violation (UB), which we seem to have gotten away with thus far. Where it becomes harmful is when we: 1. Use -fno-semantic-interposition. As Fangrui notes: ``` Clang after LLVM commit 5b22bcc2b70d ("[X86][ELF] Prefer to lower MC_GlobalAddress operands to .Lfoo$local") defaults to -fno-semantic-interposition similar semantics which help -fpic/-fPIC code avoid GOT/PLT when the referenced symbol is defined within the same translation unit. Unlike GCC -fno-semantic-interposition, Clang emits such relocations referencing local symbols for non-pic code as well. ``` This causes references to jiffies to refer to `.Ljiffies$local` when jiffies is defined in the same translation unit. Likewise, references to jiffies_64 become references to `.Ljiffies_64$local` in translation units that define jiffies_64. Because these differ from the names used in the linker script, they will not be rewritten to alias one another. Combined with ... 2. Full LTO effectively treats all source files as one translation unit, causing these local references to be produced everywhere. When the linker processes the linker script, there are no longer any references to `jiffies_64` anywhere to replace with `jiffies`. And thus `.Ljiffies$local` and `.Ljiffies_64$local` no longer alias at all. In the process of porting patches enabling Full LTO from arm64 to x86_64, we observe spooky bugs where the kernel appeared to boot, but init doesn't get scheduled. Instead, we can avoid the ODR violation by matching other arch's by defining jiffies only by linker script. For -fno-semantic-interposition + Full LTO, there is no longer a global definition of jiffies for the compiler to produce a local symbol which the linker script won't ensure aliases to jiffies_64. Link: https://github.com/ClangBuiltLinux/linux/issues/852 Fixes: 40747ffa5aa8 ("asmlinkage: Make jiffies visible") Cc: stable(a)vger.kernel.org Reported-by: Nathan Chancellor <natechancellor(a)gmail.com> Reported-by: Alistair Delva <adelva(a)google.com> Suggested-by: Fangrui Song <maskray(a)google.com> Debugged-by: Nick Desaulniers <ndesaulniers(a)google.com> Debugged-by: Sami Tolvanen <samitolvanen(a)google.com> Signed-off-by: Bob Haarman <inglorion(a)google.com> --- arch/x86/kernel/time.c | 4 ---- arch/x86/kernel/vmlinux.lds.S | 4 ++-- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/time.c b/arch/x86/kernel/time.c index 371a6b348e44..e42faa792c07 100644 --- a/arch/x86/kernel/time.c +++ b/arch/x86/kernel/time.c @@ -25,10 +25,6 @@ #include <asm/hpet.h> #include <asm/time.h> -#ifdef CONFIG_X86_64 -__visible volatile unsigned long jiffies __cacheline_aligned_in_smp = INITIAL_JIFFIES; -#endif - unsigned long profile_pc(struct pt_regs *regs) { unsigned long pc = instruction_pointer(regs); diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S index 1bf7e312361f..7c35556c7827 100644 --- a/arch/x86/kernel/vmlinux.lds.S +++ b/arch/x86/kernel/vmlinux.lds.S @@ -40,13 +40,13 @@ OUTPUT_FORMAT(CONFIG_OUTPUT_FORMAT) #ifdef CONFIG_X86_32 OUTPUT_ARCH(i386) ENTRY(phys_startup_32) -jiffies = jiffies_64; #else OUTPUT_ARCH(i386:x86-64) ENTRY(phys_startup_64) -jiffies_64 = jiffies; #endif +jiffies = jiffies_64; + #if defined(CONFIG_X86_64) /* * On 64-bit, align RODATA to 2MB so we retain large page mappings for -- 2.26.2.761.g0e0b3e54be-goog

4 years, 6 months

6
8
0 0

[PATCH] powerpc/fadump: account for memory_limit while reserving memory

by Hari Bathini

If the memory chunk found for reserving memory overshoots the memory limit imposed, do not proceed with reserving memory. Default behavior was this until commit 140777a3d8df ("powerpc/fadump: consider reserved ranges while reserving memory") changed it unwittingly. Reported-by: kbuild test robot <lkp(a)intel.com> Fixes: 140777a3d8df ("powerpc/fadump: consider reserved ranges while reserving memory") Cc: stable(a)vger.kernel.org Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com> --- For reference: - https://lists.ozlabs.org/pipermail/linuxppc-dev/2020-May/211136.html arch/powerpc/kernel/fadump.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c index 63aac8b..78ab9a6 100644 --- a/arch/powerpc/kernel/fadump.c +++ b/arch/powerpc/kernel/fadump.c @@ -603,7 +603,7 @@ int __init fadump_reserve_mem(void) */ base = fadump_locate_reserve_mem(base, size); - if (!base) { + if (!base || (base + size > mem_boundary)) { pr_err("Failed to find memory chunk for reservation!\n"); goto error_out; }

4 years, 6 months

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror May 2020