- 16 Nov, 2017 40 commits
-
-
Carlo Caione authored
BugLink: http://bugs.launchpad.net/bugs/1732698 commit d3138769 upstream. All the helper functions (i.e. hp_wmi_dock_state, hp_wmi_tablet_state, ...) using hp_wmi_perform_query to perform an HP WMI query shadow the returned value in case of error. We return -EINVAL only when the HP WMI query returns a positive value (the specific error code) to not mix this up with the actual value returned by the helper function. Suggested-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
Carlo Caione <carlo@endlessm.com> Signed-off-by:
Darren Hart (VMware) <dvhart@infradead.org> Cc: Philip Müller <philm@manjaro.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
Stefan Bader <stefan.bader@canonical.com> Signed-off-by:
Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
-
Carlo Caione authored
BugLink: http://bugs.launchpad.net/bugs/1732698 commit c7dfc2fa upstream. hp_wmi_tablet_state() fails to return the correct error code when hp_wmi_perform_query() returns the HP WMI query specific error code that is a positive value. Signed-off-by:
-
Eric Biggers authored
BugLink: http://bugs.launchpad.net/bugs/1732698 commit a3c812f7 upstream. When calling keyctl_read() on a key of type "trusted", if the user-supplied buffer was too small, the kernel ignored the buffer length and just wrote past the end of the buffer, potentially corrupting userspace memory. Fix it by instead returning the size required, as per the documentation for keyctl_read(). We also don't even fill the buffer at all in this case, as this is slightly easier to implement than doing a short read, and either behavior appears to be permitted. It also makes it match the behavior of the "encrypted" key type. Fixes: d00a1c72 ("keys: add new trusted key-type") Reported-by:
Ben Hutchings <ben@decadent.org.uk> Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
David Howells <dhowells@redhat.com> Reviewed-by:
Mimi Zohar <zohar@linux.vnet.ibm.com> Reviewed-by:
James Morris <james.l.morris@oracle.com> Signed-off-by:
-
Eric Biggers authored
BugLink: http://bugs.launchpad.net/bugs/1732698 commit ee618b46 upstream. As the previous patch did for encrypted-keys, zero sensitive any potentially sensitive data related to the "trusted" key type before it is freed. Notably, we were not zeroing the tpm_buf structures in which the actual key is stored for TPM seal and unseal, nor were we zeroing the trusted_key_payload in certain error paths. Cc: Mimi Zohar <zohar@linux.vnet.ibm.com> Cc: David Safford <safford@us.ibm.com> Signed-off-by:
-
Enrico Mioso authored
BugLink: http://bugs.launchpad.net/bugs/1732698 commit 2b02c20c upstream. Some firmwares in Huawei E3372H devices have been observed to switch back to NTB 32-bit format after altsetting switch. This patch implements a driver flag to check for the device settings and set NTB format to 16-bit again if needed. The flag has been activated for devices controlled by the huawei_cdc_ncm.c driver. V1->V2: - fixed broken error checks - some corrections to the commit message V2->V3: - variable name changes, to clarify what's happening - check (and possibly set) the NTB format later in the common bind code path Signed-off-by:
Enrico Mioso <mrkiko.rs@gmail.com> Reported-and-tested-by:
Christian Panton <christian@panton.org> Reviewed-by:
Bjørn Mork <bjorn@mork.no> CC: Bjørn Mork <bjorn@mork.no> CC: Christian Panton <christian@panton.org> CC: linux-usb@vger.kernel.org CC: netdev@vger.kernel.org CC: Oliver Neukum <oliver@neukum.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Porto Rio <porto.rio@gmx.net> Signed-off-by:
-
Carlo Caione authored
BugLink: http://bugs.launchpad.net/bugs/1732698 commit 298747b7 upstream. The current driver code is not checking for the error values returned by 'hp_wmi_dock_state()' and 'hp_wmi_tablet_state()' before passing the returned values down to 'input_report_switch()'. This error code is being translated to '1' in the input subsystem, reporting the wrong status. The biggest problem caused by this issue is that several laptops are wrongly reported by the driver as docked, preventing them to be put to sleep using the LID (and in most cases they are not even dockable). With this patch we create the report switches only if we are able to read the dock and tablet mode status correctly from ACPI. Signed-off-by:
-
Vivien Didelot authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 3a89eaa6 ] The support for DSA Ethernet switch chips depends on TCP/IP networking, thus explicit that HAVE_NET_DSA depends on INET. DSA uses SWITCHDEV, thus select it instead of depending on it. Signed-off-by:
Vivien Didelot <vivien.didelot@savoirfairelinux.com> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Sasha Levin <alexander.levin@verizon.com> Signed-off-by:
-
Stefan Bader authored
BugLink: http://bugs.launchpad.net/bugs/1732698 Stable commit "net: dsa: select NET_SWITCHDEV" now requires an explicit setting. Signed-off-by:
-
Julian Wiedmann authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 10340510 ] STARTLAN needs to be the first IPA command after MPC initialization completes. So move the qeth_send_startlan() call from the layer disciplines into the core path, right after the MPC handshake. While at it, replace the magic LAN OFFLINE return code with the existing enum. Signed-off-by:
Julian Wiedmann <jwi@linux.vnet.ibm.com> Reviewed-by:
Thomas Richter <tmricht@linux.vnet.ibm.com> Reviewed-by:
Ursula Braun <ubraun@linux.vnet.ibm.com> Signed-off-by:
-
Feras Daoud authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 27d41d29 ] Since ipoib_cm_tx_start function and ipoib_cm_tx_reap function belong to different work queues, they can run in parallel. In this case if ipoib_cm_tx_reap calls list_del and release the lock, ipoib_cm_tx_start may acquire it and call list_del_init on the already deleted object. Changing list_del to list_del_init in ipoib_cm_tx_reap fixes the problem. Fixes: 839fcaba ("IPoIB: Connected mode experimental support") Signed-off-by:
Feras Daoud <ferasda@mellanox.com> Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Reviewed-by:
Alex Vesker <valex@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Reviewed-by:
Yuval Shaia <yuval.shaia@oracle.com> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
-
Akinobu Mita authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 9723ddc8 ] This driver reports misc scan input events on the sensor's status register changes. But the event capability for them was not set in the device initialization, so these events were ignored. This change adds the missing event capability. Signed-off-by:
Akinobu Mita <akinobu.mita@gmail.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Akinobu Mita authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 08fea55e ] This driver reports input events on their interrupts which are triggered by the sensor's status register changes. But only single bit change is reported in the interrupt handler. So if there are multiple bits are changed at almost the same time, other press or release events are ignored. This fixes it by detecting all changed bits in the status register. Signed-off-by:
-
Gilad Ben-Yossef authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit ebd89a2d ] ah4 input processing uses the asynchronous hash crypto API which supplies an error code as part of the operation completion but the error code was being ignored. Treat a crypto API error indication as a verification failure. While a crypto API reported error would almost certainly result in a memcpy of the digest failing anyway and thus the security risk seems minor, performing a memory compare on what might be uninitialized memory is wrong. Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Liping Zhang authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit f169fd69 ] After adding the following nft rule, then ping 224.0.0.1: # nft add rule netdev t c pkttype host counter The warning complain message will be printed out again and again: WARNING: CPU: 0 PID: 10182 at net/netfilter/nft_meta.c:163 \ nft_meta_get_eval+0x3fe/0x460 [nft_meta] [...] Call Trace: <IRQ> dump_stack+0x85/0xc2 __warn+0xcb/0xf0 warn_slowpath_null+0x1d/0x20 nft_meta_get_eval+0x3fe/0x460 [nft_meta] nft_do_chain+0xff/0x5e0 [nf_tables] So we should deal with PACKET_LOOPBACK in netdev family too. For ipv4, convert it to PACKET_BROADCAST/MULTICAST according to the destination address's type; For ipv6, convert it to PACKET_MULTICAST directly. Signed-off-by:
Liping Zhang <zlpnobody@gmail.com> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
William wu authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 76b8db0d ] On some platforms(e.g. rk3399 board), we can call hcd_add/remove consecutively without calling usb_put_hcd/usb_create_hcd in between, so hcd->flags can be stale. If the HC dies due to whatever reason then without this patch we get the below error on next hcd_add. [173.296154] xhci-hcd xhci-hcd.2.auto: HC died; cleaning up [173.296209] xhci-hcd xhci-hcd.2.auto: xHCI Host Controller [173.296762] xhci-hcd xhci-hcd.2.auto: new USB bus registered, assigned bus number 6 [173.296931] usb usb6: We don't know the algorithms for LPM for this host, disabling LPM. [173.297179] usb usb6: New USB device found, idVendor=1d6b, idProduct=0003 [173.297203] usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [173.297222] usb usb6: Product: xHCI Host Controller [173.297240] usb usb6: Manufacturer: Linux 4.4.21 xhci-hcd [173.297257] usb usb6: SerialNumber: xhci-hcd.2.auto [173.298680] hub 6-0:1.0: USB hub found [173.298749] hub 6-0:1.0: 1 port detected [173.299382] rockchip-dwc3 usb@fe800000: USB HOST connected [173.395418] hub 5-0:1.0: activate --> -19 [173.603447] irq 228: nobody cared (try booting with the "irqpoll" option) [173.603493] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.4.21 #9 [173.603513] Hardware name: Google Kevin (DT) [173.603531] Call trace: [173.603568] [<ffffffc0002087dc>] dump_backtrace+0x0/0x160 [173.603596] [<ffffffc00020895c>] show_stack+0x20/0x28 [173.603623] [<ffffffc0004b28a8>] dump_stack+0x90/0xb0 [173.603650] [<ffffffc00027347c>] __report_bad_irq+0x48/0xe8 [173.603674] [<ffffffc0002737cc>] note_interrupt+0x1e8/0x28c [173.603698] [<ffffffc000270a38>] handle_irq_event_percpu+0x1d4/0x25c [173.603722] [<ffffffc000270b0c>] handle_irq_event+0x4c/0x7c [173.603748] [<ffffffc00027456c>] handle_fasteoi_irq+0xb4/0x124 [173.603777] [<ffffffc00026fe3c>] generic_handle_irq+0x30/0x44 [173.603804] [<ffffffc0002701a8>] __handle_domain_irq+0x90/0xbc [173.603827] [<ffffffc0002006f4>] gic_handle_irq+0xcc/0x188 ... [173.604500] [<ffffffc000203700>] el1_irq+0x80/0xf8 [173.604530] [<ffffffc000261388>] cpu_startup_entry+0x38/0x3cc [173.604558] [<ffffffc00090f7d8>] rest_init+0x8c/0x94 [173.604585] [<ffffffc000e009ac>] start_kernel+0x3d0/0x3fc [173.604607] [<0000000000b16000>] 0xb16000 [173.604622] handlers: [173.604648] [<ffffffc000642084>] usb_hcd_irq [173.604673] Disabling IRQ #228 Signed-off-by:
William wu <wulf@rock-chips.com> Acked-by:
Roger Quadros <rogerq@ti.com> Signed-off-by:
-
Laurent Pinchart authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit a752ba18 ] Even though most of its registers are 8-bit wide, the IRDA has two 16-bit registers that make it a 16-bit peripheral and not a 8-bit peripheral with addresses shifted by one. Fix the registers offset in the driver and the platform data regshift value. Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
-
Volodymyr Bendiuga authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 4567d686 ] Some bus names are pretty long and do not fit into 17 chars. Increase therefore MII_BUS_ID_SIZE and phy_fixup.bus_id to larger number. Now mii_bus.id can host larger name. Signed-off-by:
Volodymyr Bendiuga <volodymyr.bendiuga@gmail.com> Signed-off-by:
Magnus Öberg <magnus.oberg@westermo.se> Reviewed-by:
-
Alison Schofield authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 10e840df ] These stand-alone trigger drivers were using iio_trigger_put() where they should have been using iio_trigger_free(). The iio_trigger_put() adds a module_put which is bad since they never did a module_get. In the sysfs driver, module_get/put's are used as triggers are added & removed. This extra module_put() occurs on an error path in the probe routine (probably rare). In the bfin-timer & interrupt trigger drivers, the module resources are not explicitly managed, so it's doing a put on something that was never get'd. It occurs on the probe error path and on the remove path (not so rare). Tested with the sysfs trigger driver. The bfin & interrupt drivers were build tested & inspected only. Signed-off-by:
Alison Schofield <amsfield22@gmail.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Li Zhong authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 7dede913 ] Some preemptible check warnings were reported from enable_kernel_vsx(). This patch disables preemption in aes_ctr.c before enabling vsx, and they are now consistent with other files in the same directory. Signed-off-by:
Li Zhong <zhong@linux.vnet.ibm.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Tony Lindgren authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 4cd6a59f ] We have more than four uarts on some SoCs and that can cause noise with errors while booting. Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Valentin Longchamp authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit a674c7d4 ] It is not implemented on the kmcoge4 hardware and if not disabled it leads to error messages with the corenet32_smp_defconfig. Signed-off-by:
Valentin Longchamp <valentin.longchamp@keymile.com> Signed-off-by:
Scott Wood <oss@buserror.net> Signed-off-by:
-
Nate Watterson authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 810871c5 ] To prevent corruption of the stage-1 context pointer field when updating STEs, rebuild the entire containing dword instead of clearing individual fields. Signed-off-by:
Nate Watterson <nwatters@codeaurora.org> Signed-off-by:
Will Deacon <will.deacon@arm.com> Signed-off-by:
-
Li Zhong authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 37451bc9 ] Some counters are added in Commit 6e0365b7 ("KVM: PPC: Book3S HV: Add ICP real mode counters"), to provide some performance statistics to determine whether further optimizing is needed for real mode functions. The n_reject counter counts how many times ICP rejects an irq because of priority in real mode. The redelivery of an lsi that is still asserted after eoi doesn't fall into this category, so the increasement there is removed. Also, it needs to be increased in icp_rm_deliver_irq() if it rejects another one. Signed-off-by:
Paul Mackerras <paulus@ozlabs.org> Signed-off-by:
-
Noralf Trønnes authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit a67834f8 ] Call drm_debugfs_cleanup() in case drm_debugfs_init() fails to cover for failure in the drm_driver.debugfs_init callback. Signed-off-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170126225621.12314-3-noralf@tronnes.orgSigned-off-by:
-
Juergen Gross authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 56dd5af9 ] The default for the maximum number of tx/rx queues of one interface is the number of cpus of the system today. As each queue pair reserves 512 grant pages this default consumes a ridiculous number of grants for large guests. Limit the queue number to 8 as default. This value can be modified via a module parameter if required. Signed-off-by:
Juergen Gross <jgross@suse.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
Jason Gunthorpe authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit d9bf28e2 ] The PCI core will write to the bridge window config multiple times while they are enabled. This can lead to mbus failures like this: mvebu_mbus: cannot add window '4:e8', conflicts with another window mvebu-pcie mbus:pex@e0000000: Could not create MBus window at [mem 0xe0000000-0xe00fffff]: -22 For me this is happening during a hotplug cycle. The PCI core is not changing the values, just writing them twice while active. The patch addresses the general case of any change to an active window, but not atomically. The code is slightly refactored so io and mem can share more of the window logic. Signed-off-by:
Jason Gunthorpe <jgunthorpe@obsidianresearch.com> Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Jason Cooper <jason@lakedaemon.net> Signed-off-by:
-
Maciej W. Rozycki authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit 879e5a0d ] Fix: WARNING: drivers/video/fbdev/pmag-ba-fb.o(.text+0x308): Section mismatch in reference from the function pmagbafb_probe() to the function .init.text:pmagbafb_erase_cursor() The function pmagbafb_probe() references the function __init pmagbafb_erase_cursor(). This is often because pmagbafb_probe lacks a __init annotation or the annotation of pmagbafb_erase_cursor is wrong. -- a fallout from a missed update from commit 9625b513 ("VIDEO: PMAG-BA: Fix section mismatch") and then commit 48c68c4f ("Drivers: video: remove __dev* attributes.") Signed-off-by:
Maciej W. Rozycki <macro@linux-mips.org> Signed-off-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Signed-off-by:
-
Lars-Peter Clausen authored
BugLink: http://bugs.launchpad.net/bugs/1732698 [ Upstream commit da8892d4 ] The adv7604 driver platform data contains fields for configuring the drive strength of the output pins. When probing the driver through DT these fields are not explicitly initialized, which means they are left at 0. This is a reserved setting for the drive strength configuration though and can cause signal integrity issues. Whether these signal integrity issues are visible depends on the PCB specifics (e.g. the higher the load capacitance for the output the more visible the issue). But it has been observed on existing solutions at high pixel clock rates. Initialize the drive strength settings to the power-on-reset value of the device when probing through devicetree to avoid this issue. Fixes: 0e158be0162b ("adv7604: Add DT support") Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Tested-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Greg Kroah-Hartman authored
BugLink: http://bugs.launchpad.net/bugs/1731915Signed-off-by:
-
Larry Finger authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 07222e53 ] Sparse reports the following: CHECK drivers/staging/rtl8712/rtl871x_xmit.c drivers/staging/rtl8712/rtl871x_xmit.c:350:44: warning: restricted __le32 degrades to integer drivers/staging/rtl8712/rtl871x_xmit.c:491:23: warning: incorrect type in initializer (different base types) drivers/staging/rtl8712/rtl871x_xmit.c:491:23: expected unsigned short [usertype] *fctrl drivers/staging/rtl8712/rtl871x_xmit.c:491:23: got restricted __le16 *<noident> drivers/staging/rtl8712/rtl871x_xmit.c:580:36: warning: incorrect type in assignment (different base types) drivers/staging/rtl8712/rtl871x_xmit.c:580:36: expected unsigned short [unsigned] [short] [usertype] <noident> drivers/staging/rtl8712/rtl871x_xmit.c:580:36: got restricted __be16 [usertype] <noident> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
-
Juergen Gross authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 4e93b648 ] When registering for the Xenstore watch of the node control/sysrq the handler will be called at once. Don't issue an error message if the Xenstore node isn't there, as it will be created only when an event is being triggered. Signed-off-by:
-
Sudip Mukherjee authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 6792eb0c ] If dvb_attach() fails then we were just printing an error message and exiting but the memory allocated to state was not released. Signed-off-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
-
Stefan Haberland authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 2202134e ] Check if the device pointer is valid. Just a sanity check since we already are in the int handler of the device. Signed-off-by:
Stefan Haberland <sth@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Alexander Usyskin authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 7c47d2ca ] Request for a notification from a disconnected client will be ignored silently by the FW but the caller should know that the operation hasn't succeeded. Signed-off-by:
Alexander Usyskin <alexander.usyskin@intel.com> Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Arvind Yadav authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 4742575c ] Free memory mapping, if fimc_is_probe is not successful. Signed-off-by:
Arvind Yadav <arvind.yadav.cs@gmail.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Alexander Boyko authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 4c43c27d ] This patch resolves IO vs eviction race. After eviction failed export stayed at stale list, a client had IO processing and reconnected during it. A client sent brw rpc with last lock cookie and new connection. The lock with failed export was found and assert was happened. (ost_handler.c:1812:ost_prolong_lock_one()) ASSERTION( lock->l_export == opd->opd_exp ) failed: 1. Skip the lock at ldlm_handle2lock if lock export failed. 2. Validation of lock for IO was added at hpreq_check(). The lock searching is based on granted interval tree. If server doesn`t have a valid lock, it reply to client with ESTALE. Signed-off-by:
Alexander Boyko <alexander.boyko@seagate.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-7702 Seagate-bug-id: MRP-2787 Reviewed-on: http://review.whamcloud.com/18120Reviewed-by:
Fan Yong <fan.yong@intel.com> Reviewed-by:
Vitaly Fertman <vitaly.fertman@seagate.com> Reviewed-by:
Oleg Drokin <oleg.drokin@intel.com> Signed-off-by:
James Simmons <jsimmons@infradead.org> Signed-off-by:
-
frank zago authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 22aadb91 ] The function hai_dump_data_field will do a stack buffer overrun when cat'ing /sys/fs/lustre/.../hsm/actions if an action has some data in it. hai_dump_data_field uses snprintf. But there is no check for truncation, and the value returned by snprintf is used as-is. The coordinator code calls hai_dump_data_field with 12 bytes in the buffer. The 6th byte of data is printed incompletely to make room for the terminating NUL. However snprintf still returns 2, so when hai_dump_data_field writes the final NUL, it does it outside the reserved buffer, in the 13th byte of the buffer. This stack buffer overrun hangs my VM. Fix by checking that there is enough room for the next 2 characters plus the NUL terminator. Don't print half bytes. Change the format to 02X instead of .2X, which makes more sense. Signed-off-by:
frank zago <fzago@cray.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8171 Reviewed-on: http://review.whamcloud.com/20338Reviewed-by:
John L. Hammond <john.hammond@intel.com> Reviewed-by:
Jean-Baptiste Riaux <riaux.jb@intel.com> Reviewed-by:
-
Yang Sheng authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 77759771 ] The function generic_file_read_iter() does not check EOF before invoke direct_IO callback. So we have to check it ourselves. Signed-off-by:
Yang Sheng <yang.sheng@intel.com> Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-8969 Reviewed-on: https://review.whamcloud.com/24552Reviewed-by:
Bob Glossman <bob.glossman@intel.com> Reviewed-by:
Bobi Jam <bobijam@hotmail.com> Reviewed-by:
-
Javier Martinez Canillas authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit a93151a7 ] If the driver is built as a module, autoload won't work because the module alias information is not filled. So user-space can't match the registered device with the corresponding module. Export the module alias information using the MODULE_DEVICE_TABLE() macro. Before this patch: $ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias $ After this patch: $ modinfo drivers/platform/x86/intel_mid_thermal.ko | grep alias alias: platform:msic_thermal Signed-off-by:
Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by:
-
Raghava Aditya Renukunta authored
BugLink: http://bugs.launchpad.net/bugs/1731915 [ Upstream commit 4ec57fb4 ] Make sure that the driver processes error conditions even in the fast response path for response from the adapter. Signed-off-by:
Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by:
Dave Carroll <David.Carroll@microsemi.com> Reviewed-by:
Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
