On 02/02/2016 12:09 PM, Christoph Hellwig wrote:
> On Fri, Jan 29, 2016 at 05:32:54PM -0600, Mike Christie wrote:
>> Hey Christoph and Hannes,
>>
>> The dh/alua changes that added this:
>>
>> error = scsi_dh_add_device(sdev);
>> if (error) {
>> sdev_printk(KERN_INFO, sdev,
>> "failed to add device handler: %d\n",
>> error);
>> return error;
>> }
>>
>> to scsi_sysfs_add_sdev are adding a regression.
>>
>> 1. If that fails, then we forget to do device_del before doing the
>> return. My patch in this thread added that back, so we do not see the
>> sysfs oopses anymore. But.....
>
> Ok.
>
>> 2. It looks like in older kernels, we would allow misconfigured targets
>> like this one to still setup devices. Do we want that old behavior back?
>> Should we just ignore the return value from scsi_dh_add_device above?
>> Note that in this case, it is LIO so it can be easily fixed on the
>> target side by just setting it up properly. I do not think other targets
>> would hit this type of issue.
>
> Be liberal in what you accept.. I guess we need to continue allowing
> to connect to these broken targets, but a warning would be useful.
>
> Can you send a patch?
Serguei, can you try the attached patch? Drop the other one I sent.
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 21930c9..7dcc4bf 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1059,9 +1059,12 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
error = scsi_dh_add_device(sdev);
if (error) {
+ /*
+ * Allow device setup to succeed. Attachment can be retried
+ * from userpsace or device can be still used in degraded mode.
+ */
sdev_printk(KERN_INFO, sdev,
"failed to add device handler: %d\n", error);
- return error;
}
device_enable_async_suspend(&sdev->sdev_dev);
