diff options
author | Mikulas Patocka <mpatocka@redhat.com> | 2024-05-16 01:10:44 +0300 |
---|---|---|
committer | Christian Brauner <brauner@kernel.org> | 2024-06-03 17:35:17 +0300 |
commit | ca86a5d2f9feed16e11023891c8c70aa57ced24e (patch) | |
tree | f5426779da23e879c5f112d2c965e06875c091fc /fs/stat.c | |
parent | 2a010c41285345da60cece35575b4e0af7e7bf44 (diff) | |
download | linux-ca86a5d2f9feed16e11023891c8c70aa57ced24e.tar.xz |
tmpfs: don't interrupt fallocate with EINTR
I have a program that sets up a periodic timer with 10ms interval. When
the program attempts to call fallocate(2) on tmpfs, it goes into an
infinite loop. fallocate(2) takes longer than 10ms, so it gets
interrupted by a signal and it returns EINTR. On EINTR, the fallocate
call is restarted, going into the same loop again.
Let's change the signal_pending() check in shmem_fallocate() loop to
fatal_signal_pending(). This solves the problem of shmem_fallocate()
constantly restarting. Since most other filesystem's fallocate methods
don't react to signals, it is unlikely userspace really relies on timely
delivery of non-fatal signals while fallocate is running. Also the
comment before the signal check:
/*
* Good, the fallocate(2) manpage permits EINTR: we may have
* been interrupted because we are using up too much memory.
*/
indicates that the check was mainly added for OOM situations in which
case the process will be sent a fatal signal so this change preserves
the behavior in OOM situations.
[JK: Update changelog and comment based on upstream discussion]
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20240515221044.590-1-jack@suse.cz
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Diffstat (limited to 'fs/stat.c')
0 files changed, 0 insertions, 0 deletions