[Top] [All Lists]

Re: _pagebuf_lookup_pages() allocation flags

To: Rajagopal Ananthanarayanan <ananth@xxxxxxx>
Subject: Re: _pagebuf_lookup_pages() allocation flags
From: Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>
Date: Fri, 16 Feb 2001 19:08:46 -0200 (BRST)
Cc: linux-xfs@xxxxxxxxxxx
In-reply-to: <3A8DADE9.15A7B549@xxxxxxx>
Sender: owner-linux-xfs@xxxxxxxxxxx
On Fri, 16 Feb 2001, Rajagopal Ananthanarayanan wrote:

> Marcelo Tosatti wrote:
> > 
> > some_xfs_operation -> down(&lock) ->
> > _pagebuf_lookup_pages(_PBF_ENTER_PAGES) -> alloc_pages(GFP_HIGHUSER) ->
> > do_try_to_free_pages() -> try_to_free_pages() -> page_launder() ->
> > writepage() -> xfs_writepage() -> down(&lock)
> > 
> > Is that possible?
> The call sequence is certainly possible, but there is no
> one global "lock" as you've thought of above. A brief explanation
> of xfs locks:
> The two primary locks in xfs are per-inode: one is the
> ilock and the other is an iolock. Further both are
> read-write locks, in the sense, that they can be taken
> in SHARED or EXCLUSIVE mode.
> Generally, the I/O paths hold the iolock;
> the write I/O paths hold the iolock EXCLUSIVE.
> Any meta-data related operation will hold the ilock;
> bmap allocation would hold the ilock EXCLUSIVE.
> Notable exceptions are single page I/O operations, which
> don't hold any locks. Example, readpage() & writepage()
> don't hold any locks; since these routines are called with
> the page locked, the lock on the page acts as a serialization
> mechanism.
> The final wrinkle is that if writepage() involved a conversion,
> then ilock would be taken in EXCLUSIVE mode.
> So, there is no single "lock" that satisfies the above deadlock
> scenario as far as I can see ...

I see. 

I still wonder why GFP_BUFFER is being used as the flag for PBF_MAPPABLE
callers. If there is no deadlock condition there, GFP_KERNEL instead
GFP_BUFFER will work. Well, I'll try testing that if I find sometime. Back
to pagebuf for now.


<Prev in Thread] Current Thread [Next in Thread>