+ scsi-fix-miscalculation-of-sg_io-timeout-in-cdrom_send_packet-handler.patch added to -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



The patch titled
     scsi: fix miscalculation of sg_io timeout in CDROM_SEND_PACKET handler
has been added to the -mm tree.  Its filename is
     scsi-fix-miscalculation-of-sg_io-timeout-in-cdrom_send_packet-handler.patch

Before you just go and hit "reply", please:
   a) Consider who else should be cc'ed
   b) Prefer to cc a suitable mailing list as well
   c) Ideally: find the original patch on the mailing list and do a
      reply-to-all to that, adding suitable additional cc's

*** Remember to use Documentation/SubmitChecklist when testing your code ***

See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this

The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/

------------------------------------------------------
Subject: scsi: fix miscalculation of sg_io timeout in CDROM_SEND_PACKET handler
From: Tim Wright <timw@xxxxxxxxx>

It seems cdrwtool in the udftools has been unusable on "modern" kernels
for some time.  A Google search reveals many people with the same issue
but no solution (cdrwtool fails to format the disk).  After spending some
time tracking down the issue, it comes down to the following:

The udftools still use the older CDROM_SEND_PACKET interface to send
things like FORMAT_UNIT through to the drive.  They should really be
updated, but that's another story

Since most distros are using libata now, the cd or dvd burner appears as a
SCSI device, and we wind up in block/scsi_ioctl.c.  Here, the code tries
to take the "struct cdrom_generic_command" and translate it and stuff it
into a "struct sg_io_hdr" structure so it can pass it to the modern
sg_io() routine instead.

Unfortunately, there is one error, or rather an omission in the
translation.  The timeout that is passed in in the "struct
cdrom_generic_command" is in HZ=100 units, and this is modified and
correctly converted to jiffies by use of clock_t_to_jiffies()

However, a little further down, this cgc.timeout value in jiffies is
simply copied into the sg_io_hdr timeout, which should be in milliseconds.
 Since most modern x86 kernels seems to be getting build with HZ=250, the
timeout that is passed to sg_io and eventually converted to the
timeout_per_command member of the scsi_cmnd structure is now four times
too small.

Since cdrwtool tries to set the timeout to one hour for the FORMAT_UNIT
command, and it takes about 20 minutes to format a 4x CDRW, the SCSI
error-handler kicks in after the FORMAT_UNIT completes because it took
longer than the incorrectly-calculated timeout.

Patch to correct this follows. It fixes the problem on my test system.

Signed-off-by: Tim Wright <timw@xxxxxxxxx>
Cc: Jens Axboe <jens.axboe@xxxxxxxxxx>
Cc: James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx>
Cc: <stable@xxxxxxxxxx>		[2.6.25.x, 2.6.26.x]
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---

 block/scsi_ioctl.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff -puN block/scsi_ioctl.c~scsi-fix-miscalculation-of-sg_io-timeout-in-cdrom_send_packet-handler block/scsi_ioctl.c
--- a/block/scsi_ioctl.c~scsi-fix-miscalculation-of-sg_io-timeout-in-cdrom_send_packet-handler
+++ a/block/scsi_ioctl.c
@@ -518,7 +518,7 @@ int scsi_cmd_ioctl(struct file *file, st
 			hdr.sbp = cgc.sense;
 			if (hdr.sbp)
 				hdr.mx_sb_len = sizeof(struct request_sense);
-			hdr.timeout = cgc.timeout;
+			hdr.timeout = jiffies_to_msecs(cgc.timeout);
 			hdr.cmdp = ((struct cdrom_generic_command __user*) arg)->cmd;
 			hdr.cmd_len = sizeof(cgc.cmd);
 
_

Patches currently in -mm which might be from timw@xxxxxxxxx are

scsi-fix-miscalculation-of-sg_io-timeout-in-cdrom_send_packet-handler.patch

--
To unsubscribe from this list: send the line "unsubscribe mm-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Kernel Newbies FAQ]     [Kernel Archive]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [Bugtraq]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]

  Powered by Linux