January 2024 - Linux-stable-mirror

[PATCH bpf-next v12 3/4] bpf: Fix re-attachment branch in bpf_tracing_prog_attach

by Dmitrii Dolgov

From: Jiri Olsa <olsajiri(a)gmail.com> The following case can cause a crash due to missing attach_btf: 1) load rawtp program 2) load fentry program with rawtp as target_fd 3) create tracing link for fentry program with target_fd = 0 4) repeat 3 In the end we have: - prog->aux->dst_trampoline == NULL - tgt_prog == NULL (because we did not provide target_fd to link_create) - prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X) - the program was loaded for tgt_prog but we have no way to find out which one BUG: kernel NULL pointer dereference, address: 0000000000000058 Call Trace: <TASK> ? __die+0x20/0x70 ? page_fault_oops+0x15b/0x430 ? fixup_exception+0x22/0x330 ? exc_page_fault+0x6f/0x170 ? asm_exc_page_fault+0x22/0x30 ? bpf_tracing_prog_attach+0x279/0x560 ? btf_obj_id+0x5/0x10 bpf_tracing_prog_attach+0x439/0x560 __sys_bpf+0x1cf4/0x2de0 __x64_sys_bpf+0x1c/0x30 do_syscall_64+0x41/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 Return -EINVAL in this situation. Fixes: f3a95075549e0 ("bpf: Allow trampoline re-attach for tracing and lsm programs") Cc: stable(a)vger.kernel.org Signed-off-by: Jiri Olsa <olsajiri(a)gmail.com> Acked-by: Jiri Olsa <olsajiri(a)gmail.com> Acked-by: Song Liu <song(a)kernel.org> Signed-off-by: Dmitrii Dolgov <9erthalion6(a)gmail.com> --- kernel/bpf/syscall.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c index c40cad8886e9..5096ddfbe426 100644 --- a/kernel/bpf/syscall.c +++ b/kernel/bpf/syscall.c @@ -3201,6 +3201,10 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog, * * - if prog->aux->dst_trampoline and tgt_prog is NULL, the program * was detached and is going for re-attachment. + * + * - if prog->aux->dst_trampoline is NULL and tgt_prog and prog->aux->attach_btf + * are NULL, then program was already attached and user did not provide + * tgt_prog_fd so we have no way to find out or create trampoline */ if (!prog->aux->dst_trampoline && !tgt_prog) { /* @@ -3214,6 +3218,11 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog, err = -EINVAL; goto out_unlock; } + /* We can allow re-attach only if we have valid attach_btf. */ + if (!prog->aux->attach_btf) { + err = -EINVAL; + goto out_unlock; + } btf_id = prog->aux->attach_btf_id; key = bpf_trampoline_compute_key(NULL, prog->aux->attach_btf, btf_id); } -- 2.41.0

1 year, 11 months

1
0
0 0

Re: [PATCH 6.6 00/49] 6.6.10-rc1 review

by Ronald Warsow

Hi Greg no regressions here on x86_64 (Intel Rocket Lake: i5-11400) Thanks Tested-by: Ronald Warsow <rwarsow(a)gmx.de>

1 year, 11 months

1
0
0 0

