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

From: Reinoud Zandijk <reinoud@netbsd.org>
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 19:21:28 +0100

 --ibTvN161/egqYuK8
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
   > 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?
 
 What about the struct buf definition? If we can't rely on fields to have 
 valid info in their fields.... rely on (undocumented) conventions?
 
   > 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?
 
 That bp->b_bufsize indicates the length of the datablock pointed to by 
 bp->b_data ?
 
 > they are released by uvm_aio_biodone1().
 
 Undocumented feature of UVM aparently... maybe a comment would be good :)
 
   > 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.
 
 Consistency. If one wants to be consistent, b_resid ought to allways 
 indicate the number of bytes to be transfered independent of the place one 
 finds the buf used and not for conventions sake suddenly been taken over by 
 b_bcount.
 
 Reinoud
 
 
 --ibTvN161/egqYuK8
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.2.6 (NetBSD)
 
 iQEVAwUBQ43toIKcNwBDyKpoAQILtwgApLLPUDtSO85C8LBI6ONPHP/365yZXBNK
 oG5/H9UhiHVC7WmTOENG+hAj02ra5D48e2yvsBFnNt6eIzCbC64xFfUwt5Jpe/SX
 ppVG80srYLDeOQOh11SqFpUOc4qPnTM/pRRRKOrFoc5VPvQRBw3oWJl1IzUjUoRB
 qGeFZNy8qnrnqlUxNdNgQSqArRtXCErYOJaQesKQYluNpOOw8LnzWqaRIC38o1js
 6pAlwXqysZ3Xi2Jz5rWmTFR+Z+gn23tuJESavRmru5A0EQztGP7GmnCnTZlfpiQi
 QHJWp4ZXoTg1Ee9i2u4YL5opRhMnEYMECcwif5YAXkq/1BVwbCiUvA==
 =yawL
 -----END PGP SIGNATURE-----
 
 --ibTvN161/egqYuK8--