[PATCH] bsg: bidi bio map failure fix

[PATCH] bsg: bidi bio map failure fix

[Pete Wyckoff]

If blk_rq_map_user requires more than one bio, and fails mapping
somewhere after the first bio, it will return with rq->bio set to
non-NULL, but it will have already unmapped the partial bio.  The
"out:" error exit section will see the non-null bio and try to unmap
it again, triggering a mapcount bug via bad_page().

Signed-off-by: Pete Wyckoff <pw@osc.edu>
---
 block/bsg.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/block/bsg.c b/block/bsg.c
index 3337125..bba7154 100644
--- a/block/bsg.c
+++ b/block/bsg.c
@@ -295,8 +295,10 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
 
 		dxferp = (void*)(unsigned long)hdr->din_xferp;
 		ret =  blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len);
-		if (ret)
+		if (ret) {
+			next_rq->bio = NULL;  /* do not unmap twice */
 			goto out;
+		}
 	}
 
 	if (hdr->dout_xfer_len) {
-- 
1.5.3.8

Re: [PATCH] bsg: bidi bio map failure fix

[James Bottomley]

On Tue, 2008-02-12 at 15:40 -0500, Pete Wyckoff wrote:
> If blk_rq_map_user requires more than one bio, and fails mapping
> somewhere after the first bio, it will return with rq->bio set to
> non-NULL, but it will have already unmapped the partial bio.  The
> "out:" error exit section will see the non-null bio and try to unmap
> it again, triggering a mapcount bug via bad_page().
> 
> Signed-off-by: Pete Wyckoff <pw@osc.edu>
> ---
>  block/bsg.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/block/bsg.c b/block/bsg.c
> index 3337125..bba7154 100644
> --- a/block/bsg.c
> +++ b/block/bsg.c
> @@ -295,8 +295,10 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
>  
>  		dxferp = (void*)(unsigned long)hdr->din_xferp;
>  		ret =  blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len);
> -		if (ret)
> +		if (ret) {
> +			next_rq->bio = NULL;  /* do not unmap twice */

Nice ... that's a nasty asymmetry of the blk_rq_map_user API.  The map
takes a request gets a ref and fills in the bio.  The unmap has to be
called on the bio leaving you to clear the now removed bio reference
manually.

James

Re: [PATCH] bsg: bidi bio map failure fix

[FUJITA Tomonori]

On Tue, 12 Feb 2008 15:40:24 -0500
Pete Wyckoff <pw@osc.edu> wrote:

> If blk_rq_map_user requires more than one bio, and fails mapping
> somewhere after the first bio, it will return with rq->bio set to
> non-NULL, but it will have already unmapped the partial bio.  The
> "out:" error exit section will see the non-null bio and try to unmap
> it again, triggering a mapcount bug via bad_page().
> 
> Signed-off-by: Pete Wyckoff <pw@osc.edu>
> ---
>  block/bsg.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/block/bsg.c b/block/bsg.c
> index 3337125..bba7154 100644
> --- a/block/bsg.c
> +++ b/block/bsg.c
> @@ -295,8 +295,10 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
>  
>  		dxferp = (void*)(unsigned long)hdr->din_xferp;
>  		ret =  blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len);
> -		if (ret)
> +		if (ret) {
> +			next_rq->bio = NULL;  /* do not unmap twice */
>  			goto out;
> +		}
>  	}
>  
>  	if (hdr->dout_xfer_len) {

Thanks!

Acked-by: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>

James, please put this to the scsi-fixes tree.

Re: [PATCH] bsg: bidi bio map failure fix

[Jens Axboe]

On Tue, Feb 12 2008, James Bottomley wrote:
> On Tue, 2008-02-12 at 15:40 -0500, Pete Wyckoff wrote:
> > If blk_rq_map_user requires more than one bio, and fails mapping
> > somewhere after the first bio, it will return with rq->bio set to
> > non-NULL, but it will have already unmapped the partial bio.  The
> > "out:" error exit section will see the non-null bio and try to unmap
> > it again, triggering a mapcount bug via bad_page().
> > 
> > Signed-off-by: Pete Wyckoff <pw@osc.edu>
> > ---
> >  block/bsg.c |    4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> > 
> > diff --git a/block/bsg.c b/block/bsg.c
> > index 3337125..bba7154 100644
> > --- a/block/bsg.c
> > +++ b/block/bsg.c
> > @@ -295,8 +295,10 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
> >  
> >  		dxferp = (void*)(unsigned long)hdr->din_xferp;
> >  		ret =  blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len);
> > -		if (ret)
> > +		if (ret) {
> > +			next_rq->bio = NULL;  /* do not unmap twice */
> 
> Nice ... that's a nasty asymmetry of the blk_rq_map_user API.  The map
> takes a request gets a ref and fills in the bio.  The unmap has to be
> called on the bio leaving you to clear the now removed bio reference
> manually.

It is nasty, how about fixing that instead?

diff --git a/block/blk-map.c b/block/blk-map.c
index 955d75c..bc5ce60 100644
--- a/block/blk-map.c
+++ b/block/blk-map.c
@@ -143,6 +143,7 @@ int blk_rq_map_user(struct request_queue *q, struct request *rq,
 	return 0;
 unmap_rq:
 	blk_rq_unmap_user(bio);
+	rq->bio = NULL;
 	return ret;
 }
 EXPORT_SYMBOL(blk_rq_map_user);

-- 
Jens Axboe

Re: [PATCH] bsg: bidi bio map failure fix

[FUJITA Tomonori]

On Mon, 18 Feb 2008 13:55:08 +0100
Jens Axboe <jens.axboe@oracle.com> wrote:

> On Tue, Feb 12 2008, James Bottomley wrote:
> > On Tue, 2008-02-12 at 15:40 -0500, Pete Wyckoff wrote:
> > > If blk_rq_map_user requires more than one bio, and fails mapping
> > > somewhere after the first bio, it will return with rq->bio set to
> > > non-NULL, but it will have already unmapped the partial bio.  The
> > > "out:" error exit section will see the non-null bio and try to unmap
> > > it again, triggering a mapcount bug via bad_page().
> > > 
> > > Signed-off-by: Pete Wyckoff <pw@osc.edu>
> > > ---
> > >  block/bsg.c |    4 +++-
> > >  1 files changed, 3 insertions(+), 1 deletions(-)
> > > 
> > > diff --git a/block/bsg.c b/block/bsg.c
> > > index 3337125..bba7154 100644
> > > --- a/block/bsg.c
> > > +++ b/block/bsg.c
> > > @@ -295,8 +295,10 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
> > >  
> > >  		dxferp = (void*)(unsigned long)hdr->din_xferp;
> > >  		ret =  blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len);
> > > -		if (ret)
> > > +		if (ret) {
> > > +			next_rq->bio = NULL;  /* do not unmap twice */
> > 
> > Nice ... that's a nasty asymmetry of the blk_rq_map_user API.  The map
> > takes a request gets a ref and fills in the bio.  The unmap has to be
> > called on the bio leaving you to clear the now removed bio reference
> > manually.
> 
> It is nasty, how about fixing that instead?

Yeah, looks better for me though the blk_rq_map_user API is still a
bit hacky, as James said.

James, Pete's patch is still in scsi-fixes, so how about dropping it
and sending this patch via the block?


> diff --git a/block/blk-map.c b/block/blk-map.c
> index 955d75c..bc5ce60 100644
> --- a/block/blk-map.c
> +++ b/block/blk-map.c
> @@ -143,6 +143,7 @@ int blk_rq_map_user(struct request_queue *q, struct request *rq,
>  	return 0;
>  unmap_rq:
>  	blk_rq_unmap_user(bio);
> +	rq->bio = NULL;
>  	return ret;
>  }
>  EXPORT_SYMBOL(blk_rq_map_user);
> 
> -- 
> Jens Axboe
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] bsg: bidi bio map failure fix

