On Wed, 2019-01-16 at 11:32 -0500, Douglas Gilbert wrote: > On 2019-01-16 5:58 a.m., Martin Wilck wrote: > > On Wed, 2019-01-16 at 11:32 +0100, Hannes Reinecke wrote: > > > On 1/16/19 11:26 AM, Martin Wilck wrote: > > > > On Wed, 2019-01-16 at 08:35 +0100, Hannes Reinecke wrote: > > > > > If the device is _not_ removable we should not start the > > > > > event > > > > > poller as the media will not go away. Having the event poller > > > > > running > > > > > will block the open() call as it will try to flush > > > > > outstanding > > > > > events, > > > > > which it can't if the device is in state 'BLOCKED'. So the > > > > > open() > > > > > call > > > > > will be stalled until the device state changed, which might > > > > > be > > > > > quite > > > > > some time depending on the transport. > > > > > > > > > > Signed-off-by: Hannes Reinecke <hare@xxxxxxxx> > > > > > --- > > > > > drivers/scsi/sd.c | 3 +++ > > > > > 1 file changed, 3 insertions(+) > > > > > > > > Thanks - you lost patience with me, did you? :-) > > > > > > > > I didn't submit this yet because Tejun (adding him to CC) had > > > > explicitly removed this check in commit 2bae0093cab4, and I was > > > > still > > > > trying to understand why. > > > > > > > > Perhaps a follow-up discussion will clarify that. > > > > > > > To my understanding Tejun removed it as the check got moved into > > > set_media_not_present() function. > > > > Maybe, but as a matter of fact, after 2bae0093cab4, TUR could be > > executed for non-removable disks in sd_check_events(), which was > > never > > done in sd_media_changed() beforehand. > > > > > However, I'd be very much interested to hear on how a non- > > > removable > > > device can change ... > > > > Me too. The specs at least don't seem to mandate that only > > removable > > devices can return MEDIUM NOT PRESENT. But even then, it makes only > > little sense to actively test such devices for a media change by > > sending TURs. > > So to be more precise, do you mean the LU disappearing while its > port(s) and containing target device remain online? > > Otherwise a hot unplug meets the bill. Also some curious things can > happen at the transport level. For example I believe T10 have just > accepted a MODE SELECT command that will change a SAS wide port > to narrow port(s) (and vice versa). The device is taken offline for > a programmable period meant to be long enough for the scanning logic > to notice and then brought back in its new configuration. Are these really cases where the sense code would be UNIT ATTENTION / MEDIUM NOT PRESENT or NOT READY / MEDIUM NOT PRESENT? That's all that matters here. Other sorts of device removal would be handled much differently. Cheers, Martin
