[PATCH 0/5] megaraid_sas: Updates for scsi-misc

James/linux-scsi, The following patch series for megaraid_sas brings the driver up to v06.803.01.00-rc1: 1. Load correct raid context timeout value for multipathing and clustering. 2. Fix megasas_ioc_init_fusion to use local stack variable. 3. Return leaked MPT frames to MPT command pool. 4. Add

[PATCH 2/5] megaraid_sas: Fix megasas_ioc_init_fusion

James/linux-scsi, The following patch for megaraid_sas fixes the megasas_ioc_init_fusion function to use a local stack variable for the IOCinit frame physical address instead of clobbering the first request descriptor. Signed-off-by: Adam Radford aradf...@gmail.com diff -Naur

[PATCH 3/5] megaraid_sas: Return leaked MPT frames to MPT frame pool

James/linux-scsi, The following patch for megaraid_sas will return leaked MPT frames from any polled DCMD's that timeout to the MPT frame pool. Signed-off-by: Adam Radford aradf...@gmail.com diff -Naur scsi-misc.old/drivers/scsi/megaraid/megaraid_sas_fusion.c

[PATCH 1/5] megaraid_sas: Load correct raid context timeout

James/linux-scsi, The following patch for megaraid_sas loads the correct raid context timeout value for multpathing and clustering. Signed-off-by: Adam Radford aradf...@gmail.com diff -Naur scsi-misc.old/drivers/scsi/megaraid/megaraid_sas_fp.c

[PATCH 5/5] megaraid_sas: Version and Changelog update

James/linux-scsi, The following patch for megaraid_sas updates the driver version to v06.803.01.00-rc1, and updates Documentation/scsi/ChangeLog.megaraid_sas. Signed-off-by: Adam Radford aradf...@gmail.com diff -Naur scsi-misc.old/Documentation/scsi/ChangeLog.megaraid_sas

[PATCH v2 0/3] bnx2fc: fix memory leaks and NULL pointer dereferences

PATCH 1/3 removes a unused variable from the bnx2fc_free_hash_table() function, it was already posted on the linux-scsi mailing list: http://www.spinics.net/lists/linux-scsi/msg72740.html but has not been picked up yet. PATCH 2/3 fixes a memory leak and some NULL pointer dereferences in the

[PATCH 3/3] bnx2fc: fix memory leak in bnx2fc_allocate_hash_table()

In case of error, the bnx2fc_allocate_hash_table() didn't free all the memory it allocated. Signed-off-by: Maurizio Lombardi mlomb...@redhat.com --- drivers/scsi/bnx2fc/bnx2fc_hwi.c | 31 +++ 1 file changed, 19 insertions(+), 12 deletions(-) diff --git

[PATCH 1/3] bnx2fc: remove unused variable hash_table_size

hash_table_size is not used by the bnx2fc_free_hash_table() function. Signed-off-by: Maurizio Lombardi mlomb...@redhat.com --- drivers/scsi/bnx2fc/bnx2fc_hwi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/scsi/bnx2fc/bnx2fc_hwi.c b/drivers/scsi/bnx2fc/bnx2fc_hwi.c index

[PATCH 2/3] bnx2fc: fix memory leak and potential NULL pointer dereference.

If bnx2fc_allocate_hash_table() for some reasons fails, it is possible that the hash_tbl_segments or the hash_tbl_pbl pointers are NULL. In this case bnx2fc_free_hash_table() will panic the system. this patch also fixes a memory leak, the hash_tbl_segments pointer was never freed. Signed-off-by:

Invitation for Wine-Apps.org

Hello linux-scsi@vger.kernel.org, this is an invitation sent to you from user I AM AN INVESTOR WITH CAPITAL OF US$6.7 MILLION. I WANT TO INVEST IN YOUR COUNTRY UNDER YOU CONTROL (nancyabdul1) for the social network Wine-Apps.org. If you want to join please have a look at WINE-Apps.org where you

