Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On 02/11/2015 16:05, Mike Snitzer wrote: > > In any case, if we don't start path activation we should return > > ENOTCONN, not ENOTTY. > > Currently, if we don't start path activation we're returning EIO. > ENOTCONN is used for when we do start path activation (and ENOTCONN is > the means for

Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On Mon, Nov 02 2015 at 10:45am -0500, Paolo Bonzini wrote: > > > On 02/11/2015 16:05, Mike Snitzer wrote: > > > In any case, if we don't start path activation we should return > > > ENOTCONN, not ENOTTY. > > > > Currently, if we don't start path activation we're returning

Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On Mon, Nov 02 2015 at 2:28am -0500, Hannes Reinecke wrote: > On 10/31/2015 11:47 PM, Mike Snitzer wrote: > > > > For Hannes, and in my head, it didn't matter if a future bdev satisfies > > the length condition. I don't think Hannes was trying to guard against > > dangerous

Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On Mon, Nov 02 2015 at 9:52am -0500, Paolo Bonzini wrote: > > > On 02/11/2015 14:56, Hannes Reinecke wrote: > > But then the real question remains: > > > > What is the 'correct' behaviour for ioctls when no path retry > > is active (or when no paths are present)? > > >

Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On 11/02/2015 04:14 PM, Mike Snitzer wrote: > On Mon, Nov 02 2015 at 9:36am -0500, > Hannes Reinecke wrote: [ .. ] >> From b0d5848e91cfc3b97adb49121085c994b707eac3 Mon Sep 17 00:00:00 2001 >> From: Hannes Reinecke >> Date: Mon, 2 Nov 2015 15:33:58 +0100 >> Subject:

Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On 11/02/2015 02:31 PM, Mike Snitzer wrote: > On Mon, Nov 02 2015 at 2:28am -0500, > Hannes Reinecke wrote: > >> On 10/31/2015 11:47 PM, Mike Snitzer wrote: >>> >>> For Hannes, and in my head, it didn't matter if a future bdev satisfies >>> the length condition. I don't think

Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On 02/11/2015 14:56, Hannes Reinecke wrote: > But then the real question remains: > > What is the 'correct' behaviour for ioctls when no path retry > is active (or when no paths are present)? > > Should we start path activation? > If so, should we wait for path activation to finish, risking

Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On Mon, Nov 02 2015 at 8:56am -0500, Hannes Reinecke wrote: > On 11/02/2015 02:31 PM, Mike Snitzer wrote: > > On Mon, Nov 02 2015 at 2:28am -0500, > > Hannes Reinecke wrote: > > > >> On 10/31/2015 11:47 PM, Mike Snitzer wrote: > >>> > >>> For Hannes, and in my

Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On 11/02/2015 03:12 PM, Mike Snitzer wrote: > On Mon, Nov 02 2015 at 8:56am -0500, > Hannes Reinecke wrote: > >> On 11/02/2015 02:31 PM, Mike Snitzer wrote: >>> On Mon, Nov 02 2015 at 2:28am -0500, >>> Hannes Reinecke wrote: >>> On 10/31/2015 11:47 PM, Mike

Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On 11/02/2015 03:52 PM, Paolo Bonzini wrote: > > > On 02/11/2015 14:56, Hannes Reinecke wrote: >> But then the real question remains: >> >> What is the 'correct' behaviour for ioctls when no path retry >> is active (or when no paths are present)? >> >> Should we start path activation? >> If so,

Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On Mon, Nov 02 2015 at 9:36am -0500, Hannes Reinecke wrote: > On 11/02/2015 03:12 PM, Mike Snitzer wrote: > > On Mon, Nov 02 2015 at 8:56am -0500, > > Hannes Reinecke wrote: > > > >> On 11/02/2015 02:31 PM, Mike Snitzer wrote: > >>> On Mon, Nov 02 2015 at 2:28am

RE: [PATCH 0/12] megaraid_sas : Updates for scsi for-next

> -Original Message- > From: Martin K. Petersen [mailto:martin.peter...@oracle.com] > Sent: Tuesday, November 03, 2015 9:35 AM > To: sumit.sax...@avagotech.com > Cc: linux-scsi@vger.kernel.org; the...@redhat.com; > martin.peter...@oracle.com; h...@infradead.org; jbottom...@parallels.com; >

RE: [PATCH v6 01/15] scsi: ufs: clear UTRD, UPIU req and rsp before new transfers

> + cdb_len = min_t(unsigned short, lrbp->cmd->cmd_len, MAX_CDB_SIZE); > + memcpy(ucd_req_ptr->sc.cdb, lrbp->cmd->cmnd, cdb_len); > + if (cdb_len < MAX_CDB_SIZE) > + memset(ucd_req_ptr->sc.cdb + cdb_len, 0, > +(MAX_CDB_SIZE - cdb_len)); It's just 16

