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

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

Linus Torvalds wrote:
> 
> On Sun, 28 Jul 2002, David S. Miller wrote:
> >
> >    Also skb_release_data(), ___pskb_trim() and __pskb_pull_tail().  Can these
> >    ever perform the final release against a page which is on the LRU?
> >    In interrupt context?
> >
> > These page releases run from either user or softint context.
> >
> > 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.

So we cannot take pagemap_lru_lock from softirq context.

hmm.  ia32's do_IRQ() doesn't run do_sotfirq() any more, but the
other architectures do.  What's up with that?

> > Any page that can be found in the page cache can end up here.  So
> > whatever that mean for "release against a page which is on the LRU"
> > applies here.
> 
> Being in the page cache can be ok. What is _not_ ok is if this function
> can ever be the last user to release such a page (ie the original page
> count of the page had better be held on by something else - which usually
> is the page-cacheness itself, since shrinking the page cache will only
> happen for pages that are unused).
> 

shrink_cache() explicitly removes the page from the LRU (well, it
won't even get that far if someone else has a ref).

truncate_complete_page() _used_ to explicitly remove the page from
the lru, but we took that out.  And it was never reliable anyway,
because some pages were left there (invalidatepage failed).

Anyway.  I have patches against 2.5.24, which work, which
turn pagemap_lru_lock into an innermost, irq-safe lock.  If
we get that in place then page_cache_release() from IRQ context
is fine.

-