On Mon, 29 Jan 2007, Linus Torvalds wrote:
> 
> Two more reboots and I should know exactly which one broke "nero".

This one.

However, the scary thing is that I think the patch really is correct, and 
I wonder if nero has some strange work-around for an older bug.. Although 
I don't see how you could even have that, since afaik, the behaviour 
before the fix was literally just a leak that a user process shouldn't be 
able to see.

Very strange. Will add some debugging printk's.

                Linus

----
commit 77d172ce2719b5ad2dc0637452c8871d9cba344c
Author: FUJITA Tomonori <[EMAIL PROTECTED]>
Date:   Mon Dec 11 10:01:34 2006 +0100

    [PATCH] fix SG_IO bio leak
    
    This patch fixes bio leaks in SG_IO. rq->bio can be changed after io
    completion, so we need to reset rq->bio before calling blk_rq_unmap_user()
    
    http://marc.theaimsgroup.com/?l=linux-kernel&m=116570666807983&w=2
    
    Signed-off-by: FUJITA Tomonori <[EMAIL PROTECTED]>
    Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
---
 block/scsi_ioctl.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index b3e2107..045cabd 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -228,6 +228,7 @@ static int sg_io(struct file *file, request_queue_t *q,
        struct request *rq;
        char sense[SCSI_SENSE_BUFFERSIZE];
        unsigned char cmd[BLK_MAX_CDB];
+       struct bio *bio;
 
        if (hdr->interface_id != 'S')
                return -EINVAL;
@@ -308,6 +309,7 @@ static int sg_io(struct file *file, request_queue_t *q,
        if (ret)
                goto out;
 
+       bio = rq->bio;
        rq->retries = 0;
 
        start_time = jiffies;
@@ -338,6 +340,7 @@ static int sg_io(struct file *file, request_queue_t *q,
                        hdr->sb_len_wr = len;
        }
 
+       rq->bio = bio;
        if (blk_rq_unmap_user(rq))
                ret = -EFAULT;
 
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to