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

[REGRESSION] stable-rc/linux-6.1.y: (build) stack frame size (2488) exceeds limit (2048) in 'dml31_ModeSupport...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-6.1.y: --- stack frame size (2488) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] in drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.o (drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:69fb66ef80a96ff4750a9dacf73be24a7cbe888e - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: 2c86adab41e98d103953bf8c447202c9147150ab Log excerpt: ===================================================== drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_mode_vba_31.c:3795:6: error: stack frame size (2488) exceeds limit (2048) in 'dml31_ModeSupportAndSystemConfigurationFull' [-Werror,-Wframe-larger-than] 3795 | void dml31_ModeSupportAndSystemConfigurationFull(struct display_mode_lib *mode_lib) | ^ CC drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn303/dcn303_fpu.o 1 error generated. CC drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn314/dcn314_fpu.o ===================================================== # Builds where the incident occurred: ## x86_64_defconfig+kselftest+x86-board on (x86_64): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:685193725c2cf25042b9bcc9 #kernelci issue maestro:69fb66ef80a96ff4750a9dacf73be24a7cbe888e 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

2 weeks, 6 days

1
0
0 0

[REGRESSION] stable-rc/linux-5.4.y: (build) in drivers/firmware/qcom_scm-32.o (scripts/Makefile.build:262) [lo...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.4.y: --- in drivers/firmware/qcom_scm-32.o (scripts/Makefile.build:262) [logspec:kbuild,kbuild.compiler] --- - dashboard: https://d.kernelci.org/i/maestro:04c1ce2921a16b59c7329a6026c59ea7942ef691 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: e2f5a2e75b315706dd2d1d50a4313e5785eb189d Log excerpt: ===================================================== CC drivers/firmware/qcom_scm-32.o CC drivers/firmware/trusted_foundations.o CC drivers/clk/qcom/clk-regmap.o CC drivers/gpio/gpio-pl061.o CC kernel/resource.o CC kernel/sysctl.o /tmp/ccsKkK07.s: Assembler messages: /tmp/ccsKkK07.s:45: Error: selected processor does not support `smc #0' in ARM mode /tmp/ccsKkK07.s:94: Error: selected processor does not support `smc #0' in ARM mode /tmp/ccsKkK07.s:160: Error: selected processor does not support `smc #0' in ARM mode /tmp/ccsKkK07.s:296: Error: selected processor does not support `smc #0' in ARM mode ===================================================== # Builds where the incident occurred: ## multi_v7_defconfig on (arm): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:685191a35c2cf25042b9bb4f ## multi_v7_defconfig+kselftest on (arm): - compiler: gcc-12 - dashboard: https://d.kernelci.org/build/maestro:685191ab5c2cf25042b9bb56 #kernelci issue maestro:04c1ce2921a16b59c7329a6026c59ea7942ef691 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

2 weeks, 6 days

1
0
0 0

[REGRESSION] stable-rc/linux-5.15.y: (build) integer literal is too large to be represented in type 'long', int...

by KernelCI bot

Hello, New build issue found on stable-rc/linux-5.15.y: --- integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] in drivers/gpu/drm/meson/meson_vclk.o (drivers/gpu/drm/meson/meson_vclk.c) [logspec:kbuild,kbuild.compiler.error] --- - dashboard: https://d.kernelci.org/i/maestro:ae3b0334acd91200d6ced325a381bafac2d46493 - giturl: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git - commit HEAD: d99cd6f3a570e2f93e8f966b8ca772ef3da54fe2 Log excerpt: ===================================================== drivers/gpu/drm/meson/meson_vclk.c:399:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 399 | .pll_freq = 2970000000, | ^ drivers/gpu/drm/meson/meson_vclk.c:411:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 411 | .pll_freq = 2970000000, | ^ drivers/gpu/drm/meson/meson_vclk.c:423:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 423 | .pll_freq = 2970000000, | ^ drivers/gpu/drm/meson/meson_vclk.c:436:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 436 | .phy_freq = 2970000000, | ^ drivers/gpu/drm/meson/meson_vclk.c:460:15: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 460 | .phy_freq = 2970000000, | ^ CC [M] net/dccp/feat.o drivers/gpu/drm/meson/meson_vclk.c:850:8: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 850 | case 2970000000: | ^ drivers/gpu/drm/meson/meson_vclk.c:868:8: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 868 | case 2970000000: | ^ drivers/gpu/drm/meson/meson_vclk.c:885:8: error: integer literal is too large to be represented in type 'long', interpreting as 'unsigned long' per C89; this literal will have type 'long long' in C99 onwards [-Werror,-Wc99-compat] 885 | case 2970000000: | ^ 8 errors generated. ===================================================== # Builds where the incident occurred: ## defconfig+allmodconfig+CONFIG_FRAME_WARN=2048 on (arm): - compiler: clang-17 - dashboard: https://d.kernelci.org/build/maestro:685192b15c2cf25042b9bc2e #kernelci issue maestro:ae3b0334acd91200d6ced325a381bafac2d46493 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