[PATCH v2 7/9] pm80xx: wait a minimum of 500ms before issuing commands to SPCv

The documentation for the 8070 and 8072 SPCv chip explicitly states that a minimum of 500ms must elapse before issuing commands, otherwise the SPCv may not process them and the firmware may get into an unrecoverable state requiring a reboot. While the Linux guys will probably think this is

Re: [PATCH v2 27/32] scsi: hisi_sas: add smp protocol support

On Monday 02 November 2015 17:03:58 John Garry wrote: > > > > Can do. Actually sg_req seems only ever has one element: > > expander.c, smp_execute_task() > > sg_init_one(>smp_task.smp_req, req, req_size); > > > > > I tried replacing with dma_map_single, but I feel the code is not as > clean as I

[PATCH v2 4/9] pm80xx: add support for ATTO devices during SAS address initiailization

ATTO SAS controllers retrieve the SAS address from the NVRAM in a location different from non-ATTO PMC Sierra SAS controllers. This patch makes the necessary adjustments in order to retrieve the SAS address on these types of adapters. Signed-off-by: Benjamin Rood --- Changes

Re: [PATCH 1/3] ibmvsci: make parameters max_id and max_channel read-only

> "Laurent" == Laurent Vivier writes: Laurent> Ping ? >> this series has been reviewed and ack'ed, as SCSI maintainer, could >> you take it ? My mailbox doesn't reach quite far enough back in time to pick this up and I'd rather not have to deal with mail archive-mangled

Re: [PATCH 8/8] pm80xx: avoid a panic if MSI(X) interrupts are disabled

On 10/30/2015 03:53 PM, Benjamin Rood wrote: > If MSI(X) interrupts are disabled via the kernel command line > (pci=nomsi), the pm8001 driver will kernel panic because it does not > detect that MSI interrupts are disabled and will soldier on and attempt to > configure MSI interrupts anyways. This

Re: [PATCH 1/8] pm80xx: configure PHY settings based on subsystem vendor ID

Reviewed-by: Jack Wang Thanks Jack 2015-10-30 15:53 GMT+01:00 Benjamin Rood : > Previuosly, all PMC Sierra 80xx controllers are assumed to be a > motherboard controller, except if the subsystem vendor ID was equal to > PCI_VENDOR_ID_ADAPTEC.

Re: [PATCH 7/8] pm80xx: wait a minimum of 500ms before issuing commands to SPCv

On 10/30/2015 03:53 PM, Benjamin Rood wrote: > The documentation for the 8070 and 8072 SPCv chip explicitly states that > a minimum of 500ms must elapse before issuing commands, otherwise the > SPCv may not process them and the firmware may get into an unrecoverable > state requiring a reboot.

Re: [PATCH 7/8] pm80xx: wait a minimum of 500ms before issuing commands to SPCv

2015-10-30 15:53 GMT+01:00 Benjamin Rood : > The documentation for the 8070 and 8072 SPCv chip explicitly states that > a minimum of 500ms must elapse before issuing commands, otherwise the > SPCv may not process them and the firmware may get into an unrecoverable > state

Re: [PATCH 8/8] pm80xx: avoid a panic if MSI(X) interrupts are disabled

2015-10-30 15:53 GMT+01:00 Benjamin Rood : > If MSI(X) interrupts are disabled via the kernel command line > (pci=nomsi), the pm8001 driver will kernel panic because it does not > detect that MSI interrupts are disabled and will soldier on and attempt to > configure MSI

Re: [PATCH] pm80xx: remove the SCSI host before detaching from SAS transport

2015-10-30 21:01 GMT+01:00 Benjamin Rood : > Previously, when this module was unloaded via 'rmmod' with at least one > drive attached, the SCSI error handler thread would become stuck in an > infinite recovery loop and lockup the system, necessitating a reboot. > > Once

Re: [PATCH 2/8] pm80xx: add support for PMC Sierra 8070 and PMC Sierra 8072 SAS controllers

2015-10-30 15:53 GMT+01:00 Benjamin Rood : > These SAS controllers support speeds up to 12Gb. > > Signed-off-by: Benjamin Rood > --- > drivers/scsi/pm8001/pm8001_defs.h | 2 ++ > drivers/scsi/pm8001/pm8001_init.c | 4 +++- >

Re: [PATCH v2 27/32] scsi: hisi_sas: add smp protocol support

