- 19 Aug, 2020 20 commits
-
-
Niklas Söderlund authored
[ Upstream commit d344234a ] When adding the adv7180 device node the ports node was misspelled as port, fix this. Fixes: 8cae3590 ("ARM: dts: gose: add composite video input") Signed-off-by:
Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20200704155856.3037010-2-niklas.soderlund+renesas@ragnatech.seSigned-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Lu Wei authored
[ Upstream commit 64dd4a5a ] In the function check_acpi_dev(), if it fails to create platform device, the return value is ERR_PTR() or NULL. Thus it must use IS_ERR_OR_NULL() to check return value. Fixes: 332e0812 ("intel-vbtn: new driver for Intel Virtual Button") Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Lu Wei <luwei32@huawei.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Lu Wei authored
[ Upstream commit 71fbe886 ] In the function check_acpi_dev(), if it fails to create platform device, the return value is ERR_PTR() or NULL. Thus it must use IS_ERR_OR_NULL() to check return value. Fixes: ecc83e52 ("intel-hid: new hid event driver for hotkeys") Reported-by:
-
Finn Thain authored
[ Upstream commit 931fc82a ] When writing values to the IOP status/control register make sure those values do not have any extraneous bits that will clear interrupt flags. To place the SCC IOP into bypass mode would be desirable but this is not achieved by writing IOP_DMAINACTIVE | IOP_RUN | IOP_AUTOINC | IOP_BYPASS to the control register. Drop this ineffective register write. Remove the flawed and unused iop_bypass() function. Make use of the unused iop_stop() function. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Finn Thain <fthain@telegraphics.com.au> Tested-by:
Stan Johnson <userm57@yahoo.com> Cc: Joshua Thompson <funaho@jurai.org> Link: https://lore.kernel.org/r/09bcb7359a1719a18b551ee515da3c4c3cf709e6.1590880333.git.fthain@telegraphics.com.auSigned-off-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
-
Finn Thain authored
[ Upstream commit aeb445bf ] In the following sequence of calls, iop_do_send() gets called when the "send" channel is not in the IOP_MSG_IDLE state: iop_ism_irq() iop_handle_send() (msg->handler)() iop_send_message() iop_do_send() Avoid this by testing the channel state before calling iop_do_send(). When sending, and iop_send_queue is empty, call iop_do_send() because the channel is idle. If iop_send_queue is not empty, iop_do_send() will get called later by iop_handle_send(). Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Sudeep Holla authored
[ Upstream commit fcd2e0de ] Currently we are not initializing the scmi clock with discrete rates correctly. We fetch the min_rate and max_rate value only for clocks with ranges and ignore the ones with discrete rates. This will lead to wrong initialization of rate range when clock supports discrete rate. Fix this by using the first and the last rate in the sorted list of the discrete clock rates while registering the clock. Link: https://lore.kernel.org/r/20200709081705.46084-2-sudeep.holla@arm.com Fixes: 6d6a1d82 ("clk: add support for clocks provided by SCMI") Reviewed-by:
Stephen Boyd <sboyd@kernel.org> Reported-and-tested-by:
Dien Pham <dien.pham.ry@renesas.com> Signed-off-by:
Sudeep Holla <sudeep.holla@arm.com> Signed-off-by:
-
Alim Akhtar authored
[ Upstream commit b072714b ] Once regulators are disabled after kernel boot, on Espresso board silent hang observed because of LDO7 being disabled. LDO7 actually provide power to CPU cores and non-cpu blocks circuitries. Keep this regulator always-on to fix this hang. Fixes: 9589f772 ("arm64: dts: Add S2MPS15 PMIC node on exynos7-espresso") Signed-off-by:
Alim Akhtar <alim.akhtar@samsung.com> Signed-off-by:
Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by:
-
Cristian Marussi authored
[ Upstream commit e0f1a30c ] When, at probe time, an SCMI communication failure inhibits the capacity to query power domains states, such domains should be skipped. Registering partially initialized SCMI power domains with genpd will causes kernel panic. arm-scmi timed out in resp(caller: scmi_power_state_get+0xa4/0xd0) scmi-power-domain scmi_dev.2: failed to get state for domain 9 Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000009f3691000 [0000000000000000] pgd=00000009f1ca0003, p4d=00000009f1ca0003, pud=00000009f35ea003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP CPU: 2 PID: 381 Comm: bash Not tainted 5.8.0-rc1-00011-gebd118c2cca8 #2 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Jan 3 2020 Internal error: Oops: 96000006 [#1] PREEMPT SMP pstate: 80000005 (Nzcv daif -PAN -UAO BTYPE=--) pc : of_genpd_add_provider_onecell+0x98/0x1f8 lr : of_genpd_add_provider_onecell+0x48/0x1f8 Call trace: of_genpd_add_provider_onecell+0x98/0x1f8 scmi_pm_domain_probe+0x174/0x1e8 scmi_dev_probe+0x90/0xe0 really_probe+0xe4/0x448 driver_probe_device+0xfc/0x168 device_driver_attach+0x7c/0x88 bind_store+0xe8/0x128 drv_attr_store+0x2c/0x40 sysfs_kf_write+0x4c/0x60 kernfs_fop_write+0x114/0x230 __vfs_write+0x24/0x50 vfs_write+0xbc/0x1e0 ksys_write+0x70/0xf8 __arm64_sys_write+0x24/0x30 el0_svc_common.constprop.3+0x94/0x160 do_el0_svc+0x2c/0x98 el0_sync_handler+0x148/0x1a8 el0_sync+0x158/0x180 Do not register any power domain that failed to be queried with genpd. Fixes: 898216c9 ("firmware: arm_scmi: add device power domain support using genpd") Link: https://lore.kernel.org/r/20200619220330.12217-1-cristian.marussi@arm.comSigned-off-by:
Cristian Marussi <cristian.marussi@arm.com> Signed-off-by:
-
Gilad Ben-Yossef authored
[ Upstream commit 9bc6165d ] Fix a small resource leak on the error path of cipher processing. Signed-off-by:
Gilad Ben-Yossef <gilad@benyossef.com> Fixes: 63ee04c8 ("crypto: ccree - add skcipher support") Cc: Markus Elfring <Markus.Elfring@web.de> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Stephan Gerhold authored
[ Upstream commit 1b6a1a16 ] msm8916-pins.dtsi specifies "bias-pull-none" for most of the audio pin configurations. This was likely copied from the qcom kernel fork where the same property was used for these audio pins. However, "bias-pull-none" actually does not exist at all - not in mainline and not in downstream. I can only guess that the original intention was to configure "no pull", i.e. bias-disable. Change it to that instead. Fixes: 143bb9ad ("arm64: dts: qcom: add audio pinctrls") Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Link: https://lore.kernel.org/r/20200605185916.318494-2-stephan@gerhold.netSigned-off-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
-
Qiushi Wu authored
[ Upstream commit 17ed808a ] When kobject_init_and_add() returns an error, it should be handled because kobject_init_and_add() takes a reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Therefore, replace calling kfree() and call kobject_put() and add a missing kobject_put() in the edac_device_register_sysfs_main_kobj() error path. [ bp: Massage and merge into a single patch. ] Fixes: b2ed215a ("Kobject: change drivers/edac to use kobject_init_and_add") Signed-off-by:
Qiushi Wu <wu000273@umn.edu> Signed-off-by:
Borislav Petkov <bp@suse.de> Link: https://lkml.kernel.org/r/20200528202238.18078-1-wu000273@umn.edu Link: https://lkml.kernel.org/r/20200528203526.20908-1-wu000273@umn.eduSigned-off-by:
-
Heiko Stuebner authored
[ Upstream commit 8a445086 ] The puma gmac node currently uses opposite active-values for the gmac phy reset pin. The gpio-declaration uses active-high while the separate snps,reset-active-low property marks the pin as active low. While on the kernel side this works ok, other DT users may get confused - as seen with uboot right now. So bring this in line and make both properties match, similar to the other Rockchip board. Fixes: 2c66fc34 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Signed-off-by:
Heiko Stuebner <heiko.stuebner@theobroma-systems.com> Link: https://lore.kernel.org/r/20200603132836.362519-1-heiko@sntech.deSigned-off-by:
-
Heiko Stuebner authored
[ Upstream commit 7a7184f6 ] The puma vcc5v0_host regulator node currently uses opposite active-values for the enable pin. The gpio-declaration uses active-high while the separate enable-active-low property marks the pin as active low. While on the kernel side this works ok, other DT users may get confused - as seen with uboot right now. So bring this in line and make both properties match, similar to the gmac fix. Fixes: 2c66fc34 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Signed-off-by:
-
Heiko Stuebner authored
[ Upstream commit 2300e6da ] The lion gmac node currently uses opposite active-values for the gmac phy reset pin. The gpio-declaration uses active-high while the separate snps,reset-active-low property marks the pin as active low. While on the kernel side this works ok, other DT users may get confused - as seen with uboot right now. So bring this in line and make both properties match, similar to the other Rockchip board. Fixes: d99a02bc ("arm64: dts: rockchip: add RK3368-uQ7 (Lion) SoM") Signed-off-by:
-
Peng Liu authored
[ Upstream commit 9b1b234b ] During sched domain init, we check whether non-topological SD_flags are returned by tl->sd_flags(), if found, fire a waning and correct the violation, but the code failed to correct the violation. Correct this. Fixes: 143e1e28 ("sched: Rework sched_domain topology definition") Signed-off-by:
Peng Liu <iwtbavbm@gmail.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by:
Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by:
Valentin Schneider <valentin.schneider@arm.com> Link: https://lkml.kernel.org/r/20200609150936.GA13060@iZj6chx1xj0e0buvshuecpZSigned-off-by:
-
Vincent Guittot authored
[ Upstream commit 3ea2f097 ] With commit: 'b7031a02 ("sched/fair: Add NOHZ_STATS_KICK")' rebalance_domains of the local cfs_rq happens before others idle cpus have updated nohz.next_balance and its value is overwritten. Move the update of nohz.next_balance for other idles cpus before balancing and updating the next_balance of local cfs_rq. Also, the nohz.next_balance is now updated only if all idle cpus got a chance to rebalance their domains and the idle balance has not been aborted because of new activities on the CPU. In case of need_resched, the idle load balance will be kick the next jiffie in order to address remaining ilb. Fixes: b7031a02 ("sched/fair: Add NOHZ_STATS_KICK") Reported-by:
Mel Gorman <mgorman@suse.de> Link: https://lkml.kernel.org/r/20200609123748.18636-1-vincent.guittot@linaro.orgSigned-off-by:
-
Zhenzhong Duan authored
[ Upstream commit 5d7f7d1d ] The original code is a nop as i_mce.status is or'ed with part of itself, fix it. Fixes: a1300e50 ("x86/ras/mce_amd_inj: Trigger deferred and thresholding errors interrupts") Signed-off-by:
Zhenzhong Duan <zhenzhong.duan@gmail.com> Signed-off-by:
Yazen Ghannam <yazen.ghannam@amd.com> Link: https://lkml.kernel.org/r/20200611023238.3830-1-zhenzhong.duan@gmail.comSigned-off-by:
-
Yang Yingliang authored
Add skcd->no_refcnt check which is missed when backporting ad0f75e5 ("cgroup: fix cgroup_sk_alloc() for sk_clone_lock()"). This patch is needed in stable-4.9, stable-4.14 and stable-4.19. Signed-off-by:
Yang Yingliang <yangyingliang@huawei.com> Signed-off-by:
-
Grant Likely authored
commit 4f57cace upstream. Some devices, particularly the 3DConnexion Spacemouse wireless 3D controllers, return more than just the battery capacity in the battery report. The Spacemouse devices return an additional byte with a device specific field. However, hidinput_query_battery_capacity() only requests a 2 byte transfer. When a spacemouse is connected via USB (direct wire, no wireless dongle) and it returns a 3 byte report instead of the assumed 2 byte battery report the larger transfer confuses and frightens the USB subsystem which chooses to ignore the transfer. Then after 2 seconds assume the device has stopped responding and reset it. This can be reproduced easily by using a wired connection with a wireless spacemouse. The Spacemouse will enter a loop of resetting every 2 seconds which can be observed in dmesg. This patch solves the problem by increasing the transfer request to 4 bytes instead of 2. The fix isn't particularly elegant, but it is simple and safe to backport to stable kernels. A further patch will follow to more elegantly handle battery reports that contain additional data. Signed-off-by:
Grant Likely <grant.likely@secretlab.ca> Cc: Darren Hart <darren@dvhart.com> Cc: Jiri Kosina <jikos@kernel.org> Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com> Cc: stable@vger.kernel.org Tested-by:
Darren Hart <dvhart@infradead.org> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nick Desaulniers authored
commit f3751ad0 upstream. __tracepoint_string's have their string data stored in .rodata, and an address to that data stored in the "__tracepoint_str" section. Functions that refer to those strings refer to the symbol of the address. Compiler optimization can replace those address references with references directly to the string data. If the address doesn't appear to have other uses, then it appears dead to the compiler and is removed. This can break the /tracing/printk_formats sysfs node which iterates the addresses stored in the "__tracepoint_str" section. Like other strings stored in custom sections in this header, mark these __used to inform the compiler that there are other non-obvious users of the address, so they should still be emitted. Link: https://lkml.kernel.org/r/20200730224555.2142154-2-ndesaulniers@google.com Cc: Ingo Molnar <mingo@redhat.com> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Cc: stable@vger.kernel.org Fixes: 102c9323 ("tracing: Add __tracepoint_string() to export string pointers") Reported-by:
Tim Murray <timmurray@google.com> Reported-by:
Simon MacMullen <simonmacm@google.com> Suggested-by:
Greg Hackmann <ghackmann@google.com> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
- 11 Aug, 2020 20 commits
-
-
Greg Kroah-Hartman authored
Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Eric Biggers authored
commit beb4ee67 upstream. smk_write_relabel_self() frees memory from the task's credentials with no locking, which can easily cause a use-after-free because multiple tasks can share the same credentials structure. Fix this by using prepare_creds() and commit_creds() to correctly modify the task's credentials. Reproducer for "BUG: KASAN: use-after-free in smk_write_relabel_self": #include <fcntl.h> #include <pthread.h> #include <unistd.h> static void *thrproc(void *arg) { int fd = open("/sys/fs/smackfs/relabel-self", O_WRONLY); for (;;) write(fd, "foo", 3); } int main() { pthread_t t; pthread_create(&t, NULL, thrproc, NULL); thrproc(NULL); } Reported-by: syzbot+e6416dabb497a650da40@syzkaller.appspotmail.com Fixes: 38416e53 ("Smack: limited capability for changing process label") Cc: <stable@vger.kernel.org> # v4.4+ Signed-off-by:
Eric Biggers <ebiggers@google.com> Signed-off-by:
Casey Schaufler <casey@schaufler-ca.com> Signed-off-by:
-
Martyna Szapar authored
[ Upstream commit 0b636446 ] Added freeing the old allocation of vf->qvlist_info in function i40e_config_iwarp_qvlist before overwriting it with the new allocation. Fixes: e3219ce6 ("i40e: Add support for client interface for IWARP driver") Signed-off-by:
Martyna Szapar <martyna.szapar@intel.com> Tested-by:
Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by:
Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Signed-off-by:
-
Martyna Szapar authored
[ Upstream commit 24474f27 ] Fixed possible memory leak in i40e_vc_add_cloud_filter function: cfilter is being allocated and in some error conditions the function returns without freeing the memory. Fix of integer truncation from u16 (type of queue_id value) to u8 when calling i40e_vc_isvalid_queue_id function. Fixes: e284fc28 ("i40e: Add and delete cloud filter") Signed-off-by:
-
Grzegorz Siwik authored
[ Upstream commit c004804d ] In this patch fixed wrong truncation method from u16 to u8 during validation. It was changed by changing u8 to u32 parameter in method declaration and arguments were changed to u32. Fixes: 5c3c48ac ("i40e: implement virtual device interface") Signed-off-by:
Grzegorz Siwik <grzegorz.siwik@intel.com> Tested-by:
-
Sergey Nemov authored
[ Upstream commit 7015ca3d ] Field num_vectors from struct virtchnl_iwarp_qvlist_info should not be larger than num_msix_vectors_vf in the hw struct. The iwarp uses the same set of vectors as the LAN VF driver. Fixes: e3219ce6 ("i40e: Add support for client interface for IWARP driver") Signed-off-by:
Sergey Nemov <sergey.nemov@intel.com> Tested-by:
-
David Howells authored
[ Upstream commit 65550098 ] There's a race between rxrpc_sendmsg setting up a call, but then failing to send anything on it due to an error, and recvmsg() seeing the call completion occur and trying to return the state to the user. An assertion fails in rxrpc_recvmsg() because the call has already been released from the socket and is about to be released again as recvmsg deals with it. (The recvmsg_q queue on the socket holds a ref, so there's no problem with use-after-free.) We also have to be careful not to end up reporting an error twice, in such a way that both returns indicate to userspace that the user ID supplied with the call is no longer in use - which could cause the client to malfunction if it recycles the user ID fast enough. Fix this by the following means: (1) When sendmsg() creates a call after the point that the call has been successfully added to the socket, don't return any errors through sendmsg(), but rather complete the call and let recvmsg() retrieve them. Make sendmsg() return 0 at this point. Further calls to sendmsg() for that call will fail with ESHUTDOWN. Note that at this point, we haven't send any packets yet, so the server doesn't yet know about the call. (2) If sendmsg() returns an error when it was expected to create a new call, it means that the user ID wasn't used. (3) Mark the call disconnected before marking it completed to prevent an oops in rxrpc_release_call(). (4) recvmsg() will then retrieve the error and set MSG_EOR to indicate that the user ID is no longer known by the kernel. An oops like the following is produced: kernel BUG at net/rxrpc/recvmsg.c:605! ... RIP: 0010:rxrpc_recvmsg+0x256/0x5ae ... Call Trace: ? __init_waitqueue_head+0x2f/0x2f ____sys_recvmsg+0x8a/0x148 ? import_iovec+0x69/0x9c ? copy_msghdr_from_user+0x5c/0x86 ___sys_recvmsg+0x72/0xaa ? __fget_files+0x22/0x57 ? __fget_light+0x46/0x51 ? fdget+0x9/0x1b do_recvmmsg+0x15e/0x232 ? _raw_spin_unlock+0xa/0xb ? vtime_delta+0xf/0x25 __x64_sys_recvmmsg+0x2c/0x2f do_syscall_64+0x4c/0x78 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: 357f5ef6 ("rxrpc: Call rxrpc_release_call() on error in rxrpc_new_client_call()") Reported-by: syzbot+b54969381df354936d96@syzkaller.appspotmail.com Signed-off-by:
David Howells <dhowells@redhat.com> Reviewed-by:
Marc Dionne <marc.dionne@auristor.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Willem de Bruijn authored
[ Upstream commit 16f6458f ] The msg_zerocopy test pins the sender and receiver threads to separate cores to reduce variance between runs. But it hardcodes the cores and skips core 0, so it fails on machines with the selected cores offline, or simply fewer cores. The test mainly gives code coverage in automated runs. The throughput of zerocopy ('-z') and non-zerocopy runs is logged for manual inspection. Continue even when sched_setaffinity fails. Just log to warn anyone interpreting the data. Fixes: 07b65c5b ("test: add msg_zerocopy test") Reported-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
Willem de Bruijn <willemb@google.com> Acked-by:
-
Hangbin Liu authored
[ Upstream commit a0dced17 ] This reverts commit 71130f29. In commit 71130f29 ("vxlan: fix tos value before xmit") we want to make sure the tos value are filtered by RT_TOS() based on RFC1349. 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | PRECEDENCE | TOS | MBZ | +-----+-----+-----+-----+-----+-----+-----+-----+ But RFC1349 has been obsoleted by RFC2474. The new DSCP field defined like 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DS FIELD, DSCP | ECN FIELD | +-----+-----+-----+-----+-----+-----+-----+-----+ So with IPTOS_TOS_MASK 0x1E RT_TOS(tos) ((tos)&IPTOS_TOS_MASK) the first 3 bits DSCP info will get lost. To take all the DSCP info in xmit, we should revert the patch and just push all tos bits to ip_tunnel_ecn_encap(), which will handling ECN field later. Fixes: 71130f29 ("vxlan: fix tos value before xmit") Signed-off-by:
Hangbin Liu <liuhangbin@gmail.com> Acked-by:
Guillaume Nault <gnault@redhat.com> Signed-off-by:
-
Peilin Ye authored
[ Upstream commit 9aba6c5b ] ovs_ct_put_key() is potentially copying uninitialized kernel stack memory into socket buffers, since the compiler may leave a 3-byte hole at the end of `struct ovs_key_ct_tuple_ipv4` and `struct ovs_key_ct_tuple_ipv6`. Fix it by initializing `orig` with memset(). Fixes: 9dd7f890 ("openvswitch: Add original direction conntrack tuple to sw_flow_key.") Suggested-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Peilin Ye <yepeilin.cs@gmail.com> Signed-off-by:
-
Xin Long authored
[ Upstream commit bab9693a ] A dead lock was triggered on thunderx driver: CPU0 CPU1 ---- ---- [01] lock(&(&nic->rx_mode_wq_lock)->rlock); [11] lock(&(&mc->mca_lock)->rlock); [12] lock(&(&nic->rx_mode_wq_lock)->rlock); [02] <Interrupt> lock(&(&mc->mca_lock)->rlock); The path for each is: [01] worker_thread() -> process_one_work() -> nicvf_set_rx_mode_task() [02] mld_ifc_timer_expire() [11] ipv6_add_dev() -> ipv6_dev_mc_inc() -> igmp6_group_added() -> [12] dev_mc_add() -> __dev_set_rx_mode() -> nicvf_set_rx_mode() To fix it, it needs to disable bh on [1], so that the timer on [2] wouldn't be triggered until rx_mode_wq_lock is released. So change to use spin_lock_bh() instead of spin_lock(). Thanks to Paolo for helping with this. v1->v2: - post to netdev. Reported-by:
Rafael P. <rparrazo@redhat.com> Tested-by:
Dean Nelson <dnelson@redhat.com> Fixes: 469998c8 ("net: thunderx: prevent concurrent data re-writing by nicvf_set_rx_mode") Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Lorenzo Bianconi authored
[ Upstream commit 622e32b7 ] The GRE tunnel can be used to transport traffic that does not rely on a Internet checksum (e.g. SCTP). The issue can be triggered creating a GRE or GRETAP tunnel and transmitting SCTP traffic ontop of it where CRC offload has been disabled. In order to fix the issue we need to recompute the GRE csum in gre_gso_segment() not relying on the inner checksum. The issue is still present when we have the CRC offload enabled. In this case we need to disable the CRC offload if we require GRE checksum since otherwise skb_checksum() will report a wrong value. Fixes: 90017acc ("sctp: Add GSO support") Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
-
Stephen Hemminger authored
[ Upstream commit 7c9864bb ] If the accelerated networking SRIOV VF device has lost carrier use the synthetic network device which is available as backup path. This is a rare case since if VF link goes down, normally the VMBus device will also loose external connectivity as well. But if the communication is between two VM's on the same host the VMBus device will still work. Reported-by:
"Shah, Ashish N" <ashish.n.shah@intel.com> Fixes: 0c195567 ("netvsc: transparent VF management") Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Reviewed-by:
Haiyang Zhang <haiyangz@microsoft.com> Signed-off-by:
-
Johan Hovold authored
[ Upstream commit ea060b35 ] Drop the bogus endpoint-lookup helper which could end up accepting interfaces based on endpoints belonging to unrelated altsettings. Note that the returned bulk pipes and interrupt endpoint descriptor were never actually used. Instead the bulk-endpoint numbers are hardcoded to 1 and 2 (matching the specification), while the interrupt- endpoint descriptor was assumed to be the third descriptor created by USB core. Try to bring some order to this by dropping the bogus lookup helper and adding the missing endpoint sanity checks while keeping the interrupt- descriptor assumption for now. Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
-
Ido Schimmel authored
[ Upstream commit b5141915 ] The commit cited below removed the RCU read-side critical section from rtnl_fdb_dump() which means that the ndo_fdb_dump() callback is invoked without RCU protection. This results in the following warning [1] in the VXLAN driver, which relied on the callback being invoked from an RCU read-side critical section. Fix this by calling rcu_read_lock() in the VXLAN driver, as already done in the bridge driver. [1] WARNING: suspicious RCU usage 5.8.0-rc4-custom-01521-g481007553ce6 #29 Not tainted ----------------------------- drivers/net/vxlan.c:1379 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by bridge/166: #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xea/0x1090 stack backtrace: CPU: 1 PID: 166 Comm: bridge Not tainted 5.8.0-rc4-custom-01521-g481007553ce6 #29 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack+0x100/0x184 lockdep_rcu_suspicious+0x153/0x15d vxlan_fdb_dump+0x51e/0x6d0 rtnl_fdb_dump+0x4dc/0xad0 netlink_dump+0x540/0x1090 __netlink_dump_start+0x695/0x950 rtnetlink_rcv_msg+0x802/0xbd0 netlink_rcv_skb+0x17a/0x480 rtnetlink_rcv+0x22/0x30 netlink_unicast+0x5ae/0x890 netlink_sendmsg+0x98a/0xf40 __sys_sendto+0x279/0x3b0 __x64_sys_sendto+0xe6/0x1a0 do_syscall_64+0x54/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fe14fa2ade0 Code: Bad RIP value. RSP: 002b:00007fff75bb5b88 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00005614b1ba0020 RCX: 00007fe14fa2ade0 RDX: 000000000000011c RSI: 00007fff75bb5b90 RDI: 0000000000000003 RBP: 00007fff75bb5b90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00005614b1b89160 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 Fixes: 5e6d2435 ("bridge: netlink dump interface at par with brctl") Signed-off-by:
Ido Schimmel <idosch@mellanox.com> Reviewed-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Landen Chao authored
[ Upstream commit 555a8933 ] in recent kernel versions there are warnings about incorrect MTU size like these: eth0: mtu greater than device maximum mtk_soc_eth 1b100000.ethernet eth0: error -22 setting MTU to include DSA overhead Fixes: bfcb8132 ("net: dsa: configure the MTU for switch ports") Fixes: 72579e14 ("net: dsa: don't fail to probe if we couldn't set the MTU") Fixes: 7a4c53be ("net: report invalid mtu value via netlink extack") Signed-off-by:
Landen Chao <landen.chao@mediatek.com> Signed-off-by:
Frank Wunderlich <frank-w@public-files.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Cong Wang authored
[ Upstream commit 8c0de6e9 ] IPV6_ADDRFORM causes resource leaks when converting an IPv6 socket to IPv4, particularly struct ipv6_ac_socklist. Similar to struct ipv6_mc_socklist, we should just close it on this path. This bug can be easily reproduced with the following C program: #include <stdio.h> #include <string.h> #include <sys/types.h> #include <sys/socket.h> #include <arpa/inet.h> int main() { int s, value; struct sockaddr_in6 addr; struct ipv6_mreq m6; s = socket(AF_INET6, SOCK_DGRAM, 0); addr.sin6_family = AF_INET6; addr.sin6_port = htons(5000); inet_pton(AF_INET6, "::ffff:192.168.122.194", &addr.sin6_addr); connect(s, (struct sockaddr *)&addr, sizeof(addr)); inet_pton(AF_INET6, "fe80::AAAA", &m6.ipv6mr_multiaddr); m6.ipv6mr_interface = 5; setsockopt(s, SOL_IPV6, IPV6_JOIN_ANYCAST, &m6, sizeof(m6)); value = AF_INET; setsockopt(s, SOL_IPV6, IPV6_ADDRFORM, &value, sizeof(value)); close(s); return 0; } Reported-by: ch3332xr@gmail.com Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by:
-
Ido Schimmel authored
[ Upstream commit 83f35228 ] fib_trie_unmerge() is called with RTNL held, but not from an RCU read-side critical section. This leads to the following warning [1] when the FIB alias list in a leaf is traversed with hlist_for_each_entry_rcu(). Since the function is always called with RTNL held and since modification of the list is protected by RTNL, simply use hlist_for_each_entry() and silence the warning. [1] WARNING: suspicious RCU usage 5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Not tainted ----------------------------- net/ipv4/fib_trie.c:1867 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by ip/164: #0: ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0 stack backtrace: CPU: 0 PID: 164 Comm: ip Not tainted 5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014 Call Trace: dump_stack+0x100/0x184 lockdep_rcu_suspicious+0x153/0x15d fib_trie_unmerge+0x608/0xdb0 fib_unmerge+0x44/0x360 fib4_rule_configure+0xc8/0xad0 fib_nl_newrule+0x37a/0x1dd0 rtnetlink_rcv_msg+0x4f7/0xbd0 netlink_rcv_skb+0x17a/0x480 rtnetlink_rcv+0x22/0x30 netlink_unicast+0x5ae/0x890 netlink_sendmsg+0x98a/0xf40 ____sys_sendmsg+0x879/0xa00 ___sys_sendmsg+0x122/0x190 __sys_sendmsg+0x103/0x1d0 __x64_sys_sendmsg+0x7d/0xb0 do_syscall_64+0x54/0xa0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7fc80a234e97 Code: Bad RIP value. RSP: 002b:00007ffef8b66798 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fc80a234e97 RDX: 0000000000000000 RSI: 00007ffef8b66800 RDI: 0000000000000003 RBP: 000000005f141b1c R08: 0000000000000001 R09: 0000000000000000 R10: 00007fc80a2a8ac0 R11: 0000000000000246 R12: 0000000000000001 R13: 0000000000000000 R14: 00007ffef8b67008 R15: 0000556fccb10020 Fixes: 0ddcf43d ("ipv4: FIB Local/MAIN table collapse") Signed-off-by:
-
Frank van der Linden authored
commit 08b5d501 upstream. set/removexattr on an exported filesystem should break NFS delegations. This is true in general, but also for the upcoming support for RFC 8726 (NFSv4 extended attribute support). Make sure that they do. Additionally, they need to grow a _locked variant, since callers might call this with i_rwsem held (like the NFS server code). Cc: stable@vger.kernel.org # v4.9+ Cc: linux-fsdevel@vger.kernel.org Cc: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
Frank van der Linden <fllinden@amazon.com> Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
-
Dexuan Cui authored
[ Upstream commit ddc9d357 ] When a Linux hv_sock app tries to connect to a Service GUID on which no host app is listening, a recent host (RS3+) sends a CHANNELMSG_TL_CONNECT_RESULT (23) message to Linux and this triggers such a warning: unknown msgtype=23 WARNING: CPU: 2 PID: 0 at drivers/hv/vmbus_drv.c:1031 vmbus_on_msg_dpc Actually Linux can safely ignore the message because the Linux app's connect() will time out in 2 seconds: see VSOCK_DEFAULT_CONNECT_TIMEOUT and vsock_stream_connect(). We don't bother to make use of the message because: 1) it's only supported on recent hosts; 2) a non-trivial effort is required to use the message in Linux, but the benefit is small. So, let's not see the warning by silently ignoring the message. Signed-off-by:
Dexuan Cui <decui@microsoft.com> Reviewed-by:
Michael Kelley <mikelley@microsoft.com> Signed-off-by:
-
