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-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060725092400.GK4044@suse.de>
Date:	Tue, 25 Jul 2006 11:24:01 +0200
From:	Jens Axboe <axboe@...e.de>
To:	Mike Christie <michaelc@...wisc.edu>
Cc:	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/2] blk request timeout handler: mv scsi timer code to  block layer

On Tue, Jul 25 2006, Mike Christie wrote:
> 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 :)

Excellent, one item off my TODO list :-). I had pending code, but not
completed yet.

I had intended to make the timer addition/deletion implicit from the
activate/deactive rq paths, both to have it happen automatically and
from a cleanliness POV. That makes the timer only active when the
request is in the driver, and should also make the deletion implicit for
when the request gets requeued.

-- 
Jens Axboe

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