The cdrom driver does an order-4 allocation and the open will fail if that
allocation does not succeed.  This happened to me on an unstressed 900MB
machine.

So add the __GFP_REPEAT flag in there - this will cause the page allocator to
keep on freeing pages until the allocation succeeds.

It can in theory livelock but in practice I expect it is OK: the user should
just stop running dbench or whatever it is which is gobbling all the memory
and the mount/open will then succeed.



 drivers/ide/ide-cd.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletion(-)

diff -puN drivers/ide/ide-cd.c~cdrom-allocation-try-harder drivers/ide/ide-cd.c
--- 25/drivers/ide/ide-cd.c~cdrom-allocation-try-harder	2003-10-17 23:03:25.000000000 -0700
+++ 25-akpm/drivers/ide/ide-cd.c	2003-10-17 23:03:25.000000000 -0700
@@ -3339,7 +3339,8 @@ static int idecd_open(struct block_devic
 	drive->usage++;
 
 	if (!info->buffer)
-		info->buffer = (char *) kmalloc(SECTOR_BUFFER_SIZE, GFP_KERNEL);
+		info->buffer = kmalloc(SECTOR_BUFFER_SIZE,
+					GFP_KERNEL|__GFP_REPEAT);
         if (!info->buffer || (rc = cdrom_open(&info->devinfo, bdev, file)))
 		drive->usage--;
 	return rc;

_