Re: [PATCH] scsi: rescan VPD attributes

[Martin K. Petersen]

> "Hannes" == Hannes Reinecke  writes:

Hannes> The VPD page information might change, so we need to be able to
Hannes> update it. This patch implements a VPD page rescan whenever the
Hannes> 'rescan' sysfs attribute is triggered.

Applied to 4.5/scsi-queue.

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

RE: [PATCH] scsi: rescan VPD attributes

[Seymour, Shane M]

> The VPD page information might change, so we need to be able to
> update it. This patch implements a VPD page rescan whenever
> the 'rescan' sysfs attribute is triggered.
>
> Signed-off-by: Hannes Reinecke 
> ---

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

Re: [PATCH] scsi: rescan VPD attributes

[Martin K. Petersen]

> "Hannes" == Hannes Reinecke  writes:

Hannes> The VPD page information might change, so we need to be able to
Hannes> update it. This patch implements a VPD page rescan whenever the
Hannes> 'rescan' sysfs attribute is triggered.

I was looking into merging the ALUA series but this prerequisite patch
is lacking reviews...

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

RE: [PATCH] scsi: rescan VPD attributes

[Seymour, Shane M]

Hi Hannes,

I have one probably small nitpick about the patch. I'm not sure how likely what 
I've put below is likely to happen in real life though.

Is there any chance at all that sdev->vpd_pg83_len could change when updated? 
If there's any chance of that I'd have expected that both the length of and the 
pointer to the vpd data would need to be protected not just the pointer so 
someone would have a consistent picture of the vpd and its length. Without that 
there is a race where someone could be using a new length with the old vpd 
data. That leaves the potential for a length that exceeds the vpd size if the 
new data is larger than the old data - I don't know how likely it is but wanted 
to at least bring it up as something to consider. 

I'm not so concerned about sdev->vpd_pg80_len changing since it should have 1 
of 2 fixed sizes and it seems unlikely that once read the first time a device 
would increase it in size (but for consistency in the code if you make a change 
you might want to treat them the same way).

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

Re: [PATCH] scsi: rescan VPD attributes

[Johannes Thumshirn]

