commit 28895317f9a7d726cd13fc9b5447cb5dcb5cd22c Author: Zefan Li Date: Mon Feb 2 17:05:26 2015 +0800 Linux 3.4.106 commit e02ae9ddc8130c8a83c3439d24ac831608384fc9 Author: Ben Hutchings Date: Thu Oct 30 18:27:17 2014 +0000 drivers/net, ipv6: Select IPv6 fragment idents for virtio UFO packets commit 5188cd44c55db3e92cd9e77a40b5baa7ed4340f7 upstream. UFO is now disabled on all drivers that work with virtio net headers, but userland may try to send UFO/IPv6 packets anyway. Instead of sending with ID=0, we should select identifiers on their behalf (as we used to). Signed-off-by: Ben Hutchings Fixes: 916e4cf46d02 ("ipv6: reuse ip6_frag_id from ip6_ufo_append_data") Signed-off-by: David S. Miller [bwh: For 3.2, net/ipv6/output_core.c is a completely new file] Signed-off-by: Zefan Li commit fd873bf1ce5477514515e82aa8acdc7ec06a9b97 Author: Jeffrey Knockel Date: Fri Dec 12 06:14:26 2014 +0000 Patch for 3.2.x, 3.4.x IP identifier regression commit c3b4ccb8b03769e2867fabecc078483ee6710ccf upstream. With commits 73f156a6e8c1 ("inetpeer: get rid of ip_id_count") and 04ca6973f7c1 ("ip: make IP identifiers less predictable"), IP identifiers are generated from a counter chosen from an array of counters indexed by the hash of the outgoing packet header's source address, destination address, and protocol number. Thus, in __ip_make_skb(), we must now call ip_select_ident() only after setting these fields in the IP header to prevent IP identifiers from being generated from bogus counters. IP id sequence before fix: 18174, 5789, 5953, 59420, 59637, ... After fix: 5967, 6185, 6374, 6600, 6795, 6892, 7051, 7288, ... Signed-off-by: Jeffrey Knockel Signed-off-by: Ben Hutchings Cc: Eric Dumazet [Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit cfa0515dc4826a9d14bc871d88d6d80bafe0e7cf Author: Nadav Amit Date: Tue Oct 28 00:03:43 2014 +0200 KVM: x86: Fix far-jump to non-canonical check commit 7e46dddd6f6cd5dbf3c7bd04a7e75d19475ac9f2 upstream. Commit d1442d85cc30 ("KVM: x86: Handle errors when RIP is set during far jumps") introduced a bug that caused the fix to be incomplete. Due to incorrect evaluation, far jump to segment with L bit cleared (i.e., 32-bit segment) and RIP with any of the high bits set (i.e, RIP[63:32] != 0) set may not trigger #GP. As we know, this imposes a security problem. In addition, the condition for two warnings was incorrect. Fixes: d1442d85cc30ea75f7d399474ca738e0bc96f715 Reported-by: Dan Carpenter Signed-off-by: Nadav Amit [Add #ifdef CONFIG_X86_64 to avoid complaints of undefined behavior. - Paolo] Signed-off-by: Paolo Bonzini Signed-off-by: Zefan Li commit 29adeacbed114e97e7aaee3bb2e4be65ec806dcb Author: Andy Lutomirski Date: Thu Jan 22 11:27:59 2015 -0800 x86, tls: Interpret an all-zero struct user_desc as "no segment" commit 3669ef9fa7d35f573ec9c0e0341b29251c2734a7 upstream. The Witcher 2 did something like this to allocate a TLS segment index: struct user_desc u_info; bzero(&u_info, sizeof(u_info)); u_info.entry_number = (uint32_t)-1; syscall(SYS_set_thread_area, &u_info); Strictly speaking, this code was never correct. It should have set read_exec_only and seg_not_present to 1 to indicate that it wanted to find a free slot without putting anything there, or it should have put something sensible in the TLS slot if it wanted to allocate a TLS entry for real. The actual effect of this code was to allocate a bogus segment that could be used to exploit espfix. The set_thread_area hardening patches changed the behavior, causing set_thread_area to return -EINVAL and crashing the game. This changes set_thread_area to interpret this as a request to find a free slot and to leave it empty, which isn't *quite* what the game expects but should be close enough to keep it working. In particular, using the code above to allocate two segments will allocate the same segment both times. According to FrostbittenKing on Github, this fixes The Witcher 2. If this somehow still causes problems, we could instead allocate a limit==0 32-bit data segment, but that seems rather ugly to me. Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix Signed-off-by: Andy Lutomirski Cc: torvalds@linux-foundation.org Link: http://lkml.kernel.org/r/0cb251abe1ff0958b8e468a9a9a905b80ae3a746.1421954363.git.luto@amacapital.net Signed-off-by: Thomas Gleixner Signed-off-by: Zefan Li commit 44574983e717f6e251e4c265d2f55fa022963474 Author: Andy Lutomirski Date: Thu Jan 22 11:27:58 2015 -0800 x86, tls, ldt: Stop checking lm in LDT_empty commit e30ab185c490e9a9381385529e0fd32f0a399495 upstream. 32-bit programs don't have an lm bit in their ABI, so they can't reliably cause LDT_empty to return true without resorting to memset. They shouldn't need to do this. This should fix a longstanding, if minor, issue in all 64-bit kernels as well as a potential regression in the TLS hardening code. Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix Signed-off-by: Andy Lutomirski Cc: torvalds@linux-foundation.org Link: http://lkml.kernel.org/r/72a059de55e86ad5e2935c80aa91880ddf19d07c.1421954363.git.luto@amacapital.net Signed-off-by: Thomas Gleixner Signed-off-by: Zefan Li commit 3814999ba2bbdcfe893f36e807c7fa973cf06708 Author: Andy Lutomirski Date: Thu Dec 4 16:48:16 2014 -0800 x86/tls: Validate TLS entries to protect espfix commit 41bdc78544b8a93a9c6814b8bbbfef966272abbe upstream. Installing a 16-bit RW data segment into the GDT defeats espfix. AFAICT this will not affect glibc, Wine, or dosemu at all. Signed-off-by: Andy Lutomirski Acked-by: H. Peter Anvin Cc: Konrad Rzeszutek Wilk Cc: Linus Torvalds Cc: security@kernel.org Cc: Willy Tarreau Signed-off-by: Ingo Molnar Signed-off-by: Zefan Li commit ea500805ef36f95b4126c2fdd00dc33e84ac3a0a Author: Andy Lutomirski Date: Fri Dec 5 19:03:28 2014 -0800 x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit commit 29fa6825463c97e5157284db80107d1bfac5d77b upstream. paravirt_enabled has the following effects: - Disables the F00F bug workaround warning. There is no F00F bug workaround any more because Linux's standard IDT handling already works around the F00F bug, but the warning still exists. This is only cosmetic, and, in any event, there is no such thing as KVM on a CPU with the F00F bug. - Disables 32-bit APM BIOS detection. On a KVM paravirt system, there should be no APM BIOS anyway. - Disables tboot. I think that the tboot code should check the CPUID hypervisor bit directly if it matters. - paravirt_enabled disables espfix32. espfix32 should *not* be disabled under KVM paravirt. The last point is the purpose of this patch. It fixes a leak of the high 16 bits of the kernel stack address on 32-bit KVM paravirt guests. Fixes CVE-2014-8134. Suggested-by: Konrad Rzeszutek Wilk Signed-off-by: Andy Lutomirski Signed-off-by: Paolo Bonzini Signed-off-by: Zefan Li commit 66cc8f8440666b4ef0996ec76d9a208f5b54970f Author: Jan Kara Date: Thu Oct 30 10:35:00 2014 +1100 mm: Remove false WARN_ON from pagecache_isize_extended() commit f55fefd1a5a339b1bd08c120b93312d6eb64a9fb upstream. The WARN_ON checking whether i_mutex is held in pagecache_isize_extended() was wrong because some filesystems (e.g. XFS) use different locks for serialization of truncates / writes. So just remove the check. Signed-off-by: Jan Kara Reviewed-by: Dave Chinner Signed-off-by: Dave Chinner Signed-off-by: Zefan Li commit cadd269d90b521f43fb0717439a2f252e2f27fcd Author: Stefan Richter Date: Tue Nov 11 17:16:44 2014 +0100 firewire: cdev: prevent kernel stack leaking into ioctl arguments commit eaca2d8e75e90a70a63a6695c9f61932609db212 upstream. Found by the UC-KLEE tool: A user could supply less input to firewire-cdev ioctls than write- or write/read-type ioctl handlers expect. The handlers used data from uninitialized kernel stack then. This could partially leak back to the user if the kernel subsequently generated fw_cdev_event_'s (to be read from the firewire-cdev fd) which notably would contain the _u64 closure field which many of the ioctl argument structures contain. The fact that the handlers would act on random garbage input is a lesser issue since all handlers must check their input anyway. The fix simply always null-initializes the entire ioctl argument buffer regardless of the actual length of expected user input. That is, a runtime overhead of memset(..., 40) is added to each firewirew-cdev ioctl() call. [Comment from Clemens Ladisch: This part of the stack is most likely to be already in the cache.] Remarks: - There was never any leak from kernel stack to the ioctl output buffer itself. IOW, it was not possible to read kernel stack by a read-type or write/read-type ioctl alone; the leak could at most happen in combination with read()ing subsequent event data. - The actual expected minimum user input of each ioctl from include/uapi/linux/firewire-cdev.h is, in bytes: [0x00] = 32, [0x05] = 4, [0x0a] = 16, [0x0f] = 20, [0x14] = 16, [0x01] = 36, [0x06] = 20, [0x0b] = 4, [0x10] = 20, [0x15] = 20, [0x02] = 20, [0x07] = 4, [0x0c] = 0, [0x11] = 0, [0x16] = 8, [0x03] = 4, [0x08] = 24, [0x0d] = 20, [0x12] = 36, [0x17] = 12, [0x04] = 20, [0x09] = 24, [0x0e] = 4, [0x13] = 40, [0x18] = 4. Reported-by: David Ramos Signed-off-by: Stefan Richter Signed-off-by: Zefan Li commit cd56d3907e3b2ddf0558a913a112ceffcd9eb355 Author: Andy Lutomirski Date: Mon Nov 24 17:39:06 2014 -0800 x86/asm/traps: Disable tracing and kprobes in fixup_bad_iret and sync_regs commit 7ddc6a2199f1da405a2fb68c40db8899b1a8cd87 upstream. These functions can be executed on the int3 stack, so kprobes are dangerous. Tracing is probably a bad idea, too. Fixes: b645af2d5905 ("x86_64, traps: Rework bad_iret") Signed-off-by: Andy Lutomirski Cc: Linus Torvalds Cc: Steven Rostedt Link: http://lkml.kernel.org/r/50e33d26adca60816f3ba968875801652507d0c4.1416870125.git.luto@amacapital.net Signed-off-by: Ingo Molnar [bwh: Backported to 3.2: - Use __kprobes instead of NOKPROBE_SYMBOL() - Don't use __visible] Signed-off-by: Ben Hutchings Signed-off-by: Zefan Li commit c0cb6036899b7ef63f4cac1c9a951c87ff78686e Author: Andy Lutomirski Date: Sat Nov 22 18:00:33 2014 -0800 x86_64, traps: Rework bad_iret commit b645af2d5905c4e32399005b867987919cbfc3ae upstream. It's possible for iretq to userspace to fail. This can happen because of a bad CS, SS, or RIP. Historically, we've handled it by fixing up an exception from iretq to land at bad_iret, which pretends that the failed iret frame was really the hardware part of #GP(0) from userspace. To make this work, there's an extra fixup to fudge the gs base into a usable state. This is suboptimal because it loses the original exception. It's also buggy because there's no guarantee that we were on the kernel stack to begin with. For example, if the failing iret happened on return from an NMI, then we'll end up executing general_protection on the NMI stack. This is bad for several reasons, the most immediate of which is that general_protection, as a non-paranoid idtentry, will try to deliver signals and/or schedule from the wrong stack. This patch throws out bad_iret entirely. As a replacement, it augments the existing swapgs fudge into a full-blown iret fixup, mostly written in C. It's should be clearer and more correct. Signed-off-by: Andy Lutomirski Reviewed-by: Thomas Gleixner Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: - We didn't use the _ASM_EXTABLE macro - Don't use __visible] Signed-off-by: Ben Hutchings Signed-off-by: Zefan Li commit fbe1dd0c2eb7fcd9b21aac5bfee924a9e0223f1b Author: Andy Lutomirski Date: Sat Nov 22 18:00:31 2014 -0800 x86_64, traps: Fix the espfix64 #DF fixup and rewrite it in C commit af726f21ed8af2cdaa4e93098dc211521218ae65 upstream. There's nothing special enough about the espfix64 double fault fixup to justify writing it in assembly. Move it to C. This also fixes a bug: if the double fault came from an IST stack, the old asm code would return to a partially uninitialized stack frame. Fixes: 3891a04aafd668686239349ea58f3314ea2af86b Signed-off-by: Andy Lutomirski Reviewed-by: Thomas Gleixner Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: - Keep using the paranoiderrorentry macro to generate the asm code - Adjust context] Signed-off-by: Ben Hutchings Signed-off-by: Zefan Li commit db331d416913aa6809c4abc3b8f03d3de734f5ce Author: Andy Lutomirski Date: Sat Nov 22 18:00:32 2014 -0800 x86_64, traps: Stop using IST for #SS commit 6f442be2fb22be02cafa606f1769fa1e6f894441 upstream. On a 32-bit kernel, this has no effect, since there are no IST stacks. On a 64-bit kernel, #SS can only happen in user code, on a failed iret to user space, a canonical violation on access via RSP or RBP, or a genuine stack segment violation in 32-bit kernel code. The first two cases don't need IST, and the latter two cases are unlikely fatal bugs, and promoting them to double faults would be fine. This fixes a bug in which the espfix64 code mishandles a stack segment violation. This saves 4k of memory per CPU and a tiny bit of code. Signed-off-by: Andy Lutomirski Reviewed-by: Thomas Gleixner Signed-off-by: Linus Torvalds [bwh: Backported to 3.2: - No need to define trace_stack_segment - Use the errorentry macro to generate #SS asm code - Adjust context - Checked that this matches Luis's backport for Ubuntu] Signed-off-by: Ben Hutchings Signed-off-by: Zefan Li commit a1e400a0b7da9e889a1dde76c9b761c13f3de0ab Author: Aaro Koskinen Date: Fri Oct 17 18:10:24 2014 +0300 MIPS: oprofile: Fix backtrace on 64-bit kernel commit bbaf113a481b6ce32444c125807ad3618643ce57 upstream. Fix incorrect cast that always results in wrong address for the new frame on 64-bit kernels. Signed-off-by: Aaro Koskinen Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8110/ Signed-off-by: Ralf Baechle Signed-off-by: Zefan Li commit a36f0b51eb6821dc794a769030bacc5aad8dd8c3 Author: Benjamin Herrenschmidt Date: Fri Nov 14 17:55:03 2014 +1100 of/base: Fix PowerPC address parsing hack commit 746c9e9f92dde2789908e51a354ba90a1962a2eb upstream. We have a historical hack that treats missing ranges properties as the equivalent of an empty one. This is needed for ancient PowerMac "bad" device-trees, and shouldn't be enabled for any other PowerPC platform, otherwise we get some nasty layout of devices in sysfs or even duplication when a set of otherwise identically named devices is created multiple times under a different parent node with no ranges property. This fix is needed for the PowerNV i2c busses to be exposed properly and will fix a number of other embedded cases. Signed-off-by: Benjamin Herrenschmidt Acked-by: Grant Likely Signed-off-by: Rob Herring Signed-off-by: Zefan Li commit 11c9fc9d691d0a6669319c30f4da60c1d425801e Author: Alexey Khoroshilov Date: Sat Oct 11 00:31:07 2014 +0400 can: esd_usb2: fix memory leak on disconnect commit efbd50d2f62fc1f69a3dcd153e63ba28cc8eb27f upstream. It seems struct esd_usb2 dev is not deallocated on disconnect. The patch adds the missing deallocation. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Acked-by: Matthias Fuchs Signed-off-by: Marc Kleine-Budde Signed-off-by: Zefan Li commit 79cbdbf4cfbba078cc8864934eaf843db6ad31c3 Author: Thomas Körper Date: Fri Oct 31 07:33:54 2014 +0100 can: dev: avoid calling kfree_skb() from interrupt context commit 5247a589c24022ab34e780039cc8000c48f2035e upstream. ikfree_skb() is Called in can_free_echo_skb(), which might be called from (TX Error) interrupt, which triggers the folloing warning: [ 1153.360705] ------------[ cut here ]------------ [ 1153.360715] WARNING: CPU: 0 PID: 31 at net/core/skbuff.c:563 skb_release_head_state+0xb9/0xd0() [ 1153.360772] Call Trace: [ 1153.360778] [] dump_stack+0x41/0x52 [ 1153.360782] [] warn_slowpath_common+0x7e/0xa0 [ 1153.360784] [] ? skb_release_head_state+0xb9/0xd0 [ 1153.360786] [] ? skb_release_head_state+0xb9/0xd0 [ 1153.360788] [] warn_slowpath_null+0x22/0x30 [ 1153.360791] [] skb_release_head_state+0xb9/0xd0 [ 1153.360793] [] skb_release_all+0x10/0x30 [ 1153.360795] [] kfree_skb+0x36/0x80 [ 1153.360799] [] ? can_free_echo_skb+0x28/0x40 [can_dev] [ 1153.360802] [] can_free_echo_skb+0x28/0x40 [can_dev] [ 1153.360805] [] esd_pci402_interrupt+0x34c/0x57a [esd402] [ 1153.360809] [] handle_irq_event_percpu+0x35/0x180 [ 1153.360811] [] ? handle_irq_event_percpu+0xa3/0x180 [ 1153.360813] [] handle_irq_event+0x31/0x50 [ 1153.360816] [] handle_fasteoi_irq+0x6f/0x120 [ 1153.360818] [] ? handle_edge_irq+0x110/0x110 [ 1153.360822] [] handle_irq+0x71/0x90 [ 1153.360823] [] do_IRQ+0x3c/0xd0 [ 1153.360829] [] common_interrupt+0x2c/0x34 [ 1153.360834] [] ? finish_task_switch+0x47/0xf0 [ 1153.360836] [] __schedule+0x35b/0x7e0 [ 1153.360839] [] ? console_unlock+0x2c4/0x4d0 [ 1153.360842] [] ? n_tty_receive_buf_common+0x890/0x890 [ 1153.360845] [] ? process_one_work+0x196/0x370 [ 1153.360847] [] schedule+0x23/0x60 [ 1153.360849] [] worker_thread+0x161/0x460 [ 1153.360852] [] ? __wake_up_locked+0x1f/0x30 [ 1153.360854] [] ? rescuer_thread+0x2f0/0x2f0 [ 1153.360856] [] kthread+0xa1/0xc0 [ 1153.360859] [] ret_from_kernel_thread+0x21/0x30 [ 1153.360861] [] ? kthread_create_on_node+0x110/0x110 [ 1153.360863] ---[ end trace 5ff83639cbb74b35 ]--- This patch replaces the kfree_skb() by dev_kfree_skb_any(). Signed-off-by: Thomas Körper Signed-off-by: Marc Kleine-Budde Signed-off-by: Zefan Li commit a2c749a7cac83a0d5e45080b1e97c84ec3c6e349 Author: Dave Hansen Date: Tue Nov 11 14:01:33 2014 -0800 x86: Require exact match for 'noxsave' command line option commit 2cd3949f702692cf4c5d05b463f19cd706a92dd3 upstream. We have some very similarly named command-line options: arch/x86/kernel/cpu/common.c:__setup("noxsave", x86_xsave_setup); arch/x86/kernel/cpu/common.c:__setup("noxsaveopt", x86_xsaveopt_setup); arch/x86/kernel/cpu/common.c:__setup("noxsaves", x86_xsaves_setup); __setup() is designed to match options that take arguments, like "foo=bar" where you would have: __setup("foo", x86_foo_func...); The problem is that "noxsave" actually _matches_ "noxsaves" in the same way that "foo" matches "foo=bar". If you boot an old kernel that does not know about "noxsaves" with "noxsaves" on the command line, it will interpret the argument as "noxsave", which is not what you want at all. This makes the "noxsave" handler only return success when it finds an *exact* match. [ tglx: We really need to make __setup() more robust. ] Signed-off-by: Dave Hansen Cc: Dave Hansen Cc: Fenghua Yu Cc: x86@kernel.org Link: http://lkml.kernel.org/r/20141111220133.FE053984@viggo.jf.intel.com Signed-off-by: Thomas Gleixner Signed-off-by: Zefan Li commit fdb554dcb0ea1c7e7233db882a396e99a2f56c49 Author: Fabio Estevam Date: Fri Nov 14 02:14:47 2014 -0200 ASoC: sgtl5000: Fix SMALL_POP bit definition commit c251ea7bd7a04f1f2575467e0de76e803cf59149 upstream. On a mx28evk with a sgtl5000 codec we notice a loud 'click' sound to happen 5 seconds after the end of a playback. The SMALL_POP bit should fix this, but its definition is incorrect: according to the sgtl5000 manual it is bit 0 of CHIP_REF_CTRL register, not bit 1. Fix the definition accordingly and enable the bit as intended per the code comment. After applying this change, no loud 'click' sound is heard after playback Signed-off-by: Fabio Estevam Signed-off-by: Mark Brown Signed-off-by: Zefan Li commit 4c753f06b4e4b09f85fc2bb631bc5e3787bd16d0 Author: Stanislaw Gruszka Date: Tue Nov 11 14:28:47 2014 +0100 rt2x00: do not align payload on modern H/W commit cfd9167af14eb4ec21517a32911d460083ee3d59 upstream. RT2800 and newer hardware require padding between header and payload if header length is not multiple of 4. For historical reasons we also align payload to to 4 bytes boundary, but such alignment is not needed on modern H/W. Patch fixes skb_under_panic problems reported from time to time: https://bugzilla.kernel.org/show_bug.cgi?id=84911 https://bugzilla.kernel.org/show_bug.cgi?id=72471 http://marc.info/?l=linux-wireless&m=139108549530402&w=2 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1087591 Panic happened because we eat 4 bytes of skb headroom on each (re)transmission when sending frame without the payload and the header length not being multiple of 4 (i.e. QoS header has 26 bytes). On such case because paylad_aling=2 is bigger than header_align=0 we increase header_align by 4 bytes. To prevent that we could change the check to: if (payload_length && payload_align > header_align) header_align += 4; but not aligning payload at all is more effective and alignment is not really needed by H/W (that has been tested on OpenWrt project for few years now). Reported-and-tested-by: Antti S. Lankila Debugged-by: Antti S. Lankila Reported-by: Henrik Asp Originally-From: Helmut Schaa Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Zefan Li commit b02eb60255c011ce2d9fc2195a4b7f21b1d548ee Author: Kuninori Morimoto Date: Tue Oct 28 21:01:53 2014 -0700 ASoC: fsi: remove unsupported PAUSE flag commit c1b9b9b1ad2df6144ca3fbe6989f7bd9ea5c5562 upstream. FSI doesn't support PAUSE. Remove SNDRV_PCM_INFO_PAUSE flags from snd_pcm_hardware info Signed-off-by: Kuninori Morimoto Signed-off-by: Mark Brown Signed-off-by: Zefan Li commit 9aa66231c8d8efb13ced247c8e8096bcb52a7e86 Author: Bart Van Assche Date: Sun Oct 19 18:05:33 2014 +0300 srp-target: Retry when QP creation fails with ENOMEM commit ab477c1ff5e0a744c072404bf7db51bfe1f05b6e upstream. It is not guaranteed to that srp_sq_size is supported by the HCA. So if we failed to create the QP with ENOMEM, try with a smaller srp_sq_size. Keep it up until we hit MIN_SRPT_SQ_SIZE, then fail the connection. Reported-by: Mark Lehrer Signed-off-by: Bart Van Assche Signed-off-by: Sagi Grimberg Signed-off-by: Nicholas Bellinger Signed-off-by: Zefan Li commit 0def10217e7b768a501d2c51ea6d5ee4332afe69 Author: Ilya Dryomov Date: Thu Oct 23 00:25:22 2014 +0400 libceph: do not crash on large auth tickets commit aaef31703a0cf6a733e651885bfb49edc3ac6774 upstream. Large (greater than 32k, the value of PAGE_ALLOC_COSTLY_ORDER) auth tickets will have their buffers vmalloc'ed, which leads to the following crash in crypto: [ 28.685082] BUG: unable to handle kernel paging request at ffffeb04000032c0 [ 28.686032] IP: [] scatterwalk_pagedone+0x22/0x80 [ 28.686032] PGD 0 [ 28.688088] Oops: 0000 [#1] PREEMPT SMP [ 28.688088] Modules linked in: [ 28.688088] CPU: 0 PID: 878 Comm: kworker/0:2 Not tainted 3.17.0-vm+ #305 [ 28.688088] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007 [ 28.688088] Workqueue: ceph-msgr con_work [ 28.688088] task: ffff88011a7f9030 ti: ffff8800d903c000 task.ti: ffff8800d903c000 [ 28.688088] RIP: 0010:[] [] scatterwalk_pagedone+0x22/0x80 [ 28.688088] RSP: 0018:ffff8800d903f688 EFLAGS: 00010286 [ 28.688088] RAX: ffffeb04000032c0 RBX: ffff8800d903f718 RCX: ffffeb04000032c0 [ 28.688088] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8800d903f750 [ 28.688088] RBP: ffff8800d903f688 R08: 00000000000007de R09: ffff8800d903f880 [ 28.688088] R10: 18df467c72d6257b R11: 0000000000000000 R12: 0000000000000010 [ 28.688088] R13: ffff8800d903f750 R14: ffff8800d903f8a0 R15: 0000000000000000 [ 28.688088] FS: 00007f50a41c7700(0000) GS:ffff88011fc00000(0000) knlGS:0000000000000000 [ 28.688088] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b [ 28.688088] CR2: ffffeb04000032c0 CR3: 00000000da3f3000 CR4: 00000000000006b0 [ 28.688088] Stack: [ 28.688088] ffff8800d903f698 ffffffff81392ca8 ffff8800d903f6e8 ffffffff81395d32 [ 28.688088] ffff8800dac96000 ffff880000000000 ffff8800d903f980 ffff880119b7e020 [ 28.688088] ffff880119b7e010 0000000000000000 0000000000000010 0000000000000010 [ 28.688088] Call Trace: [ 28.688088] [] scatterwalk_done+0x38/0x40 [ 28.688088] [] scatterwalk_done+0x38/0x40 [ 28.688088] [] blkcipher_walk_done+0x182/0x220 [ 28.688088] [] crypto_cbc_encrypt+0x15f/0x180 [ 28.688088] [] ? crypto_aes_set_key+0x30/0x30 [ 28.688088] [] ceph_aes_encrypt2+0x29c/0x2e0 [ 28.688088] [] ceph_encrypt2+0x93/0xb0 [ 28.688088] [] ceph_x_encrypt+0x4a/0x60 [ 28.688088] [] ? ceph_buffer_new+0x5d/0xf0 [ 28.688088] [] ceph_x_build_authorizer.isra.6+0x297/0x360 [ 28.688088] [] ? kmem_cache_alloc_trace+0x11b/0x1c0 [ 28.688088] [] ? ceph_auth_create_authorizer+0x36/0x80 [ 28.688088] [] ceph_x_create_authorizer+0x63/0xd0 [ 28.688088] [] ceph_auth_create_authorizer+0x54/0x80 [ 28.688088] [] get_authorizer+0x80/0xd0 [ 28.688088] [] prepare_write_connect+0x18b/0x2b0 [ 28.688088] [] try_read+0x1e59/0x1f10 This is because we set up crypto scatterlists as if all buffers were kmalloc'ed. Fix it. Signed-off-by: Ilya Dryomov Reviewed-by: Sage Weil Signed-off-by: Zefan Li commit 552f4eccfeeb34a4152d9f8190ec0f23e4afa26f Author: Trond Myklebust Date: Fri Oct 17 15:10:25 2014 +0300 NFSv4: Ensure that we remove NFSv4.0 delegations when state has expired commit 4dfd4f7af0afd201706ad186352ca423b0f17d4b upstream. NFSv4.0 does not have TEST_STATEID/FREE_STATEID functionality, so unlike NFSv4.1, the recovery procedure when stateids have expired or have been revoked requires us to just forget the delegation. http://lkml.kernel.org/r/CAN-5tyHwG=Cn2Q9KsHWadewjpTTy_K26ee+UnSvHvG4192p-Xw@mail.gmail.com Signed-off-by: Trond Myklebust Signed-off-by: Zefan Li commit 6aaa1e03cb296b1824b3150723909d740f6b293e Author: Jan Kara Date: Thu Oct 23 14:02:47 2014 +0200 nfs: Fix use of uninitialized variable in nfs_getattr() commit 16caf5b6101d03335b386e77e9e14136f989be87 upstream. Variable 'err' needn't be initialized when nfs_getattr() uses it to check whether it should call generic_fillattr() or not. That can result in spurious error returns. Initialize 'err' properly. Signed-off-by: Jan Kara Signed-off-by: Trond Myklebust Signed-off-by: Zefan Li commit bf5dbba17a6816e0b7f33abc034f5ca089884e10 Author: Miklos Szeredi Date: Tue Nov 4 11:27:12 2014 +0100 audit: keep inode pinned commit 799b601451b21ebe7af0e6e8f6e2ccd4683c5064 upstream. Audit rules disappear when an inode they watch is evicted from the cache. This is likely not what we want. The guilty commit is "fsnotify: allow marks to not pin inodes in core", which didn't take into account that audit_tree adds watches with a zero mask. Adding any mask should fix this. Fixes: 90b1e7a57880 ("fsnotify: allow marks to not pin inodes in core") Signed-off-by: Miklos Szeredi Signed-off-by: Paul Moore Signed-off-by: Zefan Li commit 3b5d98d44729594d72d3c36881234b7caa040d87 Author: Christoph Hellwig Date: Mon Nov 3 19:36:40 2014 +0100 scsi: only re-lock door after EH on devices that were reset commit 48379270fe6808cf4612ee094adc8da2b7a83baa upstream. Setups that use the blk-mq I/O path can lock up if a host with a single device that has its door locked enters EH. Make sure to only send the command to re-lock the door to devices that actually were reset and thus might have lost their state. Otherwise the EH code might be get blocked on blk_get_request as all requests for non-reset devices might be in use. Signed-off-by: Christoph Hellwig Reported-by: Meelis Roos Tested-by: Meelis Roos Reviewed-by: Martin K. Petersen Signed-off-by: Zefan Li commit e3412bce0c655b3896c0142b58ccddb6ae91bc01 Author: Pali Rohár Date: Sat Nov 8 12:58:57 2014 -0800 Input: alps - allow up to 2 invalid packets without resetting device commit 9d720b34c0a432639252f63012e18b0507f5b432 upstream. On some Dell Latitude laptops ALPS device or Dell EC send one invalid byte in 6 bytes ALPS packet. In this case psmouse driver enter out of sync state. It looks like that all other bytes in packets are valid and also device working properly. So there is no need to do full device reset, just need to wait for byte which match condition for first byte (start of packet). Because ALPS packets are bigger (6 or 8 bytes) default limit is small. This patch increase number of invalid bytes to size of 2 ALPS packets which psmouse driver can drop before do full reset. Resetting ALPS devices take some time and when doing reset on some Dell laptops touchpad, trackstick and also keyboard do not respond. So it is better to do it only if really necessary. Signed-off-by: Pali Rohár Tested-by: Pali Rohár Reviewed-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li commit 11246b668d42617a626de9b4ffdd611c5e7d79dd Author: Pali Rohár Date: Sat Nov 8 12:45:23 2014 -0800 Input: alps - ignore potential bare packets when device is out of sync commit 4ab8f7f320f91f279c3f06a9795cfea5c972888a upstream. 5th and 6th byte of ALPS trackstick V3 protocol match condition for first byte of PS/2 3 bytes packet. When driver enters out of sync state and ALPS trackstick is sending data then driver match 5th, 6th and next 1st bytes as PS/2. It basically means if user is using trackstick when driver is in out of sync state driver will never resync. Processing these bytes as 3 bytes PS/2 data cause total mess (random cursor movements, random clicks) and make trackstick unusable until psmouse driver decide to do full device reset. Lot of users reported problems with ALPS devices on Dell Latitude E6440, E6540 and E7440 laptops. ALPS device or Dell EC for unknown reason send some invalid ALPS PS/2 bytes which cause driver out of sync. It looks like that i8042 and psmouse/alps driver always receive group of 6 bytes packets so there are no missing bytes and no bytes were inserted between valid ones. This patch does not fix root of problem with ALPS devices found in Dell Latitude laptops but it does not allow to process some (invalid) subsequence of 6 bytes ALPS packets as 3 bytes PS/2 when driver is out of sync. So with this patch trackstick input device does not report bogus data when also driver is out of sync, so trackstick should be usable on those machines. Signed-off-by: Pali Rohár Tested-by: Pali Rohár Reviewed-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li commit 4dc9a295a5975b4e60edd87f8e469dd5746dded5 Author: Alex Deucher Date: Wed Nov 5 17:14:32 2014 -0500 drm/radeon: add missing crtc unlock when setting up the MC commit f0d7bfb9407fccb6499ec01c33afe43512a439a2 upstream. Need to unlock the crtc after updating the blanking state. Signed-off-by: Alex Deucher Signed-off-by: Zefan Li commit 11e4f1f6a3ea6ed6284732b50f621974c5766f22 Author: Herbert Xu Date: Mon Nov 3 14:01:25 2014 +0800 macvtap: Fix csum_start when VLAN tags are present commit 3ce9b20f1971690b8b3b620e735ec99431573b39 upstream. When VLAN is in use in macvtap_put_user, we end up setting csum_start to the wrong place. The result is that the whoever ends up doing the checksum setting will corrupt the packet instead of writing the checksum to the expected location, usually this means writing the checksum with an offset of -4. This patch fixes this by adjusting csum_start when VLAN tags are detected. Fixes: f09e2249c4f5 ("macvtap: restore vlan header on user read") Signed-off-by: Herbert Xu Cheers, Signed-off-by: David S. Miller Signed-off-by: Zefan Li commit 17ee0a10c12204dab58922c25823fc7efe1dc4b6 Author: Johannes Berg Date: Mon Nov 3 13:57:46 2014 +0100 mac80211: fix use-after-free in defragmentation commit b8fff407a180286aa683d543d878d98d9fc57b13 upstream. Upon receiving the last fragment, all but the first fragment are freed, but the multicast check for statistics at the end of the function refers to the current skb (the last fragment) causing a use-after-free bug. Since multicast frames cannot be fragmented and we check for this early in the function, just modify that check to also do the accounting to fix the issue. Reported-by: Yosef Khyal Signed-off-by: Johannes Berg Signed-off-by: Zefan Li commit 14194d6c2736eb1129579814dabb6e1751c7c964 Author: Jan Kara Date: Thu Oct 30 20:43:38 2014 +0100 block: Fix computation of merged request priority commit ece9c72accdc45c3a9484dacb1125ce572647288 upstream. Priority of a merged request is computed by ioprio_best(). If one of the requests has undefined priority (IOPRIO_CLASS_NONE) and another request has priority from IOPRIO_CLASS_BE, the function will return the undefined priority which is wrong. Fix the function to properly return priority of a request with the defined priority. Fixes: d58cdfb89ce0c6bd5f81ae931a984ef298dbda20 Signed-off-by: Jan Kara Reviewed-by: Jeff Moyer Signed-off-by: Jens Axboe [lizf: Backported to 3.4: adjust filename] Signed-off-by: Zefan Li commit 0ec7236b1a62c0308b1249c9304f23335a72902b Author: Johannes Berg Date: Tue Oct 21 20:56:42 2014 +0200 mac80211: properly flush delayed scan work on interface removal commit 46238845bd609a5c0fbe076e1b82b4c5b33360b2 upstream. When an interface is deleted, an ongoing hardware scan is canceled and the driver must abort the scan, at the very least reporting completion while the interface is removed. However, if it scheduled the work that might only run after everything is said and done, which leads to cfg80211 warning that the scan isn't reported as finished yet; this is no fault of the driver, it already did, but mac80211 hasn't processed it. To fix this situation, flush the delayed work when the interface being removed is the one that was executing the scan. Reported-by: Sujith Manoharan Tested-by: Sujith Manoharan Signed-off-by: Johannes Berg [lizf: Backported to 3.4: rcu_access_pointer() isn't used] Signed-off-by: Zefan Li commit fbbe552c46a0272d8318aa21df7e369840a61e50 Author: James Ralston Date: Mon Oct 13 15:16:38 2014 -0700 ahci: Add Device IDs for Intel Sunrise Point PCH commit 690000b930456a98663567d35dd5c54b688d1e3f upstream. This patch adds the AHCI-mode SATA Device IDs for the Intel Sunrise Point PCH. Signed-off-by: James Ralston Signed-off-by: Tejun Heo Signed-off-by: Zefan Li commit c0f73f51c40b93af864a1c0093fb1a05f24762c3 Author: Heinz Mauelshagen Date: Fri Oct 17 13:38:50 2014 +0200 dm raid: ensure superblock's size matches device's logical block size commit 40d43c4b4cac4c2647bf07110d7b07d35f399a84 upstream. The dm-raid superblock (struct dm_raid_superblock) is padded to 512 bytes and that size is being used to read it in from the metadata device into one preallocated page. Reading or writing this on a 512-byte sector device works fine but on a 4096-byte sector device this fails. Set the dm-raid superblock's size to the logical block size of the metadata device, because IO at that size is guaranteed too work. Also add a size check to avoid silent partial metadata loss in case the superblock should ever grow past the logical block size or PAGE_SIZE. [includes pointer math fix from Dan Carpenter] Reported-by: "Liuhua Wang" Signed-off-by: Heinz Mauelshagen Signed-off-by: Dan Carpenter Signed-off-by: Mike Snitzer Signed-off-by: Zefan Li commit 792a118bb47f8e34ca0794032a533df214fbb1fe Author: Max Filippov Date: Mon Oct 6 21:01:17 2014 +0400 xtensa: re-wire umount syscall to sys_oldumount commit 2651cc6974d47fc43bef1cd8cd26966e4f5ba306 upstream. Userspace actually passes single parameter (path name) to the umount syscall, so new umount just fails. Fix it by requesting old umount syscall implementation and re-wiring umount to it. Signed-off-by: Max Filippov [lizf: Backported to 3.4: adjust filename] Signed-off-by: Zefan Li commit 0e7638d87693175cc479b91a8227a27991363cf0 Author: Mikulas Patocka Date: Thu Oct 16 14:45:20 2014 -0400 dm bufio: change __GFP_IO to __GFP_FS in shrinker callbacks commit 9d28eb12447ee08bb5d1e8bb3195cf20e1ecd1c0 upstream. The shrinker uses gfp flags to indicate what kind of operation can the driver wait for. If __GFP_IO flag is present, the driver can wait for block I/O operations, if __GFP_FS flag is present, the driver can wait on operations involving the filesystem. dm-bufio tested for __GFP_IO. However, dm-bufio can run on a loop block device that makes calls into the filesystem. If __GFP_IO is present and __GFP_FS isn't, dm-bufio could still block on filesystem operations if it runs on a loop block device. The change from __GFP_IO to __GFP_FS supposedly fixes one observed (though unreproducible) deadlock involving dm-bufio and loop device. Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer [lizf: Backported to 3.4: - drop changes to dm_bufio_shrink_scan() and dm_bufio_shrink_count() - change __GFP_IO to __GFP_FS in shrink()] Signed-off-by: Zefan Li commit d7b1b1db066e9aa59d25ed13c97353a4dbf6ea6c Author: Yijing Wang Date: Fri Nov 7 12:05:49 2014 +0800 sysfs: driver core: Fix glue dir race condition by gdp_mutex commit e4a60d139060975eb956717e4f63ae348d4d8cc5 upstream. There is a race condition when removing glue directory. It can be reproduced in following test: path 1: Add first child device device_add() get_device_parent() /*find parent from glue_dirs.list*/ list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry) if (k->parent == parent_kobj) { kobj = kobject_get(k); break; } .... class_dir_create_and_add() path2: Remove last child device under glue dir device_del() cleanup_device_parent() cleanup_glue_dir() kobject_put(glue_dir); If path2 has been called cleanup_glue_dir(), but not call kobject_put(glue_dir), the glue dir is still in parent's kset list. Meanwhile, path1 find the glue dir from the glue_dirs.list. Path2 may release glue dir before path1 call kobject_get(). So kernel will report the warning and bug_on. This is a "classic" problem we have of a kref in a list that can be found while the last instance could be removed at the same time. This patch reuse gdp_mutex to fix this race condition. The following calltrace is captured in kernel 3.4, but the latest kernel still has this bug. ----------------------------------------------------- <4>[ 3965.441471] WARNING: at ...include/linux/kref.h:41 kobject_get+0x33/0x40() <4>[ 3965.441474] Hardware name: Romley <4>[ 3965.441475] Modules linked in: isd_iop(O) isd_xda(O)... ... <4>[ 3965.441605] Call Trace: <4>[ 3965.441611] [] warn_slowpath_common+0x7a/0xb0 <4>[ 3965.441615] [] warn_slowpath_null+0x15/0x20 <4>[ 3965.441618] [] kobject_get+0x33/0x40 <4>[ 3965.441624] [] get_device_parent.isra.11+0x135/0x1f0 <4>[ 3965.441627] [] device_add+0xd4/0x6d0 <4>[ 3965.441631] [] ? dev_set_name+0x3c/0x40 .... <2>[ 3965.441912] kernel BUG at ..../fs/sysfs/group.c:65! <4>[ 3965.441915] invalid opcode: 0000 [#1] SMP ... <4>[ 3965.686743] [] sysfs_create_group+0xe/0x10 <4>[ 3965.686748] [] blk_trace_init_sysfs+0x14/0x20 <4>[ 3965.686753] [] blk_register_queue+0x3b/0x120 <4>[ 3965.686756] [] add_disk+0x1cc/0x490 .... ------------------------------------------------------- Signed-off-by: Yijing Wang Signed-off-by: Weng Meiling Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 0bb9566eaaabf31b2368340fbedc34010c09e8f0 Author: Imre Deak Date: Thu Oct 2 16:34:31 2014 +0300 tty/vt: don't set font mappings on vc not supporting this commit 9e326f78713a4421fe11afc2ddeac07698fac131 upstream. We can call this function for a dummy console that doesn't support setting the font mapping, which will result in a null ptr BUG. So check for this case and return error for consoles w/o font mapping support. Reference: https://bugzilla.kernel.org/show_bug.cgi?id=59321 Signed-off-by: Imre Deak Signed-off-by: Greg Kroah-Hartman [lizf: Backported to 3.4: just return -EINVAL as we don't need to unlock] Signed-off-by: Zefan Li commit 871518e986137e72b3ad20e5b3fd7093cda69bbf Author: Peter Hurley Date: Thu Oct 16 13:54:36 2014 -0400 tty: Prevent "read/write wait queue active!" log flooding commit 494c1eac7e73f719af9d474a96ec8494c33efd6a upstream. Only print one warning when a task is on the read_wait or write_wait wait queue at final tty release. Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 26bc3aa52a38602cc5a4430571d90e158430573b Author: Peter Hurley Date: Thu Oct 16 13:51:30 2014 -0400 tty: Fix high cpu load if tty is unreleaseable commit 37b164578826406a173ca7c20d9ba7430134d23e upstream. Kernel oops can cause the tty to be unreleaseable (for example, if n_tty_read() crashes while on the read_wait queue). This will cause tty_release() to endlessly loop without sleeping. Use a killable sleep timeout which grows by 2n+1 jiffies over the interval [0, 120 secs.) and then jumps to forever (but still killable). NB: killable just allows for the task to be rewoken manually, not to be terminated. Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 741946cf911c1ea1cefcf790baaeb618b0712d0f Author: Peter Hurley Date: Thu Oct 16 13:46:38 2014 -0400 serial: Fix divide-by-zero fault in uart_get_divisor() commit 547039ec502076e60034eeb79611df3433a99b7d upstream. uart_get_baud_rate() will return baud == 0 if the max rate is set to the "magic" 38400 rate and the SPD_* flags are also specified. On the first iteration, if the current baud rate is higher than the max, the baud rate is clamped at the max (which in the degenerate case is 38400). On the second iteration, the now-"magic" 38400 baud rate selects the possibly higher alternate baud rate indicated by the SPD_* flag. Since only two loop iterations are performed, the loop is exited, a kernel WARNING is generated and a baud rate of 0 is returned. Reproducible with: setserial /dev/ttyS0 spd_hi base_baud 38400 Only perform the "magic" 38400 -> SPD_* baud transform on the first loop iteration, which prevents the degenerate case from recognizing the clamped baud rate as the "magic" 38400 value. Reported-by: Robert Święcki Signed-off-by: Peter Hurley Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit c85f70407eaf925cdea7050a02bb30637ad8a155 Author: Johan Hovold Date: Wed Nov 5 18:41:59 2014 +0100 USB: cdc-acm: only raise DTR on transitions from B0 commit 4473d054ceb572557954f9536731d39b20937b0c upstream. Make sure to only raise DTR on transitions from B0 in set_termios. Also allow set_termios to be called from open with a termios_old of NULL. Note that DTR will not be raised prematurely in this case. Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit adea30f0a90aa958594ca553e920a96f7a0b5b22 Author: Lars-Peter Clausen Date: Tue Nov 4 18:03:15 2014 +0100 staging:iio:ade7758: Fix check if channels are enabled in prenable commit 79fa64eb2ee8ccb4bcad7f54caa2699730b10b22 upstream. We should check if a channel is enabled, not if no channels are enabled. Fixes: 550268ca1111 ("staging:iio: scrap scan_count and ensure all drivers use active_scan_mask") Signed-off-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron Signed-off-by: Zefan Li commit 7ef2f8d116f0e0b5513ecd5c06a72e84745c9041 Author: Takashi Iwai Date: Wed Nov 5 15:08:49 2014 +0100 ALSA: usb-audio: Fix device_del() sysfs warnings at disconnect commit 0725dda207e95ff25f1aa01432250323e0ec49d6 upstream. Some USB-audio devices show weird sysfs warnings at disconnecting the devices, e.g. usb 1-3: USB disconnect, device number 3 ------------[ cut here ]------------ WARNING: CPU: 0 PID: 973 at fs/sysfs/group.c:216 device_del+0x39/0x180() sysfs group ffffffff8183df40 not found for kobject 'midiC1D0' Call Trace: [] ? dump_stack+0x49/0x71 [] ? warn_slowpath_common+0x82/0xb0 [] ? warn_slowpath_fmt+0x45/0x50 [] ? device_del+0x39/0x180 [] ? device_unregister+0x9/0x20 [] ? device_destroy+0x34/0x40 [] ? snd_unregister_device+0x7f/0xd0 [snd] [] ? snd_rawmidi_dev_disconnect+0xce/0x100 [snd_rawmidi] [] ? snd_device_disconnect+0x62/0x90 [snd] [] ? snd_device_disconnect_all+0x3c/0x60 [snd] [] ? snd_card_disconnect+0x124/0x1a0 [snd] [] ? usb_audio_disconnect+0x88/0x1c0 [snd_usb_audio] [] ? usb_unbind_interface+0x5e/0x1b0 [usbcore] [] ? __device_release_driver+0x79/0xf0 [] ? device_release_driver+0x25/0x40 [] ? bus_remove_device+0xf1/0x130 [] ? device_del+0x109/0x180 [] ? usb_disable_device+0x95/0x1f0 [usbcore] [] ? usb_disconnect+0x8f/0x190 [usbcore] [] ? hub_thread+0x539/0x13a0 [usbcore] [] ? sched_clock_local+0x15/0x80 [] ? sched_clock_cpu+0xb8/0xd0 [] ? bit_waitqueue+0xb0/0xb0 [] ? usb_port_resume+0x430/0x430 [usbcore] [] ? usb_port_resume+0x430/0x430 [usbcore] [] ? kthread+0xce/0xf0 [] ? kthread_create_on_node+0x1c0/0x1c0 [] ? ret_from_fork+0x7c/0xb0 [] ? kthread_create_on_node+0x1c0/0x1c0 ---[ end trace 40b1928d1136b91e ]--- This comes from the fact that usb-audio driver may receive the disconnect callback multiple times, per each usb interface. When a device has both audio and midi interfaces, it gets called twice, and currently the driver tries to release resources at the last call. At this point, the first parent interface has been already deleted, thus deleting a child of the first parent hits such a warning. For fixing this problem, we need to call snd_card_disconnect() and cancel pending operations at the very first disconnect while the release of the whole objects waits until the last disconnect call. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=80931 Reported-and-tested-by: Tomas Gayoso Reported-and-tested-by: Chris J Arges Signed-off-by: Takashi Iwai [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 547f9e81ecec3e649ab565bf484fdd840bd6dc11 Author: Chris Mason Date: Tue Nov 4 06:59:04 2014 -0800 Btrfs: fix kfree on list_head in btrfs_lookup_csums_range error cleanup commit 6e5aafb27419f32575b27ef9d6a31e5d54661aca upstream. If we hit any errors in btrfs_lookup_csums_range, we'll loop through all the csums we allocate and free them. But the code was using list_entry incorrectly, and ended up trying to free the on-stack list_head instead. This bug came from commit 0678b6185 btrfs: Don't BUG_ON kzalloc error in btrfs_lookup_csums_range() Signed-off-by: Chris Mason Reported-by: Erik Berg Signed-off-by: Zefan Li commit 0350de0eab3268372dca504504688286d8d18df9 Author: Grant Likely Date: Mon Nov 3 15:15:35 2014 +0000 of: Fix overflow bug in string property parsing functions commit a87fa1d81a9fb5e9adca9820e16008c40ad09f33 upstream. The string property read helpers will run off the end of the buffer if it is handed a malformed string property. Rework the parsers to make sure that doesn't happen. At the same time add new test cases to make sure the functions behave themselves. The original implementations of of_property_read_string_index() and of_property_count_strings() both open-coded the same block of parsing code, each with it's own subtly different bugs. The fix here merges functions into a single helper and makes the original functions static inline wrappers around the helper. One non-bugfix aspect of this patch is the addition of a new wrapper, of_property_read_string_array(). The new wrapper is needed by the device_properties feature that Rafael is working on and planning to merge for v3.19. The implementation is identical both with and without the new static inline wrapper, so it just got left in to reduce the churn on the header file. Signed-off-by: Grant Likely Cc: Rafael J. Wysocki Cc: Mika Westerberg Cc: Rob Herring Cc: Arnd Bergmann Cc: Darren Hart [lizf: Backported to 3.4: - adjust context - drop selftest hunks that don't apply] Signed-off-by: Zefan Li commit c9db0543617a3ae5c50a91950641dddad43cc869 Author: Oliver Neukum Date: Mon Oct 27 14:53:29 2014 +0100 xhci: no switching back on non-ULT Haswell commit b45abacde3d551c6696c6738bef4a1805d0bf27a upstream. The switch back is limited to ULT even on HP. The contrary finding arose by bad luck in BIOS versions for testing. This fixes spontaneous resume from S3 on some HP laptops. Signed-off-by: Oliver Neukum Signed-off-by: Greg Kroah-Hartman [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit bfa58af70fd6bfd113aa1b9eb245a0165b0a8bdf Author: Adel Gadllah Date: Thu Oct 9 09:29:30 2014 +0200 USB: quirks: enable device-qualifier quirk for yet another Elan touchscreen commit d749947561af5996ccc076b2ffcc5f48b1be5d74 upstream. Yet another device affected by this. Tested-by: Kevin Fenzi Signed-off-by: Adel Gadllah Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit bbfb43b80d4102f66b958c303d9e158572844221 Author: Adel Gadllah Date: Thu Oct 9 09:29:29 2014 +0200 USB: quirks: enable device-qualifier quirk for another Elan touchscreen commit 876af5d454548be40327ba9efea4bc92a8575019 upstream. Currently this quirk is enabled for the model with the device id 0x0089, it is needed for the 0x009b model, which is found on the Fujitsu Lifebook u904 as well. Signed-off-by: Adel Gadllah Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 8cb0a20aaef0546ca0daf685ab127b181ea8284b Author: Johan Hovold Date: Mon Aug 25 17:51:26 2014 +0200 USB: core: add device-qualifier quirk commit 2a159389bf5d962359349a76827b2f683276a1c7 upstream. Add new quirk for devices that cannot handle requests for the device_qualifier descriptor. A USB-2.0 compliant device must respond to requests for the device_qualifier descriptor (even if it's with a request error), but at least one device is known to misbehave after such a request. Suggested-by: Bjørn Mork Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit c960659c347e5e0c979084a793bf1f125f3b57ba Author: Alan Stern Date: Fri Oct 31 14:49:47 2014 -0400 usb-storage: handle a skipped data phase commit 93c9bf4d1838d5851a18ca398b0ad66397f05056 upstream. Sometimes mass-storage devices using the Bulk-only transport will mistakenly skip the data phase of a command. Rather than sending the data expected by the host or sending a zero-length packet, they go directly to the status phase and send the CSW. This causes problems for usb-storage, for obvious reasons. The driver will interpret the CSW as a short data transfer and will wait to receive a CSW. The device won't have anything left to send, so the command eventually times out. The SCSI layer doesn't retry commands after they time out (this is a relatively recent change). Therefore we should do our best to detect a skipped data phase and handle it promptly. This patch adds code to do that. If usb-storage receives a short 13-byte data transfer from the device, and if the first four bytes of the data match the CSW signature, the driver will set the residue to the full transfer length and interpret the data as a CSW. This fixes Bugzilla #86611. Signed-off-by: Alan Stern CC: Matthew Dharm Tested-by: Paul Osmialowski Signed-off-by: Greg Kroah-Hartman [lizf: Backported to 3.4: change usb_stor_dbg() to US_DEBUGP()] Signed-off-by: Zefan Li commit 71f5d1de514893e8453099654da248b18feb2c6f Author: Hans de Goede Date: Wed Oct 1 11:29:14 2014 +0200 usb: Do not allow usb_alloc_streams on unconfigured devices commit 90a646c770c50cc206ceba0d7b50453c46c13c36 upstream. This commit fixes the following oops: [10238.622067] scsi host3: uas_eh_bus_reset_handler start [10240.766164] usb 3-4: reset SuperSpeed USB device number 3 using xhci_hcd [10245.779365] usb 3-4: device descriptor read/8, error -110 [10245.883331] usb 3-4: reset SuperSpeed USB device number 3 using xhci_hcd [10250.897603] usb 3-4: device descriptor read/8, error -110 [10251.058200] BUG: unable to handle kernel NULL pointer dereference at 0000000000000040 [10251.058244] IP: [] xhci_check_streams_endpoint+0x91/0x140 [10251.059473] Call Trace: [10251.059487] [] xhci_calculate_streams_and_bitmask+0xbc/0x130 [10251.059520] [] xhci_alloc_streams+0x10f/0x5a0 [10251.059548] [] ? check_preempt_curr+0x75/0xa0 [10251.059575] [] ? ttwu_do_wakeup+0x2c/0x100 [10251.059601] [] ? ttwu_do_activate.constprop.111+0x66/0x70 [10251.059635] [] usb_alloc_streams+0xab/0xf0 [10251.059662] [] uas_configure_endpoints+0x128/0x150 [uas] [10251.059694] [] uas_post_reset+0x3c/0xb0 [uas] [10251.059722] [] usb_reset_device+0x1b9/0x2a0 [10251.059749] [] uas_eh_bus_reset_handler+0xb2/0x190 [uas] [10251.059781] [] scsi_try_bus_reset+0x53/0x110 [10251.059808] [] scsi_eh_bus_reset+0xf7/0x270 The problem is the following call sequence (simplified): 1) usb_reset_device 2) usb_reset_and_verify_device 2) hub_port_init 3) hub_port_finish_reset 3) xhci_discover_or_reset_device This frees xhci->devs[slot_id]->eps[ep_index].ring for all eps but 0 4) usb_get_device_descriptor This fails 5) hub_port_init fails 6) usb_reset_and_verify_device fails, does not restore device config 7) uas_post_reset 8) xhci_alloc_streams NULL deref on the free-ed ring This commit fixes this by not allowing usb_alloc_streams to continue if the device is not configured. Note that we do allow usb_free_streams to continue after a (logical) disconnect, as it is necessary to explicitly free the streams at the xhci controller level. Signed-off-by: Hans de Goede Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 9dcbeeb2d2a2a819fc1588277ad50cd9c3172242 Author: Johan Hovold Date: Mon Oct 27 18:34:33 2014 +0100 USB: cdc-acm: add device id for GW Instek AFG-2225 commit cf84a691a61606a2e7269907d3727e2d9fa148ee upstream. Add device-id entry for GW Instek AFG-2225, which has a byte swapped bInterfaceSubClass (0x20). Reported-by: Karl Palsson Signed-off-by: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 18e9928652ab76bc3044ab872199ced278e0be75 Author: Johan Hovold Date: Wed Oct 29 09:07:31 2014 +0100 USB: opticon: fix non-atomic allocation in write path commit e681286de221af78fc85db9222b6a203148c005a upstream. Write may be called from interrupt context so make sure to use GFP_ATOMIC for all allocations in write. Fixes: 0d930e51cfe6 ("USB: opticon: Add Opticon OPN2001 write support") Signed-off-by: Johan Hovold Signed-off-by: Zefan Li commit ac9428b118d6990dbfa9df97d49a7ccdb56c7736 Author: Johan Hovold Date: Wed Oct 29 09:07:30 2014 +0100 USB: kobil_sct: fix non-atomic allocation in write path commit 191252837626fca0de694c18bb2aa64c118eda89 upstream. Write may be called from interrupt context so make sure to use GFP_ATOMIC for all allocations in write. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Johan Hovold [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit b1873077c564ef1103f593d85f0792b16ea89367 Author: Anton Blanchard Date: Fri Oct 31 16:50:57 2014 +1100 powerpc: do_notify_resume can be called with bad thread_info flags argument commit 808be31426af57af22268ef0fcb42617beb3d15b upstream. Back in 7230c5644188 ("powerpc: Rework lazy-interrupt handling") we added a call out to restore_interrupts() (written in c) before calling do_notify_resume: bl restore_interrupts addi r3,r1,STACK_FRAME_OVERHEAD bl do_notify_resume Unfortunately do_notify_resume takes two arguments, the second one being the thread_info flags: void do_notify_resume(struct pt_regs *regs, unsigned long thread_info_flags) We do populate r4 (the second argument) earlier, but restore_interrupts() is free to muck it up all it wants. My guess is the gcc compiler gods shone down on us and its register allocator never used r4. Sometimes, rarely, luck is on our side. LLVM on the other hand did trample r4. Signed-off-by: Anton Blanchard Signed-off-by: Michael Ellerman [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit d6be20a0690320e1bd3970bafd8bc86b57fdf65b Author: Hans de Goede Date: Wed Oct 22 16:06:38 2014 +0200 acer-wmi: Add acpi_backlight=video quirk for the Acer KAV80 commit 183fd8fcd7f8afb7ac5ec68f83194872f9fecc84 upstream. The acpi-video backlight interface on the Acer KAV80 is broken, and worse it causes the entire machine to slow down significantly after a suspend/resume. Blacklist it, and use the acer-wmi backlight interface instead. Note that the KAV80 is somewhat unique in that it is the only Acer model where we fall back to acer-wmi after blacklisting, rather then using the native (e.g. intel) backlight driver. This is done because there is no native backlight interface on this model. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1128309 Signed-off-by: Hans de Goede Signed-off-by: Darren Hart Signed-off-by: Zefan Li commit a00a3c0334997f7932e42f6f22ae1718c183ab83 Author: Hans de Goede Date: Wed Oct 22 16:06:37 2014 +0200 samsung-laptop: Add broken-acpi-video quirk for NC210/NC110 commit 5a1426c99f9b7aa11d60c4e6b7a3211bb5321696 upstream. The acpi-video backlight interface on the NC210 does not work, blacklist it and use the samsung-laptop interface instead. BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=861573 Signed-off-by: Hans de Goede Signed-off-by: Darren Hart [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit c4a4211292d9b4ab4f94b985ebf37a9d16fb8a93 Author: Jan Kara Date: Thu Oct 30 10:53:17 2014 -0400 ext4: bail out from make_indexed_dir() on first error commit 6050d47adcadbb53582434d919ed7f038d936712 upstream. When ext4_handle_dirty_dx_node() or ext4_handle_dirty_dirent_node() fail, there's really something wrong with the fs and there's no point in continuing further. Just return error from make_indexed_dir() in that case. Also initialize frames array so that if we return early due to error, dx_release() doesn't try to dereference uninitialized memory (which could happen also due to error in do_split()). Coverity-id: 741300 Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o [lizf: Backported to 3.4: - adjust context - replace ext4_handle_dirty_{dx,dirent}_node() with ext4_handle_dirty_metadata()] Signed-off-by: Zefan Li commit 9922dba85d9a2d752297ff6030f6af84156472a7 Author: Rabin Vincent Date: Wed Oct 29 23:06:58 2014 +0100 tracing/syscalls: Ignore numbers outside NR_syscalls' range commit 086ba77a6db00ed858ff07451bedee197df868c9 upstream. ARM has some private syscalls (for example, set_tls(2)) which lie outside the range of NR_syscalls. If any of these are called while syscall tracing is being performed, out-of-bounds array access will occur in the ftrace and perf sys_{enter,exit} handlers. # trace-cmd record -e raw_syscalls:* true && trace-cmd report ... true-653 [000] 384.675777: sys_enter: NR 192 (0, 1000, 3, 4000022, ffffffff, 0) true-653 [000] 384.675812: sys_exit: NR 192 = 1995915264 true-653 [000] 384.675971: sys_enter: NR 983045 (76f74480, 76f74000, 76f74b28, 76f74480, 76f76f74, 1) true-653 [000] 384.675988: sys_exit: NR 983045 = 0 ... # trace-cmd record -e syscalls:* true [ 17.289329] Unable to handle kernel paging request at virtual address aaaaaace [ 17.289590] pgd = 9e71c000 [ 17.289696] [aaaaaace] *pgd=00000000 [ 17.289985] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 17.290169] Modules linked in: [ 17.290391] CPU: 0 PID: 704 Comm: true Not tainted 3.18.0-rc2+ #21 [ 17.290585] task: 9f4dab00 ti: 9e710000 task.ti: 9e710000 [ 17.290747] PC is at ftrace_syscall_enter+0x48/0x1f8 [ 17.290866] LR is at syscall_trace_enter+0x124/0x184 Fix this by ignoring out-of-NR_syscalls-bounds syscall numbers. Commit cd0980fc8add "tracing: Check invalid syscall nr while tracing syscalls" added the check for less than zero, but it should have also checked for greater than NR_syscalls. Link: http://lkml.kernel.org/p/1414620418-29472-1-git-send-email-rabin@rab.in Fixes: cd0980fc8add "tracing: Check invalid syscall nr while tracing syscalls" Signed-off-by: Rabin Vincent Signed-off-by: Steven Rostedt [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 4e6b1b9702836498015705ea4e870aab6b3dc637 Author: Will Deacon Date: Thu Aug 16 18:14:14 2012 +0100 tracing/syscalls: Fix perf syscall tracing when syscall_nr == -1 commit 60916a9382e88fbf5e54fd36a3e658efd7ab7bed upstream. syscall_get_nr can return -1 in the case that the task is not executing a system call. This patch fixes perf_syscall_{enter,exit} to check that the syscall number is valid before using it as an index into a bitmap. Link: http://lkml.kernel.org/r/1345137254-7377-1-git-send-email-will.deacon@arm.com Cc: Jason Baron Cc: Wade Farnsworth Cc: Frederic Weisbecker Signed-off-by: Will Deacon Signed-off-by: Steven Rostedt Signed-off-by: Zefan Li commit 7aff1a05050df389dd41eb1d2b9ade8d9ecb3c6c Author: Sinclair Yeh Date: Fri Oct 31 09:58:06 2014 +0100 drm/vmwgfx: Filter out modes those cannot be supported by the current VRAM size. commit 9a72384d86b26cb8a2b25106677e1197f606668f upstream. When screen objects are enabled, the bpp is assumed to be 32, otherwise it is set to 16. v2: * Use u32 instead of u64 for assumed_bpp. * Fixed mechanism to check for screen objects * Limit the back buffer size to VRAM. Signed-off-by: Sinclair Yeh Reviewed-by: Thomas Hellstrom [lizf: Backported to 3.4: drop the changes to vmw_driver_load()] Signed-off-by: Zefan Li commit 9813ed0b2d83b16206353134835a03af32701697 Author: Cyril Brulebois Date: Tue Oct 28 16:42:41 2014 +0100 wireless: rt2x00: add new rt2800usb device commit 664d6a792785cc677c2091038ce10322c8d04ae1 upstream. 0x1b75 0xa200 AirLive WN-200USB wireless 11b/g/n dongle References: https://bugs.debian.org/766802 Reported-by: Martin Mokrejs Signed-off-by: Cyril Brulebois Acked-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Zefan Li commit 8f71a69fa42f842824e488be11c84af325e5feac Author: Jan Kara Date: Thu Oct 30 10:53:16 2014 -0400 ext4: fix oops when loading block bitmap failed commit 599a9b77ab289d85c2d5c8607624efbe1f552b0f upstream. When we fail to load block bitmap in __ext4_new_inode() we will dereference NULL pointer in ext4_journal_get_write_access(). So check for error from ext4_read_block_bitmap(). Coverity-id: 989065 Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Zefan Li commit 64c7113dc103815f5631f8ed18e10b2b275fa1a0 Author: Jan Kara Date: Thu Oct 30 10:52:57 2014 -0400 ext4: fix overflow when updating superblock backups after resize commit 9378c6768e4fca48971e7b6a9075bc006eda981d upstream. When there are no meta block groups update_backups() will compute the backup block in 32-bit arithmetics thus possibly overflowing the block number and corrupting the filesystem. OTOH filesystems without meta block groups larger than 16 TB should be rare. Fix the problem by doing the counting in 64-bit arithmetics. Coverity-id: 741252 Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Reviewed-by: Lukas Czerner [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 638c69e2d59422dd2bd63d80f4d0b322ba9a14fb Author: Jan Kara Date: Wed Oct 29 14:50:44 2014 -0700 lib/bitmap.c: fix undefined shift in __bitmap_shift_{left|right}() commit ea5d05b34aca25c066e0699512d0ffbd8ee6ac3e upstream. If __bitmap_shift_left() or __bitmap_shift_right() are asked to shift by a multiple of BITS_PER_LONG, they will try to shift a long value by BITS_PER_LONG bits which is undefined. Change the functions to avoid the undefined shift. Coverity id: 1192175 Coverity id: 1192174 Signed-off-by: Jan Kara Cc: Rasmus Villemoes Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Zefan Li commit 5e93a23b3f887d4824d0e3f64e834fbc22b2bf9b Author: David Rientjes Date: Wed Oct 29 14:50:31 2014 -0700 mm, thp: fix collapsing of hugepages on madvise commit 6d50e60cd2edb5a57154db5a6f64eef5aa59b751 upstream. If an anonymous mapping is not allowed to fault thp memory and then madvise(MADV_HUGEPAGE) is used after fault, khugepaged will never collapse this memory into thp memory. This occurs because the madvise(2) handler for thp, hugepage_madvise(), clears VM_NOHUGEPAGE on the stack and it isn't stored in vma->vm_flags until the final action of madvise_behavior(). This causes the khugepaged_enter_vma_merge() to be a no-op in hugepage_madvise() when the vma had previously had VM_NOHUGEPAGE set. Fix this by passing the correct vma flags to the khugepaged mm slot handler. There's no chance khugepaged can run on this vma until after madvise_behavior() returns since we hold mm->mmap_sem. It would be possible to clear VM_NOHUGEPAGE directly from vma->vm_flags in hugepage_advise(), but I didn't want to introduce special case behavior into madvise_behavior(). I think it's best to just let it always set vma->vm_flags itself. Signed-off-by: David Rientjes Reported-by: Suleiman Souhlal Cc: "Kirill A. Shutemov" Cc: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 4fc93811a205db660b007a6d03386f9ef188a6b8 Author: Wang Nan Date: Wed Oct 29 14:50:18 2014 -0700 cgroup/kmemleak: add kmemleak_free() for cgroup deallocations. commit 401507d67d5c2854f5a88b3f93f64fc6f267bca5 upstream. Commit ff7ee93f4715 ("cgroup/kmemleak: Annotate alloc_page() for cgroup allocations") introduces kmemleak_alloc() for alloc_page_cgroup(), but corresponding kmemleak_free() is missing, which makes kmemleak be wrongly disabled after memory offlining. Log is pasted at the end of this commit message. This patch add kmemleak_free() into free_page_cgroup(). During page offlining, this patch removes corresponding entries in kmemleak rbtree. After that, the freed memory can be allocated again by other subsystems without killing kmemleak. bash # for x in 1 2 3 4; do echo offline > /sys/devices/system/memory/memory$x/state ; sleep 1; done ; dmesg | grep leak Offlined Pages 32768 kmemleak: Cannot insert 0xffff880016969000 into the object search tree (overlaps existing) CPU: 0 PID: 412 Comm: sleep Not tainted 3.17.0-rc5+ #86 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: dump_stack+0x46/0x58 create_object+0x266/0x2c0 kmemleak_alloc+0x26/0x50 kmem_cache_alloc+0xd3/0x160 __sigqueue_alloc+0x49/0xd0 __send_signal+0xcb/0x410 send_signal+0x45/0x90 __group_send_sig_info+0x13/0x20 do_notify_parent+0x1bb/0x260 do_exit+0x767/0xa40 do_group_exit+0x44/0xa0 SyS_exit_group+0x17/0x20 system_call_fastpath+0x16/0x1b kmemleak: Kernel memory leak detector disabled kmemleak: Object 0xffff880016900000 (size 524288): kmemleak: comm "swapper/0", pid 0, jiffies 4294667296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace: log_early+0x63/0x77 kmemleak_alloc+0x4b/0x50 init_section_page_cgroup+0x7f/0xf5 page_cgroup_init+0xc5/0xd0 start_kernel+0x333/0x408 x86_64_start_reservations+0x2a/0x2c x86_64_start_kernel+0xf5/0xfc Fixes: ff7ee93f4715 (cgroup/kmemleak: Annotate alloc_page() for cgroup allocations) Signed-off-by: Wang Nan Acked-by: Johannes Weiner Acked-by: Michal Hocko Cc: Steven Rostedt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Zefan Li commit 00d495a36788a4ad50295a93fafa82905f8f7aef Author: Will Deacon Date: Tue Oct 28 13:16:28 2014 -0700 zap_pte_range: update addr when forcing flush after TLB batching faiure commit ce9ec37bddb633404a0c23e1acb181a264e7f7f2 upstream. When unmapping a range of pages in zap_pte_range, the page being unmapped is added to an mmu_gather_batch structure for asynchronous freeing. If we run out of space in the batch structure before the range has been completely unmapped, then we break out of the loop, force a TLB flush and free the pages that we have batched so far. If there are further pages to unmap, then we resume the loop where we left off. Unfortunately, we forget to update addr when we break out of the loop, which causes us to truncate the range being invalidated as the end address is exclusive. When we re-enter the loop at the same address, the page has already been freed and the pte_present test will fail, meaning that we do not reconsider the address for invalidation. This patch fixes the problem by incrementing addr by the PAGE_SIZE before breaking out of the loop on batch failure. Signed-off-by: Will Deacon Signed-off-by: Linus Torvalds [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit d309bea3dc968c2bb976abcd16c86f05107daa38 Author: Alex Deucher Date: Sun Oct 26 15:18:42 2014 -0400 drm/radeon: remove invalid pci id commit 8c3e434769b1707fd2d24de5a2eb25fedc634c4a upstream. 0x4c6e is a secondary device id so should not be used by the driver. Noticed-by: Mark Kettenis Signed-off-by: Alex Deucher Signed-off-by: Zefan Li commit 63578cc53582e6fdf441cdaff1cc9d5a3ca3f6d2 Author: Dmitry Kasatkin Date: Tue Oct 28 14:28:49 2014 +0200 evm: check xattr value length and type in evm_inode_setxattr() commit 3b1deef6b1289a99505858a3b212c5b50adf0c2f upstream. evm_inode_setxattr() can be called with no value. The function does not check the length so that following command can be used to produce the kernel oops: setfattr -n security.evm FOO. This patch fixes it. Changes in v3: * there is no reason to return different error codes for EVM_XATTR_HMAC and non EVM_XATTR_HMAC. Remove unnecessary test then. Changes in v2: * testing for validity of xattr type [ 1106.396921] BUG: unable to handle kernel NULL pointer dereference at (null) [ 1106.398192] IP: [] evm_inode_setxattr+0x2a/0x48 [ 1106.399244] PGD 29048067 PUD 290d7067 PMD 0 [ 1106.399953] Oops: 0000 [#1] SMP [ 1106.400020] Modules linked in: bridge stp llc evdev serio_raw i2c_piix4 button fuse [ 1106.400020] CPU: 0 PID: 3635 Comm: setxattr Not tainted 3.16.0-kds+ #2936 [ 1106.400020] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 1106.400020] task: ffff8800291a0000 ti: ffff88002917c000 task.ti: ffff88002917c000 [ 1106.400020] RIP: 0010:[] [] evm_inode_setxattr+0x2a/0x48 [ 1106.400020] RSP: 0018:ffff88002917fd50 EFLAGS: 00010246 [ 1106.400020] RAX: 0000000000000000 RBX: ffff88002917fdf8 RCX: 0000000000000000 [ 1106.400020] RDX: 0000000000000000 RSI: ffffffff818136d3 RDI: ffff88002917fdf8 [ 1106.400020] RBP: ffff88002917fd68 R08: 0000000000000000 R09: 00000000003ec1df [ 1106.400020] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800438a0a00 [ 1106.400020] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 [ 1106.400020] FS: 00007f7dfa7d7740(0000) GS:ffff88005da00000(0000) knlGS:0000000000000000 [ 1106.400020] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1106.400020] CR2: 0000000000000000 CR3: 000000003763e000 CR4: 00000000000006f0 [ 1106.400020] Stack: [ 1106.400020] ffff8800438a0a00 ffff88002917fdf8 0000000000000000 ffff88002917fd98 [ 1106.400020] ffffffff812a1030 ffff8800438a0a00 ffff88002917fdf8 0000000000000000 [ 1106.400020] 0000000000000000 ffff88002917fde0 ffffffff8116d08a ffff88002917fdc8 [ 1106.400020] Call Trace: [ 1106.400020] [] security_inode_setxattr+0x5d/0x6a [ 1106.400020] [] vfs_setxattr+0x6b/0x9f [ 1106.400020] [] setxattr+0x122/0x16c [ 1106.400020] [] ? mnt_want_write+0x21/0x45 [ 1106.400020] [] ? __sb_start_write+0x10f/0x143 [ 1106.400020] [] ? mnt_want_write+0x21/0x45 [ 1106.400020] [] ? __mnt_want_write+0x48/0x4f [ 1106.400020] [] SyS_setxattr+0x6e/0xb0 [ 1106.400020] [] system_call_fastpath+0x16/0x1b [ 1106.400020] Code: c3 0f 1f 44 00 00 55 48 89 e5 41 55 49 89 d5 41 54 49 89 fc 53 48 89 f3 48 c7 c6 d3 36 81 81 48 89 df e8 18 22 04 00 85 c0 75 07 <41> 80 7d 00 02 74 0d 48 89 de 4c 89 e7 e8 5a fe ff ff eb 03 83 [ 1106.400020] RIP [] evm_inode_setxattr+0x2a/0x48 [ 1106.400020] RSP [ 1106.400020] CR2: 0000000000000000 [ 1106.428061] ---[ end trace ae08331628ba3050 ]--- Reported-by: Jan Kara Signed-off-by: Dmitry Kasatkin Signed-off-by: Mimi Zohar Signed-off-by: Zefan Li commit ad82ca3bfb2b43a17c9434ce03cfb5a91c9221e4 Author: Takashi Iwai Date: Tue Oct 28 12:42:19 2014 +0100 ALSA: pcm: Zero-clear reserved fields of PCM status ioctl in compat mode commit 317168d0c766defd14b3d0e9c2c4a9a258b803ee upstream. In compat mode, we copy each field of snd_pcm_status struct but don't touch the reserved fields, and this leaves uninitialized values there. Meanwhile the native ioctl does zero-clear the whole structure, so we should follow the same rule in compat mode, too. Reported-by: Pierre-Louis Bossart Signed-off-by: Takashi Iwai Signed-off-by: Zefan Li commit 358105b826419ac319ad05b398d40a31c52de90d Author: Imre Deak Date: Fri Oct 24 20:29:10 2014 +0300 PM / Sleep: fix recovery during resuming from hibernation commit 94fb823fcb4892614f57e59601bb9d4920f24711 upstream. If a device's dev_pm_ops::freeze callback fails during the QUIESCE phase, we don't rollback things correctly calling the thaw and complete callbacks. This could leave some devices in a suspended state in case of an error during resuming from hibernation. Signed-off-by: Imre Deak Signed-off-by: Rafael J. Wysocki Signed-off-by: Zefan Li commit b1a76f1c42ec736247cd9a789d67532f7f2a1d31 Author: Brian Silverman Date: Sat Oct 25 20:20:37 2014 -0400 futex: Fix a race condition between REQUEUE_PI and task death commit 30a6b8031fe14031ab27c1fa3483cb9780e7f63c upstream. free_pi_state and exit_pi_state_list both clean up futex_pi_state's. exit_pi_state_list takes the hb lock first, and most callers of free_pi_state do too. requeue_pi doesn't, which means free_pi_state can free the pi_state out from under exit_pi_state_list. For example: task A | task B exit_pi_state_list | pi_state = | curr->pi_state_list->next | | futex_requeue(requeue_pi=1) | // pi_state is the same as | // the one in task A | free_pi_state(pi_state) | list_del_init(&pi_state->list) | kfree(pi_state) list_del_init(&pi_state->list) | Move the free_pi_state calls in requeue_pi to before it drops the hb locks which it's already holding. [ tglx: Removed a pointless free_pi_state() call and the hb->lock held debugging. The latter comes via a seperate patch ] Signed-off-by: Brian Silverman Cc: austin.linux@gmail.com Cc: darren@dvhart.com Cc: peterz@infradead.org Link: http://lkml.kernel.org/r/1414282837-23092-1-git-send-email-bsilver16384@gmail.com Signed-off-by: Thomas Gleixner [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit aab6a6fa71741bb96288b634d4506e1630dba46a Author: Mathias Krause Date: Sat Oct 4 23:06:39 2014 +0200 posix-timers: Fix stack info leak in timer_create() commit 6891c4509c792209c44ced55a60f13954cb50ef4 upstream. If userland creates a timer without specifying a sigevent info, we'll create one ourself, using a stack local variable. Particularly will we use the timer ID as sival_int. But as sigev_value is a union containing a pointer and an int, that assignment will only partially initialize sigev_value on systems where the size of a pointer is bigger than the size of an int. On such systems we'll copy the uninitialized stack bytes from the timer_create() call to userland when the timer actually fires and we're going to deliver the signal. Initialize sigev_value with 0 to plug the stack info leak. Found in the PaX patch, written by the PaX Team. Fixes: 5a9fa7307285 ("posix-timers: kill ->it_sigev_signo and...") Signed-off-by: Mathias Krause Cc: Oleg Nesterov Cc: Brad Spengler Cc: PaX Team Link: http://lkml.kernel.org/r/1412456799-32339-1-git-send-email-minipli@googlemail.com Signed-off-by: Thomas Gleixner [lizf: Backported to 3.4: adjust filename] Signed-off-by: Zefan Li commit 65979d9f71de14952febb9f397a5949c220fa2dd Author: Hans de Goede Date: Fri Oct 24 14:55:24 2014 -0700 Input: i8042 - quirks for Fujitsu Lifebook A544 and Lifebook AH544 commit 993b3a3f80a7842a48cd46c2b41e1b3ef6302468 upstream. These models need i8042.notimeout, otherwise the touchpad will not work. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=69731 BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1111138 Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li commit 72c2bc686cf768114a519e2dbb31a37e7793b002 Author: Jack Pham Date: Tue Oct 21 16:31:10 2014 -0700 usb: dwc3: gadget: Properly initialize LINK TRB commit 1200a82a59b6aa65758ccc92c3447b98c53cd7a2 upstream. On ISOC endpoints the last trb_pool entry used as a LINK TRB is not getting zeroed out correctly due to memset being called incorrectly and in the wrong place. If pool allocated from DMA was not zero-initialized to begin with this will result in the size and ctrl values being random garbage. Call memset correctly after assignment of the trb_link pointer. Fixes: f6bafc6a1c ("usb: dwc3: convert TRBs into bitshifts") Signed-off-by: Jack Pham Signed-off-by: Felipe Balbi Signed-off-by: Zefan Li commit 971918b8e4fbe202b6be1fa1a31f1991c08164dc Author: J. Bruce Fields Date: Wed Oct 22 14:46:29 2014 -0400 nfsd4: fix crash on unknown operation number commit 51904b08072a8bf2b9ed74d1bd7a5300a614471d upstream. Unknown operation numbers are caught in nfsd4_decode_compound() which sets op->opnum to OP_ILLEGAL and op->status to nfserr_op_illegal. The error causes the main loop in nfsd4_proc_compound() to skip most processing. But nfsd4_proc_compound also peeks ahead at the next operation in one case and doesn't take similar precautions there. Signed-off-by: J. Bruce Fields Signed-off-by: Zefan Li commit 6b91578a5af27dbba3c9b26bc918165eefcff7d3 Author: Perry Hung Date: Wed Oct 22 23:31:34 2014 -0400 usb: serial: ftdi_sio: add "bricked" FTDI device PID commit 7f2719f0003da1ad13124ef00f48d7514c79e30d upstream. An official recent Windows driver from FTDI detects counterfeit devices and reprograms the internal EEPROM containing the USB PID to 0, effectively bricking the device. Add support for this VID/PID pair to correctly bind the driver on these devices. See: http://hackaday.com/2014/10/22/watch-that-windows-update-ftdi-drivers-are-killing-fake-chips/ Signed-off-by: Perry Hung Acked-by: Greg Kroah-Hartman Signed-off-by: Johan Hovold [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 981cf05b831a41bf4e73ee557d404568907f36ff Author: Jan Kara Date: Wed Oct 22 20:13:39 2014 -0600 scsi: Fix error handling in SCSI_IOCTL_SEND_COMMAND commit 84ce0f0e94ac97217398b3b69c21c7a62ebeed05 upstream. When sg_scsi_ioctl() fails to prepare request to submit in blk_rq_map_kern() we jump to a label where we just end up copying (luckily zeroed-out) kernel buffer to userspace instead of reporting error. Fix the problem by jumping to the right label. CC: Jens Axboe CC: linux-scsi@vger.kernel.org Coverity-id: 1226871 Signed-off-by: Jan Kara Fixed up the, now unused, out label. Signed-off-by: Jens Axboe Signed-off-by: Zefan Li commit 69fd3543d6eb6150af2d5f712f01a1452a9a2b78 Author: Andy Lutomirski Date: Wed Oct 15 10:12:07 2014 -0700 x86, apic: Handle a bad TSC more gracefully commit b47dcbdc5161d3d5756f430191e2840d9b855492 upstream. If the TSC is unusable or disabled, then this patch fixes: - Confusion while trying to clear old APIC interrupts. - Division by zero and incorrect programming of the TSC deadline timer. This fixes boot if the CPU has a TSC deadline timer but a missing or broken TSC. The failure to boot can be observed with qemu using -cpu qemu64,-tsc,+tsc-deadline This also happens to me in nested KVM for unknown reasons. With this patch, I can boot cleanly (although without a TSC). Signed-off-by: Andy Lutomirski Cc: Bandan Das Link: http://lkml.kernel.org/r/e2fa274e498c33988efac0ba8b7e3120f7f92d78.1413393027.git.luto@amacapital.net Signed-off-by: Thomas Gleixner [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit b7914bbd932cd0e372c1bf755b2c4e48bfec99e7 Author: Dan Williams Date: Tue Oct 14 11:10:41 2014 -0500 USB: option: add Haier CE81B CDMA modem commit 012eee1522318b5ccd64d277d50ac32f7e9974fe upstream. Port layout: 0: QCDM/DIAG 1: NMEA 2: AT 3: AT/PPP Signed-off-by: Dan Williams Signed-off-by: Johan Hovold Signed-off-by: Zefan Li commit 4e8dba76aa02aa7fbb76403a0417421aebb28652 Author: Daniele Palmas Date: Tue Oct 14 10:47:37 2014 +0200 usb: option: add support for Telit LE910 commit 2d0eb862dd477c3c4f32b201254ca0b40e6f465c upstream. Add VID/PID for Telit LE910 modem. Interfaces description is almost the same than LE920, except that the qmi interface is number 2 (instead than 5). Signed-off-by: Daniele Palmas Signed-off-by: Johan Hovold Signed-off-by: Zefan Li commit f60cca4079a53606382a4d958fc20dcb38cd8efc Author: Frans Klaver Date: Fri Oct 10 11:52:08 2014 +0200 usb: serial: ftdi_sio: add Awinda Station and Dongle products commit edd74ffab1f6909eee400c7de8ce621870aacac9 upstream. Add new IDs for the Xsens Awinda Station and Awinda Dongle. While at it, order the definitions by PID and add a logical separation between devices using Xsens' VID and those using FTDI's VID. Signed-off-by: Frans Klaver Signed-off-by: Johan Hovold Signed-off-by: Zefan Li commit c870bd06eeadc89056ce1d59df7c88ded422e04e Author: Patrick Riphagen Date: Thu Jul 24 09:09:50 2014 +0200 USB: serial: ftdi_sio: Add support for new Xsens devices commit 4bdcde358b4bda74e356841d351945ca3f2245dd upstream. This adds support for new Xsens devices, using Xsens' own Vendor ID. Signed-off-by: Patrick Riphagen Signed-off-by: Frans Klaver Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit aa1ef47d3c8a7f8f80f57b2024b5f1f5ebde9c08 Author: Patrick Riphagen Date: Thu Jul 24 09:12:52 2014 +0200 USB: serial: ftdi_sio: Annotate the current Xsens PID assignments commit 9273b8a270878906540349422ab24558b9d65716 upstream. The converters are used in specific products. It can be useful to know which they are exactly. Signed-off-by: Patrick Riphagen Signed-off-by: Frans Klaver Cc: Johan Hovold Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 6810992a49a289e03c913a8c3af4842ce368cc67 Author: Nathaniel Ting Date: Fri Oct 3 12:01:20 2014 -0400 USB: serial: cp210x: add Silicon Labs 358x VID and PID commit 35cc83eab097e5720a9cc0ec12bdc3a726f58381 upstream. Enable Silicon Labs Ember VID chips to enumerate with the cp210x usb serial driver. EM358x devices operating with the Ember Z-Net 5.1.2 stack may now connect to host PCs over a USB serial link. Signed-off-by: Nathaniel Ting Signed-off-by: Johan Hovold Signed-off-by: Zefan Li commit 67ff8829e6954ec9894f55db93bb6db297aaf1b7 Author: Jan Kara Date: Tue Sep 16 22:23:10 2014 +0200 ext3: Don't check quota format when there are no quota files commit 7938db449bbc55bbeb164bec7af406212e7e98f1 upstream. The check whether quota format is set even though there are no quota files with journalled quota is pointless and it actually makes it impossible to turn off journalled quotas (as there's no way to unset journalled quota format). Just remove the check. Signed-off-by: Jan Kara Signed-off-by: Zefan Li commit 0169c97f99ba46668a0da5a650defa29c424b343 Author: Felipe Balbi Date: Wed Sep 24 14:19:52 2014 -0500 usb: dwc3: gadget: fix set_halt() bug with pending transfers commit 7a60855972f0d3c014093046cb6f013a1ee5bb19 upstream. According to our Gadget Framework API documentation, ->set_halt() *must* return -EAGAIN if we have pending transfers (on either direction) or FIFO isn't empty (on TX endpoints). Fix this bug so that the mass storage gadget can be used without stall=0 parameter. This patch should be backported to all kernels since v3.2. Suggested-by: Alan Stern Signed-off-by: Felipe Balbi [lizf: Backported to 3.4: - adjust context - drop the change to dwc3_gadget_ep_set_wedge()] Signed-off-by: Zefan Li commit 37cccefbb8dd18738beb6df75c1537a86750c6ce Author: Ray Jui Date: Thu Oct 9 11:44:54 2014 -0700 spi: pl022: Fix incorrect dma_unmap_sg commit 3ffa6158f002e096d28ede71be4e0ee8ab20baa2 upstream. When mapped RX DMA entries are unmapped in an error condition when DMA is firstly configured in the driver, the number of TX DMA entries was passed in, which is incorrect Signed-off-by: Ray Jui Signed-off-by: Mark Brown Signed-off-by: Zefan Li commit 30e55da73d161504f610115a2de141137e69e924 Author: Lars-Peter Clausen Date: Thu Sep 25 15:27:00 2014 +0100 staging:iio:ad5933: Drop "raw" from channel names commit 6822ee34ad57b29a3b44df2c2829910f03c34fa4 upstream. "raw" is the name of a channel property, but should not be part of the channel name itself. Signed-off-by: Lars-Peter Clausen Signed-off-by: Jonathan Cameron [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 1fb46361f9b20239de0ab5337e457f581646f0ea Author: Jonathan Cameron Date: Fri Apr 13 10:42:58 2012 +0100 staging:iio:impedance-analyzer:ad5933 unwind use of IIO_CHAN macro. commit cdacc05bfa479997424fa9a3b54c07573b0ce4ed upstream. This macro is being removed to simplify ongoing maintenance so we need to unwind and remaining users. Signed-off-by: Jonathan Cameron Acked-by: Lars-Peter Clausen Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit ee7b6267225752affabcbc93ff47678e9de502a0 Author: Quentin Casasnovas Date: Fri Oct 17 22:55:59 2014 +0200 kvm: fix excessive pages un-pinning in kvm_iommu_map error path. commit 3d32e4dbe71374a6780eaf51d719d76f9a9bf22f upstream. The third parameter of kvm_unpin_pages() when called from kvm_iommu_map_pages() is wrong, it should be the number of pages to un-pin and not the page size. This error was facilitated with an inconsistent API: kvm_pin_pages() takes a size, but kvn_unpin_pages() takes a number of pages, so fix the problem by matching the two. This was introduced by commit 350b8bd ("kvm: iommu: fix the third parameter of kvm_iommu_put_pages (CVE-2014-3601)"), which fixes the lack of un-pinning for pages intended to be un-pinned (i.e. memory leak) but unfortunately potentially aggravated the number of pages we un-pin that should have stayed pinned. As far as I understand though, the same practical mitigations apply. This issue was found during review of Red Hat 6.6 patches to prepare Ksplice rebootless updates. Thanks to Vegard for his time on a late Friday evening to help me in understanding this code. Fixes: 350b8bd ("kvm: iommu: fix the third parameter of... (CVE-2014-3601)") Signed-off-by: Quentin Casasnovas Signed-off-by: Vegard Nossum Signed-off-by: Jamie Iles Reviewed-by: Sasha Levin Signed-off-by: Paolo Bonzini [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit c7ea5dfa84defdcb410aba2466164dbd604b7341 Author: Michael S. Tsirkin Date: Thu Sep 18 16:21:16 2014 +0300 kvm: x86: don't kill guest on unknown exit reason commit 2bc19dc3754fc066c43799659f0d848631c44cfe upstream. KVM_EXIT_UNKNOWN is a kvm bug, we don't really know whether it was triggered by a priveledged application. Let's not kill the guest: WARN and inject #UD instead. Signed-off-by: Michael S. Tsirkin Signed-off-by: Paolo Bonzini Signed-off-by: Zefan Li commit 19016101fc9260be9d2f6f2def34f56b29afaa7e Author: Petr Matousek Date: Tue Sep 23 20:22:30 2014 +0200 kvm: vmx: handle invvpid vm exit gracefully commit a642fc305053cc1c6e47e4f4df327895747ab485 upstream. On systems with invvpid instruction support (corresponding bit in IA32_VMX_EPT_VPID_CAP MSR is set) guest invocation of invvpid causes vm exit, which is currently not handled and results in propagation of unknown exit to userspace. Fix this by installing an invvpid vm exit handler. This is CVE-2014-3646. Signed-off-by: Petr Matousek Signed-off-by: Paolo Bonzini [lizf: Backported to 3.4: - adjust filename - drop the change to VMX_EXIT_REASON strings] Signed-off-by: Zefan Li commit 291fd081a444af428d3b3ccca15aede242827c6f Author: Nadav Har'El Date: Mon Aug 5 11:07:17 2013 +0300 nEPT: Nested INVEPT commit bfd0a56b90005f8c8a004baf407ad90045c2b11e upstream. If we let L1 use EPT, we should probably also support the INVEPT instruction. In our current nested EPT implementation, when L1 changes its EPT table for L2 (i.e., EPT12), L0 modifies the shadow EPT table (EPT02), and in the course of this modification already calls INVEPT. But if last level of shadow page is unsync not all L1's changes to EPT12 are intercepted, which means roots need to be synced when L1 calls INVEPT. Global INVEPT should not be different since roots are synced by kvm_mmu_load() each time EPTP02 changes. Reviewed-by: Xiao Guangrong Signed-off-by: Nadav Har'El Signed-off-by: Jun Nakajima Signed-off-by: Xinhao Xu Signed-off-by: Yang Zhang Signed-off-by: Gleb Natapov Signed-off-by: Paolo Bonzini [bwh: Backported to 3.2: - Adjust context, filename - Simplify handle_invept() as recommended by Paolo - nEPT is not supported so we always raise #UD] Signed-off-by: Ben Hutchings Signed-off-by: Zefan Li commit 48dfdb0c21f8254ef2a91f91792d73414fa635ae Author: Nadav Amit Date: Thu Sep 18 22:39:39 2014 +0300 KVM: x86: Handle errors when RIP is set during far jumps commit d1442d85cc30ea75f7d399474ca738e0bc96f715 upstream. Far jmp/call/ret may fault while loading a new RIP. Currently KVM does not handle this case, and may result in failed vm-entry once the assignment is done. The tricky part of doing so is that loading the new CS affects the VMCS/VMCB state, so if we fail during loading the new RIP, we are left in unconsistent state. Therefore, this patch saves on 64-bit the old CS descriptor and restores it if loading RIP failed. This fixes CVE-2014-3647. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini [lizf: Backported to 3.4: - adjust context - __load_segment_descriptor() doesn't take in_task_switch parameter] Signed-off-by: Zefan Li commit d1d7b57b3c62a47e0a2a2a4c742d7df06b58cd15 Author: Paolo Bonzini Date: Thu May 15 17:56:57 2014 +0200 KVM: x86: use new CS.RPL as CPL during task switch commit 2356aaeb2f58f491679dc0c38bc3f6dbe54e7ded upstream. During task switch, all of CS.DPL, CS.RPL, SS.DPL must match (in addition to all the other requirements) and will be the new CPL. So far this worked by carefully setting the CS selector and flag before doing the task switch; setting CS.selector will already change the CPL. However, this will not work once we get the CPL from SS.DPL, because then you will have to set the full segment descriptor cache to change the CPL. ctxt->ops->cpl(ctxt) will then return the old CPL during the task switch, and the check that SS.DPL == CPL will fail. Temporarily assume that the CPL comes from CS.RPL during task switch to a protected-mode task. This is the same approach used in QEMU's emulation code, which (until version 2.0) manually tracks the CPL. Signed-off-by: Paolo Bonzini [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 858f9338565cba5fba27a30466417816f7ed5035 Author: Nadav Amit Date: Thu Sep 18 22:39:38 2014 +0300 KVM: x86: Emulator fixes for eip canonical checks on near branches commit 234f3ce485d54017f15cf5e0699cff4100121601 upstream. Before changing rip (during jmp, call, ret, etc.) the target should be asserted to be canonical one, as real CPUs do. During sysret, both target rsp and rip should be canonical. If any of these values is noncanonical, a #GP exception should occur. The exception to this rule are syscall and sysenter instructions in which the assigned rip is checked during the assignment to the relevant MSRs. This patch fixes the emulator to behave as real CPUs do for near branches. Far branches are handled by the next patch. This fixes CVE-2014-3647. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini [lizf: Backported to 3.4: - adjust context - use ctxt->regs rather than reg_read() and reg_write()] Signed-off-by: Zefan Li commit 973be4a7c781c0112f71f28d847d0f02acb3b85a Author: Nadav Amit Date: Thu Sep 18 22:39:37 2014 +0300 KVM: x86: Fix wrong masking on relative jump/call commit 05c83ec9b73c8124555b706f6af777b10adf0862 upstream. Relative jumps and calls do the masking according to the operand size, and not according to the address size as the KVM emulator does today. This patch fixes KVM behavior. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini Signed-off-by: Zefan Li commit 375c51cd3742b2d38f9e2d905778a3d7c3aca962 Author: Andy Honig Date: Wed Aug 27 14:42:54 2014 -0700 KVM: x86: Improve thread safety in pit commit 2febc839133280d5a5e8e1179c94ea674489dae2 upstream. There's a race condition in the PIT emulation code in KVM. In __kvm_migrate_pit_timer the pit_timer object is accessed without synchronization. If the race condition occurs at the wrong time this can crash the host kernel. This fixes CVE-2014-3611. Signed-off-by: Andrew Honig Signed-off-by: Paolo Bonzini [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 6a607be83eb48696177fa8140550db7c54bf5758 Author: Andy Honig Date: Wed Aug 27 11:16:44 2014 -0700 KVM: x86: Prevent host from panicking on shared MSR writes. commit 8b3c3104c3f4f706e99365c3e0d2aa61b95f969f upstream. The previous patch blocked invalid writes directly when the MSR is written. As a precaution, prevent future similar mistakes by gracefulling handle GPs caused by writes to shared MSRs. Signed-off-by: Andrew Honig [Remove parts obsoleted by Nadav's patch. - Paolo] Signed-off-by: Paolo Bonzini [lizf: Backported to 3.4: - adjust context - s/wrmsrl_safe/checking_wrmsrl/] Signed-off-by: Zefan Li commit ab998b3caaab608a0ebe0b8e2030e4e68054e270 Author: Nadav Amit Date: Tue Sep 16 03:24:05 2014 +0300 KVM: x86: Check non-canonical addresses upon WRMSR commit 854e8bb1aa06c578c2c9145fa6bfe3680ef63b23 upstream. Upon WRMSR, the CPU should inject #GP if a non-canonical value (address) is written to certain MSRs. The behavior is "almost" identical for AMD and Intel (ignoring MSRs that are not implemented in either architecture since they would anyhow #GP). However, IA32_SYSENTER_ESP and IA32_SYSENTER_EIP cause #GP if non-canonical address is written on Intel but not on AMD (which ignores the top 32-bits). Accordingly, this patch injects a #GP on the MSRs which behave identically on Intel and AMD. To eliminate the differences between the architecutres, the value which is written to IA32_SYSENTER_ESP and IA32_SYSENTER_EIP is turned to canonical value before writing instead of injecting a #GP. Some references from Intel and AMD manuals: According to Intel SDM description of WRMSR instruction #GP is expected on WRMSR "If the source register contains a non-canonical address and ECX specifies one of the following MSRs: IA32_DS_AREA, IA32_FS_BASE, IA32_GS_BASE, IA32_KERNEL_GS_BASE, IA32_LSTAR, IA32_SYSENTER_EIP, IA32_SYSENTER_ESP." According to AMD manual instruction manual: LSTAR/CSTAR (SYSCALL): "The WRMSR instruction loads the target RIP into the LSTAR and CSTAR registers. If an RIP written by WRMSR is not in canonical form, a general-protection exception (#GP) occurs." IA32_GS_BASE and IA32_FS_BASE (WRFSBASE/WRGSBASE): "The address written to the base field must be in canonical form or a #GP fault will occur." IA32_KERNEL_GS_BASE (SWAPGS): "The address stored in the KernelGSbase MSR must be in canonical form." This patch fixes CVE-2014-3610. Signed-off-by: Nadav Amit Signed-off-by: Paolo Bonzini [lizf: Backported to 3.4: - adjust context - s/msr->index/msr_index and s/msr->data/data] Signed-off-by: Zefan Li commit aea44610e138333df482345cbc81a8959be0da94 Author: Dirk Brandewie Date: Mon Oct 13 08:37:40 2014 -0700 cpufreq: expose scaling_cur_freq sysfs file for set_policy() drivers commit c034b02e213d271b98c45c4a7b54af8f69aaac1e upstream. Currently the core does not expose scaling_cur_freq for set_policy() drivers this breaks some userspace monitoring tools. Change the core to expose this file for all drivers and if the set_policy() driver supports the get() callback use it to retrieve the current frequency. Link: https://bugzilla.kernel.org/show_bug.cgi?id=73741 Signed-off-by: Dirk Brandewie Signed-off-by: Rafael J. Wysocki [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit e930516632e7bde53d1abc5154e9245c4b0bdb09 Author: David Daney Date: Mon Oct 20 15:34:23 2014 -0700 MIPS: tlbex: Properly fix HUGE TLB Refill exception handler commit 9e0f162a36914937a937358fcb45e0609ef2bfc4 upstream. In commit 8393c524a25609 (MIPS: tlbex: Fix a missing statement for HUGETLB), the TLB Refill handler was fixed so that non-OCTEON targets would work properly with huge pages. The change was incorrect in that it broke the OCTEON case. The problem is shown here: xxx0: df7a0000 ld k0,0(k1) . . . xxxc0: df610000 ld at,0(k1) xxxc4: 335a0ff0 andi k0,k0,0xff0 xxxc8: e825ffcd bbit1 at,0x5,0x0 xxxcc: 003ad82d daddu k1,at,k0 . . . In the non-octeon case there is a destructive test for the huge PTE bit, and then at 0, $k0 is reloaded (that is what the 8393c524a25609 patch added). In the octeon case, we modify k1 in the branch delay slot, but we never need k0 again, so the new load is not needed, but since k1 is modified, if we do the load, we load from a garbage location and then get a nested TLB Refill, which is seen in userspace as either SIGBUS or SIGSEGV (depending on the garbage). The real fix is to only do this reloading if it is needed, and never where it is harmful. Signed-off-by: David Daney Cc: Huacai Chen Cc: Fuxin Zhang Cc: Zhangjin Wu Cc: linux-mips@linux-mips.org Patchwork: https://patchwork.linux-mips.org/patch/8151/ Signed-off-by: Ralf Baechle Signed-off-by: Zefan Li commit b58f0431a070f39b0e140255a26e87b3ad4557a0 Author: Huacai Chen Date: Tue Jul 29 14:54:40 2014 +0800 MIPS: tlbex: Fix a missing statement for HUGETLB commit 8393c524a25609a30129e4a8975cf3b91f6c16a5 upstream. In commit 2c8c53e28f1 (MIPS: Optimize TLB handlers for Octeon CPUs) build_r4000_tlb_refill_handler() is modified. But it doesn't compatible with the original code in HUGETLB case. Because there is a copy & paste error and one line of code is missing. It is very easy to produce a bug with LTP's hugemmap05 test. Signed-off-by: Huacai Chen Signed-off-by: Binbin Zhou Cc: John Crispin Cc: Steven J. Hill Cc: linux-mips@linux-mips.org Cc: Fuxin Zhang Cc: Zhangjin Wu Patchwork: https://patchwork.linux-mips.org/patch/7496/ Signed-off-by: Ralf Baechle Signed-off-by: Zefan Li commit 7655f8554eb2792101151ba7a79919bf0a78b51c Author: Michal Hocko Date: Mon Oct 20 18:12:32 2014 +0200 OOM, PM: OOM killed task shouldn't escape PM suspend commit 5695be142e203167e3cb515ef86a88424f3524eb upstream. PM freezer relies on having all tasks frozen by the time devices are getting frozen so that no task will touch them while they are getting frozen. But OOM killer is allowed to kill an already frozen task in order to handle OOM situtation. In order to protect from late wake ups OOM killer is disabled after all tasks are frozen. This, however, still keeps a window open when a killed task didn't manage to die by the time freeze_processes finishes. Reduce the race window by checking all tasks after OOM killer has been disabled. This is still not race free completely unfortunately because oom_killer_disable cannot stop an already ongoing OOM killer so a task might still wake up from the fridge and get killed without freeze_processes noticing. Full synchronization of OOM and freezer is, however, too heavy weight for this highly unlikely case. Introduce and check oom_kills counter which gets incremented early when the allocator enters __alloc_pages_may_oom path and only check all the tasks if the counter changes during the freezing attempt. The counter is updated so early to reduce the race window since allocator checked oom_killer_disabled which is set by PM-freezing code. A false positive will push the PM-freezer into a slow path but that is not a big deal. Changes since v1 - push the re-check loop out of freeze_processes into check_frozen_processes and invert the condition to make the code more readable as per Rafael Fixes: f660daac474c6f (oom: thaw threads if oom killed thread is frozen before deferring) Signed-off-by: Michal Hocko Signed-off-by: Rafael J. Wysocki Signed-off-by: Zefan Li commit b71ec07584b31aacb937d8b775a6e373b109028a Author: Oleg Nesterov Date: Tue Jan 21 15:49:56 2014 -0800 introduce for_each_thread() to replace the buggy while_each_thread() commit 0c740d0afc3bff0a097ad03a1c8df92757516f5c upstream. while_each_thread() and next_thread() should die, almost every lockless usage is wrong. 1. Unless g == current, the lockless while_each_thread() is not safe. while_each_thread(g, t) can loop forever if g exits, next_thread() can't reach the unhashed thread in this case. Note that this can happen even if g is the group leader, it can exec. 2. Even if while_each_thread() itself was correct, people often use it wrongly. It was never safe to just take rcu_read_lock() and loop unless you verify that pid_alive(g) == T, even the first next_thread() can point to the already freed/reused memory. This patch adds signal_struct->thread_head and task->thread_node to create the normal rcu-safe list with the stable head. The new for_each_thread(g, t) helper is always safe under rcu_read_lock() as long as this task_struct can't go away. Note: of course it is ugly to have both task_struct->thread_node and the old task_struct->thread_group, we will kill it later, after we change the users of while_each_thread() to use for_each_thread(). Perhaps we can kill it even before we convert all users, we can reimplement next_thread(t) using the new thread_head/thread_node. But we can't do this right now because this will lead to subtle behavioural changes. For example, do/while_each_thread() always sees at least one task, while for_each_thread() can do nothing if the whole thread group has died. Or thread_group_empty(), currently its semantics is not clear unless thread_group_leader(p) and we need to audit the callers before we can change it. So this patch adds the new interface which has to coexist with the old one for some time, hopefully the next changes will be more or less straightforward and the old one will go away soon. Signed-off-by: Oleg Nesterov Reviewed-by: Sergey Dyasly Tested-by: Sergey Dyasly Reviewed-by: Sameer Nanda Acked-by: David Rientjes Cc: "Eric W. Biederman" Cc: Frederic Weisbecker Cc: Mandeep Singh Baines Cc: "Ma, Xindong" Cc: Michal Hocko Cc: "Tu, Xiaobing" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Zefan Li commit ace595fd79ba3c6f1d067e8be9d311951f591d9c Author: Oleg Nesterov Date: Wed Jul 3 15:08:30 2013 -0700 kernel/fork.c:copy_process(): unify CLONE_THREAD-or-thread_group_leader code commit 80628ca06c5d42929de6bc22c0a41589a834d151 upstream. Cleanup and preparation for the next changes. Move the "if (clone_flags & CLONE_THREAD)" code down under "if (likely(p->pid))" and turn it into into the "else" branch. This makes the process/thread initialization more symmetrical and removes one check. Signed-off-by: Oleg Nesterov Cc: "Eric W. Biederman" Cc: Michal Hocko Cc: Pavel Emelyanov Cc: Sergey Dyasly Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Zefan Li commit a2ca02f15bababecd0b0626a13a6291fd2d04dbc Author: Cong Wang Date: Tue Oct 21 09:27:12 2014 +0200 freezer: Do not freeze tasks killed by OOM killer commit 51fae6da640edf9d266c94f36bc806c63c301991 upstream. Since f660daac474c6f (oom: thaw threads if oom killed thread is frozen before deferring) OOM killer relies on being able to thaw a frozen task to handle OOM situation but a3201227f803 (freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE) has reorganized the code and stopped clearing freeze flag in __thaw_task. This means that the target task only wakes up and goes into the fridge again because the freezing condition hasn't changed for it. This reintroduces the bug fixed by f660daac474c6f. Fix the issue by checking for TIF_MEMDIE thread flag in freezing_slow_path and exclude the task from freezing completely. If a task was already frozen it would get woken by __thaw_task from OOM killer and get out of freezer after rechecking freezing(). Changes since v1 - put TIF_MEMDIE check into freezing_slowpath rather than in __refrigerator as per Oleg - return __thaw_task into oom_scan_process_thread because oom_kill_process will not wake task in the fridge because it is sleeping uninterruptible [mhocko@suse.cz: rewrote the changelog] Fixes: a3201227f803 (freezer: make freezing() test freeze conditions in effect instead of TIF_FREEZE) Signed-off-by: Cong Wang Signed-off-by: Michal Hocko Acked-by: Oleg Nesterov Signed-off-by: Rafael J. Wysocki Signed-off-by: Zefan Li commit 7e55164764dc6dad42ae86ae5ebec4f352a87fdb Author: Vlad Catoi Date: Sat Oct 18 17:45:41 2014 -0500 ALSA: usb-audio: Add support for Steinberg UR22 USB interface commit f0b127fbfdc8756eba7437ab668f3169280bd358 upstream. Adding support for Steinberg UR22 USB interface via quirks table patch See Ubuntu bug report: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1317244 Also see threads: http://linux-audio.4202.n7.nabble.com/Support-for-Steinberg-UR22-Yamaha-USB-chipset-0499-1509-tc82888.html#a82917 http://www.steinberg.net/forums/viewtopic.php?t=62290 Tested by at least 4 people judging by the threads. Did not test MIDI interface, but audio output and capture both are functional. Built 3.17 kernel with this driver on Ubuntu 14.04 & tested with mpg123 Patch applied to 3.13 Ubuntu kernel works well enough for daily use. Signed-off-by: Vlad Catoi Acked-by: Clemens Ladisch Signed-off-by: Takashi Iwai [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 7a13f726f0a6a051f2a3e5b18c806e733071c5db Author: Anatol Pomozov Date: Fri Oct 17 12:43:34 2014 -0700 ALSA: pcm: use the same dma mmap codepath both for arm and arm64 commit a011e213f3700233ed2a676f1ef0a74a052d7162 upstream. This avoids following kernel crash when try to playback on arm64 [ 107.497203] [] snd_pcm_mmap_data_fault+0x90/0xd4 [ 107.503405] [] __do_fault+0xb0/0x498 [ 107.508565] [] handle_mm_fault+0x224/0x7b0 [ 107.514246] [] do_page_fault+0x11c/0x310 [ 107.519738] [] do_mem_abort+0x38/0x98 Tested: backported to 3.14 and tried to playback on arm64 machine Signed-off-by: Anatol Pomozov Signed-off-by: Takashi Iwai Signed-off-by: Zefan Li commit 6a16b0d080cd68ffac3f063891612dd9725a6d93 Author: Daniel Borkmann Date: Tue Aug 26 23:16:35 2014 -0400 random: add and use memzero_explicit() for clearing data commit d4c5efdb97773f59a2b711754ca0953f24516739 upstream. zatimend has reported that in his environment (3.16/gcc4.8.3/corei7) memset() calls which clear out sensitive data in extract_{buf,entropy, entropy_user}() in random driver are being optimized away by gcc. Add a helper memzero_explicit() (similarly as explicit_bzero() variants) that can be used in such cases where a variable with sensitive data is being cleared out in the end. Other use cases might also be in crypto code. [ I have put this into lib/string.c though, as it's always built-in and doesn't need any dependencies then. ] Fixes kernel bugzilla: 82041 Reported-by: zatimend@hotmail.co.uk Signed-off-by: Daniel Borkmann Acked-by: Hannes Frederic Sowa Cc: Alexey Dobriyan Signed-off-by: Theodore Ts'o [lizf: Backported to 3.4: - adjust context - another memset() in extract_buf() needs to be converted] Signed-off-by: Zefan Li commit e4425815a8d45e730f3a0bd52b149ab65bbad73b Author: Cesar Eduardo Barros Date: Mon Nov 25 22:00:41 2013 -0200 crypto: more robust crypto_memneq commit fe8c8a126806fea4465c43d62a1f9d273a572bf5 upstream. [Only use the compiler.h portion of this patch, to get the OPTIMIZER_HIDE_VAR() macro, which we need for other -stable patches - gregkh] Disabling compiler optimizations can be fragile, since a new optimization could be added to -O0 or -Os that breaks the assumptions the code is making. Instead of disabling compiler optimizations, use a dummy inline assembly (based on RELOC_HIDE) to block the problematic kinds of optimization, while still allowing other optimizations to be applied to the code. The dummy inline assembly is added after every OR, and has the accumulator variable as its input and output. The compiler is forced to assume that the dummy inline assembly could both depend on the accumulator variable and change the accumulator variable, so it is forced to compute the value correctly before the inline assembly, and cannot assume anything about its value after the inline assembly. This change should be enough to make crypto_memneq work correctly (with data-independent timing) even if it is inlined at its call sites. That can be done later in a followup patch. Compile-tested on x86_64. Signed-off-by: Cesar Eduardo Barros Acked-by: Daniel Borkmann Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit e7ce7b473f9131b3073baa6dae63cd22de1c4d23 Author: Eric Sandeen Date: Sat Oct 11 19:51:17 2014 -0400 ext4: fix reservation overflow in ext4_da_write_begin commit 0ff8947fc5f700172b37cbca811a38eb9cb81e08 upstream. Delalloc write journal reservations only reserve 1 credit, to update the inode if necessary. However, it may happen once in a filesystem's lifetime that a file will cross the 2G threshold, and require the LARGE_FILE feature to be set in the superblock as well, if it was not set already. This overruns the transaction reservation, and can be demonstrated simply on any ext4 filesystem without the LARGE_FILE feature already set: dd if=/dev/zero of=testfile bs=1 seek=2147483646 count=1 \ conv=notrunc of=testfile sync dd if=/dev/zero of=testfile bs=1 seek=2147483647 count=1 \ conv=notrunc of=testfile leads to: EXT4-fs: ext4_do_update_inode:4296: aborting transaction: error 28 in __ext4_handle_dirty_super EXT4-fs error (device loop0) in ext4_do_update_inode:4301: error 28 EXT4-fs error (device loop0) in ext4_reserve_inode_write:4757: Readonly filesystem EXT4-fs error (device loop0) in ext4_dirty_inode:4876: error 28 EXT4-fs error (device loop0) in ext4_da_write_end:2685: error 28 Adjust the number of credits based on whether the flag is already set, and whether the current write may extend past the LARGE_FILE limit. Signed-off-by: Eric Sandeen Signed-off-by: Theodore Ts'o Reviewed-by: Andreas Dilger [lizf: Backported to 3.4: - adjust context - ext4_journal_start() has no parameter type] Signed-off-by: Zefan Li commit 07cf4db32b426b6b9d649cac784a4b199001fbd1 Author: Theodore Ts'o Date: Sun Oct 5 22:56:00 2014 -0400 ext4: add ext4_iget_normal() which is to be used for dir tree lookups commit f4bb2981024fc91b23b4d09a8817c415396dbabb upstream. If there is a corrupted file system which has directory entries that point at reserved, metadata inodes, prohibit them from being used by treating them the same way we treat Boot Loader inodes --- that is, mark them to be bad inodes. This prohibits them from being opened, deleted, or modified via chmod, chown, utimes, etc. In particular, this prevents a corrupted file system which has a directory entry which points at the journal inode from being deleted and its blocks released, after which point Much Hilarity Ensues. Reported-by: Sami Liedes Signed-off-by: Theodore Ts'o Signed-off-by: Zefan Li commit 07048f9e15e456be7d216e6f4515c33cafc6fc2b Author: Theodore Ts'o Date: Sun Oct 5 22:47:07 2014 -0400 ext4: don't orphan or truncate the boot loader inode commit e2bfb088fac03c0f621886a04cffc7faa2b49b1d upstream. The boot loader inode (inode #5) should never be visible in the directory hierarchy, but it's possible if the file system is corrupted that there will be a directory entry that points at inode #5. In order to avoid accidentally trashing it, when such a directory inode is opened, the inode will be marked as a bad inode, so that it's not possible to modify (or read) the inode from userspace. Unfortunately, when we unlink this (invalid/illegal) directory entry, we will put the bad inode on the ophan list, and then when try to unlink the directory, we don't actually remove the bad inode from the orphan list before freeing in-memory inode structure. This means the in-memory orphan list is corrupted, leading to a kernel oops. In addition, avoid truncating a bad inode in ext4_destroy_inode(), since truncating the boot loader inode is not a smart thing to do. Reported-by: Sami Liedes Reviewed-by: Jan Kara Signed-off-by: Theodore Ts'o [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 60e7100a311b7b0d4ad87f20d6a13f1f4a4d786d Author: Jan Kara Date: Wed Oct 1 21:49:18 2014 -0400 vfs: fix data corruption when blocksize < pagesize for mmaped data commit 90a8020278c1598fafd071736a0846b38510309c upstream. ->page_mkwrite() is used by filesystems to allocate blocks under a page which is becoming writeably mmapped in some process' address space. This allows a filesystem to return a page fault if there is not enough space available, user exceeds quota or similar problem happens, rather than silently discarding data later when writepage is called. However VFS fails to call ->page_mkwrite() in all the cases where filesystems need it when blocksize < pagesize. For example when blocksize = 1024, pagesize = 4096 the following is problematic: ftruncate(fd, 0); pwrite(fd, buf, 1024, 0); map = mmap(NULL, 1024, PROT_WRITE, MAP_SHARED, fd, 0); map[0] = 'a'; ----> page_mkwrite() for index 0 is called ftruncate(fd, 10000); /* or even pwrite(fd, buf, 1, 10000) */ mremap(map, 1024, 10000, 0); map[4095] = 'a'; ----> no page_mkwrite() called At the moment ->page_mkwrite() is called, filesystem can allocate only one block for the page because i_size == 1024. Otherwise it would create blocks beyond i_size which is generally undesirable. But later at ->writepage() time, we also need to store data at offset 4095 but we don't have block allocated for it. This patch introduces a helper function filesystems can use to have ->page_mkwrite() called at all the necessary moments. Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o [lizf: Backported to 3.4: - adjust context - truncate_setsize() already has an oldsize variable] Signed-off-by: Zefan Li commit e306b0daae1fe8ad4b581dcc2f12917732a5fb1b Author: Quinn Tran Date: Thu Sep 25 06:22:28 2014 -0400 target: Fix queue full status NULL pointer for SCF_TRANSPORT_TASK_SENSE commit 082f58ac4a48d3f5cb4597232cb2ac6823a96f43 upstream. During temporary resource starvation at lower transport layer, command is placed on queue full retry path, which expose this problem. The TCM queue full handling of SCF_TRANSPORT_TASK_SENSE currently sends the same cmd twice to lower layer. The 1st time led to cmd normal free path. The 2nd time cause Null pointer access. This regression bug was originally introduced v3.1-rc code in the following commit: commit e057f53308a5f071556ee80586b99ee755bf07f5 Author: Christoph Hellwig Date: Mon Oct 17 13:56:41 2011 -0400 target: remove the transport_qf_callback se_cmd callback Signed-off-by: Quinn Tran Signed-off-by: Saurav Kashyap Signed-off-by: Nicholas Bellinger Signed-off-by: Zefan Li commit a38c4d8a974e03044f208dfdf09a5a5d55d1dd4d Author: Jan Kara Date: Thu Sep 18 01:12:15 2014 -0400 ext4: don't check quota format when there are no quota files commit 279bf6d390933d5353ab298fcc306c391a961469 upstream. The check whether quota format is set even though there are no quota files with journalled quota is pointless and it actually makes it impossible to turn off journalled quotas (as there's no way to unset journalled quota format). Just remove the check. Signed-off-by: Jan Kara Signed-off-by: Theodore Ts'o Signed-off-by: Zefan Li commit b0fea9c1a057c4e4d30046b26a9309366aaf1ad6 Author: Darrick J. Wong Date: Tue Sep 16 14:34:59 2014 -0400 ext4: check EA value offset when loading commit a0626e75954078cfacddb00a4545dde821170bc5 upstream. When loading extended attributes, check each entry's value offset to make sure it doesn't collide with the entries. Without this check it is easy to crash the kernel by mounting a malicious FS containing a file with an EA wherein e_value_offs = 0 and e_value_size > 0 and then deleting the EA, which corrupts the name list. (See the f_ea_value_crash test's FS image in e2fsprogs for an example.) Signed-off-by: Darrick J. Wong Signed-off-by: Theodore Ts'o [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 4e2c6422ab866ca9ea23714b32be9fbfad77743e Author: Andy Lutomirski Date: Wed Oct 8 09:02:13 2014 -0700 x86,kvm,vmx: Preserve CR4 across VM entry commit d974baa398f34393db76be45f7d4d04fbdbb4a0a upstream. CR4 isn't constant; at least the TSD and PCE bits can vary. TBH, treating CR0 and CR3 as constant scares me a bit, too, but it looks like it's correct. This adds a branch and a read from cr4 to each vm entry. Because it is extremely likely that consecutive entries into the same vcpu will have the same host cr4 value, this fixes up the vmcs instead of restoring cr4 after the fact. A subsequent patch will add a kernel-wide cr4 shadow, reducing the overhead in the common case to just two memory reads and a branch. Signed-off-by: Andy Lutomirski Acked-by: Paolo Bonzini Cc: Petr Matousek Cc: Gleb Natapov Signed-off-by: Linus Torvalds [lizf: Backported to 3.4: - adjust context - add parameter struct vcpu_vmx *vmx to vmx_set_constant_host_state()] Signed-off-by: Zefan Li commit 9e9aab5dbf6f13478cd996692ed9679af2404fc7 Author: Catalin Marinas Date: Fri Oct 17 17:38:49 2014 +0100 futex: Ensure get_futex_key_refs() always implies a barrier commit 76835b0ebf8a7fe85beb03c75121419a7dec52f0 upstream. Commit b0c29f79ecea (futexes: Avoid taking the hb->lock if there's nothing to wake up) changes the futex code to avoid taking a lock when there are no waiters. This code has been subsequently fixed in commit 11d4616bd07f (futex: revert back to the explicit waiter counting code). Both the original commit and the fix-up rely on get_futex_key_refs() to always imply a barrier. However, for private futexes, none of the cases in the switch statement of get_futex_key_refs() would be hit and the function completes without a memory barrier as required before checking the "waiters" in futex_wake() -> hb_waiters_pending(). The consequence is a race with a thread waiting on a futex on another CPU, allowing the waker thread to read "waiters == 0" while the waiter thread to have read "futex_val == locked" (in kernel). Without this fix, the problem (user space deadlocks) can be seen with Android bionic's mutex implementation on an arm64 multi-cluster system. Signed-off-by: Catalin Marinas Reported-by: Matteo Franchin Fixes: b0c29f79ecea (futexes: Avoid taking the hb->lock if there's nothing to wake up) Acked-by: Davidlohr Bueso Tested-by: Mike Galbraith Cc: Darren Hart Cc: Thomas Gleixner Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Paul E. McKenney Signed-off-by: Linus Torvalds Signed-off-by: Zefan Li commit e8ab53a5d68c75722c8a2ad3b08a6798ed47d4dc Author: Stephen Smalley Date: Mon Oct 6 16:32:52 2014 -0400 selinux: fix inode security list corruption commit 923190d32de4428afbea5e5773be86bea60a9925 upstream. sb_finish_set_opts() can race with inode_free_security() when initializing inode security structures for inodes created prior to initial policy load or by the filesystem during ->mount(). This appears to have always been a possible race, but commit 3dc91d4 ("SELinux: Fix possible NULL pointer dereference in selinux_inode_permission()") made it more evident by immediately reusing the unioned list/rcu element of the inode security structure for call_rcu() upon an inode_free_security(). But the underlying issue was already present before that commit as a possible use-after-free of isec. Shivnandan Kumar reported the list corruption and proposed a patch to split the list and rcu elements out of the union as separate fields of the inode_security_struct so that setting the rcu element would not affect the list element. However, this would merely hide the issue and not truly fix the code. This patch instead moves up the deletion of the list entry prior to dropping the sbsec->isec_lock initially. Then, if the inode is dropped subsequently, there will be no further references to the isec. Reported-by: Shivnandan Kumar Signed-off-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Zefan Li commit fb7eb2f7483ea1017d3fed87944a1153bc0879ec Author: Michael S. Tsirkin Date: Tue Oct 14 10:40:29 2014 +1030 virtio_pci: fix virtio spec compliance on restore commit 6fbc198cf623944ab60a1db6d306a4d55cdd820d upstream. On restore, virtio pci does the following: + set features + init vqs etc - device can be used at this point! + set ACKNOWLEDGE,DRIVER and DRIVER_OK status bits This is in violation of the virtio spec, which requires the following order: - ACKNOWLEDGE - DRIVER - init vqs - DRIVER_OK This behaviour will break with hypervisors that assume spec compliant behaviour. It seems like a good idea to have this patch applied to stable branches to reduce the support butden for the hypervisors. Cc: Amit Shah Signed-off-by: Michael S. Tsirkin Signed-off-by: Rusty Russell Signed-off-by: Zefan Li commit 9f7d53c09a1f87ebe228b55a83c1b8f952d76260 Author: Eric W. Biederman Date: Wed Oct 8 10:42:27 2014 -0700 mnt: Prevent pivot_root from creating a loop in the mount tree commit 0d0826019e529f21c84687521d03f60cd241ca7d upstream. Andy Lutomirski recently demonstrated that when chroot is used to set the root path below the path for the new ``root'' passed to pivot_root the pivot_root system call succeeds and leaks mounts. In examining the code I see that starting with a new root that is below the current root in the mount tree will result in a loop in the mount tree after the mounts are detached and then reattached to one another. Resulting in all kinds of ugliness including a leak of that mounts involved in the leak of the mount loop. Prevent this problem by ensuring that the new mount is reachable from the current root of the mount tree. [Added stable cc. Fixes CVE-2014-7970. --Andy] Reported-by: Andy Lutomirski Reviewed-by: Andy Lutomirski Link: http://lkml.kernel.org/r/87bnpmihks.fsf@x220.int.ebiederm.org Signed-off-by: "Eric W. Biederman" Signed-off-by: Andy Lutomirski [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit e65c1a23f47148d534970cbdd6646cf8fba924c3 Author: Takashi Iwai Date: Mon Oct 13 23:18:02 2014 +0200 ALSA: emu10k1: Fix deadlock in synth voice lookup commit 95926035b187cc9fee6fb61385b7da9c28123f74 upstream. The emu10k1 voice allocator takes voice_lock spinlock. When there is no empty stream available, it tries to release a voice used by synth, and calls get_synth_voice. The callback function, snd_emu10k1_synth_get_voice(), however, also takes the voice_lock, thus it deadlocks. The fix is simply removing the voice_lock holds in snd_emu10k1_synth_get_voice(), as this is always called in the spinlock context. Reported-and-tested-by: Arthur Marsh Signed-off-by: Takashi Iwai Signed-off-by: Zefan Li commit bf70aaaa88db72720aee2460157bf7afd20601e4 Author: Sasha Levin Date: Mon Oct 13 15:51:05 2014 -0700 kernel: add support for gcc 5 commit 71458cfc782eafe4b27656e078d379a34e472adf upstream. We're missing include/linux/compiler-gcc5.h which is required now because gcc branched off to v5 in trunk. Just copy the relevant bits out of include/linux/compiler-gcc4.h, no new code is added as of now. This fixes a build error when using gcc 5. Signed-off-by: Sasha Levin Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Zefan Li commit fbc94908bca2603a046fd7745ccffceb0076137a Author: Hans de Goede Date: Sat Oct 11 11:27:37 2014 -0700 Input: i8042 - add noloop quirk for Asus X750LN commit 9ff84a17302aeb8913ff244ecc0d8f9d219fecb5 upstream. Without this the aux port does not get detected, and consequently the touchpad will not work. https://bugzilla.redhat.com/show_bug.cgi?id=1110011 Signed-off-by: Hans de Goede Signed-off-by: Dmitry Torokhov Signed-off-by: Zefan Li commit 8000fbfa741dcfbdfead87f419c5725becc5b62a Author: Dmitry Torokhov Date: Tue Sep 2 09:49:18 2014 -0700 Input: synaptics - gate forcepad support by DMI check commit aa972409951e0675e07918620427517cad5090e0 upstream. Unfortunately, ForcePad capability is not actually exported over PS/2, so we have to resort to DMI checks. Reported-by: Nicole Faerber Signed-off-by: Dmitry Torokhov [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 7baa56f6e80d72ab594b55465b2f42a5e13698c0 Author: Yann Droneaud Date: Thu Oct 9 15:24:40 2014 -0700 fanotify: enable close-on-exec on events' fd when requested in fanotify_init() commit 0b37e097a648aa71d4db1ad108001e95b69a2da4 upstream. According to commit 80af258867648 ("fanotify: groups can specify their f_flags for new fd"), file descriptors created as part of file access notification events inherit flags from the event_f_flags argument passed to syscall fanotify_init(2)[1]. Unfortunately O_CLOEXEC is currently silently ignored. Indeed, event_f_flags are only given to dentry_open(), which only seems to care about O_ACCMODE and O_PATH in do_dentry_open(), O_DIRECT in open_check_o_direct() and O_LARGEFILE in generic_file_open(). It's a pity, since, according to some lookup on various search engines and http://codesearch.debian.net/, there's already some userspace code which use O_CLOEXEC: - in systemd's readahead[2]: fanotify_fd = fanotify_init(FAN_CLOEXEC|FAN_NONBLOCK, O_RDONLY|O_LARGEFILE|O_CLOEXEC|O_NOATIME); - in clsync[3]: #define FANOTIFY_EVFLAGS (O_LARGEFILE|O_RDONLY|O_CLOEXEC) int fanotify_d = fanotify_init(FANOTIFY_FLAGS, FANOTIFY_EVFLAGS); - in examples [4] from "Filesystem monitoring in the Linux kernel" article[5] by Aleksander Morgado: if ((fanotify_fd = fanotify_init (FAN_CLOEXEC, O_RDONLY | O_CLOEXEC | O_LARGEFILE)) < 0) Additionally, since commit 48149e9d3a7e ("fanotify: check file flags passed in fanotify_init"). having O_CLOEXEC as part of fanotify_init() second argument is expressly allowed. So it seems expected to set close-on-exec flag on the file descriptors if userspace is allowed to request it with O_CLOEXEC. But Andrew Morton raised[6] the concern that enabling now close-on-exec might break existing applications which ask for O_CLOEXEC but expect the file descriptor to be inherited across exec(). In the other hand, as reported by Mihai Dontu[7] close-on-exec on the file descriptor returned as part of file access notify can break applications due to deadlock. So close-on-exec is needed for most applications. More, applications asking for close-on-exec are likely expecting it to be enabled, relying on O_CLOEXEC being effective. If not, it might weaken their security, as noted by Jan Kara[8]. So this patch replaces call to macro get_unused_fd() by a call to function get_unused_fd_flags() with event_f_flags value as argument. This way O_CLOEXEC flag in the second argument of fanotify_init(2) syscall is interpreted and close-on-exec get enabled when requested. [1] http://man7.org/linux/man-pages/man2/fanotify_init.2.html [2] http://cgit.freedesktop.org/systemd/systemd/tree/src/readahead/readahead-collect.c?id=v208#n294 [3] https://github.com/xaionaro/clsync/blob/v0.2.1/sync.c#L1631 https://github.com/xaionaro/clsync/blob/v0.2.1/configuration.h#L38 [4] http://www.lanedo.com/~aleksander/fanotify/fanotify-example.c [5] http://www.lanedo.com/2013/filesystem-monitoring-linux-kernel/ [6] http://lkml.kernel.org/r/20141001153621.65e9258e65a6167bf2e4cb50@linux-foundation.org [7] http://lkml.kernel.org/r/20141002095046.3715eb69@mdontu-l [8] http://lkml.kernel.org/r/20141002104410.GB19748@quack.suse.cz Link: http://lkml.kernel.org/r/cover.1411562410.git.ydroneaud@opteya.com Signed-off-by: Yann Droneaud Reviewed-by: Jan Kara Reviewed by: Heinrich Schuchardt Tested-by: Heinrich Schuchardt Cc: Mihai Don\u021bu Cc: Pádraig Brady Cc: Heinrich Schuchardt Cc: Jan Kara Cc: Valdis Kletnieks Cc: Michael Kerrisk-manpages Cc: Lino Sanfilippo Cc: Richard Guy Briggs Cc: Eric Paris Cc: Al Viro Cc: Michael Kerrisk Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Zefan Li commit c76a73b3d03e08074d08a7cbf1acb386a022a367 Author: Mike Snitzer Date: Wed Oct 8 18:26:13 2014 -0400 block: fix alignment_offset math that assumes io_min is a power-of-2 commit b8839b8c55f3fdd60dc36abcda7e0266aff7985c upstream. The math in both blk_stack_limits() and queue_limit_alignment_offset() assume that a block device's io_min (aka minimum_io_size) is always a power-of-2. Fix the math such that it works for non-power-of-2 io_min. This issue (of alignment_offset != 0) became apparent when testing dm-thinp with a thinp blocksize that matches a RAID6 stripesize of 1280K. Commit fdfb4c8c1 ("dm thin: set minimum_io_size to pool's data block size") unlocked the potential for alignment_offset != 0 due to the dm-thin-pool's io_min possibly being a non-power-of-2. Signed-off-by: Mike Snitzer Acked-by: Martin K. Petersen Signed-off-by: Jens Axboe Signed-off-by: Zefan Li commit 15c0af9cd63cf84fc7f527da7d12b80e096b60d2 Author: Al Viro Date: Wed Oct 8 23:44:00 2014 -0400 fix misuses of f_count() in ppp and netlink commit 24dff96a37a2ca319e75a74d3929b2de22447ca6 upstream. we used to check for "nobody else could start doing anything with that opened file" by checking that refcount was 2 or less - one for descriptor table and one we'd acquired in fget() on the way to wherever we are. That was race-prone (somebody else might have had a reference to descriptor table and do fget() just as we'd been checking) and it had become flat-out incorrect back when we switched to fget_light() on those codepaths - unlike fget(), it doesn't grab an extra reference unless the descriptor table is shared. The same change allowed a race-free check, though - we are safe exactly when refcount is less than 2. It was a long time ago; pre-2.6.12 for ioctl() (the codepath leading to ppp one) and 2.6.17 for sendmsg() (netlink one). OTOH, netlink hadn't grown that check until 3.9 and ppp used to live in drivers/net, not drivers/net/ppp until 3.1. The bug existed well before that, though, and the same fix used to apply in old location of file. Signed-off-by: Al Viro [lizf: Backported to 3.4: drop the change to netlink_mmap_sendmsg()] Signed-off-by: Zefan Li commit 2551b5ed84a7cfe5e414544bb9ad95ebf43b3ff3 Author: Mikulas Patocka Date: Sun Jul 27 13:00:41 2014 -0400 fs: make cont_expand_zero interruptible commit c2ca0fcd202863b14bd041a7fece2e789926c225 upstream. This patch makes it possible to kill a process looping in cont_expand_zero. A process may spend a lot of time in this function, so it is desirable to be able to kill it. It happened to me that I wanted to copy a piece data from the disk to a file. By mistake, I used the "seek" parameter to dd instead of "skip". Due to the "seek" parameter, dd attempted to extend the file and became stuck doing so - the only possibility was to reset the machine or wait many hours until the filesystem runs out of space and cont_expand_zero fails. We need this patch to be able to terminate the process. Signed-off-by: Mikulas Patocka Signed-off-by: Al Viro Signed-off-by: Zefan Li commit 2ea17e6740ac0e15f86854973dbd22100579bbf8 Author: Tetsuo Handa Date: Sat May 17 20:56:38 2014 +0900 fs: Fix theoretical division by 0 in super_cache_scan(). commit 475d0db742e3755c6b267f48577ff7cbb7dfda0d upstream. total_objects could be 0 and is used as a denom. While total_objects is a "long", total_objects == 0 unlikely happens for 3.12 and later kernels because 32-bit architectures would not be able to hold (1 << 32) objects. However, total_objects == 0 may happen for kernels between 3.1 and 3.11 because total_objects in prune_super() was an "int" and (e.g.) x86_64 architecture might be able to hold (1 << 32) objects. Signed-off-by: Tetsuo Handa Reviewed-by: Christoph Hellwig Signed-off-by: Al Viro [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit db55550da4a9ca71d76f47286a5a9790f12a2868 Author: Ben Hutchings Date: Sun Sep 7 21:05:05 2014 +0100 x86: Reject x32 executables if x32 ABI not supported commit 0e6d3112a4e95d55cf6dca88f298d5f4b8f29bd1 upstream. It is currently possible to execve() an x32 executable on an x86_64 kernel that has only ia32 compat enabled. However all its syscalls will fail, even _exit(). This usually causes it to segfault. Change the ELF compat architecture check so that x32 executables are rejected if we don't support the x32 ABI. Signed-off-by: Ben Hutchings Link: http://lkml.kernel.org/r/1410120305.6822.9.camel@decadent.org.uk Signed-off-by: Thomas Gleixner Signed-off-by: Zefan Li commit 9be2cb104b9a741878720a41911b7c4739dde12b Author: Scott Carter Date: Wed Sep 24 18:13:09 2014 -0700 pata_serverworks: disable 64-KB DMA transfers on Broadcom OSB4 IDE Controller commit 37017ac6849e772e67dd187ba2fbd056c4afa533 upstream. The Broadcom OSB4 IDE Controller (vendor and device IDs: 1166:0211) does not support 64-KB DMA transfers. Whenever a 64-KB DMA transfer is attempted, the transfer fails and messages similar to the following are written to the console log: [ 2431.851125] sr 0:0:0:0: [sr0] Unhandled sense code [ 2431.851139] sr 0:0:0:0: [sr0] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [ 2431.851152] sr 0:0:0:0: [sr0] Sense Key : Hardware Error [current] [ 2431.851166] sr 0:0:0:0: [sr0] Add. Sense: Logical unit communication time-out [ 2431.851182] sr 0:0:0:0: [sr0] CDB: Read(10): 28 00 00 00 76 f4 00 00 40 00 [ 2431.851210] end_request: I/O error, dev sr0, sector 121808 When the libata and pata_serverworks modules are recompiled with ATA_DEBUG and ATA_VERBOSE_DEBUG defined in libata.h, the 64-KB transfer size in the scatter-gather list can be seen in the console log: [ 2664.897267] sr 9:0:0:0: [sr0] Send: [ 2664.897274] 0xf63d85e0 [ 2664.897283] sr 9:0:0:0: [sr0] CDB: [ 2664.897288] Read(10): 28 00 00 00 7f b4 00 00 40 00 [ 2664.897319] buffer = 0xf6d6fbc0, bufflen = 131072, queuecommand 0xf81b7700 [ 2664.897331] ata_scsi_dump_cdb: CDB (1:0,0,0) 28 00 00 00 7f b4 00 00 40 [ 2664.897338] ata_scsi_translate: ENTER [ 2664.897345] ata_sg_setup: ENTER, ata1 [ 2664.897356] ata_sg_setup: 3 sg elements mapped [ 2664.897364] ata_bmdma_fill_sg: PRD[0] = (0x66FD2000, 0xE000) [ 2664.897371] ata_bmdma_fill_sg: PRD[1] = (0x65000000, 0x10000) ------------------------------------------------------> ======= [ 2664.897378] ata_bmdma_fill_sg: PRD[2] = (0x66A10000, 0x2000) [ 2664.897386] ata1: ata_dev_select: ENTER, device 0, wait 1 [ 2664.897422] ata_sff_tf_load: feat 0x1 nsect 0x0 lba 0x0 0x0 0xFC [ 2664.897428] ata_sff_tf_load: device 0xA0 [ 2664.897448] ata_sff_exec_command: ata1: cmd 0xA0 [ 2664.897457] ata_scsi_translate: EXIT [ 2664.897462] leaving scsi_dispatch_cmnd() [ 2664.897497] Doing sr request, dev = sr0, block = 0 [ 2664.897507] sr0 : reading 64/256 512 byte blocks. [ 2664.897553] ata_sff_hsm_move: ata1: protocol 7 task_state 1 (dev_stat 0x58) [ 2664.897560] atapi_send_cdb: send cdb [ 2666.910058] ata_bmdma_port_intr: ata1: host_stat 0x64 [ 2666.910079] __ata_sff_port_intr: ata1: protocol 7 task_state 3 [ 2666.910093] ata_sff_hsm_move: ata1: protocol 7 task_state 3 (dev_stat 0x51) [ 2666.910101] ata_sff_hsm_move: ata1: protocol 7 task_state 4 (dev_stat 0x51) [ 2666.910129] sr 9:0:0:0: [sr0] Done: [ 2666.910136] 0xf63d85e0 TIMEOUT lspci shows that the driver used for the Broadcom OSB4 IDE Controller is pata_serverworks: 00:0f.1 IDE interface: Broadcom OSB4 IDE Controller (prog-if 8e [Master SecP SecO PriP]) Flags: bus master, medium devsel, latency 64 [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [size=8] [virtual] Memory at 000003f0 (type 3, non-prefetchable) [size=1] I/O ports at 0170 [size=8] I/O ports at 0374 [size=4] I/O ports at 1440 [size=16] Kernel driver in use: pata_serverworks The pata_serverworks driver supports five distinct device IDs, one being the OSB4 and the other four belonging to the CSB series. The CSB series appears to support 64-KB DMA transfers, as tests on a machine with an SAI2 motherboard containing a Broadcom CSB5 IDE Controller (vendor and device IDs: 1166:0212) showed no problems with 64-KB DMA transfers. This problem was first discovered when attempting to install openSUSE from a DVD on a machine with an STL2 motherboard. Using the pata_serverworks module, older releases of openSUSE will not install at all due to the timeouts. Releases of openSUSE prior to 11.3 can be installed by disabling the pata_serverworks module using the brokenmodules boot parameter, which causes the serverworks module to be used instead. Recent releases of openSUSE (12.2 and later) include better error recovery and will install, though very slowly. On all openSUSE releases, the problem can be recreated on a machine containing a Broadcom OSB4 IDE Controller by mounting an install DVD and running a command similar to the following: find /mnt -type f -print | xargs cat > /dev/null The patch below corrects the problem. Similar to the other ATA drivers that do not support 64-KB DMA transfers, the patch changes the ata_port_operations qc_prep vector to point to a routine that breaks any 64-KB segment into two 32-KB segments and changes the scsi_host_template sg_tablesize element to reduce by half the number of scatter/gather elements allowed. These two changes affect only the OSB4. Signed-off-by: Scott Carter Signed-off-by: Tejun Heo Signed-off-by: Zefan Li commit 771f8a87c7e09184a411702313917e2a6db0359e Author: Chao Yu Date: Thu Jul 24 17:25:42 2014 +0800 ecryptfs: avoid to access NULL pointer when write metadata in xattr commit 35425ea2492175fd39f6116481fe98b2b3ddd4ca upstream. Christopher Head 2014-06-28 05:26:20 UTC described: "I tried to reproduce this on 3.12.21. Instead, when I do "echo hello > foo" in an ecryptfs mount with ecryptfs_xattr specified, I get a kernel crash: BUG: unable to handle kernel NULL pointer dereference at (null) IP: [] fsstack_copy_attr_all+0x2/0x61 PGD d7840067 PUD b2c3c067 PMD 0 Oops: 0002 [#1] SMP Modules linked in: nvidia(PO) CPU: 3 PID: 3566 Comm: bash Tainted: P O 3.12.21-gentoo-r1 #2 Hardware name: ASUSTek Computer Inc. G60JX/G60JX, BIOS 206 03/15/2010 task: ffff8801948944c0 ti: ffff8800bad70000 task.ti: ffff8800bad70000 RIP: 0010:[] [] fsstack_copy_attr_all+0x2/0x61 RSP: 0018:ffff8800bad71c10 EFLAGS: 00010246 RAX: 00000000000181a4 RBX: ffff880198648480 RCX: 0000000000000000 RDX: 0000000000000004 RSI: ffff880172010450 RDI: 0000000000000000 RBP: ffff880198490e40 R08: 0000000000000000 R09: 0000000000000000 R10: ffff880172010450 R11: ffffea0002c51e80 R12: 0000000000002000 R13: 000000000000001a R14: 0000000000000000 R15: ffff880198490e40 FS: 00007ff224caa700(0000) GS:ffff88019fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 00000000bb07f000 CR4: 00000000000007e0 Stack: ffffffff811826e8 ffff8800a39d8000 0000000000000000 000000000000001a ffff8800a01d0000 ffff8800a39d8000 ffffffff81185fd5 ffffffff81082c2c 00000001a39d8000 53d0abbc98490e40 0000000000000037 ffff8800a39d8220 Call Trace: [] ? ecryptfs_setxattr+0x40/0x52 [] ? ecryptfs_write_metadata+0x1b3/0x223 [] ? should_resched+0x5/0x23 [] ? ecryptfs_initialize_file+0xaf/0xd4 [] ? ecryptfs_create+0xf4/0x142 [] ? vfs_create+0x48/0x71 [] ? do_last.isra.68+0x559/0x952 [] ? link_path_walk+0xbd/0x458 [] ? path_openat+0x224/0x472 [] ? do_filp_open+0x2b/0x6f [] ? __alloc_fd+0xd6/0xe7 [] ? do_sys_open+0x65/0xe9 [] ? system_call_fastpath+0x16/0x1b RIP [] fsstack_copy_attr_all+0x2/0x61 RSP CR2: 0000000000000000 ---[ end trace df9dba5f1ddb8565 ]---" If we create a file when we mount with ecryptfs_xattr_metadata option, we will encounter a crash in this path: ->ecryptfs_create ->ecryptfs_initialize_file ->ecryptfs_write_metadata ->ecryptfs_write_metadata_to_xattr ->ecryptfs_setxattr ->fsstack_copy_attr_all It's because our dentry->d_inode used in fsstack_copy_attr_all is NULL, and it will be initialized when ecryptfs_initialize_file finish. So we should skip copying attr from lower inode when the value of ->d_inode is invalid. Signed-off-by: Chao Yu Signed-off-by: Tyler Hicks Signed-off-by: Zefan Li commit dbd43539a8faff93490475bccbf9e4d0b7ebc2cb Author: Alexey Khoroshilov Date: Wed Oct 1 22:58:35 2014 +0200 dm log userspace: fix memory leak in dm_ulog_tfr_init failure path commit 56ec16cb1e1ce46354de8511eef962a417c32c92 upstream. If cn_add_callback() fails in dm_ulog_tfr_init(), it does not deallocate prealloced memory but calls cn_del_callback(). Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by: Alexey Khoroshilov Reviewed-by: Jonathan Brassow Signed-off-by: Mike Snitzer Signed-off-by: Zefan Li commit adcbd2e571ae7b295c25065b55af6550659bd483 Author: Joe Thornber Date: Tue Sep 30 09:32:46 2014 +0100 dm bufio: update last_accessed when relinking a buffer commit eb76faf53b1ff7a77ce3f78cc98ad392ac70c2a0 upstream. The 'last_accessed' member of the dm_buffer structure was only set when the the buffer was created. This led to each buffer being discarded after dm_bufio_max_age time even if it was used recently. In practice this resulted in all thinp metadata being evicted soon after being read -- this is particularly problematic for metadata intensive workloads like multithreaded small random IO. 'last_accessed' is now updated each time the buffer is moved to the head of the LRU list, so the buffer is now properly discarded if it was not used in dm_bufio_max_age time. Signed-off-by: Joe Thornber Signed-off-by: Mikulas Patocka Signed-off-by: Mike Snitzer [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 82556daff1b0ab58610d94188eed14dacf427bdc Author: Geert Uytterhoeven Date: Sun Sep 28 10:50:06 2014 +0200 m68k: Disable/restore interrupts in hwreg_present()/hwreg_write() commit e4dc601bf99ccd1c95b7e6eef1d3cf3c4b0d4961 upstream. hwreg_present() and hwreg_write() temporarily change the VBR register to another vector table. This table contains a valid bus error handler only, all other entries point to arbitrary addresses. If an interrupt comes in while the temporary table is active, the processor will start executing at such an arbitrary address, and the kernel will crash. While most callers run early, before interrupts are enabled, or explicitly disable interrupts, Finn Thain pointed out that macsonic has one callsite that doesn't, causing intermittent boot crashes. There's another unsafe callsite in hilkbd. Fix this for good by disabling and restoring interrupts inside hwreg_present() and hwreg_write(). Explicitly disabling interrupts can be removed from the callsites later. Reported-by: Finn Thain Signed-off-by: Geert Uytterhoeven Signed-off-by: Zefan Li commit 2c9d556d14bc8d18cfa6635d1d5e751508dc7ec8 Author: Andy Adamson Date: Mon Sep 29 12:31:57 2014 -0400 NFSv4.1: Fix an NFSv4.1 state renewal regression commit d1f456b0b9545f1606a54cd17c20775f159bd2ce upstream. Commit 2f60ea6b8ced ("NFSv4: The NFSv4.0 client must send RENEW calls if it holds a delegation") set the NFS4_RENEW_TIMEOUT flag in nfs4_renew_state, and does not put an nfs41_proc_async_sequence call, the NFSv4.1 lease renewal heartbeat call, on the wire to renew the NFSv4.1 state if the flag was not set. The NFS4_RENEW_TIMEOUT flag is set when "now" is after the last renewal (cl_last_renewal) plus the lease time divided by 3. This is arbitrary and sometimes does the following: In normal operation, the only way a future state renewal call is put on the wire is via a call to nfs4_schedule_state_renewal, which schedules a nfs4_renew_state workqueue task. nfs4_renew_state determines if the NFS4_RENEW_TIMEOUT should be set, and the calls nfs41_proc_async_sequence, which only gets sent if the NFS4_RENEW_TIMEOUT flag is set. Then the nfs41_proc_async_sequence rpc_release function schedules another state remewal via nfs4_schedule_state_renewal. Without this change we can get into a state where an application stops accessing the NFSv4.1 share, state renewal calls stop due to the NFS4_RENEW_TIMEOUT flag _not_ being set. The only way to recover from this situation is with a clientid re-establishment, once the application resumes and the server has timed out the lease and so returns NFS4ERR_BAD_SESSION on the subsequent SEQUENCE operation. An example application: open, lock, write a file. sleep for 6 * lease (could be less) ulock, close. In the above example with NFSv4.1 delegations enabled, without this change, there are no OP_SEQUENCE state renewal calls during the sleep, and the clientid is recovered due to lease expiration on the close. This issue does not occur with NFSv4.1 delegations disabled, nor with NFSv4.0, with or without delegations enabled. Signed-off-by: Andy Adamson Link: http://lkml.kernel.org/r/1411486536-23401-1-git-send-email-andros@netapp.com Fixes: 2f60ea6b8ced (NFSv4: The NFSv4.0 client must send RENEW calls...) Signed-off-by: Trond Myklebust [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit f4c4b923165f5c6342898a3428b1997dbc54f8f1 Author: Borislav Petkov Date: Tue Sep 30 12:55:41 2014 +0200 mpc85xx_edac: Make L2 interrupt shared too commit a18c3f16a907b8977ef65fc8dd71ed3f7b751748 upstream. The other two interrupt handlers in this driver are shared, except this one. When loading the driver, it fails like this. So make the IRQ line shared. Freescale(R) MPC85xx EDAC driver, (C) 2006 Montavista Software mpc85xx_mc_err_probe: No ECC DIMMs discovered EDAC DEVICE0: Giving out device to module MPC85xx_edac controller mpc85xx_l2_err: DEV mpc85xx_l2_err (INTERRUPT) genirq: Flags mismatch irq 16. 00000000 ([EDAC] L2 err) vs. 00000080 ([EDAC] PCI err) mpc85xx_l2_err_probe: Unable to request irq 16 for MPC85xx L2 err remove_proc_entry: removing non-empty directory 'irq/16', leaking at least 'aerdrv' ------------[ cut here ]------------ WARNING: at fs/proc/generic.c:521 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc5-dirty #1 task: ee058000 ti: ee046000 task.ti: ee046000 NIP: c016c0c4 LR: c016c0c4 CTR: c037b51c REGS: ee047c10 TRAP: 0700 Not tainted (3.17.0-rc5-dirty) MSR: 00029000 CR: 22008022 XER: 20000000 GPR00: c016c0c4 ee047cc0 ee058000 00000053 00029000 00000000 c037c744 00000003 GPR08: c09aab28 c09aab24 c09aab28 00000156 20008028 00000000 c0002ac8 00000000 GPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000139 c0950394 GPR24: c09f0000 ee5585b0 ee047d08 c0a10000 ee047d08 ee15f808 00000002 ee03f660 NIP [c016c0c4] remove_proc_entry LR [c016c0c4] remove_proc_entry Call Trace: remove_proc_entry (unreliable) unregister_irq_proc free_desc irq_free_descs mpc85xx_l2_err_probe platform_drv_probe really_probe __driver_attach bus_for_each_dev bus_add_driver driver_register mpc85xx_mc_init do_one_initcall kernel_init_freeable kernel_init ret_from_kernel_thread Instruction dump: ... Reported-and-tested-by: Acked-by: Johannes Thumshirn Signed-off-by: Borislav Petkov [lizf: Backported to 3.4: IRQF_DISABLED hasn't been removed in 3.4] Signed-off-by: Zefan Li commit ab766b86a074e8a2a600a106418b240497d2d6aa Author: Mikulas Patocka Date: Tue Sep 16 12:40:26 2014 -0400 framebuffer: fix border color commit f74a289b9480648a654e5afd8458c2263c03a1e1 upstream. The framebuffer code uses the current background color to fill the border when switching consoles, however, this results in inconsistent behavior. For example: - start Midnigh Commander - the border is black - switch to another console and switch back - the border is cyan - type something into the command line in mc - the border is cyan - switch to another console and switch back - the border is black - press F9 to go to menu - the border is black - switch to another console and switch back - the border is dark blue When switching to a console with Midnight Commander, the border is random color that was left selected by the slang subsystem. This patch fixes this inconsistency by always using black as the background color when switching consoles. Signed-off-by: Mikulas Patocka Signed-off-by: Tomi Valkeinen Signed-off-by: Zefan Li commit a06f6a5d229bbf9fcb0f39a9dbee56dda06f363a Author: Bryan O'Donoghue Date: Tue Sep 23 01:21:11 2014 +0100 serial: 8250: Add Quark X1000 to 8250_pci.c commit 1ede7dcca3c4fa15a518ab0473126f9c3e621e4c upstream. Quark X1000 contains two designware derived 8250 serial ports. Each port has a unique PCI configuration space consisting of BAR0:UART BAR1:DMA respectively. Unlike the standard 8250 the register width is 32 bits for RHR,IER etc The Quark UART has a fundamental clock @ 44.2368 MHz allowing for a bitrate of up to about 2.76 megabits per second. This patch enables standard 8250 mode Signed-off-by: Bryan O'Donoghue Reviewed-by: Heikki Krogerus Signed-off-by: Greg Kroah-Hartman [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 5a0b8b70d79afe7d77d3737fb6012abcf4157cf2 Author: Trond Myklebust Date: Sat Sep 27 17:41:51 2014 -0400 NFSv4: fix open/lock state recovery error handling commit df817ba35736db2d62b07de6f050a4db53492ad8 upstream. The current open/lock state recovery unfortunately does not handle errors such as NFS4ERR_CONN_NOT_BOUND_TO_SESSION correctly. Instead of looping, just proceeds as if the state manager is finished recovering. This patch ensures that we loop back, handle higher priority errors and complete the open/lock state recovery. Signed-off-by: Trond Myklebust Signed-off-by: Zefan Li commit 39aca9c1368c298189f95a77e789bc7f42ff80fc Author: Ondrej Zary Date: Sat Sep 27 00:04:46 2014 +0200 libata-sff: Fix controllers with no ctl port commit 6d8ca28fa688a9354bc9fbc935bdaeb3651b6677 upstream. Currently, ata_sff_softreset is skipped for controllers with no ctl port. But that also skips ata_sff_dev_classify required for device detection. This means that libata is currently broken on controllers with no ctl port. No device connected: [ 1.872480] pata_isapnp 01:01.02: activated [ 1.889823] scsi2 : pata_isapnp [ 1.890109] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11 [ 6.888110] ata3.01: qc timeout (cmd 0xec) [ 6.888179] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5) [ 16.888085] ata3.01: qc timeout (cmd 0xec) [ 16.888147] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5) [ 46.888086] ata3.01: qc timeout (cmd 0xec) [ 46.888148] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5) [ 51.888100] ata3.00: qc timeout (cmd 0xec) [ 51.888160] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5) [ 61.888079] ata3.00: qc timeout (cmd 0xec) [ 61.888141] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5) [ 91.888089] ata3.00: qc timeout (cmd 0xec) [ 91.888152] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x5) ATAPI device connected: [ 1.882061] pata_isapnp 01:01.02: activated [ 1.893430] scsi2 : pata_isapnp [ 1.893719] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11 [ 6.892107] ata3.01: qc timeout (cmd 0xec) [ 6.892171] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5) [ 16.892079] ata3.01: qc timeout (cmd 0xec) [ 16.892138] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5) [ 46.892079] ata3.01: qc timeout (cmd 0xec) [ 46.892138] ata3.01: failed to IDENTIFY (I/O error, err_mask=0x5) [ 46.908586] ata3.00: ATAPI: ACER CD-767E/O, V1.5X, max PIO2, CDB intr [ 46.924570] ata3.00: configured for PIO0 (device error ignored) [ 46.926295] scsi 2:0:0:0: CD-ROM ACER CD-767E/O 1.5X PQ: 0 ANSI: 5 [ 46.984519] sr0: scsi3-mmc drive: 6x/6x xa/form2 tray [ 46.984592] cdrom: Uniform CD-ROM driver Revision: 3.20 So don't skip ata_sff_softreset, just skip the reset part of ata_bus_softreset if the ctl port is not available. This makes IDE port on ES968 behave correctly: No device connected: [ 4.670888] pata_isapnp 01:01.02: activated [ 4.673207] scsi host2: pata_isapnp [ 4.673675] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11 [ 7.081840] Adding 2541652k swap on /dev/sda2. Priority:-1 extents:1 across:2541652k ATAPI device connected: [ 4.704362] pata_isapnp 01:01.02: activated [ 4.706620] scsi host2: pata_isapnp [ 4.706877] ata3: PATA max PIO0 cmd 0x1e8 ctl 0x0 irq 11 [ 4.872782] ata3.00: ATAPI: ACER CD-767E/O, V1.5X, max PIO2, CDB intr [ 4.888673] ata3.00: configured for PIO0 (device error ignored) [ 4.893984] scsi 2:0:0:0: CD-ROM ACER CD-767E/O 1.5X PQ: 0 ANSI: 5 [ 7.015578] Adding 2541652k swap on /dev/sda2. Priority:-1 extents:1 across:2541652k Signed-off-by: Ondrej Zary Signed-off-by: Tejun Heo Signed-off-by: Zefan Li commit 65b412cc6708ed1c5ce325a790a31f12f80ef6ba Author: Xiubo Li Date: Sun Sep 28 17:09:54 2014 +0800 regmap: fix possible ZERO_SIZE_PTR pointer dereferencing error. commit d6b41cb06044a7d895db82bdd54f6e4219970510 upstream. Since we cannot make sure the 'val_count' will always be none zero here, and then if it equals to zero, the kmemdup() will return ZERO_SIZE_PTR, which equals to ((void *)16). So this patch fix this with just doing the zero check before calling kmemdup(). Signed-off-by: Xiubo Li Signed-off-by: Mark Brown [lizf: Backported to 3.4: release mutex before returning EINVAL] Signed-off-by: Zefan Li commit a3f3ff3879234e3dc92f4a5b3e08500b0e483b2e Author: Xiubo Li Date: Sun Sep 28 11:35:25 2014 +0800 regmap: debugfs: fix possbile NULL pointer dereference commit 2c98e0c1cc6b8e86f1978286c3d4e0769ee9d733 upstream. If 'map->dev' is NULL and there will lead dev_name() to be NULL pointer dereference. So before dev_name(), we need to have check of the map->dev pionter. We also should make sure that the 'name' pointer shouldn't be NULL for debugfs_create_dir(). So here using one default "dummy" debugfs name when the 'name' pointer and 'map->dev' are both NULL. Signed-off-by: Xiubo Li Signed-off-by: Mark Brown [lizf: Backported to 3.4: dev_name() is passed to debugfs_create_dir() in 3.4] Signed-off-by: Zefan Li commit d3c4aba01df7fa991576387660e3fb7dd27431fa Author: Willy Tarreau Date: Sat Sep 27 12:31:37 2014 +0200 lzo: check for length overrun in variable length encoding. commit 72cf90124e87d975d0b2114d930808c58b4c05e4 upstream. This fix ensures that we never meet an integer overflow while adding 255 while parsing a variable length encoding. It works differently from commit 206a81c ("lzo: properly check for overruns") because instead of ensuring that we don't overrun the input, which is tricky to guarantee due to many assumptions in the code, it simply checks that the cumulated number of 255 read cannot overflow by bounding this number. The MAX_255_COUNT is the maximum number of times we can add 255 to a base count without overflowing an integer. The multiply will overflow when multiplying 255 by more than MAXINT/255. The sum will overflow earlier depending on the base count. Since the base count is taken from a u8 and a few bits, it is safe to assume that it will always be lower than or equal to 2*255, thus we can always prevent any overflow by accepting two less 255 steps. This patch also reduces the CPU overhead and actually increases performance by 1.1% compared to the initial code, while the previous fix costs 3.1% (measured on x86_64). The fix needs to be backported to all currently supported stable kernels. Reported-by: Willem Pinckaers Cc: "Don A. Bailey" Signed-off-by: Willy Tarreau Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 1cb3f30f67c36e6a6a17dc04d7b8d6a8429c94f9 Author: Willy Tarreau Date: Sat Sep 27 12:31:36 2014 +0200 Revert "lzo: properly check for overruns" commit af958a38a60c7ca3d8a39c918c1baa2ff7b6b233 upstream. This reverts commit 206a81c ("lzo: properly check for overruns"). As analysed by Willem Pinckaers, this fix is still incomplete on certain rare corner cases, and it is easier to restart from the original code. Reported-by: Willem Pinckaers Cc: "Don A. Bailey" Signed-off-by: Willy Tarreau Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit c6d401effc132d21fb69faa6e1c04428434c375c Author: Willy Tarreau Date: Sat Sep 27 12:31:35 2014 +0200 Documentation: lzo: document part of the encoding commit d98a0526434d27e261f622cf9d2e0028b5ff1a00 upstream. Add a complete description of the LZO format as processed by the decompressor. I have not found a public specification of this format hence this analysis, which will be used to better understand the code. Cc: Willem Pinckaers Cc: "Don A. Bailey" Signed-off-by: Willy Tarreau Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit bbb7a273be2cd8ea01fdb8c542c120ab2ffef6ad Author: Stanislaw Gruszka Date: Wed Sep 24 11:24:54 2014 +0200 rt2800: correct BBP1_TX_POWER_CTRL mask commit 01f7feeaf4528bec83798316b3c811701bac5d3e upstream. Two bits control TX power on BBP_R1 register. Correct the mask, otherwise we clear additional bit on BBP_R1 register, what can have unknown, possible negative effect. Signed-off-by: Stanislaw Gruszka Signed-off-by: John W. Linville Signed-off-by: Zefan Li commit 9fa2377fcc46960755f826a2d343b444c6dd5c40 Author: Krzysztof Kozlowski Date: Fri Sep 26 13:27:03 2014 +0200 power: charger-manager: Fix NULL pointer exception with missing cm-fuel-gauge commit 661a88860274e059fdb744dfaa98c045db7b5d1d upstream. NULL pointer exception happens during charger-manager probe if 'cm-fuel-gauge' property is not present. [ 2.448536] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 2.456572] pgd = c0004000 [ 2.459217] [00000000] *pgd=00000000 [ 2.462759] Internal error: Oops: 5 [#1] PREEMPT SMP ARM [ 2.468047] Modules linked in: [ 2.471089] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.17.0-rc6-00251-ge44cf96cd525-dirty #969 [ 2.479765] task: ea890000 ti: ea87a000 task.ti: ea87a000 [ 2.485161] PC is at strcmp+0x4/0x30 [ 2.488719] LR is at power_supply_match_device_by_name+0x10/0x1c [ 2.494695] pc : [] lr : [] psr: a0000113 [ 2.494695] sp : ea87bde0 ip : 00000000 fp : eaa97010 [ 2.506150] r10: 00000004 r9 : ea97269c r8 : ea3bbfd0 [ 2.511360] r7 : eaa97000 r6 : c030fe28 r5 : 00000000 r4 : ea3b0000 [ 2.517869] r3 : 0000006d r2 : 00000000 r1 : 00000000 r0 : c057c195 [ 2.524381] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 2.531671] Control: 10c5387d Table: 4000404a DAC: 00000015 [ 2.537399] Process swapper/0 (pid: 1, stack limit = 0xea87a240) [ 2.543388] Stack: (0xea87bde0 to 0xea87c000) [ 2.547733] bde0: ea3b0210 c026b1c8 eaa97010 eaa97000 eaa97010 eabb60a8 ea3b0210 00000000 [ 2.555891] be00: 00000008 ea2db210 ea1a3410 c030fee0 ea3bbf90 c03138fc c068969c c013526c [ 2.564050] be20: eaa040c0 00000000 c068969c 00000000 eaa040c0 ea2da300 00000002 00000000 [ 2.572208] be40: 00000001 ea2da3c0 00000000 00000001 00000000 eaa97010 c068969c 00000000 [ 2.580367] be60: 00000000 c068969c 00000000 00000002 00000000 c026b71c c026b6f0 eaa97010 [ 2.588527] be80: c0e82530 c026a330 00000000 eaa97010 c068969c eaa97044 00000000 c061df50 [ 2.596686] bea0: ea87a000 c026a4dc 00000000 c068969c c026a448 c0268b5c ea8054a8 eaa8fd50 [ 2.604845] bec0: c068969c ea2db180 c06801f8 c0269b18 c0590f68 c068969c c0656c98 c068969c [ 2.613004] bee0: c0656c98 ea3bbe40 c06988c0 c026aaf0 00000000 c0656c98 c0656c98 c00088a4 [ 2.621163] bf00: 00000000 c0055f48 00000000 00000004 00000000 ea890000 c05dbc54 c062c178 [ 2.629323] bf20: c0603518 c005f674 00000001 ea87a000 eb7ff83b c0476440 00000091 c003d41c [ 2.637482] bf40: c05db344 00000007 eb7ff858 00000007 c065a76c c0647d24 00000007 c062c170 [ 2.645642] bf60: c06988c0 00000091 c062c178 c0603518 00000000 c0603cc4 00000007 00000007 [ 2.653801] bf80: c0603518 c0c0c0c0 00000000 c0453948 00000000 00000000 00000000 00000000 [ 2.661959] bfa0: 00000000 c0453950 00000000 c000e728 00000000 00000000 00000000 00000000 [ 2.670118] bfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 2.678277] bfe0: 00000000 00000000 00000000 00000000 00000013 00000000 c0c0c0c0 c0c0c0c0 [ 2.686454] [] (strcmp) from [] (power_supply_match_device_by_name+0x10/0x1c) [ 2.695303] [] (power_supply_match_device_by_name) from [] (class_find_device+0x54/0xac) [ 2.705106] [] (class_find_device) from [] (power_supply_get_by_name+0x1c/0x30) [ 2.714137] [] (power_supply_get_by_name) from [] (charger_manager_probe+0x3d8/0xe58) [ 2.723683] [] (charger_manager_probe) from [] (platform_drv_probe+0x2c/0x5c) [ 2.732532] [] (platform_drv_probe) from [] (driver_probe_device+0x10c/0x224) [ 2.741384] [] (driver_probe_device) from [] (__driver_attach+0x94/0x98) [ 2.749813] [] (__driver_attach) from [] (bus_for_each_dev+0x54/0x88) [ 2.757969] [] (bus_for_each_dev) from [] (bus_add_driver+0xd4/0x1d0) [ 2.766123] [] (bus_add_driver) from [] (driver_register+0x78/0xf4) [ 2.774110] [] (driver_register) from [] (do_one_initcall+0x80/0x1bc) [ 2.782276] [] (do_one_initcall) from [] (kernel_init_freeable+0x100/0x1cc) [ 2.790952] [] (kernel_init_freeable) from [] (kernel_init+0x8/0xec) [ 2.799029] [] (kernel_init) from [] (ret_from_fork+0x14/0x2c) [ 2.806572] Code: e12fff1e e1a03000 eafffff7 e4d03001 (e4d12001) [ 2.812832] ---[ end trace 7f12556111b9e7ef ]--- Signed-off-by: Krzysztof Kozlowski Fixes: 856ee6115e2d ("charger-manager: Support deivce tree in charger manager driver") Signed-off-by: Sebastian Reichel Signed-off-by: Zefan Li commit 8e65d449fb0fd36359fbcfef34198135d223a4d0 Author: Benjamin Coddington Date: Tue Sep 23 12:26:20 2014 -0400 lockd: Try to reconnect if statd has moved commit 173b3afceebe76fa2205b2c8808682d5b541fe3c upstream. If rpc.statd is restarted, upcalls to monitor hosts can fail with ECONNREFUSED. In that case force a lookup of statd's new port and retry the upcall. Signed-off-by: Benjamin Coddington Signed-off-by: Trond Myklebust Signed-off-by: Zefan Li commit ca3a4163bb5d66c346801c83c9296e7fe97b6132 Author: Bryan O'Donoghue Date: Wed Sep 24 00:26:24 2014 +0100 x86/intel/quark: Switch off CR4.PGE so TLB flush uses CR3 instead commit ee1b5b165c0a2f04d2107e634e51f05d0eb107de upstream. Quark x1000 advertises PGE via the standard CPUID method PGE bits exist in Quark X1000's PTEs. In order to flush an individual PTE it is necessary to reload CR3 irrespective of the PTE.PGE bit. See Quark Core_DevMan_001.pdf section 6.4.11 This bug was fixed in Galileo kernels, unfixed vanilla kernels are expected to crash and burn on this platform. Signed-off-by: Bryan O'Donoghue Cc: Borislav Petkov Link: http://lkml.kernel.org/r/1411514784-14885-1-git-send-email-pure.logic@nexus-software.ie Signed-off-by: Ingo Molnar Signed-off-by: Zefan Li commit 21ff5d93554d5f1ece80bd7ded145dc786c6469a Author: David Matlack Date: Fri Sep 19 16:03:25 2014 -0700 kvm: don't take vcpu mutex for obviously invalid vcpu ioctls commit 2ea75be3219571d0ec009ce20d9971e54af96e09 upstream. vcpu ioctls can hang the calling thread if issued while a vcpu is running. However, invalid ioctls can happen when userspace tries to probe the kind of file descriptors (e.g. isatty() calls ioctl(TCGETS)); in that case, we know the ioctl is going to be rejected as invalid anyway and we can fail before trying to take the vcpu mutex. This patch does not change functionality, it just makes invalid ioctls fail faster. Signed-off-by: David Matlack Signed-off-by: Paolo Bonzini [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 92f961b3bf9166e0e5cb1e1d54217db1803c1720 Author: Andy Shevchenko Date: Thu Sep 18 20:08:53 2014 +0300 spi: dw-mid: terminate ongoing transfers at exit commit 8e45ef682cb31fda62ed4eeede5d9745a0a1b1e2 upstream. Do full clean up at exit, means terminate all ongoing DMA transfers. Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit 08b407459f4ece5096105730a2c7d1da1d16fb9e Author: Andy Shevchenko Date: Thu Sep 18 20:08:51 2014 +0300 spi: dw-mid: respect 8 bit mode commit b41583e7299046abdc578c33f25ed83ee95b9b31 upstream. In case of 8 bit mode and DMA usage we end up with every second byte written as 0. We have to respect bits_per_word settings what this patch actually does. Signed-off-by: Andy Shevchenko Signed-off-by: Mark Brown Signed-off-by: Zefan Li commit 67ecb11ce62e9d87b29edbf73bf87c562206edcb Author: K. Y. Srinivasan Date: Wed Aug 27 16:25:33 2014 -0700 Drivers: hv: vmbus: Cleanup vmbus_close_internal() commit 98d731bb064a9d1817a6ca9bf8b97051334a7cfe upstream. Eliminate calls to BUG_ON() in vmbus_close_internal(). We have chosen to potentially leak memory, than crash the guest in case of failures. In this version of the patch I have addressed comments from Dan Carpenter (dan.carpenter@oracle.com). Signed-off-by: K. Y. Srinivasan Tested-by: Sitsofe Wheeler Signed-off-by: Greg Kroah-Hartman [lizf: Backported to 3.4: s/return ret/return/g] Signed-off-by: Zefan Li commit a12dc90d616b4ea7cc2cce6d4c6b2394073daaed Author: K. Y. Srinivasan Date: Wed Aug 27 16:25:35 2014 -0700 Drivers: hv: vmbus: Fix a bug in vmbus_open() commit 45d727cee9e200f5b351528b9fb063b69cf702c8 upstream. Fix a bug in vmbus_open() and properly propagate the error. I would like to thank Dexuan Cui for identifying the issue. Signed-off-by: K. Y. Srinivasan Tested-by: Sitsofe Wheeler Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 1e0293dd0218520d0b8e802e07357b07061882b1 Author: K. Y. Srinivasan Date: Wed Aug 27 16:25:34 2014 -0700 Drivers: hv: vmbus: Cleanup vmbus_establish_gpadl() commit 72c6b71c245dac8f371167d97ef471b367d0b66b upstream. Eliminate the call to BUG_ON() by waiting for the host to respond. We are trying to reclaim the ownership of memory that was given to the host and so we will have to wait until the host responds. Signed-off-by: K. Y. Srinivasan Tested-by: Sitsofe Wheeler Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 3adbbcc200f4911123fa5c71f729958a54e9c51d Author: K. Y. Srinivasan Date: Wed Aug 27 16:25:32 2014 -0700 Drivers: hv: vmbus: Cleanup vmbus_teardown_gpadl() commit 66be653083057358724d56d817e870e53fb81ca7 upstream. Eliminate calls to BUG_ON() by properly handling errors. In cases where rollback is possible, we will return the appropriate error to have the calling code decide how to rollback state. In the case where we are transferring ownership of the guest physical pages to the host, we will wait for the host to respond. Signed-off-by: K. Y. Srinivasan Tested-by: Sitsofe Wheeler Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 3aae84bbb972584b095a9d170631d825c1dd9de2 Author: K. Y. Srinivasan Date: Wed Aug 27 16:25:31 2014 -0700 Drivers: hv: vmbus: Cleanup vmbus_post_msg() commit fdeebcc62279119dbeafbc1a2e39e773839025fd upstream. Posting messages to the host can fail because of transient resource related failures. Correctly deal with these failures and increase the number of attempts to post the message before giving up. In this version of the patch, I have normalized the error code to Linux error code. Signed-off-by: K. Y. Srinivasan Tested-by: Sitsofe Wheeler Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 0bd172d1db29b8379fc8a78dd384c462fe833183 Author: Kees Cook Date: Thu Sep 18 11:25:37 2014 -0700 firmware_class: make sure fw requests contain a name commit 471b095dfe0d693a8d624cbc716d1ee4d74eb437 upstream. An empty firmware request name will trigger warnings when building device names. Make sure this is caught earlier and rejected. The warning was visible via the test_firmware.ko module interface: echo -ne "\x00" > /sys/devices/virtual/misc/test_firmware/trigger_request Reported-by: Sasha Levin Signed-off-by: Kees Cook Tested-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit eea5a87d270e8d6925063019c3b0f3ff61fcb49a Author: Lu Baolu Date: Fri Sep 19 10:13:50 2014 +0800 USB: Add device quirk for ASUS T100 Base Station keyboard commit ddbe1fca0bcb87ca8c199ea873a456ca8a948567 upstream. This full-speed USB device generates spurious remote wakeup event as soon as USB_DEVICE_REMOTE_WAKEUP feature is set. As the result, Linux can't enter system suspend and S0ix power saving modes once this keyboard is used. This patch tries to introduce USB_QUIRK_IGNORE_REMOTE_WAKEUP quirk. With this quirk set, wakeup capability will be ignored during device configure. This patch could be back-ported to kernels as old as 2.6.39. Signed-off-by: Lu Baolu Acked-by: Alan Stern Signed-off-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit 7a6185a12d7bc28267a0917b2cb41e8eb8adb24f Author: Ricardo Ribalda Delgado Date: Wed Aug 27 14:57:57 2014 +0200 PCI: Generate uppercase hex for modalias interface class commit 89ec3dcf17fd3fa009ecf8faaba36828dd6bc416 upstream. Some implementations of modprobe fail to load the driver for a PCI device automatically because the "interface" part of the modalias from the kernel is lowercase, and the modalias from file2alias is uppercase. The "interface" is the low-order byte of the Class Code, defined in PCI r3.0, Appendix D. Most interface types defined in the spec do not use alpha characters, so they won't be affected. For example, 00h, 01h, 10h, 20h, etc. are unaffected. Print the "interface" byte of the Class Code in uppercase hex, as we already do for the Vendor ID, Device ID, Class, etc. [bhelgaas: changelog] Signed-off-by: Ricardo Ribalda Delgado Signed-off-by: Bjorn Helgaas Acked-by: Greg Kroah-Hartman Signed-off-by: Zefan Li commit a84663095ae6c00ecb0dcc07a0b82801aa33180f Author: Andreas Bomholtz Date: Mon Sep 22 09:50:43 2014 +0200 USB: cp210x: add support for Seluxit USB dongle commit dee80ad12d2b1b304286a707fde7ab05d1fc7bab upstream. Added the Seluxit ApS USB Serial Dongle to cp210x driver. Signed-off-by: Andreas Bomholtz Signed-off-by: Johan Hovold Signed-off-by: Zefan Li commit 810c74bd39235ef7b9f166e842efb6f2b42a9c3b Author: Joe Savage Date: Sat Sep 20 08:01:16 2014 -0500 USB: serial: cp210x: added Ketra N1 wireless interface support commit bfc2d7dfdd761ae3beccdb26abebe03cef042f46 upstream. Added support for Ketra N1 wireless interface, which uses the Silicon Labs' CP2104 USB to UART bridge with customized PID 8946. Signed-off-by: Joe Savage Signed-off-by: Johan Hovold Signed-off-by: Zefan Li commit 8e48aa5819ec9d87953110ca6ea2079b17d94524 Author: Guenter Roeck Date: Sun Sep 21 15:04:53 2014 -0700 Revert "percpu: free percpu allocation info for uniprocessor system" commit bb2e226b3bef596dd56be97df655d857b4603923 upstream. This reverts commit 3189eddbcafc ("percpu: free percpu allocation info for uniprocessor system"). The commit causes a hang with a crisv32 image. This may be an architecture problem, but at least for now the revert is necessary to be able to boot a crisv32 image. Cc: Tejun Heo Cc: Honggang Li Signed-off-by: Guenter Roeck Signed-off-by: Tejun Heo Fixes: 3189eddbcafc ("percpu: free percpu allocation info for uniprocessor system") Signed-off-by: Zefan Li commit 2d150da34ec69ac10329d01cab11e9334d0faba7 Author: Johan Hedberg Date: Thu Sep 18 11:26:32 2014 +0300 Bluetooth: Fix setting correct security level when initiating SMP commit 5eb596f55cacc2389554a8d7572d90d5e9d4269d upstream. We can only determine the final security level when both pairing request and response have been exchanged. When initiating pairing the starting target security level is set to MEDIUM unless explicitly specified to be HIGH, so that we can still perform pairing even if the remote doesn't have MITM capabilities. However, once we've received the pairing response we should re-consult the remote and local IO capabilities and upgrade the target security level if necessary. Without this patch the resulting Long Term Key will occasionally be reported to be unauthenticated when it in reality is an authenticated one. Signed-off-by: Johan Hedberg Signed-off-by: Marcel Holtmann [lizf: Backported to 3.4: adjust context] Signed-off-by: Zefan Li commit a66b378950318cc5ab9be8eb3f21dd2383ae18b9 Author: Douglas Lehr Date: Thu Aug 21 09:26:52 2014 +1000 PCI: Increase IBM ipr SAS Crocodile BARs to at least system page size commit 9fe373f9997b48fcd6222b95baf4a20c134b587a upstream. The Crocodile chip occasionally comes up with 4k and 8k BAR sizes. Due to an erratum, setting the SR-IOV page size causes the physical function BARs to expand to the system page size. Since ppc64 uses 64k pages, when Linux tries to assign the smaller resource sizes to the now 64k BARs the address will be truncated and the BARs will overlap. Force Linux to allocate the resource as a full page, which avoids the overlap. [bhelgaas: print expanded resource, too] Signed-off-by: Douglas Lehr Signed-off-by: Anton Blanchard Signed-off-by: Bjorn Helgaas Acked-by: Milton Miller Signed-off-by: Zefan Li commit 7cf009d054e48bea3eb70af362d8c58b22baadec Author: Andreas Noever Date: Tue Sep 16 15:16:02 2014 -0600 PCI: pciehp: Prevent NULL dereference during probe commit bceee4a97eb58bd0e80e39eff11b506ddd9e7ad3 upstream. pciehp assumes that dev->subordinate, the struct pci_bus for a bridge's secondary bus, exists. But we do not create that bus if we run out of bus numbers during enumeration. This leads to a NULL dereference in init_slot() (and other places). Change pciehp_probe() to return -ENODEV when no secondary bus is present. Signed-off-by: Andreas Noever Signed-off-by: Bjorn Helgaas Signed-off-by: Zefan Li commit c002aa006faa936b9b1c29431807fe8ab97df1b2 Author: Christian Borntraeger Date: Wed Sep 3 16:21:32 2014 +0200 KVM: s390: unintended fallthrough for external call commit f346026e55f1efd3949a67ddd1dcea7c1b9a615e upstream. We must not fallthrough if the conditions for external call are not met. Signed-off-by: Christian Borntraeger Reviewed-by: Thomas Huth Signed-off-by: Zefan Li commit d480591d22c6ccf8327da5716f96a41ae1cb9663 Author: Champion Chen Date: Sat Sep 6 14:06:08 2014 -0500 Bluetooth: Fix issue with USB suspend in btusb driver commit 85560c4a828ec9c8573840c9b66487b6ae584768 upstream. Suspend could fail for some platforms because btusb_suspend==> btusb_stop_traffic ==> usb_kill_anchored_urbs. When btusb_bulk_complete returns before system suspend and resubmits an URB, the system cannot enter suspend state. Signed-off-by: Champion Chen Signed-off-by: Larry Finger Signed-off-by: Marcel Holtmann Signed-off-by: Zefan Li commit 82508e0f0bdd4fd1090fc8ee09c6b94e170f78a5 Author: Artem Bityutskiy Date: Wed Jul 16 15:22:29 2014 +0300 UBIFS: fix free log space calculation commit ba29e721eb2df6df8f33c1f248388bb037a47914 upstream. Hu (hujianyang ) discovered an issue in the 'empty_log_bytes()' function, which calculates how many bytes are left in the log: " If 'c->lhead_lnum + 1 == c->ltail_lnum' and 'c->lhead_offs == c->leb_size', 'h' would equalent to 't' and 'empty_log_bytes()' would return 'c->log_bytes' instead of 0. " At this point it is not clear what would be the consequences of this, and whether this may lead to any problems, but this patch addresses the issue just in case. Tested-by: hujianyang Reported-by: hujianyang Signed-off-by: Artem Bityutskiy Signed-off-by: Zefan Li commit db73d4fcba98f8427d820b9e3cae01f1ec604233 Author: Artem Bityutskiy Date: Sun Jun 29 17:00:45 2014 +0300 UBIFS: fix a race condition commit 052c28073ff26f771d44ef33952a41d18dadd255 upstream. Hu (hujianyang@huawei.com) discovered a race condition which may lead to a situation when UBIFS is unable to mount the file-system after an unclean reboot. The problem is theoretical, though. In UBIFS, we have the log, which basically a set of LEBs in a certain area. The log has the tail and the head. Every time user writes data to the file-system, the UBIFS journal grows, and the log grows as well, because we append new reference nodes to the head of the log. So the head moves forward all the time, while the log tail stays at the same position. At any time, the UBIFS master node points to the tail of the log. When we mount the file-system, we scan the log, and we always start from its tail, because this is where the master node points to. The only occasion when the tail of the log changes is the commit operation. The commit operation has 2 phases - "commit start" and "commit end". The former is relatively short, and does not involve much I/O. During this phase we mostly just build various in-memory lists of the things which have to be written to the flash media during "commit end" phase. During the commit start phase, what we do is we "clean" the log. Indeed, the commit operation will index all the data in the journal, so the entire journal "disappears", and therefore the data in the log become unneeded. So we just move the head of the log to the next LEB, and write the CS node there. This LEB will be the tail of the new log when the commit operation finishes. When the "commit start" phase finishes, users may write more data to the file-system, in parallel with the ongoing "commit end" operation. At this point the log tail was not changed yet, it is the same as it had been before we started the commit. The log head keeps moving forward, though. The commit operation now needs to write the new master node, and the new master node should point to the new log tail. After this the LEBs between the old log tail and the new log tail can be unmapped and re-used again. And here is the possible problem. We do 2 operations: (a) We first update the log tail position in memory (see 'ubifs_log_end_commit()'). (b) And then we write the master node (see the big lock of code in 'do_commit()'). But nothing prevents the log head from moving forward between (a) and (b), and the log head may "wrap" now to the old log tail. And when the "wrap" happens, the contends of the log tail gets erased. Now a power cut happens and we are in trouble. We end up with the old master node pointing to the old tail, which was erased. And replay fails because it expects the master node to point to the correct log tail at all times. This patch merges the abovementioned (a) and (b) operations by moving the master node change code to the 'ubifs_log_end_commit()' function, so that it runs with the log mutex locked, which will prevent the log from being changed benween operations (a) and (b). Reported-by: hujianyang Tested-by: hujianyang Signed-off-by: Artem Bityutskiy Signed-off-by: Zefan Li commit a5b4755f4bd37cef9498e2d53a8cd666361e3cbe Author: Artem Bityutskiy Date: Sun Jun 29 16:55:02 2014 +0300 UBIFS: remove mst_mutex commit 07e19dff63e3d5d6500d831e36554ac9b1b0560e upstream. The 'mst_mutex' is not needed since because 'ubifs_write_master()' is only called on the mount path and commit path. The mount path is sequential and there is no parallelism, and the commit path is also serialized - there is only one commit going on at a time. Signed-off-by: Artem Bityutskiy Signed-off-by: Zefan Li commit 9083cb065a03722697dc5b81cfb2d0d426a73f82 Author: David Matlack Date: Mon Aug 18 15:46:07 2014 -0700 kvm: x86: fix stale mmio cache bug commit 56f17dd3fbc44adcdbc3340fe3988ddb833a47a7 upstream. The following events can lead to an incorrect KVM_EXIT_MMIO bubbling up to userspace: (1) Guest accesses gpa X without a memory slot. The gfn is cached in struct kvm_vcpu_arch (mmio_gfn). On Intel EPT-enabled hosts, KVM sets the SPTE write-execute-noread so that future accesses cause EPT_MISCONFIGs. (2) Host userspace creates a memory slot via KVM_SET_USER_MEMORY_REGION covering the page just accessed. (3) Guest attempts to read or write to gpa X again. On Intel, this generates an EPT_MISCONFIG. The memory slot generation number that was incremented in (2) would normally take care of this but we fast path mmio faults through quickly_check_mmio_pf(), which only checks the per-vcpu mmio cache. Since we hit the cache, KVM passes a KVM_EXIT_MMIO up to userspace. This patch fixes the issue by using the memslot generation number to validate the mmio cache. Signed-off-by: David Matlack [xiaoguangrong: adjust the code to make it simpler for stable-tree fix.] Signed-off-by: Xiao Guangrong Reviewed-by: David Matlack Reviewed-by: Xiao Guangrong Tested-by: David Matlack Signed-off-by: Paolo Bonzini Signed-off-by: Zefan Li