Re: [PATCH 0/5] megaraid_sas: Updates for scsi-misc

On 03/10/2014 10:51 AM, adam radford wrote: James/linux-scsi, The following patch series for megaraid_sas brings the driver up to v06.803.01.00-rc1: 1. Load correct raid context timeout value for multipathing and clustering. 2. Fix megasas_ioc_init_fusion to use local stack variable. 3.

Re: [PATCH 0/5] megaraid_sas: Updates for scsi-misc

On 03/10/2014 12:13 PM, Hannes Reinecke wrote: On 03/10/2014 10:51 AM, adam radford wrote: James/linux-scsi, The following patch series for megaraid_sas brings the driver up to v06.803.01.00-rc1: 1. Load correct raid context timeout value for multipathing and clustering. 2. Fix

Re: [PATCH 1/3] VMW_PVSCSI: Fix pvscsi_abort() function.

On Sat, 2014-03-08 at 12:51 -0800, Arvind Kumar wrote: This change ensures that pvscsi_abort() function returns SUCCESS only when the command in question was actually completed, otherwise returns FAILURE. The code before change, was causing a bug where driver tries to complete a command to the

[PATCH RESEND] isci: update version to 1.2

The version of isci driver has not been updated for 2 years. It was 83 isci commits ago. Suspend/resume support has been implemented and many bugs have been fixed since 1.1. Now update the version to 1.2. Signed-off-by: Lukasz Dorau lukasz.do...@intel.com Signed-off-by: Dave Jiang

[PATCH 1/5] scsi_sysfs: Implement 'is_visible' callback

Instead of modifying attributes after the device has been created we should be using the 'is_visible' callback to avoid races. Signed-off-by: Hannes Reinecke h...@suse.de --- drivers/scsi/scsi_sysfs.c | 184 +++--- 1 file changed, 93 insertions(+), 91

[PATCH 3/5] Add EVPD page 0x83 to sysfs

EVPD page 0x83 is used to uniquely identify the device. So instead of having each and every program issue a separate SG_IO call to retrieve this information it does make far more sense to display it in sysfs. Cc: Jeremy Linton jlin...@tributary.com Cc: Kay Sievers k...@vrfy.org Cc: Doug Gilbert

[PATCHv8 0/5] Display EVPD pages in sysfs

Here's now v8 of my patch series to display VPD pages in sysfs. Changes to v7: - Modify ses driver to use vpd_pg83 information - Use get_unaligned_XX where possible - Split off modifications to scsi_vpd_inquiry() into a separate patch. So with this series all outstanding issues should be

[PATCH 4/5] Add EVPD page 0x80 to sysfs

Some older devices (most notably tapes) will only report reliable information in page 0x80 (Unit Serial Number). So export this in the sysfs attribute 'vpd_pg80'. Cc: Doug Gilbert dgilb...@interlog.com Cc: Jeremy Linton jlin...@tributary.com Signed-off-by: Hannes Reinecke h...@suse.de ---

[PATCH 5/5] ses: Use vpd information from scsi_device

The scsi_device now has VPD page83 information attached, so there is no need to query it again. Signed-off-by: Hannes Reinecke h...@suse.de --- drivers/scsi/ses.c | 38 ++ 1 file changed, 10 insertions(+), 28 deletions(-) diff --git a/drivers/scsi/ses.c

[PATCH 2/5] scsi: Return VPD page length in scsi_vpd_inquiry()

We should be returning the number of bytes of the requested VPD page in scsi_vpd_inquiry. This makes it easier for the caller to verify the required space. Signed-off-by: Hannes Reinecke h...@suse.de --- drivers/scsi/scsi.c | 17 ++--- 1 file changed, 10 insertions(+), 7 deletions(-)

Re: [PATCH v5 3/3] scsi: async sd resume

