- 16 Feb, 2018 1 commit
-
-
Naveen N. Rao authored
commit 844e3be4 upstream. Classic BPF JIT was never ported completely to work on little endian powerpc. However, it can be enabled and will crash the system when used. As such, disable use of BPF JIT on ppc64le. Fixes: 7c105b63 ("powerpc: Add CONFIG_CPU_LITTLE_ENDIAN kernel config option.") Reported-by:
Thadeu Lima de Souza Cascardo <cascardo@redhat.com> Signed-off-by:
Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com> Acked-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 03 Feb, 2018 39 commits
-
-
Greg Kroah-Hartman authored
-
Stefan Agner authored
commit d593574a upstream. Since clocks are disabled except during message transfer clocks are also disabled when spi_imx_remove gets called. Accessing registers leads to a freeeze at least on a i.MX 6ULL. Enable clocks before disabling accessing the MXC_CSPICTRL register. Fixes: 9e556dcc ("spi: spi-imx: only enable the clocks when we start to transfer a message") Signed-off-by:
Stefan Agner <stefan@agner.ch> Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Fabio Estevam authored
commit 38b1f0fb upstream. The wakeup mechanism via RTSDEN bit relies on the system using the RTS/CTS lines, so only allow such wakeup method when the system actually has RTS/CTS support. Fixes: bc85734b ("serial: imx: allow waking up on RTSD") Signed-off-by:
Fabio Estevam <fabio.estevam@nxp.com> Reviewed-by:
Martin Kaiser <martin@kaiser.cx> Acked-by:
Fugang Duan <fugang.duan@nxp.com> Signed-off-by:
-
Mark Salyzyn authored
In the absence of commit a4298e45 ("net: add SOCK_RCU_FREE socket flag") and all the associated infrastructure changes to take advantage of a RCU grace period before freeing, there is a heightened possibility that a security check is performed while an ill-timed setsockopt call races in from user space. It then is prudent to null check sk_security, and if the case, reject the permissions. Because of the nature of this problem, hard to duplicate, no clear path, this patch is a simplified band-aid for stable trees lacking the infrastructure for the series of commits leading up to providing a suitable RCU grace period. This adjustment is orthogonal to infrastructure improvements that may nullify the needed check, but could be added as good code hygiene in all trees. general protection fault: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 14233 Comm: syz-executor2 Not tainted 4.4.112-g5f6325b #28 task: ffff8801d1095f00 task.stack: ffff8800b5950000 RIP: 0010:[<ffffffff81b69b7e>] [<ffffffff81b69b7e>] sock_has_perm+0x1fe/0x3e0 security/selinux/hooks.c:4069 RSP: 0018:ffff8800b5957ce0 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: 1ffff10016b2af9f RCX: ffffffff81b69b51 RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000010 RBP: ffff8800b5957de0 R08: 0000000000000001 R09: 0000000000000001 R10: 0000000000000000 R11: 1ffff10016b2af68 R12: ffff8800b5957db8 R13: 0000000000000000 R14: ffff8800b7259f40 R15: 00000000000000d7 FS: 00007f72f5ae2700(0000) GS:ffff8801db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000a2fa38 CR3: 00000001d7980000 CR4: 0000000000160670 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Stack: ffffffff81b69a1f ffff8800b5957d58 00008000b5957d30 0000000041b58ab3 ffffffff83fc82f2 ffffffff81b69980 0000000000000246 ffff8801d1096770 ffff8801d3165668 ffffffff8157844b ffff8801d1095f00 ffff880000000001 Call Trace: [<ffffffff81b6a19d>] selinux_socket_setsockopt+0x4d/0x80 security/selinux/hooks.c:4338 [<ffffffff81b4873d>] security_socket_setsockopt+0x7d/0xb0 security/security.c:1257 [<ffffffff82df1ac8>] SYSC_setsockopt net/socket.c:1757 [inline] [<ffffffff82df1ac8>] SyS_setsockopt+0xe8/0x250 net/socket.c:1746 [<ffffffff83776499>] entry_SYSCALL_64_fastpath+0x16/0x92 Code: c2 42 9b b6 81 be 01 00 00 00 48 c7 c7 a0 cb 2b 84 e8 f7 2f 6d ff 49 8d 7d 10 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 83 01 00 00 41 8b 75 10 31 RIP [<ffffffff81b69b7e>] sock_has_perm+0x1fe/0x3e0 security/selinux/hooks.c:4069 RSP <ffff8800b5957ce0> ---[ end trace 7b5aaf788fef6174 ]--- Signed-off-by:
Mark Salyzyn <salyzyn@android.com> Acked-by:
Paul Moore <paul@paul-moore.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Stephen Smalley <sds@tycho.nsa.gov> Cc: selinux@tycho.nsa.gov Cc: linux-security-module@vger.kernel.org Cc: Eric Paris <eparis@parisplace.org> Cc: Serge E. Hallyn <serge@hallyn.com> Cc: linux-kernel@vger.kernel.org Signed-off-by:
-
Oliver Neukum authored
commit cbeef22f upstream. Quoting Hans: If we return 1 from our post_reset handler, then our disconnect handler will be called immediately afterwards. Since pre_reset blocks all scsi requests our disconnect handler will then hang in the scsi_remove_host call. This is esp. bad because our disconnect handler hanging for ever also stops the USB subsys from enumerating any new USB devices, causes commands like lsusb to hang, etc. In practice this happens when unplugging some uas devices because the hub code may see the device as needing a warm-reset and calls usb_reset_device before seeing the disconnect. In this case uas_configure_endpoints fails with -ENODEV. We do not want to print an error for this, so this commit also silences the shost_printk for -ENODEV. ENDQUOTE However, if we do that we better drop any unconditional execution and report to the SCSI subsystem that we have undergone a reset but we are not operational now. Signed-off-by:
Oliver Neukum <oneukum@suse.com> Reported-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
-
Hemant Kumar authored
commit ce5bf9a5 upstream. Upon usb composition switch there is possibility of ep0 file release happening after gadget driver bind. In case of composition switch from adb to a non-adb composition gadget will never gets bound again resulting into failure of usb device enumeration. Fix this issue by checking FFS_FL_BOUND flag and avoid extra gadget driver unbind if it is already done as part of composition switch. This fixes adb reconnection error reported on Android running v4.4 and above kernel versions. Verified on Hikey running vanilla v4.15-rc7 + few out of tree Mali patches. Reviewed-at: https://android-review.googlesource.com/#/c/582632/ Cc: Felipe Balbi <balbi@kernel.org> Cc: Greg KH <gregkh@linux-foundation.org> Cc: Michal Nazarewicz <mina86@mina86.com> Cc: John Stultz <john.stultz@linaro.org> Cc: Dmitry Shmidt <dimitrysh@google.com> Cc: Badhri <badhri@google.com> Cc: Android Kernel Team <kernel-team@android.com> Signed-off-by:
Hemant Kumar <hemantk@codeaurora.org> [AmitP: Cherry-picked it from android-4.14 and updated the commit log] Signed-off-by:
Amit Pundir <amit.pundir@linaro.org> Signed-off-by:
-
Johan Hovold authored
commit 46fe895e upstream. Add new Motorola Tetra (simple) driver for Motorola Solutions TETRA PEI devices. D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1 P: Vendor=0cad ProdID=9011 Rev=24.16 S: Manufacturer=Motorola Solutions Inc. S: Product=Motorola Solutions TETRA PEI interface C: #Ifs= 2 Cfg#= 1 Atr=80 MxPwr=500mA I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none) Note that these devices do not support the CDC SET_CONTROL_LINE_STATE request (for any interface). Reported-by:
Max Schulze <max.schulze@posteo.de> Tested-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Shuah Khan authored
commit ef824501 upstream. usbip host lists devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Fix it to check and not list devices that are attached to vhci_hcd. Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
-
Shuah Khan authored
commit ef54cf0c upstream. usbip host binds to devices attached to vhci_hcd on the same server when user does attach over localhost or specifies the server as the remote. usbip attach -r localhost -b busid or usbip attach -r servername (or server IP) Unbind followed by bind works, however device is left in a bad state with accesses via the attached busid result in errors and system hangs during shutdown. Fix it to check and bail out if the device is already attached to vhci_hcd. Signed-off-by:
-
Jia-Ju Bai authored
commit c7b8f778 upstream. According to drivers/usb/serial/io_edgeport.c, the driver may sleep under a spinlock. The function call path is: edge_bulk_in_callback (acquire the spinlock) process_rcvd_data process_rcvd_status change_port_settings send_iosp_ext_cmd write_cmd_usb usb_kill_urb --> may sleep To fix it, the redundant usb_kill_urb() is removed from the error path after usb_submit_urb() fails. This possible bug is found by my static analysis tool (DSAC) and checked by my code review. Signed-off-by:
Jia-Ju Bai <baijiaju1990@gmail.com> Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Oliver Neukum authored
commit df1cc78a upstream. This devices drops random bytes from messages if you talk to it too fast. Signed-off-by:
-
Hans de Goede authored
commit f0386c08 upstream. When disconnected sometimes the cdc-acm driver logs errors like these: [20278.039417] cdc_acm 2-2:2.1: urb 9 failed submission with -19 [20278.042924] cdc_acm 2-2:2.1: urb 10 failed submission with -19 [20278.046449] cdc_acm 2-2:2.1: urb 11 failed submission with -19 [20278.049920] cdc_acm 2-2:2.1: urb 12 failed submission with -19 [20278.053442] cdc_acm 2-2:2.1: urb 13 failed submission with -19 [20278.056915] cdc_acm 2-2:2.1: urb 14 failed submission with -19 [20278.060418] cdc_acm 2-2:2.1: urb 15 failed submission with -19 Silence these by not logging errors when the result is -ENODEV. Signed-off-by:
-
Greg Kroah-Hartman authored
commit d08dd3f3 upstream. This adds a new device id for Chilitag devices to the pl2303 driver. Reported-by:
"Chu.Mike [朱堅宜]" <Mike-Chu@prolific.com.tw> Acked-by:
-
OKAMOTO Yoshiaki authored
commit 69341bd1 upstream. FS040U modem is manufactured by omega, and sold by Fujisoft. This patch adds ID of the modem to use option1 driver. Interface 3 is used as qmi_wwan, so the interface is ignored. Signed-off-by:
Yoshiaki Okamoto <yokamoto@allied-telesis.co.jp> Signed-off-by:
Hiroyuki Yamamoto <hyamamo@allied-telesis.co.jp> Acked-by:
-
Larry Finger authored
[ Upstream commit b77992d2 ] When not associated with an AP, wifi device drivers should respond to the SIOCGIWESSID ioctl with a zero-length string for the SSID, which is the behavior expected by dhcpcd. Currently, this driver returns an error code (-1) from the ioctl call, which causes dhcpcd to assume that the device is not a wireless interface and therefore it fails to work correctly with it thereafter. This problem was reported and tested at https://github.com/lwfinger/rtl8188eu/issues/234. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit b2fc059f ] Avoid dereferencing pointer g until after g has been sanity null checked; move the assignment of cdev much later when it is required into a more local scope. Detected by CoverityScan, CID#1222135 ("Dereference before null check") Fixes: b785ea7c ("usb: gadget: composite: fix ep->maxburst initialization") Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Felipe Balbi <felipe.balbi@linux.intel.com> Signed-off-by:
-
Icenowy Zheng authored
[ Upstream commit 04226916 ] A new usbid of UTV007 is found in a newly bought device. The usbid is 1f71:3301. The ID on the chip is: UTV007 A89029.1 1520L18K1 Both video and audio is tested with the modified usbtv driver. Signed-off-by:
Icenowy Zheng <icenowy@aosc.io> Acked-by:
Lubomir Rintel <lkundrak@v3.sk> Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by:
-
Gustavo A. R. Silva authored
[ Upstream commit 72753590 ] _vreg_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _vreg_ has been null checked. This issue was detected with the help of Coccinelle. Fixes: aa497613 ("ufs: Add regulator enable support") Signed-off-by:
Gustavo A. R. Silva <garsilva@embeddedor.com> Reviewed-by:
Subhash Jadavani <subhashj@codeaurora.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Guilherme G. Piccoli authored
[ Upstream commit e4717292 ] As part of the scsi EH path, aacraid performs a reinitialization of the adapter, which encompass freeing resources and IRQs, NULLifying lots of pointers, and then initialize it all over again. We've identified a problem during the free IRQ portion of this path if CONFIG_DEBUG_SHIRQ is enabled on kernel config file. Happens that, in case this flag was set, right after free_irq() effectively clears the interrupt, it checks if it was requested as IRQF_SHARED. In positive case, it performs another call to the IRQ handler on driver. Problem is: since aacraid currently free some resources *before* freeing the IRQ, once free_irq() path calls the handler again (due to CONFIG_DEBUG_SHIRQ), aacraid crashes due to NULL pointer dereference with the following trace: aac_src_intr_message+0xf8/0x740 [aacraid] __free_irq+0x33c/0x4a0 free_irq+0x78/0xb0 aac_free_irq+0x13c/0x150 [aacraid] aac_reset_adapter+0x2e8/0x970 [aacraid] aac_eh_reset+0x3a8/0x5d0 [aacraid] scsi_try_host_reset+0x74/0x180 scsi_eh_ready_devs+0xc70/0x1510 scsi_error_handler+0x624/0xa20 This patch prevents the crash by changing the order of the deinitialization in this path of aacraid: first we clear the IRQ, then we free other resources. No functional change intended. Signed-off-by:
Guilherme G. Piccoli <gpiccoli@linux.vnet.ibm.com> Reviewed-by:
Raghava Aditya Renukunta <RaghavaAditya.Renukunta@microsemi.com> Signed-off-by:
-
Darrick J. Wong authored
[ Upstream commit 22a6c837 ] Fix some complaints from the UBSAN about signed integer addition overflows. Signed-off-by:
Darrick J. Wong <darrick.wong@oracle.com> Reviewed-by:
Brian Foster <bfoster@redhat.com> Signed-off-by:
-
Christophe JAILLET authored
[ Upstream commit 8677b1ac ] If we don't find a matching device node, we must free the memory allocated in 'omap_dmm' a few lines above. Fixes: 7cb0d6c1 ("drm/omap: fix TILER on OMAP5") Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Yisheng Xie authored
[ Upstream commit bde5f6bc ] kmemleak_scan() will scan struct page for each node and it can be really large and resulting in a soft lockup. We have seen a soft lockup when do scan while compile kernel: watchdog: BUG: soft lockup - CPU#53 stuck for 22s! [bash:10287] [...] Call Trace: kmemleak_scan+0x21a/0x4c0 kmemleak_write+0x312/0x350 full_proxy_write+0x5a/0xa0 __vfs_write+0x33/0x150 vfs_write+0xad/0x1a0 SyS_write+0x52/0xc0 do_syscall_64+0x61/0x1a0 entry_SYSCALL64_slow_path+0x25/0x25 Fix this by adding cond_resched every MAX_SCAN_SIZE. Link: http://lkml.kernel.org/r/1511439788-20099-1-git-send-email-xieyisheng1@huawei.comSigned-off-by:
Yisheng Xie <xieyisheng1@huawei.com> Suggested-by:
Catalin Marinas <catalin.marinas@arm.com> Acked-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit 4ba161a7 ] Reported-by:
Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Trond Myklebust <trond.myklebust@primarydata.com> Tested-by:
Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by:
-
Tetsuo Handa authored
[ Upstream commit 88bc0ede ] register_shrinker() might return -ENOMEM error since Linux 3.12. Call panic() as with other failure checks in this function if register_shrinker() failed. Fixes: 1d3d4437 ("vmscan: per-node deferred work") Signed-off-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Cc: Jan Kara <jack@suse.com> Cc: Michal Hocko <mhocko@suse.com> Reviewed-by:
Michal Hocko <mhocko@suse.com> Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 15bfe05c ] On 64-bit (e.g. powerpc64/allmodconfig): drivers/net/ethernet/xilinx/ll_temac_main.c: In function 'temac_start_xmit_done': drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] dev_kfree_skb_irq((struct sk_buff *)cur_p->app4); ^ cdmac_bd.app4 is u32, so it is too small to hold a kernel pointer. Note that several other fields in struct cdmac_bd are also too small to hold physical addresses on 64-bit platforms. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Robert Lippert authored
[ Upstream commit bd467e4e ] Power values in the 100s of watt range can easily blow past 32bit math limits when processing everything in microwatts. Use 64bit math instead to avoid these issues on common 32bit ARM BMC platforms. Fixes: 442aba78 ("hwmon: PMBus device driver") Signed-off-by:
Robert Lippert <rlippert@google.com> Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
-
Vasily Averin authored
[ Upstream commit 81833de1 ] restart_grace() uses hardcoded init_net. It can cause to "list_add double add" in following scenario: 1) nfsd and lockd was started in several net namespaces 2) nfsd in init_net was stopped (lockd was not stopped because it have users from another net namespaces) 3) lockd got signal, called restart_grace() -> set_grace_period() and enabled lock_manager in hardcoded init_net. 4) nfsd in init_net is started again, its lockd_up() calls set_grace_period() and tries to add lock_manager into init_net 2nd time. Jeff Layton suggest: "Make it safe to call locks_start_grace multiple times on the same lock_manager. If it's already on the global grace_list, then don't try to add it again. (But we don't intentionally add twice, so for now we WARN about that case.) With this change, we also need to ensure that the nfsd4 lock manager initializes the list before we call locks_start_grace. While we're at it, move the rest of the nfsd_net initialization into nfs4_state_create_net. I see no reason to have it spread over two functions like it is today." Suggested patch was updated to generate warning in described situation. Suggested-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Vasily Averin <vvs@virtuozzo.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Andrew Elble authored
[ Upstream commit ae254dac ] Prevent the use of the closed (invalid) special stateid by clients. Signed-off-by:
Andrew Elble <aweits@rit.edu> Signed-off-by:
-
Vasily Averin authored
[ Upstream commit b8722857 ] Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit 9271d7e5 ] After taking the stateid st_mutex, we want to know that the stateid still represents valid state before performing any non-idempotent actions. Signed-off-by:
-
Trond Myklebust authored
[ Upstream commit fb500a7c ] Signed-off-by:
-
Eduardo Otubo authored
[ Upstream commit 5b5971df ] v2: * Replace busy wait with wait_event()/wake_up_all() * Cannot garantee that at the time xennet_remove is called, the xen_netback state will not be XenbusStateClosed, so added a condition for that * There's a small chance for the xen_netback state is XenbusStateUnknown by the time the xen_netfront switches to Closed, so added a condition for that. When unloading module xen_netfront from guest, dmesg would output warning messages like below: [ 105.236836] xen:grant_table: WARNING: g.e. 0x903 still in use! [ 105.236839] deferring g.e. 0x903 (pfn 0x35805) This problem relies on netfront and netback being out of sync. By the time netfront revokes the g.e.'s netback didn't have enough time to free all of them, hence displaying the warnings on dmesg. The trick here is to make netfront to wait until netback frees all the g.e.'s and only then continue to cleanup for the module removal, and this is done by manipulating both device states. Signed-off-by:
Eduardo Otubo <otubo@redhat.com> Acked-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
Wanpeng Li authored
[ Upstream commit c37c2873 ] Reported by syzkaller: *** Guest State *** CR0: actual=0x0000000080010031, shadow=0x0000000060000010, gh_mask=fffffffffffffff7 CR4: actual=0x0000000000002061, shadow=0x0000000000000000, gh_mask=ffffffffffffe8f1 CR3 = 0x000000002081e000 RSP = 0x000000000000fffa RIP = 0x0000000000000000 RFLAGS=0x00023000 DR7 = 0x00000000000000 ^^^^^^^^^^ ------------[ cut here ]------------ WARNING: CPU: 6 PID: 24431 at /home/kernel/linux/arch/x86/kvm//x86.c:7302 kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] CPU: 6 PID: 24431 Comm: reprotest Tainted: G W OE 4.14.0+ #26 RIP: 0010:kvm_arch_vcpu_ioctl_run+0x651/0x2ea0 [kvm] RSP: 0018:ffff880291d179e0 EFLAGS: 00010202 Call Trace: kvm_vcpu_ioctl+0x479/0x880 [kvm] do_vfs_ioctl+0x142/0x9a0 SyS_ioctl+0x74/0x80 entry_SYSCALL_64_fastpath+0x23/0x9a The failed vmentry is triggered by the following beautified testcase: #include <unistd.h> #include <sys/syscall.h> #include <string.h> #include <stdint.h> #include <linux/kvm.h> #include <fcntl.h> #include <sys/ioctl.h> long r[5]; int main() { struct kvm_debugregs dr = { 0 }; r[2] = open("/dev/kvm", O_RDONLY); r[3] = ioctl(r[2], KVM_CREATE_VM, 0); r[4] = ioctl(r[3], KVM_CREATE_VCPU, 7); struct kvm_guest_debug debug = { .control = 0xf0403, .arch = { .debugreg[6] = 0x2, .debugreg[7] = 0x2 } }; ioctl(r[4], KVM_SET_GUEST_DEBUG, &debug); ioctl(r[4], KVM_RUN, 0); } which testcase tries to setup the processor specific debug registers and configure vCPU for handling guest debug events through KVM_SET_GUEST_DEBUG. The KVM_SET_GUEST_DEBUG ioctl will get and set rflags in order to set TF bit if single step is needed. All regs' caches are reset to avail and GUEST_RFLAGS vmcs field is reset to 0x2 during vCPU reset. However, the cache of rflags is not reset during vCPU reset. The function vmx_get_rflags() returns an unreset rflags cache value since the cache is marked avail, it is 0 after boot. Vmentry fails if the rflags reserved bit 1 is 0. This patch fixes it by resetting both the GUEST_RFLAGS vmcs field and its cache to 0x2 during vCPU reset. Reported-by:
David Hildenbrand <david@redhat.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Nadav Amit <nadav.amit@gmail.com> Cc: Dmitry Vyukov <dvyukov@google.com> Signed-off-by:
Wanpeng Li <wanpeng.li@hotmail.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Josef Bacik authored
[ Upstream commit b77000ed ] If we fail to prepare our pages for whatever reason (out of memory in our case) we need to make sure to drop the block_group->data_rwsem, otherwise hilarity ensues. Signed-off-by:
Josef Bacik <jbacik@fb.com> Reviewed-by:
Omar Sandoval <osandov@fb.com> Reviewed-by:
Liu Bo <bo.li.liu@oracle.com> Reviewed-by:
David Sterba <dsterba@suse.com> [ add label and use existing unlocking code ] Signed-off-by:
-
Chun-Yeow Yeoh authored
[ Upstream commit fbbdad5e ] The previous path metric update from RANN frame has not considered the own link metric toward the transmitting mesh STA. Fix this. Reported-by: Michael65535 Signed-off-by:
Chun-Yeow Yeoh <yeohchunyeow@gmail.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
zhangliping authored
[ Upstream commit 67c8d22a ] If we want to add a datapath flow, which has more than 500 vxlan outputs' action, we will get the following error reports: openvswitch: netlink: Flow action size 32832 bytes exceeds max openvswitch: netlink: Flow action size 32832 bytes exceeds max openvswitch: netlink: Actions may not be safe on all matching packets ... ... It seems that we can simply enlarge the MAX_ACTIONS_BUFSIZE to fix it, but this is not the root cause. For example, for a vxlan output action, we need about 60 bytes for the nlattr, but after it is converted to the flow action, it only occupies 24 bytes. This means that we can still support more than 1000 vxlan output actions for a single datapath flow under the the current 32k max limitation. So even if the nla_len(attr) is larger than MAX_ACTIONS_BUFSIZE, we shouldn't report EINVAL and keep it move on, as the judgement can be done by the reserve_sfa_size. Signed-off-by:
zhangliping <zhangliping02@baidu.com> Acked-by:
Pravin B Shelar <pshelar@ovn.org> Signed-off-by:
-
Felix Kuehling authored
[ Upstream commit 8c946b89 ] SDMA only supports a fixed number of queues. HWS cannot handle oversubscription. Signed-off-by:
shaoyun liu <shaoyun.liu@amd.com> Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Oded Gabbay <oded.gabbay@gmail.com> Signed-off-by:
-
shaoyunl authored
[ Upstream commit d12fb13f ] ffs function return the position of the first bit set on 1 based. (bit zero returns 1). Signed-off-by:
-
Felix Kuehling authored
[ Upstream commit cf21654b ] Fix the SDMA load and unload sequence as suggested by HW document. Signed-off-by:
-
