RFC: error handling workqueue design

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

 



I'd like to get some comments on the approach on how to move error
handling out from the transport processing thread.

Just like I/O submission all EH callers actually are from process
context and can block.  But given how long EH can take I'd rather not
push it into that context as it might end up blocking other LUs
from making progress.  It seems like having a dedicated EH context
for each LU, just like we do in the Linux SCSI midlayer would be
appronpinquate here.

What makes our life even easier is that there is only one TMF
implemented in the target core right now, the LUN reset.  Given
the nature of a LUN reset there is no real reason to ever process
multiple of those at the same time.  Can we simply fail a second
LUN RESET while the first one is in progress, or do we have to
complete them all once the reset is done?
--
To unsubscribe from this list: send the line "unsubscribe target-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux SCSI]     [Kernel Newbies]     [Linux SCSI Target Infrastructure]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Device Mapper]

  Powered by Linux