- 03 Apr, 2014 27 commits
-
-
Hans de Goede authored
commit 8a0435d9 upstream. This extends Benjamin Tissoires manual min/max quirk table with support for the ThinkPad X240. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
Jiri Slaby <jslaby@suse.cz>
-
Benjamin Tissoires authored
commit 421e08c4 upstream. The new Lenovo Haswell series (-40's) contains a new Synaptics touchpad. However, these new Synaptics devices report bad axis ranges. Under Windows, it is not a problem because the Windows driver uses RMI4 over SMBus to talk to the device. Under Linux, we are using the PS/2 fallback interface and it occurs the reported ranges are wrong. Of course, it would be too easy to have only one range for the whole series, each touchpad seems to be calibrated in a different way. We can not use SMBus to get the actual range because I suspect the firmware will switch into the SMBus mode and stop talking through PS/2 (this is the case for hybrid HID over I2C / PS/2 Synaptics touchpads). So as a temporary solution (until RMI4 land into upstream), start a new list of quirks with the min/max manually set. Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
-
Dmitry Torokhov authored
commit e4dbedc7 upstream. We should not be using static variable mousedev_mix in methods that can be called before that singleton gets assigned. While at it let's add open and close methods to mousedev structure so that we do not need to test if we are dealing with multiplexor or normal device and simply call appropriate method directly. This fixes: https://bugzilla.kernel.org/show_bug.cgi?id=71551Reported-by:
GiulioDP <depasquale.giulio@gmail.com> Tested-by:
-
Theodore Ts'o authored
commit 00a1a053 upstream. Use cmpxchg() to atomically set i_flags instead of clearing out the S_IMMUTABLE, S_APPEND, etc. flags and then setting them from the EXT4_IMMUTABLE_FL, EXT4_APPEND_FL flags, since this opens up a race where an immutable file has the immutable flag cleared for a brief window of time. Reported-by:
John Sullivan <jsrhbz@kanargh.force9.co.uk> Signed-off-by:
"Theodore Ts'o" <tytso@mit.edu> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Martin Schwidefsky authored
commit ca5de58b upstream. With git commit 79c74ecb "s390/time,vdso: convert to the new update_vsyscall interface" the new update_vsyscall function already does the sum of xtime and wall_to_monotonic. The old update_vsyscall function only copied the wall_to_monotonic offset. The vdso code needs to be modified to take this into consideration. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Ping Cheng authored
commit b5fd2a3e upstream. Two tablets in this series support both pen and touch. One (Intuos S) only supports pen. This patch also updates the driver to process wireless devices that do not support touch interface. Tested-by:
Jason Gerecke <killertofu@gmail.com> Acked-by:
Chris Bagwell <chris@cnpbagwell.com> Signed-off-by:
Ping Cheng <pingc@wacom.com> Signed-off-by:
-
Michal Kubecek authored
commit 2a971354 upstream. If a fwmark is passed to ip_vs_conn_new(), it is passed in vaddr, not daddr. Therefore we should set AF to AF_UNSPEC in vaddr assignment (like we do in ip_vs_ct_in_get()), otherwise we may copy only first 4 bytes of an IPv6 address into cp->daddr. Signed-off-by:
Bogdano Arendartchuk <barendartchuk@suse.com> Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Acked-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
Simon Horman <horms@verge.net.au> Signed-off-by:
-
David Howells authored
commit 7026f192 upstream. When FS-Cache allocates an object, the following sequence of events can occur: -->fscache_alloc_object() -->cachefiles_alloc_object() [via cache->ops->alloc_object] <--[returns new object] -->fscache_attach_object() <--[failed] -->cachefiles_put_object() [via cache->ops->put_object] -->fscache_object_destroy() -->fscache_objlist_remove() -->rb_erase() to remove the object from fscache_object_list. resulting in a crash in the rbtree code. The problem is that the object is only added to fscache_object_list on the success path of fscache_attach_object() where it calls fscache_objlist_add(). So if fscache_attach_object() fails, the object won't have been added to the objlist rbtree. We do, however, unconditionally try to remove the object from the tree. Thanks to NeilBrown for finding this and suggesting this solution. Reported-by:
NeilBrown <neilb@suse.de> Signed-off-by:
David Howells <dhowells@redhat.com> Tested-by:
-
Dongmao Zhang authored
commit ece35848 upstream. The recovery time for a failed node was taking a long time because the failed node could not perform the full shutdown process. Removing the linger time speeds this up. The dlm does not care what happens to messages to or from the failed node. Signed-off-by:
Dongmao Zhang <dmzhang@suse.com> Signed-off-by:
David Teigland <teigland@redhat.com> Signed-off-by:
-
Andy Adamson authored
commit f9c96fcc upstream. Fix a dynamic session slot leak where a slot is preallocated and I/O is resent through the MDS. Signed-off-by:
Andy Adamson <andros@netapp.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Signed-off-by:
-
Jeff Layton authored
commit 4db72b40 upstream. If the setting of NFS_INO_INVALIDATING gets reordered to before the clearing of NFS_INO_INVALID_DATA, then another task may hit a race window where both appear to be clear, even though the inode's pages are still in need of invalidation. Fix this by adding the appropriate memory barriers. Signed-off-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
-
Trond Myklebust authored
commit 17dfeb91 upstream. Commit d529ef83 (NFS: fix the handling of NFS_INO_INVALID_DATA flag in nfs_revalidate_mapping) introduces a potential race, since it doesn't test the value of nfsi->cache_validity and set the bitlock in nfsi->flags atomically. Signed-off-by:
-
Jeff Layton authored
commit d529ef83 upstream. There is a possible race in how the nfs_invalidate_mapping function is handled. Currently, we go and invalidate the pages in the file and then clear NFS_INO_INVALID_DATA. The problem is that it's possible for a stale page to creep into the mapping after the page was invalidated (i.e., via readahead). If another writer comes along and sets the flag after that happens but before invalidate_inode_pages2 returns then we could clear the flag without the cache having been properly invalidated. So, we must clear the flag first and then invalidate the pages. Doing this however, opens another race: It's possible to have two concurrent read() calls that end up in nfs_revalidate_mapping at the same time. The first one clears the NFS_INO_INVALID_DATA flag and then goes to call nfs_invalidate_mapping. Just before calling that though, the other task races in, checks the flag and finds it cleared. At that point, it trusts that the mapping is good and gets the lock on the page, allowing the read() to be satisfied from the cache even though the data is no longer valid. These effects are easily manifested by running diotest3 from the LTP test suite on NFS. That program does a series of DIO writes and buffered reads. The operations are serialized and page-aligned but the existing code fails the test since it occasionally allows a read to come out of the cache incorrectly. While mixing direct and buffered I/O isn't recommended, I believe it's possible to hit this in other ways that just use buffered I/O, though that situation is much harder to reproduce. The problem is that the checking/clearing of that flag and the invalidation of the mapping really need to be atomic. Fix this by serializing concurrent invalidations with a bitlock. At the same time, we also need to allow other places that check NFS_INO_INVALID_DATA to check whether we might be in the middle of invalidating the file, so fix up a couple of places that do that to look for the new NFS_INO_INVALIDATING flag. Doing this requires us to be careful not to set the bitlock unnecessarily, so this code only does that if it believes it will be doing an invalidation. Signed-off-by:
-
Weston Andros Adamson authored
commit 471252cd upstream. cond_resched_lock(cinfo->lock) is called everywhere else while holding the cinfo->lock spinlock. Not holding this lock while calling transfer_commit_list in filelayout_recover_commit_reqs causes the BUG below. It's true that we can't hold this lock while calling pnfs_put_lseg, because that might try to lock the inode lock - which might be the same lock as cinfo->lock. To reproduce, mount a 2 DS pynfs server and run an O_DIRECT command that crosses a stripe boundary and is not page aligned, such as: dd if=/dev/zero of=/mnt/f bs=17000 count=1 oflag=direct BUG: sleeping function called from invalid context at linux/fs/nfs/nfs4filelayout.c:1161 in_atomic(): 0, irqs_disabled(): 0, pid: 27, name: kworker/0:1 2 locks held by kworker/0:1/27: #0: (events){.+.+.+}, at: [<ffffffff810501d7>] process_one_work+0x175/0x3a5 #1: ((&dreq->work)){+.+...}, at: [<ffffffff810501d7>] process_one_work+0x175/0x3a5 CPU: 0 PID: 27 Comm: kworker/0:1 Not tainted 3.13.0-rc3-branch-dros_testing+ #21 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013 Workqueue: events nfs_direct_write_schedule_work [nfs] 0000000000000000 ffff88007a39bbb8 ffffffff81491256 ffff88007b87a130 ffff88007a39bbd8 ffffffff8105f103 ffff880079614000 ffff880079617d40 ffff88007a39bc20 ffffffffa011603e ffff880078988b98 0000000000000000 Call Trace: [<ffffffff81491256>] dump_stack+0x4d/0x66 [<ffffffff8105f103>] __might_sleep+0x100/0x105 [<ffffffffa011603e>] transfer_commit_list+0x94/0xf1 [nfs_layout_nfsv41_files] [<ffffffffa01160d6>] filelayout_recover_commit_reqs+0x3b/0x68 [nfs_layout_nfsv41_files] [<ffffffffa00ba53a>] nfs_direct_write_reschedule+0x9f/0x1d6 [nfs] [<ffffffff810705df>] ? mark_lock+0x1df/0x224 [<ffffffff8106e617>] ? trace_hardirqs_off_caller+0x37/0xa4 [<ffffffff8106e691>] ? trace_hardirqs_off+0xd/0xf [<ffffffffa00ba8f8>] nfs_direct_write_schedule_work+0x9d/0xb7 [nfs] [<ffffffff810501d7>] ? process_one_work+0x175/0x3a5 [<ffffffff81050258>] process_one_work+0x1f6/0x3a5 [<ffffffff810501d7>] ? process_one_work+0x175/0x3a5 [<ffffffff8105187e>] worker_thread+0x149/0x1f5 [<ffffffff81051735>] ? rescuer_thread+0x28d/0x28d [<ffffffff81056d74>] kthread+0xd2/0xda [<ffffffff81056ca2>] ? __kthread_parkme+0x61/0x61 [<ffffffff8149e66c>] ret_from_fork+0x7c/0xb0 [<ffffffff81056ca2>] ? __kthread_parkme+0x61/0x61 Signed-off-by:
Weston Andros Adamson <dros@primarydata.com> Signed-off-by:
-
Christoph Hellwig authored
commit 1f90ee27 upstream. i_dio_count is used to protect dio access against truncate. We want to make sure there are no dio reads pending either when doing a truncate. I suspect on plain NFS things might work even without this, but once we use a pnfs layout driver that access backing devices directly things will go bad without the proper synchronization. Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
-
Christoph Hellwig authored
commit 2a009ec9 upstream. We need to have the I/O fully finished before telling the truncate code that we are done. Signed-off-by:
-
Christoph Hellwig authored
commit 9811cd57 upstream. nfs_file_direct_write only updates the inode size if it succeeded and returned the number of bytes written. But in the AIO case nfs_direct_wait turns the return value into -EIOCBQUEUED and we skip the size update. Instead the aio completion path should updated it, which this patch does. The implementation is a little hacky because there is no obvious way to find out we are called for a write in nfs_direct_complete. Signed-off-by:
-
Alexander Aring authored
commit a8c22754 upstream. The correct way to check on IPV6_ADDR_SCOPE_LINKLOCAL is to check with the ipv6_addr_src_scope function. Currently this can't be work, because ipv6_addr_scope returns a int with a mask of IPV6_ADDR_SCOPE_MASK (0x00f0U) and IPV6_ADDR_SCOPE_LINKLOCAL is 0x02. So the condition is always false. Signed-off-by:
Alexander Aring <alex.aring@gmail.com> Signed-off-by:
-
Trond Myklebust authored
commit f22e5edd upstream. Andy Adamson reports: The state manager is recovering expired state and recovery OPENs are being processed. If kswapd is pruning inodes at the same time, a deadlock can occur when kswapd calls evict_inode on an NFSv4.1 inode with a layout, and the resultant layoutreturn gets an error that the state mangager is to handle, causing the layoutreturn to wait on the (NFS client) cl_rpcwaitq. At the same time an open is waiting for the inode deletion to complete in __wait_on_freeing_inode. If the open is either the open called by the state manager, or an open from the same open owner that is holding the NFSv4 sequence id which causes the OPEN from the state manager to wait for the sequence id on the Seqid_waitqueue, then the state is deadlocked with kswapd. The fix is simply to have layoutreturn ignore all errors except NFS4ERR_DELAY. We already know that layouts are dropped on all server reboots, and that it has to be coded to deal with the "forgetful client model" that doesn't send layoutreturns. Reported-by:
-
Andy Adamson authored
commit c297c8b9 upstream. Otherwise RPCSEC_GSS_DESTROY messages are not sent. Signed-off-by:
Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by:
-
Olaf Hering authored
commit f5d2b7c2 upstream. Documentation/fb/modedb.txt states that video=option should be considered a global option. But video_setup and fb_get_options are not coded that way. Instead its required to boot with video=driver:option to set a given option in drvier. This is cumbersome because it requires to know in advance which driver will be active for a given board/kernel. The following patch implements the documented catchall for the fbdev drivers. It is now possible to boot with video=XxY without the need to know the active driver in advance. The specific case it tries to fix is syslinux in the SUSE installer which offers a menu to set a display resolution. Right now this just appends the vga= option the kernel. But in addition to vga= it should be possible to pass a generic video=XxY for all framebuffer/drm drivers. With this change forcing a certain window size of VM displays is now much easier. Today the video= option is stored in a global fb_mode_option. But unfortunately only drm uses it. Note: this change introduces a small memleak if video=option is actually used because fb_mode_option is const. Most drivers use strsep to get to individual options. This could be fixed in a followup patch which always releases the option string in every caller of fb_get_options. Signed-off-by:
Olaf Hering <olaf@aepfle.de> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Toshi Kani authored
commit a85eba88 upstream. When ACPI SLIT table has an I/O locality (i.e. a locality unique to an I/O device), numa_set_distance() emits this warning message: NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10 acpi_numa_slit_init() calls numa_set_distance() with pxm_to_node(), which assumes that all localities have been parsed with SRAT previously. SRAT does not list I/O localities, where as SLIT lists all localities including I/Os. Hence, pxm_to_node() returns NUMA_NO_NODE (-1) for an I/O locality. I/O localities are not supported and are ignored today, but emitting such warning message leads to unnecessary confusion. Change acpi_numa_slit_init() to avoid calling numa_set_distance() with NUMA_NO_NODE. Signed-off-by:
Toshi Kani <toshi.kani@hp.com> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Cc: Yinghai Lu <yinghai@kernel.org> Link: http://lkml.kernel.org/n/tip-dSvpjjvp8aMzs1ybkftxohlh@git.kernel.orgSigned-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
-
Oliver Neukum authored
commit 16c0c4e1 upstream. The AVX2 implementation also uses BMI2 instructions, but doesn't test for their availability. The assumption that AVX2 and BMI2 always go together is false. Some Haswells have AVX2 but not BMI2. Signed-off-by:
Oliver Neukum <oneukum@suse.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Jeff Mahoney authored
commit d0ce7b85 upstream. Commit 8116188f ("nouveau/acpi: hook up to the MXM method for mux switching.") broke the build on non-x86 architectures due to the new dependency on MXM and MXM being an x86 platform driver. It built previously since the vga switcheroo registration routines were zereod out on !X86. The code was built in but unused. This patch makes all of the DSM code depend on CONFIG_VGA_SWITCHEROO, allowing it to build on non-x86 and shrinking the module size as well. [rdunlap@infradead.org: fix build eror when VGA_SWITCHEROO is not enabled] Signed-off-by:
Jeff Mahoney <jeffm@suse.com> Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Dave Airlie <airlied@redhat.com> Signed-off-by:
-
J. Bruce Fields authored
commit a3f432bf upstream. This check was added by Al Viro with d9e80b7d "nfs d_revalidate() is too trigger-happy with d_drop()", with the explanation that we don't want to remove the root of a disconnected tree, which will still be included on the s_anon list. But DCACHE_DISCONNECTED does *not* actually identify dentries that are disconnected from the dentry tree or hashed on s_anon. IS_ROOT() is the way to do that. Also add a comment from Al's commit to remind us why this check is there. Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Reviewed-by:
-
David Howells authored
commit 57be4a78 upstream. struct x509_certificate needs struct tm declaring by #inclusion of linux/time.h prior to its definition. Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Josh Boyer <jwboyer@redhat.com> Signed-off-by:
-
Bockholdt Arne authored
commit 22e580d0 upstream. Corrected the MWAIT flag for C-State C6 on Intel Avoton/Rangeley processors. Signed-off-by:
Arne Bockholdt <linux-kernel@bockholdt.com> Acked-by:
Len Brown <len.brown@intel.com> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
- 01 Apr, 2014 3 commits
-
-
Len Brown authored
commit fab04b22 upstream. Support the "Intel(R) Atom(TM) Processor C2000 Product Family", formerly code-named Avoton. It is based on the next generation Intel Atom processor architecture, formerly code-named Silvermont. Signed-off-by:
-
James Ralston authored
commit afc65924 upstream. This patch adds the SMBus Device IDs for the Intel Wildcat Point-LP PCH. Signed-off-by:
James Ralston <james.d.ralston@intel.com> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Takashi Iwai authored
commit 7fe30711 upstream. The current code for controlling mic mute LED in patch_sigmatel.c blindly assumes that there is a single capture switch. But, there can be multiple multiple ones, and each of them flips the state, ended up in an inconsistent state. For fixing this problem, this patch adds kcontrol to be passed to the hook function so that the callee can check which switch is being accessed. In stac_capture_led_hook(), the state is checked as a bitmask, and turns on the LED when all capture switches are off. Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
- 31 Mar, 2014 10 commits
-
-
Jiri Slaby authored
-
Ilya Dryomov authored
commit f2be82b0 upstream. The check that makes sure that we have enough memory allocated to read in the entire header of the message in question is currently busted. It compares front_len of the incoming message with iov_len field of ceph_msg::front structure, which is used primarily to indicate the amount of data already read in, and not the size of the allocated buffer. Under certain conditions (e.g. a short read from a socket followed by that socket's shutdown and owning ceph_connection reset) this results in a warning similar to [85688.975866] libceph: get_reply front 198 > preallocated 122 (4#0) and, through another bug, leads to forever hung tasks and forced reboots. Fix this by comparing front_len with front_alloc_len field of struct ceph_msg, which stores the actual size of the buffer. Fixes: http://tracker.ceph.com/issues/5425Signed-off-by:
Ilya Dryomov <ilya.dryomov@inktank.com> Reviewed-by:
Sage Weil <sage@inktank.com> Signed-off-by:
-
Ilya Dryomov authored
commit 3f0a4ac5 upstream. Rename front local variable to front_len in get_reply() to make its purpose more clear. Signed-off-by:
-
Ilya Dryomov authored
commit 3cea4c30 upstream. Rename front_max field of struct ceph_msg to front_alloc_len to make its purpose more clear. Signed-off-by:
-
Michele Baldessari authored
commit 2b6e0ca1 upstream. In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and https://bugzilla.redhat.com/show_bug.cgi?id=970480 we received different reports of e100 throwing the following warning: [<c06a0ba5>] ? pci_disable_device+0x85/0x90 [<c044a153>] warn_slowpath_fmt+0x33/0x40 [<c06a0ba5>] pci_disable_device+0x85/0x90 [<f7fdf7e0>] __e100_shutdown+0x80/0x120 [e100] [<c0476ca5>] ? check_preempt_curr+0x65/0x90 [<f7fdf8d6>] e100_suspend+0x16/0x30 [e100] [<c06a1ebb>] pci_legacy_suspend+0x2b/0xb0 [<c098fc0f>] ? wait_for_completion+0x1f/0xd0 [<c06a2d50>] ? pci_pm_poweroff+0xb0/0xb0 [<c06a2de4>] pci_pm_freeze+0x94/0xa0 [<c0767bb7>] dpm_run_callback+0x37/0x80 [<c076a204>] ? pm_wakeup_pending+0xc4/0x140 [<c0767f12>] __device_suspend+0xb2/0x1f0 [<c076806f>] async_suspend+0x1f/0x90 [<c04706e5>] async_run_entry_fn+0x35/0x140 [<c0478aef>] ? wake_up_process+0x1f/0x40 [<c0464495>] process_one_work+0x115/0x370 [<c0462645>] ? start_worker+0x25/0x30 [<c0464dc5>] ? manage_workers.isra.27+0x1a5/0x250 [<c0464f6e>] worker_thread+0xfe/0x330 [<c0464e70>] ? manage_workers.isra.27+0x250/0x250 [<c046a224>] kthread+0x94/0xa0 [<c0997f37>] ret_from_kernel_thread+0x1b/0x28 [<c046a190>] ? insert_kthread_work+0x30/0x30 This patch removes pci_disable_device() from __e100_shutdown(). pci_clear_master() is enough. Signed-off-by:
Michele Baldessari <michele@acksyn.org> Tested-by:
Mark Harig <idirectscm@aim.com> Signed-off-by:
Aaron Brown <aaron.f.brown@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
-
Sarah Sharp authored
commit 1aa9578c upstream. Don Zickus <dzickus@redhat.com> writes: Some co-workers of mine bought Samsung laptops that had mostly usb3 ports. Those ports did not resume correctly (the driver would timeout communicating and fail). This led to frustration as suspend/resume is a common use for laptops. Poking around, I applied the reset on resume quirk to this chipset and the resume started working. Reloading the xhci_hcd module had been the temporary workaround. Signed-off-by:
Sarah Sharp <sarah.a.sharp@linux.intel.com> Reported-by:
Don Zickus <dzickus@redhat.com> Tested-by:
Prarit Bhargava <prarit@redhat.com> Signed-off-by:
-
Ping Cheng authored
commit 1d0d6df0 upstream. Old single touch Tablet PCs do not have touch_max set at wacom_features. Since touch device at lease supports one finger, assign touch_max to 1 when touch usage is defined in its HID Descriptor and touch_max is not pre-defined. Tested-by:
-
Marcelo Tosatti authored
commit 26a865f4 upstream. After free_loaded_vmcs executes, the "loaded_vmcs" structure is kfreed, and now vmx->loaded_vmcs points to a kfreed area. Subsequent free_loaded_vmcs then attempts to manipulate vmx->loaded_vmcs. Switch the order to avoid the problem. https://bugzilla.redhat.com/show_bug.cgi?id=1047892Reviewed-by:
Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
-
Marcelo Tosatti authored
commit 37f6a4e2 upstream. Rom Freiman <rom@stratoscale.com> notes other code paths vulnerable to bug fixed by 989c6b34. Signed-off-by:
-
Marcelo Tosatti authored
commit 989c6b34 upstream. It is possible for __direct_map to be called on invalid root_hpa (-1), two examples: 1) try_async_pf -> can_do_async_pf -> vmx_interrupt_allowed -> nested_vmx_vmexit 2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexit Then to load_vmcs12_host_state and kvm_mmu_reset_context. Check for this possibility, let fault exception be regenerated. BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by:
-
