在 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/
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/