Liu Shixin [Sat, 26 Nov 2022 11:31:26 +0000 (11:31 +0000)]
media: saa7164: fix missing pci_disable_device()
[ Upstream commit
57fb35d7542384cac8f198cd1c927540ad38b61a ]
Add missing pci_disable_device() in the error path in saa7164_initdev().
Fixes:
443c1228d505 ("V4L/DVB (12923): SAA7164: Add support for the NXP SAA7164 silicon")
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Mon, 5 Dec 2022 13:21:22 +0000 (14:21 +0100)]
ALSA: pcm: Set missing stop_operating flag at undoing trigger start
[ Upstream commit
5c8cc93b06d1ff860327a273abf3ac006290d242 ]
When a PCM trigger-start fails at snd_pcm_do_start(), PCM core tries
to undo the action at snd_pcm_undo_start() by issuing the trigger STOP
manually. At that point, we forgot to set the stop_operating flag,
hence the sync-stop won't be issued at the next prepare or other
calls.
This patch adds the missing stop_operating flag at
snd_pcm_undo_start().
Fixes:
1e850beea278 ("ALSA: pcm: Add the support for sync-stop operation")
Link: https://lore.kernel.org/r/b4e71631-4a94-613-27b2-fb595792630@carlh.net
Link: https://lore.kernel.org/r/20221205132124.11585-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Fri, 2 Dec 2022 11:16:40 +0000 (11:16 +0000)]
bpf, sockmap: fix race in sock_map_free()
[ Upstream commit
0a182f8d607464911756b4dbef5d6cad8de22469 ]
sock_map_free() calls release_sock(sk) without owning a reference
on the socket. This can cause use-after-free as syzbot found [1]
Jakub Sitnicki already took care of a similar issue
in sock_hash_free() in commit
75e68e5bf2c7 ("bpf, sockhash:
Synchronize delete from bucket list on map free")
[1]
refcount_t: decrement hit 0; leaking memory.
WARNING: CPU: 0 PID: 3785 at lib/refcount.c:31 refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
Modules linked in:
CPU: 0 PID: 3785 Comm: kworker/u4:6 Not tainted 6.1.0-rc7-syzkaller-00103-gef4d3ea40565 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
Workqueue: events_unbound bpf_map_free_deferred
RIP: 0010:refcount_warn_saturate+0x17c/0x1a0 lib/refcount.c:31
Code: 68 8b 31 c0 e8 75 71 15 fd 0f 0b e9 64 ff ff ff e8 d9 6e 4e fd c6 05 62 9c 3d 0a 01 48 c7 c7 80 bb 68 8b 31 c0 e8 54 71 15 fd <0f> 0b e9 43 ff ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a2 fe ff
RSP: 0018:
ffffc9000456fb60 EFLAGS:
00010246
RAX:
eae59bab72dcd700 RBX:
0000000000000004 RCX:
ffff8880207057c0
RDX:
0000000000000000 RSI:
0000000000000201 RDI:
0000000000000000
RBP:
0000000000000004 R08:
ffffffff816fdabd R09:
fffff520008adee5
R10:
fffff520008adee5 R11:
1ffff920008adee4 R12:
0000000000000004
R13:
dffffc0000000000 R14:
ffff88807b1c6c00 R15:
1ffff1100f638dcf
FS:
0000000000000000(0000) GS:
ffff8880b9800000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000001b30c30000 CR3:
000000000d08e000 CR4:
00000000003506f0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
<TASK>
__refcount_dec include/linux/refcount.h:344 [inline]
refcount_dec include/linux/refcount.h:359 [inline]
__sock_put include/net/sock.h:779 [inline]
tcp_release_cb+0x2d0/0x360 net/ipv4/tcp_output.c:1092
release_sock+0xaf/0x1c0 net/core/sock.c:3468
sock_map_free+0x219/0x2c0 net/core/sock_map.c:356
process_one_work+0x81c/0xd10 kernel/workqueue.c:2289
worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
kthread+0x266/0x300 kernel/kthread.c:376
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
</TASK>
Fixes:
7e81a3530206 ("bpf: Sockmap, ensure sock lock held during tear down")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: Jakub Sitnicki <jakub@cloudflare.com>
Cc: John Fastabend <john.fastabend@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Song Liu <songliubraving@fb.com>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Link: https://lore.kernel.org/r/20221202111640.2745533-1-edumazet@google.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Toke Høiland-Jørgensen [Thu, 1 Dec 2022 12:39:39 +0000 (13:39 +0100)]
bpf: Add dummy type reference to nf_conn___init to fix type deduplication
[ Upstream commit
578ce69ffda49d6c1a252490553290d1f27199f0 ]
The bpf_ct_set_nat_info() kfunc is defined in the nf_nat.ko module, and
takes as a parameter the nf_conn___init struct, which is allocated through
the bpf_xdp_ct_alloc() helper defined in the nf_conntrack.ko module.
However, because kernel modules can't deduplicate BTF types between each
other, and the nf_conn___init struct is not referenced anywhere in vmlinux
BTF, this leads to two distinct BTF IDs for the same type (one in each
module). This confuses the verifier, as described here:
https://lore.kernel.org/all/87leoh372s.fsf@toke.dk/
As a workaround, add an explicit BTF_TYPE_EMIT for the type in
net/filter.c, so the type definition gets included in vmlinux BTF. This
way, both modules can refer to the same type ID (as they both build on top
of vmlinux BTF), and the verifier is no longer confused.
v2:
- Use BTF_TYPE_EMIT (which is a statement so it has to be inside a function
definition; use xdp_func_proto() for this, since this is mostly
xdp-related).
Fixes:
820dc0523e05 ("net: netfilter: move bpf_ct_set_nat_info kfunc in nf_nat_bpf.c")
Signed-off-by: Toke Høiland-Jørgensen <toke@redhat.com>
Link: https://lore.kernel.org/r/20221201123939.696558-1-toke@redhat.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Martin Blumenstingl [Sun, 23 Oct 2022 21:31:57 +0000 (23:31 +0200)]
hwmon: (jc42) Restore the min/max/critical temperatures on resume
[ Upstream commit
084ed144c448fd5bc8ed5a58247153fbbfd115c3 ]
The JC42 compatible thermal sensor on Kingston KSM32ES8/16ME DIMMs
(using Micron E-Die) is an ST Microelectronics STTS2004 (manufacturer
0x104a, device 0x2201). It does not keep the previously programmed
minimum, maximum and critical temperatures after system suspend and
resume (which is a shutdown / startup cycle for the JC42 temperature
sensor). This results in an alarm on system resume because the hardware
default for these values is 0°C (so any environment temperature greater
than 0°C will trigger the alarm).
Example before system suspend:
jc42-i2c-0-1a
Adapter: SMBus PIIX4 adapter port 0 at 0b00
temp1: +34.8°C (low = +0.0°C)
(high = +85.0°C, hyst = +85.0°C)
(crit = +95.0°C, hyst = +95.0°C)
Example after system resume (without this change):
jc42-i2c-0-1a
Adapter: SMBus PIIX4 adapter port 0 at 0b00
temp1: +34.8°C (low = +0.0°C) ALARM (HIGH, CRIT)
(high = +0.0°C, hyst = +0.0°C)
(crit = +0.0°C, hyst = +0.0°C)
Apply the cached values from the JC42_REG_TEMP_UPPER,
JC42_REG_TEMP_LOWER, JC42_REG_TEMP_CRITICAL and JC42_REG_SMBUS (where
the SMBUS register is not related to this issue but a side-effect of
using regcache_sync() during system resume with the previously
cached/programmed values. This fixes the alarm due to the hardware
defaults of 0°C because the previously applied limits (set by userspace)
are re-applied on system resume.
Fixes:
175c490c9e7f ("hwmon: (jc42) Add support for STTS2004 and AT30TSE004")
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20221023213157.11078-3-martin.blumenstingl@googlemail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Martin Blumenstingl [Sun, 23 Oct 2022 21:31:56 +0000 (23:31 +0200)]
hwmon: (jc42) Convert register access and caching to regmap/regcache
[ Upstream commit
8f2fa4726faf01094d7a5be7bd0c120c565f54d9 ]
Switch the jc42 driver to use an I2C regmap to access the registers.
Also move over to regmap's built-in caching instead of adding a
custom caching implementation. This works for JC42_REG_TEMP_UPPER,
JC42_REG_TEMP_LOWER and JC42_REG_TEMP_CRITICAL as these values never
change except when explicitly written. The cache For JC42_REG_TEMP is
dropped (regmap can't cache it because it's volatile, meaning it can
change at any time) as well for simplicity and consistency with other
drivers.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20221023213157.11078-2-martin.blumenstingl@googlemail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Stable-dep-of:
084ed144c448 ("hwmon: (jc42) Restore the min/max/critical temperatures on resume")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Fri, 2 Dec 2022 02:51:11 +0000 (10:51 +0800)]
regulator: core: fix resource leak in regulator_register()
[ Upstream commit
ba62319a42c50e6254e98b3f316464fac8e77968 ]
I got some resource leak reports while doing fault injection test:
OF: ERROR: memory leak, expected refcount 1 instead of 100,
of_node_get()/of_node_put() unbalanced - destroy cset entry:
attach overlay node /i2c/pmic@64/regulators/buck1
unreferenced object 0xffff88810deea000 (size 512):
comm "490-i2c-rt5190a", pid 253, jiffies
4294859840 (age 5061.046s)
hex dump (first 32 bytes):
00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........
ff ff ff ff ff ff ff ff a0 1e 00 a1 ff ff ff ff ................
backtrace:
[<
00000000d78541e2>] kmalloc_trace+0x21/0x110
[<
00000000b343d153>] device_private_init+0x32/0xd0
[<
00000000be1f0c70>] device_add+0xb2d/0x1030
[<
00000000e3e6344d>] regulator_register+0xaf2/0x12a0
[<
00000000e2f5e754>] devm_regulator_register+0x57/0xb0
[<
000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator]
unreferenced object 0xffff88810b617b80 (size 32):
comm "490-i2c-rt5190a", pid 253, jiffies
4294859904 (age 5060.983s)
hex dump (first 32 bytes):
72 65 67 75 6c 61 74 6f 72 2e 32 38 36 38 2d 53 regulator.2868-S
55 50 50 4c 59 00 ff ff 29 00 00 00 2b 00 00 00 UPPLY...)...+...
backtrace:
[<
000000009da9280d>] __kmalloc_node_track_caller+0x44/0x1b0
[<
0000000025c6a4e5>] kstrdup+0x3a/0x70
[<
00000000790efb69>] create_regulator+0xc0/0x4e0
[<
0000000005ed203a>] regulator_resolve_supply+0x2d4/0x440
[<
0000000045796214>] regulator_register+0x10b3/0x12a0
[<
00000000e2f5e754>] devm_regulator_register+0x57/0xb0
[<
000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator]
After calling regulator_resolve_supply(), the 'rdev->supply' is set
by set_supply(), after this set, in the error path, the resources
need be released, so call regulator_put() to avoid the leaks.
Fixes:
aea6cb99703e ("regulator: resolve supply after creating regulator")
Fixes:
8a866d527ac0 ("regulator: core: Resolve supply name earlier to prevent double-init")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221202025111.496402-1-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chen Zhongjin [Mon, 17 Oct 2022 01:42:30 +0000 (09:42 +0800)]
configfs: fix possible memory leak in configfs_create_dir()
[ Upstream commit
c65234b283a65cfbfc94619655e820a5e55199eb ]
kmemleak reported memory leaks in configfs_create_dir():
unreferenced object 0xffff888009f6af00 (size 192):
comm "modprobe", pid 3777, jiffies
4295537735 (age 233.784s)
backtrace:
kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)
new_fragment (./include/linux/slab.h:600 fs/configfs/dir.c:163)
configfs_register_subsystem (fs/configfs/dir.c:1857)
basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic
do_one_initcall (init/main.c:1296)
do_init_module (kernel/module/main.c:2455)
...
unreferenced object 0xffff888003ba7180 (size 96):
comm "modprobe", pid 3777, jiffies
4295537735 (age 233.784s)
backtrace:
kmem_cache_alloc (mm/slub.c:3250 mm/slub.c:3256 mm/slub.c:3263 mm/slub.c:3273)
configfs_new_dirent (./include/linux/slab.h:723 fs/configfs/dir.c:194)
configfs_make_dirent (fs/configfs/dir.c:248)
configfs_create_dir (fs/configfs/dir.c:296)
configfs_attach_group.isra.28 (fs/configfs/dir.c:816 fs/configfs/dir.c:852)
configfs_register_subsystem (fs/configfs/dir.c:1881)
basic_write (drivers/hwtracing/stm/p_basic.c:14) stm_p_basic
do_one_initcall (init/main.c:1296)
do_init_module (kernel/module/main.c:2455)
...
This is because the refcount is not correct in configfs_make_dirent().
For normal stage, the refcount is changing as:
configfs_register_subsystem()
configfs_create_dir()
configfs_make_dirent()
configfs_new_dirent() # set s_count = 1
dentry->d_fsdata = configfs_get(sd); # s_count = 2
...
configfs_unregister_subsystem()
configfs_remove_dir()
remove_dir()
configfs_remove_dirent() # s_count = 1
dput() ...
*dentry_unlink_inode()*
configfs_d_iput() # s_count = 0, release
However, if we failed in configfs_create():
configfs_register_subsystem()
configfs_create_dir()
configfs_make_dirent() # s_count = 2
...
configfs_create() # fail
->out_remove:
configfs_remove_dirent(dentry)
configfs_put(sd) # s_count = 1
return PTR_ERR(inode);
There is no inode in the error path, so the configfs_d_iput() is lost
and makes sd and fragment memory leaked.
To fix this, when we failed in configfs_create(), manually call
configfs_put(sd) to keep the refcount correct.
Fixes:
7063fbf22611 ("[PATCH] configfs: User-driven configuration filesystem")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sebastian Andrzej Siewior [Tue, 29 Nov 2022 16:48:13 +0000 (17:48 +0100)]
hsr: Synchronize sequence number updates.
[ Upstream commit
5c7aa13210c3abdd34fd421f62347665ec6eb551 ]
hsr_register_frame_out() compares new sequence_nr vs the old one
recorded in hsr_node::seq_out and if the new sequence_nr is higher then
it will be written to hsr_node::seq_out as the new value.
This operation isn't locked so it is possible that two frames with the
same sequence number arrive (via the two slave devices) and are fed to
hsr_register_frame_out() at the same time. Both will pass the check and
update the sequence counter later to the same value. As a result the
content of the same packet is fed into the stack twice.
This was noticed by running ping and observing DUP being reported from
time to time.
Instead of using the hsr_priv::seqnr_lock for the whole receive path (as
it is for sending in the master node) add an additional lock that is only
used for sequence number checks and updates.
Add a per-node lock that is used during sequence number reads and
updates.
Fixes:
f421436a591d3 ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sebastian Andrzej Siewior [Tue, 29 Nov 2022 16:48:12 +0000 (17:48 +0100)]
hsr: Synchronize sending frames to have always incremented outgoing seq nr.
[ Upstream commit
06afd2c31d338fa762548580c1bf088703dd1e03 ]
Sending frames via the hsr (master) device requires a sequence number
which is tracked in hsr_priv::sequence_nr and protected by
hsr_priv::seqnr_lock. Each time a new frame is sent, it will obtain a
new id and then send it via the slave devices.
Each time a packet is sent (via hsr_forward_do()) the sequence number is
checked via hsr_register_frame_out() to ensure that a frame is not
handled twice. This make sense for the receiving side to ensure that the
frame is not injected into the stack twice after it has been received
from both slave ports.
There is no locking to cover the sending path which means the following
scenario is possible:
CPU0 CPU1
hsr_dev_xmit(skb1) hsr_dev_xmit(skb2)
fill_frame_info() fill_frame_info()
hsr_fill_frame_info() hsr_fill_frame_info()
handle_std_frame() handle_std_frame()
skb1's sequence_nr = 1
skb2's sequence_nr = 2
hsr_forward_do() hsr_forward_do()
hsr_register_frame_out(, 2) // okay, send)
hsr_register_frame_out(, 1) // stop, lower seq duplicate
Both skbs (or their struct hsr_frame_info) received an unique id.
However since skb2 was sent before skb1, the higher sequence number was
recorded in hsr_register_frame_out() and the late arriving skb1 was
dropped and never sent.
This scenario has been observed in a three node HSR setup, with node1 +
node2 having ping and iperf running in parallel. From time to time ping
reported a missing packet. Based on tracing that missing ping packet did
not leave the system.
It might be possible (didn't check) to drop the sequence number check on
the sending side. But if the higher sequence number leaves on wire
before the lower does and the destination receives them in that order
and it will drop the packet with the lower sequence number and never
inject into the stack.
Therefore it seems the only way is to lock the whole path from obtaining
the sequence number and sending via dev_queue_xmit() and assuming the
packets leave on wire in the same order (and don't get reordered by the
NIC).
Cover the whole path for the master interface from obtaining the ID
until after it has been forwarded via hsr_forward_skb() to ensure the
skbs are sent to the NIC in the order of the assigned sequence numbers.
Fixes:
f421436a591d3 ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sebastian Andrzej Siewior [Tue, 29 Nov 2022 16:48:11 +0000 (17:48 +0100)]
hsr: Disable netpoll.
[ Upstream commit
d5c7652eb16fa203d82546e0285136d7b321ffa9 ]
The hsr device is a software device. Its
net_device_ops::ndo_start_xmit() routine will process the packet and
then pass the resulting skb to dev_queue_xmit().
During processing, hsr acquires a lock with spin_lock_bh()
(hsr_add_node()) which needs to be promoted to the _irq() suffix in
order to avoid a potential deadlock.
Then there are the warnings in dev_queue_xmit() (due to
local_bh_disable() with disabled interrupts) left.
Instead trying to address those (there is qdisc and…) for netpoll sake,
just disable netpoll on hsr.
Disable netpoll on hsr and replace the _irqsave() locking with _bh().
Fixes:
f421436a591d3 ("net/hsr: Add support for the High-availability Seamless Redundancy protocol (HSRv0)")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sebastian Andrzej Siewior [Tue, 29 Nov 2022 16:48:10 +0000 (17:48 +0100)]
hsr: Avoid double remove of a node.
[ Upstream commit
0c74d9f79ec4299365bbe803baa736ae0068179e ]
Due to the hashed-MAC optimisation one problem become visible:
hsr_handle_sup_frame() walks over the list of available nodes and merges
two node entries into one if based on the information in the supervision
both MAC addresses belong to one node. The list-walk happens on a RCU
protected list and delete operation happens under a lock.
If the supervision arrives on both slave interfaces at the same time
then this delete operation can occur simultaneously on two CPUs. The
result is the first-CPU deletes the from the list and the second CPUs
BUGs while attempting to dereference a poisoned list-entry. This happens
more likely with the optimisation because a new node for the mac_B entry
is created once a packet has been received and removed (merged) once the
supervision frame has been received.
Avoid removing/ cleaning up a hsr_node twice by adding a `removed' field
which is set to true after the removal and checked before the removal.
Fixes:
f266a683a4804 ("net/hsr: Better frame dispatch")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sebastian Andrzej Siewior [Tue, 29 Nov 2022 16:48:09 +0000 (17:48 +0100)]
hsr: Add a rcu-read lock to hsr_forward_skb().
[ Upstream commit
5aa2820177af650293b2f9f1873c1f6f8e4ad7a4 ]
hsr_forward_skb() a skb and keeps information in an on-stack
hsr_frame_info. hsr_get_node() assigns hsr_frame_info::node_src which is
from a RCU list. This pointer is used later in hsr_forward_do().
I don't see a reason why this pointer can't vanish midway since there is
no guarantee that hsr_forward_skb() is invoked from an RCU read section.
Use rcu_read_lock() to protect hsr_frame_info::node_src from its
assignment until it is no longer used.
Fixes:
f266a683a4804 ("net/hsr: Better frame dispatch")
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sebastian Andrzej Siewior [Tue, 29 Nov 2022 16:48:08 +0000 (17:48 +0100)]
Revert "net: hsr: use hlist_head instead of list_head for mac addresses"
[ Upstream commit
e012764cebf6e33097f6833ff15a936fbe7b846c ]
The hlist optimisation (which not only uses hlist_head instead of
list_head but also splits hsr_priv::node_db into an array of 256 slots)
does not consider the "node merge":
Upon starting the hsr network (with three nodes) a packet that is
sent from node1 to node3 will also be sent from node1 to node2 and then
forwarded to node3.
As a result node3 will receive 2 packets because it is not able
to filter out the duplicate. Each packet received will create a new
struct hsr_node with macaddress_A only set the MAC address it received
from (the two MAC addesses from node1).
At some point (early in the process) two supervision frames will be
received from node1. They will be processed by hsr_handle_sup_frame()
and one frame will leave early ("Node has already been merged") and does
nothing. The other frame will be merged as portB and have its MAC
address written to macaddress_B and the hsr_node (that was created for
it as macaddress_A) will be removed.
From now on HSR is able to identify a duplicate because both packets
sent from one node will result in the same struct hsr_node because
hsr_get_node() will find the MAC address either on macaddress_A or
macaddress_B.
Things get tricky with the optimisation: If sender's MAC address is
saved as macaddress_A then the lookup will work as usual. If the MAC
address has been merged into macaddress_B of another hsr_node then the
lookup won't work because it is likely that the data structure is in
another bucket. This results in creating a new struct hsr_node and not
recognising a possible duplicate.
A way around it would be to add another hsr_node::mac_list_B and attach
it to the other bucket to ensure that this hsr_node will be looked up
either via macaddress_A _or_ macaddress_B.
I however prefer to revert it because it sounds like an academic problem
rather than real life workload plus it adds complexity. I'm not an HSR
expert with what is usual size of a network but I would guess 40 to 60
nodes. With 10.000 nodes and assuming 60us for pass-through (from node
to node) then it would take almost 600ms for a packet to almost wrap
around which sounds a lot.
Revert the hash MAC addresses optimisation.
Fixes:
4acc45db71158 ("net: hsr: use hlist_head instead of list_head for mac addresses")
Cc: Juhee Kang <claudiajkang@gmail.com>
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christian Marangi [Tue, 8 Nov 2022 21:56:25 +0000 (22:56 +0100)]
clk: qcom: clk-krait: fix wrong div2 functions
[ Upstream commit
d676d3a3717cf726d3affedbe5ba98fc4ccad7b3 ]
Currently div2 value is applied to the wrong bits. This is caused by a
bug in the code where the shift is done only for lpl, for anything
else the mask is not shifted to the correct bits.
Fix this by correctly shift if lpl is not supported.
Fixes:
4d7dc77babfe ("clk: qcom: Add support for Krait clocks")
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221108215625.30186-1-ansuelsmth@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Douglas Anderson [Fri, 4 Nov 2022 13:56:29 +0000 (06:56 -0700)]
clk: qcom: lpass-sc7180: Fix pm_runtime usage
[ Upstream commit
ff1ccf59eaffd192efe21f7de9fb0c130faf1b1b ]
The sc7180 lpass clock controller's pm_runtime usage wasn't broken
quite as spectacularly as the sc7280's pm_runtime usage, but it was
still broken. Putting some printouts in at boot showed me this (with
serial console enabled, which makes the prints slow and thus changes
timing):
[ 3.109951] DOUG: my_pm_clk_resume, usage=1
[ 3.114767] DOUG: my_pm_clk_resume, usage=1
[ 3.664443] DOUG: my_pm_clk_suspend, usage=0
[ 3.897566] DOUG: my_pm_clk_suspend, usage=0
[ 3.910137] DOUG: my_pm_clk_resume, usage=1
[ 3.923217] DOUG: my_pm_clk_resume, usage=0
[ 4.440116] DOUG: my_pm_clk_suspend, usage=-1
[ 4.444982] DOUG: my_pm_clk_suspend, usage=0
[ 14.170501] DOUG: my_pm_clk_resume, usage=1
[ 14.176245] DOUG: my_pm_clk_resume, usage=0
...or this w/out serial console:
[ 0.556139] DOUG: my_pm_clk_resume, usage=1
[ 0.556279] DOUG: my_pm_clk_resume, usage=1
[ 1.058422] DOUG: my_pm_clk_suspend, usage=-1
[ 1.058464] DOUG: my_pm_clk_suspend, usage=0
[ 1.186250] DOUG: my_pm_clk_resume, usage=1
[ 1.186292] DOUG: my_pm_clk_resume, usage=0
[ 1.731536] DOUG: my_pm_clk_suspend, usage=-1
[ 1.731557] DOUG: my_pm_clk_suspend, usage=0
[ 10.288910] DOUG: my_pm_clk_resume, usage=1
[ 10.289496] DOUG: my_pm_clk_resume, usage=0
It seems to be doing roughly the right sequence of calls, but just
like with sc7280 this is more by luck than anything. Having a usage of
-1 is just not OK.
Let's fix this like we did with sc7280.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Fixes:
ce8c195e652f ("clk: qcom: lpasscc: Introduce pm autosuspend for SC7180")
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221104064055.2.I49b25b9bda9430fc7ea21e5a708ca5a0aced2798@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
Douglas Anderson [Fri, 4 Nov 2022 13:56:28 +0000 (06:56 -0700)]
clk: qcom: lpass-sc7280: Fix pm_runtime usage
[ Upstream commit
d470be3c4f30b4666e43eef6bab80f543563cdb0 ]
The pm_runtime usage in lpass-sc7280 was broken in quite a few
ways. Specifically:
1. At the end of probe it called "put" twice. This is a no-no and will
end us up with a negative usage count. Even worse than calling
"put" twice, it never called "get" once. Thus after bootup it could
be seen that the runtime usage of the devices managed by this
driver was -2.
2. In some error cases it manually called pm_runtime_disable() even
though it had previously used devm_add_action_or_reset() to set
this up to be called automatically. This meant that in these error
cases we'd double-call pm_runtime_disable().
3. It forgot to call undo pm_runtime_use_autosuspend(), which can
sometimes have subtle problems (and the docs specifically mention
that you need to undo this function).
Overall the above seriously calls into question how this driver is
working. It seems like a combination of "it doesn't", "by luck", and
"because of the weirdness of runtime_pm". Specifically I put a
printout to the serial console every time the runtime suspend/resume
was called for the two devices created by this driver (I wrapped the
pm_clk calls). When I had serial console enabled, I found that the
calls got resumed at bootup (when the clk core probed and before our
double-put) and then never touched again. That's no good.
[ 0.829997] DOUG: my_pm_clk_resume, usage=1
[ 0.835487] DOUG: my_pm_clk_resume, usage=1
When I disabled serial console (speeding up boot), I got a different
pattern, which I guess (?) is better:
[ 0.089767] DOUG: my_pm_clk_resume, usage=1
[ 0.090507] DOUG: my_pm_clk_resume, usage=1
[ 0.151885] DOUG: my_pm_clk_suspend, usage=-2
[ 0.151914] DOUG: my_pm_clk_suspend, usage=-2
[ 1.825747] DOUG: my_pm_clk_resume, usage=-1
[ 1.825774] DOUG: my_pm_clk_resume, usage=-1
[ 1.888269] DOUG: my_pm_clk_suspend, usage=-2
[ 1.888282] DOUG: my_pm_clk_suspend, usage=-2
These different patterns have to do with the fact that the core PM
Runtime code really isn't designed to be robust to negative usage
counts and sometimes may happen to stumble upon a behavior that
happens to "work". For instance, you can see that
__pm_runtime_suspend() will treat any non-zero value (including
negative numbers) as if the device is in use.
In any case, let's fix the driver to be correct. We'll hold a
pm_runtime reference for the whole probe and then drop it (once!) at
the end. We'll get rid of manual pm_runtime_disable() calls in the
error handling. We'll also switch to devm_pm_runtime_enable(), which
magically handles undoing pm_runtime_use_autosuspend() as of commit
b4060db9251f ("PM: runtime: Have devm_pm_runtime_enable() handle
pm_runtime_dont_use_autosuspend()").
While we're at this, let's also use devm_pm_clk_create() instead of
rolling it ourselves.
Note that the above changes make it obvious that
lpassaudio_create_pm_clks() was doing more than just creating
clocks. It was also setting up pm_runtime parameters. Let's rename it.
All of these problems were found by code inspection. I started looking
at this driver because it was involved in a deadlock that I reported a
while ago [1]. Though I bisected the deadlock to commit
1b771839de05
("clk: qcom: gdsc: enable optional power domain support"), it was
never really clear why that patch affected it other than a luck of
timing changes. I'll also note that by fixing the timing (as done in
this change) we also seem to aboid the deadlock, which is a nice
benefit.
Also note that some of the fixes here are much the same type of stuff
that Dmitry did in commit
72cfc73f4663 ("clk: qcom: use
devm_pm_runtime_enable and devm_pm_clk_create"), but I guess
lpassaudiocc-sc7280.c didn't exist then.
[1] https://lore.kernel.org/r/
20220922154354.2486595-1-dianders@chromium.org
Fixes:
a9dd26639d05 ("clk: qcom: lpass: Add support for LPASS clock controller for SC7280")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20221104064055.1.I00a0e4564a25489e85328ec41636497775627564@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Thu, 1 Dec 2022 12:27:05 +0000 (20:27 +0800)]
regulator: core: fix module refcount leak in set_supply()
[ Upstream commit
da46ee19cbd8344d6860816b4827a7ce95764867 ]
If create_regulator() fails in set_supply(), the module refcount
needs be put to keep refcount balanced.
Fixes:
e2c09ae7a74d ("regulator: core: Increase refcount for regulator supply's module")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221201122706.4055992-2-yangyingliang@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiongfeng Wang [Fri, 25 Nov 2022 02:58:31 +0000 (10:58 +0800)]
mt76: mt7915: Fix PCI device refcount leak in mt7915_pci_init_hif2()
[ Upstream commit
5938196cc188ba4323bc6357f5ac55127d715888 ]
As comment of pci_get_device() says, it returns a pci_device with its
refcount increased. We need to call pci_dev_put() to decrease the
refcount. Save the return value of pci_get_device() and call
pci_dev_put() to decrease the refcount.
Fixes:
9093cfff72e3 ("mt76: mt7915: add support for using a secondary PCIe link for gen1")
Fixes:
2e30db0dde61 ("mt76: mt7915: add device id for mt7916")
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Deren Wu [Thu, 24 Nov 2022 14:20:38 +0000 (22:20 +0800)]
wifi: mt76: do not send firmware FW_FEATURE_NON_DL region
[ Upstream commit
f37f76d43865c58cb96aa13c87164abb41f22d0b ]
skip invalid section to avoid potential risks
Fixes:
23bdc5d8cadf ("wifi: mt76: mt7921: introduce Country Location Control support")
Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Deren Wu [Mon, 28 Nov 2022 07:04:21 +0000 (15:04 +0800)]
wifi: mt76: mt7921: Add missing __packed annotation of struct mt7921_clc
[ Upstream commit
e5c6bc6f19d8c293f86b347cddab54d5a3830b38 ]
Add __packed annotation to avoid potential CLC parsing error
Fixes:
23bdc5d8cadf ("wifi: mt76: mt7921: introduce Country Location Control support")
Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Deren Wu [Sun, 27 Nov 2022 02:35:37 +0000 (10:35 +0800)]
wifi: mt76: fix coverity overrun-call in mt76_get_txpower()
[ Upstream commit
03dd0d49de7db680a856fa566963bb8421f46368 ]
Make sure the nss is valid for nss_delta array. Return zero
if the index is invalid.
Coverity message:
Event overrun-call: Overrunning callee's array of size 4 by passing
argument "n_chains" (which evaluates to 15) in call to
"mt76_tx_power_nss_delta".
int delta = mt76_tx_power_nss_delta(n_chains);
Fixes:
07cda406308b ("mt76: fix rounding issues on converting per-chain and combined txpower")
Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
YN Chen [Wed, 16 Nov 2022 14:43:02 +0000 (22:43 +0800)]
wifi: mt76: mt7921: fix wrong power after multiple SAR set
[ Upstream commit
7eefb93d4a6fbccd859e538d208c50fd10b44cb7 ]
We should update CLC config before SAR set to synchronize all
related settings.
Fixes:
23bdc5d8cadf ("wifi: mt76: mt7921: introduce Country Location Control support")
Signed-off-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nicolas Cavallari [Thu, 10 Nov 2022 15:39:51 +0000 (16:39 +0100)]
wifi: mt76: mt7915: Fix chainmask calculation on mt7915 DBDC
[ Upstream commit
de147cc28985a2a09e5d6d179fc5ef59b22fc058 ]
mt7915 does not have a per-band number of chains unlike the other chips,
it only has a total number of chains. Yet the current code would
consider the total number as a per-band number.
For example, it would report that a 2x2 + 2x2 DBDC card have 4 chains on
each band and set chainmask to 0b1111 for the first interface and
0b11110000 for the second.
Fixes:
99ad32a4ca3a ("mt76: mt7915: add support for MT7986")
Co-developed-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shayne Chen [Fri, 30 Sep 2022 15:13:10 +0000 (23:13 +0800)]
wifi: mt76: mt7915: rework eeprom tx paths and streams init
[ Upstream commit
a7ec8bcf00034ce84d4c9a15dffd7577fbed4db2 ]
Rework tx paths and streams init part to improve readability, and make
sure that the available tx streams should be smaller than or equal to
the available tx paths.
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Stable-dep-of:
de147cc28985 ("wifi: mt76: mt7915: Fix chainmask calculation on mt7915 DBDC")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Wed, 2 Nov 2022 12:46:50 +0000 (13:46 +0100)]
wifi: mt76: mt7921: fix reporting of TX AGGR histogram
[ Upstream commit
028b4f22b37b88821fd87b56ce47b180583c774e ]
Similar to mt7915, fix stats clash between bins [4-7] in 802.11 tx
aggregation histogram.
Fixes:
163f4d22c118d ("mt76: mt7921: add MAC support")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Wed, 2 Nov 2022 12:35:01 +0000 (13:35 +0100)]
wifi: mt76: mt7915: fix reporting of TX AGGR histogram
[ Upstream commit
528d13e7f033b54d50e0077922dd52f005d648cf ]
Fix stats clash between bins [4-7] in 802.11 tx aggregation histogram.
Fixes:
e57b7901469fc ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ryder Lee [Sat, 1 Oct 2022 01:42:44 +0000 (09:42 +0800)]
wifi: mt76: mt7915: fix mt7915_mac_set_timing()
[ Upstream commit
0c881dc08fd71ca2673f31a64989fbb28eac26f4 ]
Correct mac timiing settings for different hardware generations.
This improves 40-60Mbps performance.
Fixes:
9aac2969fe5f ("mt76: mt7915: update mac timing settings")
Reported-By: Carson Vandegriffe <carson.vandegriffe@candelatech.com>
Tested-by: Chad Monroe <chad.monroe@smartrg.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sean Wang [Fri, 16 Sep 2022 22:46:45 +0000 (06:46 +0800)]
wifi: mt76: mt7921: fix antenna signal are way off in monitor mode
[ Upstream commit
c256ba6b1909f28b517274282b6845567e974143 ]
Group 3 in RxD is disabled in monitor mode. We should use the group 5 in
RxD instead to fix antenna signal way off issue, e.g we would see the
incorrect antenna signal value in wireshark. On the other hand, Group 5
wouldn't be used in STA or AP mode, so the patch shouldn't cause any
harm to those modes.
Fixes:
cbaa0a404f8d ("mt76: mt7921: fix up the monitor mode")
Reported-by: Adrian Granados <agranados@gmail.com>
Co-developed-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chen Zhongjin [Wed, 9 Nov 2022 09:02:37 +0000 (17:02 +0800)]
wifi: cfg80211: Fix not unregister reg_pdev when load_builtin_regdb_keys() fails
[ Upstream commit
833a9fd28c9b7ccb39a334721379e992dc1c0c89 ]
In regulatory_init_db(), when it's going to return a error, reg_pdev
should be unregistered. When load_builtin_regdb_keys() fails it doesn't
do it and makes cfg80211 can't be reload with report:
sysfs: cannot create duplicate filename '/devices/platform/regulatory.0'
...
<TASK>
dump_stack_lvl+0x79/0x9b
sysfs_warn_dup.cold+0x1c/0x29
sysfs_create_dir_ns+0x22d/0x290
kobject_add_internal+0x247/0x800
kobject_add+0x135/0x1b0
device_add+0x389/0x1be0
platform_device_add+0x28f/0x790
platform_device_register_full+0x376/0x4b0
regulatory_init+0x9a/0x4b2 [cfg80211]
cfg80211_init+0x84/0x113 [cfg80211]
...
Fixes:
90a53e4432b1 ("cfg80211: implement regdb signature checking")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Link: https://lore.kernel.org/r/20221109090237.214127-1-chenzhongjin@huawei.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Íñigo Huguet [Fri, 11 Nov 2022 15:36:22 +0000 (16:36 +0100)]
wifi: mac80211: fix maybe-unused warning
[ Upstream commit
09d838a457a89883a926b8b0104d575158fd4b92 ]
In ieee80211_lookup_key, the variable named `local` is unused if
compiled without lockdep, getting this warning:
net/mac80211/cfg.c: In function ‘ieee80211_lookup_key’:
net/mac80211/cfg.c:542:26: error: unused variable ‘local’ [-Werror=unused-variable]
struct ieee80211_local *local = sdata->local;
^~~~~
Fix it with __maybe_unused.
Fixes:
8cbf0c2ab6df ("wifi: mac80211: refactor some key code")
Signed-off-by: Íñigo Huguet <ihuguet@redhat.com>
Link: https://lore.kernel.org/r/20221111153622.29016-1-ihuguet@redhat.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhengchao Shao [Thu, 17 Nov 2022 06:45:00 +0000 (14:45 +0800)]
wifi: mac80211: fix memory leak in ieee80211_if_add()
[ Upstream commit
13e5afd3d773c6fc6ca2b89027befaaaa1ea7293 ]
When register_netdevice() failed in ieee80211_if_add(), ndev->tstats
isn't released. Fix it.
Fixes:
5a490510ba5f ("mac80211: use per-CPU TX/RX statistics")
Signed-off-by: Zhengchao Shao <shaozhengchao@huawei.com>
Link: https://lore.kernel.org/r/20221117064500.319983-1-shaozhengchao@huawei.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yuan Can [Tue, 29 Nov 2022 01:42:11 +0000 (01:42 +0000)]
wifi: nl80211: Add checks for nla_nest_start() in nl80211_send_iface()
[ Upstream commit
5cc58b376675981386c6192405fe887cd29c527a ]
As the nla_nest_start() may fail with NULL returned, the return value needs
to be checked.
Fixes:
ce08cd344a00 ("wifi: nl80211: expose link information for interfaces")
Signed-off-by: Yuan Can <yuancan@huawei.com>
Link: https://lore.kernel.org/r/20221129014211.56558-1-yuancan@huawei.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexander Sverdlin [Wed, 30 Nov 2022 16:29:27 +0000 (17:29 +0100)]
spi: spidev: mask SPI_CS_HIGH in SPI_IOC_RD_MODE
[ Upstream commit
7dbfa445ff7393d1c4c066c1727c9e0af1251958 ]
Commit
f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
has changed the user-space interface so that bogus SPI_CS_HIGH started
to appear in the mask returned by SPI_IOC_RD_MODE even for active-low CS
pins. Commit
138c9c32f090
("spi: spidev: Fix CS polarity if GPIO descriptors are used") fixed only
SPI_IOC_WR_MODE part of the problem. Let's fix SPI_IOC_RD_MODE
symmetrically.
Test case:
#include <sys/ioctl.h>
#include <fcntl.h>
#include <linux/spi/spidev.h>
int main(int argc, char **argv)
{
char modew = SPI_CPHA;
char moder;
int f = open("/dev/spidev0.0", O_RDWR);
if (f < 0)
return 1;
ioctl(f, SPI_IOC_WR_MODE, &modew);
ioctl(f, SPI_IOC_RD_MODE, &moder);
return moder == modew ? 0 : 2;
}
Fixes:
f3186dd87669 ("spi: Optionally use GPIO descriptors for CS GPIOs")
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@siemens.com>
Link: https://lore.kernel.org/r/20221130162927.539512-1-alexander.sverdlin@siemens.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Mon, 28 Nov 2022 11:06:14 +0000 (14:06 +0300)]
bonding: uninitialized variable in bond_miimon_inspect()
[ Upstream commit
e5214f363dabca240446272dac54d404501ad5e5 ]
The "ignore_updelay" variable needs to be initialized to false.
Fixes:
f8a65ab2f3ff ("bonding: fix link recovery in mode 2 when updelay is nonzero")
Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Link: https://lore.kernel.org/r/Y4SWJlh3ohJ6EPTL@kili
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pengcheng Yang [Tue, 29 Nov 2022 10:40:40 +0000 (18:40 +0800)]
bpf, sockmap: Fix data loss caused by using apply_bytes on ingress redirect
[ Upstream commit
9072931f020bfd907d6d89ee21ff1481cd78b407 ]
Use apply_bytes on ingress redirect, when apply_bytes is less than
the length of msg data, some data may be skipped and lost in
bpf_tcp_ingress().
If there is still data in the scatterlist that has not been consumed,
we cannot move the msg iter.
Fixes:
604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface")
Signed-off-by: Pengcheng Yang <yangpc@wangsu.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/1669718441-2654-4-git-send-email-yangpc@wangsu.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pengcheng Yang [Tue, 29 Nov 2022 10:40:39 +0000 (18:40 +0800)]
bpf, sockmap: Fix missing BPF_F_INGRESS flag when using apply_bytes
[ Upstream commit
a351d6087bf7d3d8440d58d3bf244ec64b89394a ]
When redirecting, we use sk_msg_to_ingress() to get the BPF_F_INGRESS
flag from the msg->flags. If apply_bytes is used and it is larger than
the current data being processed, sk_psock_msg_verdict() will not be
called when sendmsg() is called again. At this time, the msg->flags is 0,
and we lost the BPF_F_INGRESS flag.
So we need to save the BPF_F_INGRESS flag in sk_psock and use it when
redirection.
Fixes:
8934ce2fd081 ("bpf: sockmap redirect ingress support")
Signed-off-by: Pengcheng Yang <yangpc@wangsu.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/1669718441-2654-3-git-send-email-yangpc@wangsu.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pengcheng Yang [Tue, 29 Nov 2022 10:40:38 +0000 (18:40 +0800)]
bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data
[ Upstream commit
7a9841ca025275b5b0edfb0b618934abb6ceec15 ]
In tcp_bpf_send_verdict() redirection, the eval variable is assigned to
__SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,
sock_put() will be called multiple times.
We should reset the eval variable to __SK_NONE every time more_data
starts.
This causes:
IPv4: Attempt to release TCP socket in state 1
00000000b4c925d7
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110
Modules linked in:
CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1
Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
Call Trace:
<TASK>
__tcp_transmit_skb+0xa1b/0xb90
? __alloc_skb+0x8c/0x1a0
? __kmalloc_node_track_caller+0x184/0x320
tcp_write_xmit+0x22a/0x1110
__tcp_push_pending_frames+0x32/0xf0
do_tcp_sendpages+0x62d/0x640
tcp_bpf_push+0xae/0x2c0
tcp_bpf_sendmsg_redir+0x260/0x410
? preempt_count_add+0x70/0xa0
tcp_bpf_send_verdict+0x386/0x4b0
tcp_bpf_sendmsg+0x21b/0x3b0
sock_sendmsg+0x58/0x70
__sys_sendto+0xfa/0x170
? xfd_validate_state+0x1d/0x80
? switch_fpu_return+0x59/0xe0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x37/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Fixes:
cd9733f5d75c ("tcp_bpf: Fix one concurrency problem in the tcp_bpf_send_verdict function")
Signed-off-by: Pengcheng Yang <yangpc@wangsu.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Jakub Sitnicki <jakub@cloudflare.com>
Link: https://lore.kernel.org/bpf/1669718441-2654-2-git-send-email-yangpc@wangsu.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Randy Dunlap [Wed, 30 Nov 2022 23:01:07 +0000 (15:01 -0800)]
Input: wistron_btns - disable on UML
[ Upstream commit
b2b80d9dd14cb5b70dc254bddbc4eea932694791 ]
The wistron_btns driver calls rtc_cmos_read(), which isn't
available with UML builds, so disable this driver on UML.
Prevents this build error:
ld: drivers/input/misc/wistron_btns.o: in function `poll_bios':
wistron_btns.c:(.text+0x4be): undefined reference to `rtc_cmos_read'
Fixes:
0bbadafdc49d ("um: allow disabling NO_IOMEM") # v5.14+
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://lore.kernel.org/r/20221130161604.1879-1-rdunlap@infradead.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Florian Westphal [Tue, 22 Nov 2022 15:00:09 +0000 (16:00 +0100)]
netfilter: conntrack: set icmpv6 redirects as RELATED
[ Upstream commit
7d7cfb48d81353e826493d24c7cec7360950968f ]
icmp conntrack will set icmp redirects as RELATED, but icmpv6 will not
do this.
For icmpv6, only icmp errors (code <= 128) are examined for RELATED state.
ICMPV6 Redirects are part of neighbour discovery mechanism, those are
handled by marking a selected subset (e.g. neighbour solicitations) as
UNTRACKED, but not REDIRECT -- they will thus be flagged as INVALID.
Add minimal support for REDIRECTs. No parsing of neighbour options is
added for simplicity, so this will only check that we have the embeeded
original header (ND_OPT_REDIRECT_HDR), and then attempt to do a flow
lookup for this tuple.
Also extend the existing test case to cover redirects.
Fixes:
9fb9cbb1082d ("[NETFILTER]: Add nf_conntrack subsystem.")
Reported-by: Eric Garver <eric@garver.life>
Link: https://github.com/firewalld/firewalld/issues/1046
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Eric Garver <eric@garver.life>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiu Jianfeng [Tue, 22 Nov 2022 15:23:53 +0000 (23:23 +0800)]
clk: visconti: Fix memory leak in visconti_register_pll()
[ Upstream commit
b55226f8553d255f5002c751c7c6ba9291f34bf2 ]
@pll->rate_table has allocated memory by kmemdup(), if clk_hw_register()
fails, it should be freed, otherwise it will cause memory leak issue,
this patch fixes it.
Fixes:
b4cbe606dc36 ("clk: visconti: Add support common clock driver and reset driver")
Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Link: https://lore.kernel.org/r/20221122152353.204132-1-xiujianfeng@huawei.com
Acked-by: Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Qilong [Wed, 28 Sep 2022 16:04:02 +0000 (00:04 +0800)]
ASoC: pcm512x: Fix PM disable depth imbalance in pcm512x_probe
[ Upstream commit
97b801be6f8e53676b9f2b105f54e35c745c1b22 ]
The pm_runtime_enable will increase power disable depth. Thus
a pairing decrement is needed on the error handling path to
keep it balanced according to context. We fix it by going to
err_pm instead of err_clk.
Fixes:
f086ba9d5389c ("ASoC: pcm512x: Support mastering BCLK/LRCLK using the PLL")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20220928160402.126140-1-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xia Fukun [Fri, 25 Nov 2022 06:34:28 +0000 (14:34 +0800)]
drm/i915/bios: fix a memory leak in generate_lfp_data_ptrs
[ Upstream commit
1382901f75a5a7dc8eac05059fd0c7816def4eae ]
When (size != 0 || ptrs->lvds_ entries != 3), the program tries to
free() the ptrs. However, the ptrs is not created by calling kzmalloc(),
but is obtained by pointer offset operation.
This may lead to memory leaks or undefined behavior.
Fix this by replacing the arguments of kfree() with ptrs_block.
Fixes:
a87d0a847607 ("drm/i915/bios: Generate LFP data table pointers if the VBT lacks them")
Signed-off-by: Xia Fukun <xiafukun@huawei.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20221125063428.69486-1-xiafukun@huawei.com
(cherry picked from commit
7674cd0b7d28b952151c3df26bbfa7e07eb2b4ec)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Konstantin Meskhidze [Tue, 29 Nov 2022 04:02:54 +0000 (23:02 -0500)]
drm/amdkfd: Fix memory leakage
[ Upstream commit
75818afff631e1ea785a82c3e8bb82eb0dee539c ]
This patch fixes potential memory leakage and seg fault
in _gpuvm_import_dmabuf() function
Fixes:
d4ec4bdc0bd5 ("drm/amdkfd: Allow access for mmapping KFD BOs")
Signed-off-by: Konstantin Meskhidze <konstantin.meskhidze@huawei.com>
Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiongfeng Wang [Tue, 22 Nov 2022 11:30:43 +0000 (19:30 +0800)]
drm/amdgpu: Fix PCI device refcount leak in amdgpu_atrm_get_bios()
[ Upstream commit
ca54639c7752edf1304d92ff4d0c049d4efc9ba0 ]
As comment of pci_get_class() says, it returns a pci_device with its
refcount increased and decreased the refcount for the input parameter
@from if it is not NULL.
If we break the loop in amdgpu_atrm_get_bios() with 'pdev' not NULL, we
need to call pci_dev_put() to decrease the refcount. Add the missing
pci_dev_put() to avoid refcount leak.
Fixes:
d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiongfeng Wang [Tue, 22 Nov 2022 11:30:42 +0000 (19:30 +0800)]
drm/radeon: Fix PCI device refcount leak in radeon_atrm_get_bios()
[ Upstream commit
725a521a18734f65de05b8d353b5bd0d3ca4c37a ]
As comment of pci_get_class() says, it returns a pci_device with its
refcount increased and decreased the refcount for the input parameter
@from if it is not NULL.
If we break the loop in radeon_atrm_get_bios() with 'pdev' not NULL, we
need to call pci_dev_put() to decrease the refcount. Add the missing
pci_dev_put() to avoid refcount leak.
Fixes:
d8ade3526b2a ("drm/radeon: handle non-VGA class pci devices with ATRM")
Fixes:
c61e2775873f ("drm/radeon: split ATRM support out from the ATPX handler (v3)")
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Veerabadhran Gopalakrishnan [Wed, 23 Nov 2022 14:40:32 +0000 (20:10 +0530)]
amdgpu/nv.c: Corrected typo in the video capabilities resolution
[ Upstream commit
65009bf2b4d287ef7ad7e6eb082b7c3d35eb611f ]
Corrected the typo in the 4K resolution parameters.
Fixes:
b3a24461f9fb15 ("amdgpu/nv.c - Added codec query for Beige Goby")
Fixes:
9075096b09e590 ("amdgpu/nv.c - Optimize code for video codec support structure")
Fixes:
9ac0edaa0f8323 ("drm/amdgpu: add vcn_4_0_0 video codec query")
Signed-off-by: Veerabadhran Gopalakrishnan <veerabadhran.gopalakrishnan@amd.com>
Acked-by: Luben Tuikov <luben.tuikov@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Guchun Chen [Tue, 22 Nov 2022 09:33:24 +0000 (17:33 +0800)]
drm/amd/pm/smu11: BACO is supported when it's in BACO state
[ Upstream commit
6dca7efe6e522bf213c7dab691fa580d82f48f74 ]
Return true early if ASIC is in BACO state already, no need
to talk to SMU. It can fix the issue that driver was not
calling BACO exit at all in runtime pm resume, and a timing
issue leading to a PCI AER error happened eventually.
Fixes:
8795e182b02d ("PCI/portdrv: Don't disable AER reporting in get_port_device_capability()")
Suggested-by: Lijo Lazar <lijo.lazar@amd.com>
Signed-off-by: Guchun Chen <guchun.chen@amd.com>
Reviewed-by: Lijo Lazar <lijo.lazar@amd.com>
Reviewed-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Daniel Golle [Wed, 26 Oct 2022 16:18:07 +0000 (17:18 +0100)]
clk: mediatek: fix dependency of MT7986 ADC clocks
[ Upstream commit
a46315295489933209e902638cd287aeb5f982ab ]
It seems like CLK_INFRA_ADC_FRC_CK always need to be enabled for
CLK_INFRA_ADC_26M_CK to work. Instead of adding this dependency to the
mtk-thermal and mt6577_auxadc drivers, add dependency to the clock
driver clk-mt7986-infracfg.c.
Fixes:
ec97d23c8e22 ("clk: mediatek: add mt7986 clock support")
Suggested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Link: https://lore.kernel.org/r/5e55012567da74870e1fb2edc2dc513b5821e523.1666801017.git.daniel@makrotopia.org
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ricardo Ribalda [Mon, 28 Nov 2022 10:49:16 +0000 (11:49 +0100)]
ASoC: mediatek: mt8173: Enable IRQ when pdata is ready
[ Upstream commit
4cbb264d4e9136acab2c8fd39e39ab1b1402b84b ]
If the device does not come straight from reset, we might receive an IRQ
before we are ready to handle it.
Fixes:
[ 2.334737] Unable to handle kernel read from unreadable memory at virtual address
00000000000001e4
[ 2.522601] Call trace:
[ 2.525040] regmap_read+0x1c/0x80
[ 2.528434] mt8173_afe_irq_handler+0x40/0xf0
...
[ 2.598921] start_kernel+0x338/0x42c
Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
Fixes:
ee0bcaff109f ("ASoC: mediatek: Add AFE platform driver")
Link: https://lore.kernel.org/r/20221128-mt8173-afe-v1-0-70728221628f@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ben Greear [Wed, 23 Nov 2022 21:02:06 +0000 (23:02 +0200)]
wifi: iwlwifi: mvm: fix double free on tx path.
[ Upstream commit
0473cbae2137b963bd0eaa74336131cb1d3bc6c3 ]
We see kernel crashes and lockups and KASAN errors related to ax210
firmware crashes. One of the KASAN dumps pointed at the tx path,
and it appears there is indeed a way to double-free an skb.
If iwl_mvm_tx_skb_sta returns non-zero, then the 'skb' sent into the
method will be freed. But, in case where we build TSO skb buffer,
the skb may also be freed in error case. So, return 0 in that particular
error case and do cleanup manually.
BUG: KASAN: use-after-free in __list_del_entry_valid+0x12/0x90
iwlwifi 0000:06:00.0: 0x00000000 | tsf hi
Read of size 8 at addr
ffff88813cfa4ba0 by task btserver/9650
CPU: 4 PID: 9650 Comm: btserver Tainted: G W 5.19.8+ #5
iwlwifi 0000:06:00.0: 0x00000000 | time gp1
Hardware name: Default string Default string/SKYBAY, BIOS 5.12 02/19/2019
Call Trace:
<TASK>
dump_stack_lvl+0x55/0x6d
print_report.cold.12+0xf2/0x684
iwlwifi 0000:06:00.0: 0x1D0915A8 | time gp2
? __list_del_entry_valid+0x12/0x90
kasan_report+0x8b/0x180
iwlwifi 0000:06:00.0: 0x00000001 | uCode revision type
? __list_del_entry_valid+0x12/0x90
__list_del_entry_valid+0x12/0x90
iwlwifi 0000:06:00.0: 0x00000048 | uCode version major
tcp_update_skb_after_send+0x5d/0x170
__tcp_transmit_skb+0xb61/0x15c0
iwlwifi 0000:06:00.0: 0xDAA05125 | uCode version minor
? __tcp_select_window+0x490/0x490
iwlwifi 0000:06:00.0: 0x00000420 | hw version
? trace_kmalloc_node+0x29/0xd0
? __kmalloc_node_track_caller+0x12a/0x260
? memset+0x1f/0x40
? __build_skb_around+0x125/0x150
? __alloc_skb+0x1d4/0x220
? skb_zerocopy_clone+0x55/0x230
iwlwifi 0000:06:00.0: 0x00489002 | board version
? kmalloc_reserve+0x80/0x80
? rcu_read_lock_bh_held+0x60/0xb0
tcp_write_xmit+0x3f1/0x24d0
iwlwifi 0000:06:00.0: 0x034E001C | hcmd
? __check_object_size+0x180/0x350
iwlwifi 0000:06:00.0: 0x24020000 | isr0
tcp_sendmsg_locked+0x8a9/0x1520
iwlwifi 0000:06:00.0: 0x01400000 | isr1
? tcp_sendpage+0x50/0x50
iwlwifi 0000:06:00.0: 0x48F0000A | isr2
? lock_release+0xb9/0x400
? tcp_sendmsg+0x14/0x40
iwlwifi 0000:06:00.0: 0x00C3080C | isr3
? lock_downgrade+0x390/0x390
? do_raw_spin_lock+0x114/0x1d0
iwlwifi 0000:06:00.0: 0x00200000 | isr4
? rwlock_bug.part.2+0x50/0x50
iwlwifi 0000:06:00.0: 0x034A001C | last cmd Id
? rwlock_bug.part.2+0x50/0x50
? lockdep_hardirqs_on_prepare+0xe/0x200
iwlwifi 0000:06:00.0: 0x0000C2F0 | wait_event
? __local_bh_enable_ip+0x87/0xe0
? inet_send_prepare+0x220/0x220
iwlwifi 0000:06:00.0: 0x000000C4 | l2p_control
tcp_sendmsg+0x22/0x40
sock_sendmsg+0x5f/0x70
iwlwifi 0000:06:00.0: 0x00010034 | l2p_duration
__sys_sendto+0x19d/0x250
iwlwifi 0000:06:00.0: 0x00000007 | l2p_mhvalid
? __ia32_sys_getpeername+0x40/0x40
iwlwifi 0000:06:00.0: 0x00000000 | l2p_addr_match
? rcu_read_lock_held_common+0x12/0x50
? rcu_read_lock_sched_held+0x5a/0xd0
? rcu_read_lock_bh_held+0xb0/0xb0
? rcu_read_lock_sched_held+0x5a/0xd0
? rcu_read_lock_sched_held+0x5a/0xd0
? lock_release+0xb9/0x400
? lock_downgrade+0x390/0x390
? ktime_get+0x64/0x130
? ktime_get+0x8d/0x130
? rcu_read_lock_held_common+0x12/0x50
? rcu_read_lock_sched_held+0x5a/0xd0
? rcu_read_lock_held_common+0x12/0x50
? rcu_read_lock_sched_held+0x5a/0xd0
? rcu_read_lock_bh_held+0xb0/0xb0
? rcu_read_lock_bh_held+0xb0/0xb0
__x64_sys_sendto+0x6f/0x80
do_syscall_64+0x34/0xb0
entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f1d126e4531
Code: 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 35 80 0c 00 41 89 ca 8b 00 85 c0 75 1c 45 31 c9 45 31 c0 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89
RSP: 002b:
00007ffe21a679d8 EFLAGS:
00000246 ORIG_RAX:
000000000000002c
RAX:
ffffffffffffffda RBX:
000000000000ffdc RCX:
00007f1d126e4531
RDX:
0000000000010000 RSI:
000000000374acf0 RDI:
0000000000000014
RBP:
00007ffe21a67ac0 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000246 R12:
0000000000000010
R13:
0000000000000000 R14:
0000000000000001 R15:
0000000000000000
</TASK>
Allocated by task 9650:
kasan_save_stack+0x1c/0x40
__kasan_slab_alloc+0x6d/0x90
kmem_cache_alloc_node+0xf3/0x2b0
__alloc_skb+0x191/0x220
tcp_stream_alloc_skb+0x3f/0x330
tcp_sendmsg_locked+0x67c/0x1520
tcp_sendmsg+0x22/0x40
sock_sendmsg+0x5f/0x70
__sys_sendto+0x19d/0x250
__x64_sys_sendto+0x6f/0x80
do_syscall_64+0x34/0xb0
entry_SYSCALL_64_after_hwframe+0x46/0xb0
Freed by task 9650:
kasan_save_stack+0x1c/0x40
kasan_set_track+0x21/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0x102/0x170
kmem_cache_free+0xc8/0x3e0
iwl_mvm_mac_itxq_xmit+0x124/0x270 [iwlmvm]
ieee80211_queue_skb+0x874/0xd10 [mac80211]
ieee80211_xmit_fast+0xf80/0x1180 [mac80211]
__ieee80211_subif_start_xmit+0x287/0x680 [mac80211]
ieee80211_subif_start_xmit+0xcd/0x730 [mac80211]
dev_hard_start_xmit+0xf6/0x420
__dev_queue_xmit+0x165b/0x1b50
ip_finish_output2+0x66e/0xfb0
__ip_finish_output+0x487/0x6d0
ip_output+0x11c/0x350
__ip_queue_xmit+0x36b/0x9d0
__tcp_transmit_skb+0xb35/0x15c0
tcp_write_xmit+0x3f1/0x24d0
tcp_sendmsg_locked+0x8a9/0x1520
tcp_sendmsg+0x22/0x40
sock_sendmsg+0x5f/0x70
__sys_sendto+0x19d/0x250
__x64_sys_sendto+0x6f/0x80
do_syscall_64+0x34/0xb0
entry_SYSCALL_64_after_hwframe+0x46/0xb0
The buggy address belongs to the object at
ffff88813cfa4b40
which belongs to the cache skbuff_fclone_cache of size 472
The buggy address is located 96 bytes inside of
472-byte region [
ffff88813cfa4b40,
ffff88813cfa4d18)
The buggy address belongs to the physical page:
page:
ffffea0004f3e900 refcount:1 mapcount:0 mapping:
0000000000000000 index:0xffff88813cfa6c40 pfn:0x13cfa4
head:
ffffea0004f3e900 order:2 compound_mapcount:0 compound_pincount:0
flags: 0x5fff8000010200(slab|head|node=0|zone=2|lastcpupid=0x3fff)
raw:
005fff8000010200 ffffea0004656b08 ffffea0008e8cf08 ffff8881081a5240
raw:
ffff88813cfa6c40 0000000000170015 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88813cfa4a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88813cfa4b00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb
>
ffff88813cfa4b80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88813cfa4c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88813cfa4c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Fixes:
08f7d8b69aaf ("iwlwifi: mvm: bring back mvm GSO code")
Link: https://lore.kernel.org/linux-wireless/20220928193057.16132-1-greearb@candelatech.com/
Tested-by: Amol Jawale <amol.jawale@candelatech.com>
Signed-off-by: Ben Greear <greearb@candelatech.com>
Link: https://lore.kernel.org/r/20221123225313.21b1ee31d666.I3b3ba184433dd2a544d91eeeda29b467021824ae@changeid
Signed-off-by: Gregory Greenman <gregory.greenman@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bitterblue Smith [Mon, 21 Nov 2022 20:56:58 +0000 (22:56 +0200)]
wifi: rtl8xxxu: Fix use after rcu_read_unlock in rtl8xxxu_bss_info_changed
[ Upstream commit
7927afb5e27baac694f585b59c436ba323528dc2 ]
Commit
a8b5aef2cca1 ("wifi: rtl8xxxu: gen2: Enable 40 MHz channel width")
introduced a line where the pointer returned by ieee80211_find_sta() is
used after rcu_read_unlock().
Move rcu_read_unlock() a bit lower to fix this.
Fixes:
a8b5aef2cca1 ("wifi: rtl8xxxu: gen2: Enable 40 MHz channel width")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/3c82ad09-7593-3be1-1d2c-e58505fb43cb@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ziyang Xuan [Sat, 19 Nov 2022 05:19:00 +0000 (13:19 +0800)]
wifi: plfxlc: fix potential memory leak in __lf_x_usb_enable_rx()
[ Upstream commit
895b3b06efc285c1245242e9638b9ae251dc13ec ]
urbs does not be freed in exception paths in __lf_x_usb_enable_rx().
That will trigger memory leak. To fix it, add kfree() for urbs within
"error" label. Compile tested only.
Fixes:
68d57a07bfe5 ("wireless: add plfxlc driver for pureLiFi X, XL, XC devices")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221119051900.1192401-1-william.xuanziyang@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Liu Shixin [Sat, 26 Nov 2022 02:14:29 +0000 (10:14 +0800)]
ALSA: asihpi: fix missing pci_disable_device()
[ Upstream commit
9d86515c3d4c0564a0c31a2df87d735353a1971e ]
pci_disable_device() need be called while module exiting, switch to use
pcim_enable(), pci_disable_device() will be called in pcim_release().
Fixes:
3285ea10e9b0 ("ALSA: asihpi - Interrelated HPI tidy up.")
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Link: https://lore.kernel.org/r/20221126021429.3029562-1-liushixin2@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trond Myklebust [Mon, 14 Nov 2022 22:30:39 +0000 (17:30 -0500)]
NFS: Fix an Oops in nfs_d_automount()
[ Upstream commit
35e3b6ae84935d0d7ff76cbdaa83411b0ad5e471 ]
When mounting from a NFSv4 referral, path->dentry can end up being a
negative dentry, so derive the struct nfs_server from the dentry
itself instead.
Fixes:
2b0143b5c986 ("VFS: normal filesystems (and lustre): d_inode() annotations")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trond Myklebust [Fri, 4 Nov 2022 17:20:01 +0000 (13:20 -0400)]
NFSv4: Fix a deadlock between nfs4_open_recover_helper() and delegreturn
[ Upstream commit
51069e4aef6257b0454057359faed0ab0c9af083 ]
If we're asked to recover open state while a delegation return is
outstanding, then the state manager thread cannot use a cached open, so
if the server returns a delegation, we can end up deadlocked behind the
pending delegreturn.
To avoid this problem, let's just ask the server not to give us a
delegation unless we're explicitly reclaiming one.
Fixes:
be36e185bd26 ("NFSv4: nfs4_open_recover_helper() must set share access")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trond Myklebust [Thu, 27 Oct 2022 20:50:12 +0000 (16:50 -0400)]
NFSv4: Fix a credential leak in _nfs4_discover_trunking()
[ Upstream commit
e83458fce080dc23c25353a1af90bfecf79c7369 ]
Fixes:
4f40a5b55446 ("NFSv4: Add an fattr allocation to _nfs4_discover_trunking()")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trond Myklebust [Wed, 19 Oct 2022 17:12:11 +0000 (13:12 -0400)]
NFSv4.2: Fix initialisation of struct nfs4_label
[ Upstream commit
c528f70f504434eaff993a5ddd52203a2010d51f ]
The call to nfs4_label_init_security() should return a fully initialised
label.
Fixes:
aa9c2669626c ("NFS: Client implementation of Labeled-NFS")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trond Myklebust [Tue, 18 Oct 2022 22:21:14 +0000 (18:21 -0400)]
NFSv4.2: Fix a memory stomp in decode_attr_security_label
[ Upstream commit
43c1031f7110967c240cb6e922adcfc4b8899183 ]
We must not change the value of label->len if it is zero, since that
indicates we stored a label.
Fixes:
b4487b935452 ("nfs: Fix getxattr kernel panic and memory overflow")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trond Myklebust [Tue, 18 Oct 2022 21:41:30 +0000 (17:41 -0400)]
NFSv4.2: Always decode the security label
[ Upstream commit
c8a62f440229ae7a10874776344dfcc17d860336 ]
If the server returns a reply that includes a security label, then we
must decode it whether or not we can store the results.
Fixes:
1e2f67da8931 ("NFS: Remove the nfs4_label argument from decode_getattr_*() functions")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trond Myklebust [Tue, 18 Oct 2022 20:44:47 +0000 (16:44 -0400)]
NFSv4.2: Clear FATTR4_WORD2_SECURITY_LABEL when done decoding
[ Upstream commit
eef7314caf2d73a94b68ba293cd105154d3a664e ]
We need to clear the FATTR4_WORD2_SECURITY_LABEL bitmap flag
irrespective of whether or not the label is too long.
Fixes:
aa9c2669626c ("NFS: Client implementation of Labeled-NFS")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dmitry Baryshkov [Fri, 25 Nov 2022 00:02:13 +0000 (02:02 +0200)]
drm/msm/mdp5: fix reading hw revision on db410c platform
[ Upstream commit
5d8c0417ea62fed3cec7f5daed06a20477efeb39 ]
Since the commit commit
c6122688f265 ("drm/msm/mdp5: stop overriding
drvdata") reading the MDP5 hw revision on db410c will crash the board
as the MDSS_GDSC is not enabled. Revert a part of the offending commit
(moving rpm enablement) and set priv->kms earlier. This make it possible
to use pm_runtime_get_sync() during read_mdp_hw_revision(), which will
power up both the MDP5 and MDSS devices.
Fixes:
c6122688f265 ("drm/msm/mdp5: stop overriding drvdata")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/512985/
Link: https://lore.kernel.org/r/20221125000213.252115-1-dmitry.baryshkov@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Wed, 16 Nov 2022 03:07:50 +0000 (11:07 +0800)]
ASoC: mediatek: mtk-btcvsd: Add checks for write and read of mtk_btcvsd_snd
[ Upstream commit
d067b3378a78c9c3048ac535e31c171b6f5b5846 ]
As the mtk_btcvsd_snd_write and mtk_btcvsd_snd_read may return error,
it should be better to catch the exception.
Fixes:
4bd8597dc36c ("ASoC: mediatek: add btcvsd driver")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Link: https://lore.kernel.org/r/20221116030750.40500-1-jiasheng@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dmitry Torokhov [Thu, 27 Oct 2022 07:46:48 +0000 (00:46 -0700)]
ASoC: dt-bindings: wcd9335: fix reset line polarity in example
[ Upstream commit
34cb111f8a7b98b5fec809dd194003bca20ef1b2 ]
When resetting the block, the reset line is being driven low and then
high, which means that the line in DTS should be annotated as "active
low".
Fixes:
1877c9fda1b7 ("ASoC: dt-bindings: add dt bindings for wcd9335 audio codec")
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20221027074652.1044235-2-dmitry.torokhov@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Zekun [Tue, 2 Aug 2022 08:50:50 +0000 (08:50 +0000)]
drm/tegra: Add missing clk_disable_unprepare() in tegra_dc_probe()
[ Upstream commit
7ad4384d53c67672a8720cdc2ef638d7d1710ab8 ]
Add the missing clk_disable_unprepare() before return from
tegra_dc_probe() in the error handling path.
Fixes:
f68ba6912bd2 ("drm/tegra: dc: Link DC1 to DC0 on Tegra20")
Signed-off-by: Zhang Zekun <zhangzekun11@huawei.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Aakarsh Jain [Mon, 14 Nov 2022 11:50:23 +0000 (11:50 +0000)]
media: s5p-mfc: Add variant data for MFC v7 hardware for Exynos 3250 SoC
[ Upstream commit
f50ebe10f5d8092c37e2bd430c78e03bf38b1e20 ]
Commit
5441e9dafdfc6dc40 ("[media] s5p-mfc: Core support for MFC v7")
which adds mfc v7 support for Exynos3250 and use the same compatible
string as used by Exynos5240 but both the IPs are a bit different in
terms of IP clock.
Add variant driver data based on the new compatible string
"samsung,exynos3250-mfc" for Exynos3250 SoC.
Suggested-by: Alim Akhtar <alim.akhtar@samsung.com>
Fixes:
5441e9dafdfc ("[media] s5p-mfc: Core support for MFC v7")
Signed-off-by: Aakarsh Jain <aakarsh.jain@samsung.com>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yunfei Dong [Thu, 17 Nov 2022 09:24:53 +0000 (09:24 +0000)]
media: mediatek: vcodec: Core thread depends on core_list
[ Upstream commit
95bc23513c9188065a22194f9af870376fc38fdd ]
Core thread will continue to work when core_list is not empty, not
depends on lat_list.
Fixes:
365e4ba01df4 ("media: mtk-vcodec: Add work queue for core hardware decode")
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yunfei Dong [Thu, 17 Nov 2022 09:24:52 +0000 (09:24 +0000)]
media: mediatek: vcodec: Setting lat buf to lat_list when lat decode error
[ Upstream commit
12ac20d60213a439d1552382d04aabb905e0b784 ]
Need to set lat buf to lat_list when lat decode error, or lat buffer will
be lost.
Fixes:
5d418351ca8f ("media: mediatek: vcodec: support stateless VP9 decoding")
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yunfei Dong [Thu, 17 Nov 2022 09:24:51 +0000 (09:24 +0000)]
media: mediatek: vcodec: Fix h264 set lat buffer error
[ Upstream commit
23d677bd9cdd10323e6d290578bbb0a408f43499 ]
Will set lat buffer to lat_list two times when lat decode timeout for
inner racing mode.
If core thread can't get frame buffer, need to return error value.
Fixes:
59fba9eed5a7 ("media: mediatek: vcodec: support stateless H.264 decoding for mt8192")
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yunfei Dong [Thu, 17 Nov 2022 09:24:49 +0000 (09:24 +0000)]
media: mediatek: vcodec: Fix getting NULL pointer for dst buffer
[ Upstream commit
d879f770e4d1d5f0d9b692d3a2702f23ee441dbb ]
The driver may can't get v4l2 buffer when lat or core decode timeout,
will lead to crash when call v4l2_m2m_buf_done to set dst buffer
(NULL pointer) done.
Fixes:
7b182b8d9c85 ("media: mediatek: vcodec: Refactor get and put capture buffer flow")
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ming Qian [Mon, 21 Nov 2022 06:34:42 +0000 (06:34 +0000)]
media: amphion: lock and check m2m_ctx in event handler
[ Upstream commit
1ade3f3f16986cd7c6fce02feede957f03eb8a42 ]
driver needs to cancel vpu before releasing the vpu instance,
so call v4l2_m2m_ctx_release() first,
to handle the redundant event triggered after m2m_ctx is released.
lock and check m2m_ctx in the event handler.
Fixes:
3cd084519c6f ("media: amphion: add vpu v4l2 m2m support")
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ming Qian [Mon, 21 Nov 2022 06:34:07 +0000 (06:34 +0000)]
media: amphion: cancel vpu before release instance
[ Upstream commit
b3dd974af9de342c733492565ad02d7e23372876 ]
Revert "media: amphion: release m2m ctx when releasing vpu instance"
This reverts commit
d91d7bc85062309aae6d8064563ddf17947cb6bc.
Call v4l2_m2m_ctx_release() to cancel vpu,
afterwards release the vpu instance.
Fixes:
d91d7bc85062 ("media: amphion: release m2m ctx when releasing vpu instance")
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ming Qian [Fri, 18 Nov 2022 08:51:29 +0000 (08:51 +0000)]
media: amphion: try to wakeup vpu core to avoid failure
[ Upstream commit
082744433f7b96db7214a98202ed96f367684693 ]
firmware should be waked up by start or configure command,
but there is a very small chance that firmware failed to wakeup.
in such case, try to wakeup firmware again by sending a noop command
Fixes:
6de8d628df6e ("media: amphion: add v4l2 m2m vpu decoder stateful driver")
Signed-off-by: Ming Qian <ming.qian@nxp.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul Kocialkowski [Fri, 9 Sep 2022 13:39:54 +0000 (14:39 +0100)]
media: sun8i-a83t-mipi-csi2: Register async subdev with no sensor attached
[ Upstream commit
614f6e35a9e214c80270ab942bf58d85066a3e34 ]
This allows the device to probe and register its async subdev without
a sensor attached.
The rationale is that the parent driver might otherwise wait for the
subdev to be registered when it should be available (from the fwnode
graph endpoint perspective). This is generally not problematic when
the MIPI CSI-2 bridge is the only device attached to the parent, but
in the case of a CSI controller that can feed from both MIPI CSI-2
and parallel, it would prevent using the parallel sensor due to the
parent waiting for the MIPI CSI-2 subdev to register.
Fixes:
576d196c522b ("media: sunxi: Add support for the A83T MIPI CSI-2 controller")
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul Kocialkowski [Fri, 9 Sep 2022 13:39:53 +0000 (14:39 +0100)]
media: sun6i-mipi-csi2: Register async subdev with no sensor attached
[ Upstream commit
67182951f1dde5a88479cf8befee5f32ea014a49 ]
This allows the device to probe and register its async subdev without
a sensor attached.
The rationale is that the parent driver might otherwise wait for the
subdev to be registered when it should be available (from the fwnode
graph endpoint perspective). This is generally not problematic when
the MIPI CSI-2 bridge is the only device attached to the parent, but
in the case of a CSI controller that can feed from both MIPI CSI-2
and parallel, it would prevent using the parallel sensor due to the
parent waiting for the MIPI CSI-2 subdev to register.
Fixes:
af54b4f4c17f ("media: sunxi: Add support for the A31 MIPI CSI-2 controller")
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul Kocialkowski [Fri, 9 Sep 2022 13:39:52 +0000 (14:39 +0100)]
media: sun8i-a83t-mipi-csi2: Require both pads to be connected for streaming
[ Upstream commit
8985fc724ba89d9b00694304b3f9faf69f4073d0 ]
The bridge needs both its pads connected to be able to stream data.
Enforcing this is useful to produce an error when no sensor is
connected.
Fixes:
576d196c522b ("media: sunxi: Add support for the A83T MIPI CSI-2 controller")
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul Kocialkowski [Fri, 9 Sep 2022 13:39:51 +0000 (14:39 +0100)]
media: sun6i-mipi-csi2: Require both pads to be connected for streaming
[ Upstream commit
f042b08b833de3be810f8769d88ca44aeefd7eba ]
The bridge needs both its pads connected to be able to stream data.
Enforcing this is useful to produce an error when no sensor is
connected.
Fixes:
af54b4f4c17f ("media: sunxi: Add support for the A31 MIPI CSI-2 controller")
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Juergen Gross [Wed, 23 Nov 2022 11:45:23 +0000 (12:45 +0100)]
x86/boot: Skip realmode init code when running as Xen PV guest
[ Upstream commit
f1e525009493cbd569e7c8dd7d58157855f8658d ]
When running as a Xen PV guest there is no need for setting up the
realmode trampoline, as realmode isn't supported in this environment.
Trying to setup the trampoline has been proven to be problematic in
some cases, especially when trying to debug early boot problems with
Xen requiring to keep the EFI boot-services memory mapped (some
firmware variants seem to claim basically all memory below 1Mb for boot
services).
Introduce new x86_platform_ops operations for that purpose, which can
be set to a NOP by the Xen PV specific kernel boot code.
[ bp: s/call_init_real_mode/do_init_real_mode/ ]
Fixes:
084ee1c641a0 ("x86, realmode: Relocator for realmode code")
Suggested-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lore.kernel.org/r/20221123114523.3467-1-jgross@suse.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Baisong Zhong [Sun, 20 Nov 2022 06:59:18 +0000 (06:59 +0000)]
media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()
[ Upstream commit
0ed554fd769a19ea8464bb83e9ac201002ef74ad ]
Wei Chen reports a kernel bug as blew:
general protection fault, probably for non-canonical address
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
...
Call Trace:
<TASK>
__i2c_transfer+0x77e/0x1930 drivers/i2c/i2c-core-base.c:2109
i2c_transfer+0x1d5/0x3d0 drivers/i2c/i2c-core-base.c:2170
i2cdev_ioctl_rdwr+0x393/0x660 drivers/i2c/i2c-dev.c:297
i2cdev_ioctl+0x75d/0x9f0 drivers/i2c/i2c-dev.c:458
vfs_ioctl fs/ioctl.c:51 [inline]
__do_sys_ioctl fs/ioctl.c:870 [inline]
__se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fd834a8bded
In az6027_i2c_xfer(), if msg[i].addr is 0x99,
a null-ptr-deref will caused when accessing msg[i].buf.
For msg[i].len is 0 and msg[i].buf is null.
Fix this by checking msg[i].len in az6027_i2c_xfer().
Link: https://lore.kernel.org/lkml/CAO4mrfcPHB5aQJO=mpqV+p8mPLNg-Fok0gw8gZ=zemAfMGTzMg@mail.gmail.com/
Link: https://lore.kernel.org/linux-media/20221120065918.2160782-1-zhongbaisong@huawei.com
Fixes:
76f9a820c867 ("V4L/DVB: AZ6027: Initial import of the driver")
Reported-by: Wei Chen <harperchen1110@gmail.com>
Signed-off-by: Baisong Zhong <zhongbaisong@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chen Zhongjin [Tue, 8 Nov 2022 03:30:05 +0000 (03:30 +0000)]
media: dvb-core: Fix ignored return value in dvb_register_frontend()
[ Upstream commit
a574359e2e71ce16be212df3a082ed60a4bd2c5f ]
In dvb_register_frontend(), dvb_register_device() is possible to fail
but its return value is ignored.
It will cause use-after-free when module is removed, because in
dvb_unregister_frontend() it tries to unregister a not registered
device.
BUG: KASAN: use-after-free in dvb_remove_device+0x18b/0x1f0 [dvb_core]
Read of size 4 at addr
ffff88800dff4824 by task rmmod/428
CPU: 3 PID: 428 Comm: rmmod
Call Trace:
<TASK>
...
dvb_remove_device+0x18b/0x1f0 [dvb_core]
dvb_unregister_frontend+0x7b/0x130 [dvb_core]
vidtv_bridge_remove+0x6e/0x160 [dvb_vidtv_bridge]
...
Fix this by catching return value of dvb_register_device().
However the fe->refcount can't be put to zero immediately, because
there are still modules calling dvb_frontend_detach() when
dvb_register_frontend() fails.
Link: https://lore.kernel.org/linux-media/20221108033005.169095-1-chenzhongjin@huawei.com
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ZhangPeng [Fri, 25 Nov 2022 07:01:56 +0000 (07:01 +0000)]
pinctrl: pinconf-generic: add missing of_node_put()
[ Upstream commit
5ead93289815a075d43c415e35c8beafafb801c9 ]
of_node_put() needs to be called when jumping out of the loop, since
for_each_available_child_of_node() will increase the refcount of node.
Fixes:
c7289500e29d ("pinctrl: pinconf-generic: scan also referenced phandle node")
Signed-off-by: ZhangPeng <zhangpeng362@huawei.com>
Link: https://lore.kernel.org/r/20221125070156.3535855-1-zhangpeng362@huawei.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dario Binacchi [Thu, 17 Nov 2022 11:36:37 +0000 (12:36 +0100)]
clk: imx8mn: fix imx8mn_enet_phy_sels clocks list
[ Upstream commit
2626cf67f20b28446dfc3a5b9493dd535cdb747b ]
According to the "Clock Root" table of the reference manual (document
IMX8MNRM Rev 2, 07/2022):
Clock Root offset Source Select (CCM_TARGET_ROOTn[MUX])
... ... ...
ENET_PHY_REF_CLK_ROOT 0xAA80 000 - 24M_REF_CLK
001 - SYSTEM_PLL2_DIV20
010 - SYSTEM_PLL2_DIV8
011 - SYSTEM_PLL2_DIV5
100 - SYSTEM_PLL2_DIV2
101 - AUDIO_PLL1_CLK
110 - VIDEO_PLL_CLK
111 - AUDIO_PLL2_CLK
... ... ...
while the imx8mn_enet_phy_sels list didn't contained audio_pll1_out for
source select bits 101b.
Fixes:
96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221117113637.1978703-6-dario.binacchi@amarulasolutions.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dario Binacchi [Thu, 17 Nov 2022 11:36:36 +0000 (12:36 +0100)]
clk: imx8mn: fix imx8mn_sai2_sels clocks list
[ Upstream commit
34d996747a74e3a86990f9f9c48de09159d78edb ]
According to the "Clock Root" table of the reference manual (document
IMX8MNRM Rev 2, 07/2022):
Clock Root offset Source Select (CCM_TARGET_ROOTn[MUX])
... ... ...
SAI2_CLK_ROOT 0xA600 000 - 24M_REF_CLK
001 - AUDIO_PLL1_CLK
010 - AUDIO_PLL2_CLK
011 - VIDEO_PLL_CLK
100 - SYSTEM_PLL1_DIV6
110 - EXT_CLK_2
111 - EXT_CLK_3
... ... ...
while the imx8mn_sai2_sels list contained clk_ext3 and clk_ext4 for
source select bits 110b and 111b.
Fixes:
96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221117113637.1978703-5-dario.binacchi@amarulasolutions.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dario Binacchi [Thu, 17 Nov 2022 11:36:35 +0000 (12:36 +0100)]
clk: imx: rename video_pll1 to video_pll
[ Upstream commit
bedcf9d1dcf88ed38731f0ac9620e5a421e1e9d6 ]
Unlike audio_pll1 and audio_pll2, there is no video_pll2. Further, the
name used in the RM is video_pll. So, let's rename "video_pll1" to
"video_pll" to be consistent with the RM and avoid misunderstandings.
The IMX8MN_VIDEO_PLL1* constants have not been removed to ensure
backward compatibility of the patch.
No functional changes intended.
Fixes:
96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221117113637.1978703-4-dario.binacchi@amarulasolutions.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dario Binacchi [Thu, 17 Nov 2022 11:36:34 +0000 (12:36 +0100)]
clk: imx: replace osc_hdmi with dummy
[ Upstream commit
e7fa365ff66f16772dc06b480cd78f858d10856b ]
There is no occurrence of the hdmi oscillator in the reference manual
(document IMX8MNRM Rev 2, 07/2022). Further, if we consider the indexes
76-81 and 134 of the "Clock Root" table of chapter 5 of the RM, there is
no entry for the source select bits 101b, which is the setting referenced
by "osc_hdmi".
Fix by renaming "osc_hdmi" with "dummy", a clock which has already been
used for missing source select bits.
Tested on the BSH SystemMaster (SMM) S2 board.
Fixes:
96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221117113637.1978703-3-dario.binacchi@amarulasolutions.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dario Binacchi [Thu, 17 Nov 2022 11:36:33 +0000 (12:36 +0100)]
clk: imx8mn: rename vpu_pll to m7_alt_pll
[ Upstream commit
a429c60baefd95ab43a2ce7f25d5b2d7a2e431df ]
The IMX8MN platform does not have any video processing unit (VPU), and
indeed in the reference manual (document IMX8MNRM Rev 2, 07/2022) there
is no occurrence of its pll. From an analysis of the code and the RM
itself, I think vpu pll is used instead of m7 alternate pll, probably
for copy and paste of code taken from modules of similar architectures.
As an example for all, if we consider the second row of the "Clock Root"
table of chapter 5 (Clocks and Power Management) of the RM:
Clock Root offset Source Select (CCM_TARGET_ROOTn[MUX])
... ... ...
ARM_M7_CLK_ROOT 0x8080 000 - 24M_REF_CLK
001 - SYSTEM_PLL2_DIV5
010 - SYSTEM_PLL2_DIV4
011 - M7_ALT_PLL_CLK
100 - SYSTEM_PLL1_CLK
101 - AUDIO_PLL1_CLK
110 - VIDEO_PLL_CLK
111 - SYSTEM_PLL3_CLK
... ... ...
but in the source code, the imx8mn_m7_sels clocks list contains vpu_pll
for the source select bits 011b.
So, let's rename "vpu_pll" to "m7_alt_pll" to be consistent with the RM.
The IMX8MN_VPU_* constants have not been removed to ensure backward
compatibility of the patch.
No functional changes intended.
Fixes:
96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Acked-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20221117113637.1978703-2-dario.binacchi@amarulasolutions.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marek Vasut [Sun, 20 Nov 2022 14:13:04 +0000 (14:13 +0000)]
media: mt9p031: Drop bogus v4l2_subdev_get_try_crop() call from mt9p031_init_cfg()
[ Upstream commit
e208ad015f9310a87b4bb1ba1e4d3e347f391aa4 ]
The mt9p031_init_cfg() already calls __mt9p031_get_pad_crop(), which
correctly calls v4l2_subdev_get_try_crop() on V4L2_SUBDEV_FORMAT_TRY
or returns &mt9p031->crop on V4L2_SUBDEV_FORMAT_ACTIVE. No need to
call v4l2_subdev_get_try_crop() in mt9p031_init_cfg() again in case
of both V4L2_SUBDEV_FORMAT_TRY and V4L2_SUBDEV_FORMAT_ACTIVE.
This also fixes a splat generated by this call since commit
2ba3e38517f5a ("media: v4l: subdev: Fail graciously when getting try data for NULL state")
because v4l2_subdev_get_try_crop() is called with sd_state = NULL
in mt9p031_init_cfg().
Fixes:
69681cd041648 ("media: mt9p031: Move open subdev op init code into init_cfg")
Signed-off-by: Marek Vasut <marex@denx.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Laurent Pinchart [Wed, 7 Sep 2022 18:42:16 +0000 (19:42 +0100)]
media: imx: imx7-media-csi: Clear BIT_MIPI_DOUBLE_CMPNT for <16b formats
[ Upstream commit
cccc08a95ca57624563daafd47df5691e8c38995 ]
Commit
9babbbaaeb87 ("media: imx: imx7-media-csi: Use dual sampling for
YUV 1X16") set BIT_MIPI_DOUBLE_CMPNT in the CR18 register for 16-bit YUV
formats in imx7_csi_configure(). The CR18 register is always updated
with read-modify-write cycles, so if a 16-bit YUV format is selected,
the bit will stay set forever, even if the format is changed. Fix it by
clearing the bit at the beginning of the imx7_csi_configure() function.
While at it, swap two of the bits being cleared to match the MSB to LSB
order. This doesn't cause any functional change.
Fixes:
9babbbaaeb87 ("media: imx: imx7-media-csi: Use dual sampling for YUV 1X16")
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Paul Elder <paul.elder@ideasonboard.com>
Acked-by: Rui Miguel Silva <rmfrfs@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gautam Menghani [Wed, 19 Oct 2022 05:02:14 +0000 (06:02 +0100)]
media: imon: fix a race condition in send_packet()
[ Upstream commit
813ceef062b53d68f296aa3cb944b21a091fabdb ]
The function send_packet() has a race condition as follows:
func send_packet()
{
// do work
call usb_submit_urb()
mutex_unlock()
wait_for_event_interruptible() <-- lock gone
mutex_lock()
}
func vfd_write()
{
mutex_lock()
call send_packet() <- prev call is not completed
mutex_unlock()
}
When the mutex is unlocked and the function send_packet() waits for the
call to complete, vfd_write() can start another call, which leads to the
"URB submitted while active" warning in usb_submit_urb().
Fix this by removing the mutex_unlock() call in send_packet() and using
mutex_lock_interruptible().
Link: https://syzkaller.appspot.com/bug?id=e378e6a51fbe6c5cc43e34f131cc9a315ef0337e
Fixes:
21677cfc562a ("V4L/DVB: ir-core: add imon driver")
Reported-by: syzbot+0c3cb6dc05fbbdc3ad66@syzkaller.appspotmail.com
Signed-off-by: Gautam Menghani <gautammenghani201@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chen Zhongjin [Thu, 10 Nov 2022 07:26:33 +0000 (07:26 +0000)]
media: vimc: Fix wrong function called when vimc_init() fails
[ Upstream commit
f74d3f326d1d5b8951ce263c59a121ecfa65e7c0 ]
In vimc_init(), when platform_driver_register(&vimc_pdrv) fails,
platform_driver_unregister(&vimc_pdrv) is wrongly called rather than
platform_device_unregister(&vimc_pdev), which causes kernel warning:
Unexpected driver unregister!
WARNING: CPU: 1 PID: 14517 at drivers/base/driver.c:270 driver_unregister+0x8f/0xb0
RIP: 0010:driver_unregister+0x8f/0xb0
Call Trace:
<TASK>
vimc_init+0x7d/0x1000 [vimc]
do_one_initcall+0xd0/0x4e0
do_init_module+0x1cf/0x6b0
load_module+0x65c2/0x7820
Fixes:
4a29b7090749 ("[media] vimc: Subdevices as modules")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiaxin Yu [Thu, 24 Nov 2022 02:30:50 +0000 (10:30 +0800)]
ASoC: mediatek: mt8186: Correct I2S shared clocks
[ Upstream commit
248579fc9a4f3bf36e7cfe9f6a354cee0f9848dc ]
In mt8186 platform, I2S2 should be the main I2S port that provide
the clock, on the contrary I2S3 should be the second I2S port that
use this clock.
Fixes:
9986bdaee477 ("ASoC: mediatek: mt8186: Configure shared clocks")
Signed-off-by: Jiaxin Yu <jiaxin.yu@mediatek.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20221124023050.4470-1-jiaxin.yu@mediatek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Srinivas Kandagatla [Thu, 24 Nov 2022 14:03:51 +0000 (14:03 +0000)]
ASoC: qcom: cleanup and fix dependency of QCOM_COMMON
[ Upstream commit
8d89cf6ff229ff31cd4f73f5b3928564b81fc41e ]
SND_SOC_QCOM_COMMON depends on SOUNDWIRE for some symbols but this
is not explicitly specified using Kconfig depends. On the other hand
SND_SOC_QCOM_COMMON is also directly selected by the sound card
Kconfigs, this could result in various combinations and some symbols
ending up in modules and soundcard that uses those symbols as in-build
driver.
Fix these issues by explicitly specifying the dependencies of
SND_SOC_QCOM_COMMON and also use imply a to select SND_SOC_QCOM_COMMON
so that the symbol is selected based on its dependencies.
Also remove dummy stubs in common.c around CONFIG_SOUNDWIRE
Fixes:
3bd975f3ae0a ("ASoC: qcom: sm8250: move some code to common")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20221124140351.407506-1-srinivas.kandagatla@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yuan Can [Thu, 24 Nov 2022 14:05:10 +0000 (14:05 +0000)]
ASoC: qcom: Add checks for devm_kcalloc
[ Upstream commit
1bf5ee979076ceb121ee51c95197d890b1cee7f4 ]
As the devm_kcalloc may return NULL, the return value needs to be checked
to avoid NULL poineter dereference.
Fixes:
24caf8d9eb10 ("ASoC: qcom: lpass-sc7180: Add platform driver for lpass audio")
Signed-off-by: Yuan Can <yuancan@huawei.com>
Link: https://lore.kernel.org/r/20221124140510.63468-1-yuancan@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang ShaoBo [Thu, 24 Nov 2022 01:58:17 +0000 (09:58 +0800)]
drbd: destroy workqueue when drbd device was freed
[ Upstream commit
8692814b77ca4228a99da8a005de0acf40af6132 ]
A submitter workqueue is dynamically allocated by init_submitter()
called by drbd_create_device(), we should destroy it when this
device is not needed or destroyed.
Fixes:
113fef9e20e0 ("drbd: prepare to queue write requests on a submit worker")
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
Link: https://lore.kernel.org/r/20221124015817.2729789-3-bobo.shaobowang@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang ShaoBo [Thu, 24 Nov 2022 01:58:16 +0000 (09:58 +0800)]
drbd: remove call to memset before free device/resource/connection
[ Upstream commit
6e7b854e4c1b02dba00760dfa79d8dbf6cce561e ]
This revert
c2258ffc56f2 ("drbd: poison free'd device, resource and
connection structs"), add memset is odd here for debugging, there are
some methods to accurately show what happened, such as kdump.
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
Link: https://lore.kernel.org/r/20221124015817.2729789-2-bobo.shaobowang@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Stable-dep-of:
8692814b77ca ("drbd: destroy workqueue when drbd device was freed")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zheng Yongjun [Sat, 19 Nov 2022 07:33:07 +0000 (07:33 +0000)]
mtd: maps: pxa2xx-flash: fix memory leak in probe
[ Upstream commit
2399401feee27c639addc5b7e6ba519d3ca341bf ]
Free 'info' upon remapping error to avoid a memory leak.
Fixes:
e644f7d62894 ("[MTD] MAPS: Merge Lubbock and Mainstone drivers into common PXA2xx driver")
Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com>
[<miquel.raynal@bootlin.com>: Reword the commit log]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20221119073307.22929-1-zhengyongjun3@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shang XiaoJing [Sat, 19 Nov 2022 06:39:15 +0000 (14:39 +0800)]
mtd: core: Fix refcount error in del_mtd_device()
[ Upstream commit
56570bdad5e31c5c538cd6efff5c4510256e1bb4 ]
del_mtd_device() will call of_node_put() to mtd_get_of_node(mtd), which
is mtd->dev.of_node. However, memset(&mtd->dev, 0) is called before
of_node_put(). As the result, of_node_put() won't do anything in
del_mtd_device(), and causes the refcount leak.
del_mtd_device()
memset(&mtd->dev, 0, sizeof(mtd->dev) # clear mtd->dev
of_node_put()
mtd_get_of_node(mtd) # mtd->dev is cleared, can't locate of_node
# of_node_put(NULL) won't do anything
Fix the error by caching the pointer of the device_node.
OF: ERROR: memory leak, expected refcount 1 instead of 2,
of_node_get()/of_node_put() unbalanced - destroy cset entry: attach
overlay node /spi/spi-sram@0
CPU: 3 PID: 275 Comm: python3 Tainted: G N 6.1.0-rc3+ #54
0d8a1edddf51f172ff5226989a7565c6313b08e2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0x67/0x83
kobject_get+0x155/0x160
of_node_get+0x1f/0x30
of_fwnode_get+0x43/0x70
fwnode_handle_get+0x54/0x80
fwnode_get_nth_parent+0xc9/0xe0
fwnode_full_name_string+0x3f/0xa0
device_node_string+0x30f/0x750
pointer+0x598/0x7a0
vsnprintf+0x62d/0x9b0
...
cfs_overlay_release+0x30/0x90
config_item_release+0xbe/0x1a0
config_item_put+0x5e/0x80
configfs_rmdir+0x3bd/0x540
vfs_rmdir+0x18c/0x320
do_rmdir+0x198/0x330
__x64_sys_rmdir+0x2c/0x40
do_syscall_64+0x37/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Fixes:
00596576a051 ("mtd: core: clear out unregistered devices a bit more")
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
[<miquel.raynal@bootlin.com>: Light reword of the commit log]
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Link: https://lore.kernel.org/linux-mtd/20221119063915.11108-1-shangxiaojing@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hui Tang [Sat, 19 Nov 2022 05:48:58 +0000 (13:48 +0800)]
clk: microchip: check for null return of devm_kzalloc()
[ Upstream commit
e2e6a217a84d09785848a82599729c9a41566e3a ]
Because of the possible failure of devm_kzalloc(), name might be NULL and
will cause null pointer dereference later.
Therefore, it might be better to check it and directly return -ENOMEM.
Fixes:
d39fb172760e ("clk: microchip: add PolarFire SoC fabric clock support")
Signed-off-by: Hui Tang <tanghui20@huawei.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
[claudiu.beznea: s/refrence/reference/, s/possilble/possible]
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20221119054858.178629-1-tanghui20@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jonathan Toppins [Tue, 22 Nov 2022 21:24:29 +0000 (16:24 -0500)]
bonding: fix link recovery in mode 2 when updelay is nonzero
[ Upstream commit
f8a65ab2f3ff7410921ebbf0dc55453102c33c56 ]
Before this change when a bond in mode 2 lost link, all of its slaves
lost link, the bonding device would never recover even after the
expiration of updelay. This change removes the updelay when the bond
currently has no usable links. Conforming to bonding.txt section 13.1
paragraph 4.
Fixes:
41f891004063 ("bonding: ignore updelay param when there is no active slave")
Signed-off-by: Jonathan Toppins <jtoppins@redhat.com>
Acked-by: Jay Vosburgh <jay.vosburgh@canonical.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stanislav Fomichev [Wed, 23 Nov 2022 20:08:29 +0000 (12:08 -0800)]
selftests/bpf: Mount debugfs in setns_by_fd
[ Upstream commit
8ac88eece8009428e2577c345080a458e4507e2f ]
Jiri reports broken test_progs after recent commit
68f8e3d4b916
("selftests/bpf: Make sure zero-len skbs aren't redirectable").
Apparently we don't remount debugfs when we switch back networking namespace.
Let's explicitly mount /sys/kernel/debug.
0: https://lore.kernel.org/bpf/
63b85917-a2ea-8e35-620c-
808560910819@meta.com/T/#ma66ca9c92e99eee0a25e40f422489b26ee0171c1
Fixes:
a30338840fa5 ("selftests/bpf: Move open_netns() and close_netns() into network_helpers.c")
Reported-by: Jiri Olsa <olsajiri@gmail.com>
Signed-off-by: Stanislav Fomichev <sdf@google.com>
Link: https://lore.kernel.org/r/20221123200829.2226254-1-sdf@google.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>