FAILED: patch "[PATCH] tracing/kprobes: Fix symbol counting logic by looking at" failed to apply to 6.1-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 6.1-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.1.y git checkout FETCH_HEAD git cherry-pick -x 926fe783c8a64b33997fec405cf1af3e61aed441 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2023102922-handwrite-unpopular-0e1d@gregkh' --subject-prefix 'PATCH 6.1.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From 926fe783c8a64b33997fec405cf1af3e61aed441 Mon Sep 17 00:00:00 2001 From: Andrii Nakryiko <andrii(a)kernel.org> Date: Fri, 27 Oct 2023 16:31:26 -0700 Subject: [PATCH] tracing/kprobes: Fix symbol counting logic by looking at modules as well Recent changes to count number of matching symbols when creating a kprobe event failed to take into account kernel modules. As such, it breaks kprobes on kernel module symbols, by assuming there is no match. Fix this my calling module_kallsyms_on_each_symbol() in addition to kallsyms_on_each_match_symbol() to perform a proper counting. Link: https://lore.kernel.org/all/20231027233126.2073148-1-andrii@kernel.org/ Cc: Francis Laniel <flaniel(a)linux.microsoft.com> Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Steven Rostedt <rostedt(a)goodmis.org> Fixes: b022f0c7e404 ("tracing/kprobes: Return EADDRNOTAVAIL when func matches several symbols") Signed-off-by: Andrii Nakryiko <andrii(a)kernel.org> Acked-by: Song Liu <song(a)kernel.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c index 95c5b0668cb7..e834f149695b 100644 --- a/kernel/trace/trace_kprobe.c +++ b/kernel/trace/trace_kprobe.c @@ -714,14 +714,30 @@ static int count_symbols(void *data, unsigned long unused) return 0; } +struct sym_count_ctx { + unsigned int count; + const char *name; +}; + +static int count_mod_symbols(void *data, const char *name, unsigned long unused) +{ + struct sym_count_ctx *ctx = data; + + if (strcmp(name, ctx->name) == 0) + ctx->count++; + + return 0; +} + static unsigned int number_of_same_symbols(char *func_name) { - unsigned int count; + struct sym_count_ctx ctx = { .count = 0, .name = func_name }; + + kallsyms_on_each_match_symbol(count_symbols, func_name, &ctx.count); - count = 0; - kallsyms_on_each_match_symbol(count_symbols, func_name, &count); + module_kallsyms_on_each_symbol(NULL, count_mod_symbols, &ctx); - return count; + return ctx.count; } static int __trace_kprobe_create(int argc, const char *argv[])

1 year, 11 months

5
7
0 0

[PATCH stable 5.15 0/1] bpf: Fix map poke update

by Jiri Olsa

hi, sending the 5.15 backport of map poke update fix [1]. It's not straight backport, the details are in changelog. I also backported the bpf selftest [2] to reproduce the issue and verify the fix, but it's more deviated from the upstream so I decided not to post it. Also I had to fix bpf selftests on other place to be able to compile them. thanks, jirka [1] 4b7de801606e ("bpf: Fix prog_array_map_poke_run map poke update") [2] ffed24eff9e0 ("selftests/bpf: Add test for early update in prog_array_map_poke_run") --- Jiri Olsa (1): bpf: Fix prog_array_map_poke_run map poke update arch/x86/net/bpf_jit_comp.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ include/linux/bpf.h | 3 +++ kernel/bpf/arraymap.c | 58 ++++++++++------------------------------------------------ 3 files changed, 59 insertions(+), 48 deletions(-)

1 year, 11 months

2
2
0 0

[PATCH 1/2] dt-bindings: thermal: correct thermal zone node name limit

by Krzysztof Kozlowski

Linux kernel uses thermal zone node name during registering thermal zones and has a hard-coded limit of 20 characters, including terminating NUL byte. The bindings expect node names to finish with '-thermal' which is eight bytes long, thus we have only 11 characters for the reset of the node name, not 12. Reported-by: Rob Herring <robh(a)kernel.org> Closes: https://lore.kernel.org/all/CAL_JsqKogbT_4DPd1n94xqeHaU_J8ve5K09WOyVsRX3jxx… Fixes: 1202a442a31f ("dt-bindings: thermal: Add yaml bindings for thermal zones") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- Documentation/devicetree/bindings/thermal/thermal-zones.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml index 4a8dabc48170..bbc883fd4044 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-zones.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-zones.yaml @@ -49,7 +49,7 @@ properties: to take when the temperature crosses those thresholds. patternProperties: - "^[a-zA-Z][a-zA-Z0-9\\-]{1,12}-thermal$": + "^[a-zA-Z][a-zA-Z0-9\\-]{1,11}-thermal$": type: object description: Each thermal zone node contains information about how frequently it -- 2.34.1

1 year, 11 months

2
2
0 0

[RFC 0/2] PCI: acpiphp: workaround race between hotplug and SCSI_SCAN_ASYNC job

by Igor Mammedov

Hacks to mask a race between HBA scan job and bridge re-configuration(s) during hotplug. I don't like it a bit but it something that could be done quickly and solves problems that were reported. Other options to discuss/possibly more invasive: 1: make sure pci_assign_unassigned_bridge_resources() doesn't reconfigure bridge if it's not necessary. 2. make SCSI_SCAN_ASYNC job wait till hotplug is finished for all slots on the bridge or somehow restart the job if it fails 3. any other ideas? 1st reported: https://lore.kernel.org/r/9eb669c0-d8f2-431d-a700-6da13053ae54@proxmox.com CC: Dongli Zhang <dongli.zhang(a)oracle.com> CC: linux-acpi(a)vger.kernel.org CC: linux-pci(a)vger.kernel.org CC: imammedo(a)redhat.com CC: mst(a)redhat.com CC: rafael(a)kernel.org CC: lenb(a)kernel.org CC: bhelgaas(a)google.com CC: mika.westerberg(a)linux.intel.com CC: boris.ostrovsky(a)oracle.com CC: joe.jin(a)oracle.com CC: stable(a)vger.kernel.org CC: linux-kernel(a)vger.kernel.org CC: Fiona Ebner <f.ebner(a)proxmox.com> CC: Thomas Lamprecht <t.lamprecht(a)proxmox.com> Igor Mammedov (2): PCI: acpiphp: enable slot only if it hasn't been enabled already PCI: acpiphp: slowdown hotplug if hotplugging multiple devices at a time drivers/pci/hotplug/acpiphp_glue.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) -- 2.39.3

1 year, 11 months

8
22
0 0

Re: [RFC PATCH] drm/amd/display: fix bandwidth validation failure on DCN 2.1

by Hamza Mahfooz

On 12/29/23 11:25, Melissa Wen wrote: > IGT `amdgpu/amd_color/crtc-lut-accuracy` fails right at the beginning of > the test execution, during atomic check, because DC rejects the > bandwidth state for a fb sizing 64x64. The test was previously working > with the deprecated dc_commit_state(). Now using > dc_validate_with_context() approach, the atomic check needs to perform a > full state validation. Therefore, set fast_validation to false in the > dc_validate_global_state call for atomic check. > > Fixes: b8272241ff9d ("drm/amd/display: Drop dc_commit_state in favor of dc_commit_streams") > Signed-off-by: Melissa Wen <mwen(a)igalia.com> > --- > > Hi, > > It's a long story. I was inspecting this bug report: > - https://gitlab.freedesktop.org/drm/amd/-/issues/2016 > and noticed the IGT test `igt@amdgpu/amd_color@crtc-lut-accuracy` > mentioned there wasn't even being executed on a laptop with DCN 2.1 > (HP HP ENVY x360 Convertible 13-ay1xxx/8929). The test fails right at > the beginning due to an atomic check rejection, as below: > > Starting subtest: crtc-lut-accuracy > (amd_color:14772) igt_kms-CRITICAL: Test assertion failure function igt_display_commit_atomic, file ../lib/igt_kms.c:4530: > (amd_color:14772) igt_kms-CRITICAL: Failed assertion: ret == 0 > (amd_color:14772) igt_kms-CRITICAL: Last errno: 22, Invalid argument > (amd_color:14772) igt_kms-CRITICAL: error: -22 != 0 > Stack trace: > #0 ../lib/igt_core.c:1989 __igt_fail_assert() > #1 [igt_display_commit_atomic+0x44] > #2 ../tests/amdgpu/amd_color.c:159 __igt_unique____real_main395() > #3 ../tests/amdgpu/amd_color.c:395 main() > #4 ../sysdeps/nptl/libc_start_call_main.h:74 __libc_start_call_main() > #5 ../csu/libc-start.c:128 __libc_start_main@@GLIBC_2.34() > #6 [_start+0x21] > Subtest crtc-lut-accuracy failed. > > Checking dmesg, we can see that a bandwidth validation failure causes > the atomic check rejection: > > [ 711.147663] amdgpu 0000:04:00.0: [drm] Mode Validation Warning: Unknown Status failed validation. > [ 711.147667] [drm:amdgpu_dm_atomic_check [amdgpu]] DC global validation failure: Bandwidth validation failure (BW and Watermark) (13) > [ 711.147772] [drm:amdgpu_irq_dispatch [amdgpu]] Unregistered interrupt src_id: 243 of client_id:8 > [ 711.148033] [drm:amdgpu_dm_atomic_check [amdgpu]] Atomic check failed with err: -22 > > I also noticed that the atomic check doesn't fail if I change the fb > width and height used in the test from 64 to 66, and I can get the test > execution back (and with success). However, I recall that all test cases > of IGT `amd_color` were working in the past, so I bisected and found the > first bad commit: > > b8272241ff9d drm/amd/display: Drop dc_commit_state in favor of dc_commit_streams > > Bringing the `dc_commit_state` machinery back also prevents the > bandwidth validation failure, but the commit above says > dc_commit_streams validation is more complete than dc_commit_state, so I > discarded this approach. > > After some debugging and code inspection, I found out that avoiding fast > validation on dc_validate_global_state during atomic check solves the > issue, but I'm not sure if this change may affect performance. I > compared exec time of some IGT tests and didn't see any differences, but > I recognize it doesn't provide enough evidence. > > What do you think about this change? Should I examine other things? Do > you see any potential issue that I should investigate? Could you > recommend a better approach to assess any side-effect of not enabling > fast validation in the atomic check? > > Please, let me know your thoughts. We shouldn't be doing fast updates when lock_and_validation_needed is true, so this seems to be correct. Which is to say, applied, thanks! Cc: stable(a)vger.kernel.org > > Happy New Year! > > Melissa > > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > index 2845c884398e..4f51a7ad7a3c 100644 > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c > @@ -10745,7 +10745,7 @@ static int amdgpu_dm_atomic_check(struct drm_device *dev, > DRM_DEBUG_DRIVER("drm_dp_mst_atomic_check() failed\n"); > goto fail; > } > - status = dc_validate_global_state(dc, dm_state->context, true); > + status = dc_validate_global_state(dc, dm_state->context, false); > if (status != DC_OK) { > DRM_DEBUG_DRIVER("DC global validation failure: %s (%d)", > dc_status_to_str(status), status); -- Hamza

