January 2024 - Linux-stable-mirror

[PATCH v5 1/5] lib/pci_iomap.c: fix cleanup bugs in pci_iounmap()

by Philipp Stanner

pci_iounmap() in lib/pci_iomap.c is supposed to check whether an address is within ioport-range IF the config specifies that ioports exist. If so, the port should be unmapped with ioport_unmap(). If not, it's a generic MMIO address that has to be passed to iounmap(). The bugs are: 1. ioport_unmap() is missing entirely, so this function will never actually unmap a port. 2. the #ifdef for the ioport-ranges accidentally also guards iounmap(), potentially compiling an empty function. This would cause the mapping to be leaked. Implement the missing call to ioport_unmap(). Move the guard so that iounmap() will always be part of the function. CC: <stable(a)vger.kernel.org> # v5.15+ Fixes: 316e8d79a095 ("pci_iounmap'2: Electric Boogaloo: try to make sense of it all") Reported-by: Danilo Krummrich <dakr(a)redhat.com> Suggested-by: Arnd Bergmann <arnd(a)kernel.org> Signed-off-by: Philipp Stanner <pstanner(a)redhat.com> Reviewed-by: Arnd Bergmann <arnd(a)arndb.de> --- lib/pci_iomap.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c index ce39ce9f3526..6e144b017c48 100644 --- a/lib/pci_iomap.c +++ b/lib/pci_iomap.c @@ -168,10 +168,12 @@ void pci_iounmap(struct pci_dev *dev, void __iomem *p) uintptr_t start = (uintptr_t) PCI_IOBASE; uintptr_t addr = (uintptr_t) p; - if (addr >= start && addr < start + IO_SPACE_LIMIT) + if (addr >= start && addr < start + IO_SPACE_LIMIT) { + ioport_unmap(p); return; - iounmap(p); + } #endif + iounmap(p); } EXPORT_SYMBOL(pci_iounmap); -- 2.43.0

1 year, 1 month

1
0
0 0

[PATCH v3] LoongArch: Fix and simplify fcsr initialization on execve

by Xi Ruoyao

