[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: kern/40681: possible data loss path in the buffer cache code
The following reply was made to PR kern/40681; it has been noted by GNATS.
From: Andrew Doran <ad%netbsd.org@localhost>
Subject: Re: kern/40681: possible data loss path in the buffer cache code
Date: Wed, 18 Feb 2009 21:59:12 +0000
> It appears that if you call getblk(), it finds an existing buffer, and
> it attempts to resize it, and the allocation for the resize fails, the
> buffer is unceremoniously invalidated, even if it previously contained
> valid and dirty data.
There was an assertion in the code that implied requests for disk address
`blkno' always had the same size `size'. See line 1184. It was changed with
revision 1.78 so that it did not fire for block devices.
You could legitmately take the position that requests should always have the
same size because the code can't handle overlap. I guess that could break
heuristics like the disk partition code mentioned in the log message for
> If I don't understand things correctly then I have no idea how callers
> of getblk are supposed to tell if they got an already-valid block back
> or not and would appreciate enlightenment. :-/
I don't see how they can, unless (a) they always request the same size or
(b) are stacked with a pile of fragile assumptions. Even without
invalidating the buffer on failure, the expanded segment contains garbage
Main Index |
Thread Index |