Re: [PATCH] tmpfs: don't interrupt fallocate with EINTR

[Matthew Wilcox <willy@infradead.org>]

On Thu, May 16, 2024 at 12:10:44AM +0200, Jan Kara wrote:
> From: Mikulas Patocka <mpatocka@redhat.com>
> 
> 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>

Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>