Re: Fw: Re: 2.6.9-rc2-mm4

Jens Axboe
2004-10-04T17:36:43Z

On Mon, Oct 04 2004, Borislav Petkov wrote:
> Ok here we go,
>
> final results:
>
> 2.6.8-rc1: OK
> 2.6.8-rc2: OK
> 2.6.8-rc3: OK
> 2.6.8-rc3-bk1: OK
> 2.6.8-rc3-bk2: OK
> 2.6.8-rc3-bk3: OK
> 2.6.8-rc3-bk4: OK
> 2.6.8-rc4: BUG!
>
> So, assuming that everything went fine during testing, the bug got introduced
> in the transition between 2.6.8-rc3-bk4 and 2.6.8-rc4.

That's some nice testing, thank you. Try backing out this hunk:

diff -urp linux-2.6.8-rc3-bk4/drivers/block/scsi_ioctl.c linux-2.6.8-rc4/drivers/block/scsi_ioctl.c
--- linux-2.6.8-rc3-bk4/drivers/block/scsi_ioctl.c 2004-08-03 23:28:51.000000000 +0200
+++ linux-2.6.8-rc4/drivers/block/scsi_ioctl.c 2004-08-10 04:24:08.000000000 +0200
@@ -90,7 +90,7 @@ static int sg_set_reserved_size(request_
if (size < 0)
return -EINVAL;
if (size > (q->max_sectors << 9))
- return -EINVAL;
+ size = q->max_sectors << 9;

q->sg_reserved_size = size;
return 0;

It's the only thing that sticks out, and it could easily explain it if
your cd ripper starts issuing requests that are too big. Maybe even add
a printk() here, so it will look like this in the kernel you test:

if (size > (q->sectors << 9)) {
printk("%u rejected\n", size);
return -EINVAL;
}

to verify.

--
Jens Axboe