- 09 Jul, 2014 31 commits
-
-
Alex Hung authored
commit 4ef366c5 upstream. On HP 1000 lapops, BIOS reports minimum backlight on boot and causes backlight to dim completely. This ignores the initial backlight values and set to max brightness. References:: https://bugs.launchpad.net/bugs/1167760Signed-off-by:
Alex Hung <alex.hung@canonical.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk> Cc: Yijing Wang <wangyijing@huawei.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bastian Triller authored
commit c8f6d835 upstream. Like on UL30VT, the ACPI video driver can't control backlight correctly on Asus UL30A. Vendor driver (asus-laptop) can work. This patch is to add "Asus UL30A" to ACPI video detect blacklist in order to use asus-laptop for video control on the "Asus UL30A" rather than ACPI video driver. Signed-off-by:
Bastian Triller <bastian.triller@gmail.com> Signed-off-by:
-
Lan Tianyu authored
commit d0c2ce16 upstream. The ACPI video driver can't control backlight correctly on Asus UL30VT. Vendor driver (asus-laptop) can work. This patch is to add "Asus UL30VT" to ACPI video detect blacklist in order to use asus-laptop for video control on the "Asus UL30VT" rather than ACPI video driver. References: https://bugzilla.kernel.org/show_bug.cgi?id=32592Reported-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Lan Tianyu <tianyu.lan@intel.com> Signed-off-by:
-
Corentin Chary authored
commit 084940d5 upstream. On Samsung X360, the BIOS will set a flag (VDRV) if the generic ACPI backlight device is used. This flag will definitively break the backlight interface (even the vendor interface) untill next reboot. It's why we should prevent video.ko from being used here and we can't rely on a later call to acpi_video_unregister(). Signed-off-by:
Corentin Chary <corentin.chary@gmail.com> Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
-
Mikulas Patocka authored
commit fd1232b2 upstream. This patch fixes I/O errors with the sym53c8xx_2 driver when the disk returns QUEUE FULL status. When the controller encounters an error (including QUEUE FULL or BUSY status), it aborts all not yet submitted requests in the function sym_dequeue_from_squeue. This function aborts them with DID_SOFT_ERROR. If the disk has full tag queue, the request that caused the overflow is aborted with QUEUE FULL status (and the scsi midlayer properly retries it until it is accepted by the disk), but the sym53c8xx_2 driver aborts the following requests with DID_SOFT_ERROR --- for them, the midlayer does just a few retries and then signals the error up to sd. The result is that disk returning QUEUE FULL causes request failures. The error was reproduced on 53c895 with COMPAQ BD03685A24 disk (rebranded ST336607LC) with command queue 48 or 64 tags. The disk has 64 tags, but under some access patterns it return QUEUE FULL when there are less than 64 pending tags. The SCSI specification allows returning QUEUE FULL anytime and it is up to the host to retry. Signed-off-by:
Mikulas Patocka <mpatocka@redhat.com> Cc: Matthew Wilcox <matthew@wil.cx> Cc: James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
NeilBrown authored
commit 133d4527 upstream. When we write to a degraded array which has a bitmap, we make sure the relevant bit in the bitmap remains set when the write completes (so a 're-add' can quickly rebuilt a temporarily-missing device). If, immediately after such a write starts, we incorporate a spare, commence recovery, and skip over the region where the write is happening (because the 'needs recovery' flag isn't set yet), then that write will not get to the new device. Once the recovery finishes the new device will be trusted, but will have incorrect data, leading to possible corruption. We cannot set the 'needs recovery' flag when we start the write as we do not know easily if the write will be "degraded" or not. That depends on details of the particular raid level and particular write request. This patch fixes a corruption issue of long standing and so it suitable for any -stable kernel. It applied correctly to 3.0 at least and will minor editing to earlier kernels. Reported-by:
Bill <billstuff2001@sbcglobal.net> Tested-by:
NeilBrown <neilb@suse.de> Signed-off-by:
-
Michal Nazarewicz authored
commit f35f7124 upstream. It appears that no one ever run ffs-test on a big-endian machine, since it used cpu-endianess for fs_count and hs_count fields which should be in little-endian format. Fix by wrapping the numbers in cpu_to_le32. Signed-off-by:
Michal Nazarewicz <mina86@mina86.com> Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
-
J. Bruce Fields authored
commit 76f47128 upstream. An NFS operation that creates a new symlink includes the symlink data, which is xdr-encoded as a length followed by the data plus 0 to 3 bytes of zero-padding as required to reach a 4-byte boundary. The vfs, on the other hand, wants null-terminated data. The simple way to handle this would be by copying the data into a newly allocated buffer with space for the final null. The current nfsd_symlink code tries to be more clever by skipping that step in the (likely) case where the byte following the string is already 0. But that assumes that the byte following the string is ours to look at. In fact, it might be the first byte of a page that we can't read, or of some object that another task might modify. Worse, the NFSv4 code tries to fix the problem by actually writing to that byte. In the NFSv2/v3 cases this actually appears to be safe: - nfs3svc_decode_symlinkargs explicitly null-terminates the data (after first checking its length and copying it to a new page). - NFSv2 limits symlinks to 1k. The buffer holding the rpc request is always at least a page, and the link data (and previous fields) have maximum lengths that prevent the request from reaching the end of a page. In the NFSv4 case the CREATE op is potentially just one part of a long compound so can end up on the end of a page if you're unlucky. The minimal fix here is to copy and null-terminate in the NFSv4 case. The nfsd_symlink() interface here seems too fragile, though. It should really either do the copy itself every time or just require a null-terminated string. Reported-by:
Jeff Layton <jlayton@primarydata.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Paolo Bonzini authored
commit 7cb060a9 upstream. KVM does not really do much with the PAT, so this went unnoticed for a long time. It is exposed however if you try to do rdmsr on the PAT register. Reported-by:
Valentine Sinitsyn <valentine.sinitsyn@gmail.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Nadav Amit authored
commit 682367c4 upstream. Recent Intel CPUs have 10 variable range MTRRs. Since operating systems sometime make assumptions on CPUs while they ignore capability MSRs, it is better for KVM to be consistent with recent CPUs. Reporting more MTRRs than actually supported has no functional implications. Signed-off-by:
Nadav Amit <namit@cs.technion.ac.il> Signed-off-by:
-
Steve French authored
commit ce36d9ab upstream. When we SMB3 mounted with mapchars (to allow reserved characters : \ / > < * ? via the Unicode Windows to POSIX remap range) empty paths (eg when we open "" to query the root of the SMB3 directory on mount) were not null terminated so we sent garbarge as a path name on empty paths which caused SMB2/SMB2.1/SMB3 mounts to fail when mapchars was specified. mapchars is particularly important since Unix Extensions for SMB3 are not supported (yet) Signed-off-by:
Steve French <smfrench@gmail.com> Reviewed-by:
David Disseldorp <ddiss@suse.de> Signed-off-by:
-
Rafał Miłecki authored
commit 2fc68eb1 upstream. Support for firmware rev 508+ was added years ago, but we never noticed it reports channel in a different way for G-PHY devices. Instead of offset from 2400 MHz it simply passes channel id (AKA hw_value). So far it was (most probably) affecting monitor mode users only, but the following recent commit made it noticeable for quite everybody: commit 3afc2167 Author: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Date: Tue Mar 4 16:50:13 2014 +0200 cfg80211/mac80211: ignore signal if the frame was heard on wrong channel Reported-by:
Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by:
Rafał Miłecki <zajec5@gmail.com> Tested-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
-
David R. Piegdon authored
commit c021f241 upstream. Fix a parser-bug in the omap2 muxing code where muxtable-entries will be wrongly selected if the requested muxname is a *prefix* of their m0-entry and they have a matching mN-entry. Fix by additionally checking that the length of the m0_entry is equal. For example muxing of "dss_data2.dss_data2" on omap32xx will fail because the prefix "dss_data2" will match the mux-entries "dss_data2" as well as "dss_data20", with the suffix "dss_data2" matching m0 (for dss_data2) and m4 (for dss_data20). Thus both are recognized as signal path candidates: Relevant muxentries from mux34xx.c: _OMAP3_MUXENTRY(DSS_DATA20, 90, "dss_data20", NULL, "mcspi3_somi", "dss_data2", "gpio_90", NULL, NULL, "safe_mode"), _OMAP3_MUXENTRY(DSS_DATA2, 72, "dss_data2", NULL, NULL, NULL, "gpio_72", NULL, NULL, "safe_mode"), This will result in a failure to mux the pin at all: _omap_mux_get_by_name: Multiple signal paths (2) for dss_data2.dss_data2 Patch should apply to linus' latest master down to rather old linux-2.6 trees. Signed-off-by:
David R. Piegdon <lkml@p23q.org> Cc: stable@vger.kernel.org [tony@atomide.com: updated description to include full description] Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Arik Nemtsov authored
commit 923eaf36 upstream. Doing so will lead to an oops for a p2p-dev interface, since it has no netdev. Signed-off-by:
Arik Nemtsov <arikx.nemtsov@intel.com> Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Syam Sidhardhan authored
commit e10b9969 upstream. In this API, we were using sizeof operator for an array given as function argument, which is invalid. However this API is not used anywhere. Signed-off-by:
Syam Sidhardhan <s.syam@samsung.com> Signed-off-by:
Gustavo Padovan <gustavo@padovan.org> Signed-off-by:
-
Johan Hedberg authored
commit ba15a58b upstream. From the Bluetooth Core Specification 4.1 page 1958: "if both devices have set the Authentication_Requirements parameter to one of the MITM Protection Not Required options, authentication stage 1 shall function as if both devices set their IO capabilities to DisplayOnly (e.g., Numeric comparison with automatic confirmation on both devices)" So far our implementation has done user confirmation for all just-works cases regardless of the MITM requirements, however following the specification to the word means that we should not be doing confirmation when neither side has the MITM flag set. Signed-off-by:
Johan Hedberg <johan.hedberg@intel.com> Tested-by:
Szymon Janc <szymon.janc@tieto.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Thomas Hellstrom authored
commit 4e578080 upstream. Commit "drm/vmwgfx: correct fb_fix_screeninfo.line_length", while fixing a vmwgfx fbdev bug, also writes the pitch to a supposedly read-only register: SVGA_REG_BYTES_PER_LINE, while it should be (and also in fact is) written to SVGA_REG_PITCHLOCK. This patch is Cc'd stable because of the unknown effects writing to this register might have, particularly on older device versions. v2: Updated log message. Cc: Christopher Friedt <chrisfriedt@gmail.com> Tested-by:
Christopher Friedt <chrisfriedt@gmail.com> Signed-off-by:
Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by:
Jakob Bornecrantz <jakob@vmware.com> Signed-off-by:
-
Alex Deucher authored
commit 64252835 upstream. We need to specify the encoder mode as LVDS for eDP when using the Crtc_Source atom table in order to properly set up the FMT hardware. bug: https://bugs.freedesktop.org/show_bug.cgi?id=73911Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Alex Deucher authored
commit af5d3653 upstream. We were checking the ext clock rather than the display clock. Noticed by ArtForz on IRC. Signed-off-by:
-
Alex Deucher authored
commit 7d5ab300 upstream. May fix display issues with non-HDMI displays. Signed-off-by:
-
Thomas Petazzoni authored
commit b7e46062 upstream. The pxa3xx_nand driver currently uses __raw_writel() and __raw_readl() to access I/O registers. However, those functions do not do any endianness swapping, which means that they won't work when the CPU runs in big-endian but the I/O registers are little endian, which is the common situation for ARM systems running big endian. Since __raw_writel() and __raw_readl() do not include any memory barriers and the pxa3xx_nand driver can only be compiled for ARM platforms, the closest I/o accessors functions that do endianess swapping are writel_relaxed() and readl_relaxed(). This patch has been verified to work on Armada XP GP: without the patch, the NAND is not detected when the kernel runs big endian while it is properly detected when the kernel runs little endian. With the patch applied, the NAND is properly detected in both situations (little and big endian). Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
Brian Norris <computersforpeace@gmail.com> Signed-off-by:
-
Stanislaw Gruszka authored
commit 616a8394 upstream. As reported by Niels, starting rfkill polling during device probe (commit e2bc7c5f, generally sane change) broke rfkill on rt2500pci device. I considered that bug as some initalization issue, which should be fixed on rt2500pci specific code. But after several attempts (see bug report for details) we fail to find working solution. Hence I decided to revert to old behaviour on rt2500pci to fix regression. Additionally patch also unregister rfkill on device remove instead of ifconfig down, what was another issue introduced by bad commit. Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=73821 Fixes: e2bc7c5f ("rt2x00: Fix rfkill_polling register function.") Bisected-by:
Niels <nille0386@googlemail.com> Reported-and-tested-by:
Stanislaw Gruszka <stf_xl@wp.pl> Signed-off-by:
-
Stanislaw Gruszka authored
commit 8edcb0ba upstream. On USB we can not get atomically TKIP key. We have to disable support for TKIP acceleration on USB hardware to avoid bug as showed bellow. [ 860.827243] BUG: scheduling while atomic: hostapd/3397/0x00000002 <snip> [ 860.827280] Call Trace: [ 860.827282] [<ffffffff81682ea6>] dump_stack+0x4d/0x66 [ 860.827284] [<ffffffff8167eb9b>] __schedule_bug+0x47/0x55 [ 860.827285] [<ffffffff81685bb3>] __schedule+0x733/0x7b0 [ 860.827287] [<ffffffff81685c59>] schedule+0x29/0x70 [ 860.827289] [<ffffffff81684f8a>] schedule_timeout+0x15a/0x2b0 [ 860.827291] [<ffffffff8105ac50>] ? ftrace_raw_event_tick_stop+0xc0/0xc0 [ 860.827294] [<ffffffff810c13c2>] ? __module_text_address+0x12/0x70 [ 860.827296] [<ffffffff81686823>] wait_for_completion_timeout+0xb3/0x140 [ 860.827298] [<ffffffff81080fc0>] ? wake_up_state+0x20/0x20 [ 860.827301] [<ffffffff814d5b3d>] usb_start_wait_urb+0x7d/0x150 [ 860.827303] [<ffffffff814d5cd5>] usb_control_msg+0xc5/0x110 [ 860.827305] [<ffffffffa02fb0c6>] rt2x00usb_vendor_request+0xc6/0x160 [rt2x00usb] [ 860.827307] [<ffffffffa02fb215>] rt2x00usb_vendor_req_buff_lock+0x75/0x150 [rt2x00usb] [ 860.827309] [<ffffffffa02fb393>] rt2x00usb_vendor_request_buff+0xa3/0xe0 [rt2x00usb] [ 860.827311] [<ffffffffa023d1a3>] rt2x00usb_register_multiread+0x33/0x40 [rt2800usb] [ 860.827314] [<ffffffffa05805f9>] rt2800_get_tkip_seq+0x39/0x50 [rt2800lib] [ 860.827321] [<ffffffffa0480f88>] ieee80211_get_key+0x218/0x2a0 [mac80211] [ 860.827322] [<ffffffff815cc68c>] ? __nlmsg_put+0x6c/0x80 [ 860.827329] [<ffffffffa051b02e>] nl80211_get_key+0x22e/0x360 [cfg80211] Reported-and-tested-by:
Peter Wu <lekensteyn@gmail.com> Reported-and-tested-by:
Pontus Fuchs <pontus.fuchs@gmail.com> Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Signed-off-by:
-
Michal Nazarewicz authored
commit f0688c8b upstream. If the descriptors do not need any strings and user space sends empty set of strings, the ffs->stringtabs field remains NULL. Thus *ffs->stringtabs in functionfs_bind leads to a NULL pointer dereferenece. The bug was introduced by commit [fd7c9a00: “use usb_string_ids_n()”]. While at it, remove double initialisation of lang local variable in that function. ffs->strings_count does not need to be checked in any way since in the above scenario it will remain zero and usb_string_ids_n() is a no-operation when colled with 0 argument. Signed-off-by:
-
Johan Hovold authored
commit aea1ae87 upstream. Fix NULL-pointer dereference when probing an interface with no endpoints. These devices have two bulk endpoints per interface, but this avoids crashing the kernel if a user forces a non-FTDI device to be probed. Note that the iterator variable was made unsigned in order to avoid a maybe-uninitialized compiler warning for ep_desc after the loop. Fixes: 895f28ba ("USB: ftdi_sio: fix hi-speed device packet size calculation") Reported-by:
Mike Remski <mremski@mutualink.net> Tested-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Bjørn Mork authored
commit b0ebef36 upstream. Adding a couple of Olivetti modems and blacklisting the net function on a couple which are already supported. Reported-by:
Lars Melin <larsm17@gmail.com> Signed-off-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Oliver Neukum authored
commit 1cab4c68 upstream. Reported by Alif Mubarak Ahmad: This device vendor and product id is 1c9e:9800 It is working as serial interface with generic usbserial driver. I thought it is more suitable to use usbserial option driver, which has better capability distinguishing between modem serial interface and micro sd storage interface. [ johan: style changes ] Signed-off-by:
Oliver Neukum <oneukum@suse.de> Tested-by:
Alif Mubarak Ahmad <alive4ever@live.com> Signed-off-by:
-
Bjørn Mork authored
commit 17b72feb upstream. Matching on device and interface class with with unspecified subclass and protocol is sometimes useful. This is slightly different from USB_DEVICE_AND_INTERFACE_INFO which requires the full interface class/subclass/protocol triplet. Signed-off-by:
-
Wang, Yu authored
commit d6236f6d upstream. The system suspend flow as following: 1, Freeze all user processes and kenrel threads. 2, Try to suspend all devices. 2.1, If pci device is in RPM suspended state, then pci driver will try to resume it to RPM active state in the prepare stage. 2.2, xhci_resume function calls usb_hcd_resume_root_hub to queue two workqueue items to resume usb2&usb3 roothub devices. 2.3, Call suspend callbacks of devices. 2.3.1, All suspend callbacks of all hcd's children, including roothub devices are called. 2.3.2, Finally, hcd_pci_suspend callback is called. Due to workqueue threads were already frozen in step 1, the workqueue items can't be scheduled, and the roothub devices can't be resumed in this flow. The HCD_FLAG_WAKEUP_PENDING flag which is set in usb_hcd_resume_root_hub won't be cleared. Finally, hcd_pci_suspend will return -EBUSY, and system suspend fails. The reason why this issue doesn't show up very often is due to that choose_wakeup will be called in step 2.3.1. In step 2.3.1, if udev->do_remote_wakeup is not equal to device_may_wakeup(&udev->dev), then udev will resume to RPM active for changing the wakeup settings. This has been a lucky hit which hides this issue. For some special xHCI controllers which have no USB2 port, then roothub will not match hub driver due to probe failed. Then its do_remote_wakeup will be set to zero, and we won't be as lucky. xhci driver doesn't need to resume roothub devices everytime like in the above case. It's only needed when there are pending event TRBs. This patch should be back-ported to kernels as old as 3.2, that contains the commit f69e3120 "USB: XHCI: resume root hubs when the controller resumes" Signed-off-by:
Wang, Yu <yu.y.wang@intel.com> Acked-by:
Alan Stern <stern@rowland.harvard.edu> [use readl() instead of removed xhci_readl(), reword commit message -Mathias] Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Signed-off-by:
-
Mathias Nyman authored
commit 3213b151 upstream. The transfer burst count (TBC) field in xhci 1.0 hosts should be set to the number of bursts needed to transfer all packets in a isoc TD. Supported values are 0-2 (1 to 3 bursts per service interval). Formula for TBC calculation is given in xhci spec section 4.11.2.3: TBC = roundup( Transfer Descriptor Packet Count / Max Burst Size +1 ) - 1 This patch should be applied to stable kernels since 3.0 that contain the commit 5cd43e33 "xhci 1.0: Set transfer burst count field." Suggested-by:
ShiChun Ma <masc2008@qq.com> Signed-off-by:
-
Brian King authored
commit 9ee75597 upstream. If a CRQ reset is triggered for some reason while in the middle of performing VSCSI adapter initialization, we don't want to call the done function for the initialization MAD commands as this will only result in two threads attempting initialization at the same time, resulting in failures. Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> Acked-by:
Nathan Fontenot <nfont@linux.vnet.ibm.com> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
- 07 Jul, 2014 9 commits
-
-
Greg Kroah-Hartman authored
-
Oleg Nesterov authored
commit 4af4206b upstream. syscall_regfunc() and syscall_unregfunc() should set/clear TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race with copy_process() and miss the new child which was not added to the process/thread lists yet. Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT under tasklist. Link: http://lkml.kernel.org/p/20140413185854.GB20668@redhat.com Fixes: a871bd33 "tracing: Add syscall tracepoints" Acked-by:
Frederic Weisbecker <fweisbec@gmail.com> Acked-by:
Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Tejun Heo authored
commit b9cd18de upstream. The 'sysret' fastpath does not correctly restore even all regular registers, much less any segment registers or reflags values. That is very much part of why it's faster than 'iret'. Normally that isn't a problem, because the normal ptrace() interface catches the process using the signal handler infrastructure, which always returns with an iret. However, some paths can get caught using ptrace_event() instead of the signal path, and for those we need to make sure that we aren't going to return to user space using 'sysret'. Otherwise the modifications that may have been done to the register set by the tracer wouldn't necessarily take effect. Fix it by forcing IRET path by setting TIF_NOTIFY_RESUME from arch_ptrace_stop_needed() which is invoked from ptrace_stop(). Signed-off-by:
Tejun Heo <tj@kernel.org> Reported-by:
Andy Lutomirski <luto@amacapital.net> Acked-by:
-
Paul Bolle authored
commit b69a1da9 upstream. Commit cd64d169 ("powerpc: mtmsrd not defined") added a check for CONFIG_PPC_CPU were a check for CONFIG_PPC_FPU was clearly intended. Fixes: cd64d169 ("powerpc: mtmsrd not defined") Signed-off-by:
Paul Bolle <pebolle@tiscali.nl> Signed-off-by:
Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by:
-
Paul Bolle authored
commit 6e0fdf9a upstream. Commit b0d278b7 ("powerpc/perf_event: Reduce latency of calling perf_event_do_pending") added a check for CONFIG_PMAC were a check for CONFIG_PPC_PMAC was clearly intended. Fixes: b0d278b7 ("powerpc/perf_event: Reduce latency of calling perf_event_do_pending") Signed-off-by:
-
Gavin Shan authored
commit 54f112a3 upstream. In pseries_eeh_get_state(), EEH_STATE_UNAVAILABLE is always overwritten by EEH_STATE_NOT_SUPPORT because of the missed "break" there. The patch fixes the issue. Reported-by:
Joe Perches <joe@perches.com> Signed-off-by:
Gavin Shan <gwshan@linux.vnet.ibm.com> Signed-off-by:
-
Christoph Hellwig authored
commit 12337901 upstream. Note nobody's ever noticed because the typical client probably never requests FILES_AVAIL without also requesting something else on the list. Signed-off-by:
-
J. Bruce Fields authored
commit 48385408 upstream. 27b11428 ("nfsd4: remove lockowner when removing lock stateid") introduced a memory leak. Reported-by:
Jeff Layton <jeff.layton@primarydata.com> Signed-off-by:
-
Bart Van Assche authored
commit 60e1751c upstream. Avoid that closing /dev/infiniband/umad<n> or /dev/infiniband/issm<n> triggers a use-after-free. __fput() invokes f_op->release() before it invokes cdev_put(). Make sure that the ib_umad_device structure is freed by the cdev_put() call instead of f_op->release(). This avoids that changing the port mode from IB into Ethernet and back to IB followed by restarting opensmd triggers the following kernel oops: general protection fault: 0000 [#1] PREEMPT SMP RIP: 0010:[<ffffffff810cc65c>] [<ffffffff810cc65c>] module_put+0x2c/0x170 Call Trace: [<ffffffff81190f20>] cdev_put+0x20/0x30 [<ffffffff8118e2ce>] __fput+0x1ae/0x1f0 [<ffffffff8118e35e>] ____fput+0xe/0x10 [<ffffffff810723bc>] task_work_run+0xac/0xe0 [<ffffffff81002a9f>] do_notify_resume+0x9f/0xc0 [<ffffffff814b8398>] int_signal+0x12/0x17 Reference: https://bugzilla.kernel.org/show_bug.cgi?id=75051Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Reviewed-by:
Yann Droneaud <ydroneaud@opteya.com> Signed-off-by:
Roland Dreier <roland@purestorage.com> Signed-off-by:
-
