Zheyu Ma [Wed, 3 Aug 2022 09:24:19 +0000 (17:24 +0800)]
video: fbdev: i740fb: Check the argument of i740_calc_vclk()
[ Upstream commit
40bf722f8064f50200b8c4f8946cd625b441dda9 ]
Since the user can control the arguments of the ioctl() from the user
space, under special arguments that may result in a divide-by-zero bug.
If the user provides an improper 'pixclock' value that makes the argumet
of i740_calc_vclk() less than 'I740_RFREQ_FIX', it will cause a
divide-by-zero bug in:
drivers/video/fbdev/i740fb.c:353 p_best = min(15, ilog2(I740_MAX_VCO_FREQ / (freq / I740_RFREQ_FIX)));
The following log can reveal it:
divide error: 0000 [#1] PREEMPT SMP KASAN PTI
RIP: 0010:i740_calc_vclk drivers/video/fbdev/i740fb.c:353 [inline]
RIP: 0010:i740fb_decode_var drivers/video/fbdev/i740fb.c:646 [inline]
RIP: 0010:i740fb_set_par+0x163f/0x3b70 drivers/video/fbdev/i740fb.c:742
Call Trace:
fb_set_var+0x604/0xeb0 drivers/video/fbdev/core/fbmem.c:1034
do_fb_ioctl+0x234/0x670 drivers/video/fbdev/core/fbmem.c:1110
fb_ioctl+0xdd/0x130 drivers/video/fbdev/core/fbmem.c:1189
Fix this by checking the argument of i740_calc_vclk() first.
Signed-off-by: Zheyu Ma <zheyuma97@gmail.com>
Signed-off-by: Helge Deller <deller@gmx.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stanimir Varbanov [Mon, 1 Aug 2022 15:16:41 +0000 (18:16 +0300)]
venus: pm_helpers: Fix warning in OPP during probe
[ Upstream commit
1d95af02f23031c2e1cca7607c514b86ce85bc6e ]
Fix the following WARN triggered during Venus driver probe on
5.19.0-rc8-next-
20220728:
WARNING: CPU: 7 PID: 339 at drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610
Modules linked in: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor
qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+)
videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched
snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats
drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5
phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro
lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers
qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector
drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6
CPU: 7 PID: 339 Comm: systemd-udevd Not tainted 5.19.0-rc8-next-
20220728 #4
Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
pstate:
80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : dev_pm_opp_set_config+0x49c/0x610
lr : dev_pm_opp_set_config+0x58/0x610
sp :
ffff8000093c3710
x29:
ffff8000093c3710 x28:
ffffbca3959d82b8 x27:
ffff8000093c3d00
x26:
ffffbca3959d8e08 x25:
ffff4396cac98118 x24:
ffff4396c0e24810
x23:
ffff4396c4272c40 x22:
ffff4396c0e24810 x21:
ffff8000093c3810
x20:
ffff4396cac36800 x19:
ffff4396cac96800 x18:
0000000000000000
x17:
0000000000000003 x16:
ffffbca3f4edf198 x15:
0000001cba64a858
x14:
0000000000000180 x13:
000000000000017e x12:
0000000000000000
x11:
0000000000000002 x10:
0000000000000a60 x9 :
ffff8000093c35c0
x8 :
ffff4396c4273700 x7 :
ffff43983efca6c0 x6 :
ffff43983efca640
x5 :
00000000410fd0d0 x4 :
ffff4396c4272c40 x3 :
ffffbca3f5d1e008
x2 :
0000000000000000 x1 :
ffff4396c2421600 x0 :
ffff4396cac96860
Call trace:
dev_pm_opp_set_config+0x49c/0x610
devm_pm_opp_set_config+0x18/0x70
vcodec_domains_get+0xb8/0x1638 [venus_core]
core_get_v4+0x1d8/0x218 [venus_core]
venus_probe+0xf4/0x468 [venus_core]
platform_probe+0x68/0xd8
really_probe+0xbc/0x2a8
__driver_probe_device+0x78/0xe0
driver_probe_device+0x3c/0xf0
__driver_attach+0x70/0x120
bus_for_each_dev+0x70/0xc0
driver_attach+0x24/0x30
bus_add_driver+0x150/0x200
driver_register+0x64/0x120
__platform_driver_register+0x28/0x38
qcom_venus_driver_init+0x24/0x1000 [venus_core]
do_one_initcall+0x54/0x1c8
do_init_module+0x44/0x1d0
load_module+0x16c8/0x1aa0
__do_sys_finit_module+0xbc/0x110
__arm64_sys_finit_module+0x20/0x30
invoke_syscall+0x44/0x108
el0_svc_common.constprop.0+0xcc/0xf0
do_el0_svc+0x2c/0xb8
el0_svc+0x2c/0x88
el0t_64_sync_handler+0xb8/0xc0
el0t_64_sync+0x18c/0x190
qcom-venus: probe of aa00000.video-codec failed with error -16
The fix is re-ordering the code related to OPP core. The OPP core
expects all configuration options to be provided before the OPP
table is added.
Reported-by: Linux Kernel Functional Testing <lkft@linaro.org>
Suggested-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhouyi Zhou [Tue, 26 Jul 2022 01:57:47 +0000 (09:57 +0800)]
powerpc/64: Init jump labels before parse_early_param()
[ Upstream commit
ca829e05d3d4f728810cc5e4b468d9ebc7745eb3 ]
On 64-bit, calling jump_label_init() in setup_feature_keys() is too
late because static keys may be used in subroutines of
parse_early_param() which is again subroutine of early_init_devtree().
For example booting with "threadirqs":
static_key_enable_cpuslocked(): static key '0xc000000002953260' used before call to jump_label_init()
WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120
...
NIP static_key_enable_cpuslocked+0xfc/0x120
LR static_key_enable_cpuslocked+0xf8/0x120
Call Trace:
static_key_enable_cpuslocked+0xf8/0x120 (unreliable)
static_key_enable+0x30/0x50
setup_forced_irqthreads+0x28/0x40
do_early_param+0xa0/0x108
parse_args+0x290/0x4e0
parse_early_options+0x48/0x5c
parse_early_param+0x58/0x84
early_init_devtree+0xd4/0x518
early_setup+0xb4/0x214
So call jump_label_init() just before parse_early_param() in
early_init_devtree().
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Zhouyi Zhou <zhouzhouyi@gmail.com>
[mpe: Add call trace to change log and minor wording edits.]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220726015747.11754-1-zhouzhouyi@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Steve French [Tue, 12 Jul 2022 16:43:44 +0000 (11:43 -0500)]
smb3: check xattr value length earlier
[ Upstream commit
5fa2cffba0b82336a2244d941322eb1627ff787b ]
Coverity complains about assigning a pointer based on
value length before checking that value length goes
beyond the end of the SMB. Although this is even more
unlikely as value length is a single byte, and the
pointer is not dereferenced until laterm, it is clearer
to check the lengths first.
Addresses-Coverity: 1467704 ("Speculative execution data leak")
Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chao Yu [Wed, 27 Jul 2022 14:51:05 +0000 (22:51 +0800)]
f2fs: fix to do sanity check on segment type in build_sit_entries()
[ Upstream commit
09beadf289d6e300553e60d6e76f13c0427ecab3 ]
As Wenqing Liu <wenqingliu0120@gmail.com> reported in bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=216285
RIP: 0010:memcpy_erms+0x6/0x10
f2fs_update_meta_page+0x84/0x570 [f2fs]
change_curseg.constprop.0+0x159/0xbd0 [f2fs]
f2fs_do_replace_block+0x5c7/0x18a0 [f2fs]
f2fs_replace_block+0xeb/0x180 [f2fs]
recover_data+0x1abd/0x6f50 [f2fs]
f2fs_recover_fsync_data+0x12ce/0x3250 [f2fs]
f2fs_fill_super+0x4459/0x6190 [f2fs]
mount_bdev+0x2cf/0x3b0
legacy_get_tree+0xed/0x1d0
vfs_get_tree+0x81/0x2b0
path_mount+0x47e/0x19d0
do_mount+0xce/0xf0
__x64_sys_mount+0x12c/0x1a0
do_syscall_64+0x38/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
The root cause is segment type is invalid, so in f2fs_do_replace_block(),
f2fs accesses f2fs_sm_info::curseg_array with out-of-range segment type,
result in accessing invalid curseg->sum_blk during memcpy in
f2fs_update_meta_page(). Fix this by adding sanity check on segment type
in build_sit_entries().
Reported-by: Wenqing Liu <wenqingliu0120@gmail.com>
Signed-off-by: Chao Yu <chao.yu@oppo.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chao Yu [Sun, 24 Jul 2022 16:03:23 +0000 (00:03 +0800)]
f2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page()
[ Upstream commit
141170b759e03958f296033bb7001be62d1d363b ]
As Dipanjan Das <mail.dipanjan.das@gmail.com> reported, syzkaller
found a f2fs bug as below:
RIP: 0010:f2fs_new_node_page+0x19ac/0x1fc0 fs/f2fs/node.c:1295
Call Trace:
write_all_xattrs fs/f2fs/xattr.c:487 [inline]
__f2fs_setxattr+0xe76/0x2e10 fs/f2fs/xattr.c:743
f2fs_setxattr+0x233/0xab0 fs/f2fs/xattr.c:790
f2fs_xattr_generic_set+0x133/0x170 fs/f2fs/xattr.c:86
__vfs_setxattr+0x115/0x180 fs/xattr.c:182
__vfs_setxattr_noperm+0x125/0x5f0 fs/xattr.c:216
__vfs_setxattr_locked+0x1cf/0x260 fs/xattr.c:277
vfs_setxattr+0x13f/0x330 fs/xattr.c:303
setxattr+0x146/0x160 fs/xattr.c:611
path_setxattr+0x1a7/0x1d0 fs/xattr.c:630
__do_sys_lsetxattr fs/xattr.c:653 [inline]
__se_sys_lsetxattr fs/xattr.c:649 [inline]
__x64_sys_lsetxattr+0xbd/0x150 fs/xattr.c:649
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x46/0xb0
NAT entry and nat bitmap can be inconsistent, e.g. one nid is free
in nat bitmap, and blkaddr in its NAT entry is not NULL_ADDR, it
may trigger BUG_ON() in f2fs_new_node_page(), fix it.
Reported-by: Dipanjan Das <mail.dipanjan.das@gmail.com>
Signed-off-by: Chao Yu <chao.yu@oppo.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Thu, 28 Jul 2022 12:59:45 +0000 (14:59 +0200)]
ALSA: control: Use deferred fasync helper
[ Upstream commit
4a971e84a7ae10a38d875cd2d4e487c8d1682ca3 ]
For avoiding the potential deadlock via kill_fasync() call, use the
new fasync helpers to defer the invocation from the control API. Note
that it's merely a workaround.
Another note: although we haven't received reports about the deadlock
with the control API, the deadlock is still potentially possible, and
it's better to align the behavior with other core APIs (PCM and
timer); so let's move altogether.
Link: https://lore.kernel.org/r/20220728125945.29533-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Thu, 28 Jul 2022 12:59:43 +0000 (14:59 +0200)]
ALSA: timer: Use deferred fasync helper
[ Upstream commit
95cc637c1afd83fb7dd3d7c8a53710488f4caf9c ]
For avoiding the potential deadlock via kill_fasync() call, use the
new fasync helpers to defer the invocation from PCI API. Note that
it's merely a workaround.
Reported-by: syzbot+1ee0910eca9c94f71f25@syzkaller.appspotmail.com
Reported-by: syzbot+49b10793b867871ee26f@syzkaller.appspotmail.com
Reported-by: syzbot+8285e973a41b5aa68902@syzkaller.appspotmail.com
Link: https://lore.kernel.org/r/20220728125945.29533-3-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Thu, 28 Jul 2022 12:59:42 +0000 (14:59 +0200)]
ALSA: core: Add async signal helpers
[ Upstream commit
ef34a0ae7a2654bc9e58675e36898217fb2799d8 ]
Currently the call of kill_fasync() from an interrupt handler might
lead to potential spin deadlocks, as spotted by syzkaller.
Unfortunately, it's not so trivial to fix this lock chain as it's
involved with the tasklist_lock that is touched in allover places.
As a temporary workaround, this patch provides the way to defer the
async signal notification in a work. The new helper functions,
snd_fasync_helper() and snd_kill_faync() are replacements for
fasync_helper() and kill_fasync(), respectively. In addition,
snd_fasync_free() needs to be called at the destructor of the relevant
file object.
Link: https://lore.kernel.org/r/20220728125945.29533-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alexey Kardashevskiy [Thu, 14 Jul 2022 08:08:00 +0000 (18:08 +1000)]
powerpc/ioda/iommu/debugfs: Generate unique debugfs entries
[ Upstream commit
d73b46c3c1449bf27f793b9d9ee86ed70c7a7163 ]
The iommu_table::it_index is a LIOBN which is not initialized on PowerNV
as it is not used except IOMMU debugfs where it is used for a node name.
This initializes it_index witn a unique number to avoid warnings and
have a node for every iommu_table.
This should not cause any behavioral change without CONFIG_IOMMU_DEBUGFS.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220714080800.3712998-1-aik@ozlabs.ru
Signed-off-by: Sasha Levin <sashal@kernel.org>
Miklos Szeredi [Wed, 27 Jul 2022 14:31:30 +0000 (16:31 +0200)]
ovl: warn if trusted xattr creation fails
[ Upstream commit
b10b85fe5149ee8b39fbbf86095b303632dde2cd ]
When mounting overlayfs in an unprivileged user namespace, trusted xattr
creation will fail. This will lead to failures in some file operations,
e.g. in the following situation:
mkdir lower upper work merged
mkdir lower/directory
mount -toverlay -olowerdir=lower,upperdir=upper,workdir=work none merged
rmdir merged/directory
mkdir merged/directory
The last mkdir will fail:
mkdir: cannot create directory 'merged/directory': Input/output error
The cause for these failures is currently extremely non-obvious and hard to
debug. Hence, warn the user and suggest using the userxattr mount option,
if it is not already supplied and xattr creation fails during the
self-check.
Reported-by: Alois Wohlschlager <alois1@gmx-topmail.de>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe Leroy [Mon, 11 Jul 2022 14:19:30 +0000 (16:19 +0200)]
powerpc/32: Don't always pass -mcpu=powerpc to the compiler
[ Upstream commit
446cda1b21d9a6b3697fe399c6a3a00ff4a285f5 ]
Since commit
4bf4f42a2feb ("powerpc/kbuild: Set default generic
machine type for 32-bit compile"), when building a 32 bits kernel
with a bi-arch version of GCC, or when building a book3s/32 kernel,
the option -mcpu=powerpc is passed to GCC at all time, relying on it
being eventually overriden by a subsequent -mcpu=xxxx.
But when building the same kernel with a 32 bits only version of GCC,
that is not done, relying on gcc being built with the expected default
CPU.
This logic has two problems. First, it is a bit fragile to rely on
whether the GCC version is bi-arch or not, because today we can have
bi-arch versions of GCC configured with a 32 bits default. Second,
there are some versions of GCC which don't support -mcpu=powerpc,
for instance for e500 SPE-only versions.
So, stop relying on this approximative logic and allow the user to
decide whether he/she wants to use the toolchain's default CPU or if
he/she wants to set one, and allow only possible CPUs based on the
selected target.
Reported-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Tested-by: Pali Rohár <pali@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/d4df724691351531bf46d685d654689e5dfa0d74.1657549153.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe Leroy [Tue, 14 Jun 2022 10:34:09 +0000 (12:34 +0200)]
powerpc/32: Set an IBAT covering up to _einittext during init
[ Upstream commit
2a0fb3c155c97c75176e557d61f8e66c1bd9b735 ]
Always set an IBAT covering up to _einittext during init because when
CONFIG_MODULES is not selected there is no reason to have an exception
handler for kernel instruction TLB misses.
It implies DBAT and IBAT are now totaly independent, IBATs are set
by setibat() and DBAT by setbat().
This allows to revert commit
9bb162fa26ed ("powerpc/603: Fix
boot failure with DEBUG_PAGEALLOC and KFENCE")
Reported-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/ce7f04a39593934d9b1ee68c69144ccd3d4da4a1.1655202804.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <sashal@kernel.org>
Laurent Dufour [Wed, 13 Jul 2022 15:47:27 +0000 (17:47 +0200)]
watchdog: export lockup_detector_reconfigure
[ Upstream commit
7c56a8733d0a2a4be2438a7512566e5ce552fccf ]
In some circumstances it may be interesting to reconfigure the watchdog
from inside the kernel.
On PowerPC, this may helpful before and after a LPAR migration (LPM) is
initiated, because it implies some latencies, watchdog, and especially NMI
watchdog is expected to be triggered during this operation. Reconfiguring
the watchdog with a factor, would prevent it to happen too frequently
during LPM.
Rename lockup_detector_reconfigure() as __lockup_detector_reconfigure() and
create a new function lockup_detector_reconfigure() calling
__lockup_detector_reconfigure() under the protection of watchdog_mutex.
Signed-off-by: Laurent Dufour <ldufour@linux.ibm.com>
[mpe: Squash in build fix from Laurent, reported by Sachin]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220713154729.80789-3-ldufour@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xianting Tian [Mon, 6 Jun 2022 08:23:08 +0000 (16:23 +0800)]
RISC-V: Add fast call path of crash_kexec()
[ Upstream commit
3f1901110a89b0e2e13adb2ac8d1a7102879ea98 ]
Currently, almost all archs (x86, arm64, mips...) support fast call
of crash_kexec() when "regs && kexec_should_crash()" is true. But
RISC-V not, it can only enter crash system via panic(). However panic()
doesn't pass the regs of the real accident scene to crash_kexec(),
it caused we can't get accurate backtrace via gdb,
$ riscv64-linux-gnu-gdb vmlinux vmcore
Reading symbols from vmlinux...
[New LWP 95]
#0 console_unlock () at kernel/printk/printk.c:2557
2557 if (do_cond_resched)
(gdb) bt
#0 console_unlock () at kernel/printk/printk.c:2557
#1 0x0000000000000000 in ?? ()
With the patch we can get the accurate backtrace,
$ riscv64-linux-gnu-gdb vmlinux vmcore
Reading symbols from vmlinux...
[New LWP 95]
#0 0xffffffe00063a4e0 in test_thread (data=<optimized out>) at drivers/test_crash.c:81
81 *(int *)p = 0xdead;
(gdb)
(gdb) bt
#0 0xffffffe00064d5c0 in test_thread (data=<optimized out>) at drivers/test_crash.c:81
#1 0x0000000000000000 in ?? ()
Test code to produce NULL address dereference in test_crash.c,
void *p = NULL;
*(int *)p = 0xdead;
Reviewed-by: Guo Ren <guoren@kernel.org>
Tested-by: Xianting Tian <xianting.tian@linux.alibaba.com>
Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
Link: https://lore.kernel.org/r/20220606082308.2883458-1-xianting.tian@linux.alibaba.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Celeste Liu [Tue, 31 May 2022 07:56:52 +0000 (15:56 +0800)]
riscv: mmap with PROT_WRITE but no PROT_READ is invalid
[ Upstream commit
2139619bcad7ac44cc8f6f749089120594056613 ]
As mentioned in Table 4.5 in RISC-V spec Volume 2 Section 4.3, write
but not read is "Reserved for future use.". For now, they are not valid.
In the current code, -wx is marked as invalid, but -w- is not marked
as invalid.
This patch refines that judgment.
Reported-by: xctan <xc-tan@outlook.com>
Co-developed-by: dram <dramforever@live.com>
Signed-off-by: dram <dramforever@live.com>
Co-developed-by: Ruizhe Pan <c141028@gmail.com>
Signed-off-by: Ruizhe Pan <c141028@gmail.com>
Signed-off-by: Celeste Liu <coelacanthus@outlook.com>
Link: https://lore.kernel.org/r/PH7PR14MB559464DBDD310E755F5B21E8CEDC9@PH7PR14MB5594.namprd14.prod.outlook.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Conor Dooley [Tue, 5 Jul 2022 19:04:36 +0000 (20:04 +0100)]
riscv: dts: canaan: Add k210 topology information
[ Upstream commit
d9d193dea8666bbf69fc21c5bdcdabaa34a466e3 ]
The k210 has no cpu-map node, so tools like hwloc cannot correctly
parse the topology. Add the node using the existing node labels.
Reported-by: Brice Goglin <Brice.Goglin@inria.fr>
Link: https://github.com/open-mpi/hwloc/issues/536
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Link: https://lore.kernel.org/r/20220705190435.1790466-6-mail@conchuod.ie
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Conor Dooley [Tue, 5 Jul 2022 19:04:34 +0000 (20:04 +0100)]
riscv: dts: sifive: Add fu740 topology information
[ Upstream commit
bf6cd1c01c959a31002dfa6784c0d8caffed4cf1 ]
The fu740 has no cpu-map node, so tools like hwloc cannot correctly
parse the topology. Add the node using the existing node labels.
Reported-by: Brice Goglin <Brice.Goglin@inria.fr>
Link: https://github.com/open-mpi/hwloc/issues/536
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20220705190435.1790466-4-mail@conchuod.ie
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kuninori Morimoto [Thu, 14 Jul 2022 06:28:15 +0000 (06:28 +0000)]
ASoC: rsnd: care default case on rsnd_ssiu_busif_err_irq_ctrl()
[ Upstream commit
ef30911d3c39fd57884c348c29b9cbff88def155 ]
Before, ssiu.c didn't care SSI5-8, thus,
commit
b1384d4c95088d0 ("ASoC: rsnd: care default case on
rsnd_ssiu_busif_err_status_clear()") cares it for status clear.
But we should care it for error irq handling, too.
This patch cares it.
Reported-by: Nguyen Bao Nguyen <nguyen.nguyen.yj@renesas.com>
Reported-by: Nishiyama Kunihiko <kunihiko.nishiyama.dn@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/871quocio1.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Helge Deller [Fri, 8 Jul 2022 09:44:54 +0000 (11:44 +0200)]
modules: Ensure natural alignment for .altinstructions and __bug_table sections
[ Upstream commit
87c482bdfa79f378297d92af49cdf265be199df5 ]
In the kernel image vmlinux.lds.S linker scripts the .altinstructions
and __bug_table sections are 4- or 8-byte aligned because they hold 32-
and/or 64-bit values.
Most architectures use altinstructions and BUG() or WARN() in modules as
well, but in the module linker script (module.lds.S) those sections are
currently missing. As consequence the linker will store their content
byte-aligned by default, which then can lead to unnecessary unaligned
memory accesses by the CPU when those tables are processed at runtime.
Usually unaligned memory accesses are unnoticed, because either the
hardware (as on x86 CPUs) or in-kernel exception handlers (e.g. on
parisc or sparc) emulate and fix them up at runtime. Nevertheless, such
unaligned accesses introduce a performance penalty and can even crash
the kernel if there is a bug in the unalignment exception handlers
(which happened once to me on the parisc architecture and which is why I
noticed that issue at all).
This patch fixes a non-critical issue and might be backported at any time.
It's trivial and shouldn't introduce any regression because it simply
tells the linker to use a different (8-byte alignment) for those
sections by default.
Signed-off-by: Helge Deller <deller@gmx.de>
Link: https://lore.kernel.org/all/Yr8%2Fgr8e8I7tVX4d@p100/
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yunfei Wang [Thu, 30 Jun 2022 09:29:25 +0000 (17:29 +0800)]
iommu/io-pgtable-arm-v7s: Add a quirk to allow pgtable PA up to 35bit
[ Upstream commit
bfdd231374181254742c5e2faef0bef2d30c0ee4 ]
Single memory zone feature will remove ZONE_DMA32 and ZONE_DMA and
cause pgtable PA size larger than 32bit.
Since Mediatek IOMMU hardware support at most 35bit PA in pgtable,
so add a quirk to allow the PA of pgtables support up to bit35.
Signed-off-by: Ning Li <ning.li@mediatek.com>
Signed-off-by: Yunfei Wang <yf.wang@mediatek.com>
Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20220630092927.24925-2-yf.wang@mediatek.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Liang He [Fri, 1 Jul 2022 12:41:12 +0000 (20:41 +0800)]
mips: cavium-octeon: Fix missing of_node_put() in octeon2_usb_clocks_start
[ Upstream commit
7a9f743ceead60ed454c46fbc3085ee9a79cbebb ]
We should call of_node_put() for the reference 'uctl_node' returned by
of_get_parent() which will increase the refcount. Otherwise, there will
be a refcount leak bug.
Signed-off-by: Liang He <windhl@126.com>
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Schspa Shi [Wed, 29 Jun 2022 02:29:48 +0000 (10:29 +0800)]
vfio: Clear the caps->buf to NULL after free
[ Upstream commit
6641085e8d7b3f061911517f79a2a15a0a21b97b ]
On buffer resize failure, vfio_info_cap_add() will free the buffer,
report zero for the size, and return -ENOMEM. As additional
hardening, also clear the buffer pointer to prevent any chance of a
double free.
Signed-off-by: Schspa Shi <schspa@gmail.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Link: https://lore.kernel.org/r/20220629022948.55608-1-schspa@gmail.com
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fabiano Rosas [Wed, 25 May 2022 13:05:50 +0000 (10:05 -0300)]
KVM: PPC: Book3S HV: Fix "rm_exit" entry in debugfs timings
[ Upstream commit
9981bace85d816ed8724ac46e49285e8488d29e6 ]
At debugfs/kvm/<pid>/vcpu0/timings we show how long each part of the
code takes to run:
$ cat /sys/kernel/debug/kvm/*-*/vcpu0/timings
rm_entry: 123785
49398892 118 4898
rm_intr: 123780 6075890 22 390
rm_exit: 0 0 0 0 <-- NOK
guest: 123780
46732919988 402 9997638
cede: 0 0 0 0 <-- OK, no cede napping in P9
The "rm_exit" is always showing zero because it is the last one and
end_timing does not increment the counter of the previous entry.
We can fix it by calling accumulate_time again instead of
end_timing. That way the counter gets incremented. The rest of the
arithmetic can be ignored because there are no timing points after
this and the accumulators are reset before the next round.
Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220525130554.2614394-2-farosas@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Liang He [Sat, 18 Jun 2022 06:08:50 +0000 (14:08 +0800)]
tty: serial: Fix refcount leak bug in ucc_uart.c
[ Upstream commit
d24d7bb2cd947676f9b71fb944d045e09b8b282f ]
In soc_info(), of_find_node_by_type() will return a node pointer
with refcount incremented. We should use of_node_put() when it is
not used anymore.
Acked-by: Timur Tabi <timur@kernel.org>
Signed-off-by: Liang He <windhl@126.com>
Link: https://lore.kernel.org/r/20220618060850.4058525-1-windhl@126.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Guenter Roeck [Tue, 31 May 2022 22:29:51 +0000 (15:29 -0700)]
lib/list_debug.c: Detect uninitialized lists
[ Upstream commit
0cc011c576aaa4de505046f7a6c90933d7c749a9 ]
In some circumstances, attempts are made to add entries to or to remove
entries from an uninitialized list. A prime example is
amdgpu_bo_vm_destroy(): It is indirectly called from
ttm_bo_init_reserved() if that function fails, and tries to remove an
entry from a list. However, that list is only initialized in
amdgpu_bo_create_vm() after the call to ttm_bo_init_reserved() returned
success. This results in crashes such as
BUG: kernel NULL pointer dereference, address:
0000000000000000
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 1479 Comm: chrome Not tainted 5.10.110-15768-g29a72e65dae5
Hardware name: Google Grunt/Grunt, BIOS Google_Grunt.11031.149.0 07/15/2020
RIP: 0010:__list_del_entry_valid+0x26/0x7d
...
Call Trace:
amdgpu_bo_vm_destroy+0x48/0x8b
ttm_bo_init_reserved+0x1d7/0x1e0
amdgpu_bo_create+0x212/0x476
? amdgpu_bo_user_destroy+0x23/0x23
? kmem_cache_alloc+0x60/0x271
amdgpu_bo_create_vm+0x40/0x7d
amdgpu_vm_pt_create+0xe8/0x24b
...
Check if the list's prev and next pointers are NULL to catch such problems.
Link: https://lkml.kernel.org/r/20220531222951.92073-1-linux@roeck-us.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cc: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kiselev, Oleg [Wed, 20 Jul 2022 04:27:48 +0000 (04:27 +0000)]
ext4: avoid resizing to a partial cluster size
[ Upstream commit
69cb8e9d8cd97cdf5e293b26d70a9dee3e35e6bd ]
This patch avoids an attempt to resize the filesystem to an
unaligned cluster boundary. An online resize to a size that is not
integral to cluster size results in the last iteration attempting to
grow the fs by a negative amount, which trips a BUG_ON and leaves the fs
with a corrupted in-memory superblock.
Signed-off-by: Oleg Kiselev <okiselev@amazon.com>
Link: https://lore.kernel.org/r/0E92A0AB-4F16-4F1A-94B7-702CC6504FDE@amazon.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ye Bin [Wed, 22 Jun 2022 09:02:23 +0000 (17:02 +0800)]
ext4: avoid remove directory when directory is corrupted
[ Upstream commit
b24e77ef1c6d4dbf42749ad4903c97539cc9755a ]
Now if check directoy entry is corrupted, ext4_empty_dir may return true
then directory will be removed when file system mounted with "errors=continue".
In order not to make things worse just return false when directory is corrupted.
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Link: https://lore.kernel.org/r/20220622090223.682234-1-yebin10@huawei.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wentao_Liang [Thu, 28 Jul 2022 11:39:19 +0000 (19:39 +0800)]
drivers:md:fix a potential use-after-free bug
[ Upstream commit
104212471b1c1817b311771d817fb692af983173 ]
In line 2884, "raid5_release_stripe(sh);" drops the reference to sh and
may cause sh to be released. However, sh is subsequently used in lines
2886 "if (sh->batch_head && sh != sh->batch_head)". This may result in an
use-after-free bug.
It can be fixed by moving "raid5_release_stripe(sh);" to the bottom of
the function.
Signed-off-by: Wentao_Liang <Wentao_Liang_g@163.com>
Signed-off-by: Song Liu <song@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sagi Grimberg [Sun, 24 Jul 2022 08:58:43 +0000 (11:58 +0300)]
nvmet-tcp: fix lockdep complaint on nvmet_tcp_wq flush during queue teardown
[ Upstream commit
533d2e8b4d5e4c89772a0adce913525fb86cbbee ]
We probably need nvmet_tcp_wq to have MEM_RECLAIM as we are
sending/receiving for the socket from works on this workqueue.
Also this eliminates lockdep complaints:
--
[ 6174.010200] workqueue: WQ_MEM_RECLAIM
nvmet-wq:nvmet_tcp_release_queue_work [nvmet_tcp] is flushing
!WQ_MEM_RECLAIM nvmet_tcp_wq:nvmet_tcp_io_work [nvmet_tcp]
[ 6174.010216] WARNING: CPU: 20 PID: 14456 at kernel/workqueue.c:2628
check_flush_dependency+0x110/0x14c
Reported-by: Yi Zhang <yi.zhang@redhat.com>
Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Logan Gunthorpe [Wed, 8 Jun 2022 16:27:56 +0000 (10:27 -0600)]
md: Notify sysfs sync_completed in md_reap_sync_thread()
[ Upstream commit
9973f0fa7d20269fe6fefe6333997fb5914449c1 ]
The mdadm test 07layouts randomly produces a kernel hung task deadlock.
The deadlock is caused by the suspend_lo/suspend_hi files being set by
the mdadm background process during reshape and not being cleared
because the process hangs. (Leaving aside the issue of the fragility of
freezing kernel tasks by buggy userspace processes...)
When the background mdadm process hangs it, is waiting (without a
timeout) on a change to the sync_completed file signalling that the
reshape has completed. The process is woken up a couple times when
the reshape finishes but it is woken up before MD_RECOVERY_RUNNING
is cleared so sync_completed_show() reports 0 instead of "none".
To fix this, notify the sysfs file in md_reap_sync_thread() after
MD_RECOVERY_RUNNING has been cleared. This wakes up mdadm and causes
it to continue and write to suspend_lo/suspend_hi to allow IO to
continue.
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Song Liu <song@kernel.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marek Szyprowski [Tue, 28 Jun 2022 22:04:08 +0000 (00:04 +0200)]
phy: samsung: phy-exynos-pcie: sanitize init/power_on callbacks
[ Upstream commit
f2812227bb07e2eaee74253f11cea1576945df31 ]
The exynos-pcie driver called phy_power_on() before phy_init() for some
historical reasons. However the generic PHY framework assumes that the
proper sequence is to call phy_init() first, then phy_power_on(). The
operations done by both functions should be considered as one action and as
such they are called by the exynos-pcie driver (without doing anything
between them). The initialization is just a sequence of register writes,
which cannot be altered without breaking the hardware operation.
To match the generic PHY framework requirement, simply move all register
writes to the phy_init()/phy_exit() and drop power_on()/power_off()
callbacks. This way the driver will also work with the old (incorrect)
PHY initialization call sequence.
Link: https://lore.kernel.org/r/20220628220409.26545-1-m.szyprowski@samsung.com
Reported-by: Bjorn Helgaas <helgaas@kernel.org>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Reviewed-by: Chanho Park <chanho61.park@samsung.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Acked-By: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stafford Horne [Fri, 29 Jul 2022 10:54:08 +0000 (19:54 +0900)]
openrisc: io: Define iounmap argument as volatile
[ Upstream commit
52e0ea900202d23843daee8f7089817e81dd3dd7 ]
When OpenRISC enables PCI it allows for more drivers to be compiled
resulting in exposing the following with -Werror.
drivers/video/fbdev/riva/fbdev.c: In function 'rivafb_probe':
drivers/video/fbdev/riva/fbdev.c:2062:42: error:
passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type
drivers/video/fbdev/nvidia/nvidia.c: In function 'nvidiafb_probe':
drivers/video/fbdev/nvidia/nvidia.c:1414:20: error:
passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type
drivers/scsi/aic7xxx/aic7xxx_osm.c: In function 'ahc_platform_free':
drivers/scsi/aic7xxx/aic7xxx_osm.c:1231:41: error:
passing argument 1 of 'iounmap' discards 'volatile' qualifier from pointer target type
Most architectures define the iounmap argument to be volatile. To fix this
issue we do the same for OpenRISC. This patch must go before PCI is enabled on
OpenRISC to avoid any compile failures.
Link: https://lore.kernel.org/lkml/20220729033728.GA2195022@roeck-us.net/
Reported-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Stafford Horne <shorne@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Uwe Kleine-König [Thu, 21 Jul 2022 20:40:54 +0000 (22:40 +0200)]
dmaengine: sprd: Cleanup in .remove() after pm_runtime_get_sync() failed
[ Upstream commit
1e42f82cbec7b2cc4873751e7791e6611901c5fc ]
It's not allowed to quit remove early without cleaning up completely.
Otherwise this results in resource leaks that probably yield graver
problems later. Here for example some tasklets might survive the lifetime
of the sprd-dma device and access sdev which is freed after .remove()
returns.
As none of the device freeing requires an active device, just ignore the
return value of pm_runtime_get_sync().
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
Link: https://lore.kernel.org/r/20220721204054.323602-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Steven Rostedt (Google) [Tue, 12 Jul 2022 20:17:07 +0000 (16:17 -0400)]
selftests/kprobe: Do not test for GRP/ without event failures
[ Upstream commit
f5eab65ff2b76449286d18efc7fee3e0b72f7d9b ]
A new feature is added where kprobes (and other probes) do not need to
explicitly state the event name when creating a probe. The event name will
come from what is being attached.
That is:
# echo 'p:foo/ vfs_read' > kprobe_events
Will no longer error, but instead create an event:
# cat kprobe_events
p:foo/p_vfs_read_0 vfs_read
This should not be tested as an error case anymore. Remove it from the
selftest as now this feature "breaks" the selftest as it no longer fails
as expected.
Link: https://lore.kernel.org/all/1656296348-16111-1-git-send-email-quic_linyyuan@quicinc.com/
Link: https://lkml.kernel.org/r/20220712161707.6dc08a14@gandalf.local.home
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Liao Chang [Wed, 25 May 2022 08:02:41 +0000 (16:02 +0800)]
csky/kprobe: reclaim insn_slot on kprobe unregistration
[ Upstream commit
a2310c74d418deca0f1d749c45f1f43162510f51 ]
On kprobe registration kernel allocate one insn_slot for new kprobe,
but it forget to reclaim the insn_slot on unregistration, leading to a
potential leakage.
Reported-by: Chen Guokai <chenguokai17@mails.ucas.ac.cn>
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Liao Chang <liaochang1@huawei.com>
Signed-off-by: Guo Ren <guoren@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bob Pearson [Thu, 30 Jun 2022 19:04:25 +0000 (14:04 -0500)]
RDMA/rxe: Limit the number of calls to each tasklet
[ Upstream commit
eff6d998ca297cb0b2e53b032a56cf8e04dd8b17 ]
Limit the maximum number of calls to each tasklet from rxe_do_task()
before yielding the cpu. When the limit is reached reschedule the tasklet
and exit the calling loop. This patch prevents one tasklet from consuming
100% of a cpu core and causing a deadlock or soft lockup.
Link: https://lore.kernel.org/r/20220630190425.2251-9-rpearsonhpe@gmail.com
Signed-off-by: Bob Pearson <rpearsonhpe@gmail.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ben Dooks [Fri, 8 Jul 2022 17:01:53 +0000 (18:01 +0100)]
dmaengine: dw-axi-dmac: ignore interrupt if no descriptor
[ Upstream commit
820f5ce999d2f99961e88c16d65cd26764df0590 ]
If the channel has no descriptor and the interrupt is raised then the
kernel will OOPS. Check the result of vchan_next_desc() in the handler
axi_chan_block_xfer_complete() to avoid the error happening.
Signed-off-by: Ben Dooks <ben.dooks@sifive.com>
Link: https://lore.kernel.org/r/20220708170153.269991-4-ben.dooks@sifive.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ben Dooks [Fri, 8 Jul 2022 17:01:52 +0000 (18:01 +0100)]
dmaengine: dw-axi-dmac: do not print NULL LLI during error
[ Upstream commit
86cb0defe0e275453bc39e856bb523eb425a6537 ]
During debugging we have seen an issue where axi_chan_dump_lli()
is passed a NULL LLI pointer which ends up causing an OOPS due
to trying to get fields from it. Simply print NULL LLI and exit
to avoid this.
Signed-off-by: Ben Dooks <ben.dooks@sifive.com>
Link: https://lore.kernel.org/r/20220708170153.269991-3-ben.dooks@sifive.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jason A. Donenfeld [Wed, 13 Jul 2022 11:56:17 +0000 (13:56 +0200)]
um: add "noreboot" command line option for PANIC_TIMEOUT=-1 setups
[ Upstream commit
dda520d07b95072a0b63f6c52a8eb566d08ea897 ]
QEMU has a -no-reboot option, which halts instead of reboots when the
guest asks to reboot. This is invaluable when used with
CONFIG_PANIC_TIMEOUT=-1 (and panic_on_warn), because it allows panics
and warnings to be caught immediately in CI. Implement this in UML too,
by way of a basic setup param.
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Huacai Chen [Thu, 14 Jul 2022 12:42:10 +0000 (20:42 +0800)]
PCI/ACPI: Guard ARM64-specific mcfg_quirks
[ Upstream commit
40a6cc141b4b9580de140bcb3e893445708acc5d ]
Guard ARM64-specific quirks with CONFIG_ARM64 to avoid build errors,
since mcfg_quirks will be shared by more than one architectures.
Link: https://lore.kernel.org/r/20220714124216.1489304-2-chenhuacai@loongson.cn
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Mon, 11 Jul 2022 19:14:48 +0000 (21:14 +0200)]
cxl: Fix a memory leak in an error handling path
[ Upstream commit
3a15b45b5454da862376b5d69a4967f5c6fa1368 ]
A bitmap_zalloc() must be balanced by a corresponding bitmap_free() in the
error handling path of afu_allocate_irqs().
Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/ce5869418f5838187946eb6b11a52715a93ece3d.1657566849.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andy Shevchenko [Mon, 6 Jun 2022 16:41:28 +0000 (19:41 +0300)]
pinctrl: intel: Check against matching data instead of ACPI companion
[ Upstream commit
c551bd81d198bf1dcd4398d5454acdc0309dbe77 ]
In some cases we may get a platform device that has ACPI companion
which is different to the pin control described in the ACPI tables.
This is primarily happens when device is instantiated by board file.
In order to allow this device being enumerated, refactor
intel_pinctrl_get_soc_data() to check the matching data instead of
ACPI companion.
Reported-by: Henning Schild <henning.schild@siemens.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Tested-by: Henning Schild <henning.schild@siemens.com>
Acked-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wolfram Sang [Sat, 25 Jun 2022 13:17:22 +0000 (15:17 +0200)]
mmc: tmio: avoid glitches when resetting
[ Upstream commit
2e586f8a5b0ed4a525014a692923ac96f6647816 ]
If we reset because of an error, we need to preserve values for the
clock frequency. Otherwise, glitches may be seen on the bus.
To achieve that, we introduce a 'preserve' parameter to the reset
function and the IP core specific reset callbacks to handle everything
accordingly.
Reported-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20220625131722.1397-1-wsa@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Oded Gabbay [Fri, 24 Jun 2022 13:45:02 +0000 (16:45 +0300)]
habanalabs/gaudi: mask constant value before cast
[ Upstream commit
e3f49437a2e0221a387ecd192d742ae1434e1e3a ]
This fixes a sparse warning of
"cast truncates bits from constant value"
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ofir Bitton [Wed, 15 Jun 2022 13:11:31 +0000 (16:11 +0300)]
habanalabs/gaudi: fix shift out of bounds
[ Upstream commit
01622098aeb05a5efbb727199bbc2a4653393255 ]
When validating NIC queues, queue offset calculation must be
performed only for NIC queues.
Signed-off-by: Ofir Bitton <obitton@habana.ai>
Reviewed-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Oded Gabbay <ogabbay@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nick Desaulniers [Fri, 8 Jul 2022 23:15:20 +0000 (16:15 -0700)]
coresight: etm4x: avoid build failure with unrolled loops
[ Upstream commit
4d45bc82df667ad9e9cb8361830e54fc1264e993 ]
When the following configs are enabled:
* CORESIGHT
* CORESIGHT_SOURCE_ETM4X
* UBSAN
* UBSAN_TRAP
Clang fails assemble the kernel with the error:
<instantiation>:1:7: error: expected constant expression in '.inst' directive
.inst (0xd5200000|((((2) << 19) | ((1) << 16) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 7) & 0x7)) << 12) | ((((((((((0x160 + (i * 4))))) >> 2))) & 0xf)) << 8) | (((((((((((0x160 + (i * 4))))) >> 2))) >> 4) & 0x7)) << 5)))|(.L__reg_num_x8))
^
drivers/hwtracing/coresight/coresight-etm4x-core.c:702:4: note: while in
macro instantiation
etm4x_relaxed_read32(csa, TRCCNTVRn(i));
^
drivers/hwtracing/coresight/coresight-etm4x.h:403:4: note: expanded from
macro 'etm4x_relaxed_read32'
read_etm4x_sysreg_offset((offset), false)))
^
drivers/hwtracing/coresight/coresight-etm4x.h:383:12: note: expanded
from macro 'read_etm4x_sysreg_offset'
__val = read_etm4x_sysreg_const_offset((offset)); \
^
drivers/hwtracing/coresight/coresight-etm4x.h:149:2: note: expanded from
macro 'read_etm4x_sysreg_const_offset'
READ_ETM4x_REG(ETM4x_OFFSET_TO_REG(offset))
^
drivers/hwtracing/coresight/coresight-etm4x.h:144:2: note: expanded from
macro 'READ_ETM4x_REG'
read_sysreg_s(ETM4x_REG_NUM_TO_SYSREG((reg)))
^
arch/arm64/include/asm/sysreg.h:1108:15: note: expanded from macro
'read_sysreg_s'
asm volatile(__mrs_s("%0", r) : "=r" (__val)); \
^
arch/arm64/include/asm/sysreg.h:1074:2: note: expanded from macro '__mrs_s'
" mrs_s " v ", " __stringify(r) "\n" \
^
Consider the definitions of TRCSSCSRn and TRCCNTVRn:
drivers/hwtracing/coresight/coresight-etm4x.h:56
#define TRCCNTVRn(n) (0x160 + (n * 4))
drivers/hwtracing/coresight/coresight-etm4x.h:81
#define TRCSSCSRn(n) (0x2A0 + (n * 4))
Where the macro parameter is expanded to i; a loop induction variable
from etm4_disable_hw.
When any compiler can determine that loops may be unrolled, then the
__builtin_constant_p check in read_etm4x_sysreg_offset() defined in
drivers/hwtracing/coresight/coresight-etm4x.h may evaluate to true. This
can lead to the expression `(0x160 + (i * 4))` being passed to
read_etm4x_sysreg_const_offset. Via the trace above, this is passed
through READ_ETM4x_REG, read_sysreg_s, and finally to __mrs_s where it
is string-ified and used directly in inline asm.
Regardless of which compiler or compiler options determine whether a
loop can or can't be unrolled, which determines whether
__builtin_constant_p evaluates to true when passed an expression using a
loop induction variable, it is NEVER safe to allow the preprocessor to
construct inline asm like:
asm volatile (".inst (0x160 + (i * 4))" : "=r"(__val));
^ expected constant expression
Instead of read_etm4x_sysreg_offset() using __builtin_constant_p(), use
__is_constexpr from include/linux/const.h instead to ensure only
expressions that are valid integer constant expressions get passed
through to read_sysreg_s().
This is not a bug in clang; it's a potentially unsafe use of the macro
arguments in read_etm4x_sysreg_offset dependent on __builtin_constant_p.
Link: https://github.com/ClangBuiltLinux/linux/issues/1310
Reported-by: Arnd Bergmann <arnd@kernel.org>
Reported-by: Tao Zhang <quic_taozha@quicinc.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20220708231520.3958391-1-ndesaulniers@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jozef Martiniak [Fri, 8 Jul 2022 07:06:44 +0000 (09:06 +0200)]
gadgetfs: ep_io - wait until IRQ finishes
[ Upstream commit
04cb742d4d8f30dc2e83b46ac317eec09191c68e ]
after usb_ep_queue() if wait_for_completion_interruptible() is
interrupted we need to wait until IRQ gets finished.
Otherwise complete() from epio_complete() can corrupt stack.
Signed-off-by: Jozef Martiniak <jomajm@gmail.com>
Link: https://lore.kernel.org/r/20220708070645.6130-1-jomajm@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
James Smart [Fri, 1 Jul 2022 21:14:18 +0000 (14:14 -0700)]
scsi: lpfc: Fix possible memory leak when failing to issue CMF WQE
[ Upstream commit
2f67dc7970bce3529edce93a0a14234d88b3fcd5 ]
There is no corresponding free routine if lpfc_sli4_issue_wqe fails to
issue the CMF WQE in lpfc_issue_cmf_sync_wqe.
If ret_val is non-zero, then free the iocbq request structure.
Link: https://lore.kernel.org/r/20220701211425.2708-6-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
James Smart [Fri, 1 Jul 2022 21:14:15 +0000 (14:14 -0700)]
scsi: lpfc: Prevent buffer overflow crashes in debugfs with malformed user input
[ Upstream commit
f8191d40aa612981ce897e66cda6a88db8df17bb ]
Malformed user input to debugfs results in buffer overflow crashes. Adapt
input string lengths to fit within internal buffers, leaving space for NULL
terminators.
Link: https://lore.kernel.org/r/20220701211425.2708-3-jsmart2021@gmail.com
Co-developed-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: Justin Tee <justin.tee@broadcom.com>
Signed-off-by: James Smart <jsmart2021@gmail.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vladimir Zapolskiy [Fri, 1 Jul 2022 06:27:11 +0000 (09:27 +0300)]
clk: qcom: clk-alpha-pll: fix clk_trion_pll_configure description
[ Upstream commit
94bed9bb05c7850ff5d80b87cc29004901f37956 ]
After merging lucid and trion pll functions in commit
0b01489475c6
("clk: qcom: clk-alpha-pll: same regs and ops for trion and lucid")
the function clk_trion_pll_configure() is left with an old description
header, which results in a W=2 compile time warning, fix it.
Acked-by: Stephen Boyd <sboyd@kernel.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220701062711.2757855-1-vladimir.zapolskiy@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sergey Senozhatsky [Wed, 22 Jun 2022 02:35:01 +0000 (11:35 +0900)]
zram: do not lookup algorithm in backends table
[ Upstream commit
dc89997264de565999a1cb55db3f295d3a8e457b ]
Always use crypto_has_comp() so that crypto can lookup module, call
usermodhelper to load the modules, wait for usermodhelper to finish and so
on. Otherwise crypto will do all of these steps under CPU hot-plug lock
and this looks like too much stuff to handle under the CPU hot-plug lock.
Besides this can end up in a deadlock when usermodhelper triggers a code
path that attempts to lock the CPU hot-plug lock, that zram already holds.
An example of such deadlock:
- path A. zram grabs CPU hot-plug lock, execs /sbin/modprobe from crypto
and waits for modprobe to finish
disksize_store
zcomp_create
__cpuhp_state_add_instance
__cpuhp_state_add_instance_cpuslocked
zcomp_cpu_up_prepare
crypto_alloc_base
crypto_alg_mod_lookup
call_usermodehelper_exec
wait_for_completion_killable
do_wait_for_common
schedule
- path B. async work kthread that brings in scsi device. It wants to
register CPUHP states at some point, and it needs the CPU hot-plug
lock for that, which is owned by zram.
async_run_entry_fn
scsi_probe_and_add_lun
scsi_mq_alloc_queue
blk_mq_init_queue
blk_mq_init_allocated_queue
blk_mq_realloc_hw_ctxs
__cpuhp_state_add_instance
__cpuhp_state_add_instance_cpuslocked
mutex_lock
schedule
- path C. modprobe sleeps, waiting for all aync works to finish.
load_module
do_init_module
async_synchronize_full
async_synchronize_cookie_domain
schedule
[senozhatsky@chromium.org: add comment]
Link: https://lkml.kernel.org/r/20220624060606.1014474-1-senozhatsky@chromium.org
Link: https://lkml.kernel.org/r/20220622023501.517125-1-senozhatsky@chromium.org
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Minchan Kim <minchan@kernel.org>
Cc: Nitin Gupta <ngupta@vflare.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jean-Philippe Brucker [Fri, 1 Jul 2022 03:48:43 +0000 (11:48 +0800)]
uacce: Handle parent device removal or parent driver module rmmod
[ Upstream commit
80fc671bcc0173836e9032b0c698ea74c13b9d7c ]
The uacce driver must deal with a possible removal of the parent device
or parent driver module rmmod at any time.
Although uacce_remove(), called on device removal and on driver unbind,
prevents future use of the uacce fops by removing the cdev, fops that
were called before that point may still be running.
Serialize uacce_fops_open() and uacce_remove() with uacce->mutex.
Serialize other fops against uacce_remove() with q->mutex.
Since we need to protect uacce_fops_poll() which gets called on the fast
path, replace uacce->queues_lock with q->mutex to improve scalability.
The other fops are only used during setup.
uacce_queue_is_valid(), checked under q->mutex or uacce->mutex, denotes
whether uacce_remove() has disabled all queues. If that is the case,
don't go any further since the parent device is being removed and
uacce->ops should not be called anymore.
Reported-by: Yang Shen <shenyang39@huawei.com>
Signed-off-by: Zhangfei Gao <zhangfei.gao@linaro.org>
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Link: https://lore.kernel.org/r/20220701034843.7502-1-zhangfei.gao@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Robert Marko [Sun, 15 May 2022 21:00:47 +0000 (23:00 +0200)]
clk: qcom: ipq8074: dont disable gcc_sleep_clk_src
[ Upstream commit
1bf7305e79aab095196131bdc87a97796e0e3fac ]
Once the usb sleep clocks are disabled, clock framework is trying to
disable the sleep clock source also.
However, it seems that it cannot be disabled and trying to do so produces:
[ 245.436390] ------------[ cut here ]------------
[ 245.441233] gcc_sleep_clk_src status stuck at 'on'
[ 245.441254] WARNING: CPU: 2 PID: 223 at clk_branch_wait+0x130/0x140
[ 245.450435] Modules linked in: xhci_plat_hcd xhci_hcd dwc3 dwc3_qcom leds_gpio
[ 245.456601] CPU: 2 PID: 223 Comm: sh Not tainted 5.18.0-rc4 #215
[ 245.463889] Hardware name: Xiaomi AX9000 (DT)
[ 245.470050] pstate:
204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 245.474307] pc : clk_branch_wait+0x130/0x140
[ 245.481073] lr : clk_branch_wait+0x130/0x140
[ 245.485588] sp :
ffffffc009f2bad0
[ 245.489838] x29:
ffffffc009f2bad0 x28:
ffffff8003e6c800 x27:
0000000000000000
[ 245.493057] x26:
0000000000000000 x25:
0000000000000000 x24:
ffffff800226ef20
[ 245.500175] x23:
ffffffc0089ff550 x22:
0000000000000000 x21:
ffffffc008476ad0
[ 245.507294] x20:
0000000000000000 x19:
ffffffc00965ac70 x18:
fffffffffffc51a7
[ 245.514413] x17:
68702e3030303837 x16:
3a6d726f6674616c x15:
ffffffc089f2b777
[ 245.521531] x14:
ffffffc0095c9d18 x13:
0000000000000129 x12:
0000000000000129
[ 245.528649] x11:
00000000ffffffea x10:
ffffffc009621d18 x9 :
0000000000000001
[ 245.535767] x8 :
0000000000000001 x7 :
0000000000017fe8 x6 :
0000000000000001
[ 245.542885] x5 :
ffffff803fdca6d8 x4 :
0000000000000000 x3 :
0000000000000027
[ 245.550002] x2 :
0000000000000027 x1 :
0000000000000023 x0 :
0000000000000026
[ 245.557122] Call trace:
[ 245.564229] clk_branch_wait+0x130/0x140
[ 245.566490] clk_branch2_disable+0x2c/0x40
[ 245.570656] clk_core_disable+0x60/0xb0
[ 245.574561] clk_core_disable+0x68/0xb0
[ 245.578293] clk_disable+0x30/0x50
[ 245.582113] dwc3_qcom_remove+0x60/0xc0 [dwc3_qcom]
[ 245.585588] platform_remove+0x28/0x60
[ 245.590361] device_remove+0x4c/0x80
[ 245.594179] device_release_driver_internal+0x1dc/0x230
[ 245.597914] device_driver_detach+0x18/0x30
[ 245.602861] unbind_store+0xec/0x110
[ 245.607027] drv_attr_store+0x24/0x40
[ 245.610847] sysfs_kf_write+0x44/0x60
[ 245.614405] kernfs_fop_write_iter+0x128/0x1c0
[ 245.618052] new_sync_write+0xc0/0x130
[ 245.622391] vfs_write+0x1d4/0x2a0
[ 245.626123] ksys_write+0x58/0xe0
[ 245.629508] __arm64_sys_write+0x1c/0x30
[ 245.632895] invoke_syscall.constprop.0+0x5c/0x110
[ 245.636890] do_el0_svc+0xa0/0x150
[ 245.641488] el0_svc+0x18/0x60
[ 245.644872] el0t_64_sync_handler+0xa4/0x130
[ 245.647914] el0t_64_sync+0x174/0x178
[ 245.652340] ---[ end trace
0000000000000000 ]---
So, add CLK_IS_CRITICAL flag to the clock so that the kernel won't try
to disable the sleep clock.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220515210048.483898-10-robimarko@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pascal Terjan [Sun, 12 Jun 2022 13:37:44 +0000 (14:37 +0100)]
vboxguest: Do not use devm for irq
[ Upstream commit
6169525b76764acb81918aa387ac168fb9a55575 ]
When relying on devm it doesn't get freed early enough which causes the
following warning when unloading the module:
[249348.837181] remove_proc_entry: removing non-empty directory 'irq/20', leaking at least 'vboxguest'
[249348.837219] WARNING: CPU: 0 PID: 6708 at fs/proc/generic.c:715 remove_proc_entry+0x119/0x140
[249348.837379] Call Trace:
[249348.837385] unregister_irq_proc+0xbd/0xe0
[249348.837392] free_desc+0x23/0x60
[249348.837396] irq_free_descs+0x4a/0x70
[249348.837401] irq_domain_free_irqs+0x160/0x1a0
[249348.837452] mp_unmap_irq+0x5c/0x60
[249348.837458] acpi_unregister_gsi_ioapic+0x29/0x40
[249348.837463] acpi_unregister_gsi+0x17/0x30
[249348.837467] acpi_pci_irq_disable+0xbf/0xe0
[249348.837473] pcibios_disable_device+0x20/0x30
[249348.837478] pci_disable_device+0xef/0x120
[249348.837482] vbg_pci_remove+0x6c/0x70 [vboxguest]
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Pascal Terjan <pterjan@google.com>
Link: https://lore.kernel.org/r/20220612133744.4030602-1-pterjan@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Amelie Delaunay [Wed, 22 Jun 2022 16:07:17 +0000 (18:07 +0200)]
usb: dwc2: gadget: remove D+ pull-up while no vbus with usb-role-switch
[ Upstream commit
db638c6500abaffb8f7770b2a69c40d003d54ae1 ]
When using usb-role-switch, D+ pull-up is set as soon as DTCL_SFTDISCON is
cleared, whatever the vbus valid signal state is. The pull-up should not
be set when vbus isn't present (this is determined by the drd controller).
This patch ensures that B-Session (so Peripheral role + vbus valid signal)
is valid before clearing the DCTL_SFTDISCON bit when role switch is used.
Keep original behavior when usb-role-switch isn't used.
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Signed-off-by: Fabrice Gasnier <fabrice.gasnier@foss.st.com>
Link: https://lore.kernel.org/r/20220622160717.314580-1-fabrice.gasnier@foss.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Liang He [Sat, 18 Jun 2022 02:32:05 +0000 (10:32 +0800)]
usb: renesas: Fix refcount leak bug
[ Upstream commit
9d6d5303c39b8bc182475b22f45504106a07f086 ]
In usbhs_rza1_hardware_init(), of_find_node_by_name() will return
a node pointer with refcount incremented. We should use of_node_put()
when it is not used anymore.
Signed-off-by: Liang He <windhl@126.com>
Link: https://lore.kernel.org/r/20220618023205.4056548-1-windhl@126.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Liang He [Fri, 17 Jun 2022 03:46:37 +0000 (11:46 +0800)]
usb: host: ohci-ppc-of: Fix refcount leak bug
[ Upstream commit
40a959d7042bb7711e404ad2318b30e9f92c6b9b ]
In ohci_hcd_ppc_of_probe(), of_find_compatible_node() will return
a node pointer with refcount incremented. We should use of_node_put()
when it is not used anymore.
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Liang He <windhl@126.com>
Link: https://lore.kernel.org/r/20220617034637.4003115-1-windhl@126.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Po-Wen Kao [Thu, 16 Jun 2022 05:37:18 +0000 (13:37 +0800)]
scsi: ufs: ufs-mediatek: Fix the timing of configuring device regulators
[ Upstream commit
3fd23b8dfb54d9b74eba6dfdd3225db3ac116785 ]
Currently the LPM configurations of device regulators may not work since
VCC is not disabled yet while ufs_mtk_vreg_set_lpm() is executed.
Fix this by changing the timing of invoking ufs_mtk_vreg_set_lpm().
Link: https://lore.kernel.org/r/20220616053725.5681-5-stanley.chu@mediatek.com
Reviewed-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Po-Wen Kao <powen.kao@mediatek.com>
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Wed, 15 Jun 2022 06:43:06 +0000 (09:43 +0300)]
clk: ti: Stop using legacy clkctrl names for omap4 and 5
[ Upstream commit
255584b138343d4a28c6d25bd82d04b09460d672 ]
With the addition of clock-output-names, we can now unify the internal
clock naming for omap4 and 5 to follow the other TI SoCs.
We are still using legacy clkctrl names for omap4 and 5 based on the clock
manager name which is wrong. Instead, we want to use the clkctrl clock
based naming.
We must now also drop the legacy TI_CLK_CLKCTRL_COMPAT quirk for the
clkctrl clock.
This change will allow further devicetree warning cleanup as already
done for am3/4 and dra7.
Cc: linux-clk@vger.kernel.org
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Tero Kristo <kristo@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20220615064306.22254-1-tony@atomide.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sai Prakash Ranjan [Wed, 18 May 2022 16:44:13 +0000 (22:14 +0530)]
drm/meson: Fix overflow implicit truncation warnings
[ Upstream commit
98692f52c588225034cbff458622c2c06dfcb544 ]
Fix -Woverflow warnings for drm/meson driver which is a result
of moving arm64 custom MMIO accessor macros to asm-generic function
implementations giving a bonus type-checking now and uncovering these
overflow warnings.
drivers/gpu/drm/meson/meson_viu.c: In function ‘meson_viu_init’:
drivers/gpu/drm/meson/meson_registers.h:1826:48: error: large integer implicitly truncated to unsigned type [-Werror=overflow]
#define VIU_OSD_BLEND_REORDER(dest, src) ((src) << (dest * 4))
^
drivers/gpu/drm/meson/meson_viu.c:472:18: note: in expansion of macro ‘VIU_OSD_BLEND_REORDER’
writel_relaxed(VIU_OSD_BLEND_REORDER(0, 1) |
^~~~~~~~~~~~~~~~~~~~~
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sai Prakash Ranjan [Wed, 18 May 2022 16:44:12 +0000 (22:14 +0530)]
irqchip/tegra: Fix overflow implicit truncation warnings
[ Upstream commit
443685992bda9bb4f8b17fc02c9f6c60e62b1461 ]
Fix -Woverflow warnings for tegra irqchip driver which is a result
of moving arm64 custom MMIO accessor macros to asm-generic function
implementations giving a bonus type-checking now and uncovering these
overflow warnings.
drivers/irqchip/irq-tegra.c: In function ‘tegra_ictlr_suspend’:
drivers/irqchip/irq-tegra.c:151:18: warning: large integer implicitly truncated to unsigned type [-Woverflow]
writel_relaxed(~0ul, ictlr + ICTLR_COP_IER_CLR);
^
Suggested-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Sai Prakash Ranjan <quic_saipraka@quicinc.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Cc: Marc Zyngier <maz@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pali Rohár [Tue, 24 May 2022 13:28:27 +0000 (15:28 +0200)]
PCI: aardvark: Fix reporting Slot capabilities on emulated bridge
[ Upstream commit
bcdb6fd4f3e9ac1097698c8d8f56b70853b49873 ]
Slot capabilities are currently not reported because emulated bridge does
not report the PCI_EXP_FLAGS_SLOT flag.
Set PCI_EXP_FLAGS_SLOT to let the kernel know that PCI_EXP_SLT* registers
are supported.
Move setting of PCI_EXP_SLTCTL register from "dynamic" pcie_conf_read
function to static buffer as it is only statically filled the
PCI_EXP_SLTSTA_PDS flag and dynamic read callback is not needed for this
register.
Set Presence State Bit to 1 since there is no support for unplugging the
card and there is currently no platform able to detect presence of a card -
in such a case the bit needs to be set to 1.
Finally correctly set Physical Slot Number to 1 since there is only one
port and zero value is reserved for ports within the same silicon as Root
Port which is not our case for Aardvark HW.
Link: https://lore.kernel.org/r/20220524132827.8837-3-kabel@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Grzeschik [Sun, 29 May 2022 22:38:48 +0000 (00:38 +0200)]
usb: gadget: uvc: call uvc uvcg_warn on completed status instead of uvcg_info
[ Upstream commit
a725d0f6dfc5d3739d6499f30ec865305ba3544d ]
Likewise to the uvcvideo hostside driver, this patch is changing the
usb_request message of an non zero completion handler call from dev_info
to dev_warn.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220529223848.105914-4-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Grzeschik [Sun, 29 May 2022 22:38:46 +0000 (00:38 +0200)]
usb: gadget: uvc: calculate the number of request depending on framesize
[ Upstream commit
87d76b5f1d8eeb49efa16e2018e188864cbb9401 ]
The current limitation of possible number of requests being handled is
dependent on the gadget speed. It makes more sense to depend on the
typical frame size when calculating the number of requests. This patch
is changing this and is using the previous limits as boundaries for
reasonable minimum and maximum number of requests.
For a 1080p jpeg encoded video stream with a maximum imagesize of
e.g. 800kB with a maxburst of 8 and an multiplier of 1 the resulting
number of requests is calculated to 49.
800768 1
nreqs = ------ * -------------- ~= 49
2 (1024 * 8 * 1)
Tested-by: Dan Vacura <w36195@motorola.com>
Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
Link: https://lore.kernel.org/r/20220529223848.105914-2-m.grzeschik@pengutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Frank Li [Thu, 9 Jun 2022 15:44:56 +0000 (10:44 -0500)]
usb: cdns3: fix random warning message when driver load
[ Upstream commit
8659ab3d936fcf0084676f98b75b317017aa8f82 ]
Warning log:
[ 4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code!
[ 4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20
[ 4.158010] Hardware name: Freescale i.MX8QXP MEK (DT)
[ 4.163155] Call trace:
[ 4.165600] dump_backtrace+0x0/0x1b0
[ 4.169286] show_stack+0x18/0x68
[ 4.172611] dump_stack_lvl+0x68/0x84
[ 4.176286] dump_stack+0x18/0x34
[ 4.179613] kmalloc_fix_flags+0x60/0x88
[ 4.183550] new_slab+0x334/0x370
[ 4.186878] ___slab_alloc.part.108+0x4d4/0x748
[ 4.191419] __slab_alloc.isra.109+0x30/0x78
[ 4.195702] kmem_cache_alloc+0x40c/0x420
[ 4.199725] dma_pool_alloc+0xac/0x1f8
[ 4.203486] cdns3_allocate_trb_pool+0xb4/0xd0
pool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)
{
...
page = kmalloc(sizeof(*page), mem_flags);
page->vaddr = dma_alloc_coherent(pool->dev, pool->allocation,
&page->dma, mem_flags);
...
}
kmalloc was called with mem_flags, which is passed down in
cdns3_allocate_trb_pool() and have GFP_DMA32 flags.
kmall_fix_flags() report warning.
GFP_DMA32 is not useful at all. dma_alloc_coherent() will handle
DMA memory region correctly by pool->dev. GFP_DMA32 can be removed
safely.
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20220609154456.2871672-1-Frank.Li@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Frank Li [Wed, 8 Jun 2022 19:04:30 +0000 (14:04 -0500)]
usb: cdns3 fix use-after-free at workaround 2
[ Upstream commit
7d602f30149a117eea260208b1661bc404c21dfd ]
BUG: KFENCE: use-after-free read in __list_del_entry_valid+0x10/0xac
cdns3_wa2_remove_old_request()
{
...
kfree(priv_req->request.buf);
cdns3_gadget_ep_free_request(&priv_ep->endpoint, &priv_req->request);
list_del_init(&priv_req->list);
^^^ use after free
...
}
cdns3_gadget_ep_free_request() free the space pointed by priv_req,
but priv_req is used in the following list_del_init().
This patch move list_del_init() before cdns3_gadget_ep_free_request().
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Faqiang Zhu <faqiang.zhu@nxp.com>
Link: https://lore.kernel.org/r/20220608190430.2814358-1-Frank.Li@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tzung-Bi Shih [Thu, 9 Jun 2022 08:49:49 +0000 (08:49 +0000)]
platform/chrome: cros_ec_proto: don't show MKBP version if unsupported
[ Upstream commit
b36f0643ff14a2fb281b105418e4e73c9d7c11d0 ]
It wrongly showed the following message when it doesn't support MKBP:
"MKBP support version
4294967295".
Fix it.
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://lore.kernel.org/r/20220609084957.3684698-14-tzungbi@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pavan Chebbi [Thu, 9 Jun 2022 17:41:47 +0000 (13:41 -0400)]
PCI: Add ACS quirk for Broadcom BCM5750x NICs
[ Upstream commit
afd306a65cedb9589564bdb23a0c368abc4215fd ]
The Broadcom BCM5750x NICs may be multi-function devices. They do not
advertise ACS capability. Peer-to-peer transactions are not possible
between the individual functions, so it is safe to treat them as fully
isolated.
Add an ACS quirk for these devices so the functions can be in independent
IOMMU groups and attached individually to userspace applications using
VFIO.
Link: https://lore.kernel.org/r/1654796507-28610-1-git-send-email-michael.chan@broadcom.com
Signed-off-by: Pavan Chebbi <pavan.chebbi@broadcom.com>
Signed-off-by: Michael Chan <michael.chan@broadcom.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tao Jin [Fri, 20 May 2022 03:51:32 +0000 (23:51 -0400)]
HID: multitouch: new device class fix Lenovo X12 trackpad sticky
[ Upstream commit
54eed5c7b938dc4ef6b14d4ee048bbdafdbce352 ]
The trackpad of the given device sends continuous report of pointers
status as per wxn8 spec. However, the spec did not clarify when the
fingers are lifted so fast that between the interval of two report
frames fingers on pad reduced from >=2 to 0. The second last report
contains >=2 fingers with tip state 1 and the last report contains only
1 finger with tip state 0. Although this can happen unfrequently, a
quick fix will be improve the consistency to 100%. A quick fix is to
disable MT_QUIRK_ALWAYS_VALID and enable MT_QUIRK_NOT_SEEN_MEANS_UP.
Test for hid-tools is added in [1]
In addition to this, I2C device 04CA:00B1 may also need similar class
but with MT_QUIRK_FORCE_MULTI_INPUT disabled (but it does not harm to
enable it on non-multi-input device either). The respective owner has
been notified and a patch may coming soon after test.
[1]: https://gitlab.freedesktop.org/libevdev/hid-tools/-/merge_requests/130
Signed-off-by: Tao Jin <tao-j@outlook.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Oliver Upton [Tue, 16 Aug 2022 19:25:54 +0000 (19:25 +0000)]
KVM: arm64: Reject 32bit user PSTATE on asymmetric systems
[ Upstream commit
b10d86fb8e46cc812171728bcd326df2f34e9ed5 ]
KVM does not support AArch32 EL0 on asymmetric systems. To that end,
prevent userspace from configuring a vCPU in such a state through
setting PSTATE.
It is already ABI that KVM rejects such a write on a system where
AArch32 EL0 is unsupported. Though the kernel's definition of a 32bit
system changed in commit
2122a833316f ("arm64: Allow mismatched
32-bit EL0 support"), KVM's did not.
Fixes:
2122a833316f ("arm64: Allow mismatched 32-bit EL0 support")
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220816192554.1455559-3-oliver.upton@linux.dev
Signed-off-by: Sasha Levin <sashal@kernel.org>
Oliver Upton [Tue, 16 Aug 2022 19:25:53 +0000 (19:25 +0000)]
KVM: arm64: Treat PMCR_EL1.LC as RES1 on asymmetric systems
[ Upstream commit
f3c6efc72f3b20ec23566e768979802f0a398f04 ]
KVM does not support AArch32 on asymmetric systems. To that end, enforce
AArch64-only behavior on PMCR_EL1.LC when on an asymmetric system.
Fixes:
2122a833316f ("arm64: Allow mismatched 32-bit EL0 support")
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20220816192554.1455559-2-oliver.upton@linux.dev
Signed-off-by: Sasha Levin <sashal@kernel.org>
Maxim Kochetkov [Thu, 11 Aug 2022 09:48:40 +0000 (12:48 +0300)]
net: qrtr: start MHI channel after endpoit creation
[ Upstream commit
68a838b84effb7b57ba7d50b1863fc6ae35a54ce ]
MHI channel may generates event/interrupt right after enabling.
It may leads to 2 race conditions issues.
1)
Such event may be dropped by qcom_mhi_qrtr_dl_callback() at check:
if (!qdev || mhi_res->transaction_status)
return;
Because dev_set_drvdata(&mhi_dev->dev, qdev) may be not performed at
this moment. In this situation qrtr-ns will be unable to enumerate
services in device.
---------------------------------------------------------------
2)
Such event may come at the moment after dev_set_drvdata() and
before qrtr_endpoint_register(). In this case kernel will panic with
accessing wrong pointer at qcom_mhi_qrtr_dl_callback():
rc = qrtr_endpoint_post(&qdev->ep, mhi_res->buf_addr,
mhi_res->bytes_xferd);
Because endpoint is not created yet.
--------------------------------------------------------------
So move mhi_prepare_for_transfer_autoqueue after endpoint creation
to fix it.
Fixes:
a2e2cc0dbb11 ("net: qrtr: Start MHI channels during init")
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
Reviewed-by: Hemant Kumar <quic_hemantk@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Samuel Holland [Fri, 12 Aug 2022 03:16:23 +0000 (22:16 -0500)]
drm/sun4i: dsi: Prevent underflow when computing packet sizes
[ Upstream commit
82a1356a933d8443139f8886f11b63c974a09a67 ]
Currently, the packet overhead is subtracted using unsigned arithmetic.
With a short sync pulse, this could underflow and wrap around to near
the maximal u16 value. Fix this by using signed subtraction. The call to
max() will correctly handle any negative numbers that are produced.
Apply the same fix to the other timings, even though those subtractions
are less likely to underflow.
Fixes:
133add5b5ad4 ("drm/sun4i: Add Allwinner A31 MIPI-DSI controller support")
Signed-off-by: Samuel Holland <samuel@sholland.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20220812031623.34057-1-samuel@sholland.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Liang He [Tue, 26 Jul 2022 01:07:22 +0000 (09:07 +0800)]
drm/meson: Fix refcount bugs in meson_vpu_has_available_connectors()
[ Upstream commit
91b3c8dbe898df158fd2a84675f3a284ff6666f7 ]
In this function, there are two refcount leak bugs:
(1) when breaking out of for_each_endpoint_of_node(), we need call
the of_node_put() for the 'ep';
(2) we should call of_node_put() for the reference returned by
of_graph_get_remote_port() when it is not used anymore.
Fixes:
bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller")
Signed-off-by: Liang He <windhl@126.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220726010722.1319416-1-windhl@126.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Mon, 1 Aug 2022 16:54:20 +0000 (18:54 +0200)]
ASoC: SOF: Intel: hda: Fix potential buffer overflow by snprintf()
[ Upstream commit
94c1ceb043c1a002de9649bb630c8e8347645982 ]
snprintf() returns the would-be-filled size when the string overflows
the given buffer size, hence using this value may result in the buffer
overflow (although it's unrealistic).
This patch replaces with a safer version, scnprintf() for papering
over such a potential issue.
Fixes:
29c8e4398f02 ("ASoC: SOF: Intel: hda: add extended rom status dump to error log")
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20220801165420.25978-4-tiwai@suse.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ranjani Sridharan [Thu, 14 Apr 2022 18:48:15 +0000 (13:48 -0500)]
ASoC: SOF: Intel: hda: Define rom_status_reg in sof_intel_dsp_desc
[ Upstream commit
71778f7940f0b496aa1ca1134f3b70b425a59bab ]
Add the rom_status_reg field to struct sof_intel_dsp_desc and define
it for HDA platforms. This will be used to check the ROM status during
FW boot.
Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Péter Ujfalusi <peter.ujfalusi@linux.intel.com>
Link: https://lore.kernel.org/r/20220414184817.362215-14-pierre-louis.bossart@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Laurentiu Palcu [Thu, 21 Jul 2022 12:09:12 +0000 (15:09 +0300)]
drm/imx/dcss: get rid of HPD warning message
[ Upstream commit
30bdc36b8c776cd4fce5de2a96ff28b37f96942f ]
When DCSS + MIPI_DSI is used, and the last bridge in the chain supports
HPD, we can see a "Hot plug detection already enabled" warning stack
trace dump that's thrown when DCSS is initialized.
The problem appeared when HPD was enabled by default in the
bridge_connector initialization, which made the
drm_bridge_connector_enable_hpd() call, in DCSS init path, redundant.
So, let's remove that call.
Fixes:
09077bc311658 ("drm/bridge_connector: enable HPD by default if supported")
Signed-off-by: Laurentiu Palcu <laurentiu.palcu@oss.nxp.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20220721120912.6639-1-laurentiu.palcu@oss.nxp.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Steven Rostedt (Google) [Sat, 20 Aug 2022 13:43:19 +0000 (09:43 -0400)]
tracing/eprobes: Fix reading of string fields
commit
f04dec93466a0481763f3b56cdadf8076e28bfbf upstream.
Currently when an event probe (eprobe) hooks to a string field, it does
not display it as a string, but instead as a number. This makes the field
rather useless. Handle the different kinds of strings, dynamic, static,
relational/dynamic etc.
Now when a string field is used, the ":string" type can be used to display
it:
echo "e:sw sched/sched_switch comm=$next_comm:string" > dynamic_events
Link: https://lkml.kernel.org/r/20220820134400.959640191@goodmis.org
Cc: stable@vger.kernel.org
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
Cc: Tom Zanussi <zanussi@kernel.org>
Fixes:
7491e2c44278 ("tracing: Add a probe that attaches to trace events")
Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrew Donnellan [Tue, 16 Aug 2022 05:17:20 +0000 (15:17 +1000)]
gcc-plugins: Undefine LATENT_ENTROPY_PLUGIN when plugin disabled for a file
commit
012e8d2034f1bda8863435cd589636e618d6a659 upstream.
Commit
36d4b36b6959 ("lib/nodemask: inline next_node_in() and
node_random()") refactored some code by moving node_random() from
lib/nodemask.c to include/linux/nodemask.h, thus requiring nodemask.h to
include random.h, which conditionally defines add_latent_entropy()
depending on whether the macro LATENT_ENTROPY_PLUGIN is defined.
This broke the build on powerpc, where nodemask.h is indirectly included
in arch/powerpc/kernel/prom_init.c, part of the early boot machinery that
is excluded from the latent entropy plugin using
DISABLE_LATENT_ENTROPY_PLUGIN. It turns out that while we add a gcc flag
to disable the actual plugin, we don't undefine LATENT_ENTROPY_PLUGIN.
This leads to the following:
CC arch/powerpc/kernel/prom_init.o
In file included from ./include/linux/nodemask.h:97,
from ./include/linux/mmzone.h:17,
from ./include/linux/gfp.h:7,
from ./include/linux/xarray.h:15,
from ./include/linux/radix-tree.h:21,
from ./include/linux/idr.h:15,
from ./include/linux/kernfs.h:12,
from ./include/linux/sysfs.h:16,
from ./include/linux/kobject.h:20,
from ./include/linux/pci.h:35,
from arch/powerpc/kernel/prom_init.c:24:
./include/linux/random.h: In function 'add_latent_entropy':
./include/linux/random.h:25:46: error: 'latent_entropy' undeclared (first use in this function); did you mean 'add_latent_entropy'?
25 | add_device_randomness((const void *)&latent_entropy, sizeof(latent_entropy));
| ^~~~~~~~~~~~~~
| add_latent_entropy
./include/linux/random.h:25:46: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [scripts/Makefile.build:249: arch/powerpc/kernel/prom_init.o] Fehler 1
make[1]: *** [scripts/Makefile.build:465: arch/powerpc/kernel] Fehler 2
make: *** [Makefile:1855: arch/powerpc] Error 2
Change the DISABLE_LATENT_ENTROPY_PLUGIN flags to undefine
LATENT_ENTROPY_PLUGIN for files where the plugin is disabled.
Cc: Yury Norov <yury.norov@gmail.com>
Fixes:
38addce8b600 ("gcc-plugins: Add latent_entropy plugin")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216367
Link: https://lore.kernel.org/linuxppc-dev/alpine.DEB.2.22.394.2208152006320.289321@ramsan.of.borg/
Reported-by: Erhard Furtner <erhard_f@mailbox.org>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Reviewed-by: Yury Norov <yury.norov@gmail.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20220816051720.44108-1-ajd@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masahiro Yamada [Sat, 13 Aug 2022 23:09:28 +0000 (08:09 +0900)]
kbuild: fix the modules order between drivers and libs
commit
113147510b48e764e624e3d0e6707a1e48bc05a9 upstream.
Commit
b2c885549122 ("kbuild: update modules.order only when contained
modules are updated") accidentally changed the modules order.
Prior to that commit, the modules order was determined based on
vmlinux-dirs, which lists core-y/m, drivers-y/m, libs-y/m, in this order.
Now, subdir-modorder lists them in a different order: core-y/m, libs-y/m,
drivers-y/m.
Presumably, there was no practical issue because the modules in drivers
and libs are orthogonal, but there is no reason to have this distortion.
Get back to the original order.
Fixes:
b2c885549122 ("kbuild: update modules.order only when contained modules are updated")
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lin Ma [Wed, 17 Aug 2022 18:49:21 +0000 (11:49 -0700)]
igb: Add lock to avoid data race
commit
6faee3d4ee8be0f0367d0c3d826afb3571b7a5e0 upstream.
The commit
c23d92b80e0b ("igb: Teardown SR-IOV before
unregister_netdev()") places the unregister_netdev() call after the
igb_disable_sriov() call to avoid functionality issue.
However, it introduces several race conditions when detaching a device.
For example, when .remove() is called, the below interleaving leads to
use-after-free.
(FREE from device detaching) | (USE from netdev core)
igb_remove | igb_ndo_get_vf_config
igb_disable_sriov | vf >= adapter->vfs_allocated_count?
kfree(adapter->vf_data) |
adapter->vfs_allocated_count = 0 |
| memcpy(... adapter->vf_data[vf]
Moreover, the igb_disable_sriov() also suffers from data race with the
requests from VF driver.
(FREE from device detaching) | (USE from requests)
igb_remove | igb_msix_other
igb_disable_sriov | igb_msg_task
kfree(adapter->vf_data) | vf < adapter->vfs_allocated_count
adapter->vfs_allocated_count = 0 |
To this end, this commit first eliminates the data races from netdev
core by using rtnl_lock (similar to commit
719479230893 ("dpaa2-eth: add
MAC/PHY support through phylink")). And then adds a spinlock to
eliminate races from driver requests. (similar to commit
1e53834ce541
("ixgbe: Add locking to prevent panic when setting sriov_numvfs to zero")
Fixes:
c23d92b80e0b ("igb: Teardown SR-IOV before unregister_netdev()")
Signed-off-by: Lin Ma <linma@zju.edu.cn>
Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://lore.kernel.org/r/20220817184921.735244-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Tue, 16 Aug 2022 14:23:57 +0000 (16:23 +0200)]
stmmac: intel: Add a missing clk_disable_unprepare() call in intel_eth_pci_remove()
commit
5c23d6b717e4e956376f3852b90f58e262946b50 upstream.
Commit
09f012e64e4b ("stmmac: intel: Fix clock handling on error and remove
paths") removed this clk_disable_unprepare()
This was partly revert by commit
ac322f86b56c ("net: stmmac: Fix clock
handling on remove path") which removed this clk_disable_unprepare()
because:
"
While unloading the dwmac-intel driver, clk_disable_unprepare() is
being called twice in stmmac_dvr_remove() and
intel_eth_pci_remove(). This causes kernel panic on the second call.
"
However later on, commit
5ec55823438e8 ("net: stmmac: add clocks management
for gmac driver") has updated stmmac_dvr_remove() which do not call
clk_disable_unprepare() anymore.
So this call should now be called from intel_eth_pci_remove().
Fixes:
5ec55823438e8 ("net: stmmac: add clocks management for gmac driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/d7c8c1dadf40df3a7c9e643f76ffadd0ccc1ad1b.1660659689.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Csókás Bence [Thu, 11 Aug 2022 10:13:49 +0000 (12:13 +0200)]
fec: Fix timer capture timing in `fec_ptp_enable_pps()`
commit
61d5e2a251fb20c2c5e998c3f1d52ed6d5360319 upstream.
Code reimplements functionality already in `fec_ptp_read()`,
but misses check for FEC_QUIRK_BUG_CAPTURE. Replace with function call.
Fixes:
28b5f058cf1d ("net: fec: ptp: fix convergence issue to support LinuxPTP stack")
Signed-off-by: Csókás Bence <csokas.bence@prolan.hu>
Link: https://lore.kernel.org/r/20220811101348.13755-1-csokas.bence@prolan.hu
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Brady [Tue, 2 Aug 2022 08:19:17 +0000 (10:19 +0200)]
i40e: Fix to stop tx_timeout recovery if GLOBR fails
commit
57c942bc3bef0970f0b21f8e0998e76a900ea80d upstream.
When a tx_timeout fires, the PF attempts to recover by incrementally
resetting. First we try a PFR, then CORER and finally a GLOBR. If the
GLOBR fails, then we keep hitting the tx_timeout and incrementing the
recovery level and issuing dmesgs, which is both annoying to the user
and accomplishes nothing.
If the GLOBR fails, then we're pretty much totally hosed, and there's
not much else we can do to recover, so this makes it such that we just
kill the VSI and stop hitting the tx_timeout in such a case.
Fixes:
41c445ff0f48 ("i40e: main driver core")
Signed-off-by: Alan Brady <alan.brady@intel.com>
Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Frieder Schrempf [Tue, 2 Aug 2022 06:43:34 +0000 (08:43 +0200)]
regulator: pca9450: Remove restrictions for regulator-name
commit
b0de7fa706506bf0591037908376351beda8c5d6 upstream.
The device bindings shouldn't put any constraints on the regulator-name
property specified in the generic bindings. This allows using arbitrary
and descriptive names for the regulators.
Suggested-by: Mark Brown <broonie@kernel.org>
Fixes:
7ae9e3a6bf3f ("dt-bindings: regulator: add pca9450 regulator yaml")
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Link: https://lore.kernel.org/r/20220802064335.8481-1-frieder@fris.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Uwe Kleine-König [Wed, 20 Jul 2022 15:09:33 +0000 (17:09 +0200)]
i2c: imx: Make sure to unregister adapter on remove()
commit
d98bdd3a5b50446d8e010be5b04ce81c4eabf728 upstream.
If for whatever reasons pm_runtime_resume_and_get() fails and .remove() is
exited early, the i2c adapter stays around and the irq still calls its
handler, while the driver data and the register mapping go away. So if
later the i2c adapter is accessed or the irq triggers this results in
havoc accessing freed memory and unmapped registers.
So unregister the software resources even if resume failed, and only skip
the hardware access in that case.
Fixes:
588eb93ea49f ("i2c: imx: add runtime pm support to improve the performance")
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Grzegorz Siwik [Fri, 12 Aug 2022 13:25:48 +0000 (15:25 +0200)]
ice: Ignore EEXIST when setting promisc mode
commit
11e551a2efa4481bd4f616ab75374a2710b480e9 upstream.
Ignore EEXIST error when setting promiscuous mode.
This fix is needed because the driver could set promiscuous mode
when it still has not cleared properly.
Promiscuous mode could be set only once, so setting it second
time will be rejected.
Fixes:
5eda8afd6bcc ("ice: Add support for PF/VF promiscuous mode")
Signed-off-by: Grzegorz Siwik <grzegorz.siwik@intel.com>
Link: https://lore.kernel.org/all/CAK8fFZ7m-KR57M_rYX6xZN39K89O=LGooYkKsu6HKt0Bs+x6xQ@mail.gmail.com/
Tested-by: Jaroslav Pulchart <jaroslav.pulchart@gooddata.com>
Tested-by: Igor Raits <igor@gooddata.com>
Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rustam Subkhankulov [Wed, 17 Aug 2022 00:38:45 +0000 (03:38 +0300)]
net: dsa: sja1105: fix buffer overflow in sja1105_setup_devlink_regions()
commit
fd8e899cdb5ecaf8e8ee73854a99e10807eef1de upstream.
If an error occurs in dsa_devlink_region_create(), then 'priv->regions'
array will be accessed by negative index '-1'.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Rustam Subkhankulov <subkhankulov@ispras.ru>
Fixes:
bf425b82059e ("net: dsa: sja1105: expose static config as devlink region")
Link: https://lore.kernel.org/r/20220817003845.389644-1-subkhankulov@ispras.ru
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vladimir Oltean [Tue, 16 Aug 2022 20:14:45 +0000 (23:14 +0300)]
net: dsa: don't warn in dsa_port_set_state_now() when driver doesn't support it
commit
211987f3ac734000ea1548784b2a4539a974fbc8 upstream.
ds->ops->port_stp_state_set() is, like most DSA methods, optional, and
if absent, the port is supposed to remain in the forwarding state (as
standalone). Such is the case with the mv88e6060 driver, which does not
offload the bridge layer. DSA warns that the STP state can't be changed
to FORWARDING as part of dsa_port_enable_rt(), when in fact it should not.
The error message is also not up to modern standards, so take the
opportunity to make it more descriptive.
Fixes:
fd3645413197 ("net: dsa: change scope of STP state setter")
Reported-by: Sergei Antonov <saproj@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Reviewed-by: Sergei Antonov <saproj@gmail.com>
Link: https://lore.kernel.org/r/20220816201445.1809483-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jakub Kicinski [Tue, 16 Aug 2022 16:19:39 +0000 (09:19 -0700)]
net: genl: fix error path memory leak in policy dumping
commit
249801360db3dec4f73768c502192020bfddeacc upstream.
If construction of the array of policies fails when recording
non-first policy we need to unwind.
netlink_policy_dump_add_policy() itself also needs fixing as
it currently gives up on error without recording the allocated
pointer in the pstate pointer.
Reported-by: syzbot+dc54d9ba8153b216cae0@syzkaller.appspotmail.com
Fixes:
50a896cf2d6f ("genetlink: properly support per-op policy dumping")
Link: https://lore.kernel.org/r/20220816161939.577583-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vladimir Oltean [Tue, 16 Aug 2022 13:53:45 +0000 (16:53 +0300)]
net: dsa: felix: fix ethtool 256-511 and 512-1023 TX packet counters
commit
40d21c4565bce064c73a03b79a157a3493c518b9 upstream.
What the driver actually reports as 256-511 is in fact 512-1023, and the
TX packets in the 256-511 bucket are not reported. Fix that.
Fixes:
56051948773e ("net: dsa: ocelot: add driver for Felix switch family")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arun Ramadoss [Tue, 16 Aug 2022 10:55:16 +0000 (16:25 +0530)]
net: dsa: microchip: ksz9477: fix fdb_dump last invalid entry
commit
36c0d935015766bf20d621c18313f17691bda5e3 upstream.
In the ksz9477_fdb_dump function it reads the ALU control register and
exit from the timeout loop if there is valid entry or search is
complete. After exiting the loop, it reads the alu entry and report to
the user space irrespective of entry is valid. It works till the valid
entry. If the loop exited when search is complete, it reads the alu
table. The table returns all ones and it is reported to user space. So
bridge fdb show gives ff:ff:ff:ff:ff:ff as last entry for every port.
To fix it, after exiting the loop the entry is reported only if it is
valid one.
Fixes:
b987e98e50ab ("dsa: add DSA switch driver for Microchip KSZ9477")
Signed-off-by: Arun Ramadoss <arun.ramadoss@microchip.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20220816105516.18350-1-arun.ramadoss@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Xiong [Sat, 13 Aug 2022 12:49:08 +0000 (20:49 +0800)]
net: fix potential refcount leak in ndisc_router_discovery()
commit
7396ba87f1edf549284869451665c7c4e74ecd4f upstream.
The issue happens on specific paths in the function. After both the
object `rt` and `neigh` are grabbed successfully, when `lifetime` is
nonzero but the metric needs change, the function just deletes the
route and set `rt` to NULL. Then, it may try grabbing `rt` and `neigh`
again if above conditions hold. The function simply overwrite `neigh`
if succeeds or returns if fails, without decreasing the reference
count of previous `neigh`. This may result in memory leaks.
Fix it by decrementing the reference count of `neigh` in place.
Fixes:
6b2e04bc240f ("net: allow user to set metric on default route learned via Router Advertisement")
Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergei Antonov [Fri, 12 Aug 2022 17:13:39 +0000 (20:13 +0300)]
net: moxa: pass pdev instead of ndev to DMA functions
commit
3a12df22a8f68954a4ba48435c06b3d1791c87c4 upstream.
dma_map_single() calls fail in moxart_mac_setup_desc_ring() and
moxart_mac_start_xmit() which leads to an incessant output of this:
[ 16.043925] moxart-ethernet
92000000.mac eth0: DMA mapping error
[ 16.050957] moxart-ethernet
92000000.mac eth0: DMA mapping error
[ 16.058229] moxart-ethernet
92000000.mac eth0: DMA mapping error
Passing pdev to DMA is a common approach among net drivers.
Fixes:
6c821bd9edc9 ("net: Add MOXA ART SoCs ethernet driver")
Signed-off-by: Sergei Antonov <saproj@gmail.com>
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20220812171339.2271788-1-saproj@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Amit Cohen [Fri, 12 Aug 2022 15:32:01 +0000 (17:32 +0200)]
mlxsw: spectrum: Clear PTP configuration after unregistering the netdevice
commit
a159e986ad26d3f35c0157ac92760ba5e44e6785 upstream.
Currently as part of removing port, PTP API is called to clear the
existing configuration and set the 'rx_filter' and 'tx_type' to zero.
The clearing is done before unregistering the netdevice, which means that
there is a window of time in which the user can reconfigure PTP in the
port, and this configuration will not be cleared.
Reorder the operations, clear PTP configuration after unregistering the
netdevice.
Fixes:
8748642751ede ("mlxsw: spectrum: PTP: Support SIOCGHWTSTAMP, SIOCSHWTSTAMP ioctls")
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergei Antonov [Thu, 11 Aug 2022 07:09:39 +0000 (10:09 +0300)]
net: dsa: mv88e6060: prevent crash on an unused port
commit
246bbf2f977ea36aaf41f5d24370fef433250728 upstream.
If the port isn't a CPU port nor a user port, 'cpu_dp'
is a null pointer and a crash happened on dereferencing
it in mv88e6060_setup_port():
[ 9.575872] Unable to handle kernel NULL pointer dereference at virtual address
00000014
...
[ 9.942216] mv88e6060_setup from dsa_register_switch+0x814/0xe84
[ 9.948616] dsa_register_switch from mdio_probe+0x2c/0x54
[ 9.954433] mdio_probe from really_probe.part.0+0x98/0x2a0
[ 9.960375] really_probe.part.0 from driver_probe_device+0x30/0x10c
[ 9.967029] driver_probe_device from __device_attach_driver+0xb8/0x13c
[ 9.973946] __device_attach_driver from bus_for_each_drv+0x90/0xe0
[ 9.980509] bus_for_each_drv from __device_attach+0x110/0x184
[ 9.986632] __device_attach from bus_probe_device+0x8c/0x94
[ 9.992577] bus_probe_device from deferred_probe_work_func+0x78/0xa8
[ 9.999311] deferred_probe_work_func from process_one_work+0x290/0x73c
[ 10.006292] process_one_work from worker_thread+0x30/0x4b8
[ 10.012155] worker_thread from kthread+0xd4/0x10c
[ 10.017238] kthread from ret_from_fork+0x14/0x3c
Fixes:
0abfd494deef ("net: dsa: use dedicated CPU port")
CC: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
CC: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sergei Antonov <saproj@gmail.com>
Signed-off-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://lore.kernel.org/r/20220811070939.1717146-1-saproj@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Xiong [Wed, 10 Aug 2022 15:29:13 +0000 (23:29 +0800)]
net/sunrpc: fix potential memory leaks in rpc_sysfs_xprt_state_change()
commit
bfc48f1b0505ffcb03a6d749139b7577d6b81ae0 upstream.
The issue happens on some error handling paths. When the function
fails to grab the object `xprt`, it simply returns 0, forgetting to
decrease the reference count of another object `xps`, which is
increased by rpc_sysfs_xprt_kobj_get_xprt_switch(), causing refcount
leaks. Also, the function forgets to check whether `xps` is valid
before using it, which may result in NULL-dereferencing issues.
Fix it by adding proper error handling code when either `xprt` or
`xps` is NULL.
Fixes:
5b7eb78486cd ("SUNRPC: take a xprt offline using sysfs")
Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Neil Armstrong [Thu, 11 Aug 2022 13:44:45 +0000 (15:44 +0200)]
spi: meson-spicc: add local pow2 clock ops to preserve rate between messages
commit
09992025dacd258c823f50e82db09d7ef06cdac4 upstream.
At the end of a message, the HW gets a reset in meson_spicc_unprepare_transfer(),
this resets the SPICC_CONREG register and notably the value set by the
Common Clock Framework.
This is problematic because:
- the register value CCF can be different from the corresponding CCF cached rate
- CCF is allowed to change the clock rate whenever the HW state
This introduces:
- local pow2 clock ops checking the HW state before allowing a clock operation
- separation of legacy pow2 clock patch and new enhanced clock path
- SPICC_CONREG datarate value is now value kepts across messages
It has been checked that:
- SPICC_CONREG datarate value is kept across messages
- CCF is only allowed to change the SPICC_CONREG datarate value when busy
- SPICC_CONREG datarate value is correct for each transfer
This didn't appear before commit
3e0cf4d3fc29 ("spi: meson-spicc: add a linear clock divider support")
because we recalculated and wrote the rate for each xfer.
Fixes:
3e0cf4d3fc29 ("spi: meson-spicc: add a linear clock divider support")
Reported-by: Da Xue <da@libre.computer>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20220811134445.678446-1-narmstrong@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Ellerman [Mon, 15 Aug 2022 06:55:23 +0000 (16:55 +1000)]
powerpc/pci: Fix get_phb_number() locking
commit
8d48562a2729742f767b0fdd994d6b2a56a49c63 upstream.
The recent change to get_phb_number() causes a DEBUG_ATOMIC_SLEEP
warning on some systems:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper
preempt_count: 1, expected: 0
RCU nest depth: 0, expected: 0
1 lock held by swapper/1:
#0:
c157efb0 (hose_spinlock){+.+.}-{2:2}, at: pcibios_alloc_controller+0x64/0x220
Preemption disabled at:
[<
00000000>] 0x0
CPU: 0 PID: 1 Comm: swapper Not tainted 5.19.0-yocto-standard+ #1
Call Trace:
[
d101dc90] [
c073b264] dump_stack_lvl+0x50/0x8c (unreliable)
[
d101dcb0] [
c0093b70] __might_resched+0x258/0x2a8
[
d101dcd0] [
c0d3e634] __mutex_lock+0x6c/0x6ec
[
d101dd50] [
c0a84174] of_alias_get_id+0x50/0xf4
[
d101dd80] [
c002ec78] pcibios_alloc_controller+0x1b8/0x220
[
d101ddd0] [
c140c9dc] pmac_pci_init+0x198/0x784
[
d101de50] [
c140852c] discover_phbs+0x30/0x4c
[
d101de60] [
c0007fd4] do_one_initcall+0x94/0x344
[
d101ded0] [
c1403b40] kernel_init_freeable+0x1a8/0x22c
[
d101df10] [
c00086e0] kernel_init+0x34/0x160
[
d101df30] [
c001b334] ret_from_kernel_thread+0x5c/0x64
This is because pcibios_alloc_controller() holds hose_spinlock but
of_alias_get_id() takes of_mutex which can sleep.
The hose_spinlock protects the phb_bitmap, and also the hose_list, but
it doesn't need to be held while get_phb_number() calls the OF routines,
because those are only looking up information in the device tree.
So fix it by having get_phb_number() take the hose_spinlock itself, only
where required, and then dropping the lock before returning.
pcibios_alloc_controller() then needs to take the lock again before the
list_add() but that's safe, the order of the list is not important.
Fixes:
0fe1e96fef0a ("powerpc/pci: Prefer PCI domain assignment via DT 'linux,pci-domain' and alias")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20220815065550.1303620-1-mpe@ellerman.id.au
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
projects / platform / kernel / linux-rpi.git / log