- 18 Sep, 2014 40 commits
-
-
Bart Van Assche authored
commit bcc05910 upstream. If scsi_remove_host() is invoked after a SCSI device has been blocked, if the fast_io_fail_tmo or dev_loss_tmo work gets scheduled on the workqueue executing srp_remove_work() and if an I/O request is scheduled after the SCSI device had been blocked by e.g. multipathd then the following deadlock can occur: kworker/6:1 D ffff880831f3c460 0 195 2 0x00000000 Call Trace: [<ffffffff814aafd9>] schedule+0x29/0x70 [<ffffffff814aa0ef>] schedule_timeout+0x10f/0x2a0 [<ffffffff8105af6f>] msleep+0x2f/0x40 [<ffffffff8123b0ae>] __blk_drain_queue+0x4e/0x180 [<ffffffff8123d2d5>] blk_cleanup_queue+0x225/0x230 [<ffffffffa0010732>] __scsi_remove_device+0x62/0xe0 [scsi_mod] [<ffffffffa000ed2f>] scsi_forget_host+0x6f/0x80 [scsi_mod] [<ffffffffa0002eba>] scsi_remove_host+0x7a/0x130 [scsi_mod] [<ffffffffa07cf5c5>] srp_remove_work+0x95/0x180 [ib_srp] [<ffffffff8106d7aa>] process_one_work+0x1ea/0x6c0 [<ffffffff8106dd9b>] worker_thread+0x11b/0x3a0 [<ffffffff810758bd>] kthread+0xed/0x110 [<ffffffff814b972c>] ret_from_fork+0x7c/0xb0 multipathd D ffff880096acc460 0 5340 1 0x00000000 Call Trace: [<ffffffff814aafd9>] schedule+0x29/0x70 [<ffffffff814aa0ef>] schedule_timeout+0x10f/0x2a0 [<ffffffff814ab79b>] io_schedule_timeout+0x9b/0xf0 [<ffffffff814abe1c>] wait_for_completion_io_timeout+0xdc/0x110 [<ffffffff81244b9b>] blk_execute_rq+0x9b/0x100 [<ffffffff8124f665>] sg_io+0x1a5/0x450 [<ffffffff8124fd21>] scsi_cmd_ioctl+0x2a1/0x430 [<ffffffff8124fef2>] scsi_cmd_blk_ioctl+0x42/0x50 [<ffffffffa00ec97e>] sd_ioctl+0xbe/0x140 [sd_mod] [<ffffffff8124bd04>] blkdev_ioctl+0x234/0x840 [<ffffffff811cb491>] block_ioctl+0x41/0x50 [<ffffffff811a0df0>] do_vfs_ioctl+0x300/0x520 [<ffffffff811a1051>] SyS_ioctl+0x41/0x80 [<ffffffff814b9962>] tracesys+0xd0/0xd5 Fix this by scheduling removal work on another workqueue than the transport layer timers. Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Sagi Grimberg <sagig@mellanox.com> Reviewed-by:
David Dillow <dave@thedillows.org> Cc: Sebastian Parschauer <sebastian.riemer@profitbricks.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
Kamal Mostafa <kamal@canonical.com>
-
Alex Smith authored
commit e90e6fdd upstream. On 32-bit/O32, pt_regs has a padding area at the beginning into which the syscall arguments passed via the user stack are copied. 4 arguments totalling 16 bytes are copied to offset 16 bytes into this area, however the area is only 24 bytes long. This means the last 2 arguments overwrite pt_regs->regs[{0,1}]. If a syscall function returns an error, handle_sys stores the original syscall number in pt_regs->regs[0] for syscall restart. signal.c checks whether regs[0] is non-zero, if it is it will check whether the syscall return value is one of the ERESTART* codes to see if it must be restarted. Should a syscall be made that results in a non-zero value being copied off the user stack into regs[0], and then returns a positive (non-error) value that matches one of the ERESTART* error codes, this can be mistaken for requiring a syscall restart. While the possibility for this to occur has always existed, it is made much more likely to occur by commit 46e12c07 ("MIPS: O32 / 32-bit: Always copy 4 stack arguments."), since now every syscall will copy 4 arguments and overwrite regs[0], rather than just those with 7 or 8 arguments. Since that commit, booting Debian under a 32-bit MIPS kernel almost always results in a hang early in boot, due to a wait4 syscall returning a PID that matches one of the ERESTART* codes, which then causes an incorrect restart of the syscall. The problem is fixed by increasing the size of the padding area so that arguments copied off the stack will not overwrite pt_regs->regs[{0,1}]. Signed-off-by:
Alex Smith <alex.smith@imgtec.com> Reviewed-by:
Aurelien Jarno <aurelien@aurel32.net> Tested-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Kinglong Mee authored
commit d9499a95 upstream. A memory allocation failure could cause nfsd_startup_generic to fail, in which case nfsd_users wouldn't be incorrectly left elevated. After nfsd restarts nfsd_startup_generic will then succeed without doing anything--the first consequence is likely nfs4_start_net finding a bad laundry_wq and crashing. Signed-off-by:
Kinglong Mee <kinglongmee@gmail.com> Fixes: 4539f149 "nfsd: replace boolean nfsd_up flag by users counter" Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Wolfram Sang authored
commit 28772ac8 upstream. dma_{un}map_* uses 'enum dma_data_direction' not 'enum dma_transfer_direction'. Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Acked-by:
Ludovic Desroches <ludovic.desroches@atmel.com> Signed-off-by:
-
Paul Moore authored
commit d960a618 upstream. The two NetLabel LSM secattr catmap walk functions didn't handle certain edge conditions correctly, causing incorrect security labels to be generated in some cases. This patch corrects these problems and converts the functions to use the new _netlbl_secattr_catmap_getnode() function in order to reduce the amount of repeated code. Signed-off-by:
Paul Moore <pmoore@redhat.com> Tested-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
-
Paul Moore authored
commit 4b8feff2 upstream. The NetLabel secattr catmap functions, and the SELinux import/export glue routines, were broken in many horrible ways and the SELinux glue code fiddled with the NetLabel catmap structures in ways that we probably shouldn't allow. At some point this "worked", but that was likely due to a bit of dumb luck and sub-par testing (both inflicted by yours truly). This patch corrects these problems by basically gutting the code in favor of something less obtuse and restoring the NetLabel abstractions in the SELinux catmap glue code. Everything is working now, and if it decides to break itself in the future this code will be much easier to debug than the code it replaces. One noteworthy side effect of the changes is that it is no longer necessary to allocate a NetLabel catmap before calling one of the NetLabel APIs to set a bit in the catmap. NetLabel will automatically allocate the catmap nodes when needed, resulting in less allocations when the lowest bit is greater than 255 and less code in the LSMs. Reported-by:
Christian Evans <frodox@zoho.com> Signed-off-by:
-
Paul Moore authored
commit 41c3bd20 upstream. The NetLabel category (catmap) functions have a problem in that they assume categories will be set in an increasing manner, e.g. the next category set will always be larger than the last. Unfortunately, this is not a valid assumption and could result in problems when attempting to set categories less than the startbit in the lowest catmap node. In some cases kernel panics and other nasties can result. This patch corrects the problem by checking for this and allocating a new catmap node instance and placing it at the front of the list. Reported-by:
-
Jeremy Vial authored
commit 9b5f7428 upstream. According to the comment “restore_es3: applies to 34xx >= ES3.0" in "arch/arm/mach-omap2/sleep34xx.S”, omap3_restore_es3 should be used if the revision of an OMAP34xx is ES3.1.2. Signed-off-by:
Jeremy Vial <jvial@adeneo-embedded.com> Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Eric W. Biederman authored
commit db181ce0 upstream. Kenton Varda <kenton@sandstorm.io> discovered that by remounting a read-only bind mount read-only in a user namespace the MNT_LOCK_READONLY bit would be cleared, allowing an unprivileged user to the remount a read-only mount read-write. Upon review of the code in remount it was discovered that the code allowed nosuid, noexec, and nodev to be cleared. It was also discovered that the code was allowing the per mount atime flags to be changed. The first naive patch to fix these issues contained the flaw that using default atime settings when remounting a filesystem could be disallowed. To avoid this problems in the future add tests to ensure unprivileged remounts are succeeding and failing at the appropriate times. Acked-by:
Serge E. Hallyn <serge.hallyn@ubuntu.com> Signed-off-by:
"Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by:
-
Jeffrey Deans authored
commit ffc8415a upstream. A GIC interrupt which is declared as having a GIC_MAP_TO_NMI_MSK mapping causes the cpu parameter to gic_setup_intr() to be increased to 32, causing memory corruption when pcpu_masks[] is written to again later in the function. Signed-off-by:
Jeffrey Deans <jeffrey.deans@imgtec.com> Signed-off-by:
Markos Chandras <markos.chandras@imgtec.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7375/Signed-off-by:
-
Axel Lin authored
commit cf44819c upstream. Ensure mutex lock protects the read-modify-write period to prevent possible race condition bug. In additional, update data->valid should also be protected by the mutex lock. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Guenter Roeck authored
commit 1074d683 upstream. On platforms with sizeof(int) < sizeof(long), writing a temperature limit larger than MAXINT will result in unpredictable limit values written to the chip. Avoid auto-conversion from long to int to fix the problem. Cc: Axel Lin <axel.lin@ingics.com> Reviewed-by:
-
Guenter Roeck authored
commit 3248c3b7 upstream. Temperature limit register writes did not account for negative numbers. As a result, writing -127000 resulted in -126000 written into the temperature limit register. This problem affected temp[1-3]_min, temp[1-3]_max, temp[1-3]_auto_temp_crit, and temp[1-3]_auto_temp_min. When writing pwm[1-3]_freq, a long variable was auto-converted into an int without range check. Wiring values larger than MAXINT resulted in unexpected register values. When writing temp[1-3]_auto_temp_max, an unsigned long variable was auto-converted into an int without range check. Writing values larger than MAXINT resulted in unexpected register values. vrm is an u8, so the written value needs to be limited to [0, 255]. Cc: Axel Lin <axel.lin@ingics.com> Reviewed-by:
-
Theodore Ts'o authored
commit 86f0afd4 upstream. If there is a failure while allocating the preallocation structure, a number of blocks can end up getting marked in the in-memory buddy bitmap, and then not getting released. This can result in the following corruption getting reported by the kernel: EXT4-fs error (device sda3): ext4_mb_generate_buddy:758: group 1126, 12793 clusters in bitmap, 12729 in gd In that case, we need to release the blocks using mb_free_blocks(). Tested: fs smoke test; also demonstrated that with injected errors, the file system is no longer getting corrupted Google-Bug-Id: 16657874 Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
-
NeilBrown authored
commit 2446dba0 upstream. Currently we don't abort recovery on a write error if the write error to the recovering device was triggerd by normal IO (as opposed to recovery IO). This means that for one bitmap region, the recovery might write to the recovering device for a few sectors, then not bother for subsequent sectors (as it never writes to failed devices). In this case the bitmap bit will be cleared, but it really shouldn't. The result is that if the recovering device fails and is then re-added (after fixing whatever hardware problem triggerred the failure), the second recovery won't redo the region it was in the middle of, so some of the device will not be recovered properly. If we abort the recovery, the region being processes will be cancelled (bit not cleared) and the whole region will be retried. As the bug can result in data corruption the patch is suitable for -stable. For kernels prior to 3.11 there is a conflict in raid10.c which will require care. Original-from: jiao hui <jiaohui@bwstor.com.cn> Reported-and-tested-by:
jiao hui <jiaohui@bwstor.com.cn> Signed-off-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Alex Smith authored
commit c23b3d1a upstream. Commit 6a9c001b ("MIPS: Switch ELF core dumper to use regsets.") switched the core dumper to use regsets, however the GP regset code simply makes a direct copy of the kernel's pt_regs, which does not match the original core dump register layout as defined in asm/reg.h. Furthermore, the definition of pt_regs can vary with certain Kconfig variables, therefore the GP regset can never be relied upon to return registers in the same layout. Therefore, this patch changes the GP regset to match the original core dump layout. The layout differs for 32- and 64-bit processes, so separate implementations of the get/set functions are added for the 32- and 64-bit regsets. Signed-off-by:
Alex Smith <alex@alex-smith.me.uk> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/7452/Signed-off-by:
-
Alex Smith authored
commit bcec7c8d upstream. Get rid of the WANT_COMPAT_REG_H test and instead define both the 32- and 64-bit register offset definitions at the same time with MIPS{32,64}_ prefixes, then define the existing EF_* names to the correct definitions for the kernel's bitness. This patch is a prerequisite of the following bug fix patch. Signed-off-by:
-
Alex Smith authored
commit 65768a1a upstream. task_user_regset_view() should test for TIF_32BIT_REGS in the flags of the specified task, not of the current task. Signed-off-by:
-
Huacai Chen authored
commit 2e5767a2 upstream. In do_ade(), is_fpu_owner() isn't preempt-safe. For example, when an unaligned ldc1 is executed, do_cpu() is called and then FPU will be enabled (and TIF_USEDFPU will be set for the current process). Then, do_ade() is called because the access is unaligned. If the current process is preempted at this time, TIF_USEDFPU will be cleard. So when the process is scheduled again, BUG_ON(!is_fpu_owner()) is triggered. This small program can trigger this BUG in a preemptible kernel: int main (int argc, char *argv[]) { double u64[2]; while (1) { asm volatile ( ".set push \n\t" ".set noreorder \n\t" "ldc1 $f3, 4(%0) \n\t" ".set pop \n\t" ::"r"(u64): ); } return 0; } V2: Remove the BUG_ON() unconditionally due to Paul's suggestion. Signed-off-by:
Huacai Chen <chenhc@lemote.com> Signed-off-by:
Jie Chen <chenj@lemote.com> Signed-off-by:
Rui Wang <wangr@lemote.com> Cc: John Crispin <john@phrozen.org> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Signed-off-by:
-
Paolo Bonzini authored
commit 0f6c0a74 upstream. Currently, the EOI exit bitmap (used for APICv) does not include interrupts that are masked. However, this can cause a bug that manifests as an interrupt storm inside the guest. Alex Williamson reported the bug and is the one who really debugged this; I only wrote the patch. :) The scenario involves a multi-function PCI device with OHCI and EHCI USB functions and an audio function, all assigned to the guest, where both USB functions use legacy INTx interrupts. As soon as the guest boots, interrupts for these devices turn into an interrupt storm in the guest; the host does not see the interrupt storm. Basically the EOI path does not work, and the guest continues to see the interrupt over and over, even after it attempts to mask it at the APIC. The bug is only visible with older kernels (RHEL6.5, based on 2.6.32 with not many changes in the area of APIC/IOAPIC handling). Alex then tried forcing bit 59 (corresponding to the USB functions' IRQ) on in the eoi_exit_bitmap and TMR, and things then work. What happens is that VFIO asserts IRQ11, then KVM recomputes the EOI exit bitmap. It does not have set bit 59 because the RTE was masked, so the IOAPIC never sees the EOI and the interrupt continues to fire in the guest. My guess was that the guest is masking the interrupt in the redirection table in the interrupt routine, i.e. while the interrupt is set in a LAPIC's ISR, The simplest fix is to ignore the masking state, we would rather have an unnecessary exit rather than a missed IRQ ACK and anyway IOAPIC interrupts are not as performance-sensitive as for example MSIs. Alex tested this patch and it fixed his bug. [Thanks to Alex for his precise description of the problem and initial debugging effort. A lot of the text above is based on emails exchanged with him.] Reported-by:
Alex Williamson <alex.williamson@redhat.com> Tested-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Paul Burton authored
commit b1442d39 upstream. If one or more matching FCSR cause & enable bits are set in saved thread context then when that context is restored the kernel will take an FP exception. This is of course undesirable and considered an oops, leading to the kernel writing a backtrace to the console and potentially rebooting depending upon the configuration. Thus the kernel avoids this situation by clearing the cause bits of the FCSR register when handling FP exceptions and after emulating FP instructions. However the kernel does not prevent userland from setting arbitrary FCSR cause & enable bits via ptrace, using either the PTRACE_POKEUSR or PTRACE_SETFPREGS requests. This means userland can trivially cause the kernel to oops on any system with an FPU. Prevent this from happening by clearing the cause bits when writing to the saved FCSR context via ptrace. This problem appears to exist at least back to the beginning of the git era in the PTRACE_POKEUSR case. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Paul Burton <paul.burton@imgtec.com> Patchwork: https://patchwork.linux-mips.org/patch/7438/Signed-off-by:
-
Huacai Chen authored
commit 8393c524 upstream. In commit 2c8c53e2 (MIPS: Optimize TLB handlers for Octeon CPUs) build_r4000_tlb_refill_handler() is modified. But it doesn't compatible with the original code in HUGETLB case. Because there is a copy & paste error and one line of code is missing. It is very easy to produce a bug with LTP's hugemmap05 test. Signed-off-by:
Binbin Zhou <zhoubb@lemote.com> Cc: John Crispin <john@phrozen.org> Cc: Steven J. Hill <Steven.Hill@imgtec.com> Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang <zhangfx@lemote.com> Cc: Zhangjin Wu <wuzhangjin@gmail.com> Patchwork: https://patchwork.linux-mips.org/patch/7496/Signed-off-by:
-
Hui Wang authored
commit 7440850c upstream. ON the machine, two pin complex (0xb and 0xe) are both routed to the same external right-side mic jack, this makes the jack can't work. To fix this problem, set the 0xe to "not connected". BugLink: https://bugs.launchpad.net/bugs/1350148Tested-by:
Franz Hsieh <franz.hsieh@canonical.com> Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Axel Lin authored
commit 56de1377 upstream. Current code uses channel as array index, so the valid channel value is 0 .. ADS1015_CHANNELS - 1. Signed-off-by:
-
Janusz Dziemidowicz authored
commit 0213436a upstream. Some devices don't like REPORT SUPPORTED OPERATION CODES and will simply timeout causing sd_mod init to take a very very long time. Introduce BLIST_NO_RSOC scsi scan flag, that stops RSOC from being issued. Add it to Promise Vtrak E610f entry in scsi scan blacklist. Fixes bug #79901 reported at https://bugzilla.kernel.org/show_bug.cgi?id=79901 Fixes: 98dcc294 ("SCSI: sd: Update WRITE SAME heuristics") Signed-off-by:
Janusz Dziemidowicz <rraptorr@nails.eu.org> Reviewed-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Jarkko Sakkinen authored
commit 3e14d83e upstream. Regression in 41ab999c. Call to tpm_chip_put is missing. This will cause TPM device driver not to unload if tmp_get_random() is called. Signed-off-by:
Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by:
Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
-
Jason Gunthorpe authored
commit f07a5e9a upstream. Most device drivers do call 'tpm_do_selftest' which executes a TPM_ContinueSelfTest. tpm_i2c_stm_st33 is just pointlessly different, I think it is bug. These days we have the general assumption that the TPM is usable by the kernel immediately after the driver is finished, so we can no longer defer the mandatory self test to userspace. Reported-by:
Richard Marciel <rmaciel@linux.vnet.ibm.com> Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
-
Michael Welling authored
commit 46de8ff8 upstream. single-ulpi-bypass is a flag used for older OMAP3 silicon. The flag when set, can excite code that improperly uses the OMAP_UHH_HOSTCONFIG_UPLI_BYPASS define to clear the corresponding bit. Instead it clears all of the other bits disabling all of the ports in the process. Signed-off-by:
Michael Welling <mwelling@emacinc.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Thomas Petazzoni authored
commit e06871cd upstream. In commit f814f9ac ("spi/orion: add device tree binding"), Device Tree support was added to the spi-orion driver. However, this commit reads the "cell-index" property, without taking into account the fact that DT properties are big-endian encoded. Since most of the platforms using spi-orion with DT have apparently not used anything but cell-index = <0>, the problem was not visible. But as soon as one starts using cell-index = <1>, the problem becomes clearly visible, as the master->bus_num gets a wrong value (actually it gets the value 0, which conflicts with the first bus that has cell-index = <0>). This commit fixes that by using of_property_read_u32() to read the property value, which does the appropriate endianness conversion when needed. Fixes: f814f9ac ("spi/orion: add device tree binding") Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Acked-by:
Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Signed-off-by:
Mark Brown <broonie@linaro.org> Signed-off-by:
-
Paul Mackerras authored
commit ef1af2e2 upstream. This does for PR KVM what c9438092 ("KVM: PPC: Book3S HV: Take SRCU read lock around kvm_read_guest() call") did for HV KVM, that is, eliminate a "suspicious rcu_dereference_check() usage!" warning by taking the SRCU lock around the call to kvmppc_rtas_hcall(). It also fixes a return of RESUME_HOST to return EMULATE_FAIL instead, since kvmppc_h_pr() is supposed to return EMULATE_* values. Signed-off-by:
Paul Mackerras <paulus@samba.org> Signed-off-by:
Alexander Graf <agraf@suse.de> Signed-off-by:
-
Andy Lutomirski authored
commit 53b884ac upstream. This commit in Linux 3.6: commit c767a54b Author: Joe Perches <joe@perches.com> Date: Mon May 21 19:50:07 2012 -0700 x86/debug: Add KERN_<LEVEL> to bare printks, convert printks to pr_<level> caused warn_bad_vsyscall to output garbage in the middle of the line. Revert the bad part of it. The printk in question isn't actually bare; the level is "%s". The bug this fixes is purely cosmetic; backports are optional. Signed-off-by:
Andy Lutomirski <luto@amacapital.net> Link: http://lkml.kernel.org/r/03eac1f24110bbe496ecc12a4df467e0d88466d4.1406330947.git.luto@amacapital.netSigned-off-by:
H. Peter Anvin <hpa@linux.intel.com> Signed-off-by:
-
K. Y. Srinivasan authored
commit 3533f860 upstream. On some Windows hosts on FC SANs, TEST_UNIT_READY can return SRB_STATUS_ERROR. Correctly handle this. Note that there is sufficient sense information to support scsi error handling even in this case. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Reviewed-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
K. Y. Srinivasan authored
commit f885fb73 upstream. Correctly set SRB flags for all valid I/O directions. Some IHV drivers on the Windows host require this. The host validates the command and SRB flags prior to passing the command down to native driver stack. Signed-off-by:
-
K. Y. Srinivasan authored
commit 56b26e69 upstream. On Azure, we have seen instances of unbounded I/O latencies. To deal with this issue, implement handler that can reset the timeout. Note that the host gaurantees that it will respond to each command that has been issued. Signed-off-by:
-
K. Y. Srinivasan authored
commit adb6f9e1 upstream. Based on the negotiated VMBUS protocol version, we adjust the size of the storage protocol messages. The two sizes we currently handle are pre-win8 and post-win8. In WS2012 R2, we are negotiating higher VMBUS protocol version than the win8 version. Make adjustments to correctly handle this. Signed-off-by:
-
K. Y. Srinivasan authored
commit 8caf92d8 upstream. Going forward it is possible that some of the commands that are not currently implemented will be implemented on future Windows hosts. Even if they are not implemented, we are told the host will corrrectly handle unsupported commands (by returning appropriate return code and sense information). Make command filtering depend on the host version. Signed-off-by:
-
K. Y. Srinivasan authored
commit 52f9614d upstream. Set cmd_per_lun to reflect value supported by the Host. Signed-off-by:
-
K. Y. Srinivasan authored
commit 4cd83ecd upstream. Hyper-V hosts can support multiple targets and multiple channels and larger number of LUNs per target. Update the code to reflect this. With this patch we can correctly enumerate all the paths in a multi-path storage environment. Signed-off-by:
-
Stephen M. Cameron authored
commit 0758f4f7 upstream. When copy_from_user fails, return -EFAULT, not -ENOMEM Signed-off-by:
Stephen M. Cameron <scameron@beardog.cce.hp.com> Reported-by:
Robert Elliott <elliott@hp.com> Reviewed-by:
Joe Handzik <joseph.t.handzik@hp.com> Reviewed-by:
Scott Teel <scott.teel@hp.com> Reviewed by: Mike MIller <michael.miller@canonical.com> Signed-off-by:
-
Ben Hutchings authored
commit 03a6c3ff upstream. bfa_swap_words() shifts its argument (assumed to be 64-bit) by 32 bits each way. In two places the argument type is dma_addr_t, which may be 32-bit, in which case the effect of the bit shift is undefined: drivers/scsi/bfa/bfa_fcpim.c: In function 'bfa_ioim_send_ioreq': drivers/scsi/bfa/bfa_fcpim.c:2497:4: warning: left shift count >= width of type [enabled by default] addr = bfa_sgaddr_le(sg_dma_address(sg)); ^ drivers/scsi/bfa/bfa_fcpim.c:2497:4: warning: right shift count >= width of type [enabled by default] drivers/scsi/bfa/bfa_fcpim.c:2509:4: warning: left shift count >= width of type [enabled by default] addr = bfa_sgaddr_le(sg_dma_address(sg)); ^ drivers/scsi/bfa/bfa_fcpim.c:2509:4: warning: right shift count >= width of type [enabled by default] Avoid this by adding casts to u64 in bfa_swap_words(). Compile-tested only. Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Reviewed-by:
Anil Gurumurthy <anil.gurumurthy@qlogic.com> Fixes: f16a1750 ('[SCSI] bfa: remove all OS wrappers') Signed-off-by:
-
