read_pages bug?

Speaking of read_pages(), doesn't the AOP_TRUNCATED_PAGE case
cause a dangling page which can't get cleaned up because it
is not on the lru (and the file has presumably already been
truncated)?

(also, let's not worry about pretending we propogate errors)

--
SUSE Labs, Novell Inc.
Index: linux-2.6/mm/readahead.c
===================================================================
--- linux-2.6.orig/mm/readahead.c 2006-04-30 21:59:09.000000000 +1000
+++ linux-2.6/mm/readahead.c 2006-04-30 22:02:26.000000000 +1000
@@ -164,16 +164,15 @@ int read_cache_pages(struct address_spac

EXPORT_SYMBOL(read_cache_pages);

-static int read_pages(struct address_space *mapping, struct file *filp,
+static void read_pages(struct address_space *mapping, struct file *filp,
struct list_head *pages, unsigned nr_pages)
{
unsigned page_idx;
struct pagevec lru_pvec;
- int ret;

if (mapping->a_ops->readpages) {
- ret = mapping->a_ops->readpages(filp, mapping, pages, nr_pages);
- goto out;
+ mapping->a_ops->readpages(filp, mapping, pages, nr_pages);
+ return;
}

pagevec_init(&lru_pvec, 0);
@@ -182,19 +181,13 @@ static int read_pages(struct address_spa
list_del(&page->lru);
if (!add_to_page_cache(page, mapping,
page->index, GFP_KERNEL)) {
- ret = mapping->a_ops->readpage(filp, page);
- if (ret != AOP_TRUNCATED_PAGE) {
- if (!pagevec_add(&lru_pvec, page))
- __pagevec_lru_add(&lru_pvec);
- continue;
- } /* else fall through to release */
- }
- page_cache_release(page);
+ mapping->a_ops->readpage(filp, page);
+ if (!pagevec_add(&lru_pvec, page))
+ __pagevec_lru_add(&lru_pvec);
+ } else
+ page_cache_release(page);
}
pagevec_lru_add(&lru_pvec);
- ret = 0;
-out:
- return ret;
}

/*