Как реализации системных вызовов Linux обрабатывают перехваченный сигнал?

How does the syscalls implementation (for example read()) handle a signal.

Что ж, это может быть частью неправильного понимания, которое мы часто говорим о системных вызовах, как будто это одно и то же, но на самом деле интерфейс пользовательского пространства обычно проходит через стандартную библиотеку. И часть пространства ядра, которая выполняет работу системного вызова, представляет собой поток ядра, выполняющий код ядра. Потоки ядра не подчиняются тем же правилам, что и потоки пользовательского пространства, а сигналы ставятся в очередь и потенциально объединяются и могут даже не доставляться.

... For example, in case of read(), let's say we are inside a read function in the ext2 filesystem driver. Does the function check every time if a signal had occurred? Because it needs to free the resources it allocated and/or unlock the locks it aquired. To sum up, my question is how the syscall implementation (that includes calling to many different functions in the kernel and in drivers) know that the signal had occurred and free the resources it allocated?

В этом нет необходимости, потому что код файловой системы будет выполняться как поток ядра без сигналов. Существует высокая вероятность того, что ваш системный вызов все равно не вызовет немедленное действие kenrel, а скорее поставит очередь для завершения рабочего потока. В этом случае поток обычно обрабатывает сигнал, ожидая завершения ввода-вывода, это прерываемое поведение. Обратите внимание, что это происходит в пользовательском пространстве вне контекста, в котором выполняется системный вызов. Потоки ядра частично не реагируют на системный вызов, потому что то, что они будут делать, сложно сохранять и восстанавливать в странных контекстах.

If the syscall is waiting on a mutex to be available (the task is blocked) and a signal occurs, how does the kernel inform the calling function for the mutex lock() that it wasn't locked but a signal had occurred?

Этого не должно происходить в пространстве ядра с сигналами в очереди. Важно защитить код пользовательского пространства от небезопасной ситуации с сигналами, поэтому приложение может написать, чтобы выяснить, была ли это проблема и как ее исправить.

Let's say a signal occurred during the execution of function read() of the ext2 driver. How does the VFS layer and the main syscall function (read()) know that the ext2 driver read function had failed because of a signal. Do they all have the necessary checks for it? Isn't it a lot of checks to make?

Это не так, потому что это не приведет к сбою, поскольку процессы ядра не действуют на сигналы. Он будет поставлен в очередь до тех пор, пока управление не будет возвращено процессу пользовательского пространства, о котором было сообщено.

См. также:

Как сигналы обрабатываются в ядре

Это может быть обманом.