On Fri, Feb 02, 2024 at 10:08:59AM +0100, Miklos Szeredi wrote: > On Fri, 2 Feb 2024 at 09:51, David Howells <dhowells@xxxxxxxxxx> 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.. > > Are you suggesting to make lots more filesystem/vfs/mm sleeps > killable? That would present problems with being called from certain > contexts. > > Or are there bugs already? I believe it's both. Potentially we could get rid of e.g. mutex_lock_interruptible() and mutex_lock_killable() so our API surface goes down, and I've seen at least one bug where we were checking for a signal pending and bailing out where we really didn't want to be. I think we'd need the new API prototyped in order to have a concrete discussion though.
