Whamcloud - gitweb
LU-15994 llite: use fatal_signal_pending in range_lock
authorQian Yingjin <qian@ddn.com>
Tue, 2 Aug 2022 09:14:48 +0000 (05:14 -0400)
committerAndreas Dilger <adilger@whamcloud.com>
Wed, 10 Aug 2022 01:40:11 +0000 (01:40 +0000)
commit3c1ebf1f460151a6ef9e3daab397ccf21435f843
tree3598e458d3561218d06b83380e17a44bbdbce356
parent4b37e5c01e30e820bd8558f9381c0b6b2d2eb158
LU-15994 llite: use fatal_signal_pending in range_lock

FIO io_uring failed with one file shared by two FIO processes
under Unubtu 2204 kernel.
After analyzed, we found that range_lock() function returns
-ERESTARTSYS when there is pending signal on current process in
Lustre I/O. This causes -EINTR returned to the application.

The reason that we have pending signal is because that io_uring
is using signal based task_work running in new kernel. Thus when
I/O process tries to acquire range lock and checks whether
signal_pending(), it may always find a pending signal and return
-ERESTARTSYS.

we solve this bug by replacing @signal_pending(current) with
@fatal_signal_pending(current) in range_lock(). The range_lock()
function only returns -ERESTARTSYS when the current process has
fatal pending signal such as SIGKILL.

Lustre-change: https://review.whamcloud.com/48106
Lustre-commit: TBD(91244566e9d2762c2f64a67e7d4fad8f301b556c)

Signed-off-by: Qian Yingjin <qian@ddn.com>
Change-Id: I0a0be8fa3b4ba5c89f7866286b2bdc6595f18026
Reviewed-on: https://review.whamcloud.com/48111
Tested-by: jenkins <devops@whamcloud.com>
Tested-by: Maloo <maloo@whamcloud.com>
Reviewed-by: Andreas Dilger <adilger@whamcloud.com>
lustre/obdclass/range_lock.c