- 05 Dec, 2017 37 commits
-
-
Colin Ian King authored
Don't populate the read-only array card_types on the stack but instead make it static and constify it. Makes the object code smaller by over 110 bytes: Before: text data bss dec hex filename 25625 5752 0 31377 7a91 drivers/scsi/wd719x.o After: text data bss dec hex filename 25447 5816 0 31263 7a1f drivers/scsi/wd719x.o (gcc version 7.2.0 x86_64) Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com>
-
Arnd Bergmann authored
There is no need to go through an intermediate timespec to convert to ktime_t when we just want a simple multiplication. This gets rid of one of the few users of jiffies_to_timespec, which I hope to remove as part of the y2038 cleanup. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Acked-by:
Douglas Gilbert <dgilbert@interlog.com> Signed-off-by:
-
Dan Carpenter authored
device->scsi3addr[] is an array, not a pointer, so it can't be NULL. I've removed the check. [mkp: fixed typo] Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Acked-by:
Don Brace <don.brace@microsemi.com> Signed-off-by:
-
James Smart authored
Update the driver version to 11.4.0.5 Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <james.smart@broadcom.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
James Smart authored
The logic for sg_seg_cnt is a bit convoluted. This patch tries to clean up a couple of areas, especially around the +2 and +1 logic. This patch: - Cleans up the lpfc_sg_seg_cnt attribute to specify a real minimum rather than making the minimum be whatever the default is. - Removes the hardcoding of +2 (for the number of elements we use in a sgl for cmd iu and rsp iu) and +1 (an additional entry to compensate for nvme's reduction of io size based on a possible partial page) logic in sg list initialization. In the case where the +1 logic is referenced in host and target io checks, use the values set in the transport template as that value was properly set. There can certainly be more done in this area and it will be addressed in combined host/target driver effort. Signed-off-by:
-
James Smart authored
During driver unload, the driver may crash due to NULL pointers. The NULL pointers were due to the driver not protecting itself sufficiently during some of the teardown paths. Additionally, the driver was not waiting for and cleanup up nvme io resources. As such, the driver wasn't making the callbacks to the transport, stalling the transports association teardown. This patch waits for io clean up before tearding down and adds checks for possible NULL pointers. Cc: <stable@vger.kernel.org> # 4.12+ Signed-off-by:
-
James Smart authored
When the driver is unloading, the nvme transport could be in the process of submitting new requests, will send abort requests to terminate associations, or may make LS-related requests. The driver's abort and request entry points currently is ignorant of the unloading state and is starting the requests even though the infrastructure to complete them continues to teardown. Change the entry points for new requests to check whether unloading and if so, reject the requests. Abort routines check unloading, and if so, noop the request. An abort is noop'd as the teardown paths are already aborting/terminating the io outstanding at the time the teardown initiated. Signed-off-by:
-
James Smart authored
The driver's interaction with the host nvme transport has been incorrect for a while. The driver did not wait for the unregister callbacks (waited only 5 jiffies). Thus the driver may remove objects that may be referenced by subsequent abort commands from the transport, and the actual unregister callback was effectively a noop. This was especially problematic if the driver was unloaded. The driver now waits for the unregister callbacks, as it should, before continuing with teardown. Signed-off-by:
-
James Smart authored
The driver currently registers any remote port that has NVME support. It should only be registering target ports. Register only target ports. Signed-off-by:
-
James Smart authored
During RSCN storms, the driver does not rediscover some targets. The driver marks some RSCN as to be handled after the ones it's working on. The driver missed processing some deferred RSCN. Move where the driver checks for deferred RSCNs and initiate deferred RSCN handling if the flag was set. Also revise nport state within the RSCN confirm routine. Add some state data to a possible debug print to aid future debugging. Signed-off-by:
-
James Smart authored
pt2pt ndlp ref count prematurely goes to 0. There was reference removed that should only be removed if connected to a switch, not if in point-to-point mode. Add a mode check before the reference remove. Signed-off-by:
-
James Smart authored
The current default for async hw receive queues is 1, which presents issues under heavy load as number of queues influence the available async receive buffer limits. Raise the default to the either the current hw limit (16) or the number of hw qs configured (io channel value). Revise the attribute definition for mrq to better reflect what we do for hw queues. E.g. 0 means default to optimal (# of cpus), non-zero specifies a specific limit. Before this change, mrq=0 meant target mode was disabled. As 0 now has a different meaning, rework the if tests to use the better nvmet_support check. Signed-off-by:
-
James Smart authored
Display for lpfc/fnX/iDiag/queInfo isn't formatted perfectly. Corrected the format strings for the queue info debug messages. Signed-off-by:
-
James Smart authored
The driver does not respond to PLOGI from the direct attach target. The driver uses incorrect S_ID in CONFIG_LINK, after FLOGI completion Correct by issuing CONFIG_LINK with the correct S_ID after receiving the PLOGI from the target Signed-off-by:
-
James Smart authored
Raise the maximum NVME sg list size allowed to 256 elements. Signed-off-by:
-
James Smart authored
Performing an LS abort results in the following message being seen: 0603 Invalid CQ subtype 6: 00000300 22000002 ffff0016 d0050000 and the associated exchange is not properly freed. The code did not recognize the exchange type that was aborted, thus it was not properly handled. Correct by adding the NVME LS ELS type to the exchange types that are recognized. Signed-off-by:
-
James Smart authored
In test cases where an instance of the driver is detached and reattached, the driver will crash on reattachment. There is a compound if statement that will skip over the bar setup if the pci_resource_start call is not successful. The driver erroneously returns success to its bar setup in this scenario even though the bars aren't properly configured. Rework the offending code segment for proper initialization steps. If the pci_resource_start call fails, -ENOMEM is now returned. Sample stack: rport-5:0-10: blocked FC remote port time out: removing rport BUG: unable to handle kernel NULL pointer dereference at (null) ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc] ... ... RIP: 0010:... ... lpfc_sli4_wait_bmbx_ready+0x32/0x70 [lpfc] Call Trace: ... lpfc_sli4_post_sync_mbox+0x106/0x4d0 [lpfc] ... ? __alloc_pages_nodemask+0x176/0x420 ... ? __kmalloc+0x2e/0x230 ... lpfc_sli_issue_mbox_s4+0x533/0x720 [lpfc] ... ? mempool_alloc+0x69/0x170 ... ? dma_generic_alloc_coherent+0x8f/0x140 ... lpfc_sli_issue_mbox+0xf/0x20 [lpfc] ... lpfc_sli4_driver_resource_setup+0xa6f/0x1130 [lpfc] ... ? lpfc_pci_probe_one+0x23e/0x16f0 [lpfc] ... lpfc_pci_probe_one+0x445/0x16f0 [lpfc] ... local_pci_probe+0x45/0xa0 ... work_for_cpu_fn+0x14/0x20 ... process_one_work+0x17a/0x440 Cc: <stable@vger.kernel.org> # 4.12+ Signed-off-by:
-
James Smart authored
XRI_ABORTED_CQE completions were not being handled in the fast path. They were being queued and deferred to the lpfc worker thread for processing. This is an artifact of the driver design prior to moving queue processing out of the isr and into a workq element. Now that queue processing is already in a deferred context, remove this artifact and process them directly. Signed-off-by:
-
James Smart authored
Hardware queues are a fast staging area to push commands into the adapter. The adapter should drain them extremely quickly. However, under heavy io load, the host cpu is pushing commands faster than the drain rate of the adapter causing the driver to resource busy commands. Enlarge the hardware queue (wq & cq) to support a larger number of queue entries (4x the prior size) before backpressure. Enlarging the queue requires larger contiguous buffers (16k) per logical page for the hardware. This changed calling sequences that were expecting 4K page sizes that now must pass a parameter with the page sizes. It also required use of a new version of an adapter command that can vary the page size values. Signed-off-by:
-
James Smart authored
When the HBA is connected to a private loop, the driver reports FLOGI loop-open failure as functional error. This is an expected condition. Mark loop-open failure as a warning instead of error. Signed-off-by:
-
Colin Ian King authored
The pointer 'port' is being assigned but it is never read, hence it is redundant and can be removed. Cleans up clang warning: drivers/scsi/bfa/bfad_attr.c:505:2: warning: Value stored to 'port' is never read. Signed-off-by:
-
Colin Ian King authored
Variable managed_request_id is being assigned but it is never read, hence it is redundant and can be removed. Cleans up clang warning: drivers/scsi/aacraid/linit.c:706:5: warning: Value stored to 'managed_request_id' is never read Signed-off-by:
-
Randy Dunlap authored
Fix kernel-doc function name and comments in st.c::read_ns_show(): change us to ns to match the function name. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
-
Randy Dunlap authored
Correct another typo I20 to I2O. Signed-off-by:
-
Greg Kroah-Hartman authored
There is no need to #define the license of the driver, just put it in the MODULE_LICENSE() line directly as a text string. This allows tools that check that the module license matches the source code license to work properly, as there is no need to unwind the unneeded dereference, especially when the string is defined in a .h file far away from the .c file it is used in. Cc: "James E.J. Bottomley" <jejb@linux.vnet.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: Varun Prakash <varun@chelsio.com> Reported-by:
Philippe Ombredanne <pombredanne@nexb.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by:
-
Arnd Bergmann authored
The TW_IOCTL_GET_LOCK ioctl uses do_gettimeofday() to check whether a lock has expired. This can misbehave due to a concurrent settimeofday() call, as it is based on 'real' time, and it will overflow in y2038 on 32-bit architectures, producing unexpected results when used across the overflow time. This changes it to using monotonic time, using ktime_get() to simplify the code. Signed-off-by:
Adam Radford <aradford@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
The calculation of the number of seconds since Sunday 00:00:00 overflows in 2106, meaning that we instead will return the seconds since Wednesday 06:28:16 afterwards. Using 64-bit time stamps avoids this slight inconsistency, and the deprecated do_gettimeofday(), replacing it with the simpler ktime_get_real_seconds(). Signed-off-by:
-
Arnd Bergmann authored
twl_aen_queue_event/twa_aen_queue_event, we use do_gettimeofday() to read the lower 32 bits of the current time in seconds, to pass them to the TW_IOCTL_GET_NEXT_EVENT ioctl or the 3ware_aen_read sysfs file. This will overflow on all architectures in year 2106, there is not much we can do about that without breaking the ABI. User space has 90 years to learn to deal with it, so it's probably ok. I'm changing it to use ktime_get_real_seconds() with a comment to document what happens when. Signed-off-by:
-
Arnd Bergmann authored
bfa_aen_entry_s is passed through a netlink socket that can be read by either 32-bit or 64-bit processes, but the data format is different between the two on current implementations. Originally, this was using a 'struct timeval', which also suffers from getting redefined with a new libc implementation. With this patch, the layout gets fixed to having two 64-bit members for the time, making it the same on 32-bit kernels and 64-bit kernels running either compat or native user space including x32. Provided that the new header file gets used to recompile any 32-bit application binaries, this will fix running those on a 64-bit kernel (with or without this patch) e.g. in a container environment, and it will make binaries work that will be built against a future 32-bit glibc that uses a 64-bit time_t, and avoid the y2038 overflow there. However, this also breaks compatibility with any existing 32-bit binary running on a native 32-bit kernel, those must be recompiled against the new header, which in turn makes them incompatible with older kernels unless the same change gets applied there. Obviously this patch should only be applied when the benefits outweigh the possible breakage. I'm posting it under the assumption that there are no open-source tools using the netlink interface, and that users of the binaries provided by qlogic for SLES10/11 and RHEL5/6 are not actually being used on new future systems with 32-bit x86 kernels. Signed-off-by:
Anil Gurumurthy <Anil.Gurumurthy@cavium.com> Signed-off-by:
-
Arnd Bergmann authored
bfa_aen_entry_s is passed to user space in a netlink message, but is defined using a 'struct timeval' and an 'enum' that are not only different between architectures, but also between 32-bit user space and 64-bit kernels they may run on, as well as depending on the particular C library that defines timeval. This changes the in-kernel definition to no longer use the timeval type directly but instead use two open-coded 'unsigned long' members. This keeps the existing ABI, but making the variable unsigned also helps make it work after y2038, until it overflows in 2106. Since the macro becomes overly complex at this point, I'm changing it to an inline function for readability. I'm not changing the 32-bit user-space ABI at this point, to keep the changes separate, I deally this would be defined using the same binary layout for all architectures. Signed-off-by:
-
Arnd Bergmann authored
The bfa_get_log_time() returns a 64-bit timestamp that does not suffer from the y2038 overflow on 64-bit systems. However, on 32-bit architectures the timestamp will jump from 0x000000007fffffff to 0xffffffff80000000 in y2038 and produce wrong results. The ktime_get_real_seconds() function does the same thing as bfa_get_log_time() without that problem, so we can simply remove the former use ktime_get_real_seconds() instead. Signed-off-by:
-
Arnd Bergmann authored
io_profile_start_time() gets read using do_gettimeofday() and passed down as a 32-bit value through multiple functions. This will overflow in y2038 or y2106, depending on whether it gets interpreted as unsigned in the end. This changes do_gettimeofday() to ktime_get_real_seconds() and pushes the point at which it overflows to where we actually assign it to the bfa_fcpim_del_itn_stats_s structure, with an appropriate comment. Signed-off-by:
-
Arnd Bergmann authored
In bfa_ioc_send_enable, we use the deprecated do_gettimeofday() function to read the current time. This is not a problem, since the firmware interface is already limited to 32-bit timestamps, but it's better to use ktime_get_seconds() and document what the limitation is. I noticed that I did the same change in commit a5af8392 ("bna: avoid writing uninitialized data into hw registers") for the ethernet driver. That commit also changed the "disable" funtion to initialize the data we pass to the firmware properly, so I'm doing the same thing here. Signed-off-by:
-
Arnd Bergmann authored
We use the deprecated do_gettimeofday() function to read the current time when resetting the statistics in both bfa_port and bfa_svc. This works fine because overflow is handled correctly, but we want to get rid of do_gettimeofday() and using a non-monotonic time suffers from concurrent settimeofday calls and other problems. This uses the ktime_get_seconds() function instead, which does what we need here. Signed-off-by:
-
Arnd Bergmann authored
BFA_TRC_TS() calculates a 32-bit microsecond timestamp using the deprecated do_gettimeofday() function. This overflows roughly every 71 minutes, so it's obviously not used as an absolute time stamp, but it seems wrong to use a time base for it that will jump during settimeofday() calls, leap seconds, or the y2038 overflow. This converts it to ktime_get_ts64(), which has none of those problems but is not synchronized to wall-clock time. Signed-off-by:
-
Gustavo A. R. Silva authored
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through. Addresses-Coverity-ID: 114988 Addresses-Coverity-ID: 114989 Addresses-Coverity-ID: 114990 Addresses-Coverity-ID: 114991 Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the swap macro and remove unnecessary variable tmp. This makes the code easier to read and maintain. This code was detected with the help of Coccinelle. Signed-off-by:
Manish Rangankar <Manish.Rangankar@cavium.com> Signed-off-by:
-
- 27 Nov, 2017 1 commit
-
-
Linus Torvalds authored
-
- 26 Nov, 2017 2 commits
-
-
git://git.armlinux.org.uk/~rmk/linux-armLinus Torvalds authored
Pull ARM fixes from Russell King: - LPAE fixes for kernel-readonly regions - Fix for get_user_pages_fast on LPAE systems - avoid tying decompressor to a particular platform if DEBUG_LL is enabled - BUG if we attempt to return to userspace but the to-be-restored PSR value keeps us in privileged mode (defeating an issue that ftracetest found) * 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm: ARM: BUG if jumping to usermode address in kernel mode ARM: 8722/1: mm: make STRICT_KERNEL_RWX effective for LPAE ARM: 8721/1: mm: dump: check hardware RO bit for LPAE ARM: make decompressor debug output user selectable ARM: fix get_user_pages_fast
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull irq fixes from Thomas Glexiner: - unbreak the irq trigger type check for legacy platforms - a handful fixes for ARM GIC v3/4 interrupt controllers - a few trivial fixes all over the place * 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: genirq/matrix: Make - vs ?: Precedence explicit irqchip/imgpdc: Use resource_size function on resource object irqchip/qcom: Fix u32 comparison with value less than zero irqchip/exiu: Fix return value check in exiu_init() irqchip/gic-v3-its: Remove artificial dependency on PCI irqchip/gic-v4: Add forward definition of struct irq_domain_ops irqchip/gic-v3: pr_err() strings should end with newlines irqchip/s3c24xx: pr_err() strings should end with newlines irqchip/gic-v3: Fix ppi-partitions lookup irqchip/gic-v4: Clear IRQ_DISABLE_UNLAZY again if mapping fails genirq: Track whether the trigger type has been set
-