On Fri, 7 Mar 2014, Dan Williams wrote: On Fri, 2014-03-07 at 10:42 -0500, Alan Stern wrote: #ifdef CONFIG_PM_SLEEP +#define do_pm_op(dev, op) \ + dev-driver ? dev-driver-pm ? \ + dev-driver-pm-op(dev) : 0 : 0 This will crash if dev-driver-pm-op is NULL. How about making

Re: [PATCH 5/5] ses: Use vpd information from scsi_device

On Mon, 2014-03-10 at 15:28 +0100, Hannes Reinecke wrote: The scsi_device now has VPD page83 information attached, so there is no need to query it again. This is a bit new for a v8 patch, have you actually tested it? I'm asking because it looks to me like the vpd attach is done just before the

Re: [PATCH 3/5] Add EVPD page 0x83 to sysfs

On Mon, 2014-03-10 at 15:28 +0100, Hannes Reinecke wrote: EVPD page 0x83 is used to uniquely identify the device. So instead of having each and every program issue a separate SG_IO call to retrieve this information it does make far more sense to display it in sysfs. Christoph's suggestion of

Re: [PATCH 5/5] ses: Use vpd information from scsi_device

On 03/10/2014 07:20 PM, James Bottomley wrote: On Mon, 2014-03-10 at 15:28 +0100, Hannes Reinecke wrote: The scsi_device now has VPD page83 information attached, so there is no need to query it again. This is a bit new for a v8 patch, have you actually tested it? I'm asking because it looks

Re: [PATCH 3/5] Add EVPD page 0x83 to sysfs

On 03/10/2014 07:24 PM, James Bottomley wrote: On Mon, 2014-03-10 at 15:28 +0100, Hannes Reinecke wrote: EVPD page 0x83 is used to uniquely identify the device. So instead of having each and every program issue a separate SG_IO call to retrieve this information it does make far more sense to

Re: [PATCH v2 00/13] T10-PI support for iSER initiator

On Wed, Mar 5, 2014 at 7:43 PM, Sagi Grimberg sa...@mellanox.com wrote: Hey Roland, Nic, Mike and Co This patchset adds T10 protection information offload support over RDMA signature verbs API. This set, along with the iSER target set, allow end-to-end protection information passthrough and

Writing session to CD does not update some important cached information.

(This is based on the bug report https://bugzilla.redhat.com/show_bug.cgi?id=918200) When I repartition a disk, when I exit the partitioning tool, it has some method of ordering the kernel to re-read the partition table. Thus, after repartitioning, the partitions I've created/changed are

Re: [PATCH v5 1/3] libata, libsas: kill pm_result and related cleanup

Hello, On Wed, Mar 05, 2014 at 12:17:30PM -0800, Dan Williams wrote: +#define ata_port_resume_sync(ap, msg) ata_port_resume_common((ap), (msg), false) +#define queue_ata_port_resume(ap, msg) ata_port_resume_common((ap), (msg), true) Let's please use proper static functions. The compiler

Re: [PATCH v5 3/3] scsi: async sd resume

On Fri, Mar 07, 2014 at 06:52:06PM -0800, Dan Williams wrote: From: Dan Williams dan.j.willi...@intel.com async_schedule() sd resume work to allow disks and other devices to resume in parallel. This moves the entirety of scsi_device resume to an async context to ensure that

Re: [PATCH v5 1/3] libata, libsas: kill pm_result and related cleanup

On Mon, Mar 10, 2014 at 04:29:47PM -0400, Tejun Heo wrote: Let's please use proper static functions. The compiler can deal with inlining. Also, maybe ata_port_resume() and ata_port_resume_async() are better names for the wrappers? So, if the suggested names don't jive well with the rest of

Re: [PATCH v15 3/3] arm64: Add APM X-Gene SoC 15Gbps Multi-purpose PHY DTS entries

On Sun, Mar 09, 2014 at 10:23:33PM -0700, Loc Ho wrote: Hi Tejun, On Fri, Mar 7, 2014 at 9:28 AM, Loc Ho l...@apm.com wrote: This patch adds the DTS entries for the APM X-Gene SoC 15Gbps Multi-purpose PHY driver. The PHY for SATA controller 2 and 3 are enabled by default.

[PATCH v3 35/52] scsi, fcoe: Fix CPU hotplug callback registration

Subsystems that want to register CPU hotplug callbacks, as well as perform initialization for the CPUs that are already online, often do it as shown below: get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu);

