lkml.org 
[lkml]   [2005]   [Oct]   [10]   [last100]   RSS Feed
Views: [more markup]   [less markup]   [headers]   [forward]  
 
Messages in this thread
/
DateMon, 10 Oct 2005 18:07:05 -0700
FromAndrew Morton <>
SubjectRe: [PATCH] Use of getblk differs between locations
Mikulas Patocka <mikulas@artax.karlin.mff.cuni.cz> wrote:
>
>  On Mon, 10 Oct 2005, Andrew Morton wrote:
> 
>  > Anton Altaparmakov <aia21@cam.ac.uk> 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.
-
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/

\
 
 \ /
  Last update: 2005-10-11 01:10    [from the cache]
©2003-2008