Update STLinux v4.1.0 #6
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
[ Upstream commit 8f89e33 ] The device supports negative values as well. Fixes: 3a89b28 ("iio: adc: add support for mcp3911") Signed-off-by: Marcus Folkesson <marcus.folkesson@gmail.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Link: https://lore.kernel.org/r/20220722130726.7627-2-marcus.folkesson@gmail.com Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 583585e ] Fix one kernel NULL pointer dereference as below: [ 224.462334] Call Trace: [ 224.462394] __tcp_bpf_recvmsg+0xd3/0x380 [ 224.462441] ? sock_has_perm+0x78/0xa0 [ 224.462463] tcp_bpf_recvmsg+0x12e/0x220 [ 224.462494] inet_recvmsg+0x5b/0xd0 [ 224.462534] __sys_recvfrom+0xc8/0x130 [ 224.462574] ? syscall_trace_enter+0x1df/0x2e0 [ 224.462606] ? __do_page_fault+0x2de/0x500 [ 224.462635] __x64_sys_recvfrom+0x24/0x30 [ 224.462660] do_syscall_64+0x5d/0x1d0 [ 224.462709] entry_SYSCALL_64_after_hwframe+0x65/0xca In commit 9974d37 ("skmsg: Fix invalid last sg check in sk_msg_recvmsg()"), we change last sg check to sg_is_last(), but in sockmap redirection case (without stream_parser/stream_verdict/ skb_verdict), we did not mark the end of the scatterlist. Check the sk_msg_alloc, sk_msg_page_add, and bpf_msg_push_data functions, they all do not mark the end of sg. They are expected to use sg.end for end judgment. So the judgment of '(i != msg_rx->sg.end)' is added back here. Fixes: 9974d37 ("skmsg: Fix invalid last sg check in sk_msg_recvmsg()") Signed-off-by: Liu Jian <liujian56@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: John Fastabend <john.fastabend@gmail.com> Acked-by: Jakub Sitnicki <jakub@cloudflare.com> Link: https://lore.kernel.org/bpf/20220809094915.150391-1-liujian56@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 14b20b7 ] The verifier cannot perform sufficient validation of any pointers passed into bpf_attr and treats them as integers rather than pointers. The helper will then read from arbitrary pointers passed into it. Restrict the helper to CAP_PERFMON since the security model in BPF of arbitrary kernel read is CAP_BPF + CAP_PERFMON. Fixes: af2ac3e ("bpf: Prepare bpf syscall to be used from kernel and user space.") Signed-off-by: YiFei Zhu <zhuyifei@google.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Alexei Starovoitov <ast@kernel.org> Link: https://lore.kernel.org/bpf/20220816205517.682470-1-zhuyifei@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7d6620f ] Syzkaller reported a triggered kernel BUG as follows: ------------[ cut here ]------------ kernel BUG at kernel/bpf/cgroup.c:925! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 194 Comm: detach Not tainted 5.19.0-14184-g69dac8e431af #8 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:__cgroup_bpf_detach+0x1f2/0x2a0 Code: 00 e8 92 60 30 00 84 c0 75 d8 4c 89 e0 31 f6 85 f6 74 19 42 f6 84 28 48 05 00 00 02 75 0e 48 8b 80 c0 00 00 00 48 85 c0 75 e5 <0f> 0b 48 8b 0c5 RSP: 0018:ffffc9000055bdb0 EFLAGS: 00000246 RAX: 0000000000000000 RBX: ffff888100ec0800 RCX: ffffc900000f1000 RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888100ec4578 RBP: 0000000000000000 R08: ffff888100ec0800 R09: 0000000000000040 R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100ec4000 R13: 000000000000000d R14: ffffc90000199000 R15: ffff888100effb00 FS: 00007f68213d2b80(0000) GS:ffff88813bc80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055f74a0e5850 CR3: 0000000102836000 CR4: 00000000000006e0 Call Trace: <TASK> cgroup_bpf_prog_detach+0xcc/0x100 __sys_bpf+0x2273/0x2a00 __x64_sys_bpf+0x17/0x20 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7f68214dbcb9 Code: 08 44 89 e0 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff8 RSP: 002b:00007ffeb487db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 00007f68214dbcb9 RDX: 0000000000000090 RSI: 00007ffeb487db70 RDI: 0000000000000009 RBP: 0000000000000003 R08: 0000000000000012 R09: 0000000b00000003 R10: 00007ffeb487db70 R11: 0000000000000246 R12: 00007ffeb487dc20 R13: 0000000000000004 R14: 0000000000000001 R15: 000055f74a1011b0 </TASK> Modules linked in: ---[ end trace 0000000000000000 ]--- Repetition steps: For the following cgroup tree, root | cg1 | cg2 1. attach prog2 to cg2, and then attach prog1 to cg1, both bpf progs attach type is NONE or OVERRIDE. 2. write 1 to /proc/thread-self/fail-nth for failslab. 3. detach prog1 for cg1, and then kernel BUG occur. Failslab injection will cause kmalloc fail and fall back to purge_effective_progs. The problem is that cg2 have attached another prog, so when go through cg2 layer, iteration will add pos to 1, and subsequent operations will be skipped by the following condition, and cg will meet NULL in the end. `if (pos && !(cg->bpf.flags[atype] & BPF_F_ALLOW_MULTI))` The NULL cg means no link or prog match, this is as expected, and it's not a bug. So here just skip the no match situation. Fixes: 4c46091 ("bpf: Fix KASAN use-after-free Read in compute_effective_progs") Signed-off-by: Pu Lehui <pulehui@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20220813134030.1972696-1-pulehui@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit afe7116 ] There is a possible race condition (use-after-free) like below (FREE) | (USE) adf7242_remove | adf7242_channel cancel_delayed_work_sync | destroy_workqueue (1) | adf7242_cmd_rx | mod_delayed_work (2) | The root cause for this race is that the upper layer (ieee802154) is unaware of this detaching event and the function adf7242_channel can be called without any checks. To fix this, we can add a flag write at the beginning of adf7242_remove and add flag check in adf7242_channel. Or we can just defer the destructive operation like other commit 3e0588c ("hamradio: defer ax25 kfree after unregister_netdev") which let the ieee802154_unregister_hw() to handle the synchronization. This patch takes the second option. Fixes: 58e9683 ("net: ieee802154: adf7242: Fix OCL calibration runs") Signed-off-by: Lin Ma <linma@zju.edu.cn> Acked-by: Michael Hennerich <michael.hennerich@analog.com> Link: https://lore.kernel.org/r/20220808034224.12642-1-linma@zju.edu.cn Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6cc42fb ] In a long overdue refactoring, split out backlight code to new intel_backlight.[ch]. Simple code movement, leave renames for follow-up work. No functional changes. Cc: Lyude Paul <lyude@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/97d310848f03061473b9b2328e2c5c4dcf263cfa.1629888677.git.jani.nikula@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 868e8e5 ] Commit 20f85ef ("drm/i915/backlight: use unique backlight device names") added support for multiple backlight devices on dual panel systems, but did so with error handling on -EEXIST from backlight_device_register(). Unfortunately, that triggered a warning in dmesg all the way down from sysfs_add_file_mode_ns() and sysfs_warn_dup(). Instead of optimistically always attempting to register with the default name ("intel_backlight", which we have to retain for backward compatibility), check if a backlight device with the name exists first, and, if so, use the card and connector based name. v2: reworked on top of the patch commit 20f85ef ("drm/i915/backlight: use unique backlight device names") v3: fixed the ref count leak(Jani N) Fixes: 20f85ef ("drm/i915/backlight: use unique backlight device names") Signed-off-by: Arun R Murthy <arun.r.murthy@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220808035750.3111046-1-arun.r.murthy@intel.com (cherry picked from commit 4234ea3) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6376ab0 ] The module and function information can be added with 'modprobe foo dyndbg=+pmf' Suggested-by: Greg KH <gregkh@linuxfoundation.org> Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Bard Liao <yung-chuan.liao@linux.intel.com> Link: https://lore.kernel.org/r/20220616220559.136160-1-pierre-louis.bossart@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2e6481a ] The struct nhlt_format's fmt_config is a flexible array, it must not be used as normal array. When moving to the next nhlt_fmt_cfg we need to take into account the data behind the ->config.caps (indicated by ->config.size). Fixes: a864e8f ("ALSA: hda: intel-nhlt: verify config type") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Reviewed-by: Jaska Uimonen <jaska.uimonen@linux.intel.com> Link: https://lore.kernel.org/r/20220823122405.18464-1-peter.ujfalusi@linux.intel.com Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit d776763 ] The return type is supposed to be ssize_t, which is signed long, but "r" was declared as unsigned int. This means that on 64 bit systems we return positive values instead of negative error codes. Fixes: 80a3511 ("cfg80211: add debugfs HT40 allow map") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/YutvOQeJm0UjLhwU@kili Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8531aa1 ] This reverts commit 83810f8. Turning off port power in shutdown did cause issues such as a laptop not proprly powering off, and some specific usb devies failing to enumerate the subsequent boot after a warm reset. So revert this. Fixes: 83810f8 ("xhci: turn off port power in shutdown") Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20220825150840.132216-4-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7498a45 ] Packets that are not of length divisible by 4 (e.g. 77, 78, 79) would have the checksum included up to next multiple of 4 (a 77 bytes packet would have 3 bytes of ethernet checksum included). The check for the value expects it in host (Little) endian. Fixes: f3cad26 ("net: sparx5: add hostmode with phylink support") Signed-off-by: Casper Andersson <casper.casan@gmail.com> Reviewed-by: Steen Hegelund <Steen.Hegelund@microchip.com> Link: https://lore.kernel.org/r/20220825084955.684637-1-casper.casan@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3ce9f2b ] Commit 744d23c ("net: phy: Warn about incorrect mdio_bus_phy_resume() state") unveiled that the smsc911x driver was not properly stopping and restarting the PHY during suspend/resume. Correct that by indicating that the MAC is in charge of PHY PM operations and ensure that all MDIO bus activity is quiescent during suspend. Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Fixes: fba863b ("net: phy: make PHY PM ops a no-op if MAC driver manages PHY PM") Fixes: 2aa70f8 ("net: smsc911x: Quieten netif during suspend") Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20220825023951.3220-1-f.fainelli@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a87406f ] ovs_dp_cmd_new()->ovs_dp_change()->ovs_dp_set_upcall_portids() allocates array via kmalloc. If for some reason new_vport() fails during ovs_dp_cmd_new() dp->upcall_portids must be freed. Add missing kfree. Kmemleak example: unreferenced object 0xffff88800c382500 (size 64): comm "dump_state", pid 323, jiffies 4294955418 (age 104.347s) hex dump (first 32 bytes): 5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff ^.y..z8..!8..... 03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00 ............(... backtrace: [<0000000071bebc9f>] ovs_dp_set_upcall_portids+0x38/0xa0 [<000000000187d8bd>] ovs_dp_change+0x63/0xe0 [<000000002397e446>] ovs_dp_cmd_new+0x1f0/0x380 [<00000000aa06f36e>] genl_family_rcv_msg_doit+0xea/0x150 [<000000008f583bc4>] genl_rcv_msg+0xdc/0x1e0 [<00000000fa10e377>] netlink_rcv_skb+0x50/0x100 [<000000004959cece>] genl_rcv+0x24/0x40 [<000000004699ac7f>] netlink_unicast+0x23e/0x360 [<00000000c153573e>] netlink_sendmsg+0x24e/0x4b0 [<000000006f4aa380>] sock_sendmsg+0x62/0x70 [<00000000d0068654>] ____sys_sendmsg+0x230/0x270 [<0000000012dacf7d>] ___sys_sendmsg+0x88/0xd0 [<0000000011776020>] __sys_sendmsg+0x59/0xa0 [<000000002e8f2dc1>] do_syscall_64+0x3b/0x90 [<000000003243e7cb>] entry_SYSCALL_64_after_hwframe+0x63/0xcd Fixes: b83d23a ("openvswitch: Introduce per-cpu upcall dispatch") Acked-by: Aaron Conole <aconole@redhat.com> Signed-off-by: Andrey Zhadchenko <andrey.zhadchenko@virtuozzo.com> Link: https://lore.kernel.org/r/20220825020326.664073-1-andrey.zhadchenko@virtuozzo.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3f8ae9f ] xrs700x_read_port_counters() updates the stats from a worker using the u64_stats_update_begin() version. This is okay on 32-UP since on the reader side preemption is disabled. On 32bit-SMP the writer can be preempted by the reader at which point the reader will spin on the seqcount until writer continues and completes the update. Assigning the mib_mutex mutex to the underlying seqcount would ensure proper synchronisation. The API for that on the u64_stats_init() side isn't available. Since it is the only user, just use disable interrupts during the update. Use u64_stats_update_begin_irqsave() on the writer side to ensure an uninterrupted update. Fixes: ee00b24 ("net: dsa: add Arrow SpeedChips XRS700x driver") Cc: Andrew Lunn <andrew@lunn.ch> Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: George McCollister <george.mccollister@gmail.com> Cc: Vivien Didelot <vivien.didelot@gmail.com> Cc: Vladimir Oltean <olteanv@gmail.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Acked-by: George McCollister <george.mccollister@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b05972f ] The issue is the same to commit c2999f7 ("net: sched: multiq: don't call qdisc_put() while holding tree lock"). Qdiscs call qdisc_put() while holding sch tree spinlock, which results sleeping-while-atomic BUG. Fixes: c266f64 ("net: sched: protect block state with mutex") Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com> Link: https://lore.kernel.org/r/20220826013930.340121-1-shaozhengchao@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f612466 ] In attach_default_qdiscs(), if a dev has multiple queues and queue 0 fails to attach qdisc because there is no memory in attach_one_default_qdisc(). Then dev->qdisc will be noop_qdisc by default. But the other queues may be able to successfully attach to default qdisc. In this case, the fallback to noqueue process will be triggered. If the original attached qdisc is not released and a new one is directly attached, this will cause netdevice reference leaks. The following is the bug log: veth0: default qdisc (fq_codel) fail, fallback to noqueue unregister_netdevice: waiting for veth0 to become free. Usage count = 32 leaked reference. qdisc_alloc+0x12e/0x210 qdisc_create_dflt+0x62/0x140 attach_one_default_qdisc.constprop.41+0x44/0x70 dev_activate+0x128/0x290 __dev_open+0x12a/0x190 __dev_change_flags+0x1a2/0x1f0 dev_change_flags+0x23/0x60 do_setlink+0x332/0x1150 __rtnl_newlink+0x52f/0x8e0 rtnl_newlink+0x43/0x70 rtnetlink_rcv_msg+0x140/0x3b0 netlink_rcv_skb+0x50/0x100 netlink_unicast+0x1bb/0x290 netlink_sendmsg+0x37c/0x4e0 sock_sendmsg+0x5f/0x70 ____sys_sendmsg+0x208/0x280 Fix this bug by clearing any non-noop qdiscs that may have been assigned before trying to re-attach. Fixes: bf6dba7 ("net: sched: fallback to qdisc noqueue if default qdisc setup fail") Signed-off-by: Wang Hai <wanghai38@huawei.com> Link: https://lore.kernel.org/r/20220826090055.24424-1-wanghai38@huawei.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c0955bf ] The function neigh_timer_handler() is a timer handler that runs in an atomic context. When used by rocker, neigh_timer_handler() calls "kzalloc(.., GFP_KERNEL)" that may sleep. As a result, the sleep in atomic context bug will happen. One of the processes is shown below: ofdpa_fib4_add() ... neigh_add_timer() (wait a timer) neigh_timer_handler() neigh_release() neigh_destroy() rocker_port_neigh_destroy() rocker_world_port_neigh_destroy() ofdpa_port_neigh_destroy() ofdpa_port_ipv4_neigh() kzalloc(sizeof(.., GFP_KERNEL) //may sleep This patch changes the gfp_t parameter of kzalloc() from GFP_KERNEL to GFP_ATOMIC in order to mitigate the bug. Fixes: 00fc0c5 ("rocker: Change world_ops API and implementation to be switchdev independant") Signed-off-by: Duoming Zhou <duoming@zju.edu.cn> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3a1a274 ] This patch adds logic to compute the MDIO period based on the i1clk, and thereafter write the MDIO period into the YU MDIO config register. The i1clk resource from the ACPI table is used to provide addressing to YU bootrecord PLL registers. The values in these registers are used to compute MDIO period. If the i1clk resource is not present in the ACPI table, then the current default hardcorded value of 430Mhz is used. The i1clk clock value of 430MHz is only accurate for boards with BF2 mid bin and main bin SoCs. The BF2 high bin SoCs have i1clk = 500MHz, but can support a slower MDIO period. Fixes: f92e186 ("Add Mellanox BlueField Gigabit Ethernet driver") Reviewed-by: Asmaa Mnebhi <asmaa@nvidia.com> Signed-off-by: David Thompson <davthompson@nvidia.com> Link: https://lore.kernel.org/r/20220826155916.12491-1-davthompson@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8fc29ff ] strp_init() is called just a few lines above this csk->sk_user_data check, it also initializes strp->work etc., therefore, it is unnecessary to call strp_done() to cancel the freshly initialized work. And if sk_user_data is already used by KCM, psock->strp should not be touched, particularly strp->work state, so we need to move strp_init() after the csk->sk_user_data check. This also makes a lockdep warning reported by syzbot go away. Reported-and-tested-by: syzbot+9fc084a4348493ef65d2@syzkaller.appspotmail.com Reported-by: syzbot+e696806ef96cdd2d87cd@syzkaller.appspotmail.com Fixes: e557124 ("kcm: Check if sk_user_data already set in kcm_attach") Fixes: dff8baa ("kcm: Call strp_stop before strp_done in kcm_attach") Cc: Tom Herbert <tom@herbertland.com> Signed-off-by: Cong Wang <cong.wang@bytedance.com> Link: https://lore.kernel.org/r/20220827181314.193710-1-xiyou.wangcong@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 90fabae ] When the GSO splitting feature of sch_cake is enabled, GSO superpackets will be broken up and the resulting segments enqueued in place of the original skb. In this case, CAKE calls consume_skb() on the original skb, but still returns NET_XMIT_SUCCESS. This can confuse parent qdiscs into assuming the original skb still exists, when it really has been freed. Fix this by adding the __NET_XMIT_STOLEN flag to the return value in this case. Fixes: 0c85034 ("sch_cake: Conditionally split GSO segments") Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> Reported-by: zdi-disclosures@trendmicro.com # ZDI-CAN-18231 Link: https://lore.kernel.org/r/20220831092103.442868-1-toke@toke.dk Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8c70521 ] challenge_timestamp can be read an written by concurrent threads. This was expected, but we need to annotate the race to avoid potential issues. Following patch moves challenge_timestamp and challenge_count to per-netns storage to provide better isolation. Fixes: 354e4aa ("tcp: RFC 5961 5.2 Blind Data Injection Attack Mitigation") Reported-by: syzbot <syzkaller@googlegroups.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0b4f688 ] This reverts commit 90fabae. Patch was applied hastily, revert and let the v2 be reviewed. Fixes: 90fabae ("sch_cake: Return __NET_XMIT_STOLEN when consuming enqueued skb") Link: https://lore.kernel.org/all/87wnao2ha3.fsf@toke.dk/ Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a8424a9 ] For passive connections, the refcount increment has been done in smc_clcsock_accept()-->smc_sock_alloc(). Fixes: 3b2dec2 ("net/smc: restructure client and server code in af_smc") Signed-off-by: Yacan Liu <liuyacan@corp.netease.com> Reviewed-by: Tony Lu <tonylu@linux.alibaba.com> Link: https://lore.kernel.org/r/20220830152314.838736-1-liuyacan@corp.netease.com Signed-off-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4ef3f2a ] This patch updates device status array range from 11 to 12 as we will be reading status from device number 0 to device number 11 inclusive. Without this patch we can potentially access status array out of range during auto-enumeration. Fixes: aa1262c ("soundwire: qcom: Check device status before reading devid") Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220708104747.8722-1-srinivas.kandagatla@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 846651e upstream. The setting of RS485 RTS polarity is inverse in the current driver. When the property of 'rs485-rts-active-low' is enabled in the dts node, the RTS signal should be LOW during sending. Otherwise, if there is no such a property, the RTS should be HIGH during sending. Fixes: 03895cf ("tty: serial: fsl_lpuart: Add support for RS-485") Cc: stable <stable@kernel.org> Signed-off-by: Nicolas Diaz <nicolas.diaz@nxp.com> Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com> Link: https://lore.kernel.org/r/20220805144529.604856-1-shenwei.wang@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e230a44 upstream. _Read/Write_MACREG callbacks are NULL so the read/write_macreg_hdl() functions don't do anything except free the "pcmd" pointer. It results in a use after free. Delete them. Fixes: 2865d42 ("staging: r8712u: Add the new driver to the mainline kernel") Cc: stable <stable@kernel.org> Reported-by: Zheng Wang <hackerzheng666@gmail.com> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Link: https://lore.kernel.org/r/Yw4ASqkYcUhUfoY2@kili Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b2fa9e1 upstream. The old rtl8188eu module, removed in commit 55dfa29 ("staging: rtl8188eu: remove rtl8188eu driver from staging dir") (Linux kernel v5.15-rc1), required (through a MODULE_FIRMWARE call()) the rtlwifi/rtl8188eufw.bin firmware file, which the new r8188eu driver no longer requires. I have tested a few RTL8188EUS-based Wi-Fi cards and, while supported by both drivers, they do not work when using the new one and the firmware wasn't manually loaded. According to Larry Finger, the module maintainer, all such cards need the firmware and the driver should depend on it (see the linked mails). Add a proper MODULE_FIRMWARE() call, like it was done in the old driver. Thanks to Greg Kroah-Hartman and Larry Finger for quick responses to my questions. Cc: stable <stable@kernel.org> Link: https://answers.launchpad.net/ubuntu/+source/linux-meta-hwe-5.15/+question/702611 Link: https://lore.kernel.org/lkml/YukkBu3TNODO3or9@nx64de-df6d00/ Signed-off-by: Grzegorz Szymaszek <gszymaszek@short.pl> Link: https://lore.kernel.org/r/YulcdKfhA8dPQ78s@nx64de-df6d00 Acked-by: Phillip Potter <phil@philpotter.co.uk> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c7acee3 upstream. Christophe Leroy reported that commit 7b45371 ("kbuild: link symbol CRCs at final link, removing CONFIG_MODULE_REL_CRCS") broke mpc85xx_defconfig + CONFIG_RELOCATABLE=y. LD vmlinux SYSMAP System.map SORTTAB vmlinux CHKREL vmlinux WARNING: 451 bad relocations c0b312a9 R_PPC_UADDR32 .head.text-0x3ff9ed54 c0b312ad R_PPC_UADDR32 .head.text-0x3ffac224 c0b312b1 R_PPC_UADDR32 .head.text-0x3ffb09f4 c0b312b5 R_PPC_UADDR32 .head.text-0x3fe184dc c0b312b9 R_PPC_UADDR32 .head.text-0x3fe183a8 ... The compiler emits a bunch of R_PPC_UADDR32, which is not supported by arch/powerpc/kernel/reloc_32.S. The reason is there exists an unaligned symbol. $ powerpc-linux-gnu-nm -n vmlinux ... c0b31258 d spe_aligninfo c0b31298 d __func__.0 c0b312a9 D sys_call_table c0b319b8 d __func__.0 Commit 7b45371 is not the root cause. Even before that, I can reproduce the same issue for mpc85xx_defconfig + CONFIG_RELOCATABLE=y + CONFIG_MODVERSIONS=n. It is just that nobody noticed because when CONFIG_MODVERSIONS is enabled, a __crc_* symbol inserted before sys_call_table was hiding the unalignment issue. Adding alignment to the syscall table for ppc32 fixes the issue. Cc: stable@vger.kernel.org Reported-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Christophe Leroy <christophe.leroy@csgroup.eu> [mpe: Trim change log discussion, add Cc stable] Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/lkml/38605f6a-a568-f884-f06f-ea4da5b214f0@csgroup.eu/ Link: https://lore.kernel.org/r/20220820165129.1147589-1-masahiroy@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 566f9c9 upstream. When changing the console font with ioctl(KDFONTOP) the new font size can be bigger than the previous font. A previous selection may thus now be outside of the new screen size and thus trigger out-of-bounds accesses to graphics memory if the selection is removed in vc_do_resize(). Prevent such out-of-memory accesses by dropping the selection before the various con_font_set() console handlers are called. Reported-by: syzbot+14b0e8f3fd1612e35350@syzkaller.appspotmail.com Cc: stable <stable@kernel.org> Tested-by: Khalid Masum <khalid.masum.92@gmail.com> Signed-off-by: Helge Deller <deller@gmx.de> Link: https://lore.kernel.org/r/YuV9apZGNmGfjcor@p100 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
When the "wakeup-source" flag is found, I2C core marks the device as wakeup capable and enables the wakeup by default. Up to now, choice was being made to disable the wakeup by default. Goal was to simplify the user application, to be able to reach lowest possible power state by default (standby) on stm32mp135f-dk board. User had to specifically re-enable the type-c wakeup if needed. Since the PWR IRQ and wakeup capability is now implemented by the secure and non-secure side, the standby mode can be reached by default. So, remove earlier limitation, which was hacky behing "ucsi" and "psy" frameworks. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Change-Id: If2593b0d440c97d1e0cbe9da435f17b6e63da547 Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/265107 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: Alexandre TORGUE <alexandre.torgue@foss.st.com>
The "Get Current Connector Alternate Mode" command is optional. The PPM will set the "Not Supported Indicator" flag in the command status, if it isn't supported (-EOPNOTSUPP error is reported by ucsi_exec_command()). As this command is optional, this case shouldn't be treated as an error: - Improve the error message to display the error code. - Turn the not supported case into a dev_dbg instead of a dev_err. Note: This error message is no longer seen upstream, after: commit b9aa02c ("usb: typec: ucsi: Add polling mechanism for partner tasks like alt mode checking") Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Change-Id: Id7fcb5477775b90508790064d0572d310e5db5e8 Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/265182 Reviewed-by: Amelie DELAUNAY <amelie.delaunay@foss.st.com>
Add support of break control routine to stm32 serial driver. Signed-off-by: Erwan Le Ray <erwan.leray@foss.st.com> Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Change-Id: I745f35b4c0b8807d018e5a7ab339140873ea33e0 Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/264710 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Amelie DELAUNAY <amelie.delaunay@foss.st.com>
NOT_UPSTREAMABLE This commit adds new files to be able to run either Linux examples or M4 examples on DK1 board. Change-Id: Ic7db64f7b53d3da093cb91843b17087dba3b697a Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/266074 Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com>
The irq handling is currently split between the irq handler and the threaded irq handler. Some of the handling (such as dma related stuffs) done within the irq handler might sleep or take some time leading to issues if the kernel is built with realtime constraints. In order to fix that, perform an overall rework to perform most of the job within the threaded handler and only keep fifo access in the non threaded handler. Change-Id: I24740c22cacdd143b7036689de1f18353bfa9edb Signed-off-by: Alain Volmat <alain.volmat@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/265551 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Amelie DELAUNAY <amelie.delaunay@foss.st.com>
NOT_UPSTREAMABLE only avoid verbose message for valid purpose. And found why in some cases this warning is displayed (almost 80% of cases) Signed-off-by: Christophe Roullier <christophe.roullier@st.com> Change-Id: I3c6865ebddd2d6954832c352d538e9ea94ad35a0 Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/266290 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com>
Add passive cooling to the CPU of stm32mp13. Limit the CPU frequency to step 1 in case of temperatur over 95 degrees. Signed-off-by: Pascal Paillet <p.paillet@st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/266081 Change-Id: Ia0c3a93199255e83da8eaa193a0fbd01983ddd98
Avoid usage of __func__ when reporting an error message since dev_err or dev_dbg is already providing enough details to identify the source of the message. Change-Id: I84898f71890cf690bcd64b0f74524127d501f2c9 Signed-off-by: Alain VOLMAT <alain.volmat@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/230599 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: Amelie DELAUNAY <amelie.delaunay@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/266177 Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com>
Add new 157d-dk1 A7 and M4 examples. Change-Id: I77b158c62f4a8c3503a2ca0d695e39540228f3d4 Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/266077 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com>
STM32MP13 DK with non-crypto SoC won't be produced. Remove its support. Change-Id: Ide4ee02eb58a1622f3a9200bd425f2fa58af518a Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/266807 Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com>
…sitory Add contributing guide to STMicroelectronics/linux repository. Change-Id: Iab6814410323b74633d6146052557fe2ff438423 Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/269088 Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com>
Add security guide to STMicroelectronics/linux repository. Change-Id: I870e05acc5cc61e873dadef0428e551946159868 Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/269089 Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com>
The oversampling ratio is shared by all channels, no matter the type (e.g. single ended or differential). Currently two attributes are declared for each type: - in_voltage-voltage_oversampling_ratio in_voltage-voltage_oversampling_ratio_available - in_voltage_oversampling_ratio in_voltage_oversampling_ratio_available Use the "info_mask_shared_by_all" instead of "info_mask_shared_by_type". Initial value reported after probe is '0' which isn't a valid ratio. (it should be at least 1 by default, e.g. no oversampling). Fix it by storing the oversampling index in the array, instead of its value in adc struct. This fixes the initial condition. Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com> Change-Id: Ibb015e32522be01b94d05fd01896ad77fbc31540 Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/269087 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Olivier MOYSAN <olivier.moysan@foss.st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com>
Both instances ethernet based on GMAC SNPS IP on stm32mp13, Ethernet1 is on RMII mode with quartz Ethernet2 is on RMII mode without quartz Signed-off-by: Christophe Roullier <christophe.roullier@st.com> Change-Id: I2d1a85ecbcd2cd25dbedaf995b86c3e02a7b0c40 Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/268924 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com> Domain-Review: Alexandre TORGUE <alexandre.torgue@foss.st.com>
This command execute and assert + reset delay + deassert + check if deassert is ok. In a driver we can replace these lines reset_control_assert(reset); reset_control_deassert(reset); by reset_control_reset(reset); Change-Id: I7852084b78a641ae1ff7e1c7c954af0d3b2e1538 Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/234580 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: Alexandre TORGUE <alexandre.torgue@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/269014 Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com> Domain-Review: Alexandre TORGUE <alexandre.torgue@foss.st.com>
Add reset timing in match data structure for MP13. Change-Id: Ie0138deff786900dc97f781a97a1ce8a2ab00399 Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/269015 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com> Domain-Review: Alexandre TORGUE <alexandre.torgue@foss.st.com>
Add SPI1, SPI2, SPI3, SPI4, SPI5 bus clocks. Change-Id: I55049c3a27d3698cf300fd86f5691161684b94ce Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/271637 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com> Domain-Review: Alexandre TORGUE <alexandre.torgue@foss.st.com>
These clocks are needed for I2S. Change-Id: I3b8e50cf54e7725435ebc2f6341835a2e970b84f Signed-off-by: Gabriel Fernandez <gabriel.fernandez@foss.st.com> Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/271638 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com> Domain-Review: Alexandre TORGUE <alexandre.torgue@foss.st.com>
The code lacks clearing of previous DEAT/DEDT values. Thus, changing values on the fly results in garbage delays tending towards the maximum value as more and more bits are ORed together. (Leaving RS485 mode would have cleared the old values though). Fixes: 1bcda09 ("serial: stm32: add support for RS485 hardware control mode") Cc: stable@kernel.org Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Link: https://lore.kernel.org/r/20220627150753.34510-1-ilpo.jarvinen@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Change-Id: I2f1f2c0675180f65c524948a9103d03abf8f4ee8 Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/272029 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com> Domain-Review: Amelie DELAUNAY <amelie.delaunay@foss.st.com>
Add stm32_pctrl_get_desc_pin_from_gpio function to find a stm32 pin descriptor which is matching with a gpio. Most of the time pin number is equal to pin index in array. So the first part of the function is useful to speed up. And during gpio bank register, we set default gpio names with pin names. Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Change-Id: I4bf65ae77cc3f01d2e81c3944d3be69f00f70aff Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/271696 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Antonio Maria BORNEO <antonio.borneo@st.com> Reviewed-by: Amelie DELAUNAY <amelie.delaunay@foss.st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com> Domain-Review: Amelie DELAUNAY <amelie.delaunay@foss.st.com>
Some GPIO providers set names for GPIO lines that match the names of the pins on the SoC, or variations on that theme. These names are generic more often that not, such as pioC12 in the at91 case. These generic names block the possibility to set more useful GPIO line names with device properties (i.e. gpio-line-names). Allow overriding a generic name given by the GPIO driver if there is a name given to the GPIO line using device properties, but leave the generic name alone if no better name is available. However, there is a risk. If user space is depending on the above mentioned fixed GPIO names, AND there are device properties that previously did not reach the surface, the name change might cause regressions. But hopefully this stays below the radar... Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Tested-by: Alexander Dahl <ada@thorsis.com> Signed-off-by: Peter Rosin <peda@axentia.se> Signed-off-by: Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by: Valentin Caron <valentin.caron@foss.st.com> Change-Id: I26f7f2e1dcc49a7496da0d36ee526a4594189890 Reviewed-on: https://gerrit.st.com/c/mpu/oe/st/linux-stm32/+/271951 Reviewed-by: CITOOLS <MDG-smet-aci-reviews@list.st.com> Reviewed-by: CIBUILD <MDG-smet-aci-builds@list.st.com> Reviewed-by: Amelie DELAUNAY <amelie.delaunay@foss.st.com> Reviewed-by: Antonio Maria BORNEO <antonio.borneo@st.com> Reviewed-by: Eric FOURMONT <eric.fourmont-ext@st.com> Domain-Review: Amelie DELAUNAY <amelie.delaunay@foss.st.com>
mcarlin-ds
pushed a commit
that referenced
this pull request
Apr 18, 2023
commit 60eed1e upstream. code path: ocfs2_ioctl_move_extents ocfs2_move_extents ocfs2_defrag_extent __ocfs2_move_extent + ocfs2_journal_access_di + ocfs2_split_extent //sub-paths call jbd2_journal_restart + ocfs2_journal_dirty //crash by jbs2 ASSERT crash stacks: PID: 11297 TASK: ffff974a676dcd00 CPU: 67 COMMAND: "defragfs.ocfs2" #0 [ffffb25d8dad3900] machine_kexec at ffffffff8386fe01 #1 [ffffb25d8dad3958] __crash_kexec at ffffffff8395959d #2 [ffffb25d8dad3a20] crash_kexec at ffffffff8395a45d #3 [ffffb25d8dad3a38] oops_end at ffffffff83836d3f #4 [ffffb25d8dad3a58] do_trap at ffffffff83833205 #5 [ffffb25d8dad3aa0] do_invalid_op at ffffffff83833aa6 #6 [ffffb25d8dad3ac0] invalid_op at ffffffff84200d18 [exception RIP: jbd2_journal_dirty_metadata+0x2ba] RIP: ffffffffc09ca54a RSP: ffffb25d8dad3b70 RFLAGS: 00010207 RAX: 0000000000000000 RBX: ffff9706eedc5248 RCX: 0000000000000000 RDX: 0000000000000001 RSI: ffff97337029ea28 RDI: ffff9706eedc5250 RBP: ffff9703c3520200 R8: 000000000f46b0b2 R9: 0000000000000000 R10: 0000000000000001 R11: 00000001000000fe R12: ffff97337029ea28 R13: 0000000000000000 R14: ffff9703de59bf60 R15: ffff9706eedc5250 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 #7 [ffffb25d8dad3ba8] ocfs2_journal_dirty at ffffffffc137fb95 [ocfs2] #8 [ffffb25d8dad3be8] __ocfs2_move_extent at ffffffffc139a950 [ocfs2] #9 [ffffb25d8dad3c80] ocfs2_defrag_extent at ffffffffc139b2d2 [ocfs2] Analysis This bug has the same root cause of 'commit 7f27ec9 ("ocfs2: call ocfs2_journal_access_di() before ocfs2_journal_dirty() in ocfs2_write_end_nolock()")'. For this bug, jbd2_journal_restart() is called by ocfs2_split_extent() during defragmenting. How to fix For ocfs2_split_extent() can handle journal operations totally by itself. Caller doesn't need to call journal access/dirty pair, and caller only needs to call journal start/stop pair. The fix method is to remove journal access/dirty from __ocfs2_move_extent(). The discussion for this patch: https://oss.oracle.com/pipermail/ocfs2-devel/2023-February/000647.html Link: https://lkml.kernel.org/r/20230217003717.32469-1-heming.zhao@suse.com Signed-off-by: Heming Zhao <heming.zhao@suse.com> Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com> Cc: Mark Fasheh <mark@fasheh.com> Cc: Joel Becker <jlbec@evilplan.org> Cc: Junxiao Bi <junxiao.bi@oracle.com> Cc: Changwei Ge <gechangwei@live.cn> Cc: Gang He <ghe@suse.com> Cc: Jun Piao <piaojun@huawei.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mcarlin-ds
pushed a commit
that referenced
this pull request
Apr 18, 2023
[ Upstream commit 4e264be ] When a system with E810 with existing VFs gets rebooted the following hang may be observed. Pid 1 is hung in iavf_remove(), part of a network driver: PID: 1 TASK: ffff965400e5a340 CPU: 24 COMMAND: "systemd-shutdow" #0 [ffffaad04005fa50] __schedule at ffffffff8b3239cb #1 [ffffaad04005fae8] schedule at ffffffff8b323e2d #2 [ffffaad04005fb00] schedule_hrtimeout_range_clock at ffffffff8b32cebc #3 [ffffaad04005fb80] usleep_range_state at ffffffff8b32c930 #4 [ffffaad04005fbb0] iavf_remove at ffffffffc12b9b4c [iavf] #5 [ffffaad04005fbf0] pci_device_remove at ffffffff8add7513 #6 [ffffaad04005fc10] device_release_driver_internal at ffffffff8af08baa #7 [ffffaad04005fc40] pci_stop_bus_device at ffffffff8adcc5fc #8 [ffffaad04005fc60] pci_stop_and_remove_bus_device at ffffffff8adcc81e #9 [ffffaad04005fc70] pci_iov_remove_virtfn at ffffffff8adf9429 #10 [ffffaad04005fca8] sriov_disable at ffffffff8adf98e4 STMicroelectronics#11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice] STMicroelectronics#12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe [ice] STMicroelectronics#13 [ffffaad04005fd38] ice_shutdown at ffffffffc0477946 [ice] STMicroelectronics#14 [ffffaad04005fd50] pci_device_shutdown at ffffffff8add58f1 STMicroelectronics#15 [ffffaad04005fd70] device_shutdown at ffffffff8af05386 STMicroelectronics#16 [ffffaad04005fd98] kernel_restart at ffffffff8a92a870 STMicroelectronics#17 [ffffaad04005fda8] __do_sys_reboot at ffffffff8a92abd6 STMicroelectronics#18 [ffffaad04005fee0] do_syscall_64 at ffffffff8b317159 STMicroelectronics#19 [ffffaad04005ff08] __context_tracking_enter at ffffffff8b31b6fc STMicroelectronics#20 [ffffaad04005ff18] syscall_exit_to_user_mode at ffffffff8b31b50d STMicroelectronics#21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169 STMicroelectronics#22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe at ffffffff8b40009b RIP: 00007f1baa5c13d7 RSP: 00007fffbcc55a98 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1baa5c13d7 RDX: 0000000001234567 RSI: 0000000028121969 RDI: 00000000fee1dead RBP: 00007fffbcc55ca0 R8: 0000000000000000 R9: 00007fffbcc54e90 R10: 00007fffbcc55050 R11: 0000000000000202 R12: 0000000000000005 R13: 0000000000000000 R14: 00007fffbcc55af0 R15: 0000000000000000 ORIG_RAX: 00000000000000a9 CS: 0033 SS: 002b During reboot all drivers PM shutdown callbacks are invoked. In iavf_shutdown() the adapter state is changed to __IAVF_REMOVE. In ice_shutdown() the call chain above is executed, which at some point calls iavf_remove(). However iavf_remove() expects the VF to be in one of the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If that's not the case it sleeps forever. So if iavf_shutdown() gets invoked before iavf_remove() the system will hang indefinitely because the adapter is already in state __IAVF_REMOVE. Fix this by returning from iavf_remove() if the state is __IAVF_REMOVE, as we already went through iavf_shutdown(). Fixes: 9745780 ("iavf: Add waiting so the port is initialized in remove") Fixes: a841733 ("iavf: Fix race condition between iavf_shutdown and iavf_remove") Reported-by: Marius Cornea <mcornea@redhat.com> Signed-off-by: Stefan Assmann <sassmann@kpanic.de> Reviewed-by: Michal Kubiak <michal.kubiak@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
mcarlin-ds
pushed a commit
that referenced
this pull request
Apr 18, 2023
commit 7ff8491 upstream. Commit 6930bcb dropped the setting of the file_lock range when decoding a nlm_lock off the wire. This causes the client side grant callback to miss matching blocks and reject the lock, only to rerequest it 30s later. Add a helper function to set the file_lock range from the start and end values that the protocol uses, and have the nlm_lock decoder call that to set up the file_lock args properly. Fixes: 6930bcb ("lockd: detect and reject lock arguments that overflow") Reported-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Jeff Layton <jlayton@kernel.org> Tested-by: Amir Goldstein <amir73il@gmail.com> Cc: stable@vger.kernel.org #6.0 Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
mcarlin-ds
pushed a commit
that referenced
this pull request
Nov 7, 2023
[ Upstream commit 05bb016 ] ACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e Before this change we see the following UBSAN stack trace in Fuchsia: #0 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #1.2 0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f #1.1 0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f #1 0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f #2 0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d #3 0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d #4 0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302 #5 0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369 #6 0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac #7 0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2 #8 0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052 #9 0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8 #10 0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98 STMicroelectronics#11 0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac STMicroelectronics#12 0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d STMicroelectronics#13 0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603 Add a simple check that avoids incrementing a pointer by zero, but otherwise behaves as before. Note that our findings are against ACPICA 20221020, but the same code exists on master. Link: acpica/acpica@770653e3 Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
mcarlin-ds
pushed a commit
that referenced
this pull request
Nov 7, 2023
…ting commit b71b552 upstream. Currently ffa_drv->remove() is called unconditionally from ffa_device_remove(). Since the driver registration doesn't check for it and allows it to be registered without .remove callback, we need to check for the presence of it before executing it from ffa_device_remove() to above a NULL pointer dereference like the one below: | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000086000004 | EC = 0x21: IABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x04: level 0 translation fault | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881cc8000 | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 | Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP | CPU: 3 PID: 130 Comm: rmmod Not tainted 6.3.0-rc7 #6 | Hardware name: FVP Base RevC (DT) | pstate: 63402809 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=-c) | pc : 0x0 | lr : ffa_device_remove+0x20/0x2c | Call trace: | 0x0 | device_release_driver_internal+0x16c/0x260 | driver_detach+0x90/0xd0 | bus_remove_driver+0xdc/0x11c | driver_unregister+0x30/0x54 | ffa_driver_unregister+0x14/0x20 | cleanup_module+0x18/0xeec | __arm64_sys_delete_module+0x234/0x378 | invoke_syscall+0x40/0x108 | el0_svc_common+0xb4/0xf0 | do_el0_svc+0x30/0xa4 | el0_svc+0x2c/0x7c | el0t_64_sync_handler+0x84/0xf0 | el0t_64_sync+0x190/0x194 Fixes: 244f5d5 ("firmware: arm_ffa: Add missing remove callback to ffa_bus_type") Link: https://lore.kernel.org/r/20230419-ffa_fixes_6-4-v2-1-d9108e43a176@arm.com Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is part of a major update to STMicro OpenSTLinux Ecosystem version 4.1.0. The new kernel is rebased on the official Linux kernel v5.15.67. The new ecosystem requires optee secure boot. This PR boots to the Linux kernel properly with the corresponding PRs to optee-os, u-boot, and arm-trusted-firmware.