- 06 Jun, 2015 40 commits
-
-
Takashi Iwai authored
commit fa94b0d7 upstream. Microsoft LifeCam Studio (045e:0772) needs a similar quirk for suppressing the wrong sample rate inquiry. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=98481Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Steven Rostedt authored
commit 37815bf8 upstream. The module notifier call chain for MODULE_STATE_COMING was moved up before the parsing of args, into the complete_formation() call. But if the module failed to load after that, the notifier call chain for MODULE_STATE_GOING was never called and that prevented the users of those call chains from cleaning up anything that was allocated. Link: http://lkml.kernel.org/r/554C52B9.9060700@gmail.comReported-by:
Pontus Fuchs <pontus.fuchs@gmail.com> Fixes: 4982223e "module: set nx before marking module MODULE_STATE_COMING" Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
-
Al Viro authored
commit 2159184e upstream. when we find that a child has died while we'd been trying to ascend, we should go into the first live sibling itself, rather than its sibling. Off-by-one in question had been introduced in "deal with deadlock in d_walk()" and the fix needs to be backported to all branches this one has been backported to. Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Jan Kara authored
commit f18c34e4 upstream. If the specified maximum length of the string is a multiple of unsigned long, we would load one long behind the specified maximum. If that happens to be in a next page, we can hit a page fault although we were not expected to. Fix the off-by-one bug in the test whether we are at the end of the specified range. Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Arend van Spriel authored
commit 7d072b40 upstream. The function brcmf_msgbuf_get_pktid() may return a NULL pointer so the callers should check the return pointer before accessing it to avoid the crash below (see [1]): brcmfmac: brcmf_msgbuf_get_pktid: Invalid packet id 273 (not in use) BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 IP: [<ffffffff8145b225>] skb_pull+0x5/0x50 PGD 0 Oops: 0000 [#1] PREEMPT SMP Modules linked in: pci_stub vboxpci(O) vboxnetflt(O) vboxnetadp(O) vboxdrv(O) snd_hda_codec_hdmi bnep mousedev hid_generic ushwmon msr ext4 crc16 mbcache jbd2 sd_mod uas usb_storage ahci libahci libata scsi_mod xhci_pci xhci_hcd usbcore usb_common CPU: 0 PID: 1661 Comm: irq/61-brcmf_pc Tainted: G O 4.0.1-MacbookPro-ARCH #1 Hardware name: Apple Inc. MacBookPro12,1/Mac-E43C1C25D4880AD6, BIOS MBP121.88Z.0167.B02.1503241251 03/24/2015 task: ffff880264203cc0 ti: ffff88025ffe4000 task.ti: ffff88025ffe4000 RIP: 0010:[<ffffffff8145b225>] [<ffffffff8145b225>] skb_pull+0x5/0x50 RSP: 0018:ffff88025ffe7d40 EFLAGS: 00010202 RAX: 0000000000000000 RBX: ffff88008a33c000 RCX: 0000000000000044 RDX: 0000000000000000 RSI: 000000000000004a RDI: 0000000000000000 RBP: ffff88025ffe7da8 R08: 0000000000000096 R09: 000000000000004a R10: 0000000000000000 R11: 000000000000048e R12: ffff88025ff14f00 R13: 0000000000000000 R14: ffff880263b48200 R15: ffff88008a33c000 FS: 0000000000000000(0000) GS:ffff88026ec00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000080 CR3: 000000000180b000 CR4: 00000000003407f0 Stack: ffffffffa06aed74 ffff88025ffe7dc8 ffff880263b48270 ffff880263b48278 05ea88020000004a 0002ffff81014635 000000001720b2f6 ffff88026ec116c0 ffff880263b48200 0000000000010000 ffff880263b4ae00 ffff880264203cc0 Call Trace: [<ffffffffa06aed74>] ? brcmf_msgbuf_process_rx+0x404/0x480 [brcmfmac] [<ffffffff810cea60>] ? irq_finalize_oneshot.part.30+0xf0/0xf0 [<ffffffffa06afb55>] brcmf_proto_msgbuf_rx_trigger+0x35/0xf0 [brcmfmac] [<ffffffffa06baf2a>] brcmf_pcie_isr_thread_v2+0x8a/0x130 [brcmfmac] [<ffffffff810cea80>] irq_thread_fn+0x20/0x50 [<ffffffff810ceddf>] irq_thread+0x13f/0x170 [<ffffffff810cebf0>] ? wake_threads_waitq+0x30/0x30 [<ffffffff810ceca0>] ? irq_thread_dtor+0xb0/0xb0 [<ffffffff81092a08>] kthread+0xd8/0xf0 [<ffffffff81092930>] ? kthread_create_on_node+0x1c0/0x1c0 [<ffffffff8156d898>] ret_from_fork+0x58/0x90 [<ffffffff81092930>] ? kthread_create_on_node+0x1c0/0x1c0 Code: 01 83 e2 f7 88 50 01 48 83 c4 08 5b 5d f3 c3 0f 1f 80 00 00 00 00 83 e2 f7 88 50 01 c3 66 0f 1f 84 00 00 00 00 00 0f 1f RIP [<ffffffff8145b225>] skb_pull+0x5/0x50 RSP <ffff88025ffe7d40> CR2: 0000000000000080 ---[ end trace b074c0f90e7c997d ]--- [1] http://mid.gmane.org/20150430193259.GA5630@googlemail.comReported-by:
Michael Hornung <mhornung.linux@gmail.com> Reviewed-by:
Hante Meuleman <meuleman@broadcom.com> Reviewed-by:
Pieter-Paul Giesberts <pieterpg@broadcom.com> Signed-off-by:
Arend van Spriel <arend@broadcom.com> Signed-off-by:
Kalle Valo <kvalo@codeaurora.org> Signed-off-by:
-
Dong Aisheng authored
commit d2a5d46b upstream. Before commit 035a61c3 ("clk: Make clk API return per-user struct clk instances") we acquired the enable_lock in __clk_set_parent_{before,after}() by means of calling clk_enable(). After commit 035a61c3 we use clk_core_enable() in place of the clk_enable(), and clk_core_enable() doesn't acquire the enable_lock. This opens up a race condition between clk_set_parent() and clk_enable(). Fix it. Fixes: 035a61c3 ("clk: Make clk API return per-user struct clk instances") Cc: Mike Turquette <mturquette@linaro.org> Cc: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
Dong Aisheng <aisheng.dong@freescale.com> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Javier Martinez Canillas authored
commit 97372e5a upstream. Commit ae43b328 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12") added pm support for the pl330 dma driver but it makes the clock for the Exynos5420 MDMA0 DMA controller to be gated during suspend and this in turn makes its parent clock aclk266_g2d to be gated. But the clock needs to be ungated prior suspend to allow the system to be suspend and resumed correctly. Add GATE_BUS_TOP register to the list of registers to be restored when the system enters into a suspend state so aclk266_g2d will be ungated. Thanks to Abhilash Kesavan for figuring out that this was the issue. Fixes: ae43b328 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12") Signed-off-by:
Javier Martinez Canillas <javier.martinez@collabora.co.uk> Tested-by:
Kevin Hilman <khilman@linaro.org> Tested-by:
Abhilash Kesavan <a.kesavan@samsung.com> Acked-by:
Tomasz Figa <tomasz.figa@gmail.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Guenter Roeck authored
commit c7bd6dc3 upstream. The following error message is seen when loading the nct6683 driver with DEBUG_LOCK_ALLOC enabled. BUG: key ffff88040b2f0030 not in .data! ------------[ cut here ]------------ WARNING: CPU: 0 PID: 186 at kernel/locking/lockdep.c:2988 lockdep_init_map+0x469/0x630() DEBUG_LOCKS_WARN_ON(1) Caused by a missing call to sysfs_attr_init() when initializing sysfs attributes. Reported-by:
Alexey Orishko <alexey.orishko@gmail.com> Reviewed-by:
Jean Delvare <jdelvare@suse.de> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Guenter Roeck authored
commit 1b63bf61 upstream. The following error message is seen when loading the nct6775 driver with DEBUG_LOCK_ALLOC enabled. BUG: key ffff88040b2f0030 not in .data! ------------[ cut here ]------------ WARNING: CPU: 0 PID: 186 at kernel/locking/lockdep.c:2988 lockdep_init_map+0x469/0x630() DEBUG_LOCKS_WARN_ON(1) Caused by a missing call to sysfs_attr_init() when initializing sysfs attributes. Reported-by:
-
Guenter Roeck authored
commit 9aecac04 upstream. I2C address 0x37 may be used by EEPROMs, which can result in false positives. Do not attempt to detect a chip at this address. Reviewed-by:
-
Thomas Betker authored
commit 97ffae1d upstream. The VREFN channel is bipolar, not unipolar. Small negative values do occur (e.g., -1mV), and unsigned conversion maps them incorrectly to large positive values (about +1V), so fix this. Signed-off-by:
Thomas Betker <thomas.betker@rohde-schwarz.com> Signed-off-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Thomas Betker authored
commit 00db4e52 upstream. The scaling factor for VREFP is 3.0/4096, not 1.0/4096; fix this to get correct readings. Signed-off-by:
-
Thomas Betker authored
commit d6c96c42 upstream. For the "vccaux" channel, read the VCCAUX register, not VCCINT. Signed-off-by:
-
Thomas Betker authored
commit 3960d2c0 upstream. Define the register addresses for MIN_VCCPINT, MIN_VCCPAUX, MIN_VCCO_DDR correctly. Signed-off-by:
-
Naidu Tellapati authored
commit 65a761bf upstream. regulator_get_voltage() returns a non-negative value in case of success, and a negative error in case of error. Let's fix this. Fixes: 1664f6a5 ("iio: adc: Cosmic Circuits 10001 ADC driver") Signed-off-by:
Naidu Tellapati <naidu.tellapati@imgtec.com> Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@imgtec.com> Signed-off-by:
-
Naidu Tellapati authored
commit f29b212e upstream. According to hardware team there should be some delay after setting channel number, start mode and before setting START. Add a one microsecond delay for this purpose. Fixes: 1664f6a5 ("iio: adc: Cosmic Circuits 10001 ADC driver") Signed-off-by:
-
Naidu Tellapati authored
commit 713276ea upstream. At present we are incorrectly setting the register to 0x1 to power up the ADC. Since it is an active high power down register, we need to set the register to 0x0 to actually power up. Conversely, writing 0x1 to the register powers it down. This commit adds a couple of helpers to make the code clearer and then use them to do the power-up/power-down properly. Fixes: 1664f6a5 ("iio: adc: Cosmic Circuits 10001 ADC driver") Signed-off-by:
-
Naidu Tellapati authored
commit 13415a99 upstream. When some of the ADC channels are reserved for remote CPUs, the scan index and the corresponding channel number doesn't match. This leads to convesion on the incorrect channel during triggered capture. Fix this by using a scan index to channel mapping encoded in the iio_chan_spec for this purpose while starting conversion on a particular ADC channel in trigger handler. Also, the channel_map is not really used anywhere but in probe(), so no need to keep track of it. Remove it from device structure. While here, add 1 to number of channels to register timestamp channel with the IIO core. Fixes: 1664f6a5 ("iio: adc: Cosmic Circuits 10001 ADC driver") Signed-off-by:
-
Ivan T. Ivanov authored
commit 937125ac upstream. With 'dx' equal to 0.625V and 15 bit ADC, calculations overflow when difference against GND is ~20% of the ADC range. Fix this. Signed-off-by:
Ivan T. Ivanov <ivan.ivanov@linaro.org> Signed-off-by:
-
Srinivas Pandruvada authored
commit 964e2255 upstream. Fix "null" in the raw attribute and scan elements. Signed-off-by:
Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Signed-off-by:
-
Srinivas Pandruvada authored
commit c2aab3d5 upstream. Currently in_proximity_(null)_raw is getting presented as raw sysfs attribute. Same with the scan_elements. The modifier doesn't apply to this channel. Signed-off-by:
-
Alban Bedel authored
commit 8e71c04f upstream. In SPI mode the transfer buffer is locked with a mutex. However this mutex is only initilized after the probe, but some transfer needs to be done in the probe. To fix this bug we move the mutex initialization at the beginning of the device probe. Signed-off-by:
Alban Bedel <alban.bedel@avionic-design.de> Acked-by:
Denis Ciocca <denis.ciocca@st.com> Signed-off-by:
-
Jacob Pan authored
commit d0716b0e upstream. Commit 65de7654 ("iio: iio: Fix iio_channel_read return if channel havn't info") added a check for valid info masks. This patch adds missing channel info masks for all ADC channels. Otherwise, iio_read_channel_raw() would return -EINVAL when called by consumer drivers. Note that the change of _processed to _raw actually fixes an ABI abuse in the original driver where it was used to avoid some special handling rather than because it was correct. Signed-off-by:
Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by:
-
Chris Lesiak authored
commit adba6575 upstream. When configured via device tree, the associated iio device needs to be measuring voltage for the conversion to resistance to be correct. Return -EINVAL if that is not the case. Signed-off-by:
Chris Lesiak <chris.lesiak@licor.com> Signed-off-by:
-
David Vrabel authored
commit 77bb3dfd upstream. A non-percpu VIRQ (e.g., VIRQ_CONSOLE) may be freed on a different VCPU than it is bound to. This can result in a race between handle_percpu_irq() and removing the action in __free_irq() because handle_percpu_irq() does not take desc->lock. The interrupt handler sees a NULL action and oopses. Only use the percpu chip/handler for per-CPU VIRQs (like VIRQ_TIMER). # cat /proc/interrupts | grep virq 40: 87246 0 xen-percpu-virq timer0 44: 0 0 xen-percpu-virq debug0 47: 0 20995 xen-percpu-virq timer1 51: 0 0 xen-percpu-virq debug1 69: 0 0 xen-dyn-virq xen-pcpu 74: 0 0 xen-dyn-virq mce 75: 29 0 xen-dyn-virq hvc_console Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
-
Filipe Manana authored
commit a9629596 upstream. If while setting a block group read-only we end up allocating a system chunk, through check_system_chunk(), we were not doing it while holding the chunk mutex which is a problem if a concurrent chunk allocation is happening, through do_chunk_alloc(), as it means both block groups can end up using the same logical addresses and physical regions in the device(s). So make sure we hold the chunk mutex. Fixes: 2f081088 ("btrfs: delete chunk allocation attemp when setting block group ro") Signed-off-by:
Filipe Manana <fdmanana@suse.com> Signed-off-by:
Chris Mason <clm@fb.com> Signed-off-by:
-
Ilya Dryomov authored
commit 521a04d0 upstream. This reverts commit ba9d114e. .. which introduced a regression that prevented all lingering requests requeued in kick_requests() from ever being sent to the OSDs, resulting in a lot of missed notifies. In retrospect it's pretty obvious that r_req_lru_item item in the case of lingering requests can be used not only for notarget, but also for unsent linkage due to how tightly actual map and enqueue operations are coupled in __map_request(). The assertion that was being silenced is taken care of in the previous ("libceph: request a new osdmap if lingering request maps to no osd") commit: by always kicking homeless lingering requests we ensure that none of them ends up on the notarget list outside of the critical section guarded by request_mutex. Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Reviewed-by:
Sage Weil <sage@redhat.com> Signed-off-by:
-
Ilya Dryomov authored
commit b0494532 upstream. This commit does two things. First, if there are any homeless lingering requests, we now request a new osdmap even if the osdmap that is being processed brought no changes, i.e. if a given lingering request turned homeless in one of the previous epochs and remained homeless in the current epoch. Not doing so leaves us with a stale osdmap and as a result we may miss our window for reestablishing the watch and lose notifies. MON=1 OSD=1: # cat linger-needmap.sh #!/bin/bash rbd create --size 1 test DEV=$(rbd map test) ceph osd out 0 rbd map dne/dne # obtain a new osdmap as a side effect (!) sleep 1 ceph osd in 0 rbd resize --size 2 test # rbd info test | grep size -> 2M # blockdev --getsize $DEV -> 1M N.B.: Not obtaining a new osdmap in between "osd out" and "osd in" above is enough to make it miss that resize notify, but that is a bug^Wlimitation of ceph watch/notify v1. Second, homeless lingering requests are now kicked just like those lingering requests whose mapping has changed. This is mainly to recognize that a homeless lingering request makes no sense and to preserve the invariant that a registered lingering request is not sitting on any of r_req_lru_item lists. This spares us a WARN_ON, which commit ba9d114e ("libceph: clear r_req_lru_item in __unregister_linger_request()") tried to fix the _wrong_ way. Signed-off-by:
-
Johan Hovold authored
commit e0c21530 upstream. Fix broken probe of da9052 regulators, which since commit b3f6c73d ("mfd: da9052-core: Fix platform-device id collision") use a non-deterministic platform-device id to retrieve static regulator information. Fortunately, adequate error handling was in place so probe would simply fail with an error message. Update the mfd-cell ids to be zero-based and use those to identify the cells when probing the regulator devices. Fixes: b3f6c73d ("mfd: da9052-core: Fix platform-device id collision") Signed-off-by:
Johan Hovold <johan@kernel.org> Acked-by:
Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> Reviewed-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Miklos Szeredi authored
commit cc6f67bc upstream. OpenWRT folks reported that overlayfs fails to mount if upper fs is full, because workdir can't be created. Wordir creation can fail for various other reasons too. There's no reason that the mount itself should fail, overlayfs can work fine without a workdir, as long as the overlay isn't modified. So mount it read-only and don't allow remounting read-write. Add a couple of WARN_ON()s for the impossible case of workdir being used despite being read-only. Reported-by:
Bastian Bittorf <bittorf@bluebottle.com> Signed-off-by:
Miklos Szeredi <mszeredi@suse.cz> Signed-off-by:
-
Miklos Szeredi authored
commit d377c5eb upstream. When removing an opaque directory we can't just call rmdir() to check for emptiness, because the directory will need to be replaced with a whiteout. The replacement is done with RENAME_EXCHANGE, which doesn't check emptiness. Solution is just to check emptiness by reading the directory. In the future we could add a new rename flag to check for emptiness even for RENAME_EXCHANGE to optimize this case. Reported-by:
Vincent Batts <vbatts@gmail.com> Signed-off-by:
Jordi Pujol Palomer <jordipujolp@gmail.com> Fixes: 263b4a0f ("ovl: dont replace opaque dir") Signed-off-by:
-
Rusty Russell authored
commit 83a35114 upstream. This bug has been there since day 1; addresses in the top guest physical page weren't considered valid. You could map that page (the check in check_gpte() is correct), but if a guest tried to put a pagetable there we'd check that address manually when walking it, and kill the guest. Signed-off-by:
-
Dave Chinner authored
commit cddc1162 upstream. It was missed when we converted everything in XFs to use negative error numbers, so fix it now. Bug introduced in 3.17 by commit 2451337d ("xfs: global error sign conversion"), and should go back to stable kernels. Thanks to Brian Foster for noticing it. Signed-off-by:
Dave Chinner <dchinner@redhat.com> Reviewed-by:
Brian Foster <bfoster@redhat.com> Signed-off-by:
Dave Chinner <david@fromorbit.com> Signed-off-by:
-
Dave Chinner authored
commit 6dfe5a04 upstream. xfs_attr_inactive() is supposed to clean up the attribute fork when the inode is being freed. While it removes attribute fork extents, it completely ignores attributes in local format, which means that there can still be active attributes on the inode after xfs_attr_inactive() has run. This leads to problems with concurrent inode writeback - the in-core inode attribute fork is removed without locking on the assumption that nothing will be attempting to access the attribute fork after a call to xfs_attr_inactive() because it isn't supposed to exist on disk any more. To fix this, make xfs_attr_inactive() completely remove all traces of the attribute fork from the inode, regardless of it's state. Further, also remove the in-core attribute fork structure safely so that there is nothing further that needs to be done by callers to clean up the attribute fork. This means we can remove the in-core and on-disk attribute forks atomically. Also, on error simply remove the in-memory attribute fork. There's nothing that can be done with it once we have failed to remove the on-disk attribute fork, so we may as well just blow it away here anyway. Reported-by:
Waiman Long <waiman.long@hp.com> Signed-off-by:
-
Bob Copeland authored
commit c0345ee5 upstream. The count variable is used to iterate down to (below) zero from the size of the bitmap and handle the one-filling the remainder of the last partial bitmap block. The loop conditional expects count to be signed in order to detect when the final block is processed, after which count goes negative. Unfortunately, a recent change made this unsigned along with some other related fields. The result of is this is that during mount, omfs_get_imap will overrun the bitmap array and corrupt memory unless number of blocks happens to be a multiple of 8 * blocksize. Fix by changing count back to signed: it is guaranteed to fit in an s32 without overflow due to an enforced limit on the number of blocks in the filesystem. Signed-off-by:
Bob Copeland <me@bobcopeland.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Sasha Levin authored
commit dcbff39d upstream. match_token() expects a NULL terminator at the end of the token list so that it would know where to stop. Not having one causes it to overrun to invalid memory. In practice, passing a mount option that omfs didn't recognize would sometimes panic the system. Signed-off-by:
Sasha Levin <sasha.levin@oracle.com> Signed-off-by:
-
John Stultz authored
commit f7bcb70e upstream. It was noted that the 32bit implementation of ktime_divns() was doing unsigned division and didn't properly handle negative values. And when a ktime helper was changed to utilize ktime_divns, it caused a regression on some IR blasters. See the following bugzilla for details: https://bugzilla.redhat.com/show_bug.cgi?id=1200353 This patch fixes the problem in ktime_divns by checking and preserving the sign bit, and then reapplying it if appropriate after the division, it also changes the return type to a s64 to make it more obvious this is expected. Nicolas also pointed out that negative dividers would cause infinite loops on 32bit systems, negative dividers is unlikely for users of this function, but out of caution this patch adds checks for negative dividers for both 32-bit (BUG_ON) and 64-bit(WARN_ON) versions to make sure no such use cases creep in. [ tglx: Hand an u64 to do_div() to avoid the compiler warning ] Fixes: 166afb64 'ktime: Sanitize ktime_to_us/ms conversion' Reported-and-tested-by:
Trevor Cordes <trevor@tecnopolis.ca> Signed-off-by:
John Stultz <john.stultz@linaro.org> Acked-by:
Nicolas Pitre <nicolas.pitre@linaro.org> Cc: Ingo Molnar <mingo@kernel.org> Cc: Josh Boyer <jwboyer@redhat.com> Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> Link: http://lkml.kernel.org/r/1431118043-23452-1-git-send-email-john.stultz@linaro.orgSigned-off-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
-
Liang Li authored
commit c447e76b upstream. The MPX feature requires eager KVM FPU restore support. We have verified that MPX cannot work correctly with the current lazy KVM FPU restore mechanism. Eager KVM FPU restore should be enabled if the MPX feature is exposed to VM. Signed-off-by:
Yang Zhang <yang.z.zhang@intel.com> Signed-off-by:
Liang Li <liang.z.li@intel.com> [Also activate the FPU on AMD processors. - Paolo] Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Xiao Guangrong authored
commit 0be0226f upstream. KVM may turn a user page to a kernel page when kernel writes a readonly user page if CR0.WP = 1. This shadow page entry will be reused after SMAP is enabled so that kernel is allowed to access this user page Fix it by setting SMAP && !CR0.WP into shadow page's role and reset mmu once CR4.SMAP is updated Signed-off-by:
Xiao Guangrong <guangrong.xiao@linux.intel.com> Signed-off-by:
-
Andrea Arcangeli authored
commit e8fd5e9e upstream. memslot->userfault_addr is set by the kernel with a mmap executed from the kernel but the userland can still munmap it and lead to the below oops after memslot->userfault_addr points to a host virtual address that has no vma or mapping. [ 327.538306] BUG: unable to handle kernel paging request at fffffffffffffffe [ 327.538407] IP: [<ffffffff811a7b55>] put_page+0x5/0x50 [ 327.538474] PGD 1a01067 PUD 1a03067 PMD 0 [ 327.538529] Oops: 0000 [#1] SMP [ 327.538574] Modules linked in: macvtap macvlan xt_CHECKSUM iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT iptable_filter ip_tables tun bridge stp llc rpcsec_gss_krb5 nfsv4 dns_resolver nfs fscache xprtrdma ib_isert iscsi_target_mod ib_iser libiscsi scsi_transport_iscsi ib_srpt target_core_mod ib_srp scsi_transport_srp scsi_tgt ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ipmi_devintf iTCO_wdt iTCO_vendor_support intel_powerclamp coretemp dcdbas intel_rapl kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd pcspkr sb_edac edac_core ipmi_si ipmi_msghandler acpi_pad wmi acpi_power_meter lpc_ich mfd_core mei_me [ 327.539488] mei shpchp nfsd auth_rpcgss nfs_acl lockd grace sunrpc mlx4_ib ib_sa ib_mad ib_core mlx4_en vxlan ib_addr ip_tunnel xfs libcrc32c sd_mod crc_t10dif crct10dif_common crc32c_intel mgag200 syscopyarea sysfillrect sysimgblt i2c_algo_bit drm_kms_helper ttm drm ahci i2c_core libahci mlx4_core libata tg3 ptp pps_core megaraid_sas ntb dm_mirror dm_region_hash dm_log dm_mod [ 327.539956] CPU: 3 PID: 3161 Comm: qemu-kvm Not tainted 3.10.0-240.el7.userfault19.4ca4011.x86_64.debug #1 [ 327.540045] Hardware name: Dell Inc. PowerEdge R420/0CN7CM, BIOS 2.1.2 01/20/2014 [ 327.540115] task: ffff8803280ccf00 ti: ffff880317c58000 task.ti: ffff880317c58000 [ 327.540184] RIP: 0010:[<ffffffff811a7b55>] [<ffffffff811a7b55>] put_page+0x5/0x50 [ 327.540261] RSP: 0018:ffff880317c5bcf8 EFLAGS: 00010246 [ 327.540313] RAX: 00057ffffffff000 RBX: ffff880616a20000 RCX: 0000000000000000 [ 327.540379] RDX: 0000000000002014 RSI: 00057ffffffff000 RDI: fffffffffffffffe [ 327.540445] RBP: ffff880317c5bd10 R08: 0000000000000103 R09: 0000000000000000 [ 327.540511] R10: 0000000000000000 R11: 0000000000000000 R12: fffffffffffffffe [ 327.540576] R13: 0000000000000000 R14: ffff880317c5bd70 R15: ffff880317c5bd50 [ 327.540643] FS: 00007fd230b7f700(0000) GS:ffff880630800000(0000) knlGS:0000000000000000 [ 327.540717] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 327.540771] CR2: fffffffffffffffe CR3: 000000062a2c3000 CR4: 00000000000427e0 [ 327.540837] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 327.540904] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 [ 327.540974] Stack: [ 327.541008] ffffffffa05d6d0c ffff880616a20000 0000000000000000 ffff880317c5bdc0 [ 327.541093] ffffffffa05ddaa2 0000000000000000 00000000002191bf 00000042f3feab2d [ 327.541177] 00000042f3feab2d 0000000000000002 0000000000000001 0321000000000000 [ 327.541261] Call Trace: [ 327.541321] [<ffffffffa05d6d0c>] ? kvm_vcpu_reload_apic_access_page+0x6c/0x80 [kvm] [ 327.543615] [<ffffffffa05ddaa2>] vcpu_enter_guest+0x3f2/0x10f0 [kvm] [ 327.545918] [<ffffffffa05e2f10>] kvm_arch_vcpu_ioctl_run+0x2b0/0x5a0 [kvm] [ 327.548211] [<ffffffffa05e2d02>] ? kvm_arch_vcpu_ioctl_run+0xa2/0x5a0 [kvm] [ 327.550500] [<ffffffffa05ca845>] kvm_vcpu_ioctl+0x2b5/0x680 [kvm] [ 327.552768] [<ffffffff810b8d12>] ? creds_are_invalid.part.1+0x12/0x50 [ 327.555069] [<ffffffff810b8d71>] ? creds_are_invalid+0x21/0x30 [ 327.557373] [<ffffffff812d6066>] ? inode_has_perm.isra.49.constprop.65+0x26/0x80 [ 327.559663] [<ffffffff8122d985>] do_vfs_ioctl+0x305/0x530 [ 327.561917] [<ffffffff8122dc51>] SyS_ioctl+0xa1/0xc0 [ 327.564185] [<ffffffff816de829>] system_call_fastpath+0x16/0x1b [ 327.566480] Code: 0b 31 f6 4c 89 e7 e8 4b 7f ff ff 0f 0b e8 24 fd ff ff e9 a9 fd ff ff 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 <48> f7 07 00 c0 00 00 55 48 89 e5 75 2a 8b 47 1c 85 c0 74 1e f0 Signed-off-by:
Andrea Arcangeli <aarcange@redhat.com> Signed-off-by:
-