On Mon, 2015-11-09 at 13:24 +0100, Hannes Reinecke wrote:
> The VPD page information might change, so we need to be able to
> update it. This patch implements a VPD page rescan whenever
> the 'rescan' sysfs attribute is triggered.
> 
> Signed-off-by: Hannes Reinecke 
> ---
>  drivers/scsi/scsi.c| 20 +---
>  drivers/scsi/scsi_scan.c   |  4 
>  drivers/scsi/scsi_sysfs.c  |  8 ++--
>  drivers/scsi/ses.c | 12 +---
>  include/scsi/scsi_device.h |  5 +++--
>  5 files changed, 39 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index 207d6a7..2e4ef56 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
> @@ -803,7 +803,7 @@ void scsi_attach_vpd(struct scsi_device *sdev)
>   int vpd_len = SCSI_VPD_PG_LEN;
>   int pg80_supported = 0;
>   int pg83_supported = 0;
> - unsigned char *vpd_buf;
> + unsigned char __rcu *vpd_buf, *orig_vpd_buf = NULL;
>  
>   if (sdev->skip_vpd_pages)
>   return;
> @@ -849,8 +849,16 @@ retry_pg80:
>   kfree(vpd_buf);
>   goto retry_pg80;
>   }
> + mutex_lock(>inquiry_mutex);
> + orig_vpd_buf = sdev->vpd_pg80;
>   sdev->vpd_pg80_len = result;
> - sdev->vpd_pg80 = vpd_buf;
> + rcu_assign_pointer(sdev->vpd_pg80, vpd_buf);
> + mutex_unlock(>inquiry_mutex);
> + synchronize_rcu();
> + if (orig_vpd_buf) {
> + kfree(orig_vpd_buf);
> + orig_vpd_buf = NULL;
> + }
>   vpd_len = SCSI_VPD_PG_LEN;
>   }
>  
> @@ -870,8 +878,14 @@ retry_pg83:
>   kfree(vpd_buf);
>   goto retry_pg83;
>   }
> + mutex_lock(>inquiry_mutex);
> + orig_vpd_buf = sdev->vpd_pg83;
>   sdev->vpd_pg83_len = result;
> - sdev->vpd_pg83 = vpd_buf;
> + rcu_assign_pointer(sdev->vpd_pg83, vpd_buf);
> + mutex_unlock(>inquiry_mutex);
> + synchronize_rcu();
> + if (orig_vpd_buf)
> + kfree(orig_vpd_buf);
>   }
>  }
>  
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index 3b3dfef..7e0820f 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -236,6 +236,7 @@ static struct scsi_device *scsi_alloc_sdev(struct
> scsi_target *starget,
>   INIT_LIST_HEAD(>starved_entry);
>   INIT_LIST_HEAD(>event_list);
>   spin_lock_init(>list_lock);
> + mutex_init(>inquiry_mutex);
>   INIT_WORK(>event_work, scsi_evt_thread);
>   INIT_WORK(>requeue_work, scsi_requeue_run_queue);
>  
> @@ -1517,6 +1518,9 @@ EXPORT_SYMBOL(scsi_add_device);
>  void scsi_rescan_device(struct device *dev)
>  {
>   device_lock(dev);
> +
> + scsi_attach_vpd(to_scsi_device(dev));
> +
>   if (dev->driver && try_module_get(dev->driver->owner)) {
>   struct scsi_driver *drv = to_scsi_driver(dev->driver);
>  
> diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
> index fdcf0ab..f021423 100644
> --- a/drivers/scsi/scsi_sysfs.c
> +++ b/drivers/scsi/scsi_sysfs.c
> @@ -758,11 +758,15 @@ show_vpd_##_page(struct file *filp, struct kobject
> *kobj,\
>  {\
>   struct device *dev = container_of(kobj, struct device, kobj);   
> \
>   struct scsi_device *sdev = to_scsi_device(dev); 
> \
> + int ret;\
>   if (!sdev->vpd_##_page) 
> \
>   return -EINVAL; 
> \
> - return memory_read_from_buffer(buf, count, ,\
> -    sdev->vpd_##_page,   \
> + rcu_read_lock();\
> + ret = memory_read_from_buffer(buf, count, , 
> \
> +   rcu_dereference(sdev->vpd_##_page), \
>      sdev->vpd_##_page##_len);\
> + rcu_read_unlock();  \
> + return ret; \
>  }\
>  static struct bin_attribute dev_attr_vpd_##_page = { \
>   .attr = {.name = __stringify(vpd_##_page), .mode = S_IRUGO },
>   \
> diff --git a/drivers/scsi/ses.c b/drivers/scsi/ses.c
> index dcb0d76..e234da7 100644
> --- a/drivers/scsi/ses.c
> +++ b/drivers/scsi/ses.c
> @@ -554,17 +554,22 @@ static void ses_match_to_enclosure(struct
> enclosure_device *edev,
>      struct scsi_device *sdev)
>  {
>   unsigned char *desc;
> + unsigned char __rcu *vpd_pg83;
>   

Re: [PATCH] scsi: rescan VPD attributes

[Hannes Reinecke]

On 11/26/2015 06:07 AM, Seymour, Shane M wrote:
> Hi Hannes,
> 
> I have one probably small nitpick about the patch. I'm not sure how likely 
> what I've put below is likely
> to happen in real life though.
> 
> Is there any chance at all that sdev->vpd_pg83_len could change when updated?
> If there's any chance of that I'd have expected that both the
length of and the pointer to the vpd data
> would need to be protected not just the pointer so someone would
have a consistent picture of the vpd
> and its length. Without that there is a race where someone could
be using a new length with the old vpd
> data. That leaves the potential for a length that exceeds the vpd
size if the new data is larger than
> the old data - I don't know how likely it is but wanted to at
least bring it up as something to consider.
> 
Accesses to vpd_pgXX are rcu-protected, so we're ensured that we
always see a _valid_ copy. And we know that integer updates are
atomic, so we will always see a valid number in vpd_pgXX_len.
Both, vpd_pgXX and vpd_pgXX_len, are updated at the same place, and
under the same locks/mutexes. And as we're calling
'synchronize_rcu()' after updating vpd_pgXX, which needs to
synchronize against all CPUs, I would think that this would take
care of updating vpd_pgXX_len, too.

But you are right, we can get rid of vpd_pgXX_len and calculate it
from the data.
However, I'd like to do this with another patch after the ALUA
changes are in.

Cheers,

Hannes
-- 
Dr. Hannes ReineckezSeries & Storage
h...@suse.de   +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html