- Linux-stable-mirror - lists.linaro.org

[PATCH 1/6] Revert "PCI: dw-rockchip: Don't wait for link since we can detect Link Up"

by Niklas Cassel

This reverts commit ec9fd499b9c60a187ac8d6414c3c343c77d32e42. While this fake hotplugging was a nice idea, it has shown that this feature does not handle PCIe switches correctly: pci_bus 0004:43: busn_res: can not insert [bus 43-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:43: busn_res: [bus 43-41] end is updated to 43 pci_bus 0004:43: busn_res: can not insert [bus 43] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:00.0: devices behind bridge are unusable because [bus 43] cannot be assigned for them pci_bus 0004:44: busn_res: can not insert [bus 44-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:44: busn_res: [bus 44-41] end is updated to 44 pci_bus 0004:44: busn_res: can not insert [bus 44] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:02.0: devices behind bridge are unusable because [bus 44] cannot be assigned for them pci_bus 0004:45: busn_res: can not insert [bus 45-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:45: busn_res: [bus 45-41] end is updated to 45 pci_bus 0004:45: busn_res: can not insert [bus 45] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:06.0: devices behind bridge are unusable because [bus 45] cannot be assigned for them pci_bus 0004:46: busn_res: can not insert [bus 46-41] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci_bus 0004:46: busn_res: [bus 46-41] end is updated to 46 pci_bus 0004:46: busn_res: can not insert [bus 46] under [bus 42-41] (conflicts with (null) [bus 42-41]) pci 0004:42:0e.0: devices behind bridge are unusable because [bus 46] cannot be assigned for them pci_bus 0004:42: busn_res: [bus 42-41] end is updated to 46 pci_bus 0004:42: busn_res: can not insert [bus 42-46] under [bus 41] (conflicts with (null) [bus 41]) pci 0004:41:00.0: devices behind bridge are unusable because [bus 42-46] cannot be assigned for them pcieport 0004:40:00.0: bridge has subordinate 41 but max busn 46 During the initial scan, PCI core doesn't see the switch and since the Root Port is not hot plug capable, the secondary bus number gets assigned as the subordinate bus number. This means, the PCI core assumes that only one bus will appear behind the Root Port since the Root Port is not hot plug capable. This works perfectly fine for PCIe endpoints connected to the Root Port, since they don't extend the bus. However, if a PCIe switch is connected, then there is a problem when the downstream busses starts showing up and the PCI core doesn't extend the subordinate bus number after initial scan during boot. The long term plan is to migrate this driver to the pwrctrl framework, once it adds proper support for powering up and enumerating PCIe switches. Cc: stable(a)vger.kernel.org Suggested-by: Manivannan Sadhasivam <mani(a)kernel.org> Signed-off-by: Niklas Cassel <cassel(a)kernel.org> --- drivers/pci/controller/dwc/pcie-dw-rockchip.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/pci/controller/dwc/pcie-dw-rockchip.c b/drivers/pci/controller/dwc/pcie-dw-rockchip.c index 3e2752c7dd09..07378ececd88 100644 --- a/drivers/pci/controller/dwc/pcie-dw-rockchip.c +++ b/drivers/pci/controller/dwc/pcie-dw-rockchip.c @@ -541,7 +541,6 @@ static int rockchip_pcie_configure_rc(struct platform_device *pdev, pp = &rockchip->pci.pp; pp->ops = &rockchip_pcie_host_ops; - pp->use_linkup_irq = true; ret = dw_pcie_host_init(pp); if (ret) { -- 2.51.1

1 week

1
0
0 0

[PATCH net v5 2/3] net,mptcp: fix proto fallback detection with BPF

by Jiayuan Chen

The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() syn_recv_sock()/subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_syn_recv_sock() subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Then, this subflow can be normally used by sockmap, which replaces the native sk_prot with sockmap's custom sk_prot. The issue occurs when the user executes accept::mptcp_stream_accept::mptcp_fallback_tcp_ops(). Here, it uses sk->sk_prot to compare with the native sk_prot, but this is incorrect when sockmap is used, as we may incorrectly set sk->sk_socket->ops. This fix uses the more generic sk_family for the comparison instead. Additionally, this also prevents a WARNING from occurring: result from ./scripts/decode_stacktrace.sh: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 337 at net/mptcp/protocol.c:68 mptcp_stream_accept \ (net/mptcp/protocol.c:4005) Modules linked in: ... PKRU: 55555554 Call Trace: <TASK> do_accept (net/socket.c:1989) __sys_accept4 (net/socket.c:2028 net/socket.c:2057) __x64_sys_accept (net/socket.c:2067) x64_sys_call (arch/x86/entry/syscall_64.c:41) do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130) RIP: 0033:0x7f87ac92b83d ---[ end trace 0000000000000000 ]--- Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing connections") Cc: <stable(a)vger.kernel.org> Signed-off-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> Reviewed-by: Jakub Sitnicki <jakub(a)cloudflare.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- net/mptcp/protocol.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c index 2d6b8de35c44..90b4aeca2596 100644 --- a/net/mptcp/protocol.c +++ b/net/mptcp/protocol.c @@ -61,11 +61,13 @@ static u64 mptcp_wnd_end(const struct mptcp_sock *msk) static const struct proto_ops *mptcp_fallback_tcp_ops(const struct sock *sk) { + unsigned short family = READ_ONCE(sk->sk_family); + #if IS_ENABLED(CONFIG_MPTCP_IPV6) - if (sk->sk_prot == &tcpv6_prot) + if (family == AF_INET6) return &inet6_stream_ops; #endif - WARN_ON_ONCE(sk->sk_prot != &tcp_prot); + WARN_ON_ONCE(family != AF_INET); return &inet_stream_ops; } -- 2.43.0

1 week

2
1
0 0

[PATCH] ARM: dts: nxp: imx6ul: correct SAI3 interrupt line

by Maarten Zanders

The i.MX6UL reference manual lists two possible interrupt lines for SAI3 (56 and 57, offset +32). The current device tree entry uses the first one (24), which prevents IRQs from being handled properly. Use the second interrupt line (25), which does allow interrupts to work as expected. Fixes: 36e2edf6ac07 ("ARM: dts: imx6ul: add sai support") Signed-off-by: Maarten Zanders <maarten(a)zanders.be> Cc: stable(a)vger.kernel.org --- arch/arm/boot/dts/nxp/imx/imx6ul.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi b/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi index 6de224dd2bb9..6eb80f867f50 100644 --- a/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi +++ b/arch/arm/boot/dts/nxp/imx/imx6ul.dtsi @@ -339,7 +339,7 @@ sai3: sai@2030000 { #sound-dai-cells = <0>; compatible = "fsl,imx6ul-sai", "fsl,imx6sx-sai"; reg = <0x02030000 0x4000>; - interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>; + interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6UL_CLK_SAI3_IPG>, <&clks IMX6UL_CLK_SAI3>, <&clks IMX6UL_CLK_DUMMY>, <&clks IMX6UL_CLK_DUMMY>; -- 2.51.0

1 week

2
1
0 0

[PATCH v3] w1: therm: Fix off-by-one buffer overflow in alarms_store

by Thorsten Blum

The sysfs buffer passed to alarms_store() is allocated with 'size + 1' bytes and a NUL terminator is appended. However, the 'size' argument does not account for this extra byte. The original code then allocated 'size' bytes and used strcpy() to copy 'buf', which always writes one byte past the allocated buffer since strcpy() copies until the NUL terminator at index 'size'. Fix this by parsing the 'buf' parameter directly using simple_strtol() without allocating any intermediate memory or string copying. This removes the overflow while simplifying the code. Cc: stable(a)vger.kernel.org Fixes: e2c94d6f5720 ("w1_therm: adding alarm sysfs entry") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- Compile-tested only. Changes in v3: - Add integer range check for 'temp' to match kstrtoint() behavior - Explicitly cast 'temp' to int when calling int_to_short() - Link to v2: https://lore.kernel.org/lkml/20251029130045.70127-2-thorsten.blum@linux.dev/ Changes in v2: - Fix buffer overflow instead of truncating the copy using strscpy() - Parse buffer directly using simple_strtol() as suggested by David - Update patch subject and description - Link to v1: https://lore.kernel.org/lkml/20251017170047.114224-2-thorsten.blum@linux.de… --- drivers/w1/slaves/w1_therm.c | 102 ++++++++++++----------------------- 1 file changed, 35 insertions(+), 67 deletions(-) diff --git a/drivers/w1/slaves/w1_therm.c b/drivers/w1/slaves/w1_therm.c index 9ccedb3264fb..1dad9fa1ec4a 100644 --- a/drivers/w1/slaves/w1_therm.c +++ b/drivers/w1/slaves/w1_therm.c @@ -1836,59 +1836,32 @@ static ssize_t alarms_store(struct device *device, struct w1_slave *sl = dev_to_w1_slave(device); struct therm_info info; u8 new_config_register[3]; /* array of data to be written */ - int temp, ret; - char *token = NULL; + long temp; + int ret; s8 tl, th; /* 1 byte per value + temp ring order */ - char *p_args, *orig; + const char *p = buf; + char *endp; - p_args = orig = kmalloc(size, GFP_KERNEL); - /* Safe string copys as buf is const */ - if (!p_args) { - dev_warn(device, - "%s: error unable to allocate memory %d\n", - __func__, -ENOMEM); - return size; + temp = simple_strtol(p, &endp, 10); + if (temp < INT_MIN || temp > INT_MAX || p == endp || *endp != ' ') { + dev_info(device, "%s: error parsing args %d\n", + __func__, -EINVAL); + goto err; } - strcpy(p_args, buf); - - /* Split string using space char */ - token = strsep(&p_args, " "); + /* Cast to short to eliminate out of range values */ + tl = int_to_short((int)temp); - if (!token) { - dev_info(device, - "%s: error parsing args %d\n", __func__, -EINVAL); - goto free_m; - } - - /* Convert 1st entry to int */ - ret = kstrtoint (token, 10, &temp); - if (ret) { - dev_info(device, - "%s: error parsing args %d\n", __func__, ret); - goto free_m; - } - - tl = int_to_short(temp); - - /* Split string using space char */ - token = strsep(&p_args, " "); - if (!token) { - dev_info(device, - "%s: error parsing args %d\n", __func__, -EINVAL); - goto free_m; - } - /* Convert 2nd entry to int */ - ret = kstrtoint (token, 10, &temp); - if (ret) { - dev_info(device, - "%s: error parsing args %d\n", __func__, ret); - goto free_m; + p = endp + 1; + temp = simple_strtol(p, &endp, 10); + if (temp < INT_MIN || temp > INT_MAX || p == endp) { + dev_info(device, "%s: error parsing args %d\n", + __func__, -EINVAL); + goto err; } + /* Cast to short to eliminate out of range values */ + th = int_to_short((int)temp); - /* Prepare to cast to short by eliminating out of range values */ - th = int_to_short(temp); - - /* Reorder if required th and tl */ + /* Reorder if required */ if (tl > th) swap(tl, th); @@ -1897,35 +1870,30 @@ static ssize_t alarms_store(struct device *device, * (th : byte 2 - tl: byte 3) */ ret = read_scratchpad(sl, &info); - if (!ret) { - new_config_register[0] = th; /* Byte 2 */ - new_config_register[1] = tl; /* Byte 3 */ - new_config_register[2] = info.rom[4];/* Byte 4 */ - } else { - dev_info(device, - "%s: error reading from the slave device %d\n", - __func__, ret); - goto free_m; + if (ret) { + dev_info(device, "%s: error reading from the slave device %d\n", + __func__, ret); + goto err; } + new_config_register[0] = th; /* Byte 2 */ + new_config_register[1] = tl; /* Byte 3 */ + new_config_register[2] = info.rom[4]; /* Byte 4 */ /* Write data in the device RAM */ if (!SLAVE_SPECIFIC_FUNC(sl)) { - dev_info(device, - "%s: Device not supported by the driver %d\n", - __func__, -ENODEV); - goto free_m; + dev_info(device, "%s: Device not supported by the driver %d\n", + __func__, -ENODEV); + goto err; } ret = SLAVE_SPECIFIC_FUNC(sl)->write_data(sl, new_config_register); - if (ret) - dev_info(device, - "%s: error writing to the slave device %d\n", + if (ret) { + dev_info(device, "%s: error writing to the slave device %d\n", __func__, ret); + goto err; + } -free_m: - /* free allocated memory */ - kfree(orig); - +err: return size; } -- 2.51.0

1 week

3
4
0 0

[PATCH] drm/sched: Fix UB in spsc_queue

by Philipp Stanner

The spsc_queue is an unlocked, highly asynchronous piece of infrastructure. Its inline function spsc_queue_peek() obtains the head entry of the queue. This access is performed without READ_ONCE() and is, therefore, undefined behavior. In order to prevent the compiler from ever reordering that access, or even optimizing it away, a READ_ONCE() is strictly necessary. This is easily proven by the fact that spsc_queue_pop() uses this very pattern to access the head. Add READ_ONCE() to spsc_queue_peek(). Cc: stable(a)vger.kernel.org # v4.16+ Fixes: 27105db6c63a ("drm/amdgpu: Add SPSC queue to scheduler.") Signed-off-by: Philipp Stanner <phasta(a)kernel.org> --- I think this makes it less broken, but I'm not even sure if it's enough or more memory barriers or an rcu_dereference() would be correct. The spsc_queue is, of course, not documented and the existing barrier comments are either false or not telling. If someone has an idea, shoot us the info. Otherwise I think this is the right thing to do for now. P. --- include/drm/spsc_queue.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/spsc_queue.h b/include/drm/spsc_queue.h index ee9df8cc67b7..39bada748ffc 100644 --- a/include/drm/spsc_queue.h +++ b/include/drm/spsc_queue.h @@ -54,7 +54,7 @@ static inline void spsc_queue_init(struct spsc_queue *queue) static inline struct spsc_node *spsc_queue_peek(struct spsc_queue *queue) { - return queue->head; + return READ_ONCE(queue->head); } static inline int spsc_queue_count(struct spsc_queue *queue) -- 2.49.0

1 week, 1 day

3
8
0 0

[PATCH] Revert "mm, swap: avoid redundant swap device pinning"

by Kairui Song via B4 Relay

From: Kairui Song <kasong(a)tencent.com> This reverts commit 78524b05f1a3e16a5d00cc9c6259c41a9d6003ce. While reviewing recent leaf entry changes, I noticed that commit 78524b05f1a3 ("mm, swap: avoid redundant swap device pinning") isn't correct. It's true that most all callers of __read_swap_cache_async are already holding a swap entry reference, so the repeated swap device pinning isn't needed on the same swap device, but it is possible that VMA readahead (swap_vma_readahead()) may encounter swap entries from a different swap device when there are multiple swap devices, and call __read_swap_cache_async without holding a reference to that swap device. So it is possible to cause a UAF if swapoff of device A raced with swapin on device B, and VMA readahead tries to read swap entries from device A. It's not easy to trigger but in theory possible to cause real issues. And besides, that commit made swap more vulnerable to issues like corrupted page tables. Just revert it. __read_swap_cache_async isn't that sensitive to performance after all, as it's mostly used for SSD/HDD swap devices with readahead. SYNCHRONOUS_IO devices may fallback onto it for swap count > 1 entries, but very soon we will have a new helper and routine for such devices, so they will never touch this helper or have redundant swap device reference overhead. Fixes: 78524b05f1a3 ("mm, swap: avoid redundant swap device pinning") Signed-off-by: Kairui Song <kasong(a)tencent.com> --- mm/swap_state.c | 14 ++++++-------- mm/zswap.c | 8 +------- 2 files changed, 7 insertions(+), 15 deletions(-) diff --git a/mm/swap_state.c b/mm/swap_state.c index 3f85a1c4cfd9..0c25675de977 100644 --- a/mm/swap_state.c +++ b/mm/swap_state.c @@ -406,13 +406,17 @@ struct folio *__read_swap_cache_async(swp_entry_t entry, gfp_t gfp_mask, struct mempolicy *mpol, pgoff_t ilx, bool *new_page_allocated, bool skip_if_exists) { - struct swap_info_struct *si = __swap_entry_to_info(entry); + struct swap_info_struct *si; struct folio *folio; struct folio *new_folio = NULL; struct folio *result = NULL; void *shadow = NULL; *new_page_allocated = false; + si = get_swap_device(entry); + if (!si) + return NULL; + for (;;) { int err; @@ -499,6 +503,7 @@ struct folio *__read_swap_cache_async(swp_entry_t entry, gfp_t gfp_mask, put_swap_folio(new_folio, entry); folio_unlock(new_folio); put_and_return: + put_swap_device(si); if (!(*new_page_allocated) && new_folio) folio_put(new_folio); return result; @@ -518,16 +523,11 @@ struct folio *read_swap_cache_async(swp_entry_t entry, gfp_t gfp_mask, struct vm_area_struct *vma, unsigned long addr, struct swap_iocb **plug) { - struct swap_info_struct *si; bool page_allocated; struct mempolicy *mpol; pgoff_t ilx; struct folio *folio; - si = get_swap_device(entry); - if (!si) - return NULL; - mpol = get_vma_policy(vma, addr, 0, &ilx); folio = __read_swap_cache_async(entry, gfp_mask, mpol, ilx, &page_allocated, false); @@ -535,8 +535,6 @@ struct folio *read_swap_cache_async(swp_entry_t entry, gfp_t gfp_mask, if (page_allocated) swap_read_folio(folio, plug); - - put_swap_device(si); return folio; } diff --git a/mm/zswap.c b/mm/zswap.c index 5d0f8b13a958..aefe71fd160c 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1005,18 +1005,12 @@ static int zswap_writeback_entry(struct zswap_entry *entry, struct folio *folio; struct mempolicy *mpol; bool folio_was_allocated; - struct swap_info_struct *si; int ret = 0; /* try to allocate swap cache folio */ - si = get_swap_device(swpentry); - if (!si) - return -EEXIST; - mpol = get_task_policy(current); folio = __read_swap_cache_async(swpentry, GFP_KERNEL, mpol, - NO_INTERLEAVE_INDEX, &folio_was_allocated, true); - put_swap_device(si); + NO_INTERLEAVE_INDEX, &folio_was_allocated, true); if (!folio) return -ENOMEM; --- base-commit: 02dafa01ec9a00c3758c1c6478d82fe601f5f1ba change-id: 20251109-revert-78524b05f1a3-04a1295bef8a Best regards, -- Kairui Song <kasong(a)tencent.com>

1 week, 1 day

4
8
0 0

Re: [PATCH 6.12 000/565] 6.12.58-rc1 review

by Jari Ruusu

Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> wrote: > This is the start of the stable review cycle for the 6.12.58 release. > There are 565 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. [SNIP] > Zizhi Wo <wozizhi(a)huaweicloud.com> > tty/vt: Add missing return value for VT_RESIZE in vt_ioctl() Locking seems to be messed up in backport of above mentioned patch. That patch is viewable here: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/… Upstream uses guard() locking: | case VT_RESIZE: | { | .... | guard(console_lock)(); | ^^^^^^^^^^^^^^^^^^^^^-------this generates auto-unlock code | .... | ret = __vc_resize(vc_cons[i].d, cc, ll, true); | if (ret) | return ret; | ^^^^^^^^^^----------this releases console lock | .... | break; | } Older stable branches use old-school locking: | case VT_RESIZE: | { | .... | console_lock(); | .... | ret = __vc_resize(vc_cons[i].d, cc, ll, true); | if (ret) | return ret; | ^^^^^^^^^^----------this does not release console lock | .... | console_unlock(); | break; | } Backporting upstream fixes that use guard() locking to older stable branches that use old-school locking need "extra sports". Please consider dropping or fixing above mentioned patch. -- Jari Ruusu 4096R/8132F189 12D6 4C3A DCDA 0AA4 27BD ACDF F073 3C80 8132 F189

1 week, 1 day

1
0
0 0

[PATCH net v5 1/3] mptcp: disallow MPTCP subflows from sockmap

by Jiayuan Chen

The sockmap feature allows bpf syscall from userspace, or based on bpf sockops, replacing the sk_prot of sockets during protocol stack processing with sockmap's custom read/write interfaces. ''' tcp_rcv_state_process() subflow_syn_recv_sock() tcp_init_transfer(BPF_SOCK_OPS_PASSIVE_ESTABLISHED_CB) bpf_skops_established <== sockops bpf_sock_map_update(sk) <== call bpf helper tcp_bpf_update_proto() <== update sk_prot ''' Consider two scenarios: 1. When the server has MPTCP enabled and the client also requests MPTCP, the sk passed to the BPF program is a subflow sk. Since subflows only handle partial data, replacing their sk_prot is meaningless and will cause traffic disruption. 2. When the server has MPTCP enabled but the client sends a TCP SYN without MPTCP, subflow_syn_recv_sock() performs a fallback on the subflow, replacing the subflow sk's sk_prot with the native sk_prot. ''' subflow_ulp_fallback() subflow_drop_ctx() mptcp_subflow_ops_undo_override() ''' Subsequently, accept::mptcp_stream_accept::mptcp_fallback_tcp_ops() converts the subflow to plain TCP. For the first case, we should prevent it from being combined with sockmap by setting sk_prot->psock_update_sk_prot to NULL, which will be blocked by sockmap's own flow. For the second case, since subflow_syn_recv_sock() has already restored sk_prot to native tcp_prot/tcpv6_prot, no further action is needed. Fixes: cec37a6e41aa ("mptcp: Handle MP_CAPABLE options for outgoing connections") Cc: <stable(a)vger.kernel.org> Signed-off-by: Jiayuan Chen <jiayuan.chen(a)linux.dev> Reviewed-by: Matthieu Baerts (NGI0) <matttbe(a)kernel.org> --- net/mptcp/subflow.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c index e8325890a322..af707ce0f624 100644 --- a/net/mptcp/subflow.c +++ b/net/mptcp/subflow.c @@ -2144,6 +2144,10 @@ void __init mptcp_subflow_init(void) tcp_prot_override = tcp_prot; tcp_prot_override.release_cb = tcp_release_cb_override; tcp_prot_override.diag_destroy = tcp_abort_override; +#ifdef CONFIG_BPF_SYSCALL + /* Disable sockmap processing for subflows */ + tcp_prot_override.psock_update_sk_prot = NULL; +#endif #if IS_ENABLED(CONFIG_MPTCP_IPV6) /* In struct mptcp_subflow_request_sock, we assume the TCP request sock @@ -2180,6 +2184,10 @@ void __init mptcp_subflow_init(void) tcpv6_prot_override = tcpv6_prot; tcpv6_prot_override.release_cb = tcp_release_cb_override; tcpv6_prot_override.diag_destroy = tcp_abort_override; +#ifdef CONFIG_BPF_SYSCALL + /* Disable sockmap processing for subflows */ + tcpv6_prot_override.psock_update_sk_prot = NULL; +#endif #endif mptcp_diag_subflow_init(&subflow_ulp_ops); -- 2.43.0

1 week, 1 day

1
0
0 0

[REGRESSION] stable-rc/linux-6.12.y: (build) passing argument 1 of ‘linkmode_fill’ makes pointer from integer w...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.12.y: --- passing argument 1 of ‘linkmode_fill’ makes pointer from integer without a cast [-Werror=int-conversion] in drivers/net/phy/phy_device.o (drivers/net/phy/phy_device.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:5904322dbb62197106ccc331a9b38bcced1cdf30 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 44c21f603a9a2b315280fc66ec569fb726e51fac Log excerpt: ===================================================== drivers/net/phy/phy_device.c:3061:29: error: passing argument 1 of ‘linkmode_fill’ makes pointer from integer without a cast [-Werror=int-conversion] 3061 | linkmode_fill(phydev->eee_broken_modes); | ~~~~~~^~~~~~~~~~~~~~~~~~ | | | u32 {aka unsigned int} In file included from ./include/linux/mii.h:13, from ./include/uapi/linux/mdio.h:15, from ./include/linux/mdio.h:9, from drivers/net/phy/phy_device.c:23: ./include/linux/linkmode.h:13:49: note: expected ‘long unsigned int *’ but argument is of type ‘u32’ {aka ‘unsigned int’} 13 | static inline void linkmode_fill(unsigned long *dst) | ~~~~~~~~~~~~~~~^~~ CC drivers/input/ff-core.o CC drivers/net/phy/linkmode.o AR drivers/input/touchscreen/built-in.a CC drivers/input/touchscreen.o CC drivers/input/ff-memless.o CC drivers/rtc/nvmem.o CC drivers/input/matrix-keymap.o CC drivers/mtd/mtdchar.o CC drivers/net/phy/phy_link_topology.o CC drivers/input/vivaldi-fmap.o cc1: all warnings being treated as errors ===================================================== # Builds where the incident occurred: ## cros://chromeos-6.12/arm64/chromiumos-mediatek.flavour.config+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y on (arm64): - compiler: gcc-12 - config: https://files.kernelci.org/kbuild-gcc-12-arm64-chromeos-mediatek-691292a32f… - dashboard: https://d.kernelci.org/build/maestro:691292a32fd2377ea9956eb0 ## cros://chromeos-6.12/arm64/chromiumos-qualcomm.flavour.config+lab-setup+arm64-chromebook+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y on (arm64): - compiler: gcc-12 - config: https://files.kernelci.org/kbuild-gcc-12-arm64-chromeos-qualcomm-691292a82f… - dashboard: https://d.kernelci.org/build/maestro:691292a82fd2377ea9956ed3 ## cros://chromeos-6.12/x86_64/chromeos-amd-stoneyridge.flavour.config+lab-setup+x86-board+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y on (x86_64): - compiler: gcc-12 - config: https://files.kernelci.org/kbuild-gcc-12-x86-chromeos-amd-691292ad2fd2377ea… - dashboard: https://d.kernelci.org/build/maestro:691292ad2fd2377ea9956ed6 ## cros://chromeos-6.12/x86_64/chromeos-intel-pineview.flavour.config+lab-setup+x86-board+CONFIG_MODULE_COMPRESS=n+CONFIG_MODULE_COMPRESS_NONE=y on (x86_64): - compiler: gcc-12 - config: https://files.kernelci.org/kbuild-gcc-12-x86-chromeos-intel-691292b32fd2377… - dashboard: https://d.kernelci.org/build/maestro:691292b32fd2377ea9956ee6 ## defconfig+kcidebug+x86-board on (i386): - compiler: gcc-12 - config: https://files.kernelci.org/kbuild-gcc-12-x86-kcidebug-691292932fd2377ea9956… - dashboard: https://d.kernelci.org/build/maestro:691292932fd2377ea9956e4c ## x86_64_defconfig+lab-setup+x86-board+kselftest on (x86_64): - compiler: gcc-12 - config: https://files.kernelci.org/kbuild-gcc-12-x86-691292892fd2377ea9956e40/.conf… - dashboard: https://d.kernelci.org/build/maestro:691292892fd2377ea9956e40 #kernelci issue maestro:5904322dbb62197106ccc331a9b38bcced1cdf30 Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

1 week, 1 day

1
0
0 0

[REGRESSION] stable-rc/linux-6.12.y: (build) incompatible integer to pointer conversion passing 'u32' (aka 'uns...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.12.y: --- incompatible integer to pointer conversion passing 'u32' (aka 'unsigned int') to parameter of type 'unsigned long *' [-Wint-conversion] in drivers/net/phy/phy_device.o (drivers/net/phy/phy_device.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:ca6f6d9806fc2b70ae08b439179af266398dd55e - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 44c21f603a9a2b315280fc66ec569fb726e51fac Log excerpt: ===================================================== drivers/net/phy/phy_device.c:3061:16: error: incompatible integer to pointer conversion passing 'u32' (aka 'unsigned int') to parameter of type 'unsigned long *' [-Wint-conversion] 3061 | linkmode_fill(phydev->eee_broken_modes); | ^~~~~~~~~~~~~~~~~~~~~~~~ ./include/linux/linkmode.h:13:49: note: passing argument to parameter 'dst' here 13 | static inline void linkmode_fill(unsigned long *dst) | ^ CC drivers/gpu/drm/i915/gt/intel_gtt.o 1 error generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-17 - config: https://files.kernelci.org/kbuild-clang-17-arm-allmodconfig-6912921d2fd2377… - dashboard: https://d.kernelci.org/build/maestro:6912921d2fd2377ea9956acc ## i386_defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (i386): - compiler: clang-17 - config: https://files.kernelci.org/kbuild-clang-17-i386-allmodconfig-6912926a2fd237… - dashboard: https://d.kernelci.org/build/maestro:6912926a2fd2377ea9956bce ## multi_v7_defconfig on (arm): - compiler: clang-17 - config: https://files.kernelci.org/kbuild-clang-17-arm-691292192fd2377ea9956ac9/.co… - dashboard: https://d.kernelci.org/build/maestro:691292192fd2377ea9956ac9 ## x86_64_defconfig on (x86_64): - compiler: clang-17 - config: https://files.kernelci.org/kbuild-clang-17-x86-691292272fd2377ea9956ad4/.co… - dashboard: https://d.kernelci.org/build/maestro:691292272fd2377ea9956ad4 #kernelci issue maestro:ca6f6d9806fc2b70ae08b439179af266398dd55e Reported-by: kernelci.org bot <bot(a)kernelci.org> -- This is an experimental report format. Please send feedback in! Talk to us at kernelci(a)lists.linux.dev Made with love by the KernelCI team - https://kernelci.org

1 week, 1 day

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror