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