My desktop running rc2aa1 crashed in lo_send a few minutes ago while
testing oom conditions with simultaneous heavy I/O to the loop device,
so I had a chance to fix another bug. Maybe this is what you
experienced, but I also got an oops (maybe you didn't seen the oops
because the machine hanged up?). Just guessing.
Anyways here the fix (untested as usual :)
--- 2.4.17rc2aa1/fs/buffer.c.~1~ Wed Dec 19 03:43:24 2001
+++ 2.4.17rc2aa1/fs/buffer.c Thu Dec 20 19:02:02 2001
@@ -2337,7 +2337,7 @@
struct buffer_head *bh;
page = find_or_create_page(bdev->bd_inode->i_mapping, index, GFP_NOFS);
- if (IS_ERR(page))
+ if (!page)
return NULL;
if (!PageLocked(page))
--- 2.4.17rc2aa1/mm/filemap.c.~1~ Wed Dec 19 03:43:23 2001
+++ 2.4.17rc2aa1/mm/filemap.c Thu Dec 20 19:01:53 2001
@@ -942,7 +942,7 @@
spin_unlock(&pagecache_lock);
if (!page) {
struct page *newpage = alloc_page(gfp_mask);
- page = ERR_PTR(-ENOMEM);
+ page = NULL;
if (newpage) {
spin_lock(&pagecache_lock);
page = __find_lock_page_helper(mapping, index, *hash);
explanation: grab_cache_page must definitely return NULL in case of oom,
that's the API used by the callers. find_or_create_page can use the same
API as well (there's no point for the ERR_PTR(-ENOMEM) complication).
Andrea
-
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/