Re: [PATCH] Use of getblk differs between locations
From: Andrew Morton
Date: Mon Oct 10 2005 - 20:08:15 EST
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
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/