Re: [PATCH] Use of getblk differs between locations

From: Mike Christie
Date: Wed Oct 12 2005 - 19:59:53 EST

Anton Altaparmakov wrote:
On Mon, 2005-10-10 at 18:07 -0700, Andrew Morton wrote:

Mikulas Patocka <mikulas@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:

On Mon, 10 Oct 2005, Andrew Morton wrote:

> Anton Altaparmakov <aia21@xxxxxxxxx> wrote:
>> > Maybe the best solution is neither one nor another. Testing and failing
>> > gracefully seems better.
>> >
>> > What do you think?
>> I certainly agree with you there. I neither want a deadlock nor
>> corruption. (-:
> Yup. In the present implementation __getblk_slow() "cannot fail". It's
> conceivable that at some future stage we'll change __getblk_slow() so that
> it returns NULL on an out-of-memory condition.

The question is if it is desired --- it will make bread return NULL on out-of-memory condition, callers will treat it like an IO error, skipping access to the affected block, causing damage on perfectly healthy filesystem.

Yes, that is a bit dumb. A filesystem might indeed want to take different
action for ENOMEM versus EIO.

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.

It would indeed. Much better. And whilst at it, it would be even
better if we had a lot more error codes like "ERR_PTR(-EDEVUNPLUGGED)"
for example... But that would be an even better change. Anyone feeling
like touching every block driver in the kernel? (-;

I have actually done this
(this is just the bio users, the end_that_request_first/chunk users are in another patch).

I am just trying to figure out how to support some wierd scsi HW before reposting. If you have suggestions about how to implement the bitmap suggestion in that thread I am listening too (I implemented it like scsi's scsi_cmnd result field).
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