Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
> > 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.
No, it wouldn't. What I'm suggesting is something like:
overlayfs_mkdir(inode)
{
inode_lock(inode); <--- This could be interruptible
...
begin_task_uninterruptible();
...
do_stuff();
...
inode->lower->inode->mkdir(inode->lower->inode);
^--- say ext4_mkdir
...
do_more_stuff();
end_task_uninterruptible();
inode_unlock(inode);
}
ext4_mkdir(inode)
{
inode_lock(inode); <--- This would be interruptible, but
called from overlayfs above is now
uninterruptible
...
}
You bracket the context where interruptibility is bad and then everyone you
call is forced to be uninterruptible. This would need to be nestable also:
begin_task_uninterruptible();
begin_task_uninterruptible();
begin_task_uninterruptible();
...
end_task_uninterruptible(); // must not become interruptible
end_task_uninterruptible(); // nor this
end_task_uninterruptible(); // from here *could* be interruptible again
Obviously, we would need to gradate this to accommodate killability also.
David
