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

[dholland%netbsd.org@localhost]

>Number:         40681
>Category:       kern
>Synopsis:       possible data loss path in the buffer cache code
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Feb 18 20:30:00 +0000 2009
>Originator:     David A. Holland
>Release:        NetBSD 5.99.7 (20090218) (vfs_bio.c 1.215)
>Organization:
>Environment:
  -
>Description:

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.

getblk calls allocbuf; allocbuf returns ENOMEM; getblk then
unconditionally removes the buffer from b_hash and then calls
brelse(bp, BC_INVAL).

>How-To-Repeat:

code reading.

>Fix:

If I understand things correctly, BC_INVAL should already be set on
the buffer if was new, so we should remove from b_hash only if
BC_INVAL is already set, and call brelse(bp, 0) instead of brelase(bp,
BC_INVAL).

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