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. > Sure, there might be non-compatible devices which do _not_ set the > removable flag (despite them being removable) and the notorious > aacraid > which insists on claiming all devices being removable, but if the > need > arises we can always introduce a blacklist flag. I agree. Also, I suppose that if someone has a case for checking for media change on non-removable devices, (s)he will bring it up. Therefore: Acked-by: Martin Wilck <mwilck@xxxxxxxx> Regards Martin
