linux-kernel - Re: sg timeout problem

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4A042243.1010608@interlog.com>
Date:	Fri, 08 May 2009 14:14:59 +0200
From:	Douglas Gilbert <dgilbert@...erlog.com>
To:	Norman Diamond <n0diamond@...oo.co.jp>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	linux-scsi@...r.kernel.org
Subject: Re: sg timeout problem

Norman Diamond wrote:
>>> But if sg is running on top of an actual SCSI driver, someone aborts the
>>> ioctl after 3 seconds.  The ioctl returns success even though the
>>> operation didn't complete.  I tried this with two Adaptec drivers and 
>>> one
>>> NinjaSCSI driver with 100% repro.
>>>
>>> What am I missing?  I need the call to run to completion.
>>
>> If you set it to the max of a signed int does it behave, or to a large
>> value thats well under the limit. That will help tell if there is a
>> problem with sign handling in the scsi code somewhere or it is getting
>> multiplied up for some reason.
> 
> I have the impression now that the drives are lying and it's not the fault
> of the drivers or cards.  The same problem occured with a fourth card and a
> non-Linux system.
> 
> Anyway I also tried changing the timeout to 86400000 milliseconds (one day)
> and it made no difference.  So again I stop blaming the drivers.

Norman,
I'm not sure what version or distro of Linux you have
but I just did this quick test on Ubuntu 9.04 in which
a kernel tick seems to be around 4 milliseconds:

$  uname -a
Linux zink 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 
GNU/Linux
$
$ modprobe scsi_debug delay=1000
$ lsscsi -g
[7:0:0:0]    disk    Linux    scsi_debug       0004  /dev/sdb   /dev/sg2

$ time sg_readcap /dev/sg2
Read Capacity results:
    Last logical block address=16383 (0x3fff), Number of blocks=16384
    Logical block length=512 bytes
Hence:
    Device size: 8388608 bytes, 8.0 MiB, 0.01 GB

real	0m3.999s
user	0m0.000s
sys	0m0.000s
$


See 'modinfo scsi_debug' for more about the arguments to the
scsi_debug driver. If the delay is too long then the kernel
may timeout registering the pseudo device. I picked 4 seconds
because you noted a failure above 3 seconds. The timeout on
sg_inq is set at 60 seconds.

Doug Gilbert




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/