2 weeks, 6 days

1
0
0 0

[PATCH v2] serial: core: restore of_node information in sysfs

by Aidan Stewart

Since in v6.8-rc1, the of_node symlink under tty devices is missing. This breaks any udev rules relying on this information. Link the of_node information in the serial controller device with the parent defined in the device tree. This will also apply to the serial device which takes the serial controller as a parent device. Fixes: b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device") Cc: stable(a)vger.kernel.org Signed-off-by: Aidan Stewart <astewart(a)tektelic.com> --- v1 -> v2: - v1: https://lore.kernel.org/linux-serial/20250616162154.9057-1-astewart@tekteli… - Remove IS_ENABLED(CONFIG_OF) check. --- drivers/tty/serial/serial_base_bus.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c index 5d1677f1b651..cb3b127b06b6 100644 --- a/drivers/tty/serial/serial_base_bus.c +++ b/drivers/tty/serial/serial_base_bus.c @@ -72,6 +72,7 @@ static int serial_base_device_init(struct uart_port *port, dev->parent = parent_dev; dev->bus = &serial_base_bus_type; dev->release = release; + device_set_of_node_from_dev(dev, parent_dev); if (!serial_base_initialized) { dev_dbg(port->dev, "uart_add_one_port() called before arch_initcall()?\n"); -- 2.49.0

2 weeks, 6 days

1
0
0 0

[PATCH 6.12.y 0/2] Kunit to check the longest symbol length

by Sergio González Collado

The longest length of a symbol (KSYM_NAME_LEN) was increased to 512 in the reference [1]. Because in Rust symbols can become quite long due to namespacing introduced by modules, types, traits, generics, etc. This patch series presents two commits that implement a test to verify that a symbol with KSYM_NAME_LEN of 512 can be read. The first commit: To check that symbol length was valid, the commit implements a kunit test that verifies that a symbol of 512 length can be read. The second commit: There was a warning when building with clang because there was a definition of unlikely from compiler.h in tools/include/linux, which conflicted with the one in the instruction decoder selftest. [1] https://lore.kernel.org/lkml/20220802015052.10452-6-ojeda@kernel.org/ --- Nathan Chancellor (1): x86/tools: Drop duplicate unlikely() definition in insn_decoder_test.c Sergio González Collado (1): Kunit to check the longest symbol length arch/x86/tools/insn_decoder_test.c | 5 +- lib/Kconfig.debug | 9 ++++ lib/Makefile | 2 + lib/longest_symbol_kunit.c | 82 ++++++++++++++++++++++++++++++ 4 files changed, 95 insertions(+), 3 deletions(-) create mode 100644 lib/longest_symbol_kunit.c base-commit: ba9210b8c96355a16b78e1b890dce78f284d6f31 -- 2.39.2

