Re: [patch 2/13] remove pages from the LRU in __free_pages_ok()

[Andrew Morton <akpm@zip.com.au>]

"David S. Miller" wrote:
> 
>    From: Linus Torvalds <torvalds@transmeta.com>
>    Date: Sun, 28 Jul 2002 20:51:13 -0700 (PDT)
> 
>    On Sun, 28 Jul 2002, David S. Miller wrote:
>    > They must never run from HW irqs, in fact there is a BUG()
>    > check there against this.
> 
>    From a page cache standpoint softirq's are 100% equivalent to
>    hardware irq's, so that doesn't much help here.
> 
> Wait are we trying to make the final freeing of (potentially)
> LRU/page-cache pages from any non-base context illegal?

It already is.  The combination of circumstances is pretty
remote, and indeed may never happen.  But the final put_page()
against an LRU page will go BUG() because the page is on the LRU.
And a page_cache_reelase() in IRQ context could deadlock over
pagemap_lru_lock() (it'll go BUG in -aa kernels).

> If that really becomes an issue we can do something which moves
> this back to user context when the result of doing it in irq
> context would be problematic.

I don't think it can happen in 2.4.  In the truncate case,
the page is taken off the LRU by hand.  If do_flushpage()
failed then the buffers still have a ref on the page, which
is undone in shrink_cache(), inside pagemap_lru_lock.

So, probably safe, but way too subtle.

-