On Tue, 2 Sep 2025 10:54:35 +0800 Yumei Huang wrote:

Thank you Stefano for all the comments. Sent v2 to address all the issues, just that..

On Tue, Sep 2, 2025 at 5:02 AM Stefano Brivio wrote:

...

Thanks for the patch! A couple of comments, all minor:

On Mon, 1 Sep 2025 17:45:10 +0800 Yumei Huang wrote:

...

Fix the following errors on systems with glibc < 2.29:

Before anything, it's customary to credit the original author of a patch, even if it was (very) different. Something like:

Based on an original patch by Dongsheng, fix ...

and I think you should also Cc: them (they might want to test / comment / review), you can fetch the contact from https://bugs.passt.top/show_bug.cgi?id=121.

...

tcp.c: In function ‘tcp_flow_repair_on’: tcp.c:2787:38: error: ‘TCP_REPAIR_ON’ undeclared (first use in this

function); did you mean ‘TCP_REPAIR’?

...

if ((rc = repair_set(c, conn->sock, TCP_REPAIR_ON))) ^~~~~~~~~~~~~ TCP_REPAIR tcp.c:2787:38: note: each undeclared identifier is reported only once for each function it appears in tcp.c: In function ‘tcp_flow_repair_off’: tcp.c:2807:38: error: ‘TCP_REPAIR_OFF’ undeclared (first use in this function); did you mean ‘TCP_REPAIR’? if ((rc = repair_set(c, conn->sock, TCP_REPAIR_OFF))) ^~~~~~~~~~~~~~ TCP_REPAIR make: *** [Makefile:94: passt] Error 1

Signed-off-by: Yumei Huang

Just before this tag, we typically add any references, always using the "Link:" tag for simplicity.

Many other projects use separate tags such as "Bug:", "Bugzilla:", "Closes:" and so on, but we don't, so that it's a bit easier to automate parsing, if needed. In this case that would be:

Link: https://bugs.passt.top/show_bug.cgi?id=121

and perhaps a Reported-by: tag would also be good to have, here.

...

--- linux_dep.h | 6 ++++++ passt-repair.c | 1 + 2 files changed, 7 insertions(+)

diff --git a/linux_dep.h b/linux_dep.h index 240f50a..c200444 100644 --- a/linux_dep.h +++ b/linux_dep.h @@ -135,6 +135,12 @@ struct tcp_info_linux { #define CLOSE_RANGE_UNSHARE (1U << 1) #endif

+#ifndef TCP_REPAIR_ON +#define TCP_REPAIR_ON 1 +#define TCP_REPAIR_OFF 0 +#define TCP_REPAIR_OFF_NO_WP -1 /* Turn off without window probes */

We use tabs for indentation, and a full tab is displayed as 8 characters wide. For example:

#define TCP_REPAIR_ON 1 ^^ two tabs here, so that TCP_REPAIR_OFF_NO_WP is aligned too

I did replace the spaces here with two tabs in v2, and it shows aligned in my editors both vim and vscode, but it seems it's not in gmail. Tried 'set tabstop=8' and removed 'set expandtab' in the .vimrc file, and got the same result. Not sure what's going wrong...

I'm not sure either, just mind that you shouldn't rely on the web interface of Gmail because it won't show you emails / patches exactly as they are. But v2 looks good to me, so I guess you fixed it. :) Two more things: 1. look at two paragraph above this one, you'll see that quoting is not correct:

...

I did replace ... in my editors

it looks as if "I did replace ..." is from my reply, not from yours. I've seen this issue with people using Gmail but as far as I understood it's a known issue on Gmail side and they don't plan to fix it. 2. your reply contains an HTML version. While I configured passt mailing lists to be tolerant of that, I think that many upstream mailing lists (e.g. kernel lists) will just drop your message altogether if it contains an HTML part. In the end, I would suggest you use an email client instead, which makes it so much easier to work with code. I use claws-mail, other popular options include Thunderbird, Sylpheed, mutt. Maybe it can all be fixed with Gmail configurations, I'm not sure, but I've seen people struggling quite a bit before deciding to use an email client (at least for lists and patches). -- Stefano