Re: 2.4.17rc2aa1

[Andrea Arcangeli <andrea@suse.de>]

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