Re: [LSF/MM/BPF TOPIC] Replacing TASK_(UN)INTERRUPTIBLE with regions of uninterruptibility

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux