- 25 May, 2019 18 commits
-
-
Bodong Wang authored
[ Upstream commit dd064867 ] The command was mistakenly using enable_hca in embedded CPU field. Fixes: 22e939a9 (net/mlx5: Update enable HCA dependency) Signed-off-by:
Bodong Wang <bodong@mellanox.com> Reported-by:
Alex Rosenbaum <alexr@mellanox.com> Signed-off-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
Saeed Mahameed <saeedm@mellanox.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jianbo Liu authored
[ Upstream commit 12d5cbf8 ] When flow_rule_match_XYZ() functions were first introduced, flow_rule_match_cvlan() for inner vlan is missing. In mlx5_core driver, to get inner vlan key and mask, flow_rule_match_vlan() is just called, which is wrong because it obtains outer vlan information by FLOW_DISSECTOR_KEY_VLAN. This commit fixes this by changing to call flow_rule_match_cvlan() after it's added. Fixes: 8f256622 ("flow_offload: add flow_rule and flow_match structures and use them") Signed-off-by:
Jianbo Liu <jianbol@mellanox.com> Signed-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Edward Cree authored
[ Upstream commit bae9ed69 ] Plumb it through from the flow_dissector. Signed-off-by:
-
Vadim Pasternak authored
[ Upstream commit f1436c80 ] Prevent reading unsupported slave address from SFP EEPROM by testing Diagnostic Monitoring Type byte in EEPROM. Read only page zero of EEPROM, in case this byte is zero. If some SFP transceiver does not support Digital Optical Monitoring (DOM), reading SFP EEPROM slave address 0x51 could return an error. Availability of DOM support is verified by reading from zero page Diagnostic Monitoring Type byte describing how diagnostic monitoring is implemented by transceiver. If bit 6 of this byte is set, it indicates that digital diagnostic monitoring has been implemented. Otherwise it is not and transceiver could fail to reply to transaction for slave address 0x51 [1010001X (A2h)], which is used to access measurements page. Such issue has been observed when reading cable MCP2M00-xxxx, MCP7F00-xxxx, and few others. Fixes: 2ea10903 ("mlxsw: spectrum: Add support for access cable info via ethtool") Fixes: 4400081b ("mlxsw: spectrum: Fix EEPROM access in case of SFP/SFP+") Signed-off-by:
Vadim Pasternak <vadimp@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Signed-off-by:
-
Vadim Pasternak authored
[ Upstream commit c52ecff7 ] Old Mellanox silicons, like switchx-2, switch-ib do not support reading QSFP modules temperature through MTMP register. Attempt to access this register on systems equipped with the this kind of silicon will cause initialization flow failure. Test for hardware resource capability is added in order to distinct between old and new silicon - old silicons do not have such capability. Fixes: 6a79507c ("mlxsw: core: Extend thermal module with per QSFP module thermal zones") Fixes: 5c42eaa0 ("mlxsw: core: Extend hwmon interface with QSFP module temperature attributes") Reported-by:
-
Junwei Hu authored
[ Upstream commit 532b0f7e ] Error message printed: modprobe: ERROR: could not insert 'tipc': Address family not supported by protocol. when modprobe tipc after the following patch: switch order of device registration, commit 7e27e8d6 ("tipc: switch order of device registration to fix a crash") Because sock_create_kern(net, AF_TIPC, ...) is called by tipc_topsrv_create_listener() in the initialization process of tipc_net_ops, tipc_socket_init() must be execute before that. I move tipc_socket_init() into function tipc_init_net(). Fixes: 7e27e8d6 ("tipc: switch order of device registration to fix a crash") Signed-off-by:
Junwei Hu <hujunwei4@huawei.com> Reported-by:
Wang Wang <wangwang2@huawei.com> Reviewed-by:
Kang Zhou <zhoukang7@huawei.com> Reviewed-by:
Suanming Mou <mousuanming@huawei.com> Signed-off-by:
-
Stefano Garzarella authored
[ Upstream commit ac03046e ] When the socket is released, we should free all packets queued in the per-socket list in order to avoid a memory leak. Signed-off-by:
Stefano Garzarella <sgarzare@redhat.com> Signed-off-by:
-
Junwei Hu authored
[ Upstream commit 7e27e8d6 ] When tipc is loaded while many processes try to create a TIPC socket, a crash occurs: PANIC: Unable to handle kernel paging request at virtual address "dfff20000000021d" pc : tipc_sk_create+0x374/0x1180 [tipc] lr : tipc_sk_create+0x374/0x1180 [tipc] Exception class = DABT (current EL), IL = 32 bits Call trace: tipc_sk_create+0x374/0x1180 [tipc] __sock_create+0x1cc/0x408 __sys_socket+0xec/0x1f0 __arm64_sys_socket+0x74/0xa8 ... This is due to race between sock_create and unfinished register_pernet_device. tipc_sk_insert tries to do "net_generic(net, tipc_net_id)". but tipc_net_id is not initialized yet. So switch the order of the two to close the race. This can be reproduced with multiple processes doing socket(AF_TIPC, ...) and one process doing module removal. Fixes: a62fbcce ("tipc: make subscriber server support net namespace") Signed-off-by:
Xiaogang Wang <wangxiaogang3@huawei.com> Signed-off-by:
-
Sabrina Dubroca authored
[ Upstream commit feadc4b6 ] Currently, nla_put_iflink() doesn't put the IFLA_LINK attribute when iflink == ifindex. In some cases, a device can be created in a different netns with the same ifindex as its parent. That device will not dump its IFLA_LINK attribute, which can confuse some userspace software that expects it. For example, if the last ifindex created in init_net and foo are both 8, these commands will trigger the issue: ip link add parent type dummy # ifindex 9 ip link add link parent netns foo type macvlan # ifindex 9 in ns foo So, in case a device puts the IFLA_LINK_NETNSID attribute in a dump, always put the IFLA_LINK attribute as well. Thanks to Dan Winship for analyzing the original OpenShift bug down to the missing netlink attribute. v2: change Fixes tag, it's been here forever, as Nicolas Dichtel said add Nicolas' ack v3: change Fixes tag fix subject typo, spotted by Edward Cree Analyzed-by:
Dan Winship <danw@redhat.com> Fixes: d8a5ec67 ("[NET]: netlink support for moving devices between network namespaces.") Signed-off-by:
Sabrina Dubroca <sd@queasysnail.net> Acked-by:
Nicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by:
-
YueHaibing authored
[ Upstream commit 3ebe1bca ] BUG: unable to handle kernel paging request at ffffffffa018f000 PGD 3270067 P4D 3270067 PUD 3271063 PMD 2307eb067 PTE 0 Oops: 0000 [#1] PREEMPT SMP CPU: 0 PID: 4138 Comm: modprobe Not tainted 5.1.0-rc7+ #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.9.3-0-ge2fc41e-prebuilt.qemu-project.org 04/01/2014 RIP: 0010:ppp_register_compressor+0x3e/0xd0 [ppp_generic] Code: 98 4a 3f e2 48 8b 15 c1 67 00 00 41 8b 0c 24 48 81 fa 40 f0 19 a0 75 0e eb 35 48 8b 12 48 81 fa 40 f0 19 a0 74 RSP: 0018:ffffc90000d93c68 EFLAGS: 00010287 RAX: ffffffffa018f000 RBX: ffffffffa01a3000 RCX: 000000000000001a RDX: ffff888230c750a0 RSI: 0000000000000000 RDI: ffffffffa019f000 RBP: ffffc90000d93c80 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa0194080 R13: ffff88822ee1a700 R14: 0000000000000000 R15: ffffc90000d93e78 FS: 00007f2339557540(0000) GS:ffff888237a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: ffffffffa018f000 CR3: 000000022bde4000 CR4: 00000000000006f0 Call Trace: ? 0xffffffffa01a3000 deflate_init+0x11/0x1000 [ppp_deflate] ? 0xffffffffa01a3000 do_one_initcall+0x6c/0x3cc ? kmem_cache_alloc_trace+0x248/0x3b0 do_init_module+0x5b/0x1f1 load_module+0x1db1/0x2690 ? m_show+0x1d0/0x1d0 __do_sys_finit_module+0xc5/0xd0 __x64_sys_finit_module+0x15/0x20 do_syscall_64+0x6b/0x1d0 entry_SYSCALL_64_after_hwframe+0x49/0xbe If ppp_deflate fails to register in deflate_init, module initialization failed out, however ppp_deflate_draft may has been regiestred and not unregistered before return. Then the seconed modprobe will trigger crash like this. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Acked-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
-
Pieter Jansen van Vuuren authored
[ Upstream commit cb07d915 ] Add rcu locks when accessing netdev when processing route request and tunnel keep alive messages received from hardware. Fixes: 8e6a9046 ("nfp: flower vxlan neighbour offload") Fixes: 856f5b13 ("nfp: flower vxlan neighbour keep-alive") Signed-off-by:
Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Reviewed-by:
John Hurley <john.hurley@netronome.com> Signed-off-by:
-
Daniele Palmas authored
[ Upstream commit b4e467c8 ] Added support for Telit LE910Cx 0x1260 and 0x1261 compositions. Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Acked-by:
Bjørn Mork <bjorn@mork.no> Signed-off-by:
-
Willem de Bruijn authored
[ Upstream commit 185ce5c3 ] Zerocopy skbs without completion notification were added for packet sockets with PACKET_TX_RING user buffers. Those signal completion through the TP_STATUS_USER bit in the ring. Zerocopy annotation was added only to avoid premature notification after clone or orphan, by triggering a copy on these paths for these packets. The mechanism had to define a special "no-uarg" mode because packet sockets already use skb_uarg(skb) == skb_shinfo(skb)->destructor_arg for a different pointer. Before deferencing skb_uarg(skb), verify that it is a real pointer. Fixes: 5cd8d46e ("packet: copy user buffers before orphan or clone") Signed-off-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
Yunjian Wang authored
[ Upstream commit 00f9fec4 ] The error print within mlx4_flow_steer_promisc_add() should be a info print. Fixes: 592e49dd ('net/mlx4: Implement promiscuous mode with device managed flow-steering') Signed-off-by:
Yunjian Wang <wangyunjian@huawei.com> Reviewed-by:
Tariq Toukan <tariqt@mellanox.com> Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit d7c04b05 ] When host is under high stress, it is very possible thread running netdev_wait_allrefs() returns from msleep(250) 10 seconds late. This leads to these messages in the syslog : [...] unregister_netdevice: waiting for syz_tun to become free. Usage count = 0 If the device refcount is zero, the wait is over. Signed-off-by:
Eric Dumazet <edumazet@google.com> Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 0fe9f173 ] Jiri reported that with a kernel built with CONFIG_FIXED_PHY=y, CONFIG_NET_DSA=m and CONFIG_NET_DSA_LOOP=m, we would not get to a functional state where the mock-up driver is registered. Turns out that we are not descending into drivers/net/dsa/ unconditionally, and we won't be able to link-in dsa_loop_bdinfo.o which does the actual mock-up mdio device registration. Reported-by:
Jiri Pirko <jiri@resnulli.us> Fixes: 40013ff2 ("net: dsa: Fix functional dsa-loop dependency on FIXED_PHY") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Vivien Didelot <vivien.didelot@gmail.com> Tested-by:
-
Eric Dumazet authored
[ Upstream commit 61fb0d01 ] At ipv6 route dismantle, fib6_drop_pcpu_from() is responsible for finding all percpu routes and set their ->from pointer to NULL, so that fib6_ref can reach its expected value (1). The problem right now is that other cpus can still catch the route being deleted, since there is no rcu grace period between the route deletion and call to fib6_drop_pcpu_from() This can leak the fib6 and associated resources, since no notifier will take care of removing the last reference(s). I decided to add another boolean (fib6_destroying) instead of reusing/renaming exception_bucket_flushed to ease stable backports, and properly document the memory barriers used to implement this fix. This patch has been co-developped with Wei Wang. Fixes: 93531c67 ("net/ipv6: separate handling of FIB entries from dst based routes") Signed-off-by:
Wei Wang <weiwan@google.com> Acked-by:
Martin KaFai Lau <kafai@fb.com> Reviewed-by:
David Ahern <dsahern@gmail.com> Signed-off-by:
-
Wei Wang authored
[ Upstream commit 510e2ced ] When inserting route cache into the exception table, the key is generated with both src_addr and dest_addr with src addr routing. However, current logic always assumes the src_addr used to generate the key is a /128 host address. This is not true in the following scenarios: 1. When the route is a gateway route or does not have next hop. (rt6_is_gw_or_nonexthop() == false) 2. When calling ip6_rt_cache_alloc(), saddr is passed in as NULL. This means, when looking for a route cache in the exception table, we have to do the lookup twice: first time with the passed in /128 host address, second time with the src_addr stored in fib6_info. This solves the pmtu discovery issue reported by Mikael Magnusson where a route cache with a lower mtu info is created for a gateway route with src addr. However, the lookup code is not able to find this route cache. Fixes: 2b760fcf ("ipv6: hook up exception table to store dst cache") Reported-by:
Mikael Magnusson <mikael.kernel@lists.m7n.se> Bisected-by:
-
- 22 May, 2019 22 commits
-
-
Greg Kroah-Hartman authored
-
Martin Schwidefsky authored
commit 1a42010c upstream. Define the gup_fast_permitted to check against the asce_limit of the mm attached to the current task, then replace the s390 specific gup code with the generic implementation in mm/gup.c. Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
-
Martin Schwidefsky authored
commit d1874a0c upstream. Change the way how pgd_offset, p4d_offset, pud_offset and pmd_offset walk the page tables. pgd_offset now always calculates the index for the top-level page table and adds it to the pgd, this is either a segment table offset for a 2-level setup, a region-3 offset for 3-levels, region-2 offset for 4-levels, or a region-1 offset for a 5-level setup. The other three functions p4d_offset, pud_offset and pmd_offset will only add the respective offset if they dereference the passed pointer. With the new way of walking the page tables a sequence like this from mm/gup.c now works: pgdp = pgd_offset(current->mm, addr); pgd = READ_ONCE(*pgdp); p4dp = p4d_offset(&pgd, addr); p4d = READ_ONCE(*p4dp); pudp = pud_offset(&p4d, addr); pud = READ_ONCE(*pudp); pmdp = pmd_offset(&pud, addr); pmd = READ_ONCE(*pmdp); Signed-off-by:
-
Dan Williams authored
commit c4703ce1 upstream. Users have reported intermittent occurrences of DIMM initialization failures due to duplicate allocations of address capacity detected in the labels, or errors of the form below, both have the same root cause. nd namespace1.4: failed to track label: 0 WARNING: CPU: 17 PID: 1381 at drivers/nvdimm/label.c:863 RIP: 0010:__pmem_label_update+0x56c/0x590 [libnvdimm] Call Trace: ? nd_pmem_namespace_label_update+0xd6/0x160 [libnvdimm] nd_pmem_namespace_label_update+0xd6/0x160 [libnvdimm] uuid_store+0x17e/0x190 [libnvdimm] kernfs_fop_write+0xf0/0x1a0 vfs_write+0xb7/0x1b0 ksys_write+0x57/0xd0 do_syscall_64+0x60/0x210 Unfortunately those reports were typically with a busy parallel namespace creation / destruction loop making it difficult to see the components of the bug. However, Jane provided a simple reproducer using the work-in-progress sub-section implementation. When ndctl is reconfiguring a namespace it may take an existing defunct / disabled namespace and reconfigure it with a new uuid and other parameters. Critically namespace_update_uuid() takes existing address resources and renames them for the new namespace to use / reconfigure as it sees fit. The bug is that this rename only happens in the resource tracking tree. Existing labels with the old uuid are not reaped leading to a scenario where multiple active labels reference the same span of address range. Teach namespace_update_uuid() to flag any references to the old uuid for reaping at the next label update attempt. Cc: <stable@vger.kernel.org> Fixes: bf9bccc1 ("libnvdimm: pmem label sets and namespace instantiation") Link: https://github.com/pmem/ndctl/issues/91Reported-by:
Jane Chu <jane.chu@oracle.com> Reported-by:
Jeff Moyer <jmoyer@redhat.com> Reported-by:
Erwin Tsaur <erwin.tsaur@oracle.com> Cc: Johannes Thumshirn <jthumshirn@suse.de> Signed-off-by:
Dan Williams <dan.j.williams@intel.com> Signed-off-by:
-
Christophe Leroy authored
commit 397d2300 upstream. flush_hash_pages() runs with data translation off, so current task_struct has to be accesssed using physical address. Fixes: f7354cca ("powerpc/32: Remove CURRENT_THREAD_INFO and rename TI_CPU") Cc: stable@vger.kernel.org # v5.1+ Reported-by:
Erhard F. <erhard_f@mailbox.org> Signed-off-by:
Christophe Leroy <christophe.leroy@c-s.fr> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Signed-off-by:
-
Roger Pau Monne authored
commit 72813bfb upstream. This involves initializing the boot params EFI related fields and the efi global variable. Without this fix a PVH dom0 doesn't detect when booted from EFI, and thus doesn't support accessing any of the EFI related data. Reported-by:
PGNet Dev <pgnet.dev@gmail.com> Signed-off-by:
Roger Pau Monné <roger.pau@citrix.com> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
Roger Pau Monne authored
commit c9f804d6 upstream. Or else xen_domain() returns false despite xen_pvh being set. Signed-off-by:
-
Masahiro Yamada authored
commit d2f8ae0e upstream. syncconfig is responsible for keeping auto.conf up-to-date, so if it fails for any reason, the build must be terminated immediately. However, since commit 9390dff6 ("kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing"), Kbuild continues running even after syncconfig fails. You can confirm this by intentionally making syncconfig error out: # diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c # index 08ba146..307b9de 100644 # --- a/scripts/kconfig/confdata.c # +++ b/scripts/kconfig/confdata.c # @@ -1023,6 +1023,9 @@ int conf_write_autoconf(int overwrite) # FILE *out, *tristate, *out_h; # int i; # # + if (overwrite) # + return 1; # + # if (!overwrite && is_present(autoconf_name)) # return 0; Then, syncconfig fails, but Make would not stop: $ make -s mrproper allyesconfig defconfig $ make scripts/kconfig/conf --syncconfig Kconfig *** Error during sync of the configuration. make[2]: *** [scripts/kconfig/Makefile;69: syncconfig] Error 1 make[1]: *** [Makefile;557: syncconfig] Error 2 make: *** [include/config/auto.conf.cmd] Deleting file 'include/config/tristate.conf' make: Failed to remake makefile 'include/config/auto.conf'. SYSTBL arch/x86/include/generated/asm/syscalls_32.h SYSHDR arch/x86/include/generated/asm/unistd_32_ia32.h SYSHDR arch/x86/include/generated/asm/unistd_64_x32.h SYSTBL arch/x86/include/generated/asm/syscalls_64.h [ continue running ... ] The reason is in the behavior of a pattern rule with multi-targets. %/auto.conf %/auto.conf.cmd %/tristate.conf: $(KCONFIG_CONFIG) $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig GNU Make knows this rule is responsible for making all the three files simultaneously. As far as examined, auto.conf.cmd is the target in question when this rule is invoked. It is probably because auto.conf.cmd is included below the inclusion of auto.conf. The inclusion of auto.conf is mandatory, while that of auto.conf.cmd is optional. GNU Make does not care about the failure in the process of updating optional include files. I filed this issue (https://savannah.gnu.org/bugs/?56301) in case this behavior could be improved somehow in future releases of GNU Make. Anyway, it is quite easy to fix our Makefile. Given that auto.conf is already a mandatory include file, there is no reason to stick auto.conf.cmd optional. Make it mandatory as well. Cc: linux-stable <stable@vger.kernel.org> # 5.0+ Fixes: 9390dff6 ("kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing") Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> [commented out diff above to keep patch happy - gregkh] Signed-off-by:
-
Steve French authored
commit b63a9de0 upstream. Displaying the session id in /proc/fs/cifs/DebugData is needed in order to correlate Linux client information with network and server traces for many common support scenarios. Turned out to be very important for debugging. Signed-off-by:
Steve French <stfrench@microsoft.com> CC: Stable <stable@vger.kernel.org> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> Signed-off-by:
-
Sean Christopherson authored
commit ee66e453 upstream. ...now that VMX's preemption timer, i.e. the hv_timer, also adjusts its programmed time based on lapic_timer_advance_ns. Without the delay, a guest can see a timer interrupt arrive before the requested time when KVM is using the hv_timer to emulate the guest's interrupt. Fixes: c5ce8235 ("KVM: VMX: Optimize tscdeadline timer latency") Cc: <stable@vger.kernel.org> Cc: Wanpeng Li <wanpengli@tencent.com> Reviewed-by:
Liran Alon <liran.alon@oracle.com> Signed-off-by:
Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Signed-off-by:
-
Sean Christopherson authored
commit 11988499 upstream. KVM allows userspace to violate consistency checks related to the guest's CPUID model to some degree. Generally speaking, userspace has carte blanche when it comes to guest state so long as jamming invalid state won't negatively affect the host. Currently this is seems to be a non-issue as most of the interesting EFER checks are missing, e.g. NX and LME, but those will be added shortly. Proactively exempt userspace from the CPUID checks so as not to break userspace. Note, the efer_reserved_bits check still applies to userspace writes as that mask reflects the host's capabilities, e.g. KVM shouldn't allow a guest to run with NX=1 if it has been disabled in the host. Fixes: d8017474 ("KVM: SVM: Only allow setting of EFER_SVME when CPUID SVM is set") Cc: stable@vger.kernel.org Signed-off-by:
-
Peter Xu authored
commit 4ddc9204 upstream. kvm_dirty_bitmap_bytes() will return the size of the dirty bitmap of the memslot rather than the size of bitmap passed over from the ioctl. Here for KVM_CLEAR_DIRTY_LOG we should only copy exactly the size of bitmap that covers kvm_clear_dirty_log.num_pages. Signed-off-by:
Peter Xu <peterx@redhat.com> Cc: stable@vger.kernel.org Fixes: 2a31b9dbSigned-off-by:
-
Sean Christopherson authored
commit f93f7ede upstream. The RDPMC-exiting control is dependent on the existence of the RDPMC instruction itself, i.e. is not tied to the "Architectural Performance Monitoring" feature. For all intents and purposes, the control exists on all CPUs with VMX support since RDPMC also exists on all VCPUs with VMX supported. Per Intel's SDM: The RDPMC instruction was introduced into the IA-32 Architecture in the Pentium Pro processor and the Pentium processor with MMX technology. The earlier Pentium processors have performance-monitoring counters, but they must be read with the RDMSR instruction. Because RDPMC-exiting always exists, KVM requires the control and refuses to load if it's not available. As a result, hiding the PMU from a guest breaks nested virtualization if the guest attemts to use KVM. While it's not explicitly stated in the RDPMC pseudocode, the VM-Exit check for RDPMC-exiting follows standard fault vs. VM-Exit prioritization for privileged instructions, e.g. occurs after the CPL/CR0.PE/CR4.PCE checks, but before the counter referenced in ECX is checked for validity. In other words, the original KVM behavior of injecting a #GP was correct, and the KVM unit test needs to be adjusted accordingly, e.g. eat the #GP when the unit test guest (L3 in this case) executes RDPMC without RDPMC-exiting set in the unit test host (L2). This reverts commit e51bfdb6. Fixes: e51bfdb6 ("KVM: nVMX: Expose RDPMC-exiting only when guest supports PMU") Reported-by:
David Hill <hilld@binarystorm.net> Cc: Saar Amar <saaramar@microsoft.com> Cc: Mihai Carabas <mihai.carabas@oracle.com> Cc: Jim Mattson <jmattson@google.com> Cc: Liran Alon <liran.alon@oracle.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Chengguang Xu authored
commit 0d52154b upstream. When failing from creating cache jbd2_inode_cache, we will destroy the previously created cache jbd2_handle_cache twice. This patch fixes this by moving each cache initialization/destruction to its own separate, individual function. Signed-off-by:
Chengguang Xu <cgxu519@gmail.com> Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by:
-
Michał Wadowski authored
commit 56df90b6 upstream. Add patch for realtek codec in Lenovo B50-70 that fixes inverted internal microphone channel. Device IdeaPad Y410P has the same PCI SSID as Lenovo B50-70, but first one is about fix the noise and it didn't seem help in a later kernel version. So I replaced IdeaPad Y410P device description with B50-70 and apply inverted microphone fix. Bugzilla: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1524215Signed-off-by:
Michał Wadowski <wadosm@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Kailang Yang authored
commit dad3197d upstream. Dell platform with ALC298. system enter to runtime suspend. Headphone had noise. Let Headset Mic not shutup will solve this issue. [ Fixed minor coding style issues by tiwai ] Signed-off-by:
Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jeremy Soller authored
commit 891afcf2 upstream. A mistake was made in the identification of the four variants of the System76 Gazelle (gaze14). This patch corrects the PCI ID of the 17-inch, GTX 1660 Ti variant from 0x8560 to 0x8551. This patch also adds the correct fixups for the 15-inch and 17-inch GTX 1650 variants with PCI IDs 0x8560 and 0x8561. Tests were done on all four variants ensuring full audio capability. Fixes: 80a5052d ("ALSA: hdea/realtek - Headset fixup for System76 Gazelle (gaze14)") Signed-off-by:
Jeremy Soller <jeremy@system76.com> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jan Kara authored
commit 2c1d0e36 upstream. Handling of aborted journal is a special code path different from standard ext4_error() one and it can call panic() as well. Commit 1dc1097f ("ext4: avoid panic during forced reboot") forgot to update this path so fix that omission. Fixes: 1dc1097f ("ext4: avoid panic during forced reboot") Signed-off-by:
Jan Kara <jack@suse.cz> Signed-off-by:
-
Sahitya Tummala authored
commit 08fc98a4 upstream. The buffer_head (frames[0].bh) and it's corresping page can be potentially free'd once brelse() is done inside the for loop but before the for loop exits in dx_release(). It can be free'd in another context, when the page cache is flushed via drop_caches_sysctl_handler(). This results into below data abort when accessing info->indirect_levels in dx_release(). Unable to handle kernel paging request at virtual address ffffffc17ac3e01e Call trace: dx_release+0x70/0x90 ext4_htree_fill_tree+0x2d4/0x300 ext4_readdir+0x244/0x6f8 iterate_dir+0xbc/0x160 SyS_getdents64+0x94/0x174 Signed-off-by:
Sahitya Tummala <stummala@codeaurora.org> Signed-off-by:
Andreas Dilger <adilger@dilger.ca> Cc: stable@kernel.org Signed-off-by:
-
Lukas Czerner authored
commit 57a0da28 upstream. Unaligned AIO must be serialized because the zeroing of partial blocks of unaligned AIO can result in data corruption in case it's overlapping another in flight IO. Currently we wait for all unwritten extents before we submit unaligned AIO which protects data in case of unaligned AIO is following overlapping IO. However if a unaligned AIO is followed by overlapping aligned AIO we can still end up corrupting data. To fix this, we must make sure that the unaligned AIO is the only IO in flight by waiting for unwritten extents conversion not just before the IO submission, but right after it as well. This problem can be reproduced by xfstest generic/538 Signed-off-by:
Lukas Czerner <lczerner@redhat.com> Signed-off-by:
-
Sriram Rajagopalan authored
commit 592acbf1 upstream. This commit zeroes out the unused memory region in the buffer_head corresponding to the extent metablock after writing the extent header and the corresponding extent node entries. This is done to prevent random uninitialized data from getting into the filesystem when the extent block is synced. This fixes CVE-2019-11833. Signed-off-by:
Sriram Rajagopalan <sriramr@arista.com> Signed-off-by:
-
Anup Patel authored
commit f91253a3 upstream. The Linux kernel will auto-disables all boot consoles whenever it gets a preferred real console. Currently on RISC-V systems, if we have a real console which is not RISCV SBI console then boot consoles (such as earlycon=sbi) are not auto-disabled when a real console (ttyS0 or ttySIF0) is available. This results in duplicate prints at boot-time after kernel starts using real console (i.e. ttyS0 or ttySIF0) if "earlycon=" kernel parameter was passed by bootloader. The reason for above issue is that RISCV SBI console always adds itself as preferred console which is causing other real consoles to be not used as preferred console. Ideally "console=" kernel parameter passed by bootloaders should be the one selecting a preferred real console. This patch fixes above issue by not forcing RISCV SBI console as preferred console. Fixes: afa6b1cc ("tty: New RISC-V SBI console driver") Cc: stable@vger.kernel.org Signed-off-by:
Anup Patel <anup.patel@wdc.com> Reviewed-by:
Atish Patra <atish.patra@wdc.com> Signed-off-by:
Palmer Dabbelt <palmer@sifive.com> Signed-off-by:
-
