RE: [PATCH v4 3/3] Rework handling of scsi_device.vpd_pg8[03]

> Introduce struct scsi_vpd for the VPD page length, data and the > RCU head that will be used to free the VPD data. Use kfree_rcu() > instead of kfree() to free VPD data. Move the VPD buffer pointer > check inside the RCU read lock in the sysfs code. Only annotate > pointers that are shared

RE: [PATCH v4 2/3] Rework the code for caching Vital Product Data (VPD)

> Introduce the scsi_get_vpd_buf() and scsi_update_vpd_page() > functions. The only functional change in this patch is that if > updating page 0x80 fails that it is attempted to update page 0x83. > > Signed-off-by: Bart Van Assche > Acked-by: Hannes Reinecke

RE: [PATCH 2/2] Rework handling of scsi_device.vpd_pg8[03]

J . > Bottomley <j...@linux.vnet.ibm.com> > Cc: linux-scsi@vger.kernel.org; Bart Van Assche <bart.vanass...@wdc.com>; > Christoph Hellwig <h...@lst.de>; Hannes Reinecke <h...@suse.de>; > Johannes Thumshirn <jthumsh...@suse.de>; Seymour, Shane M > <shane.seym...@hpe.com

RE: [PATCH 1/2] Introduce scsi_get_vpd_buf()

inux.vnet.ibm.com> > Cc: linux-scsi@vger.kernel.org; Bart Van Assche <bart.vanass...@wdc.com>; > Christoph Hellwig <h...@lst.de>; Hannes Reinecke <h...@suse.de>; > Johannes Thumshirn <jthumsh...@suse.de>; Seymour, Shane M > <shane.seym...@hpe.com&g

RE: [PATCH 07/19] Fix RCU handling of scsi_device.vpd_pg8[03]

> Hello Shane, > > You have either misinterpret my statement or the SCSI VPD handling code. If > you have a look at the SCSI VPD handling code you will see that an > rcu_read_lock() / > rcu_read_unlock() pair is sufficient to prevent that the VPD buffer > rcu_dereference() points at is being

RE: [PATCH 07/19] Fix RCU handling of scsi_device.vpd_pg8[03]

> -Original Message- > From: Bart Van Assche [mailto:bart.vanass...@wdc.com] > Sent: Friday, August 25, 2017 2:54 AM > To: h...@lst.de > Cc: j...@linux.vnet.ibm.com; linux-scsi@vger.kernel.org; h...@suse.de; > jthumsh...@suse.de; martin.peter...@oracle.com; Seymour, Sha

RE: [PATCH] qlogicpti: Return correct error code

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 1/2] scsi_transport_fc: implement 'disable_target_scan' module parameter

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 2/2] scsi_transport_fc: Implement 'async_user_scan' module parameter

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] snic: correctly check for array overrun on overly long version number

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 0/2][RESEND] scsi_transport_fc: LUN masking

> But this has nothing to do with the patchset, right? Correct. -- 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 0/2][RESEND] scsi_transport_fc: LUN masking

Hi Hannes, How do you know that a request for an async scan is complete (I'm assuming that you get add or change udev events)? Assuming that someone has manually started a scan on something (e.g. some newly presented devices after boot) and all scans are going to be async how do you when it is

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

Hi Kai, I've done more tested. Some stuff didn't work and I've got some suggested changes (there are two changes to the patch and one for the mt command). Testing results first: # echo 1 > /sys/bus/scsi/drivers/st/debug_flag # mt -f /dev/st2 stsetoption can-partitions # mt -f /dev/st1

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

Hi Kai, > -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of "Kai Mäkisara (Kolumbus)" > Sent: Tuesday, February 02, 2016 5:43 AM > To: Seymour, Shane M > Cc: Laurence Oberman; Emmanuel Florac;

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

Shane > -Original Message- > From: makisara@kai.makisara.private [mailto:makisara@kai.makisara.private] > On Behalf Of Kai Makisara > Sent: Saturday, January 30, 2016 4:22 AM > To: Seymour, Shane M > Cc: Laurence Oberman; Emmanuel Florac; Laurence Oberman; linux- &

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

Hi Kai, $ pwd /sys/class/scsi_tape/st1/device $ cat scsi_level 4 Thanks Shane > -Original Message- > From: "Kai Mäkisara (Kolumbus)" [mailto:kai.makis...@kolumbus.fi] > Sent: Friday, January 29, 2016 4:04 AM > To: Seymour, Shane M > Cc: Laurence Oberman;

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

Hi Laurence, > -Original Message- > From: Laurence Oberman [mailto:lober...@redhat.com] > Sent: Friday, January 29, 2016 10:25 AM > To: Seymour, Shane M > Cc: Kai Mäkisara (Kolumbus); Emmanuel Florac; Laurence Oberman; linux- > s...@vger.kernel.org > Subject: Re:

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

day, January 25, 2016 8:05 AM > To: Seymour, Shane M > Cc: Laurence Oberman; Emmanuel Florac; Laurence Oberman; linux- > s...@vger.kernel.org > Subject: RE: What partition should the MTMKPART argument specify? Was: > Re: st driver doesn't seem to grok LTO partitioning > > On

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

Hi Emmanuel, > Hmm in fact if we keep using MB we'll be stuck when tapes reach ~2 PB > which leaves some time to think about it, until LTO-15 circa 2036 :) There will be other issues to solve before then (by LTO-9 2 with compression or LTO-10 without compression and we're at LTO-7 now). Take tar

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

