All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Subhash Jadavani" <subhashj@codeaurora.org>
To: 'Christoph Hellwig' <hch@infradead.org>,
	'Dolev Raviv' <draviv@codeaurora.org>
Cc: James.Bottomley@HansenPartnership.com,
	linux-scsi@vger.kernel.org, linux-scsi-owner@vger.kernel.org,
	linux-arm-msm@vger.kernel.org, santoshsy@gmail.com
Subject: RE: [PATCH V5 02/17] scsi: sysfs: don't add scsi_device if its already added
Date: Wed, 24 Sep 2014 09:27:47 -0700	[thread overview]
Message-ID: <000f01cfd814$7a6be2b0$6f43a810$@codeaurora.org> (raw)
In-Reply-To: <20140924160825.GB13541@infradead.org>

>> If LLD has added scsi device (by calling scsi_add_device) before 
>> scheduling async scsi_scan_host then scsi_finish_async_scan() will end 
>> up calling scsi_sysfs_add_sdev for scsi device which was already added by
LLD.
>> This patch fixes this issue by adding a check at the start of
>> scsi_sysfs_add_sdev() to skip the device add if it's already visible 
>> to rest of the kernel.
>
> This looks wrong to me.   I guess this happens for the case where you
> added the well known lun explicitly, and then have one of the devices that
also report it from REPORT LUNS?  I guess the right answer is to explicitly
ignore wluns in scsi_report_lun_scan.

No, It happens in this sequence of events:
1. LLD calls the __scsi_add_device() for well known logical units before
scsi_scan_host() (This is done as part of [PATCH V5 10/17] scsi: ufs:
manually add well known logical units). __scsi_add_device() will also add
the scsi device to sysfs by calling scsi_sysfs_add_sdev()
2. Now LDD calls the scsi_scan_host() (Note that CONFIG_SCSI_SCAN_ASYNC is
enabled) which will schedule the async scan. Device reports only normal LUs
(no w-lus reported here) when REPORT LUNs in sent with SELECT REPORT
cleared. At the end of async scan, scsi_finish_async_scan() calls
scsi_sysfs_add_devices(). scsi_sysfs_add_devices() iterates through all the
scsi_device instances attached to Scsi_Host hence end up calling
scsi_sysfs_add_sdev() 2nd time for the scsi_device which were already added
explicitly by LDD.


BTW, none of the UFS devices are reporting the W-LUs when SELECT REPORT is
cleared. I was confused with the crash (which is fixed by this patch) seen
with scenario mentioned above and thought that REPORT LUNs (with SELECT
REPORT=00h) is reporting W-LUs as well but I confirmed that that's not the
case with any of the UFS device vendors.


-----Original Message-----
From: linux-scsi-owner@vger.kernel.org
[mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Christoph Hellwig
Sent: Wednesday, September 24, 2014 9:08 AM
To: Dolev Raviv
Cc: James.Bottomley@HansenPartnership.com; hch@infradead.org;
linux-scsi@vger.kernel.org; linux-scsi-owner@vger.kernel.org;
linux-arm-msm@vger.kernel.org; santoshsy@gmail.com; Subhash Jadavani
Subject: Re: [PATCH V5 02/17] scsi: sysfs: don't add scsi_device if its
already added

On Wed, Sep 24, 2014 at 06:13:58PM +0300, Dolev Raviv wrote:
> From: Subhash Jadavani <subhashj@codeaurora.org>
> 
> If LLD has added scsi device (by calling scsi_add_device) before 
> scheduling async scsi_scan_host then scsi_finish_async_scan() will end 
> up calling scsi_sysfs_add_sdev for scsi device which was already added by
LLD.
> This patch fixes this issue by adding a check at the start of
> scsi_sysfs_add_sdev() to skip the device add if it's already visible 
> to rest of the kernel.

This looks wrong to me.   I guess this happens for the case where you
added the well known lun explicitly, and then have one of the devices that
also report it from REPORT LUNS?  I guess the right answer is to explicitly
ignore wluns in scsi_report_lun_scan.

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2014-09-24 16:27 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-24 15:13 [PATCH/RESEND V5 00/17] UFS: Power management support Dolev Raviv
2014-09-24 15:13 ` [PATCH V5 01/17] scsi: fixing the "type" for well known LUs Dolev Raviv
2014-09-24 16:04   ` Christoph Hellwig
2014-09-24 20:49     ` Elliott, Robert (Server Storage)
2014-09-25  6:18       ` Subhash Jadavani
2014-09-24 15:13 ` [PATCH V5 02/17] scsi: sysfs: don't add scsi_device if its already added Dolev Raviv
2014-09-24 16:08   ` Christoph Hellwig
2014-09-24 16:27     ` Subhash Jadavani [this message]
2014-09-24 16:38       ` 'Christoph Hellwig'
2014-09-25  0:29         ` Subhash Jadavani
2014-09-24 15:13 ` [PATCH/RESEND V5 03/17] scsi: ufs: Allow vendor specific initialization Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 04/17] scsi: ufs: Add regulator enable support Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 05/17] scsi: ufs: Add clock initialization support Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 06/17] scsi: ufs: add voting support for host controller power Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 07/17] scsi: ufs: refactor query descriptor API support Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 08/17] scsi: ufs: improve init sequence Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 09/17] scsi: ufs: Active Power Mode - configuring bActiveICCLevel Dolev Raviv
2014-09-24 15:14 ` [PATCH V5 10/17] scsi: ufs: manually add well known logical units Dolev Raviv
2014-09-24 16:24   ` Christoph Hellwig
2014-09-24 16:36     ` Subhash Jadavani
2014-09-24 16:40       ` 'Christoph Hellwig'
2014-09-24 16:59         ` Subhash Jadavani
2014-09-24 15:14 ` [PATCH V5 11/17] scsi: ufs: add UFS power management support Dolev Raviv
2014-09-24 23:11   ` Akinobu Mita
2014-09-25 10:35     ` Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 12/17] scsi: ufs: refactor configuring power mode Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 13/17] scsi: ufs: Add support for clock gating Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 14/17] scsi: ufs: Add freq-table-hz property for UFS device Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 15/17] scsi: ufs: Add support for clock scaling using devfreq framework Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 16/17] scsi: ufs: tune bkops while power managment events Dolev Raviv
2014-09-24 15:14 ` [PATCH/RESEND V5 17/17] scsi: ufs: definitions for phy interface Dolev Raviv

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='000f01cfd814$7a6be2b0$6f43a810$@codeaurora.org' \
    --to=subhashj@codeaurora.org \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=draviv@codeaurora.org \
    --cc=hch@infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-scsi-owner@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=santoshsy@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.