linux-kernel - [PATCH 0/2] blk request timeout handler

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <44C5E98B.4040903@cs.wisc.edu>
Date:	Tue, 25 Jul 2006 05:51:07 -0400
From:	Mike Christie <michaelc@...wisc.edu>
To:	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
	axboe@...e.de
Subject: [PATCH 0/2] blk request timeout handler

Sorry if this is a duplicate, I had some trouble with my mailer in the
middle if sending the patches.

The following patches move the scsi command timeout code from the scsi
layer to the block layer. I originally did them so request based
multipath could reuse the code, but the code can be used by anyone so I
thought I should send it seperately.

I have tested the normal and error paths with iscsi and am in the middle
of testing the libata error paths. The latter needs more care since it
is the only strategy handler user. I have also converted all the
timeout_per_command users but some of the LLDs still need a "#include
blkdev.h".

So the patches are not ready for mergingm but I wanted to get feedback
on the scsi timer code and if it was accpetable or was it not so nice?
And I wanted to see if these patches were ok alone or if all the scsi eh
needed to be moved at the same time. These patches do not move the
quiesce, abort or reset code.
-
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/