Post #965

在 lwn 读到的一些有意思的技术文章但是自己并无深刻的见解，就时不时一起放送好了 😵 racket 9.0 发版！每次看到 lisp 系那些稀奇古怪的术语都觉得耳目一新（当然也是因为我没什么见识 😭），比如 black-box! https://docs.racket-lang.org/reference/black-box.html#%28def._%28%28quote._~23~25kernel%29._black-box%29%29 gcc15 新增了 counted_by attribute 来告诉编译器 FAM 的长度 #include <stdio.h> struct A { unsigned count; int buf[] __attribute__ ((counted_by (count))); }; static struct A __attribute__ ((noinline)) *alloc_buf (unsigned sz) { struct A *obj = __builtin_malloc (sizeof(struct A) + sz * sizeof(int)); obj->count = sz; return obj; } int main () { struct A *p = alloc_buf (10); printf("Size of buf is: %d\n", __builtin_dynamic_object_size(p->buf, 1)); p->buf[12] = 22; // out-of-bound access return 0; } 上面的代码在 gcc -fsanitize=bounds main.c 之后运行直接 out of bound runtime error oracle 的华人工程师干的： https://blogs.oracle.com/linux/improving-gcc-buffer-overflow-detection-for-c-flexible-array-members 不过我本来抱着零成本的预期（为什么？我被 bpf verifier 虐出幻觉了吗？），看了一下发现 buf[12] 会被编译成为 call __ubsan_handle_out_of_bounds，合理。。。 相信每个从 docker 时代走过来的云原神工程师都有找不到 netns 的心酸时刻，不过黑暗的日子要过去了，因为，listns() API 制作决定！这种愿意清理技术债、减小项目熵的工程师，我愿意称之为伪人，啊不是，伟人！ https://lwn.net/Articles/1043824/ PEP 805 Safe Parallel Python，给 list.append / set.add 等之前在 GIL 保护下是线程安全的操作开始打补丁，我是并发弱智所以看到什么都叫好，比如我觉得下面这个自动解决“哲学家吃饭问题”的锁排序的糖就好： with a.__mutex__ + b.__mutex__: ... __protect__ 这些 API 看起来也很直观好用的样子。 https://pep-previews--4579.org.readthedocs.build/pep-0805/ envoy 默认劫持模式是用 iptables -j REDIRECT 把流量 DNAT 成 127.0.0.1:15001，而不是 tproxy。稍微思考就会意识到，有一种风险是，之前是两个连接 10.1.1.1:19233 -> 1.1.1.1:80 和 10.1.1.1:19233 -> 1.0.0.1:80，在 DNAT 之后两个 tuples 变成一样的了，这会导致代理冲突。不过内核真的会出现两个连接共用 src port 吗？cloudflare 对各种情况做了非常仔细的解读，唯一的问题是读了两遍之后我更加不明白 envoy 默认劫持模式是怎么能上生产的，这不会爆炸吗？🤬 https://blog.cloudflare.com/how-to-stop-running-out-of-ephemeral-ports-and-start-to-love-long-lived-connections/