On Thu, Jul 19, 2018 at 03:19:04PM +0200, h...@lst.de wrote: > On Wed, Jul 18, 2018 at 03:17:11PM -0600, Keith Busch wrote: > > And there may be other drivers that don't want their completions > > ignored, so breaking them again is also a step in the wrong direction. > > > > There are not that many blk-mq drivers, so we can go through them all. > > I think the point is that SCSI is the biggest user by both the number > of low-level drivers sitting under the midlayer, and also by usage. > > We need to be very careful not to break it. Note that this doesn't > mean that I don't want to eventually move away from just ignoring > completions in timeout state for SCSI. I'd just rather rever 4.18 > to a clean known state instead of doctoring around late in the rc > phase.
I definitely do not want to break scsi. I just don't want to break every one else either, and I think scsi can get the behavior it wants without forcing others to subscribe to it. > > Most don't even implement .timeout, so they never know that condition > > ever happened. Others always return BLK_EH_RESET_TIMER without doing > > anythign else, so the 'new' behavior would have to be better for those, > > too. > > And we should never even hit the timeout handler for those as it > is rather pointless (although it looks we currently do..). I don't see why we'd expect to never hit timeout for at least some of these. It's not a stretch to see, for example, that virtio-blk or loop could have their requests lost with no way to recover if we revert. I've wasted too much time debugging hardware for such lost commands when it was in fact functioning perfectly fine. So reintroducing that behavior is a bit distressing.
