[BUG REPORT] 部分系统调用未能被信号打断

[fslongjin]

描述

在Linux中，许多系统调用在信号到来时，会返回-ERESTARTSYS或者-EINTR，以便返回用户态处理信号。而目前DragonOS的许多系统调用没有正确处理这个问题，这就会导致某些进程kill不掉，或者是定时到了之后没能返回用户态。

期望

分两步进行完善修复：

1. 首先找到这些系统调用，并且对于上述情况，返回-EINTR。由用户程序去处理系统调用的重启。
2. 实现系统调用重启机制，保存系统调用现场，并在处理完信号之后，由内核重启部分系统调用。

如何查找这些系统调用？

这类系统调用在Linux中的重要特征是，会在被唤醒时，调用signal_pending()函数来检查当前进程是否有要处理的信号。

因此，可以在code.dragonos.org.cn里面，搜索refs:signal_pending。如果想搜网络的系统调用，那么就在path那一栏再添加一个net即可。

例子： https://code.dragonos.org.cn/search?project=linux-6.6.21&full=ERESTARTSYS&defs=&refs=&path=net+-drivers&hist=&type=&xrd=&nn=1&si=path&si=path&n=25

可能存在问题的系统调用

欢迎在本issue下面补充，我会把它更新到这里~

• sys_connect 在tcp的发起connect处，应当添加信号处理逻辑，返回-ERESTARTSYS，并在外层替换为-EINTR。否则，如果connect一直在进行的话，kill不掉这个进程。
• tcp socket的read方法
• udp socket的read方法
• raw socket的read方法
• pipe的read_at和write_at 方法：如果读取还没读到（对端无数据写入），或者写入一直写不进（buffer满），但是信号来了，进程就不会退出这个过程，导致没法kill掉。
• eventfd的read_at方法