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.
-
-
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/