Re: [PATCH] Use of getblk differs between locations

[Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz>]

> >  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.

Mikulas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/