[PATCH v3 34/52] scsi, bnx2fc: Fix CPU hotplug callback registration

Subsystems that want to register CPU hotplug callbacks, as well as perform initialization for the CPUs that are already online, often do it as shown below: get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu);

[PATCH v3 33/52] scsi, bnx2i: Fix CPU hotplug callback registration

Subsystems that want to register CPU hotplug callbacks, as well as perform initialization for the CPUs that are already online, often do it as shown below: get_online_cpus(); for_each_online_cpu(cpu) init_cpu(cpu);

Re: [PATCH v5 3/3] scsi: async sd resume

On Mon, Mar 10, 2014 at 1:43 PM, Tejun Heo t...@kernel.org wrote: On Fri, Mar 07, 2014 at 06:52:06PM -0800, Dan Williams wrote: From: Dan Williams dan.j.willi...@intel.com async_schedule() sd resume work to allow disks and other devices to resume in parallel. This moves the entirety of

Re: [PATCH v5 3/3] scsi: async sd resume

On Mon, 10 Mar 2014, Dan Williams wrote: The only thing which is a bit concerning is that this doesn't have any throttling mechanism for simultaneous wakeups. Would this be able to blow up the PSU if used on a machine with a lot of spindles? Good point. The primary benefit is

Re: [PATCH v5 3/3] scsi: async sd resume

On Mon, Mar 10, 2014 at 1:59 PM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 10 Mar 2014, Dan Williams wrote: The only thing which is a bit concerning is that this doesn't have any throttling mechanism for simultaneous wakeups. Would this be able to blow up the PSU if used on a

Re: [PATCH 0/6] iser-target: Fix active I/O shutdown related issues

On Thu, 2014-03-06 at 16:05 +0200, sagi grimberg wrote: On 3/6/2014 12:04 AM, Nicholas A. Bellinger wrote: On Wed, 2014-03-05 at 14:12 +0200, Sagi Grimberg wrote: On 3/5/2014 2:06 AM, Nicholas A. Bellinger wrote: On Tue, 2014-03-04 at 17:17 +0200, Sagi Grimberg wrote: On 3/4/2014 2:00 AM,

Re: [PATCH v5 3/3] scsi: async sd resume

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 03/10/2014 04:59 PM, Alan Stern wrote: Why? The existing code doesn't have anything like that. The current sd code doesn't, but the libata code does use the AHCI staggered spinup feature flag as a hint to only spin up one drive at a time, so

[PATCHv2 6/9] target: Rename core_tpg_post_dellun to remove_lun

A clearer name, now that pre_dellun is gone. Signed-off-by: Andy Grover agro...@redhat.com --- drivers/target/target_core_device.c | 2 +- drivers/target/target_core_internal.h | 2 +- drivers/target/target_core_tpg.c | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git

[PATCHv2 0/9] target: Save memory on unused se_dev_entrys and se_luns

Hi nab, hch, and all, This patchset reduces the amount of memory for se_dev_entry and se_lun arrays by waiting to allocate array members, and includes some related simplification patches too. This is a rework of a few patches I submitted in December in a larger series, but keeping it simple by

[PATCHv2 9/9] target: Refactor core_enable_device_list_for_node

Create helper functions to alloc a deve and to transition it from demo mode to explicit. Signed-off-by: Andy Grover agro...@redhat.com --- drivers/target/target_core_device.c | 121 ++-- 1 file changed, 74 insertions(+), 47 deletions(-) diff --git