On 30/10/2015 16:22, John Garry wrote: On 30/10/2015 13:53, Arnd Bergmann wrote: On Monday 26 October 2015 22:14:58 John Garry wrote: + /* + * DMA-map SMP request, response buffers + */ + /* req */ + sg_req = >smp_task.smp_req; + elem = dma_map_sg(dev,

Re: [PATCH 1 22/25] hpsa: enhance device messages

On 10/30/2015 09:32 AM, Tomas Henzl wrote: RAID_UNKNOWN is used in few other places - raid_level_show for example, raid_level_show handles physical devices by using "N/A", otherwise it displays the RAID level for logical devices. Other functions avoid the use of raid_type when the drive is

Re: [PATCH] sg: Fix double-free when drives detach during SG_IO

On 15-10-31 12:57 AM, Calvin Owens wrote: In sg_common_write(), we free the block request and return -ENODEV if the device is detached in the middle of the SG_IO ioctl(). Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we end up freeing rq->cmd in the already free rq object,

Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On 02/11/2015 08:28, Hannes Reinecke wrote: > > With the original code we would need to wait for path activation > before we would be able to figure out if the ioctl is valid. > However, the callback to verify the ioctl is sd_ioctl(), which as > a first step calls scsi_verify_ioctl(). > So my

Re: IBM request to allow unprivledged ioctls [Was: Revert "dm mpath: fix stalls when handling invalid ioctls"]

On 31/10/2015 23:47, Mike Snitzer wrote: > Yes, with your commit ec8013be ("dm: do not forward ioctls from logical > volumes to the underlying device") you added protections to disallow > issuing ioctls to a partition that could impact the rest of the device. > > Given that I can see why you're

Re: Build regressions/improvements in v4.3

On Mon, Nov 2, 2015 at 12:26 PM, Geert Uytterhoeven wrote: > JFYI, when comparing v4.3[1] to v4.3-rc7[3], the summaries are: > - build errors: +4/-7 + /home/kisskb/slave/src/drivers/scsi/advansys.c: error: implicit declaration of function 'free_dma'

Re: [PATCH 1 24/25] hpsa: add in sas transport class

Hi Kevin, [auto build test ERROR on scsi/for-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Don-Brace/hpsa-updates/20151029-061230 config: i386-randconfig-b0-11030633 (attached as .config)

Re: [PATCH v9 0/8] Fix error message and present UFS variant

Hi Yaniv, On Wed, Oct 28, 2015 at 4:45 PM, Yaniv Gardi wrote: > V9: update commit message with Reviewed-by > and update commit message of patch 4/8 > > V8: add phy attributes to UFS devicetree documentation file > > V7: removed additional dead code > > V6: removed dead

Re: [PATCH] SCSI: Increase REPORT_LUNS timeout

> "Brian" == Brian King writes: Brian> This patch increases the timeout used on the REPORT_LUNS to 30 Brian> seconds. This patch solves the issue of 512 non existent LUNs Brian> showing up after this event. Applied. -- Martin K. Petersen Oracle Linux

Re: [PATCH 0/12] megaraid_sas : Updates for scsi for-next

> "sumit" == sumit saxena writes: sumit> This patch set is rebased on top of last patch set sent by me- sumit> http://marc.info/?l=linux-scsi=144102204225400=2 Please sumit> consider this patch set for next kernel release. Applied. -- Martin K. Petersen

Re: [PATCH 0/8] pm80xx: Add ATTO 12Gb HBA support and fix various issues

> "Benjamin" == Benjamin Rood writes: Benjamin> The following series of patches are primarily aimed at adding Benjamin> support for ATTO's 12Gb SAS adapters, which are based off of Benjamin> the PMC-Sierra 8070/8072 series chips. I have also addressed Benjamin>

Re: [PATCH] sg: Fix double-free when drives detach during SG_IO

> "Doug" == Douglas Gilbert writes: >> In sg_common_write(), we free the block request and return -ENODEV if >> the device is detached in the middle of the SG_IO ioctl(). >> >> Unfortunately, sg_finish_rem_req() also tries to free srp->rq, so we >> end up freeing

Re: [PATCH 1 00/25] hpsa updates

> "Don" == Don Brace writes: Don, There were several minor nits in the review comments. Please address these and repost with the relevant Reviewed-by tags added so we can get this series queued up. Thanks! -- Martin K. Petersen Oracle Linux Engineering -- To

[PATCH v2] megaraid_sas : Add locking to megasas_aen_polling

From: Glenn Watkins Under conditions of offlining drives, and rescanning the scsi host, we can get into situations that the megasas_aen_polling kthread can crash(GPF) in the megasas_aen_polling work queue: [ 1206.568641] general protection fault: [#1] SMP [