- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Subscribing mailing list with a different account
by shadow_coder111 July 9, 2025

July 9, 2025

Hi Kernel Newbies Team, I'm currently subscribed to the mailing list via this ProtonMail account. However, I'd like to use my Gmail address for future communication as it integrates better with my workflow and patch tracking tools. I had previously submitted a subscription request using my Gmail, but haven't received any confirmation yet. Could you please let me know the status of that request? If there's anything I need to do to expedite the process or verify my identity, I’m happy to assist. Appreciate your time and support. Best regards, Shdwcodr Sent with [Proton Mail](https://proton.me/mail/home) secure email.

1 0

Wiki editing
by Dirk Gouders July 8, 2025

July 8, 2025

Hi, from time to time, I look at the wiki and sometimes I see the need for corrections or additions. This time, it is https://kernelnewbies.org/nftables_examples; the paragraph "Improved syntax wrt. iptables" looks broken and if I were allowed to edit it, I'd try to fix that. So, I'd like to ask to be added to the list of editors. Thank you, Dirk

2 4

Kernel newbie task
by Lennie De Villiers July 5, 2025

July 5, 2025

Hi I am a old timer Senior software engineer with C/C++ as my first language. I would like to become a contributor. Any project i can assit on. Regards Lennie

2 1

Does this patch about module loading make sense?
by Julian LaGattuta June 17, 2025

June 17, 2025

Hi, I'm new to the linux kernel and have never made a patch. I just made a modification, on my own system, to linux that cancels the loading of a module if the module crashes during its init call. This has the benefit of allowing modules to be unloaded after they have crashed in the init, and allow callers of the init_module syscall to get a response saying the module crashed. Normally, the init call happens in the same thread as whoever wants to load the module. The way this is implemented is that I moved the init call to a separate kthread and I detect if the kthread exited normally. If the kthread failed, load_module returns -ECANCELED. My questions are: Is this a feature worth submitting a patch for? Is there a reason this hasn't been done? Are there fundamental flaws in my approach? Is there other feedback I should have? I don't know other people with experience with the linux kernel so anyone's feedback would be helpful. Sincerely, Julian

2 1

DMARC support
by Siddh Raman Pant June 10, 2025

June 10, 2025

Hi, Is there a reason why this mailing list still doesn't support DMARC? I see regular DMARC failure reports due to this list. Thanks, Siddh

3 2

[RFC] Netkit cannot be an XDP_REDIRECT target ?
by Alexandre Ferrieux June 8, 2025

June 8, 2025

Hi, When looking at netkit papers, one tends to view it as a kind of veth, rewritten for efficiency. However, the feature flags of a netkit never contain NETDEV_XDP_ACT_NDO_XMIT. In other words, it can never be an XDP_REDIRECT target. By contrast, xdp-redirecting to a veth works. This means that netkit is far from being a "drop-in" replacement for veth "just faster". It rather sounds like unfinished work. What am I missing here ? Is there another method to pass frames from the XDP RX hook of an interface to a netkit's ring ? Is netkit "here to stay", being actively worked on ? Or is it a single-purpose experiment that will never try to reach veth's functional coverage ? Thanks for any clarifications. -Alex

1 0

(no subject)
by chen cheng June 7, 2025

June 7, 2025

1 0

NET: TCP Server Remains in ESTABLISHED State After RST Sent — 5.15 Kernel
by Oracle June 6, 2025

June 6, 2025

I’m encountering an issue during a high-concurrency short-lived connection stress test in a distributed database system. The system under test is running on a single machine. The server sometimes sends a TCP RST after completing the three-way handshake, and while the client receives the RST and closes the connection, the server-side socket remains in ESTABLISHED state. System Information Linux systest104 5.15.0-305.176.4.el9uek.x86_64 #2 SMP Tue Jan 28 20:15:04 PST 2025 x86_64 x86_64 x86_64 GNU/Linux Problem Description During the short-link stress test (many TCP connections being rapidly established and closed), the server (PostgreSQL) sends an unexpected RST after the handshake. Despite the RST and client-side closure, the server socket stays in ESTABLISHED. This behavior repeats under high load. netstat Output [root@systest104 tools]# netstat -atpn | grep 45129 | grep LI tcp 0 0 10.13.8.104:45129 0.0.0.0:* LISTEN 3961360/postgres: tcp 0 0 10.13.8.104:45129 10.13.8.104:45052 ESTABLISHED 3961360/postgres: TCP Traffic Capture (tcpdump) From server (port 45129) to client (port 45052): 02:58:03.972859 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 10.13.8.104.45129 > 10.13.8.104.45052: Flags [S.], cksum 0x2518 (incorrect -> 0xe388), seq 175553476, ack 2894832976, win 65535, options [mss 65495,sackOK,TS val 1670382316 ecr 1670382316,nop,wscale 11], length 0 02:58:04.218997 IP (tos 0x0, ttl 64, id 9377, offset 0, flags [DF], proto TCP (6), length 52) 10.13.8.104.45129 > 10.13.8.104.45052: Flags [.], cksum 0x2510 (incorrect -> 0x0a6e), seq 1, ack 42, win 32, options [nop,nop,TS val 1670382564 ecr 1670382522], length 0 02:58:04.979788 IP (tos 0x0, ttl 64, id 9378, offset 0, flags [DF], proto TCP (6), length 52) 10.13.8.104.45129 > 10.13.8.104.45052: Flags [F.], cksum 0x2510 (incorrect -> 0x0776), seq 1, ack 42, win 32, options [nop,nop,TS val 1670383323 ecr 1670382522], length 0 02:58:06.494295 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 10.13.8.104.45129 > 10.13.8.104.45052: Flags [S.], cksum 0x2518 (incorrect -> 0x7ac8), seq 214961739, ack 2894898555, win 65535, options [mss 65495, sackOK, TS val 1670384838 ecr 1670384838,nop,wscale 11], length 0 02:58:06.497830 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) 10.13.8.104.45129 > 10.13.8.104.45052: Flags [R], cksum 0x0f95 (correct), seq 214961740, win 0, length 0 From client (port 45052) to server (port 45129): 10.13.8.104.45052 > 10.13.8.104.45129: Flags [S], cksum 0x2518 (incorrect -> 0x9bdf), seq 2894898554, win 65535, options [mss 65495,sackOK,TS val 1670384838 ecr 1670383323,nop,wscale 11], length 0 02:58:06.496318 IP (tos 0x0, ttl 64, id 15240, offset 0, flags [DF], proto TCP (6), length 52) 10.13.8.104.45052 > 10.13.8.104.45129: Flags [.], cksum 0x2510 (incorrect -> 0xa39b), seq 65579, ack 39408264, win 32, options [nop,nop,TS val 1670384839 ecr 1670384838], length 0 02:58:06.496321 IP (tos 0x0, ttl 64, id 15241, offset 0, flags [DF], proto TCP (6), length 84) 10.13.8.104.45052 > 10.13.8.104.45129: Flags [P.], cksum 0x2530 (incorrect -> 0x2b50), seq 65579:65611, ack 39408264, win 32, options [nop,nop,TS val 1670384839ecr 1670384838], length 32 Kernel Socket State Transitions ffff9de27cb78000 3499722 postgres   10.13.8.104 45052 → 45129   SYN_RECV → ESTABLISHED 0.003s ffff9dd18eb25580 3961360 postgres   10.13.8.104 45129 → 45052   SYN_SENT → ESTABLISHED 1.165s ffff9dd18eb25580 353     ksoftirqd 10.13.8.104 45129 → 45052   ESTABLISHED → CLOSE   4.154s Summary The client (45052) initiates a connection to the server (45129). The connection completes (ESTABLISHED). Then a new SYN is seen, followed shortly by an RST from the server. However, the server socket does not transition out of ESTABLISHED despite sending the RST. The connection appears "stuck" in the ESTABLISHED state from the server’s perspective. Question What could cause the kernel to send an RST but still leave the server-side socket in ESTABLISHED state? Shouldn’t the kernel remove the connection after sending the RST? Any insight into what may be going wrong here (socket leak, improper closure, application issue, kernel bug) would be appreciated. Thanks, ZHAO

2 1

Re: TCP high concurrency, RST connection cannot be released normally
by Siddh Raman Pant June 1, 2025

June 1, 2025

Please use plain text email instead of HTML and reply to the original email again. Your email was likely rejected / filtered as spam by the mailing list, maybe because of the image. Also: https://docs.kernel.org/process/submitting-patches.html#use-trimmed-interle… Thanks, Siddh

1 0

TCP high concurrency, RST connection cannot be released normally
by Oracle May 31, 2025

May 31, 2025

  Problem description: Abnormal message appears in high-concurrency short connection, the server sends rst to the client, the client connection is closed, but the server connection that sends rst is still in ESTABLISHED state? What is the reason? I captured some information through bpf and confirmed that the server sent rst and the client status changed to close. I tracked the failure return of tcp_v4_send_reset and tcp_rcv_state_process and found that TCP RST: ACK flag = 1, but the tcp state printed here is the listen state, which is not consistent with the current connection status viewed by netstat. (Not sure if some events are discarded), but the tcpdump packet capture analysis shows that the server is indeed rst and the connection is not released. [root@systest104 zx]# netstat -atpn|grep 45129 |grep ES tcp        0      0 10.13.8.104:45129       10.13.8.104:45052       ESTABLISHED 3942077/postgres:  #The connection still exists tcpdump: 02:58:06.494295 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)     10.13.8.104.45129 > 10.13.8.104.45052: Flags [S.], cksum 0x2518 (incorrect -> 0x7ac8), seq 214961739, ack 2894898555, win 65535, options [mss 65495,sackOK,TS val 1670384838 ecr 1670384838,nop,wscale 11], length 0 02:58:06.496318 IP (tos 0x0, ttl 64, id 15240, offset 0, flags [DF], proto TCP (6), length 52)     10.13.8.104.45052 > 10.13.8.104.45129: Flags [.], cksum 0x2510 (incorrect -> 0xa39b), seq 65579, ack 39408264, win 32, options [nop,nop,TS val 1670384839 ecr 1670384838], length 0 02:58:06.496321 IP (tos 0x0, ttl 64, id 15241, offset 0, flags [DF], proto TCP (6), length 84)     10.13.8.104.45052 > 10.13.8.104.45129: Flags [P.], cksum 0x2530 (incorrect -> 0x2b50), seq 65579:65611, ack 39408264, win 32, options [nop,nop,TS val 1670384839 ecr 1670384838], length 32 02:58:06.497830 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)     10.13.8.104.45129 > 10.13.8.104.45052: Flags [R], cksum 0x0f95 (correct), seq 214961740, win 0, length 0

2 1