There has been a lingering bug in LoongArch Linux systems causing some GCC tests to intermittently fail (see Closes link). I've made a minimal reproducer: zsh% cat measure.s .align 4 .globl _start _start: movfcsr2gr $a0, $fcsr0 bstrpick.w $a0, $a0, 16, 16 beqz $a0, .ok break 0 .ok: li.w $a7, 93 syscall 0 zsh% cc mesaure.s -o measure -nostdlib zsh% echo $((1.0/3)) 0.33333333333333331 zsh% while ./measure; do ; done This while loop should not stop as POSIX is clear that execve must set fenv to the default, where FCSR should be zero. But in fact it will just stop after running for a while (normally less than 30 seconds). Note that "$((1.0/3))" is needed to reproduce the issue because it raises FE_INVALID and makes fcsr0 non-zero. The problem is we are relying on SET_PERSONALITY2 to reset current->thread.fpu.fcsr. But SET_PERSONALITY2 is executed before start_thread which calls lose_fpu(0). We can see if kernel preempt is enabled, we may switch to another thread after SET_PERSONALITY2 but before lose_fpu(0). Then bad thing happens: during the thread switch the value of the fcsr0 register is stored into current->thread.fpu.fcsr, making it dirty again. The issue can be fixed by setting current->thread.fpu.fcsr after lose_fpu(0) because lose_fpu clears TIF_USEDFPU, then the thread switch won't touch current->thread.fpu.fcsr. The only other architecture setting FCSR in SET_PERSONALITY2 is MIPS. I've ran a similar test on MIPS with mainline kernel and it turns out MIPS is buggy too. Anyway MIPS do this for supporting different FP flavors (NaN encodings etc.) which do not exist on LoongArch. So for LoongArch, we can simply remove the current->thread.fpu.fcsr setting from SET_PERSONALITY2 and do it in start_thread, after lose_fpu(0). I'll leave the job to fix MIPS for MIPS maintainers. The while loop failing with the mainline kernel has survived one hour after this change on LoongArch. Closes: https://github.com/loongson-community/discussions/issues/7 Fixes: 803b0fc5c3f2 ("LoongArch: Add process management") Link: https://lore.kernel.org/linux-mips/7a6aa1bbdbbe2e63ae96ff163fab0349f58f1b9e… Cc: stable(a)vger.kernel.org Cc: linux-mips(a)vger.kernel.org Signed-off-by: Xi Ruoyao <xry111(a)xry111.site> --- v2 -> v3: - Update the commit message to mention MIPS is buggy too. - Replace tabs in the commit message with whitespaces. - No code change. v1 -> v2: - Still set current->thread.fpu.fcsr to boot_cpu_data.fpu_csr0 instead of constant 0. arch/loongarch/include/asm/elf.h | 5 ----- arch/loongarch/kernel/elf.c | 5 ----- arch/loongarch/kernel/process.c | 1 + 3 files changed, 1 insertion(+), 10 deletions(-) diff --git a/arch/loongarch/include/asm/elf.h b/arch/loongarch/include/asm/elf.h index 9b16a3b8e706..f16bd42456e4 100644 --- a/arch/loongarch/include/asm/elf.h +++ b/arch/loongarch/include/asm/elf.h @@ -241,8 +241,6 @@ void loongarch_dump_regs64(u64 *uregs, const struct pt_regs *regs); do { \ current->thread.vdso = &vdso_info; \ \ - loongarch_set_personality_fcsr(state); \ - \ if (personality(current->personality) != PER_LINUX) \ set_personality(PER_LINUX); \ } while (0) @@ -259,7 +257,6 @@ do { \ clear_thread_flag(TIF_32BIT_ADDR); \ \ current->thread.vdso = &vdso_info; \ - loongarch_set_personality_fcsr(state); \ \ p = personality(current->personality); \ if (p != PER_LINUX32 && p != PER_LINUX) \ @@ -340,6 +337,4 @@ extern int arch_elf_pt_proc(void *ehdr, void *phdr, struct file *elf, extern int arch_check_elf(void *ehdr, bool has_interpreter, void *interp_ehdr, struct arch_elf_state *state); -extern void loongarch_set_personality_fcsr(struct arch_elf_state *state); - #endif /* _ASM_ELF_H */ diff --git a/arch/loongarch/kernel/elf.c b/arch/loongarch/kernel/elf.c index 183e94fc9c69..0fa81ced28dc 100644 --- a/arch/loongarch/kernel/elf.c +++ b/arch/loongarch/kernel/elf.c @@ -23,8 +23,3 @@ int arch_check_elf(void *_ehdr, bool has_interpreter, void *_interp_ehdr, { return 0; } - -void loongarch_set_personality_fcsr(struct arch_elf_state *state) -{ - current->thread.fpu.fcsr = boot_cpu_data.fpu_csr0; -} diff --git a/arch/loongarch/kernel/process.c b/arch/loongarch/kernel/process.c index 767d94cce0de..3f9cae615f52 100644 --- a/arch/loongarch/kernel/process.c +++ b/arch/loongarch/kernel/process.c @@ -92,6 +92,7 @@ void start_thread(struct pt_regs *regs, unsigned long pc, unsigned long sp) clear_used_math(); regs->csr_era = pc; regs->regs[3] = sp; + current->thread.fpu.fcsr = boot_cpu_data.fpu_csr0; } void flush_thread(void) -- 2.43.0

1 year, 1 month

2
1
0 0

Re: [PATCH] arm64: dts: qcom: sc7280: Add additional MSI interrupts

by Krishna Chaitanya Chundru

Hi All, Can you please review this. Thanks & Regards, Krishna Chaitanya. On 12/18/2023 12:01 PM, Krishna chaitanya chundru wrote: > Current MSI's mapping was incorrect. This platform supports > 8 vectors each vector supports 32 MSI's, so total MSI's > supported is 256. > > Add all the MSI groups supported for this PCIe instance in this platform. > > Fixes: 92e0ee9f83b3 ("arm64: dts: qcom: sc7280: Add PCIe and PHY related nodes") > cc: stable(a)vger.kernel.org > Signed-off-by: Krishna chaitanya chundru <quic_krichai(a)quicinc.com> > --- > arch/arm64/boot/dts/qcom/sc7280.dtsi | 12 ++++++++++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi b/arch/arm64/boot/dts/qcom/sc7280.dtsi > index 66f1eb83cca7..e1dc41705f61 100644 > --- a/arch/arm64/boot/dts/qcom/sc7280.dtsi > +++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi > @@ -2146,8 +2146,16 @@ pcie1: pci@1c08000 { > ranges = <0x01000000 0x0 0x00000000 0x0 0x40200000 0x0 0x100000>, > <0x02000000 0x0 0x40300000 0x0 0x40300000 0x0 0x1fd00000>; > > - interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>; > - interrupt-names = "msi"; > + interrupts = <GIC_SPI 307 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 308 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 309 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 312 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 313 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 314 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>, > + <GIC_SPI 375 IRQ_TYPE_LEVEL_HIGH>; > + interrupt-names = "msi0", "msi1", "msi2", "msi3", > + "msi4", "msi5", "msi6", "msi7"; > #interrupt-cells = <1>; > interrupt-map-mask = <0 0 0 0x7>; > interrupt-map = <0 0 0 1 &intc 0 0 0 434 IRQ_TYPE_LEVEL_HIGH>, > > --- > base-commit: 5bd7ef53ffe5ca580e93e74eb8c81ed191ddc4bd > change-id: 20231218-additional_msi-6062dc812c29 > > Best regards,

1 year, 1 month

2
1
0 0

Re: [PATCH v3] Bluetooth: Fix Bluetooth for BCM4377 on T2 Intel MacBooks

by Sven Peter

Sending this again because Apple mail decided to default to HTML mails since the last update apparently *sigh* Hi, > On Dec 27, 2023, at 11:30, Johan Hovold <johan(a)kernel.org> wrote: > > On Mon, Dec 25, 2023 at 09:26:05PM +0100, Paul Menzel wrote: > >> Thank you very much for the patch. I am adding Johan to Cc field. > > Thanks for the report. Guess I could use a break from the proverbial > eggnog. > >> Am 25.12.23 um 21:01 schrieb Felix Zhang: >>> Starting v6.5, Bluetooth does not work at all on my T2 MacBookAir9,1 >>> with the BCM4377 chip. When I boot up the computer, go into >> Somehow a blank line snug in above. >>> bluetoothctl, and then try to run commands like scan on, show, list, >>> it returns "No default controller available." I have tried reloading >>> the >> It’d be great if you reflowed for 75 characters per line (also below). >>> kernel module, in which the log outputs "{Added,Removed} hci0 >>> (unconfigured)." With this patch, I am able to use Bluetooth as >>> normal >>> without any errors regarding hci0 being unconfigured. However, an >>> issue is still present where sometimes hci_bcm4377 will have to be >>> reloaded in order to get bluetooth to work. I believe this was still >>> present before the previously mentioned commit. >>> Due to the bit HCI_QUIRK_USE_BDADDR_PROPERTY being always set in >>> drivers/bluetooth/hci_bcm4377.c (line 2371), the chip would be left >>> unconfigured on kernels compiled after commit 6945795bc81a >>> ("Bluetooth: >>> fix use-bdaddr-property quirk") due to a change in its logic. On the >>> M1 Macs, the device would be configured in the devicetree. However, >>> that is not the case on T2 Macs. Because the bluetooth adapter is >>> left >>> unconfigured, it is not usable in the operating system. In order to >>> circumvent this issue, a flag is added to prevent the bit from being >>> set on the BCM4377, while setting it on the other devices. > > The commit you tracked this down to restored the original semantics for > HCI_QUIRK_USE_BDADDR_PROPERTY, which means that it should only be set > for devices with an invalid address. > > The Broadcom BCM4377 driver has so far been setting this flag > unconditionally which now potentially results in also valid addresses > being marked as invalid. > > I've just sent a patch that makes sure to only mark invalid addresses as > invalid: > > https://lore.kernel.org/lkml/20231227101003.10534-1-johan+linaro@kernel.org/ > > Note however that the flag still needs to be set in case your device > lacks storage for a unique device address so you cannot simply drop it > for some device classes as you do below (unless you are certain that > these devices will always have a valid address). We do know that though. BCM4377 is present on Apple’s x86 Macs and always has internal storage for the address. If the board comes up without an address there’s nothing much we can do because the address isn’t provided by ACPI or anything else and setting the invalid address quirk for that situation seems appropriate. BCM4378/4387 is present on Apple’s ARM Macs and never has internal storage. The address is always provided by our bootloader in the device tree. These should always unconditionally set HCI_QUIRK_USE_BDADDR_PROPERTY just like this patch does. Best, Sven

1 year, 1 month

3
5
0 0

[PATCH net v2 1/1] net: stmmac: Prevent DSA tags from breaking COE on stmmac

by Romain Gantois

Some DSA tagging protocols change the EtherType field in the MAC header e.g. DSA_TAG_PROTO_(DSA/EDSA/BRCM/MTK/RTL4C_A/SJA1105). On TX these tagged frames are ignored by the checksum offload engine and IP header checker of some stmmac cores. On RX, the stmmac driver wrongly assumes that checksums have been computed for these tagged packets, and sets CHECKSUM_UNNECESSARY. Add an additional check in the stmmac tx and rx hotpaths so that COE is deactivated for packets with ethertypes that will not trigger the COE and ip header checks. Fixes: 6b2c6e4a938f ("net: stmmac: propagate feature flags to vlan") Cc: stable(a)vger.kernel.org Reported-by: Richard Tresidder <rtresidd(a)electromag.com.au> Closes: https://lore.kernel.org/netdev/e5c6c75f-2dfa-4e50-a1fb-6bf4cdb617c2@electro… Reported-by: Romain Gantois <romain.gantois(a)bootlin.com> Closes: https://lore.kernel.org/netdev/c57283ed-6b9b-b0e6-ee12-5655c1c54495@bootlin… Signed-off-by: Romain Gantois <romain.gantois(a)bootlin.com> --- .../net/ethernet/stmicro/stmmac/stmmac_main.c | 21 ++++++++++++++++--- 1 file changed, 18 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c index 37e64283f910..bb2ae6b32b2f 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -4371,6 +4371,17 @@ static netdev_tx_t stmmac_tso_xmit(struct sk_buff *skb, struct net_device *dev) return NETDEV_TX_OK; } +/* Check if ethertype will trigger IP + * header checks/COE in hardware + */ +static inline bool stmmac_has_ip_ethertype(struct sk_buff *skb) +{ + __be16 proto = eth_header_parse_protocol(skb); + + return (proto == htons(ETH_P_IP)) || (proto == htons(ETH_P_IPV6)) || + (proto == htons(ETH_P_8021Q)); +} + /** * stmmac_xmit - Tx entry point of the driver * @skb : the socket buffer @@ -4435,9 +4446,13 @@ static netdev_tx_t stmmac_xmit(struct sk_buff *skb, struct net_device *dev) /* DWMAC IPs can be synthesized to support tx coe only for a few tx * queues. In that case, checksum offloading for those queues that don't * support tx coe needs to fallback to software checksum calculation. + * + * Packets that won't trigger the COE e.g. most DSA-tagged packets will + * also have to be checksummed in software. */ if (csum_insertion && - priv->plat->tx_queues_cfg[queue].coe_unsupported) { + (priv->plat->tx_queues_cfg[queue].coe_unsupported || + !stmmac_has_ip_ethertype(skb))) { if (unlikely(skb_checksum_help(skb))) goto dma_map_err; csum_insertion = !csum_insertion; @@ -4997,7 +5012,7 @@ static void stmmac_dispatch_skb_zc(struct stmmac_priv *priv, u32 queue, stmmac_rx_vlan(priv->dev, skb); skb->protocol = eth_type_trans(skb, priv->dev); - if (unlikely(!coe)) + if (unlikely(!coe) || !stmmac_has_ip_ethertype(skb)) skb_checksum_none_assert(skb); else skb->ip_summed = CHECKSUM_UNNECESSARY; @@ -5513,7 +5528,7 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue) stmmac_rx_vlan(priv->dev, skb); skb->protocol = eth_type_trans(skb, priv->dev); - if (unlikely(!coe)) + if (unlikely(!coe) || !stmmac_has_ip_ethertype(skb)) skb_checksum_none_assert(skb); else skb->ip_summed = CHECKSUM_UNNECESSARY; -- 2.43.0

1 year, 1 month

4
7
0 0

[PATCH v2] usb: dwc3: gadget: Queue PM runtime idle on disconnect event

by Wesley Cheng

There is a scenario where DWC3 runtime suspend is blocked due to the dwc->connected flag still being true while PM usage_count is zero after DWC3 giveback is completed and the USB gadget session is being terminated. This leads to a case where nothing schedules a PM runtime idle for the device. The exact condition is seen with the following sequence: 1. USB bus reset is issued by the host 2. Shortly after, or concurrently, a USB PD DR SWAP request is received (sink->source) 3. USB bus reset event handler runs and issues dwc3_stop_active_transfers(), and pending transfer are stopped 4. DWC3 usage_count decremented to 0, and runtime idle occurs while dwc->connected == true, returns -EBUSY 5. DWC3 disconnect event seen, dwc->connected set to false due to DR swap handling 6. No runtime idle after this point Address this by issuing an asynchronous PM runtime idle call after the disconnect event is completed, as it modifies the dwc->connected flag, which is what blocks the initial runtime idle. Fixes: fc8bb91bc83e ("usb: dwc3: implement runtime PM") Cc: stable(a)vger.kernel.org Signed-off-by: Wesley Cheng <quic_wcheng(a)quicinc.com> --- changes from v1: - CC'ed stable drivers/usb/dwc3/gadget.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 858fe4c299b7..de6056277f94 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -3973,6 +3973,13 @@ static void dwc3_gadget_disconnect_interrupt(struct dwc3 *dwc) usb_gadget_set_state(dwc->gadget, USB_STATE_NOTATTACHED); dwc3_ep0_reset_state(dwc); + + /* + * Request PM idle to address condition where usage count is + * already decremented to zero, but waiting for the disconnect + * interrupt to set dwc->connected to FALSE. + */ + pm_request_idle(dwc->dev); } static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)

1 year, 1 month

1
0
0 0

[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, 1 month

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, 1 month

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, 1 month

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, 1 month

2
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2024