Chad Dupuis [Tue, 2 Sep 2014 18:34:58 +0000 (14:34 -0400)]
bnx2fc: fix incorrect DMA memory mapping in bnx2fc_unmap_sg_list()
This patch is based on a problem and solution from Maurizio Lombardi
where bnx2fc isn't consistent in which device struct we using for DMA
map and unmap operations. Make them consistent by using dma_sg_unmap
in bnx2fc_unmap_sg_list like bnx2fc_map_sg.
Reviewed-by: Eddie Wai <eddie.wai@broadcom.com> Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
James Smart [Wed, 3 Sep 2014 16:58:23 +0000 (12:58 -0400)]
lpfc: update lpfc version to driver version 10.4.8000.0
Update lpfc version to driver version 10.4.8000.0
Signed-off-by: James Smart <james.smart@emulex.com> Signed-off-by: Dick Kennedy <dick.kennedy@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
James Smart [Wed, 3 Sep 2014 16:58:16 +0000 (12:58 -0400)]
lpfc: fix for handling unmapped ndlp in target reset handler
Fix for handling unmapped ndlp in target reset handler
Signed-off-by: James Smart <james.smart@emulex.com> Signed-off-by: Dick Kennedy <dick.kennedy@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
James Smart [Wed, 3 Sep 2014 16:58:06 +0000 (12:58 -0400)]
lpfc: fix low priority issues from fortify source code scan
Fixed Low priority issues from lpfc given by fortify source code scan.
Signed-off-by: James Smart <james.smart@emulex.com> Signed-off-by: Dick Kennedy <dick.kennedy@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
James Smart [Wed, 3 Sep 2014 16:57:55 +0000 (12:57 -0400)]
lpfc: fix high priority issues from fortify source code scan
Fixed High priority issues from lpfc given by fortify source code scan.
Signed-off-by: James Smart <james.smart@emulex.com> Signed-off-by: Dick Kennedy <dick.kennedy@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
James Smart [Wed, 3 Sep 2014 16:57:43 +0000 (12:57 -0400)]
lpfc: fix crash from page fault caused by use after rport delete
Fix crash from page fault caused by use after rport delete.
Signed-off-by: James Smart <james.smart@emulex.com> Signed-off-by: Dick Kennedy <dick.kennedy@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
James Smart [Wed, 3 Sep 2014 16:57:30 +0000 (12:57 -0400)]
lpfc: fix locking issues with abort data paths
Fix locking issues with abort data paths
Signed-off-by: James Smart <james.smart@emulex.com> Signed-off-by: Dick Kennedy <dick.kennedy@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
James Smart [Wed, 3 Sep 2014 16:57:19 +0000 (12:57 -0400)]
lpfc: fix race between LOGO/PLOGI handling causing NULL pointer
Fix race between LOGO/PLOGI handling causing NULL pointer
Signed-off-by: James Smart <james.smart@emulex.com> Signed-off-by: Dick Kennedy <dick.kennedy@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
James Smart [Wed, 3 Sep 2014 16:57:08 +0000 (12:57 -0400)]
lpfc: fix IP Reset processing - wait for RDY before proceeding
Fix IP Reset processing - wait for RDY before proceeding
Signed-off-by: James Smart <james.smart@emulex.com> Signed-off-by: Dick Kennedy <dick.kennedy@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
James Smart [Wed, 3 Sep 2014 16:56:48 +0000 (12:56 -0400)]
lpfc: fix quarantined XRI recovery qualifier state in link bounce
Fix quarantined XRI recovery qualifier state in link bounce
Signed-off-by: James Smart <james.smart@emulex.com> Signed-off-by: Dick Kennedy <dick.kennedy@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
James Smart [Wed, 3 Sep 2014 16:56:40 +0000 (12:56 -0400)]
lpfc: fix discovery timeout during nameserver login
Fix discovery timeout during nameserver login
Signed-off-by: James Smart <james.smart@emulex.com> Signed-off-by: Dick Kennedy <dick.kennedy@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
lpfc: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Reviewed-by: James Smart <james.smart@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Daniel Borkmann [Wed, 3 Sep 2014 16:56:20 +0000 (12:56 -0400)]
lpfc: do not feed jiffies as random seed from lpfc driver
In prandom we have already reseeding mechanisms that trigger
periodically from a much better entropy source than just
feeding in jiffies through lpfc_mbx_cmpl_fcf_scan_read_fcf_rec()
[what a function name 8-)]. Therefore, just remove this.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Reviewed-by: James Smart <james.smart@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
To be future-proof and for better readability the time comparisons
are modified to use time_after() instead of plain, error-prone math.
Signed-off-by: Manuel Schölling <manuel.schoelling@gmx.de> Reviewed-by: James Smart <james.smart@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
[PATCH 26/55] scsi: Mark function as static in lpfc/lpfc_bsg.c
Mark function as static in lpfc/lpfc_bsg.c because it is not used
outside this file.
This eliminates the following warning in lpfc/lpfc_bsg.c:
drivers/scsi/lpfc/lpfc_bsg.c:3348:1: warning: no previous prototype for ‘lpfc_bsg_issue_mbox_cmpl’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: James Smart <james.smart@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
lpfc: mark functions as static in lpfc/lpfc_scsi.c
Mark functions as static in lpfc/lpfc_scsi.c because they are not used
outside this file.
This eliminates the following warnings in lpfc/lpfc_scsi.c:
drivers/scsi/lpfc/lpfc_scsi.c:299:1: warning: no previous prototype for ‘lpfc_change_queue_depth’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_scsi.c:795:1: warning: no previous prototype for ‘lpfc_sli4_post_scsi_sgl_list’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_scsi.c:3019:1: warning: no previous prototype for ‘lpfc_bg_crc’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_scsi.c:3035:1: warning: no previous prototype for ‘lpfc_bg_csum’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_scsi.c:3048:1: warning: no previous prototype for ‘lpfc_calc_bg_err’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: James Smart <james.smart@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
lpfc: mark functions as static in lpfc/lpfc_init.c
Mark functions as static in lpfc/lpfc_init.c because they are not used
outside this file.
This eliminates the following warning in lpfc/lpfc_init.c:
drivers/scsi/lpfc/lpfc_init.c:652:1: warning: no previous prototype for ‘lpfc_hba_init_link’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_init.c:753:1: warning: no previous prototype for ‘lpfc_hba_down_link’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_init.c:3434:1: warning: no previous prototype for ‘lpfc_sli4_fcf_redisc_wait_tmo’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: James Smart <james.smart@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
lpfc: mark functions as static in lpfc/lpfc_hbadisc.c
Mark functions as static in lpfc/lpfc_hbadisc.c because they are not
used outside this file.
This eliminates the following warnings in lpfc/lpfc_hbadisc.c:
drivers/scsi/lpfc/lpfc_hbadisc.c:2047:5: warning: no previous prototype for ‘lpfc_sli4_fcf_pri_list_add’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_hbadisc.c:2681:1: warning: no previous prototype for ‘lpfc_init_vfi_cmpl’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_hbadisc.c:4432:1: warning: no previous prototype for ‘lpfc_nlp_logo_unreg’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: James Smart <james.smart@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
[PATCH 22/55] scsi: Mark functions as static in lpfc/lpfc_sli.c
Mark functions as static in lpfc/lpfc_sli.c because they are not used
outside this file.
This eliminates the following warnings in lpfc/lpfc_sli.c:
drivers/scsi/lpfc/lpfc_sli.c:13867:1: warning: no previous prototype for ‘lpfc_sli4_alloc_xri’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_sli.c:13897:1: warning: no previous prototype for ‘__lpfc_sli4_free_xri’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_sli.c:14317:1: warning: no previous prototype for ‘lpfc_update_rcv_time_stamp’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_sli.c:14786:1: warning: no previous prototype for ‘lpfc_sli4_handle_unsol_abort’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_sli.c:15331:1: warning: no previous prototype for ‘__lpfc_sli4_free_rpi’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_sli.c:15769:1: warning: no previous prototype for ‘lpfc_check_next_fcf_pri_level’ [-Wmissing-prototypes]
drivers/scsi/lpfc/lpfc_sli.c:16000:1: warning: no previous prototype for ‘lpfc_mbx_cmpl_redisc_fcf_table’ [-Wmissing-prototypes]
Signed-off-by: Rashika Kheria <rashika.kheria@gmail.com> Reviewed-by: Josh Triplett <josh@joshtriplett.org> Reviewed-by: James Smart <james.smart@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Hiral Shah [Sat, 3 May 2014 00:46:31 +0000 (17:46 -0700)]
fnic: assign FIP_ALL_FCF_MACS to fcoe_all_fcfs
1) Assgning FIP_ALL_FCF_MACS to fcoe_all_fcfs allows VLAN request to be sent
to correct Mac address for VLAN Discovery otherwise VLAN request will be
sent to invalid address hence FLOGI never happens.
2) Simplify the copy_and_format_trace_data code and log the correct Link event
for fnic control path tracing in case of link status UP->UP.
3) Increment Fnic driver version
Signed-off-by: Hiral Shah <hishah@cisco.com> Signed-off-by: Sesidhar Baddela <sebaddel@cisco.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Joe Lawrence [Tue, 26 Aug 2014 21:12:29 +0000 (17:12 -0400)]
qla2xxx: Prevent probe and board_disable race
The PCI register read checking introduced in commit fe1b806f4f71
("qla2xxx: Disable adapter when we encounter a PCI disconnect") is
active during driver probe. Hold off scheduling any board removal until
the driver probe has completed. This ensures that the the board_disable
work structure is initialized and more importantly, avoids racing
qla2x00_probe_one.
Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com> Acked-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Joe Lawrence [Tue, 26 Aug 2014 21:12:14 +0000 (17:12 -0400)]
qla2xxx: Prevent removal and board_disable race
Introduce mutual exclusion between the qla2xxx_remove_one PCI driver
callback and qla2x00_disable_board_on_pci_error, which is scheduled as
board_disable work by qla2x00_check_reg{32,16}_for_disconnect:
* Leave the driver-specific data attached to the underlying PCI device
intact in qla2x00_disable_board_on_pci_error, so that qla2x00_remove_one
has enough breadcrumbs to determine that any board_disable work has been
completed.
* In qla2xxx_remove_one, set a bit to prevent any subsequent
board_disable work from scheduling, then cancel and wait until pending
work has completed.
* Reuse the PCI device enable count check in qla2x00_remove_one to
determine if board_disable has occured. The original purpose of this
check was unnecessary since the driver remove function wasn't called
when the probe fails.
Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com> Acked-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Joe Lawrence [Tue, 26 Aug 2014 21:12:01 +0000 (17:12 -0400)]
qla2xxx: Schedule board_disable only once
There are various callers of qla2x00_check_reg{32,16}_for_disconnect
that may schedule board removal on PCI-disconnect. Test-and-set a
dedicated flag before scheduling board_disable so it is invoked only
once.
Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com> Acked-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Joe Lawrence [Tue, 26 Aug 2014 21:11:41 +0000 (17:11 -0400)]
qla2xxx: Collect PCI register checks and board_disable scheduling
Add an uint16_t variant of qla2x00_check_reg_for_disconnect and use
these routines to check and schedule a PCI-disconnected board from a
centralized place.
Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com> Acked-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Joe Lawrence [Tue, 26 Aug 2014 21:11:18 +0000 (17:11 -0400)]
qla2xxx: Use qla2x00_clear_drv_active on probe failure
Take advantage of commit fe1b806f4f71 ("qla2xxx: Refactor shutdown code
so some functionality can be reused") to remove an inlined copy of
qla2x00_clear_drv_active in the driver's probe hardware error path.
Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com> Acked-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Joe Lawrence [Tue, 26 Aug 2014 21:10:41 +0000 (17:10 -0400)]
qla2xxx: Fix shost use-after-free on device removal
Once calling scsi_host_put, be careful to not access qla_hw_data through
the Scsi_Host private data (ie, scsi_qla_host base_vha).
Fixes: fe1b806f4f71 ("qla2xxx: Refactor shutdown code so some functionality can be reused") Cc: stable@vger.kernel.org # 3.14, 3.15, 3.16 Signed-off-by: Joe Lawrence <joe.lawrence@stratus.com> Acked-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
pmcraid: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
csiostor: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() and pci_enable_msix_range()
interfaces.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Acked-by: Jayamohan Kallickal <jayamohan.kallickal@emulex.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Adam Radford [Wed, 9 Jul 2014 22:17:58 +0000 (15:17 -0700)]
megaraid_sas: Version and Changelog update
The following patch for megaraid_sas updates the driver version and
Documentation/scsi/ChangeLog.megaraid_sas.
Signed-off-by: Adam Radford <aradford@gmail.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Adam Radford [Wed, 9 Jul 2014 22:17:54 +0000 (15:17 -0700)]
megaraid_sas: Fix reset_mutex leak
The following patch for megaraid_sas fixes a reset_mutex leak in megasas_reset_fusion().
Signed-off-by: Adam Radford <aradford@gmail.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Adam Radford [Wed, 9 Jul 2014 22:17:55 +0000 (15:17 -0700)]
megaraid_sas: Remove unused variables in megasas_instance
The following patch for megaraid_sas removes some unused variables from the megasas_instance structure.
Signed-off-by: Adam Radford <aradford@gmail.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Adam Radford [Wed, 9 Jul 2014 22:17:57 +0000 (15:17 -0700)]
megaraid_sas: Add missing initial call to megasas_get_ld_vf_affiliation().
The following patch for megaraid_sas adds a missing initial call to
megasas_get_ld_vf_affiliation() at the end of megasas_probe_one().
Signed-off-by: Adam Radford <aradford@gmail.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Adam Radford [Wed, 9 Jul 2014 22:17:56 +0000 (15:17 -0700)]
megaraid_sas: Fix LD/VF affiliation parsing
The following patch for megaraid_sas fixes the LD/VF affiliation policy parsing
code to account for LD targetId's and Hidden LD's (not yet affiliated with any
Virtual Functions). This also breaks megasas_get_ld_vf_affiliation() into 2
separate functions: megasas_get_ld_vf_affiliation_111() and
megasas_get_ld_Vf_affiliation_12() to reduce indentation levels.
Signed-off-by: Adam Radford <aradford@gmail.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Douglas Gilbert [Tue, 5 Aug 2014 10:21:53 +0000 (12:21 +0200)]
scsi_debug: bump inquiry version to SPC-4, update version descriptors
Since a lot of functionality from SPC-4 is supported by this
driver (e.g. LBP and PI) then bump the default INQUIRY version
from SPC-3 to SPC-4. Also update the INQUIRY version
descriptors.
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Douglas Gilbert [Tue, 5 Aug 2014 10:20:46 +0000 (12:20 +0200)]
scsi_debug: give unit attention and other errors precedence over TSF
Give existing errors priority over the generation of Task
Set Full (TSF) errors. So that max_queue is not exceeded,
existing errors may be sent back in the invocation thread.
This is done so errors like Unit Attentions are not hidden
and lost by either max_queue exceeded or real/injected
TSFs.
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Douglas Gilbert [Tue, 5 Aug 2014 10:20:02 +0000 (12:20 +0200)]
scsi_debug: scsi_cmnd->cmnd check and casts unnecessary
This patch removes a NULL check for the scsi_cmnd::cmnd pointer
since many other instances in this driver and elsewhere assume
it is valid. Also redundant casts to 'unsigned char *' are removed
as the pointer has that type.
Signed-off-by: Douglas Gilbert <dgilbert@interlog.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Tomas Henzl [Thu, 14 Aug 2014 14:12:39 +0000 (16:12 +0200)]
hpsa: refine the pci enable/disable handling
When a second(kdump) kernel starts and the hard reset method is used
the driver calls pci_disable_device without previously enabling it,
so the kernel shows a warning -
[ 16.876248] WARNING: at drivers/pci/pci.c:1431 pci_disable_device+0x84/0x90()
[ 16.882686] Device hpsa
disabling already-disabled device
...
This patch fixes it, in addition to this I tried to balance also some other pairs
of enable/disable device in the driver.
Unfortunately I wasn't able to verify the functionality for the case of a sw reset,
because of a lack of proper hw.
Signed-off-by: Tomas Henzl <thenzl@redhat.com> Reviewed-by: Stephen M. Cameron <scameron@beardog.cce.hp.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: John Soni Jose <sony.john-n@emulex.com> Signed-off-by: Jayamohan Kallickal <jayamohan.kallickal@emulex.com> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: Christoph Hellwig <hch@lst.de>
be2iscsi: Fix processing CQE before connection resources are freed
Driver should process the completion queue entries before a connection
resources are freed. While running mixed traffic due to latency, driver
processes the CQE after the connection resources are freed. This fix
processes all the completion queue before the connection resources are
freed.
Signed-off-by: John Soni Jose <sony.john-n@emulex.com> Signed-off-by: Jayamohan Kallickal <jayamohan.kallickal@emulex.com> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: Christoph Hellwig <hch@lst.de>
During port async event driver should check if there is any boot target
configured on the adapter. Update sysfs enteries with the boot target
parameters.
Signed-off-by: Minh Tran <minhduc.tran@emulex.com> Signed-off-by: John Soni Jose <sony.john-n@emulex.com> Signed-off-by: Jayamohan Kallickal <jayamohan.kallickal@emulex.com> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: John Soni Jose <sony.john-n@emulex.com> Signed-off-by: Jayamohan Kallickal <jayamohan.kallickal@emulex.com> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: John Soni Jose <sony.john-n@emulex.com> Signed-off-by: Jayamohan Kallickal <jayamohan.kallickal@emulex.com> Reviewed-by: Mike Christie <michaelc@cs.wisc.edu> Signed-off-by: Christoph Hellwig <hch@lst.de>
Chad Dupuis [Fri, 8 Aug 2014 11:38:09 +0000 (07:38 -0400)]
qla2xxx: Remove restriction on starting remote device discovery on port update.
Limiting which port update events will allow the driver to kick off a
name server scan has been problematic in some corner cases so remove the
restriction and restore the previous semantic. Also move the link
up/down informational messages to the LOOP_UP and LOOP_DOWN events.
Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Chad Dupuis [Fri, 8 Aug 2014 11:38:08 +0000 (07:38 -0400)]
qla2xxx: Move mailbox failure messages to a default debug level.
Move the mailbox failure messages to a default debugging level so that
benign failures won't flood the system logs but will still show up if
default debug messaging is enabled (ql2xextended_error_logging=1).
Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com> Signed-off-by: Chad Dupuis <chad.dupuis@qlogic.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Rounding up to a multiple of 4 should be done using the ALIGN
macro. As a bonus, this also makes the generated code smaller.
In GetIocFacts(), sz is assigned to a few lines below without being
read in the meantime, so it is ok that it doesn't end up with the same
value as facts->FWImageSize.
Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Reviewed-by: Joe Lawrence <joe.lawrence@stratus.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
qla2xxx: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Log message code 0x00c6 preserved, although it is reported
after successful call to pci_enable_msix_range(), not before
possibly unsuccessful call to pci_enable_msix(). Consumers
of the error code should not notice the difference.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Acked-by: Chad Dupuis <chad.dupuis@qlogic.com> Cc: qla2xxx-upstream@qlogic.com Cc: linux-scsi@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: Christoph Hellwig <hch@lst.de>
mpt3sas: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Cc: Nagalakshmi Nandigama <Nagalakshmi.Nandigama@lsi.com> Cc: Sreekanth Reddy <Sreekanth.Reddy@lsi.com> Cc: support@lsi.com Cc: DL-MPTFusionLinux@lsi.com Cc: linux-scsi@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: Christoph Hellwig <hch@lst.de>
mpt2sas: Use pci_enable_msix_exact() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Reviewed-by: Tomas Henzl <thenzl@redhat.com> Cc: Nagalakshmi Nandigama <Nagalakshmi.Nandigama@lsi.com> Cc: Sreekanth Reddy <Sreekanth.Reddy@lsi.com> Cc: support@lsi.com Cc: DL-MPTFusionLinux@lsi.com Cc: linux-scsi@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: Christoph Hellwig <hch@lst.de>
megaraid: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
megaraid: Fail resume if MSI-X re-initialization failed
Currently the driver fails to analize MSI-X re-enablement
status on resuming and always assumes the success. This
update checks the MSI-X initialization result and fails
to resume if MSI-Xs re-enablement failed.
hpsa: Use pci_enable_msix_range() instead of pci_enable_msix()
As result of deprecation of MSI-X/MSI enablement functions
pci_enable_msix() and pci_enable_msi_block() all drivers
using these two interfaces need to be updated to use the
new pci_enable_msi_range() or pci_enable_msi_exact()
and pci_enable_msix_range() or pci_enable_msix_exact()
interfaces.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Acked-by: "Stephen M. Cameron" <scameron@beardog.cce.hp.com> Cc: iss_storagedev@hp.com Cc: linux-scsi@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: Christoph Hellwig <hch@lst.de>
hpsa: Fallback to MSI rather than to INTx if MSI-X failed
Currently the driver falls back to INTx mode when MSI-X
initialization failed. This is a suboptimal behaviour
for chips that also support MSI. This update changes that
behaviour and falls back to MSI mode in case MSI-X mode
initialization failed.
Signed-off-by: Alexander Gordeev <agordeev@redhat.com> Acked-by: "Stephen M. Cameron" <scameron@beardog.cce.hp.com> Cc: iss_storagedev@hp.com Cc: linux-scsi@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: Christoph Hellwig <hch@lst.de>
port_detect is only called from the module_init routine and thus implicitly
serialized, so remove the driver lock which was held over potentially
sleeping function calls.
Signed-off-by: Christoph Hellwig <hch@lst.de> Reported-by: Arthur Marsh <arthur.marsh@internode.on.net> Tested-by: Arthur Marsh <arthur.marsh@internode.on.net> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Hannes Reinecke <hare@suse.de>
scsi: balance out autopm get/put calls in scsi_sysfs_add_sdev()
SCSI Well-known logical units generally don't have any scsi driver
associated with it which means no one will call scsi_autopm_put_device()
on these wlun scsi devices and this would result in keeping the
corresponding scsi device always active (hence LLD can't be suspended as
well). Same exact problem can be seen for other scsi device representing
normal logical unit whose driver is yet to be loaded. This patch fixes
the above problem with this approach:
- make the scsi_autopm_put_device call at the end of scsi_sysfs_add_sdev
to make it balance out the get earlier in the function.
- let drivers do paired get/put calls in their probe methods.
Alan Stern [Tue, 2 Sep 2014 15:35:50 +0000 (11:35 -0400)]
scsi: don't store LUN bits in CDB[1] for USB mass-storage devices
The SCSI specification requires that the second Command Data Byte
should contain the LUN value in its high-order bits if the recipient
device reports SCSI level 2 or below. Nevertheless, some USB
mass-storage devices use those bits for other purposes in
vendor-specific commands. Currently Linux has no way to send such
commands, because the SCSI stack always overwrites the LUN bits.
Testing shows that Windows 7 and XP do not store the LUN bits in the
CDB when sending commands to a USB device. This doesn't matter if the
device uses the Bulk-Only or UAS transports (which virtually all
modern USB mass-storage devices do), as these have a separate
mechanism for sending the LUN value.
Therefore this patch introduces a flag in the Scsi_Host structure to
inform the SCSI midlayer that a transport does not require the LUN
bits to be stored in the CDB, and it makes usb-storage set this flag
for all devices using the Bulk-Only transport. (UAS is handled by a
separate driver, but it doesn't really matter because no SCSI-2 or
lower device is at all likely to use UAS.)
The patch also cleans up the code responsible for storing the LUN
value by adding a bitflag to the scsi_device structure. The test for
whether to stick the LUN value in the CDB can be made when the device
is probed, and stored for future use rather than being made over and
over in the fast path.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-by: Tiziano Bacocco <tiziano.bacocco@gmail.com> Acked-by: Martin K. Petersen <martin.petersen@oracle.com> Acked-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Add a use_cmd_list flag in struct Scsi_Host to request keeping track of
all outstanding commands per device.
Default behaviour is not to keep track of cmd_list per sdev, as this may
introduce lock contention. (overhead is more on multi-node NUMA.), and
only enable it on the two drivers that need it.
Signed-off-by: Kashyap Desai <kashyap.desai@avagotech.com> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Christoph Hellwig <hch@lst.de>
sd: Avoid sending medium write commands if device is write protected
The SYNCHRONIZE_CACHE command is a medium write command and hence can
fail when the device is write protected. Avoid sending such commands by
making sure that write-cache-enable is disabled even though the device
claim to support it.
Signed-off-by: Sujit Reddy Thumma <sthumma@codeaurora.org> Signed-off-by: Dolev Raviv <draviv@codeaurora.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by: Venkatesh Srinivas <venkateshs@google.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
Mike Christie [Wed, 3 Sep 2014 05:00:39 +0000 (00:00 -0500)]
libiscsi: fix potential buffer overrun in __iscsi_conn_send_pdu
This patches fixes a potential buffer overrun in __iscsi_conn_send_pdu.
This function is used by iscsi drivers and userspace to send iscsi PDUs/
commands. For login commands, we have a set buffer size. For all other
commands we do not support data buffers.
This was reported by Dan Carpenter here:
http://www.spinics.net/lists/linux-scsi/msg66838.html
Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Mike Christie <michaelc@cs.wisc.edu> Reviewed-by: Sagi Grimberg <sagig@mellanox.com> Signed-off-by: Christoph Hellwig <hch@lst.de>
vfs: simplify and shrink stack frame of link_path_walk()
Commit 9226b5b440f2 ("vfs: avoid non-forwarding large load after small
store in path lookup") made link_path_walk() always access the
"hash_len" field as a single 64-bit entity, in order to avoid mixed size
accesses to the members.
However, what I didn't notice was that that effectively means that the
whole "struct qstr this" is now basically redundant. We already
explicitly track the "const char *name", and if we just use "u64
hash_len" instead of "long len", there is nothing else left of the
"struct qstr".
We do end up wanting the "struct qstr" if we have a filesystem with a
"d_hash()" function, but that's a rare case, and we might as well then
just squirrell away the name and hash_len at that point.
End result: fewer live variables in the loop, a smaller stack frame, and
better code generation. And we don't need to pass in pointers variables
to helper functions any more, because the return value contains all the
relevant information. So this removes more lines than it adds, and the
source code is clearer too.
Pull crypto fixes from Herbert Xu:
"This fixes the newly added drbg generator so that it actually works on
32-bit machines. Previously the code was only tested on 64-bit and on
32-bit it overflowed and simply doesn't work"
* git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
crypto: drbg - remove check for uninitialized DRBG handle
crypto: drbg - backport "fix maximum value checks on 32 bit systems"
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull vfs fixes from Al Viro:
"double iput() on failure exit in lustre, racy removal of spliced
dentries from ->s_anon in __d_materialise_dentry() plus a bunch of
assorted RCU pathwalk fixes"
The RCU pathwalk fixes end up fixing a couple of cases where we
incorrectly dropped out of RCU walking, due to incorrect initialization
and testing of the sequence locks in some corner cases. Since dropping
out of RCU walk mode forces the slow locked accesses, those corner cases
slowed down quite dramatically.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
be careful with nd->inode in path_init() and follow_dotdot_rcu()
don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu()
fix bogus read_seqretry() checks introduced in b37199e
move the call of __d_drop(anon) into __d_materialise_unique(dentry, anon)
[fix] lustre: d_make_root() does iput() on dentry allocation failure
vfs: avoid non-forwarding large load after small store in path lookup
The performance regression that Josef Bacik reported in the pathname
lookup (see commit 99d263d4c5b2 "vfs: fix bad hashing of dentries") made
me look at performance stability of the dcache code, just to verify that
the problem was actually fixed. That turned up a few other problems in
this area.
There are a few cases where we exit RCU lookup mode and go to the slow
serializing case when we shouldn't, Al has fixed those and they'll come
in with the next VFS pull.
But my performance verification also shows that link_path_walk() turns
out to have a very unfortunate 32-bit store of the length and hash of
the name we look up, followed by a 64-bit read of the combined hash_len
field. That screws up the processor store to load forwarding, causing
an unnecessary hickup in this critical routine.
It's caused by the ugly calling convention for the "hash_name()"
function, and easily fixed by just making hash_name() fill in the whole
'struct qstr' rather than passing it a pointer to just the hash value.
With that, the profile for this function looks much smoother.
Merge branch 'parisc-3.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux
Pull parisc updates from Helge Deller:
"The most important patch is a new Light Weigth Syscall (LWS) for 8,
16, 32 and 64 bit atomic CAS operations which is required in order to
be able to implement the atomic gcc builtins on our platform.
Other than that, we wire up the seccomp, getrandom and memfd_create
syscalls, fixes a minor off-by-one bug and a wrong printk string"
* 'parisc-3.17-1' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Implement new LWS CAS supporting 64 bit operations.
parisc: Wire up seccomp, getrandom and memfd_create syscalls
parisc: dino: fix %d confusingly prefixed with 0x in format string
parisc: sys_hpux: NUL terminator is one past the end
Al Viro [Sun, 14 Sep 2014 01:59:43 +0000 (21:59 -0400)]
be careful with nd->inode in path_init() and follow_dotdot_rcu()
in the former we simply check if dentry is still valid after picking
its ->d_inode; in the latter we fetch ->d_inode in the same places
where we fetch dentry and its ->d_seq, under the same checks.
Cc: stable@vger.kernel.org # 2.6.38+ Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Al Viro [Sun, 14 Sep 2014 01:55:46 +0000 (21:55 -0400)]
don't bugger nd->seq on set_root_rcu() from follow_dotdot_rcu()
return the value instead, and have path_init() do the assignment. Broken by
"vfs: Fix absolute RCU path walk failures due to uninitialized seq number",
which was Cc-stable with 2.6.38+ as destination. This one should go where
it went.
To avoid dummy value returned in case when root is already set (it would do
no harm, actually, since the only caller that doesn't ignore the return value
is guaranteed to have nd->root *not* set, but it's more obvious that way),
lift the check into callers. And do the same to set_root(), to keep them
in sync.
Cc: stable@vger.kernel.org # 2.6.38+ Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Merge tag 'ntb-3.17' of git://github.com/jonmason/ntb
Pull ntb driver bugfixes from Jon Mason:
"NTB driver fixes for queue spread and buffer alignment. Also, update
to MAINTAINERS to reflect new e-mail address"
* tag 'ntb-3.17' of git://github.com/jonmason/ntb:
ntb: Add alignment check to meet hardware requirement
MAINTAINERS: update NTB info
NTB: correct the spread of queues over mw's
Merge branch 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull ARM irq chip fixes from Thomas Gleixner:
"Another pile of ARM specific irq chip fixlets:
- off by one bugs in the crossbar driver
- missing annotations
- a bunch of "make it compile" updates
I pulled the lot today from Jason, but it has been in -next for at
least a week"
* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip: gic-v3: Declare rdist as __percpu pointer to __iomem pointer
irqchip: gic: Make gic_default_routable_irq_domain_ops static
irqchip: exynos-combiner: Fix compilation error on ARM64
irqchip: crossbar: Off by one bugs in init
irqchip: gic-v3: Tag all low level accessors __maybe_unused
irqchip: gic-v3: Only define gic_peek_irq() when building SMP
Dave Jiang [Thu, 28 Aug 2014 20:53:02 +0000 (13:53 -0700)]
ntb: Add alignment check to meet hardware requirement
The NTB translate register must have the value to be BAR size aligned.
This alignment check make sure that the DMA memory allocated has the
proper alignment. Another requirement for NTB to function properly with
memory window BAR size greater or equal to 4M is to use the CMA feature
in 3.16 kernel with the appropriate CONFIG_CMA_ALIGNMENT and
CONFIG_CMA_SIZE_MBYTES set.
Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Jon Mason <jdmason@kudzu.us>
Jon Mason [Thu, 19 Jun 2014 17:11:13 +0000 (10:11 -0700)]
NTB: correct the spread of queues over mw's
The detection of an uneven number of queues on the given memory windows
was not correct. The mw_num is zero based and the mod should be
division to spread them evenly over the mw's.
Merge branches 'locking-urgent-for-linus' and 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull futex and timer fixes from Thomas Gleixner:
"A oneliner bugfix for the jinxed futex code:
- Drop hash bucket lock in the error exit path. I really could slap
myself for intruducing that bug while fixing all the other horror
in that code three month ago ...
and the timer department is not too proud about the following fixes:
- Deal with a long standing rounding bug in the timeval to jiffies
conversion. It's a real issue and this fix fell through the cracks
for quite some time.
- Another round of alarmtimer fixes. Finally this code gets used
more widely and the subtle issues hidden for quite some time are
noticed and fixed. Nothing really exciting, just the itty bitty
details which bite the serious users here and there"
* 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
futex: Unlock hb->lock in futex_wait_requeue_pi() error path
* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
alarmtimer: Lock k_itimer during timer callback
alarmtimer: Do not signal SIGEV_NONE timers
alarmtimer: Return relative times in timer_gettime
jiffies: Fix timeval conversion to jiffies
Josef Bacik found a performance regression between 3.2 and 3.10 and
narrowed it down to commit bfcfaa77bdf0 ("vfs: use 'unsigned long'
accesses for dcache name comparison and hashing"). He reports:
On xfs on a fio card this goes at about 20k dir/sec with 3.2, and 12k
dir/sec with 3.10. This is because we spend waaaaay more time in
__d_lookup on 3.10 than in 3.2.
The new hashing function for strings is suboptimal for <
sizeof(unsigned long) string names (and hell even > sizeof(unsigned
long) string names that I've tested). I broke out the old hashing
function and the new one into a userspace helper to get real numbers
and this is what I'm getting:
Old hash table had 1000000 entries, 0 dupes, 0 max dupes
New hash table had 12628 entries, 987372 dupes, 900 max dupes
We had 11400 buckets with a p50 of 30 dupes, p90 of 240 dupes, p99 of 567 dupes for the new hash
My test does the hash, and then does the d_hash into a integer pointer
array the same size as the dentry hash table on my system, and then
just increments the value at the address we got to see how many
entries we overlap with.
As you can see the old hash function ended up with all 1 million
entries in their own bucket, whereas the new one they are only
distributed among ~12.5k buckets, which is why we're using so much
more CPU in __d_lookup".
The reason for this hash regression is two-fold:
- On 64-bit architectures the down-mixing of the original 64-bit
word-at-a-time hash into the final 32-bit hash value is very
simplistic and suboptimal, and just adds the two 32-bit parts
together.
In particular, because there is no bit shuffling and the mixing
boundary is also a byte boundary, similar character patterns in the
low and high word easily end up just canceling each other out.
- the old byte-at-a-time hash mixed each byte into the final hash as it
hashed the path component name, resulting in the low bits of the hash
generally being a good source of hash data. That is not true for the
word-at-a-time case, and the hash data is distributed among all the
bits.
The fix is the same in both cases: do a better job of mixing the bits up
and using as much of the hash data as possible. We already have the
"hash_32|64()" functions to do that.
Reported-by: Josef Bacik <jbacik@fb.com> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@infradead.org> Cc: Chris Mason <clm@fb.com> Cc: linux-fsdevel@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Make hash_64() use a 64-bit multiply when appropriate
The hash_64() function historically does the multiply by the
GOLDEN_RATIO_PRIME_64 number with explicit shifts and adds, because
unlike the 32-bit case, gcc seems unable to turn the constant multiply
into the more appropriate shift and adds when required.
However, that means that we generate those shifts and adds even when the
architecture has a fast multiplier, and could just do it better in
hardware.
Use the now-cleaned-up CONFIG_ARCH_HAS_FAST_MULTIPLIER (together with
"is it a 64-bit architecture") to decide whether to use an integer
multiply or the explicit sequence of shift/add instructions.
Make ARCH_HAS_FAST_MULTIPLIER a real config variable
It used to be an ad-hoc hack defined by the x86 version of
<asm/bitops.h> that enabled a couple of library routines to know whether
an integer multiply is faster than repeated shifts and additions.
This just makes it use the real Kconfig system instead, and makes x86
(which was the only architecture that did this) select the option.
NOTE! Even for x86, this really is kind of wrong. If we cared, we would
probably not enable this for builds optimized for netburst (P4), where
shifts-and-adds are generally faster than multiplies. This patch does
*not* change that kind of logic, though, it is purely a syntactic change
with no code changes.
This was triggered by the fact that we have other places that really
want to know "do I want to expand multiples by constants by hand or
not", particularly the hash generation code.
Merge tag 'dm-3.17-fix2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fix from Mike Snitzer:
"Fix a race in the DM cache target that caused dirty blocks to be
marked as clean. This could cause no writeback to occur or spurious
dirty block counts"
* tag 'dm-3.17-fix2' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm cache: fix race causing dirty blocks to be marked as clean
Merge branch 'for-linus' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
"A small collection of fixes for the current rc series. This contains:
- Two small blk-mq patches from Rob Elliott, cleaning up error case
at init time.
- A fix from Ming Lei, fixing SG merging for blk-mq where
QUEUE_FLAG_SG_NO_MERGE is the default.
- A dev_t minor lifetime fix from Keith, fixing an issue where a
minor might be reused before all references to it were gone.
- Fix from Alan Stern where an unbalanced queue bypass caused SCSI
some headaches when it does a series of add/del on devices without
fully registrering the queue.
- A fix from me for improving the scaling of tag depth in blk-mq if
we are short on memory"
* 'for-linus' of git://git.kernel.dk/linux-block:
blk-mq: scale depth and rq map appropriate if low on memory
Block: fix unbalanced bypass-disable in blk_register_queue
block: Fix dev_t minor allocation lifetime
blk-mq: cleanup after blk_mq_init_rq_map failures
blk-mq: pass along blk_mq_alloc_tag_set return values
blk-merge: fix blk_recount_segments
Merge tag 'stable/for-linus-3.17-b-rc4-arm-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull Xen ARM bugfix from Stefano Stabellini:
"The patches fix the "xen_add_mach_to_phys_entry: cannot add" bug that
has been affecting xen on arm and arm64 guests since 3.16. They
require a few hypervisor side changes that just went in xen-unstable.
A couple of days ago David sent out a pull request with a few other
Xen fixes (it is already in master). Sorry we didn't synchronized
better among us"
* tag 'stable/for-linus-3.17-b-rc4-arm-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/arm: remove mach_to_phys rbtree
xen/arm: reimplement xen_dma_unmap_page & friends
xen/arm: introduce XENFEAT_grant_map_identity
Richard Larocque [Wed, 10 Sep 2014 01:31:05 +0000 (18:31 -0700)]
alarmtimer: Lock k_itimer during timer callback
Locks the k_itimer's it_lock member when handling the alarm timer's
expiry callback.
The regular posix timers defined in posix-timers.c have this lock held
during timout processing because their callbacks are routed through
posix_timer_fn(). The alarm timers follow a different path, so they
ought to grab the lock somewhere else.
Cc: stable@vger.kernel.org Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Sharvil Nanavati <sharvil@google.com> Signed-off-by: Richard Larocque <rlarocque@google.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
Richard Larocque [Wed, 10 Sep 2014 01:31:04 +0000 (18:31 -0700)]
alarmtimer: Do not signal SIGEV_NONE timers
Avoids sending a signal to alarm timers created with sigev_notify set to
SIGEV_NONE by checking for that special case in the timeout callback.
The regular posix timers avoid sending signals to SIGEV_NONE timers by
not scheduling any callbacks for them in the first place. Although it
would be possible to do something similar for alarm timers, it's simpler
to handle this as a special case in the timeout.
Prior to this patch, the alarm timer would ignore the sigev_notify value
and try to deliver signals to the process anyway. Even worse, the
sanity check for the value of sigev_signo is skipped when SIGEV_NONE was
specified, so the signal number could be bogus. If sigev_signo was an
unitialized value (as it often would be if SIGEV_NONE is used), then
it's hard to predict which signal will be sent.
Cc: stable@vger.kernel.org Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Sharvil Nanavati <sharvil@google.com> Signed-off-by: Richard Larocque <rlarocque@google.com> Signed-off-by: John Stultz <john.stultz@linaro.org>
Richard Larocque [Wed, 10 Sep 2014 01:31:03 +0000 (18:31 -0700)]
alarmtimer: Return relative times in timer_gettime
Returns the time remaining for an alarm timer, rather than the time at
which it is scheduled to expire. If the timer has already expired or it
is not currently scheduled, the it_value's members are set to zero.
This new behavior matches that of the other posix-timers and the POSIX
specifications.
This is a change in user-visible behavior, and may break existing
applications. Hopefully, few users rely on the old incorrect behavior.
Cc: stable@vger.kernel.org Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@kernel.org> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Cc: Sharvil Nanavati <sharvil@google.com> Signed-off-by: Richard Larocque <rlarocque@google.com>
[jstultz: minor style tweak] Signed-off-by: John Stultz <john.stultz@linaro.org>
Andrew Hunter [Thu, 4 Sep 2014 21:17:16 +0000 (14:17 -0700)]
jiffies: Fix timeval conversion to jiffies
timeval_to_jiffies tried to round a timeval up to an integral number
of jiffies, but the logic for doing so was incorrect: intervals
corresponding to exactly N jiffies would become N+1. This manifested
itself particularly repeatedly stopping/starting an itimer:
would add a full tick to val, _even if it was exactly representable in
terms of jiffies_ (say, the result of a previous rounding.) Doing
this repeatedly would cause unbounded growth in val. So fix the math.
Here's what was wrong with the conversion: we essentially computed
(eliding seconds)
jiffies = usec * (NSEC_PER_USEC/TICK_NSEC)
by using scaling arithmetic, which took the best approximation of
NSEC_PER_USEC/TICK_NSEC with denominator of 2^USEC_JIFFIE_SC =
x/(2^USEC_JIFFIE_SC), and computed:
jiffies = (usec * x) >> USEC_JIFFIE_SC
and rounded this calculation up in the intermediate form (since we
can't necessarily exactly represent TICK_NSEC in usec.) But the
scaling arithmetic is a (very slight) *over*approximation of the true
value; that is, instead of dividing by (1 usec/ 1 jiffie), we
effectively divided by (1 usec/1 jiffie)-epsilon (rounding
down). This would normally be fine, but we want to round timeouts up,
and we did so by adding 2^USEC_JIFFIE_SC - 1 before the shift; this
would be fine if our division was exact, but dividing this by the
slightly smaller factor was equivalent to adding just _over_ 1 to the
final result (instead of just _under_ 1, as desired.)
In particular, with HZ=1000, we consistently computed that 10000 usec
was 11 jiffies; the same was true for any exact multiple of
TICK_NSEC.
We could possibly still round in the intermediate form, adding
something less than 2^USEC_JIFFIE_SC - 1, but easier still is to
convert usec->nsec, round in nanoseconds, and then convert using
time*spec*_to_jiffies. This adds one constant multiplication, and is
not observably slower in microbenchmarks on recent x86 hardware.
Tested: the following program:
int main() {
struct itimerval zero = {{0, 0}, {0, 0}};
/* Initially set to 10 ms. */
struct itimerval initial = zero;
initial.it_interval.tv_usec = 10000;
setitimer(ITIMER_PROF, &initial, NULL);
/* Save and restore several times. */
for (size_t i = 0; i < 10; ++i) {
struct itimerval prev;
setitimer(ITIMER_PROF, &zero, &prev);
/* on old kernels, this goes up by TICK_USEC every iteration */
printf("previous value: %ld %ld %ld %ld\n",
prev.it_interval.tv_sec, prev.it_interval.tv_usec,
prev.it_value.tv_sec, prev.it_value.tv_usec);
setitimer(ITIMER_PROF, &prev, NULL);
}
return 0;
}
Cc: stable@vger.kernel.org Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@redhat.com> Cc: Paul Turner <pjt@google.com> Cc: Richard Cochran <richardcochran@gmail.com> Cc: Prarit Bhargava <prarit@redhat.com> Reviewed-by: Paul Turner <pjt@google.com> Reported-by: Aaron Jacobs <jacobsa@google.com> Signed-off-by: Andrew Hunter <ahh@google.com>
[jstultz: Tweaked to apply to 3.17-rc] Signed-off-by: John Stultz <john.stultz@linaro.org>
Thomas Gleixner [Thu, 11 Sep 2014 21:44:35 +0000 (23:44 +0200)]
futex: Unlock hb->lock in futex_wait_requeue_pi() error path
futex_wait_requeue_pi() calls futex_wait_setup(). If
futex_wait_setup() succeeds it returns with hb->lock held and
preemption disabled. Now the sanity check after this does:
if (match_futex(&q.key, &key2)) {
ret = -EINVAL;
goto out_put_keys;
}
which releases the keys but does not release hb->lock.
So we happily return to user space with hb->lock held and therefor
preemption disabled.
Unlock hb->lock before taking the exit route.
Reported-by: Dave "Trinity" Jones <davej@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Davidlohr Bueso <dave@stgolabs.net> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: stable@vger.kernel.org Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1409112318500.4178@nanos Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Merge tag 'char-misc-3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc
Pull char/misc driver fix from Greg KH:
"Here is one misc driver fix for 3.17-rc5. It resolves a kernel oops
that can happen in the lattice FPGA driver if the firmware isn't
present on the system.
It's been in the linux-next tree for a while now"
* tag 'char-misc-3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
Lattice ECP3 FPGA: Check firmware pointer
Merge tag 'staging-3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging
Pull staging driver fixes from Greg KH:
"Here are 3 tiny staging driver fixes for 3.17-rc5.
Two are fixes for the imx-drm driver, resolving issues that have been
reported. The other is a memory leak fix for the Android sync driver,
due to changes that went into 3.17-rc1.
All have been in linux-next for a while"
* tag 'staging-3.17-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
android: fix reference leak in sync_fence_create
imx-drm: imx-ldb: fix NULL pointer in imx_ldb_unbind()
imx-drm: ipuv3-plane: fix ipu_plane_dpms()
projects / linux-beck.git / log