1 year, 11 months

2
1
0 0

[PATCH net v2 1/2] rtnetlink: allow to set iface down before enslaving it

by Nicolas Dichtel

The below commit adds support for: > ip link set dummy0 down > ip link set dummy0 master bond0 up but breaks the opposite: > ip link set dummy0 up > ip link set dummy0 master bond0 down Let's add a workaround to have both commands working. Cc: stable(a)vger.kernel.org Fixes: a4abfa627c38 ("net: rtnetlink: Enslave device before bringing it up") Signed-off-by: Nicolas Dichtel <nicolas.dichtel(a)6wind.com> Acked-by: Phil Sutter <phil(a)nwl.cc> --- net/core/rtnetlink.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index e8431c6c8490..dd79693c2d91 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -2905,6 +2905,14 @@ static int do_setlink(const struct sk_buff *skb, call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); } + /* Backward compat: enable to set interface down before enslaving it */ + if (!(ifm->ifi_flags & IFF_UP) && ifm->ifi_change & IFF_UP) { + err = dev_change_flags(dev, rtnl_dev_combine_flags(dev, ifm), + extack); + if (err < 0) + goto errout; + } + if (tb[IFLA_MASTER]) { err = do_set_master(dev, nla_get_u32(tb[IFLA_MASTER]), extack); if (err) -- 2.39.2

1 year, 11 months

2
1
0 0

[PATCH v7 0/5] mfd: tps6586x: register restart handler

by Benjamin Bara

Hi! The Tegra20 requires an enabled VDE power domain during startup. As the VDE is currently not used, it is disabled during runtime. Since 8f0c714ad9be, there is a workaround for the "normal restart path" which enables the VDE before doing PMC's warm reboot. This workaround is not executed in the "emergency restart path", leading to a hang-up during start. This series implements and registers a new pmic-based restart handler for boards with tps6586x. This cold reboot ensures that the VDE power domain is enabled during startup on tegra20-based boards. Since bae1d3a05a8b, i2c transfers are non-atomic while preemption is disabled (which is e.g. done during panic()). This could lead to warnings ("Voluntary context switch within RCU") in i2c-based restart handlers during emergency restart. The state of preemption should be detected by i2c_in_atomic_xfer_mode() to use atomic i2c xfer when required. Beside the new system_state check, the check is the same as the one pre v5.2. --- v7: - 5/5: drop mode check (suggested by Dmitry) - Link to v6: https://lore.kernel.org/r/20230327-tegra-pmic-reboot-v6-0-af44a4cd82e9@skid… v6: - drop 4/6 to abort restart on unexpected failure (suggested by Dmitry) - 4,5: fix comments in handlers (suggested by Lee) - 4,5: same delay for both handlers (suggested by Lee) v5: - introduce new 3 & 4, therefore 3 -> 5, 4 -> 6 - 3: provide dev to sys_off handler, if it is known - 4: return NOTIFY_DONE from sys_off_notify, to avoid skipping - 5: drop Reviewed-by from Dmitry, add poweroff timeout - 5,6: return notifier value instead of direct errno from handler - 5,6: use new dev field instead of passing dev as cb_data - 5,6: increase timeout values based on error observations - 6: skip unsupported reboot modes in restart handler --- Benjamin Bara (5): kernel/reboot: emergency_restart: set correct system_state i2c: core: run atomic i2c xfer when !preemptible kernel/reboot: add device to sys_off_handler mfd: tps6586x: use devm-based power off handler mfd: tps6586x: register restart handler drivers/i2c/i2c-core.h | 2 +- drivers/mfd/tps6586x.c | 50 ++++++++++++++++++++++++++++++++++++++++++-------- include/linux/reboot.h | 3 +++ kernel/reboot.c | 4 ++++ 4 files changed, 50 insertions(+), 9 deletions(-) --- base-commit: 197b6b60ae7bc51dd0814953c562833143b292aa change-id: 20230327-tegra-pmic-reboot-4175ff814a4b Best regards, -- Benjamin Bara <benjamin.bara(a)skidata.com>

