On Fri, Feb 02, 2024 at 08:51:22AM +0000, David Howells wrote:
> Hi,
>
> We have various locks, mutexes, etc., that are taken on entry to filesystem
> code, for example, and a bunch of them are taken interruptibly or killably (or
> ought to be) - but filesystem code might be called into from uninterruptible
> code, such as the memory allocator, fscache, etc..
>
> Does it make sense to replace TASK_{INTERRUPTIBLE,KILLABLE,UNINTERRUPTIBLE}
> with begin/end functions that define the area of uninterruptibility? The
> regions would need to handle being nested, so maybe some sort of counter in
> the task_struct counter would work.
I don't think filesystems ever want to do stuff interruptible.
That allows any signal, including SIGALRM, SIGWINCH or SIGUSR[12] to
interrupt your sleep, and user code just isn't written to handle that
(short reads, etc).
But killable is useful. If I hit ^C, I want the task to die. Maybe some
of its resources hang around futilely waiting for a packet that will never
arrive; so be it. So I would not define inode_lock_interruptible().
But I would define inode_lock_killable(). I'd be happy to see that
overridden by a task_set_uninterruptible(), but we do need a new API to
give filesystems a chance to handle "I didn't get the lock, abort".
