Anton Altaparmakov wrote:
> On Mon, 2005-10-10 at 18:07 -0700, Andrew Morton wrote:
> 
>>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.
> 
> 
> 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
http://marc.theaimsgroup.com/?l=linux-scsi&m=112487427230642&w=2
(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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/