[Jens Axboe]

On Mon, Feb 18 2008, FUJITA Tomonori wrote:
> On Mon, 18 Feb 2008 13:55:08 +0100
> Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > On Tue, Feb 12 2008, James Bottomley wrote:
> > > On Tue, 2008-02-12 at 15:40 -0500, Pete Wyckoff wrote:
> > > > If blk_rq_map_user requires more than one bio, and fails mapping
> > > > somewhere after the first bio, it will return with rq->bio set to
> > > > non-NULL, but it will have already unmapped the partial bio.  The
> > > > "out:" error exit section will see the non-null bio and try to unmap
> > > > it again, triggering a mapcount bug via bad_page().
> > > > 
> > > > Signed-off-by: Pete Wyckoff <pw@osc.edu>
> > > > ---
> > > >  block/bsg.c |    4 +++-
> > > >  1 files changed, 3 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/block/bsg.c b/block/bsg.c
> > > > index 3337125..bba7154 100644
> > > > --- a/block/bsg.c
> > > > +++ b/block/bsg.c
> > > > @@ -295,8 +295,10 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
> > > >  
> > > >  		dxferp = (void*)(unsigned long)hdr->din_xferp;
> > > >  		ret =  blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len);
> > > > -		if (ret)
> > > > +		if (ret) {
> > > > +			next_rq->bio = NULL;  /* do not unmap twice */
> > > 
> > > Nice ... that's a nasty asymmetry of the blk_rq_map_user API.  The map
> > > takes a request gets a ref and fills in the bio.  The unmap has to be
> > > called on the bio leaving you to clear the now removed bio reference
> > > manually.
> > 
> > It is nasty, how about fixing that instead?
> 
> Yeah, looks better for me though the blk_rq_map_user API is still a
> bit hacky, as James said.

Seems symmetric to me now, either we fail and everything is cleaned up,
or return success. What remains?

-- 
Jens Axboe

Re: [PATCH] bsg: bidi bio map failure fix

[James Bottomley]

On Mon, 2008-02-18 at 23:37 +0900, FUJITA Tomonori wrote:
> On Mon, 18 Feb 2008 13:55:08 +0100
> Jens Axboe <jens.axboe@oracle.com> wrote:
> 
> > On Tue, Feb 12 2008, James Bottomley wrote:
> > > On Tue, 2008-02-12 at 15:40 -0500, Pete Wyckoff wrote:
> > > > If blk_rq_map_user requires more than one bio, and fails mapping
> > > > somewhere after the first bio, it will return with rq->bio set to
> > > > non-NULL, but it will have already unmapped the partial bio.  The
> > > > "out:" error exit section will see the non-null bio and try to unmap
> > > > it again, triggering a mapcount bug via bad_page().
> > > > 
> > > > Signed-off-by: Pete Wyckoff <pw@osc.edu>
> > > > ---
> > > >  block/bsg.c |    4 +++-
> > > >  1 files changed, 3 insertions(+), 1 deletions(-)
> > > > 
> > > > diff --git a/block/bsg.c b/block/bsg.c
> > > > index 3337125..bba7154 100644
> > > > --- a/block/bsg.c
> > > > +++ b/block/bsg.c
> > > > @@ -295,8 +295,10 @@ bsg_map_hdr(struct bsg_device *bd, struct sg_io_v4 *hdr)
> > > >  
> > > >  		dxferp = (void*)(unsigned long)hdr->din_xferp;
> > > >  		ret =  blk_rq_map_user(q, next_rq, dxferp, hdr->din_xfer_len);
> > > > -		if (ret)
> > > > +		if (ret) {
> > > > +			next_rq->bio = NULL;  /* do not unmap twice */
> > > 
> > > Nice ... that's a nasty asymmetry of the blk_rq_map_user API.  The map
> > > takes a request gets a ref and fills in the bio.  The unmap has to be
> > > called on the bio leaving you to clear the now removed bio reference
> > > manually.
> > 
> > It is nasty, how about fixing that instead?
> 
> Yeah, looks better for me though the blk_rq_map_user API is still a
> bit hacky, as James said.
> 
> James, Pete's patch is still in scsi-fixes, so how about dropping it
> and sending this patch via the block?

Yes, sure.

James

Re: [PATCH] bsg: bidi bio map failure fix

[James Bottomley]

On Mon, 2008-02-18 at 15:46 +0100, Jens Axboe wrote:
> Seems symmetric to me now, either we fail and everything is cleaned up,
> or return success. What remains?

My main symmetry complaint was the API:  The map takes a request, the
unmap takes a bio.

James

Re: [PATCH] bsg: bidi bio map failure fix

[FUJITA Tomonori]

On Mon, 18 Feb 2008 09:09:07 -0600
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:

> On Mon, 2008-02-18 at 15:46 +0100, Jens Axboe wrote:
> > Seems symmetric to me now, either we fail and everything is cleaned up,
> > or return success. What remains?
> 
> My main symmetry complaint was the API:  The map takes a request, the
> unmap takes a bio.

Yeah, it would be nice if we avoid such code:

blk_rq_map_user(q, rq, ...)
bio = rq->bio
blk_execute_rq(q, ...
blk_rq_unmap_user(bio);

I think that none of the users of blk_rq_map_user is interested in
bio, the details of how kernel manage I/Os. At least, we can remove
bio stuff in bsg if blk_rq_map_user and blk_rq_unmap_user take
requests.

Re: [PATCH] bsg: bidi bio map failure fix

[Jens Axboe]

On Mon, Feb 18 2008, James Bottomley wrote:
> On Mon, 2008-02-18 at 15:46 +0100, Jens Axboe wrote:
> > Seems symmetric to me now, either we fail and everything is cleaned up,
> > or return success. What remains?
> 
> My main symmetry complaint was the API:  The map takes a request, the
> unmap takes a bio.

Oh that, well that was done to make it easier for existing users. Feel
free to send a patch changing that, however it was done that way on
purpose at the time being.

-- 
Jens Axboe