linux-kernel - [PATCH 0/2] blk request timeout handler: mv scsi timer code to block layer

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>] [thread-next>] [day] [month] [year] [list]

Message-Id: <1153820377.4166.22.camel@max>
Date:	Tue, 25 Jul 2006 05:39:37 -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: mv scsi timer code to
	block layer

For the request based multipath I thought I would need to run some code
when a command times out. I did not want to duplicate the scsi code, so
I did the following patches which move the scsi timer code to the block
layer then convert scsi.

I have tested the scsi_error.c and normal paths with iscsi. And, I have
tested the normal IO paths with libata. Since libata uses the strategy
handler it needs to be tested a lot more. Some of the drivers that were
touching the timeout_per_command field need to be compile tested still
too. I converted them, but I think some still need a "#include
blkdev.h".

The patches only move the scsi timer code to the block layer and hook it
in so others can use it. I have not started on the abort, reset and
quiesce code since it is not really needed for multipath. I wanted to
see if the timer code move was ok on its own without the rest of the
scsi eh move because I do not want to manage the patches out of tree
with the other request multipath patches. I also wanted to check if the
scsi timer code was ok in general. Maybe scsi got it wrong and needed to
be rewritten :)

Both patches were made over 2.6.18-rc2.

-
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/