Subject: Re: kern/32193: vop_strategy gets broken struct buf's passed by
To: None <kern-bug-people@netbsd.org, gnats-admin@netbsd.org,>
From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
List: netbsd-bugs
Date: 11/29/2005 23:53:02
The following reply was made to PR kern/32193; it has been noted by GNATS.

From: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
To: gnats-bugs@netbsd.org
Cc: kern-bug-people@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: kern/32193: vop_strategy gets broken struct buf's passed by
 genfs/bread, possible memory leakage
Date: Wed, 30 Nov 2005 08:51:51 +0900

 > UDF's VOP_STRATEGY() gets calls from VOP_READ() using bread() on the vnode 
 > and from genfs's {get,put}_pages. Both buffers are are not according to the 
 > spec.
 
 what spec are you talking about?
 
 > VOP_STRATEGY buffers
 > --------------------
 > vop_strategy buffers are passed from genfs in 
 > sys/miscfs/genfs/genfs_vnops.c:836's VOP_TRATEGY call and created at either 
 > line 673 or at line 810 of the same file. In the buffer `mbp' created at 
 > line 673, all seems OK but at the buffer `bp' created at line 810, 
 > bp->b_bufsize is not initialised and thus ZERO!!!! quite a violation.
 
 violate what?
 
 > pages, the `bp' are still pointing at... Aparently this code is written so 
 > that `mbp' can be waited for by `biowait' when all `bp' fragments are 
 > ready. But the struct buf's claimed from genfs's own pool are not returned 
 > to the pool. Each time this fragmented scheme is used, memory gets lost.
 
 they are released by uvm_aio_biodone1().
 
 > bread buffers
 > -------------
 > vop_strategy buffers are passed from bread() in sys/kern/vfs_bio.c's 
 > bio_doread() at line 597's VOP_STRATEGY().
 > 
 > These buffers are claimed/looked up just before in line 577's getblk(). 
 > When passed to UDF's vop_strategy() bp->b_resid is undefined though mostly 
 > ZERO. Also not according to the struct buf's specs wich would suggest the 
 > number of bytes to be read/written in/from the buffer to be bp->b_resid.
 
 so?  do you have any problem with it?
 b_resid will be set by device drivers if needed.
 
 > Other filingsystems
 > ----------
 > Filingsystems seem to cope with it by passing the buffers directly to the 
 > device layer that aparently ignores most of the buf contents and only 
 > reacts to bp->b_count.
 > 
 > Filingsystems that do care about the buffer contents are also only looking 
 > at bp->b_count.
 
 so?  do you think it's a problem?  why?
 
 this PR seems bogus to me.  is it ok to close?
 
 YAMAMOTO Takashi