From patchwork Tue Feb 2 20:12:00 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Mike Christie X-Patchwork-Id: 8195241 Return-Path: X-Original-To: patchwork-linux-scsi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id E4ECB9FBE9 for ; Tue, 2 Feb 2016 20:12:41 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 4CA7E202BE for ; Tue, 2 Feb 2016 20:12:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 9FDE5202B8 for ; Tue, 2 Feb 2016 20:12:40 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754895AbcBBUMk (ORCPT ); Tue, 2 Feb 2016 15:12:40 -0500 Received: from sabe.cs.wisc.edu ([128.105.6.20]:56095 "EHLO sabe.cs.wisc.edu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754832AbcBBUMj (ORCPT ); Tue, 2 Feb 2016 15:12:39 -0500 Received: from [20.15.0.202] (c-73-242-60-185.hsd1.mn.comcast.net [73.242.60.185]) (authenticated bits=0) by sabe.cs.wisc.edu (8.14.7/8.14.1) with ESMTP id u12KC5jC005784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 2 Feb 2016 14:12:06 -0600 Message-ID: <56B10D90.2010506@cs.wisc.edu> Date: Tue, 02 Feb 2016 14:12:00 -0600 From: Mike Christie User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Christoph Hellwig CC: "Serguei Bezverkhi (sbezverk)" , "bugzilla-daemon@bugzilla.kernel.org" , "linux-scsi@vger.kernel.org" , Hannes Reinecke Subject: Re: [Bug 111441] New: iscsi fails to attach to targets References: <56AAC605.1080707@cs.wisc.edu> <9cf7d536fcc44d9d8f35d81503543497@XCH-ALN-006.cisco.com> <36266784-E570-406E-8C3A-56D0F728768B@cs.wisc.edu> <01C3BBA0-3D1A-461A-9EEF-512A57707325@cs.wisc.edu> <4c4653b259cd4f1887505dfc61d500a8@XCH-ALN-006.cisco.com> <56ABBCFF.9060003@cs.wisc.edu> <26376c0ade5645cfac5cc248a97528ba@XCH-ALN-006.cisco.com> <56ABF6A6.8070506@cs.wisc.edu> <20160202180956.GB13880@infradead.org> In-Reply-To: <20160202180956.GB13880@infradead.org> Sender: linux-scsi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-scsi@vger.kernel.org X-Spam-Status: No, score=-7.3 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, T_TVD_MIME_EPI, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP 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);