- 06 Apr, 2017 40 commits
-
-
Leonard Crestez authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit e42a46b6 upstream. It is allowed to call regulator_get with a NULL dev argument (_regulator_get explicitly checks for it) but this causes an error later when printing /sys/kernel/debug/regulator_summary. Fix this by explicitly handling "deviceless" consumers in the debugfs code. Signed-off-by:
Leonard Crestez <leonard.crestez@nxp.com> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Tim Gardner <tim.gardner@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Arnd Bergmann authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 6e017006 upstream. gcc-7 detects that wlanhdr_to_ethhdr() in two drivers calls memcpy() with a destination argument that an earlier function call may have set to NULL: staging/rtl8188eu/core/rtw_recv.c: In function 'wlanhdr_to_ethhdr': staging/rtl8188eu/core/rtw_recv.c:1318:2: warning: argument 1 null where non-null expected [-Wnonnull] staging/rtl8712/rtl871x_recv.c: In function 'r8712_wlanhdr_to_ethhdr': staging/rtl8712/rtl871x_recv.c:649:2: warning: argument 1 null where non-null expected [-Wnonnull] I'm fixing this by adding a NULL pointer check and returning failure from the function, which is hopefully already handled properly. This seems to date back to when the drivers were originally added, so backporting the fix to stable seems appropriate. There are other related realtek drivers in the kernel, but none of them contain a function with a similar name or produce this warning. Fixes: 1cc18a22 ("staging: r8188eu: Add files for new driver - part 5") Fixes: 2865d42c ("staging: r8712u: Add the new driver to the mainline kernel") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Hui Wang authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 29693efc upstream. On this machine, the micmute button is connected to Line2 of the codec and the micmute led is connected to GPIO2 of the codec. After applying this quirk, both hotkey and led work well. Signed-off-by:
Hui Wang <hui.wang@canonical.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 493de342 upstream. Dell Inspiron 17 7000 Gaming laptop needs a similar quirk like Inspiron 7599 to support its subwoofer speaker. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=194191Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit f3ac9f73 upstream. The sequencer FIFO management has a bug that may lead to a corruption (shortage) of the cell linked list. When a sequencer client faces an error at the event delivery, it tries to put back the dequeued cell. When the first queue was put back, this forgot the tail pointer tracking, and the link will be screwed up. Although there is no memory corruption, the sequencer client may stall forever at exit while flushing the pending FIFO cells in snd_seq_pool_done(), as spotted by syzkaller. This patch addresses the missing tail pointer tracking at snd_seq_fifo_cell_putback(). Also the patch makes sure to clear the cell->enxt pointer at snd_seq_fifo_event_in() for avoiding a similar mess-up of the FIFO linked list. Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 15c75b09 upstream. Currently ctxfi driver tries to set only the 64bit DMA mask on 64bit architectures, and bails out if it fails. This causes a problem on some platforms since the 64bit DMA isn't always guaranteed. We should fall back to the default 32bit DMA when 64bit DMA fails. Fixes: 6d74b86d ("ALSA: ctxfi - Allow 64bit DMA") Signed-off-by:
-
Takashi Iwai authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 71321eb3 upstream. When a user sets a too small ticks with a fine-grained timer like hrtimer, the kernel tries to fire up the timer irq too frequently. This may lead to the condensed locks, eventually the kernel spinlock lockup with warnings. For avoiding such a situation, we define a lower limit of the resolution, namely 1ms. When the user passes a too small tick value that results in less than that, the kernel returns -EINVAL now. Reported-by:
-
Jaroslav Kysela authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit e7480b34 upstream. Like for Sunrise Point, the total stream number of Lewisburg's input and output stream exceeds 15 (GCAP is 0x9701), which will cause some streams do not work because of the overflow on SDxCTL.STRM field if using the legacy stream tag allocation method. Fixes: 5cf92c8b ("ALSA: hda - Add Intel Lewisburg device IDs Audio") Signed-off-by:
Jaroslav Kysela <perex@perex.cz> Signed-off-by:
-
Kai-Heng Feng authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 9f1bc2c4 upstream. The issue is the same as "dd9aa335 ALSA: hda/realtek - Can't adjust speaker's volume on a Dell AIO", the output requires to connect to a node with Amp-out capability. Applying the same fixup "ALC298_FIXUP_SPK_VOLUME" can fix the issue. Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Signed-off-by:
-
Alexandre Belloni authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 78162d48 upstream. Enable DMA on uart1 to get a more reliable console. Acked-by:
Nicolas Ferre <nicolas.ferre@atmel.com> Signed-off-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Alexandre Belloni authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit ef8d02d4 upstream. Enable DMA on usart3 to get a more reliable console. This is especially useful for automation and kernelci were a kernel with PROVE_LOCKING enabled is quite susceptible to character loss, resulting in tests failure. Acked-by:
-
Alexandre Belloni authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit e3f0a401 upstream. The Atmel MPDDR controller support LPDDR2 and LPDDR3 memories, add their types. Signed-off-by:
Sebastian Reichel <sre@kernel.org> Signed-off-by:
-
Randy Dunlap authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit e3bb3cdd upstream. Fix dm1105 build error when CONFIG_I2C_ALGOBIT=m and CONFIG_DVB_DM1105=y. drivers/built-in.o: In function `dm1105_probe': dm1105.c:(.text+0x2836e7): undefined reference to `i2c_bit_add_bus' Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kbuild test robot <fengguang.wu@intel.com> Cc: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Guennadi Liakhovetski authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 17c341ec upstream. Don't mix up UVC_BUF_STATE_* and VB2_BUF_STATE_* codes. Fixes: 6998b6fb ("[media] uvcvideo: Use videobuf2-vmalloc") Signed-off-by:
Guennadi Liakhovetski <guennadi.liakhovetski@intel.com> Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
-
Nicolas Iooss authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 6ebf7577 upstream. In vpfe_s_fmt(), when the sensor format and the requested format were the same, bpp was assigned to vpfe->bpp without being initialized first. Grab the bpp value that is currently used by using __vpfe_get_format() instead of its wrapper, vpfe_try_fmt(). This use of uninitialized variable has been found by compiling the kernel with clang. Fixes: 417d2e50 ("[media] media: platform: add VPFE capture driver support for AM437X") Signed-off-by:
Nicolas Iooss <nicolas.iooss_linux@m4x.org> Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 096a0de4 upstream. is_jump_ins() checks for plain jump ("j") instructions since commit e7438c4b ("MIPS: Fix sibling call handling in get_frame_info") but that commit didn't make the same change to the microMIPS code, leaving it inconsistent with the MIPS32/MIPS64 code. Handle the microMIPS encoding of the jump instruction too such that it behaves consistently. Signed-off-by:
Paul Burton <paul.burton@imgtec.com> Fixes: e7438c4b ("MIPS: Fix sibling call handling in get_frame_info") Cc: Tony Wu <tung7970@gmail.com> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/14533/Signed-off-by:
Ralf Baechle <ralf@linux-mips.org> Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit bb9bc468 upstream. get_frame_info() calculates the offset of the return address within a stack frame simply by dividing a the bottom 16 bits of the instruction, treated as a signed integer, by the size of a long. Whilst this works for MIPS32 & MIPS64 ISAs where the sw or sd instructions are used, it's incorrect for microMIPS where encodings differ. The result is that we typically completely fail to unwind the stack on microMIPS. Fix this by adjusting is_ra_save_ins() to calculate the return address offset, and take into account the various different encodings there in the same place as we consider whether an instruction is storing the ra/$31 register. With this we are now able to unwind the stack for kernels targetting the microMIPS ISA, for example we can produce: Call Trace: [<80109e1f>] show_stack+0x63/0x7c [<8011ea17>] __warn+0x9b/0xac [<8011ea45>] warn_slowpath_fmt+0x1d/0x20 [<8013fe53>] register_console+0x43/0x314 [<8067c58d>] of_setup_earlycon+0x1dd/0x1ec [<8067f63f>] early_init_dt_scan_chosen_stdout+0xe7/0xf8 [<8066c115>] do_early_param+0x75/0xac [<801302f9>] parse_args+0x1dd/0x308 [<8066c459>] parse_early_options+0x25/0x28 [<8066c48b>] parse_early_param+0x2f/0x38 [<8066e8cf>] setup_arch+0x113/0x488 [<8066c4f3>] start_kernel+0x57/0x328 ---[ end trace 0000000000000000 ]--- Whereas previously we only produced: Call Trace: [<80109e1f>] show_stack+0x63/0x7c ---[ end trace 0000000000000000 ]--- Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 67c75057 upstream. is_jump_ins() checks 16b instruction fields without verifying that the instruction is indeed 16b, as is done by is_ra_save_ins() & is_sp_move_ins(). Add the appropriate check. Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit b6c7a324 upstream. get_frame_info() is meant to iterate over up to the first 128 instructions within a function, but for microMIPS kernels it will not reach that many instructions unless the function is 512 bytes long since we calculate the maximum number of instructions to check by dividing the function length by the 4 byte size of a union mips_instruction. In microMIPS kernels this won't do since instructions are variable length. Fix this by instead checking whether the pointer to the current instruction has reached the end of the function, and use max_insns as a simple constant to check the number of iterations against. Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit a3552dac upstream. During stack unwinding we call a number of functions to determine what type of instruction we're looking at. The union mips_instruction pointer provided to them may be pointing at a 2 byte, but not 4 byte, aligned address & we thus cannot directly access the 4 byte wide members of the union mips_instruction. To avoid this is_ra_save_ins() copies the required half-words of the microMIPS instruction to a correctly aligned union mips_instruction on the stack, which it can then access safely. The is_jump_ins() & is_sp_move_ins() functions do not correctly perform this temporary copy, and instead attempt to directly dereference 4 byte fields which may be misaligned and lead to an address exception. Fix this by copying the instruction halfwords to a temporary union mips_instruction in get_frame_info() such that we can provide a 4 byte aligned union mips_instruction to the is_*_ins() functions and they do not need to deal with misalignment themselves. Signed-off-by:
-
Paul Burton authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit ccaf7caf upstream. get_frame_info() can be called in microMIPS kernels with the ISA bit already clear. For example this happens when unwind_stack_by_address() is called because we begin with a PC that has the ISA bit set & subtract the (odd) offset from the preceding symbol (which does not have the ISA bit set). Since get_frame_info() unconditionally subtracts 1 from the PC in microMIPS kernels it incorrectly misaligns the address it then attempts to access code at, leading to an address error exception. Fix this by using msk_isa16_mode() to clear the ISA bit, which allows get_frame_info() to function regardless of whether it is provided with a PC that has the ISA bit set or not. Signed-off-by:
-
Felix Fietkau authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 774f0c64 upstream. Disabling ethernet during reboot (only to enable it again when the ethernet driver attaches) can put the chip into a faulty state where it corrupts the header of all incoming packets. This happens if packets arrive during the time window where the core is disabled, and it can be easily reproduced by rebooting while sending a flood ping to the broadcast address. Fixes: 95135bfa ("MIPS: Lantiq: Deactivate most of the devices by default") Signed-off-by:
Felix Fietkau <nbd@nbd.name> Acked-by:
John Crispin <john@phrozen.org> Cc: hauke.mehrtens@lantiq.com Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/15078/Signed-off-by:
James Hogan <james.hogan@imgtec.com> Signed-off-by:
-
James Cowgill authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 884b4269 upstream. If copy_from_user is called with a large buffer (>= 128 bytes) and the userspace buffer refers partially to unreadable memory, then it is possible for Octeon's copy_from_user to report the wrong number of bytes have been copied. In the case where the buffer size is an exact multiple of 128 and the fault occurs in the last 64 bytes, copy_from_user will report that all the bytes were copied successfully but leave some garbage in the destination buffer. The bug is in the main __copy_user_common loop in octeon-memcpy.S where in the middle of the loop, src and dst are incremented by 128 bytes. The l_exc_copy fault handler is used after this but that assumes that "src < THREAD_BUADDR($28)". This is not the case if src has already been incremented. Fix by adding an extra fault handler which rewinds the src and dst pointers 128 bytes before falling though to l_exc_copy. Thanks to the pwritev test from the strace test suite for originally highlighting this bug! Fixes: 5b3b1688 ("MIPS: Add Cavium OCTEON processor support ...") Signed-off-by:
James Cowgill <James.Cowgill@imgtec.com> Acked-by:
David Daney <david.daney@cavium.com> Reviewed-by:
-
Mirko Parthey authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit bdfdaf1a upstream. The Asus WL-500W buttons are active high, but the software treats them as active low. Fix the inverted logic. Fixes: 3be97255 ("MIPS: BCM47XX: Import buttons database from OpenWrt") Signed-off-by:
Mirko Parthey <mirko.parthey@web.de> Acked-by:
Rafał Miłecki <rafal@milecki.pl> Cc: Hauke Mehrtens <hauke@hauke-m.de> Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/15295/Signed-off-by:
-
Ralf Baechle authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 66fd848c upstream. For certain arguments such as saddr = 0xc0a8fd60, daddr = 0xc0a8fda1, len = 80, proto = 17, sum = 0x7eae049d there will be a carry when folding the intermediate 64 bit checksum to 32 bit but the code doesn't add the carry back to the one's complement sum, thus an incorrect result will be generated. Reported-by:
Mark Zhang <bomb.zhang@gmail.com> Signed-off-by:
-
Shuah Khan authored
BugLink: http://bugs.launchpad.net/bugs/1673538 commit 6bee835d upstream. Move mic/mpssd examples to samples and remove it from Documentation Makefile. Create a new Makefile to build mic/mpssd. It can be built from top level directory or from mic/mpssd directory: Run make -C samples/mic/mpssd or cd samples/mic/mpssd; make Acked-by:
Jonathan Corbet <corbet@lwn.net> Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> [backported to 4.4-stable as this code is broken on newer versions of gcc and we don't want to break the build for a Documentation sample. - gregkh] Signed-off-by:
-
Kamal Mostafa authored
BugLink: https://bugs.launchpad.net/bugs/1673498Signed-off-by:
Kamal Mostafa <kamal@canonical.com> Acked-by:
Colin Ian King <colin.king@canonical.com> Acked-by:
Seth Forshee <seth.forshee@canonical.com>
-
Eric Dumazet authored
BugLink: http://bugs.launchpad.net/bugs/1673303 skb->sender_cpu and skb->napi_id share a common storage, and we had various bugs about this. We had to call skb_sender_cpu_clear() in some places to not leave a prior skb->napi_id and fool netdev_pick_tx() As suggested by Alexei, we could split the space so that these errors can not happen. 0 value being reserved as the common (not initialized) value, let's reserve [1 .. NR_CPUS] range for valid sender_cpu, and [NR_CPUS+1 .. ~0U] for valid napi_id. This will allow proper busy polling support over tunnels. Signed-off-by:
Eric Dumazet <edumazet@google.com> Suggested-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
David S. Miller <davem@davemloft.net> (cherry picked from commit 52bd2d62) Signed-off-by:
Leann Ogasawara <leann.ogasawara@canonical.com> Acked-by:
Stefan Bader <stefan.bader@canonical.com> Acked-by:
-
Jeff Mahoney authored
BugLink: http://bugs.launchpad.net/bugs/1619918 Commit 4c63c245 incorrectly assumed that returning -ENOIOCTLCMD would cause the native ioctl to be called. The ->compat_ioctl callback is expected to handle all ioctls, not just compat variants. As a result, when using 32-bit userspace on 64-bit kernels, everything except those three ioctls would return -ENOTTY. Fixes: 4c63c245 ("btrfs: bugfix: handle FS_IOC32_{GETFLAGS,SETFLAGS,GETVERSION} in btrfs_ioctl") Cc: stable@vger.kernel.org Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Acked-by:
-
Tim Gardner authored
BugLink: http://bugs.launchpad.net/bugs/1667571Signed-off-by:
-
Gabriel Krisman Bertazi authored
BugLink: http://bugs.launchpad.net/bugs/1669153 Commit f209fa03 ("serial: 8250_pci: Detach low-level driver during PCI error recovery") introduces a potential use-after-free in case the pciserial_init_ports call in serial8250_io_resume fails, which may happen if a memory allocation fails or if the .init quirk failed for whatever reason). If this happen, further pci_get_drvdata will return a pointer to freed memory. This patch reworks the PCI recovery resume hook to restore the old priv structure in this case, which should be ok, since the ports were already detached. Such error during recovery causes us to give up on the recovery. Fixes: f209fa03 ("serial: 8250_pci: Detach low-level driver during PCI error recovery") Reported-by:
Michal Suchanek <msuchanek@suse.com> Signed-off-by:
Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com> Signed-off-by:
Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Signed-off-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Acked-by:
-
Haiyang Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1667527 Use the device serial number as the PCI domain. The serial numbers start with 1 and are unique within a VM. So names, such as VF NIC names, that include domain number as part of the name, can be shorter than that based on part of bus UUID previously. The new names will also stay same for VMs created with copied VHD and same number of devices. Signed-off-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
Stephen Hemminger <sthemmin@microsoft.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Reviewed-by:
K. Y. Srinivasan <kys@microsoft.com> (cherry picked from commit 4a9b0933) Signed-off-by:
-
Jack Morgenstein authored
BugLink: http://bugs.launchpad.net/bugs/1667527 When creating EQs to handle CQ completion events for the PF or for VFs, we create enough EQE entries to handle completions for the max number of CQs that can use that EQ. When SRIOV is activated, the max number of CQs a VF (or the PF) can obtain is its CQ quota (determined by the Hypervisor resource tracker). Therefore, when creating an EQ, the number of EQE entries that the VF should request for that EQ is the CQ quota value (and not the total number of CQs available in the FW). Under SRIOV, the PF, also must use its CQ quota, because the resource tracker also controls how many CQs the PF can obtain. Using the FW total CQs instead of the CQ quota when creating EQs resulted wasting MTT entries, due to allocating more EQEs than were needed. Fixes: 5a0d0a61 ("mlx4: Structures and init/teardown for VF resource quotas") Signed-off-by:
Jack Morgenstein <jackm@dev.mellanox.co.il> Reported-by:
Dexuan Ciu <decui@microsoft.com> (cherry picked from linux-next commit 6ed63d84) Signed-off-by:
-
Mark Bloch authored
BugLink: https://bugs.launchpad.net/bugs/1668042 When using an IPoIB bond currently only active-backup mode is a valid use case and this commit strengthens it. Since commit 2ab82852 ("net/bonding: Enable bonding to enslave netdevices not supporting set_mac_address()") was introduced till 4.7-rc1, IPoIB didn't support the set_mac_address ndo, and hence the fail over mac policy always applied to IPoIB bonds. With the introduction of commit 492a7e67 ("IB/IPoIB: Allow setting the device address"), that doesn't hold and practically IPoIB bonds are broken as of that. To fix it, lets go to fail over mac if the device doesn't support the ndo OR this is IPoIB device. As a by-product, this commit also prevents a stack corruption which occurred when trying to copy 20 bytes (IPoIB) device address to a sockaddr struct that has only 16 bytes of storage. Signed-off-by:
Mark Bloch <markb@mellanox.com> Signed-off-by:
Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Acked-by:
Andy Gospodarek <gospo@cumulusnetworks.com> Signed-off-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Signed-off-by:
Talat Batheesh <talatb@mellanox.com> Acked-by:
-
Matthew R. Ochs authored
BugLink: http://bugs.launchpad.net/bugs/1623750 When an EEH occurs during device initialization, the port timeout logic can cause excessive delays as MMIO reads will fail. Depending on where they are experienced, these delays can lead to a prolonged reset, causing an unnecessary triggering of other timeout logic in the SCSI stack or user applications. To expedite recovery, the port timeout logic is updated to decay the timeout at a much faster rate when in the presence of a likely EEH frozen event. Signed-off-by:
Matthew R. Ochs <mrochs@linux.vnet.ibm.com> Acked-by:
Uma Krishnan <ukrishn@linux.vnet.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> (cherry picked from commit 05dab432) Signed-off-by:
Marcelo Cerri <marcelo.cerri@canonical.com> Acked-by:
-
Matthew R. Ochs authored
BugLink: http://bugs.launchpad.net/bugs/1623750 The EEH reset handler is ignorant to the current state of the driver when processing a frozen event and initiating a device reset. This can be an issue if an EEH event occurs while a user or stack initiated reset is executing. More specifically, if an EEH occurs while the SCSI host reset handler is active, the reset initiated by the EEH thread will likely collide with the host reset thread. This can leave the device in an inconsistent state, or worse, cause a system crash. As a remedy, the EEH handler is updated to evaluate the device state and take appropriate action (proceed, wait, or disconnect host). The host reset handler is also updated to handle situations where an EEH occurred during a host reset. In such situations, the host reset handler will delay reporting back a success to give the EEH reset an opportunity to complete. Signed-off-by:
-
Uma Krishnan authored
BugLink: http://bugs.launchpad.net/bugs/1623750 Commit 704c4b0d ("cxlflash: Shutdown notify support for CXL Flash cards") was recently introduced to notify the AFU when a system is going down. Due to the position of the cxlflash driver in the device stack, cxlflash devices are _always_ removed during a reboot/shutdown. This can lead to a crash if the cxlflash shutdown hook is invoked _after_ the shutdown hook for the owning virtual PHB. Furthermore, the current implementation of shutdown/remove hooks for cxlflash are not tolerant to being invoked when the device is not enabled. This can also lead to a crash in situations where the remove hook is invoked after the device has been removed via the vPHBs shutdown hook. An example of this scenario would be an EEH reset failure while a reboot/shutdown is in progress. To solve both problems, the shutdown hook for cxlflash is updated to simply remove the device. This path already includes the AFU notification and thus this solution will continue to perform the original intent. At the same time, the remove hook is updated to protect against being called when the device is not enabled. Fixes: 704c4b0d ("cxlflash: Shutdown notify support for CXL Flash cards") Signed-off-by:
-
Uma Krishnan authored
BugLink: http://bugs.launchpad.net/bugs/1623750 When a port link is established, the AFU sends a 'link up' interrupt. After the link is up, corresponding initialization steps are performed on the card. Following that, when the card is ready for I/O, the AFU sends 'login succeeded' interrupt. Today, cxlflash invokes scsi_scan_host() upon receipt of both interrupts. SCSI commands sent to the port prior to the 'login succeeded' interrupt will fail with 'port not available' error. This is not desirable. Moreover, when async_scan is active for the host, subsequent scan calls are terminated with error. Due to this, the scsi_scan_host() call performed after 'login succeeded' interrupt could portentially return error and the devices may not be scanned properly. To avoid this problem, scsi_scan_host() should be called only after the 'login succeeded' interrupt. Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1669016Signed-off-by:
-
Peter Feiner authored
BugLink: http://bugs.launchpad.net/bugs/1669016 commit 4e59516a upstream. Between loading the new VMCS and enabling PML, the CPU was unpinned. If the vCPU thread were migrated to another CPU in the interim (e.g., due to preemption or sleeping alloc_page), then the VMWRITEs to enable PML would target the wrong VMCS -- or no VMCS at all: [ 2087.266950] vmwrite error: reg 200e value 3fe1d52000 (err -506126336) [ 2087.267062] vmwrite error: reg 812 value 1ff (err 511) [ 2087.267125] vmwrite error: reg 401e value 12229c00 (err 304258048) This patch ensures that the VMCS remains current while enabling PML by doing the VMWRITEs while the CPU is pinned. Allocation of the PML buffer is hoisted out of the critical section. Signed-off-by:
Peter Feiner <pfeiner@google.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: "Herongguang (Stephen)" <herongguang.he@huawei.com> Signed-off-by:
-