1 year, 11 months

6
19
0 0

[PATCH v7 5/7] serial: core, imx: do not set RS485 enabled if it is not supported

by Lino Sanfilippo

If the imx driver cannot support RS485 it nullifies the ports rs485_supported structure. But it still calls uart_get_rs485_mode() which may set the RS485_ENABLED flag nevertheless. This may lead to an attempt to configure RS485 even if it is not supported when the flag is evaluated in uart_configure_port() at port startup. Avoid this by bailing out of uart_get_rs485_mode() if the RS485_ENABLED flag is not supported by the caller. With this fix a check for RTS availability is now obsolete in the imx driver, since it can not evaluate to true any more. So remove this check. Furthermore the explicit nullifcation of rs485_supported is not needed, since the memory has already been set to zeros at allocation. So remove this, too. Fixes: 00d7a00e2a6f ("serial: imx: Fill in rs485_supported") Cc: Shawn Guo <shawnguo(a)kernel.org> Cc: Sascha Hauer <s.hauer(a)pengutronix.de> Cc: stable(a)vger.kernel.org Suggested-by: Uwe Kleine-König <u.kleine-koenig(a)pengutronix.de> Signed-off-by: Lino Sanfilippo <l.sanfilippo(a)kunbus.com> --- drivers/tty/serial/imx.c | 7 ------- drivers/tty/serial/serial_core.c | 3 +++ 2 files changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c index 9cffeb23112b..198ce7e7bc8b 100644 --- a/drivers/tty/serial/imx.c +++ b/drivers/tty/serial/imx.c @@ -2206,7 +2206,6 @@ static enum hrtimer_restart imx_trigger_stop_tx(struct hrtimer *t) return HRTIMER_NORESTART; } -static const struct serial_rs485 imx_no_rs485 = {}; /* No RS485 if no RTS */ static const struct serial_rs485 imx_rs485_supported = { .flags = SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND | SER_RS485_RTS_AFTER_SEND | SER_RS485_RX_DURING_TX, @@ -2290,8 +2289,6 @@ static int imx_uart_probe(struct platform_device *pdev) /* RTS is required to control the RS485 transmitter */ if (sport->have_rtscts || sport->have_rtsgpio) sport->port.rs485_supported = imx_rs485_supported; - else - sport->port.rs485_supported = imx_no_rs485; sport->port.flags = UPF_BOOT_AUTOCONF; timer_setup(&sport->timer, imx_uart_timeout, 0); @@ -2328,10 +2325,6 @@ static int imx_uart_probe(struct platform_device *pdev) return ret; } - if (sport->port.rs485.flags & SER_RS485_ENABLED && - (!sport->have_rtscts && !sport->have_rtsgpio)) - dev_err(&pdev->dev, "no RTS control, disabling rs485\n"); - /* * If using the i.MX UART RTS/CTS control then the RTS (CTS_B) * signal cannot be set low during transmission in case the diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c index 28bcbc686c67..93e4e1693601 100644 --- a/drivers/tty/serial/serial_core.c +++ b/drivers/tty/serial/serial_core.c @@ -3600,6 +3600,9 @@ int uart_get_rs485_mode(struct uart_port *port) u32 rs485_delay[2]; int ret; + if (!(port->rs485_supported.flags & SER_RS485_ENABLED)) + return 0; + ret = device_property_read_u32_array(dev, "rs485-rts-delay", rs485_delay, 2); if (!ret) { -- 2.43.0

1 year, 11 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2024