- 03 Sep, 2015 1 commit
-
-
Boris Ostrovsky authored
[ Upstream commit 5054daa2 ] Commit 1e02ce4c ("x86: Store a per-cpu shadow copy of CR4") introduced CR4 shadows. These shadows are initialized in early boot code. The commit missed initialization for 64-bit PV(H) guests that this patch adds. Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
Sasha Levin <sasha.levin@oracle.com>
-
- 31 Aug, 2015 1 commit
-
-
Sasha Levin authored
Signed-off-by:
-
- 27 Aug, 2015 38 commits
-
-
Alexander Duyck authored
[ Upstream commit d55c670c ] The vti6_rcv_cb and vti_rcv_cb calls were leaving the skb->mark modified after completing the function. This resulted in the original skb->mark value being lost. Since we only need skb->mark to be set for xfrm_policy_check we can pull the assignment into the rcv_cb calls and then just restore the original mark after xfrm_policy_check has been completed. Signed-off-by:
Alexander Duyck <alexander.h.duyck@redhat.com> Signed-off-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Alexander Duyck authored
[ Upstream commit 049f8e2e ] This change makes it so that if a tunnel is defined we just use the mark from the tunnel instead of the mark from the skb header. By doing this we can avoid the need to set skb->mark inside of the tunnel receive functions. Signed-off-by:
-
Alexander Duyck authored
[ Upstream commit cd5279c1 ] Instead of modifying skb->mark we can simply modify the flowi_mark that is generated as a result of the xfrm_decode_session. By doing this we don't need to actually touch the skb->mark and it can be preserved as it passes out through the tunnel. Signed-off-by:
-
Martin K. Petersen authored
[ Upstream commit 9051bd39 ] A new Micron drive was just announced, once again recycling the first part of the model string. Add an underscore to the M510/M550 pattern to avoid picking up the new DC drive. Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Tejun Heo <tj@kernel.org> Signed-off-by:
-
Arne Fitzenreiter authored
[ Upstream commit cda57b1b ] This device loses blocks, often the partition table area, on trim. Disable TRIM. http://pcengines.ch/msata16a.htmSigned-off-by:
Arne Fitzenreiter <arne_f@ipfire.org> Signed-off-by:
-
Arne Fitzenreiter authored
[ Upstream commit 71d126fd ] Some devices lose data on TRIM whether queued or not. This patch adds a horkage to disable TRIM. tj: Collapsed unnecessary if() nesting. Signed-off-by:
-
Martin K. Petersen authored
[ Upstream commit f3030741 ] Create a sysfs "trim" attribute for each ata_device that displays whether DSM TRIM is "unsupported", "unqueued", "forced_unqueued" (blacklisted) or "queued". Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
-
Martin K. Petersen authored
[ Upstream commit 243918be ] Queued TRIM got disabled on Micron M500DC drives thanks to the "Micron_M500*" pattern we had in place to accommodate the previous generation of this drive family. Tweak the blacklist entry slightly so we only disable queued TRIM for the non-DC variants of M500 drives. Signed-off-by:
-
Martin K. Petersen authored
[ Upstream commit 9a9324d3 ] The queued TRIM problems appear to be generic to Samsung's firmware and not tied to a particular model. A recent update to the 840 EVO firmware introduced the same issue as we saw on 850 Pro. Blacklist queued TRIM on all 800-series drives while we work this issue with Samsung. Reported-by:
Günter Waller <g.wal@web.de> Reported-by:
Sven Köhler <sven.koehler@gmail.com> Signed-off-by:
-
Martin K. Petersen authored
[ Upstream commit 6fc4d97a ] Blacklist queued TRIM on this drive for now. Reported-by:
Stefan Keller <linux-list@zahlenfresser.de> Signed-off-by:
-
Martin K. Petersen authored
[ Upstream commit ff7f53fb ] Micron has released an updated firmware (MU02) for M510/M550/MX100 drives to fix the issues with queued TRIM. Queued TRIM remains broken on M500 but is working fine on later drives such as M600 and MX200. Tweak our blacklist to reflect the above. Link: https://bugzilla.kernel.org/show_bug.cgi?id=71371Signed-off-by:
-
Martin K. Petersen authored
[ Upstream commit e61f7d1c ] As defined, the DRAT (Deterministic Read After Trim) and RZAT (Return Zero After Trim) flags in the ATA Command Set are unreliable in the sense that they only define what happens if the device successfully executed the DSM TRIM command. TRIM is only advisory, however, and the device is free to silently ignore all or parts of the request. In practice this renders the DRAT and RZAT flags completely useless and because the results are unpredictable we decided to disable discard in MD for 3.18 to avoid the risk of data corruption. Hardware vendors in the real world obviously need better guarantees than what the standards bodies provide. Unfortuntely those guarantees are encoded in product requirements documents rather than somewhere we can key off of them programatically. So we are compelled to disabling discard_zeroes_data for all devices unless we explicitly have data to support whitelisting them. This patch whitelists SSDs from a few of the main vendors. None of the whitelists are based on written guarantees. They are purely based on empirical evidence collected from internal and external users that have tested or qualified these drives in RAID deployments. The whitelist is only meant as a starting point and is by no means comprehensive: - All intel SSD models except for 510 - Micron M5?0/M600 - Samsung SSDs - Seagate SSDs Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Sasha Levin authored
This reverts commit e7a84605.
-
Joe Perches authored
[ Upstream commit a28e4b2b ] Removing unnecessary static buffers is good. Use the vsprintf %pV extension instead. Signed-off-by:
Joe Perches <joe@perches.com> Signed-off-by:
Mikulas Patocka <mikulas@twibright.com> Cc: stable@vger.kernel.org # v2.6.36+ Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Len Brown authored
[ Upstream commit bea57077 ] Signed-off-by:
Len Brown <len.brown@intel.com> Signed-off-by:
-
Martin Schwidefsky authored
[ Upstream commit 7e01b5ac ] Introduce KEXEC_CONTROL_MEMORY_GFP to allow the architecture code to override the gfp flags of the allocation for the kexec control page. The loop in kimage_alloc_normal_control_pages allocates pages with GFP_KERNEL until a page is found that happens to have an address smaller than the KEXEC_CONTROL_MEMORY_LIMIT. On systems with a large memory size but a small KEXEC_CONTROL_MEMORY_LIMIT the loop will keep allocating memory until the oom killer steps in. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Devin Ryles authored
[ Upstream commit 3eee1799 ] Signed-off-by:
Devin Ryles <devin.ryles@intel.com> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Libin Yang authored
[ Upstream commit 432ac1a2 ] Skylake and Haswell have the same behavior on display audio. So this patch applys Haswell fix-ups to Skylake. Signed-off-by:
Libin Yang <libin.yang@intel.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Libin Yang authored
[ Upstream commit 99fcb377 ] This patch adds codec ID (0x80862809) and module alias for Skylake display codec. Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit b136faff ] 'channels' is allocated via kmemdup and it is never freed in the subsequent error paths. Use 'indio_dev->channels' directly instead, so that we avoid such memory leak problem. Signed-off-by:
Fabio Estevam <fabio.estevam@freescale.com> Reviewed-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit d8c9d23e ] 'channels' is allocated via kmemdup and it is never freed in the subsequent error paths. Use 'indio_dev->channels' directly instead, so that we avoid such memory leak problem. Signed-off-by:
-
Fabio Estevam authored
[ Upstream commit 9ecdbed7 ] 'channels' is allocated via kmemdup and it is never freed in the subsequent error paths. Use 'indio_dev->channels' directly instead, so that we avoid such memory leak problem. Signed-off-by:
-
Yoshihiro Shimoda authored
[ Upstream commit 11313746 ] On R-Mobile APE6, since it has 3 thermal zones, ENR register has enable bits in bit 19-16, bit 11-8 and bit 3-0. However, on R-Car gen2, since it has 1 thermal zone, ENR register has enable bits in bit 3-0. (In other words, the write value should always be 0 for bit 31-4 of ENR register.) So, this patch fixes the ENR register value using I/O resource sets. Acked-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
Eduardo Valentin <edubezval@gmail.com> Signed-off-by:
-
Yann Droneaud authored
[ Upstream commit d6c763af ] Since commit 8a0a9bd4 ('random: make get_random_int() more random'), get_random_int() returns a random value for each call, so comment and hack introduced in mmap_rnd() as part of commit 1d18c47c ('arm64: MMU fault handling and page table management') are incorrects. Commit 1d18c47c seems to use the same hack introduced by commit a5adc91a ('powerpc: Ensure random space between stack and mmaps'), latter copied in commit 5a0efea0 ('sparc64: Sharpen address space randomization calculations.'). But both architectures were cleaned up as part of commit fa8cbaaf ('powerpc+sparc64/mm: Remove hack in mmap randomize layout') as hack is no more needed since commit 8a0a9bd4. So the present patch removes the comment and the hack around get_random_int() on AArch64's mmap_rnd(). Cc: David S. Miller <davem@davemloft.net> Cc: Anton Blanchard <anton@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Acked-by:
Will Deacon <will.deacon@arm.com> Acked-by:
Dan McGee <dpmcgee@gmail.com> Signed-off-by:
Yann Droneaud <ydroneaud@opteya.com> Signed-off-by:
-
Wen-chien Jesse Sung authored
[ Upstream commit ca79f232 ] Device info in /sys/kernel/debug/usb/devices: T: Bus=01 Lev=01 Prnt=01 Port=05 Cnt=02 Dev#= 3 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=0cf3 ProdID=e006 Rev= 0.01 C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=81(I) Atr=03(Int.) MxPS= 16 Ivl=1ms E: Ad=82(I) Atr=02(Bulk) MxPS= 64 Ivl=0ms E: Ad=02(O) Atr=02(Bulk) MxPS= 64 Ivl=0ms I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 0 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 0 Ivl=1ms I: If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 9 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 9 Ivl=1ms I: If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 17 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 17 Ivl=1ms I: If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 25 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 25 Ivl=1ms I: If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 33 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 33 Ivl=1ms I: If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb E: Ad=83(I) Atr=01(Isoc) MxPS= 49 Ivl=1ms E: Ad=03(O) Atr=01(Isoc) MxPS= 49 Ivl=1ms Signed-off-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Signed-off-by:
-
Kristian Evensen authored
[ Upstream commit a8c8316b ] The Microchip Pick16F1454 is exported as a HID device and is used by for example the Yepkit YKUSH three-port switchable USB hub. However, it is not an actual HID-device. On the Yepkit, it is used to power up/down the ports on the hub. The HID driver should ignore this device. Signed-off-by:
Kristian Evensen <kristian.evensen@gmail.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Dinesh Ram authored
[ Upstream commit adc23259 ] The Si4713 development board contains a Si4713 FM transmitter chip and is handled by the radio-usb-si4713 driver. The board reports itself as (10c4:8244) Cygnal Integrated Products, Inc. and misidentifies itself as a HID device in its USB interface descriptor. This patch ignores this device as an HID device and hence loads the custom driver. Signed-off-by:
Dinesh Ram <dinesh.ram@cern.ch> Signed-off-by:
Hans Verkuil <hans.verkuil@cisco.com> Tested-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by:
-
Forest Wilkinson authored
[ Upstream commit 9b028649 ] The linux kernel has supported the TiVo Slide remote control for some time, but does not recognize the USB ID of the newer Slide Pro. This patch adds the missing data structures so the newer remote will be recognized by the driver, thereby allowing the TiVo, LiveTV, and Thumbs Up/Down buttons to be mapped with a hwdb file. Signed-off-by:
Forest Wilkinson <web11.forest@tibit.com> Signed-off-by:
-
Stephen M. Cameron authored
[ Upstream commit 7d2cce58 ] Fix a couple of pci id table mistakes: Subdevice ID 0x3323 missing from product[] table (another name for HP Smart Storage 1210m) Bogus 0x1925 subdevice id removed from hpsa_pci_device_id[] (no such thing.) Signed-off-by:
Don Brace <don.brace@pmcs.com> Reviewed-by:
Webb Scales <webbnh@hp.com> Signed-off-by:
-
Lenny Szubowicz authored
[ Upstream commit 7e7e8fe6 ] The pcc-cpufreq driver is not automatically loaded on systems where the platform's power management setting requires this driver. Instead, on those systems no CPU frequency driver is registered and active. Make the autoloading matching criteria for loading the pcc-cpufreq driver the same as done in acpi-cpufreq by commit c655affb ("ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq"). x86 CPU frequency drivers are now typically autoloaded by specifying MODULE_DEVICE_TABLE entries and x86cpu model specific matching. But pcc-cpufreq was omitted when acpi-cpufreq and other drivers were changed to use this approach. Both acpi-cpufreq and pcc-cpufreq depend on a distinct and mutually exclusive set of ACPI methods which are not directly tied to specific processor model numbers. Both of these drivers have init routines which look for their required ACPI methods. As a result, only the appropriate driver registers as the cpu frequency driver and the other one ends up being unloaded. Tested on various systems where acpi-cpufreq, intel_pstate, and pcc-cpufreq are the expected cpu frequency drivers. Signed-off-by:
Lenny Szubowicz <lszubowi@redhat.com> Signed-off-by:
Joseph Szczypek <joseph.szczypek@hp.com> Reported-by:
Trinh Dao <trinh.dao@hp.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Yoshihiro Shimoda authored
[ Upstream commit b4c25261 ] commit 93fb9127 upstream. This patch fixes an issue that sometimes this controller is not able to complete the Control write status stage. This driver should enable DCPCTR.CCPL and PID_BUF to complete the status stage. However, if this driver detects the ctrl_stage interruption first before the control write data is received, this driver will clear the PID_BUF wrongly in the usbhsf_pio_try_pop(). To avoid this issue, this patch doesn't clear the PID_BUF in the usbhsf_pio_try_pop(). (Since also the privious code doesn't disable the PID_BUF after a control transfer was finished, this patch doesn't have any side efforts.) Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Signed-off-by:
-
Kazuya Mizuguchi authored
[ Upstream commit 5e582ff3 ] This patch fixes an issue for control write. When usbhsf_prepare_pop() is called after this driver called a gadget setup function, this controller doesn't receive the control write data. So, this patch adds a code to clear the fifo for control write in usbhsf_prepare_pop(). Signed-off-by:
Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Jeff Mahoney authored
[ Upstream commit 727b9784 ] Orphans in the fs tree are cleaned up via open_ctree and subvolume orphans are cleaned via btrfs_lookup_dentry -- except when a default subvolume is in use. The name for the default subvolume uses a manual lookup that doesn't trigger orphan cleanup and needs to trigger it manually as well. This doesn't apply to the remount case since the subvolumes are cleaned up by walking the root radix tree. Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Reviewed-by:
David Sterba <dsterba@suse.cz> Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
Chengyu Song authored
[ Upstream commit 26e726af ] fiemap_fill_next_extent returns 0 on success, -errno on error, 1 if this was the last extent that will fit in user array. If 1 is returned, the return value may eventually returned to user space, which should not happen, according to manpage of ioctl. Signed-off-by:
Chengyu Song <csong84@gatech.edu> Reviewed-by:
Liu Bo <bo.li.liu@oracle.com> Signed-off-by:
-
Axel Lin authored
[ Upstream commit e5d73218 ] Remove extra space between platform prefix and DRIVER_NAME in MODULE_ALIAS. Signed-off-by:
Axel Lin <axel.lin@ingics.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
-
NeilBrown authored
[ Upstream commit HEAD ] commit b97e9257 upstream Use separate bitmaps for each nodes in the cluster bitmap_read_sb() validates the bitmap superblock that it reads in. If it finds an inconsistency like a bad magic number or out-of-range version number, it prints an error and returns, but it incorrectly returns zero, so the array is still assembled with the (invalid) bitmap. This means it could try to use a bitmap with a new version number which it therefore does not understand. This bug was introduced in 3.5 and fix as part of a larger patch in 4.1. So the patch is suitable for any -stable kernel in that range. Fixes: 27581e5a ("md/bitmap: centralise allocation of bitmap file pages.") Signed-off-by:
NeilBrown <neilb@suse.com> Reported-by:
GuoQing Jiang <gqjiang@suse.com> (cherry picked from commit ed969167) Signed-off-by:
-
Al Viro authored
[ Upstream commit 451a2886 ] unfortunately, allowing an arbitrary 16bit value means a possibility of overflow in the calculation of total number of pages in bio_map_user_iov() - we rely on there being no more than PAGE_SIZE members of sum in the first loop there. If that sum wraps around, we end up allocating too small array of pointers to pages and it's easy to overflow it in the second loop. X-Coverup: TINC (and there's no lumber cartel either) Cc: stable@vger.kernel.org # way, way back Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Nicholas Bellinger authored
[ Upstream commit e5419865 ] This patch fixes a regression introduced with the following commit in v4.0-rc1 code, where a iscsit_start_kthreads() failure triggers a NULL pointer dereference OOPs: commit 88dcd2da Author: Nicholas Bellinger <nab@linux-iscsi.org> Date: Thu Feb 26 22:19:15 2015 -0800 iscsi-target: Convert iscsi_thread_set usage to kthread.h To address this bug, move iscsit_start_kthreads() immediately preceeding the transmit of last login response, before signaling a successful transition into full-feature-phase within existing iscsi_target_do_tx_login_io() logic. This ensures that no target-side resource allocation failures can occur after the final login response has been successfully sent. Also, it adds a iscsi_conn->rx_login_comp to allow the RX thread to sleep to prevent other socket related failures until the final iscsi_post_login_handler() call is able to complete. Cc: Sagi Grimberg <sagig@mellanox.com> Cc: <stable@vger.kernel.org> # v3.10+ Signed-off-by:
Nicholas Bellinger <nab@linux-iscsi.org> Signed-off-by:
-
