Deadlock problems

Deadlock problems

[Jan Kara]

  Hi Andrew!

  I've found hard to fix problem causing deadlock - call path is
generally following:
  some operation -> quota code -> read/write quota -> vfs -> needs a page ->
shrink caches -> free inodes -> free quota -> Ouch... (we need to acquire
some lock which is already held by the quota code)

   I hope I can fix the problems with quota locks but there's also a
problem that transaction can be already started when we want to free
some inodes etc. So I'd like to ask: Is there somewhere documented what
can/cannot hold a caller using GFP_FS?
  One a bit hacky solution would also be to clear GFP_FS from i_mapping
of quotafile inode. Do you think that is a reasonable solution?

								Honza

Re: Deadlock problems

[Chris Mason]

On Mon, 2004-05-03 at 07:58, Jan Kara wrote:
>   Hi Andrew!
> 
>   I've found hard to fix problem causing deadlock - call path is
> generally following:
>   some operation -> quota code -> read/write quota -> vfs -> needs a page ->
> shrink caches -> free inodes -> free quota -> Ouch... (we need to acquire
> some lock which is already held by the quota code)
> 
Ugh, for some reason I thought we were avoiding this one in 2.6.  This
is why I made kinoded for the quota patches in 2.4.x

-chris

Re: Deadlock problems

[Andrew Morton]

Jan Kara <jack@ucw.cz> wrote:
>
>   Hi Andrew!
> 
>   I've found hard to fix problem causing deadlock - call path is
> generally following:
>   some operation -> quota code -> read/write quota -> vfs -> needs a page ->
> shrink caches -> free inodes -> free quota -> Ouch... (we need to acquire
> some lock which is already held by the quota code)
>
>    I hope I can fix the problems with quota locks but there's also a
> problem that transaction can be already started when we want to free
> some inodes etc.

yes, there could be any number of deadlocks due to this.

> So I'd like to ask: Is there somewhere documented what
> can/cannot hold a caller using GFP_FS?

I don't understand the question, sorry.  But memory allocations while
holding fs locks should not be using __GFP_FS.

>   One a bit hacky solution would also be to clear GFP_FS from i_mapping
> of quotafile inode. Do you think that is a reasonable solution?

yes, I think that is a reasonable expression of what is going on.

It would be better to rework the filesystems so that it is not necessary,
but I assume that is complex.