Re: [PATCH] Use of getblk differs between locations

From: Mikulas Patocka
Date: Mon Oct 10 2005 - 20:20:37 EST

I liked what linux-2.0 did in this case --- if the kernel was out of
memory, getblk just took another buffer, wrote it if it was dirty and used
it. Except for writeable loopback device (where writing one buffer
generates more dirty buffers), it couldn't deadlock.

Wouldn't it be better if bread() were to return ERR_PTR(-EIO) or
ERR_PTR(-ENOMEM)? Big change.

No. Out of memory condition can happen even under normal circumstances under lightly loaded system. Think of a situation when dirty file-mapped pages fill up the whole memory, now a burst of packets from network comes that fills up kernel atomic reserve, you have zero pages free --- and what now? --- returning ENOMEM and dropping dirty pages without writing them is wrong, deadlocking (filesystem waits until memory manager frees some pages and memory manager waits until filesystem writes the dirty pages) is wrong too.

The filesystem must make sure that it doesn't need any memory to do block allocation and data write. Linux-2.0 got this right, it could do getblk and bread even if get_free_pages constantly failed.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at