On Wed, Dec 19, 2001 at 09:52:08PM +0100, Andrea Arcangeli wrote:
> On Wed, Dec 19, 2001 at 09:32:12PM +0100, Gergely Nagy wrote:
> > > This should fix the last loop deadlocks under VM pressure, if not please
> > > let me know.
> > >
> >
> > Unfortunately, it doesn't. I'll do a SysRq+T and kysmoops combo as
> > soon as I boot into that kernel again (probably later tonight).
>
> perfect, thanks.
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/
This archive was generated by hypermail 2b29 : Sun Dec 23 2001 - 21:00:22 EST