- 19 May, 2017 3 commits
-
-
Long Li authored
In lower layer driver's (LLD) scsi_host_template, the driver may optionally ask SCSI to allocate its private driver memory for each command, by specifying cmd_size. This memory is allocated at the end of scsi_cmnd by SCSI. Later when SCSI queues a command, the LLD can use scsi_cmd_priv to get to its private data. Some LLD, e.g. hv_storvsc, doesn't clear its private data before use. In this case, the LLD may get to stale or uninitialized data in its private driver memory. This may result in unexpected driver and hardware behavior. Fix this problem by also zeroing the private driver memory before passing them to LLD. Signed-off-by:
Long Li <longli@microsoft.com> Reviewed-by:
Bart Van Assche <Bart.VanAssche@sandisk.com> Reviewed-by:
KY Srinivasan <kys@microsoft.com> Reviewed-by:
Christoph Hellwig <hch@infradead.org> CC: <stable@vger.kernel.org> # 4.11+ Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Varun Prakash authored
mbp pointer is passed to csio_hw_validate_caps() so call mempool_free() after calling csio_hw_validate_caps(). Signed-off-by:
Varun Prakash <varun@chelsio.com> Fixes: 541c571f ("csiostor:Use firmware version from cxgb4/t4fw_version.h") Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
-
Michał Potomski authored
When reloading module these two attributes aren't cleaned up properly and they persist causing warnings when trying to load module again. Additionally they are not recreated properly due to that. Signed-off-by:
Michał Potomski <michalx.potomski@intel.com> Reviewed-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
-
- 18 May, 2017 2 commits
-
-
James Smart authored
fix build issue if NVME_FC_TARGET is not defined. noop the code. The code will never be invoked if target mode is not enabled. Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <james.smart@broadcom.com> Signed-off-by:
-
Guilherme G. Piccoli authored
Recent commit on patchset "lpfc updates for 11.2.0.14" fixed an issue about dereferencing a NULL pointer on port reset. The specific commit, named "lpfc: Fix system crash when port is reset.", is missing a check against NULL pointer on lpfc_els_flush_cmd() though. Since we destroy the queues on adapter resets, like in PCI error recovery path, we need the validation present on this patch in order to avoid a NULL pointer dereference when trying to flush commands of ELS wq, after it has been destroyed (which would lead to a kernel oops). Tested-by:
Raphael Silva <raphasil@linux.vnet.ibm.com> Signed-off-by:
Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Acked-by:
-
- 17 May, 2017 17 commits
-
-
James Smart authored
Change driver version to 11.2.0.14. Signed-off-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
James Smart authored
Added code to support Cisco MDS loopback diagnostic. The diagnostics run various loopbacks including one which loops-back frame through the driver. Signed-off-by:
-
James Smart authored
Code review of NVMEI's FC_PORT_ROLE_NVME_DISCOVERY looked wrong. Discussions with storage architecture team clarified NVMEI's audit of the PRLI response port roles. Following up discussion with code review showed a few minor corrections were required - especially in anticipation of NVME auto discovery. During PRLI, NVMEI should sent prli_init - which it it does. NVMET should send prli_tgt and prli_disc - which it does. When NVMEI receives a PRLI Response now, it audits the incoming target bits and stores the attributes in the corresponding NDLP. Later, when NVMEI registers the NVME rport, it uses the stored ndlp attributes to set the rport port_roles correctly. Signed-off-by:
-
James Smart authored
Too many work items being processed in IRQ context take a lot of CPU time and cause problems. With a recent change, we get out of the ISR after hitting entry_repost work items on a queue. However, the actual values for entry repost are still high. EQ is 128 and CQ is 128, this could translate into processing 128 * 128 (16384) work items under IRQ context. Set entry_repost in the actual queue creation routine now. Limit EQ repost to 8 and CQ repost to 64 to further limit the amount of time spent in the IRQ. Fix fof IRQ routines as well. Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
James Smart authored
When unloading and reloading the driver, the driver fails to recreate the lpfc root inode in the debugfs tree. The driver is incorrectly removing the lpfc root inode in lpfc_debugfs_terminate in the first driver instance that unloads and then sets the lpfc_debugfs_root global parameter to NULL. When the final driver instance unloads, the debugfs calls quietly ignore the remove on a NULL pointer. The bug is that the debugfs_remove call returns void so the driver doesn't know to correctly set the global parameter to NULL. Base the debugfs_remove of the lpfc_debugfs_root parameter on lpfc_debugfs_hba_count because this parameter tracks the fnX instance tracked per driver instance. Signed-off-by:
-
James Smart authored
When the driver send the RPA command, it does not send supported FC4 Type NVME to the management server. Encode NVME (type x28) in the AttribEntry in the RPA command. Signed-off-by:
-
James Smart authored
Previous logic would just drop the IO. Added logic to queue the IO to wait for an IO context resource from an IO thats already in progress. Signed-off-by:
-
James Smart authored
Currently IO resources are mapped 1 to 1 with RQ buffers posted Added logic to separate RQE buffers from IO op resources (sgl/iocbq/context). During initialization, the driver will determine how many SGLs it will allocate for NVMET (based on what the firmware reports) and associate a NVMET IOCBq and NVMET context structure with each one. Now that hdr/data buffers are immediately reposted back to the RQ, 512 RQEs for each MRQ is sufficient. Also, since NVMET data buffers are now 128 bytes, lpfc_nvmet_mrq_post is not necessary anymore as we will always post the max (512) buffers per NVMET MRQ. Signed-off-by:
-
James Smart authored
Using 2048 byte buffer and onle 128 bytes is needed. Create nee LFPC_NVMET_DATA_BUF_SIZE define to use for NVMET RQ/MRQs. Signed-off-by:
-
James Smart authored
After running IOPS test for 30 second we get kernel:NMI watchdog: Watchdog detected hard LOCKUP on cpu 0 The driver is speend too much time in its ISR. In ISR EQ and CQ processing routines, if we hit the entry_repost numbers of EQE/CQEs just break out of the routine as opposed to hitting the doorbell with NOARM and continue processing. Signed-off-by:
-
James Smart authored
During driver boot, a latency in the NVMET driver side causes the incoming NVMEI PRLI to get rejected by the NVMET driver. When this happens, the NVMEI driver runs out of PRLI retries. Bouncing the link does not fix the situation. If the NVMEI driver decides, on PRLI completion failures, to retry the PRLI, always decrement the fc4_prli_sent counter. This allows the PRLI completion to resolve to UNMAPPED when NVMET rejects the PRLI. Signed-off-by:
-
James Smart authored
Large block writes to the nvme target were failing because the default number of RQs posted was insufficient. Expand the NVMET RQs to 2048 RQEs and ensure a minimum of 512 RQEs are posted, no matter how many MRQs are configured. Signed-off-by:
-
James Smart authored
More debug messages added for nvme statistics. Signed-off-by:
-
James Smart authored
The driver panic when using the els_wq during port reset. Check for NULL els_wq before dereferencing. Signed-off-by:
-
James Smart authored
With 255 vports created a link trasition can casue a crash. When going through discovery after a link bounce the driver is using rpis before the cmd FCOE_POST_HDR_TEMPLATES completes. By doing that the next rpi bumps the rpi range out of the boundary. The fix it to increment the next_rpi only when the FCOE_POST_HDR_TEMPLATE succeeds. Signed-off-by:
-
Gustavo A. R. Silva authored
Previous assignment was causing the use of the uninitialized variable _explan_ inside fc_seq_ls_rjt() function, which in this particular case is being called by fc_seq_els_rsp_send(). [mkp: fixed typo] Addresses-Coverity-ID: 1398125 Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Reviewed-by:
Ewan D. Milne <emilne@redhat.com> Signed-off-by:
-
Derek Basehore authored
Some external hard drives don't support the sync command even though the hard drive has write cache enabled. In this case, upon suspend request, sync cache failures are ignored if the error code in the sense header is ILLEGAL_REQUEST. There's not much we can do for these drives, so we shouldn't fail to suspend for this error case. The drive may stay powered if that's the setup for the port it's plugged into. Signed-off-by:
Derek Basehore <dbasehore@chromium.org> Signed-off-by:
Thierry Escande <thierry.escande@collabora.com> Reviewed-by:
-
- 12 May, 2017 3 commits
-
-
Johannes Thumshirn authored
If the list search in sg_get_rq_mark() fails to find a valid request, we return a bogus element. This then can later lead to a GPF in sg_remove_scat(). So don't return bogus Sg_requests in sg_get_rq_mark() but NULL in case the list search doesn't find a valid request. Signed-off-by:
Andrey Konovalov <andreyknvl@google.com> Cc: Hannes Reinecke <hare@suse.de> Cc: Christoph Hellwig <hch@lst.de> Cc: Doug Gilbert <dgilbert@interlog.com> Reviewed-by:
Doug Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Damien Le Moal authored
For a zoned block device, sd_zbc_complete() handles zone write unlock on completion of a REQ_OP_WRITE_ZEROES command but the zone write locking is missing from sd_setup_write_zeroes_cmnd(). This patch fixes this problem by locking the target zone of a REQ_OP_WRITE_ZEROES request. Signed-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Signed-off-by:
-
Damien Le Moal authored
scsi_io_init() may fail, leaving a zone of a zoned block device locked. Fix this by properly unlocking the write same request target zone if scsi_io_init() fails. Signed-off-by:
-
- 09 May, 2017 12 commits
-
-
Colin Ian King authored
The 2nd check to see if request_size is less than zero is redundant because the first check takes error exit path on this condition. So, since it is redundant, remove it. Detected by CoverityScan, CID#146149 ("Logically Dead Code") Signed-off-by:Colin Ian King <colin.king@canonical.com> Reviewed-by:
Tyrel Datwyler <tyreld@linux.vnet.ibm.com> Signed-off-by:
-
Colin Ian King authored
I believe there is a typo on the wq destroy of els_wq, currently the driver is checking if els_cq is not null and I think this should be a check on els_wq instead. Detected by CoverityScan, CID#1411629 ("Copy-paste error") Signed-off-by: -
Guenter Roeck authored
The driver now uses IRQ_POLL and needs to select it to avoid the following build error. ERROR: ".irq_poll_complete" [drivers/scsi/cxlflash/cxlflash.ko] undefined! ERROR: ".irq_poll_sched" [drivers/scsi/cxlflash/cxlflash.ko] undefined! ERROR: ".irq_poll_disable" [drivers/scsi/cxlflash/cxlflash.ko] undefined! ERROR: ".irq_poll_init" [drivers/scsi/cxlflash/cxlflash.ko] undefined! Fixes: cba06e6d ("scsi: cxlflash: Implement IRQ polling for RRQ processing") Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Signed-off-by:
-
Kees Cook authored
Using memcpy() from a string that is shorter than the length copied means the destination buffer is being filled with arbitrary data from the kernel rodata segment. Instead, use strncpy() which will fill the trailing bytes with zeros. This was found with the future CONFIG_FORTIFY_SOURCE feature. Cc: Daniel Micay <danielmicay@gmail.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Acked-by:
Chad Dupuis <chad.dupuis@cavium.com> Signed-off-by:
-
Dan Carpenter authored
We store sc_cmd->cmnd[0] which is an unsigned char in io_log->op so this should also be unsigned char. The other thing is that this is displayed in the debugfs: seq_printf(s, "0x%02x:", io_log->op); Smatch complains that the formatting won't work for negative values so changing it to unsigned silences that warning as well. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
-
Dan Carpenter authored
There is a double lock bug here so this will deadlock instead of unlocking. Fixes: 1c5b12f7 ("Fix implicit logo and RSCN handling for NVMET") Signed-off-by:
-
Gustavo A. R. Silva authored
Properly update the position of the arguments in function call. Addresses-Coverity-ID: 1402010 Signed-off-by:
-
Bart Van Assche authored
This patch avoids that when building with W=1 the compiler complains that __scsi_init_queue() has not been declared. See also commit d48777a6 ("scsi: remove __scsi_alloc_queue"). Signed-off-by:
-
Christoph Hellwig authored
The open-osd domain doesn't exist anymore, and mails to the list lead to really annoying bounced that repeat every day. Also the primarydata address for Benny bounces, and while I have a new one for him he doesn't seem to be maintaining the OSD code any more. Which beggs the question: should we really leave the Supported status in MAINTAINERS given that the code is barely maintained? Signed-off-by:
Christoph Hellwig <hch@lst.de> Acked-by:
Jeff Layton <jlayton@redhat.com> Acked-by:
Boaz Harrosh <ooo@electrozaur.com> Acked-by:
Benny Halevy <bhalevy@gmail.com> Signed-off-by:
-
Zhou Zhengping authored
When a device is unplugged from a SCSI controller, if the scsi_device is still in use by application layer, it won't get released until users close it. In this case, scsi_device_remove just set the scsi_device's state to be SDEV_DEL. But if you plug the disk just before the old scsi_device is released, then there will be two scsi_device structures in scsi_host->__devices. When the next unplug event happens, some low-level drivers will check whether the scsi_device has been added to host (for example the MegaRAID SAS series controller) by calling scsi_device_lookup(call __scsi_device_lookup) in function megasas_aen_polling. __scsi_device_lookup will return the first scsi_device. Because its state is SDEV_DEL, the scsi_device_lookup will return NULL, making the low-level driver assume that the scsi_device has been removed, and won't call scsi_device_remove which will lead to hot swap failure. Signed-off-by:
Zhou Zhengping <johnzzpcrystal@gmail.com> Tested-by:
Zeng Rujia <ZengRujia@sangfor.com.cn> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=195607Reviewed-by:
-
James Smart authored
To select the appropriate shost template, the driver is issuing a mailbox command to retrieve the wwn. Turns out the sending of the command precedes the reset of the function. On SLI-4 adapters, this is inconsequential as the mailbox command location is specified by dma via the BMBX register. However, on SLI-3 adapters, the location of the mailbox command submission area changes. When the function is first powered on or reset, the cmd is submitted via PCI bar memory. Later the driver changes the function config to use host memory and DMA. The request to start a mailbox command is the same, a simple doorbell write, regardless of submission area. So.. if there has not been a boot driver run against the adapter, the mailbox command works as defaults are ok. But, if the boot driver has configured the card and, and if no platform pci function/slot reset occurs as the os starts, the mailbox command will fail. The SLI-3 device will use the stale boot driver dma location. This can cause PCI eeh errors. Fix is to reset the sli-3 function before sending the mailbox command, thus synchronizing the function/driver on mailbox location. Note: The fix uses routines that are typically invoked later in the call flow to reset the sli-3 device. The issue in using those routines is that the normal (non-fix) flow does additional initialization, namely the allocation of the pport structure. So, rather than significantly reworking the initialization flow so that the pport is alloc'd first, pointer checks are added to work around it. Checks are limited to the routines invoked by a sli-3 adapter (s3 routines) as this fix/early call is only invoked on a sli3 adapter. Nothing changes post the fix. Subsequent initialization, and another adapter reset, still occur - both on sli-3 and sli-4 adapters. Signed-off-by:
-
Hannes Reinecke authored
When the FCoE sending side becomes congested libfc tries to reduce the queue depth on the host; however due to the built-in lag before attempting to ramp down the queue depth _again_ the message log is flooded with the following message: libfc: queue full, reducing can_queue to 512 With this patch the message is printed only once (ie when it's actually changed). Signed-off-by:
Johannes Thumshirn <jth@kernel.org> Signed-off-by:
-
- 08 May, 2017 3 commits
-
-
git://git.kernel.org/pub/scm/virt/kvm/kvmLinus Torvalds authored
Pull KVM updates from Paolo Bonzini: "ARM: - HYP mode stub supports kexec/kdump on 32-bit - improved PMU support - virtual interrupt controller performance improvements - support for userspace virtual interrupt controller (slower, but necessary for KVM on the weird Broadcom SoCs used by the Raspberry Pi 3) MIPS: - basic support for hardware virtualization (ImgTec P5600/P6600/I6400 and Cavium Octeon III) PPC: - in-kernel acceleration for VFIO s390: - support for guests without storage keys - adapter interruption suppression x86: - usual range of nVMX improvements, notably nested EPT support for accessed and dirty bits - emulation of CPL3 CPUID faulting generic: - first part of VCPU thread request API - kvm_stat improvements" * tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (227 commits) kvm: nVMX: Don't validate disabled secondary controls KVM: put back #ifndef CONFIG_S390 around kvm_vcpu_kick Revert "KVM: Support vCPU-based gfn->hva cache" tools/kvm: fix top level makefile KVM: x86: don't hold kvm->lock in KVM_SET_GSI_ROUTING KVM: Documentation: remove VM mmap documentation kvm: nVMX: Remove superfluous VMX instruction fault checks KVM: x86: fix emulation of RSM and IRET instructions KVM: mark requests that need synchronization KVM: return if kvm_vcpu_wake_up() did wake up the VCPU KVM: add explicit barrier to kvm_vcpu_kick KVM: perform a wake_up in kvm_make_all_cpus_request KVM: mark requests that do not need a wakeup KVM: remove #ifndef CONFIG_S390 around kvm_vcpu_wake_up KVM: x86: always use kvm_make_request instead of set_bit KVM: add kvm_{test,clear}_request to replace {test,clear}_bit s390: kvm: Cpu model support for msa6, msa7 and msa8 KVM: x86: remove irq disablement around KVM_SET_CLOCK/KVM_GET_CLOCK kvm: better MWAIT emulation for guests KVM: x86: virtualize cpuid faulting ... -
git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds authored
Pull ARM updates from Russell King: "Lots of little things this time: - allow modules to be autoloaded according to the HWCAP feature bits (used primarily for crypto modules) - split module core and init PLT sections, since the core code and init code could be placed far apart, and the PLT sections need to be local to the code block. - three patches from Chris Brandt to allow Cortex-A9 L2 cache optimisations to be disabled where a SoC didn't wire up the out of band signals. - NoMMU compliance fixes, avoiding corruption of vector table which is not being used at this point, and avoiding possible register state corruption when switching mode. - fixmap memory attribute compliance update. - remove unnecessary locking from update_sections_early() - ftrace fix for DEBUG_RODATA with !FRAME_POINTER" * 'for-linus' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: 8672/1: mm: remove tasklist locking from update_sections_early() ARM: 8671/1: V7M: Preserve registers across switch from Thread to Handler mode ARM: 8670/1: V7M: Do not corrupt vector table around v7m_invalidate_l1 call ARM: 8668/1: ftrace: Fix dynamic ftrace with DEBUG_RODATA and !FRAME_POINTER ARM: 8667/3: Fix memory attribute inconsistencies when using fixmap ARM: 8663/1: wire up HWCAP/HWCAP2 feature bits to the CPU modalias ARM: 8666/1: mm: dump: Add domain to output ARM: 8662/1: module: split core and init PLT sections ARM: 8661/1: dts: r7s72100: add l2 cache ARM: 8660/1: shmobile: r7s72100: Enable L2 cache ARM: 8659/1: l2c: allow CA9 optimizations to be disabled -
git://github.com/jcmvbkbc/linux-xtensaLinus Torvalds authored
Pull Xtensa updates from Max Filippov: - clearly mark references to spilled register locations with SPILL_SLOT macros - clean up xtensa ptrace: use generic tracehooks, move internal kernel definitions from uapi/asm to asm, make locally-used functions static, fix code style and alignment - use command line parameters passed to ISS as kernel command line. * tag 'xtensa-20170507' of git://github.com/jcmvbkbc/linux-xtensa: xtensa: clean up access to spilled registers locations xtensa: use generic tracehooks xtensa: move internal ptrace definitions from uapi/asm to asm xtensa: clean up xtensa/kernel/ptrace.c xtensa: drop unused fast_io_protect function xtensa: use ITLB_HIT_BIT instead of hardcoded number xtensa: ISS: update kernel command line in platform_setup xtensa: ISS: add argc/argv simcall definitions xtensa: ISS: cleanup setup.c
-