2 weeks, 6 days

4
11
0 0

[PATCH] serial: core: restore of_node information in sysfs

by Aidan Stewart

Since in v6.8-rc1, the of_node symlink under tty devices is missing. This breaks any udev rules relying on this information. Link the of_node information in the serial controller device with the parent defined in the device tree. This will also apply to the serial device which takes the serial controller as a parent device. Fixes: b286f4e87e32 ("serial: core: Move tty and serdev to be children of serial core port device") Cc: stable(a)vger.kernel.org Signed-off-by: Aidan Stewart <astewart(a)tektelic.com> --- drivers/tty/serial/serial_base_bus.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c index 5d1677f1b651..0e4bf7a3e775 100644 --- a/drivers/tty/serial/serial_base_bus.c +++ b/drivers/tty/serial/serial_base_bus.c @@ -73,6 +73,10 @@ static int serial_base_device_init(struct uart_port *port, dev->bus = &serial_base_bus_type; dev->release = release; + if (IS_ENABLED(CONFIG_OF)) { + device_set_of_node_from_dev(dev, parent_dev); + } + if (!serial_base_initialized) { dev_dbg(port->dev, "uart_add_one_port() called before arch_initcall()?\n"); return -EPROBE_DEFER; -- 2.49.0

2 weeks, 6 days

2
3
0 0

FAILED: patch "[PATCH] usb: cdnsp: Fix issue with detecting command completion event" failed to apply to 5.4-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.4-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-5.4.y git checkout FETCH_HEAD git cherry-pick -x f4ecdc352646f7d23f348e5c544dbe3212c94fc8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025061708-cameo-caring-38a0@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^.. Possible dependencies: thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From f4ecdc352646f7d23f348e5c544dbe3212c94fc8 Mon Sep 17 00:00:00 2001 From: Pawel Laszczak <pawell(a)cadence.com> Date: Tue, 13 May 2025 05:30:09 +0000 Subject: [PATCH] usb: cdnsp: Fix issue with detecting command completion event In some cases, there is a small-time gap in which CMD_RING_BUSY can be cleared by controller but adding command completion event to event ring will be delayed. As the result driver will return error code. This behavior has been detected on usbtest driver (test 9) with configuration including ep1in/ep1out bulk and ep2in/ep2out isoc endpoint. Probably this gap occurred because controller was busy with adding some other events to event ring. The CMD_RING_BUSY is cleared to '0' when the Command Descriptor has been executed and not when command completion event has been added to event ring. To fix this issue for this test the small delay is sufficient less than 10us) but to make sure the problem doesn't happen again in the future the patch introduces 10 retries to check with delay about 20us before returning error code. Fixes: 3d82904559f4 ("usb: cdnsp: cdns3 Add main part of Cadence USBSSP DRD Driver") Cc: stable <stable(a)kernel.org> Signed-off-by: Pawel Laszczak <pawell(a)cadence.com> Acked-by: Peter Chen <peter.chen(a)kernel.org> Link: https://lore.kernel.org/r/PH7PR07MB9538AA45362ACCF1B94EE9B7DD96A@PH7PR07MB9… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> diff --git a/drivers/usb/cdns3/cdnsp-gadget.c b/drivers/usb/cdns3/cdnsp-gadget.c index cd1e00daf43f..55f95f41b3b4 100644 --- a/drivers/usb/cdns3/cdnsp-gadget.c +++ b/drivers/usb/cdns3/cdnsp-gadget.c @@ -548,6 +548,7 @@ int cdnsp_wait_for_cmd_compl(struct cdnsp_device *pdev) dma_addr_t cmd_deq_dma; union cdnsp_trb *event; u32 cycle_state; + u32 retry = 10; int ret, val; u64 cmd_dma; u32 flags; @@ -579,8 +580,23 @@ int cdnsp_wait_for_cmd_compl(struct cdnsp_device *pdev) flags = le32_to_cpu(event->event_cmd.flags); /* Check the owner of the TRB. */ - if ((flags & TRB_CYCLE) != cycle_state) + if ((flags & TRB_CYCLE) != cycle_state) { + /* + * Give some extra time to get chance controller + * to finish command before returning error code. + * Checking CMD_RING_BUSY is not sufficient because + * this bit is cleared to '0' when the Command + * Descriptor has been executed by controller + * and not when command completion event has + * be added to event ring. + */ + if (retry--) { + udelay(20); + continue; + } + return -EINVAL; + } cmd_dma = le64_to_cpu(event->event_cmd.cmd_trb);

2 weeks, 6 days

2
1
0 0

[PATCH v7 0/5] media: uvcvideo: Introduce V4L2_META_FMT_UVC_MSXU_1_5 + other meta fixes

by Ricardo Ribalda

This series introduces a new metadata format for UVC cameras and adds a couple of improvements to the UVC metadata handling. The new metadata format can be enabled in runtime with quirks. Signed-off-by: Ricardo Ribalda <ribalda(a)chromium.org> --- Changes in v7: - Add patch: Introduce dev->meta_formats - Link to v6: https://lore.kernel.org/r/20250604-uvc-meta-v6-0-7141d48c322c@chromium.org Changes in v6 (Thanks Laurent): - Fix typo in metafmt-uvc.rst - Improve metafmt-uvc-msxu-1-5.rst - uvc_meta_v4l2_try_format() block MSXU format unless the quirk is active - Refactor uvc_enable_msxu - Document uvc_meta_detect_msxu - Rebase series - Add R-b - Link to v5: https://lore.kernel.org/r/20250404-uvc-meta-v5-0-f79974fc2d20@chromium.org Changes in v5: - Fix codestyle and kerneldoc warnings reported by media-ci - Link to v4: https://lore.kernel.org/r/20250403-uvc-meta-v4-0-877aa6475975@chromium.org Changes in v4: - Rename format to V4L2_META_FMT_UVC_MSXU_1_5 (Thanks Mauro) - Flag the new format with a quirk. - Autodetect MSXU devices. - Link to v3: https://lore.kernel.org/linux-media/20250313-uvc-metadata-v3-0-c467af869c60… Changes in v3: - Fix doc syntax errors. - Link to v2: https://lore.kernel.org/r/20250306-uvc-metadata-v2-0-7e939857cad5@chromium.… Changes in v2: - Add metadata invalid fix - Move doc note to a separate patch - Introduce V4L2_META_FMT_UVC_CUSTOM (thanks HdG!). - Link to v1: https://lore.kernel.org/r/20250226-uvc-metadata-v1-1-6cd6fe5ec2cb@chromium.… --- Ricardo Ribalda (5): media: uvcvideo: Do not mark valid metadata as invalid media: Documentation: Add note about UVCH length field media: uvcvideo: Introduce dev->meta_formats media: uvcvideo: Introduce V4L2_META_FMT_UVC_MSXU_1_5 media: uvcvideo: Auto-set UVC_QUIRK_MSXU_META .../userspace-api/media/v4l/meta-formats.rst | 1 + .../media/v4l/metafmt-uvc-msxu-1-5.rst | 23 ++++ .../userspace-api/media/v4l/metafmt-uvc.rst | 4 +- MAINTAINERS | 1 + drivers/media/usb/uvc/uvc_driver.c | 7 ++ drivers/media/usb/uvc/uvc_metadata.c | 133 +++++++++++++++++++-- drivers/media/usb/uvc/uvc_video.c | 12 +- drivers/media/usb/uvc/uvcvideo.h | 3 + drivers/media/v4l2-core/v4l2-ioctl.c | 1 + include/linux/usb/uvc.h | 3 + include/uapi/linux/videodev2.h | 1 + 11 files changed, 175 insertions(+), 14 deletions(-) --- base-commit: c3021d6a80ff05034dfee494115ec71f1954e311 change-id: 20250403-uvc-meta-e556773d12ae Best regards, -- Ricardo Ribalda <ribalda(a)chromium.org>

2 weeks, 6 days

1
1
0 0

Re: Patch "tcp: reorganize tcp_in_ack_event() and tcp_count_delivered()" has been added to the 6.6-stable tree

by Eric Dumazet

On Thu, May 22, 2025 at 3:44 PM Sasha Levin <sashal(a)kernel.org> wrote: > > This is a note to let you know that I've just added the patch titled > > tcp: reorganize tcp_in_ack_event() and tcp_count_delivered() > > to the 6.6-stable tree which can be found at: > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… > > The filename of the patch is: > tcp-reorganize-tcp_in_ack_event-and-tcp_count_delive.patch > and it can be found in the queue-6.6 subdirectory. > > If you, or anyone else, feels it should not be added to the stable tree, > please let <stable(a)vger.kernel.org> know about it. > > May I ask why this patch was backported to stable versions ? This is causing a packetdrill test to fail. Ilpo, can you take a look ? # packetdrill --ip_version=ipv6 --mtu=1520 dctcp-plb-simple.pkt dctcp-plb-simple.pkt:49: error handling packet: inconsistent flowlabels for this packet: expected: 0x1c50c vs actual: 0xb867c script packet: 0.032224 P.W 5001:6001(1000) ack 1 <nop,nop,TS val 100 ecr 100> actual packet: 0.032209 P.W 5001:6001(1000) ack 1 win 255 <nop,nop,TS val 124 ecr 100> $ cat dctcp-plb-simple.pkt // DCTCP PLB Test // Check that DCTCP rehashes based on PLB congestion conditions `sysctl -qw net/ipv4/tcp_ecn=1 \ net/ipv4/tcp_congestion_control=dctcp \ net/ipv4/tcp_plb_enabled=1 \ net/ipv4/tcp_rmem="4096 131072 15000000"` // Initialize connection 0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3 +0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 +0 bind(3, ..., ...) = 0 +0 listen(3, 1) = 0 // ECN handshake: send EW flags in SYN packet, E flag in SYN-ACK response +0 < SEW 0:0(0) win 32792 <mss 1460,sackOK,TS val 100 ecr 100,nop,wscale 6> +0 > (flowlabel 0x1) SE. 0:0(0) ack 1 <mss 1460,sackOK,TS val 100 ecr 100,nop,wscale 8> +0 < . 1:1(0) ack 1 win 257 +0 accept(3, ..., ...) = 4 +0 getsockopt(4, IPPROTO_TCP, TCP_CONGESTION, "dctcp", [5]) = 0 +0 write(4, ..., 1000) = 1000 +0 > (flowlabel 0x1) P. 1:1001(1000) ack 1 <nop,nop,TS val 100 ecr 100> +0 < . 1:1(0) ack 1001 win 1000 <nop,nop,TS val 100 ecr 100> // no ECN mark, flowlabel won't change. +0 write(4, ..., 1000) = 1000 +0 > (flowlabel 0x1) P. 1001:2001(1000) ack 1 <nop,nop,TS val 100 ecr 100> +0 < . 1:1(0) ack 2001 win 1000 <nop,nop,TS val 100 ecr 100> // No packets ECN-marked. +0 write(4, ..., 1000) = 1000 +0 > (flowlabel 0x1) P. 2001:3001(1000) ack 1 <nop,nop,TS val 100 ecr 100> +0 < E. 1:1(0) ack 3001 win 1000 <nop,nop,TS val 100 ecr 100> // ECN-marked. 1 congested round. +0 write(4, ..., 1000) = 1000 +0 > (flowlabel 0x1) PW. 3001:4001(1000) ack 1 <nop,nop,TS val 100 ecr 100> +0 < E. 1:1(0) ack 4001 win 1000 <nop,nop,TS val 100 ecr 100> // ECN-marked. 2 congested round. +0 write(4, ..., 1000) = 1000 +0 > (flowlabel 0x1) PW. 4001:5001(1000) ack 1 <nop,nop,TS val 100 ecr 100> +0 < E. 1:1(0) ack 5001 win 1000 <nop,nop,TS val 100 ecr 100> // ECN-marked. 3 congested round. +0 write(4, ..., 1000) = 1000 // Flowlabel will change next round +0 > (flowlabel 0x1) PW. 5001:6001(1000) ack 1 <nop,nop,TS val 100 ecr 100> +0 < . 1:1(0) ack 6001 win 1000 <nop,nop,TS val 100 ecr 100> // No packets ECN-marked. 0 congested round. +0 write(4, ..., 1000) = 1000 +0 > (flowlabel 0x2) P. 6001:7001(1000) ack 1 <nop,nop,TS val 100 ecr 100> +0 < . 1:1(0) ack 7001 win 1000 <nop,nop,TS val 100 ecr 100> // No packets ECN-marked. Verify new flowlabel +0 write(4, ..., 1000) = 1000 +0 > (flowlabel 0x2) P. 7001:8001(1000) ack 1 <nop,nop,TS val 100 ecr 100> +0 < . 1:1(0) ack 8001 win 1000 <nop,nop,TS val 100 ecr 100> // No packets ECN-marked. New flowlabel should stick > > commit c39f5ebea6713c908f64e4682c26d144d9a659de > Author: Ilpo Järvinen <ij(a)kernel.org> > Date: Wed Mar 5 23:38:41 2025 +0100 > > tcp: reorganize tcp_in_ack_event() and tcp_count_delivered() > > [ Upstream commit 149dfb31615e22271d2525f078c95ea49bc4db24 ] > > - Move tcp_count_delivered() earlier and split tcp_count_delivered_ce() > out of it > - Move tcp_in_ack_event() later > - While at it, remove the inline from tcp_in_ack_event() and let > the compiler to decide > > Accurate ECN's heuristics does not know if there is going > to be ACE field based CE counter increase or not until after > rtx queue has been processed. Only then the number of ACKed > bytes/pkts is available. As CE or not affects presence of > FLAG_ECE, that information for tcp_in_ack_event is not yet > available in the old location of the call to tcp_in_ack_event(). > > Signed-off-by: Ilpo Järvinen <ij(a)kernel.org> > Signed-off-by: Chia-Yu Chang <chia-yu.chang(a)nokia-bell-labs.com> > Signed-off-by: David S. Miller <davem(a)davemloft.net> > Signed-off-by: Sasha Levin <sashal(a)kernel.org> > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > index 10d38ec0ff5ac..a172248b66783 100644 > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -425,6 +425,20 @@ static bool tcp_ecn_rcv_ecn_echo(const struct tcp_sock *tp, const struct tcphdr > return false; > } > > +static void tcp_count_delivered_ce(struct tcp_sock *tp, u32 ecn_count) > +{ > + tp->delivered_ce += ecn_count; > +} > + > +/* Updates the delivered and delivered_ce counts */ > +static void tcp_count_delivered(struct tcp_sock *tp, u32 delivered, > + bool ece_ack) > +{ > + tp->delivered += delivered; > + if (ece_ack) > + tcp_count_delivered_ce(tp, delivered); > +} > + > /* Buffer size and advertised window tuning. > * > * 1. Tuning sk->sk_sndbuf, when connection enters established state. > @@ -1137,15 +1151,6 @@ void tcp_mark_skb_lost(struct sock *sk, struct sk_buff *skb) > } > } > > -/* Updates the delivered and delivered_ce counts */ > -static void tcp_count_delivered(struct tcp_sock *tp, u32 delivered, > - bool ece_ack) > -{ > - tp->delivered += delivered; > - if (ece_ack) > - tp->delivered_ce += delivered; > -} > - > /* This procedure tags the retransmission queue when SACKs arrive. > * > * We have three tag bits: SACKED(S), RETRANS(R) and LOST(L). > @@ -3816,12 +3821,23 @@ static void tcp_process_tlp_ack(struct sock *sk, u32 ack, int flag) > } > } > > -static inline void tcp_in_ack_event(struct sock *sk, u32 flags) > +static void tcp_in_ack_event(struct sock *sk, int flag) > { > const struct inet_connection_sock *icsk = inet_csk(sk); > > - if (icsk->icsk_ca_ops->in_ack_event) > - icsk->icsk_ca_ops->in_ack_event(sk, flags); > + if (icsk->icsk_ca_ops->in_ack_event) { > + u32 ack_ev_flags = 0; > + > + if (flag & FLAG_WIN_UPDATE) > + ack_ev_flags |= CA_ACK_WIN_UPDATE; > + if (flag & FLAG_SLOWPATH) { > + ack_ev_flags |= CA_ACK_SLOWPATH; > + if (flag & FLAG_ECE) > + ack_ev_flags |= CA_ACK_ECE; > + } > + > + icsk->icsk_ca_ops->in_ack_event(sk, ack_ev_flags); > + } > } > > /* Congestion control has updated the cwnd already. So if we're in > @@ -3938,12 +3954,8 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag) > tcp_snd_una_update(tp, ack); > flag |= FLAG_WIN_UPDATE; > > - tcp_in_ack_event(sk, CA_ACK_WIN_UPDATE); > - > NET_INC_STATS(sock_net(sk), LINUX_MIB_TCPHPACKS); > } else { > - u32 ack_ev_flags = CA_ACK_SLOWPATH; > - > if (ack_seq != TCP_SKB_CB(skb)->end_seq) > flag |= FLAG_DATA; > else > @@ -3955,19 +3967,12 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag) > flag |= tcp_sacktag_write_queue(sk, skb, prior_snd_una, > &sack_state); > > - if (tcp_ecn_rcv_ecn_echo(tp, tcp_hdr(skb))) { > + if (tcp_ecn_rcv_ecn_echo(tp, tcp_hdr(skb))) > flag |= FLAG_ECE; > - ack_ev_flags |= CA_ACK_ECE; > - } > > if (sack_state.sack_delivered) > tcp_count_delivered(tp, sack_state.sack_delivered, > flag & FLAG_ECE); > - > - if (flag & FLAG_WIN_UPDATE) > - ack_ev_flags |= CA_ACK_WIN_UPDATE; > - > - tcp_in_ack_event(sk, ack_ev_flags); > } > > /* This is a deviation from RFC3168 since it states that: > @@ -3994,6 +3999,8 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag) > > tcp_rack_update_reo_wnd(sk, &rs); > > + tcp_in_ack_event(sk, flag); > + > if (tp->tlp_high_seq) > tcp_process_tlp_ack(sk, ack, flag); > > @@ -4025,6 +4032,7 @@ static int tcp_ack(struct sock *sk, const struct sk_buff *skb, int flag) > return 1; > > no_queue: > + tcp_in_ack_event(sk, flag); > /* If data was DSACKed, see if we can undo a cwnd reduction. */ > if (flag & FLAG_DSACKING_ACK) { > tcp_fastretrans_alert(sk, prior_snd_una, num_dupack, &flag,

2 weeks, 6 days

5
5
0 0

Revert of a commit in 6.6-stable

by Jens Axboe

Hi Greg and crew, Can you revert: commit 746e7d285dcb96caa1845fbbb62b14bf4010cdfb Author: Jens Axboe <axboe(a)kernel.dk> Date: Wed May 7 08:07:09 2025 -0600 io_uring: ensure deferred completions are posted for multishot in 6.6-stable? There's some missing dependencies that makes this not work right, I'll bring it back in a series instead. -- Jens Axboe

2 weeks, 6 days

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror