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.
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/