[PATCHv2 3/9] target: Allocate se_dev_entrys in device list only when used

Remove TRANSPORT_LUNFLAGS_INITIATOR_ACCESS and just look at if a non-NULL value is in the node_acl-device_list for the given lun. Since usually nowhere near all se_dev_entrys are used, this nets a sizable reduction in memory use. In core_disable_device_list_for_node, move all calls to functions

[PATCHv2 4/9] target: core_tpg_post_dellun can return void

Nothing in it can raise an error. Signed-off-by: Andy Grover agro...@redhat.com --- drivers/target/target_core_internal.h | 2 +- drivers/target/target_core_tpg.c | 5 + 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/target/target_core_internal.h

[PATCHv2 1/9] target: Add locking to some accesses to nacl.device_list

Make sure all accesses of deve elements in device_list are protected. This will become critically important once device_list entries are potentially NULL. Reported-by: Christoph Hellwig h...@lst.de Signed-off-by: Andy Grover agro...@redhat.com --- drivers/target/target_core_device.c |

[PATCHv2 8/9] target: Remove core_tpg_release_virtual_lun0 function

Simple and just called from one place. Signed-off-by: Andy Grover agro...@redhat.com --- drivers/target/target_core_tpg.c | 9 + 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/drivers/target/target_core_tpg.c b/drivers/target/target_core_tpg.c index a63a3d7..bc0299a 100644

[PATCHv2 7/9] target: Allocate se_luns only when used

Instead of allocating the tpg_lun_list and each member of the list when the tpg is created, make the list part of the parent struct, and use an element being non-NULL to indicate an active LUN. This will save memory if less than all the se_luns are actually configured. Now that things are

[PATCHv2 2/9] target: Don't unlock/relock tpg_lun_lock in loop in add_node_to_devs

It's not safe to unlock/relock in core_tpg_add_node_to_devs. Remove this. As a consequence, core_enable_device_list_for_node needs to be called with a lock held irqs off. Add a comment mentioning this. Change spin_lock_irqs to spin_locks. Change error handling to goto-style. Also change the

Re: [PATCH 3/5] Add EVPD page 0x83 to sysfs

On Mon, 2014-03-10 at 21:52 +0100, Hannes Reinecke wrote: On 03/10/2014 07:24 PM, James Bottomley wrote: On Mon, 2014-03-10 at 15:28 +0100, Hannes Reinecke wrote: EVPD page 0x83 is used to uniquely identify the device. So instead of having each and every program issue a separate SG_IO

Re: [PATCH v5 3/3] scsi: async sd resume

On Mon, 2014-03-10 at 16:59 -0400, Alan Stern wrote: On Mon, 10 Mar 2014, Dan Williams wrote: The only thing which is a bit concerning is that this doesn't have any throttling mechanism for simultaneous wakeups. Would this be able to blow up the PSU if used on a machine with a lot of

Re: [PATCH v5 3/3] scsi: async sd resume

On Mon, Mar 10, 2014 at 9:19 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Mon, 2014-03-10 at 16:59 -0400, Alan Stern wrote: On Mon, 10 Mar 2014, Dan Williams wrote: The only thing which is a bit concerning is that this doesn't have any throttling mechanism for

Re: [PATCH v5 3/3] scsi: async sd resume

On Mon, 2014-03-10 at 21:47 -0700, Dan Williams wrote: On Mon, Mar 10, 2014 at 9:19 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Mon, 2014-03-10 at 16:59 -0400, Alan Stern wrote: On Mon, 10 Mar 2014, Dan Williams wrote: The only thing which is a bit concerning is

Re: [PATCH v5 3/3] scsi: async sd resume

On Mon, Mar 10, 2014 at 10:16 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Mon, 2014-03-10 at 21:47 -0700, Dan Williams wrote: On Mon, Mar 10, 2014 at 9:19 PM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Mon, 2014-03-10 at 16:59 -0400, Alan Stern