Re: kern/40681: possible data loss path in the buffer cache code

[Andrew Doran <ad%netbsd.org@localhost>]

The following reply was made to PR kern/40681; it has been noted by GNATS.

From: Andrew Doran <ad%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
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
 1.78.
 
 > 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
 until initialized.
 
 Andrew