Hi Kai, > -Original Message- > From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi- > ow...@vger.kernel.org] On Behalf Of "Kai Mäkisara (Kolumbus)" > Sent: Friday, January 22, 2016 7:59 AM > To: Seymour, Shane M > Cc: Laurence Oberman; Emmanuel Florac;

RE: What partition should the MTMKPART argument specify? Was: Re: st driver doesn't seem to grok LTO partitioning

My applogies: > It may be worth noting (if you're going to update any documentation) that > isn't 100% accurate. You actually get one wrap in partition 1 and the rest > minus one wrap into partition 0. There is one wrap used as a guard between > the two partitions. The size given to a partition

RE: [PATCH] ipr: fix out-of-bounds null overwrite

> len = snprintf(fname, 99, "%s", buf); > - fname[len-1] = '\0'; Since it appears that's the only time len is actually used in that function can you please remove the variable len completely as part of the patch? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi"

RE: st driver doesn't seem to grok LTO partitioning

If you need help with anything please let me know I'd be more than happy to contribute (with testing and a review if you want). I have a system with an older LTO-3 tape drive that I can use any time (it doesn’t support partitioning so if nothing else I can make sure partitioning attempts fail

RE: [PATCH] scsi: rescan VPD attributes

> 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

RE: [PATCH] scsi: rescan VPD attributes

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

[PATCH] st: allow debug output to be enabled or disabled via sysfs

Change st driver to allow enabling or disabling debug output via sysfs file /sys/bus/scsi/drivers/st/debug_flag. Previously the only way to enable debug output was: 1. loading the driver with the module parameter debug_flag=1 2. an ioctl call (this method was also the only way to dynamically

RE: [PATCH 1/3] hpsa: convert show method snprintf usage to scnprintf

Hi James, There's been no ack on this one. However, there's no actual reason to prefer scnprintf over snprintf: the former will zero terminate, the latter won't if the write length is over the buffer length, but this is a file buffer: the routine will return as many bytes to userspace as are

[ANNOUNCE] tapestat command now part of upstream sysstat

While tape stats were being implemented in the kernel I started working on a program that would read them out and display the data to allow me to test the interface. After the changes were available in linux-next I worked with the upstream sysstat maintainer to get that code into shape so it was

[PATCH] hpsa: non-zero LUNs of multi-LUN devices missing on some Smart Arrays

A regression was introduced into the hpsa driver a while back so non-zero LUNs of multi-LUN devices may no longer be presented via a SAS based Smart Array. I have not done a bisection to discover the change that caused it. The CISS firmware specification (available on sourceforge) defines an 8

RE: [PATCH RFC 1/2] cxlflash: Base support for IBM CXL Flash Adapter

-Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Matthew R. Ochs Sent: Monday, April 27, 2015 2:50 PM To: linux-scsi@vger.kernel.org; james.bottom...@hansenpartnership.com; n...@linux-iscsi.org; brk...@linux.vnet.ibm.com Cc:

[PATCH] st: null pointer dereference panic caused by use after kref_put by st_open

Two SLES11 SP3 servers encountered similar crashes simultaneously following some kind of SAN/tape target issue: ... qla2xxx [:81:00.0]-801c:3: Abort command issued nexus=3:0:2 -- 1 2002. qla2xxx [:81:00.0]-801c:3: Abort command issued nexus=3:0:2 -- 1 2002. qla2xxx

[PATCH v2] hpsa: convert DEVICE_ATTR to RO|WO|RW and show methods must not use snprintf

Changed DEVICE_ATTR macro usage to DEVICE_ATTR_RO|WO|RW. This also forced some show/store function names to change. Changed all show method snprintf() usage to scnprintf() per Documentation/filesystems/sysfs.txt. Signed-off-by: Shane Seymour shane.seym...@hp.com --- Changes from v1: Dropped one

[PATCH 3/3] hpsa: Convert DEVICE_ATTR macro usage to DEVICE_ATTR_RO|WR|WO

Convert DEVICE_ATTR macro usage to DEVICE_ATTR_RO|WR|WO Changes forced some function names to change. Signed-off-by: Shane Seymour shane.seym...@hp.com --- --- a/drivers/scsi/hpsa.c 2015-06-30 16:34:01.403904650 -0500 +++ b/drivers/scsi/hpsa.c 2015-06-30 16:21:54.214954176 -0500 @@

[PATCH 2/3] hpsa: Remove unneccessary variable from raid_level_show

Remove unneccessary variable from raid_level_show Signed-off-by: Shane Seymour shane.seym...@hp.com --- Was not in previous patch. --- a/drivers/scsi/hpsa.c 2015-06-30 16:15:42.631979483 -0500 +++ b/drivers/scsi/hpsa.c 2015-06-30 16:16:45.737975186 -0500 @@ -612,7 +612,6 @@ static

[PATCH 1/3] hpsa: convert show method snprintf usage to scnprintf

Changed all show method snprintf usage to scnprintf per Documentation/filesystems/sysfs.txt. Signed-off-by: Shane Seymour shane.seym...@hp.com --- Please let me know if this is not the correct way to submit patches by separating them but keeping them logically together. --- a/drivers/scsi/hpsa.c

[PATCH] hpsa: convert DEVICE_ATTR to RO|WO|RW and show methods must use scnprintf

Changed DEVICE_ATTR macro usage to DEVICE_ATTR_RO|WO|RW. This also forced some show/store function names to change. Changed all show method sprint/snprintf usage to scnprintf per Documentation/filesystems/sysfs.txt. Signed-off-by: Shane Seymour shane.seym...@hp.com --- --- a/drivers/scsi/hpsa.c

scsi_dh: convert __ATTR macro to DEVICE_ATTR_RW and snprintf show method cleanup

Converted dh_state to use DEVICE_ATTR_RW macro instead of __ATTR. That forced a change to the associated show/store function names and the name of the attribute. Changed usage of snprintf in show function to scnprintf per Documentation/filesystems/sysfs.txt. Signed-off-by: Shane Seymour

[PATCH] scsi_dh: convert __ATTR macro to DEVICE_ATTR_RW and snprintf show method cleanup

Converted dh_state to use DEVICE_ATTR_RW macro instead of __ATTR. That forced a change to the associated show/store function names and the name of the attribute. Changed usage of snprintf in show function to scnprintf per Documentation/filesystems/sysfs.txt. Signed-off-by: Shane Seymour

[PATCH v2] st: convert DRIVER_ATTR macros to DRIVER_ATTR_RO

Convert DRIVER_ATTR macros to DRIVER_ATTR_RO requested by Greg KH. Also switched to using scnprintf instead of snprintf per Documentation/filesystems/sysfs.txt. Suggested-by: Greg Kroah-Hartman gre...@linuxfoundation.org Signed-off-by: Shane Seymour shane.seym...@hp.com --- This patch was

[PATCH] st: convert DRIVER_ATTR macros to DRIVER_ATTR_RO

Convert DRIVER_ATTR macros to DRIVER_ATTR_RO as requested by Greg KH. Also switched to using sprintf as nothing printed should exceed PAGE_SIZE - based on feedback from Greg when implementing show functions for tape stats. Suggested-by: Greg Kroah-Hartman gre...@linuxfoundation.org

st: convert DRIVER_ATTR macros to DRIVER_ATTR_RO

Convert DRIVER_ATTR macros to DRIVER_ATTR_RO as requested by Greg KH. Also switched to using sprintf as nothing printed should exceed PAGE_SIZE - based on feedback from Greg when implementing show functions for tape stats. Suggested-by: Greg Kroah-Hartman gre...@linuxfoundation.org

[PATCH] st: convert to using driver attr groups for sysfs

This patch changes the st driver to use attribute groups so driver sysfs files are created automatically. See the following for reference: http://kroah.com/log/blog/2013/06/26/how-to-create-a-sysfs-file-correctly/ Signed-off-by: Shane Seymour shane.seym...@hp.com --- --- a/drivers/scsi/st.c

RE: [patch] hpsa: fix an sprintf() overflow in the reset handler

With a size of 48 while it won't overflow since you're using snprintf the string with a maximum value in %d: echo -n cmd 2147483647 RESET FAILED, new lockup detected |wc -c 48 is 48 characters long without a null terminator on the string (and in the unlikely event that it's somehow a the

[PATCH v9] st: implement tape statistics

st: implement tape statistics This patch implements tape statistics in the st module via sysfs. Current no statistics are available for tape I/O and there is no easy way to reuse the block layer statistics for tape as tape is a character device and does not have perform I/O in sector sized

RE: [scsi:misc 114/120] drivers/scsi/st.c:4594:3: warning: format '%ld' expects argument of type 'long int', but argument 3 has type 'long long int'

My apologies for this I'm fixing it now. -Original Message- From: kbuild test robot [mailto:fengguang...@intel.com] Sent: Monday, June 01, 2015 12:36 PM To: Seymour, Shane M Cc: kbuild-...@01.org; James Bottomley; Christoph Hellwig; linux-scsi@vger.kernel.org Subject: [scsi:misc 114/120

[PATCH v7] st implement tape statistics

Signed-off-by: Shane Seymour shane.seym...@hp.com Tested-by: Shane Seymour shane.seym...@hp.com --- Changes from v6 - Removed tested by Laurence Oberman since the code has changed significantly. - Changed code to use ktime so time resolution is now in ns (Robert Elliot) for virtual tape drives

[PATCH RESEND v6] st implement tape statistics

The following patch exposes statistics for the st driver via sysfs. There is a need for companies with large numbers of tape drives numbering in the tens of thousands to track the performance of those tape drives (e.g. when a backup exceeds its window). The statistics provided should allow the

RE: [PATCH v6] st implement tape statistics

Retested with patch applied to 4.0.0-rc2-next-20150304 - all successful with no issues found. -Original Message- From: Laurence Oberman [mailto:oberma...@gmail.com] Sent: Thursday, February 26, 2015 5:47 AM To: Seymour, Shane M Cc: Greg KH; linux-scsi@vger.kernel.org; Laurence Oberman

[PATCH v6] st implement tape statistics

The following patch exposes statistics for the st driver via sysfs. There is a need for companies with large numbers of tape drives numbering in the tens of thousands to track the performance of those tape drives (e.g. when a backup exceeds its window). The statistics provided should allow the

[PATCH RESEND v5] st implement tape statistics

The following patch exposes statistics for the st driver via sysfs. There is a need for companies with large numbers of tape drives numbering in the tens of thousands to track the performance of those tape drives (e.g. when a backup exceeds its window). The statistics provided should allow the

RE: [PATCH] st implement tape statistics v3 (updated patch)

Hi Greg, Thank you for pushing me to go that little further. The statistics directory is back. Any feedback from anyone would be appreciated. Thanks Shane -- Signed-off-by: shane.seym...@hp.com Tested-by: shane.seym...@hp.com --- --- a/drivers/scsi/st.c 2015-01-11 14:46:00.243814755 -0600 +++

[PATCH RESEND] st implement tape statistics v3

The following patch exposes statistics for the st driver via sysfs. There is a need for companies with large numbers of tape drives numbering in the tens of thousands to track the performance of those tape drives (e.g. when a backup exceeds its window). The statistics provided should allow the

RE: [PATCH RESEND] st implement tape statistics v3

And you need to put below the --- line what has changed from the last version, I don't see any of my comments address here :( Doh! My appologies Greg, I'd missed your inline comments - I haven't had enough coffee this morning. -- To unsubscribe from this list: send the line unsubscribe

[PATCH] st implement tape statistics v3

Hi All, Please find attached v3 of the patch. It implements the changes requested by Greg. The statistics files aren't in a separate directory any more they're implemented directly as device attributes unless someone has objections to them being in a place like /sys/class/scsi_tape/*/.

RE: [PATCH] st: implement sysfs based tape statistics v2

from correcting it. If there's no way to export a partition number for the devices that support it I can add a new sysfs file (call it partition) to export it that way and see if I can get the correct value into mt_resid. -Original Message- From: Seymour, Shane M Sent: Monday, February

RE: [PATCH] st: implement sysfs based tape statistics v2

, Shane M Cc: linux-scsi@vger.kernel.org Subject: Re: [PATCH] st: implement sysfs based tape statistics v2 One feature of tape statistics is that they're as much about the *tape* as they are about the *drive*, which is uncommon for block devices. It might be useful to have a set of counters which

[RFC] implementing tape statistics single file vs multi-file in sysfs

Hello linux-api'ers There has been some ongoing discussion about the best way to implement tape statistics. The original method suggested a long time ago used a single file in sysfs similar to block statistics in sysfs. That lead to an impass about the code on the linux-scsi mailing list. The

RE: [PATCH] st: implement sysfs based tape statistics v2

I was wondering if anyone had any feedback or had any chance to review the changes? -Original Message- From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-ow...@vger.kernel.org] On Behalf Of Seymour, Shane M Sent: Tuesday, January 13, 2015 2:43 PM To: linux-scsi@vger.kernel.org Cc

[PATCH] st: implement sysfs based tape statistics v2

Some small changes since the last version - this version removes two files from sysfs compared to the last version (read and write block counts since they're derived from the byte counts they can be calculated in user space) but that's the only change. This version has been rebased to

[RFC] Deprecate, modify, or do nothing to SCSI_IOCTL_GET_IDLUN

I'd like to ask if SCSI_IOCTL_GET_IDLUN should be deprecated? This is in response to [Bug 88591] SCSI_IOCTL_GET_IDLUN only returns 8 bits for the SCSI Target value of which has been seen on the mailing list. It only returns one byte of id, lun, channel, and host number but we have

RE: [PATCH] st: implement sysfs based tape statistics

I was wondering if anyone had a chance to review the patch? Comments are appreciated and I'm more than happy to make changes that will allow it to be accepted. -- To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to majord...@vger.kernel.org More

RE: [PATCH] st: set owner in struct device_driver

I can, but at this point it will be tomorrow (11pm where I am). -- 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

[PATCH] st: implement sysfs based tape statistics

It's been a year since my last attempt at doing this as I got distracted by some other things. Comments are appreciated and any questions will be answered. The following implements sysfs based per device tape statistics files with one file per statistic and a method of trying to allow a

[PATCH] st: set owner in struct device_driver

After moving from from branch next-20141106 to next-2014 to pick up recent changes to the st driver I found that the following message was being logged by the kernel (for many other modules as well): Driver 'st' needs an owner There was a change in driver_register to check the struct

[PATCH v2]st: provide tape statistics via sysfs

New version of statistics patch: - Removed sysfs file containing hint for number of tape drives - Removed disk like stat file - there is now one file per statistic as per feedback from James - Like all other kernel stats these start at zero and keep incrementing (cannot zero them any more) -

[PATCH]st: clear driver data from struct device when released

Patch to clear driver specific data from struct device associated with a tape drive when released by st unload or because there was a problem attaching to the device. Currently set in st_probe but never cleared. Signed-off-by: Shane Seymour shane.seym...@hp.com Tested-by: Shane Seymour

RE: [PATCH] st: Take additional queue ref in st_probe

With the things I've been doing in st it was easier to reboot than unload/load the st driver since it would likely cause an oops. I applied the patch and have tested it and the st module unloads/reloads with no problems now. -- To unsubscribe from this list: send the line unsubscribe linux-scsi

RE: [Patch][RFC] st: provide tape statistics via sysfs

-Original Message- From: Kai Mäkisara [mailto:kai.makis...@kolumbus.fi] Sent: Wednesday, February 27, 2013 4:38 AM To: James Bottomley Cc: Seymour, Shane M; linux-scsi@vger.kernel.org Subject: Re: [Patch][RFC] st: provide tape statistics via sysfs The sysfs files in the patch export

[Patch][RFC] st: provide tape statistics via sysfs

First forgive me for using outlook for this, if there are any issues with what I sent let me know and I'll send it again from gmail. This is also my first attempt at a kernel patch so please be gentle. This patch was written to enable tape statistics via sysfs for the dt driver based on kernel