should delete_inode be allowed to be called from shrink_dcache?

should delete_inode be allowed to be called from shrink_dcache?

[Vladimir Saveliev]

Hello

Is there anything wrong that

mkdir dir
cd dir
rmdir ../dir
ls file
cd ..

leaves after itself two dentries - negative one ("file") and dentry of
directory "dir" which is attached to inode of that directory?

After that a process may get into somefs_delete_inode trying to free
pages by shrinking dcache (it will first free negative dentry and then
its parent).
If process is doing that being already in somefs_write (for example)
some filesystems may have problems.


Thanks

Re: should delete_inode be allowed to be called from shrink_dcache?

[Al Viro]

On Sat, Nov 27, 2004 at 02:40:57PM +0300, Vladimir Saveliev wrote:
> Hello
> 
> Is there anything wrong that
> 
> mkdir dir
> cd dir
> rmdir ../dir
> ls file
> cd ..
> 
> leaves after itself two dentries - negative one ("file") and dentry of
> directory "dir" which is attached to inode of that directory?

No, it's legitimate (and can happen in other scenarios).
 
> After that a process may get into somefs_delete_inode trying to free
> pages by shrinking dcache (it will first free negative dentry and then
> its parent).
> If process is doing that being already in somefs_write (for example)
> some filesystems may have problems.

Details, please...  All filesystems I'm familiar with won't (AFAICS) have
any problems with that.  What exactly do you have in mind?  Note that
in a lot of areas you get GFP_NOFS allocations anyway - that's the primary
defense against deadlocks and it's almost always enough.  The only trouble
I can recall more or less recently was hpfs - there we had (among shitpiles
of other races) several places that required explicit GFP_NOFS.  Usually
it just works...