commit d6f7bb5bb29096b2935c55deeb545616dab74406
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Wed Sep 15 10:02:36 2021 +0200
Linux 5.14.4
Link: https://lore.kernel.org/r/20210913131113.390368911@linuxfoundation.org
Tested-by: Florian Fainelli <f.fainelli@gmail.com>
Tested-by: Fox Chen <foxhlchen@gmail.com>
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Justin M. Forbes <jforbes@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ea003ac946386cde7d894ed274ecc41b36026878
Author: Leon Romanovsky <leon@kernel.org>
Date: Thu Jul 29 20:19:24 2021 +0300
devlink: Break parameter notification sequence to be before/after unload/load driver
commit 05a7f4a8dff19999ca8a83a35ff4782689de7bfc upstream.
The change of namespaces during devlink reload calls to driver unload
before it accesses devlink parameters. The commands below causes to
use-after-free bug when trying to get flow steering mode.
* ip netns add n1
* devlink dev reload pci/0000:00:09.0 netns n1
==================================================================
BUG: KASAN: use-after-free in mlx5_devlink_fs_mode_get+0x96/0xa0 [mlx5_core]
Read of size 4 at addr ffff888009d04308 by task devlink/275
CPU: 6 PID: 275 Comm: devlink Not tainted 5.12.0-rc2+ #2853
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
dump_stack+0x93/0xc2
print_address_description.constprop.0+0x18/0x140
? mlx5_devlink_fs_mode_get+0x96/0xa0 [mlx5_core]
? mlx5_devlink_fs_mode_get+0x96/0xa0 [mlx5_core]
kasan_report.cold+0x7c/0xd8
? mlx5_devlink_fs_mode_get+0x96/0xa0 [mlx5_core]
mlx5_devlink_fs_mode_get+0x96/0xa0 [mlx5_core]
devlink_nl_param_fill+0x1c8/0xe80
? __free_pages_ok+0x37a/0x8a0
? devlink_flash_update_timeout_notify+0xd0/0xd0
? lock_acquire+0x1a9/0x6d0
? fs_reclaim_acquire+0xb7/0x160
? lock_is_held_type+0x98/0x110
? 0xffffffff81000000
? lock_release+0x1f9/0x6c0
? fs_reclaim_release+0xa1/0xf0
? lock_downgrade+0x6d0/0x6d0
? lock_is_held_type+0x98/0x110
? lock_is_held_type+0x98/0x110
? memset+0x20/0x40
? __build_skb_around+0x1f8/0x2b0
devlink_param_notify+0x6d/0x180
devlink_reload+0x1c3/0x520
? devlink_remote_reload_actions_performed+0x30/0x30
? mutex_trylock+0x24b/0x2d0
? devlink_nl_cmd_reload+0x62b/0x1070
devlink_nl_cmd_reload+0x66d/0x1070
? devlink_reload+0x520/0x520
? devlink_get_from_attrs+0x1bc/0x260
? devlink_nl_pre_doit+0x64/0x4d0
genl_family_rcv_msg_doit+0x1e9/0x2f0
? mutex_lock_io_nested+0x1130/0x1130
? genl_family_rcv_msg_attrs_parse.constprop.0+0x240/0x240
? security_capable+0x51/0x90
genl_rcv_msg+0x27f/0x4a0
? genl_get_cmd+0x3c0/0x3c0
? lock_acquire+0x1a9/0x6d0
? devlink_reload+0x520/0x520
? lock_release+0x6c0/0x6c0
netlink_rcv_skb+0x11d/0x340
? genl_get_cmd+0x3c0/0x3c0
? netlink_ack+0x9f0/0x9f0
? lock_release+0x1f9/0x6c0
genl_rcv+0x24/0x40
netlink_unicast+0x433/0x700
? netlink_attachskb+0x730/0x730
? _copy_from_iter_full+0x178/0x650
? __alloc_skb+0x113/0x2b0
netlink_sendmsg+0x6f1/0xbd0
? netlink_unicast+0x700/0x700
? lock_is_held_type+0x98/0x110
? netlink_unicast+0x700/0x700
sock_sendmsg+0xb0/0xe0
__sys_sendto+0x193/0x240
? __x64_sys_getpeername+0xb0/0xb0
? do_sys_openat2+0x10b/0x370
? __up_read+0x1a1/0x7b0
? do_user_addr_fault+0x219/0xdc0
? __x64_sys_openat+0x120/0x1d0
? __x64_sys_open+0x1a0/0x1a0
__x64_sys_sendto+0xdd/0x1b0
? syscall_enter_from_user_mode+0x1d/0x50
do_syscall_64+0x2d/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7fc69d0af14a
Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 76 c3 0f 1f 44 00 00 55 48 83 ec 30 44 89 4c
RSP: 002b:00007ffc1d8292f8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fc69d0af14a
RDX: 0000000000000038 RSI: 0000555f57c56440 RDI: 0000000000000003
RBP: 0000555f57c56410 R08: 00007fc69d17b200 R09: 000000000000000c
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 146:
kasan_save_stack+0x1b/0x40
__kasan_kmalloc+0x99/0xc0
mlx5_init_fs+0xf0/0x1c50 [mlx5_core]
mlx5_load+0xd2/0x180 [mlx5_core]
mlx5_init_one+0x2f6/0x450 [mlx5_core]
probe_one+0x47d/0x6e0 [mlx5_core]
pci_device_probe+0x2a0/0x4a0
really_probe+0x20a/0xc90
driver_probe_device+0xd8/0x380
device_driver_attach+0x1df/0x250
__driver_attach+0xff/0x240
bus_for_each_dev+0x11e/0x1a0
bus_add_driver+0x309/0x570
driver_register+0x1ee/0x380
0xffffffffa06b8062
do_one_initcall+0xd5/0x410
do_init_module+0x1c8/0x760
load_module+0x6d8b/0x9650
__do_sys_finit_module+0x118/0x1b0
do_syscall_64+0x2d/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xae
Freed by task 275:
kasan_save_stack+0x1b/0x40
kasan_set_track+0x1c/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0x102/0x140
slab_free_freelist_hook+0x74/0x1b0
kfree+0xd7/0x2a0
mlx5_unload+0x16/0xb0 [mlx5_core]
mlx5_unload_one+0xae/0x120 [mlx5_core]
mlx5_devlink_reload_down+0x1bc/0x380 [mlx5_core]
devlink_reload+0x141/0x520
devlink_nl_cmd_reload+0x66d/0x1070
genl_family_rcv_msg_doit+0x1e9/0x2f0
genl_rcv_msg+0x27f/0x4a0
netlink_rcv_skb+0x11d/0x340
genl_rcv+0x24/0x40
netlink_unicast+0x433/0x700
netlink_sendmsg+0x6f1/0xbd0
sock_sendmsg+0xb0/0xe0
__sys_sendto+0x193/0x240
__x64_sys_sendto+0xdd/0x1b0
do_syscall_64+0x2d/0x40
entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff888009d04300
which belongs to the cache kmalloc-128 of size 128
The buggy address is located 8 bytes inside of
128-byte region [ffff888009d04300, ffff888009d04380)
The buggy address belongs to the page:
page:0000000086a64ecc refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888009d04000 pfn:0x9d04
head:0000000086a64ecc order:1 compound_mapcount:0
flags: 0x4000000000010200(slab|head)
raw: 4000000000010200 ffffea0000203980 0000000200000002 ffff8880050428c0
raw: ffff888009d04000 000000008020001d 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888009d04200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888009d04280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888009d04300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888009d04380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888009d04400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
The right solution to devlink reload is to notify about deletion of
parameters, unload driver, change net namespaces, load driver and notify
about addition of parameters.
Fixes: 070c63f20f6c ("net: devlink: allow to change namespaces during reload")
Reviewed-by: Parav Pandit <parav@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 68bd8e688eb5c9dde9da8d0f7384c22ff6f0c341
Author: Linus Walleij <linus.walleij@linaro.org>
Date: Sun Aug 15 01:55:14 2021 +0200
clk: kirkwood: Fix a clocking boot regression
commit aaedb9e00e5400220a8871180d23a83e67f29f63 upstream.
Since a few kernel releases the Pogoplug 4 has crashed like this
during boot:
Unable to handle kernel NULL pointer dereference at virtual address 00000002
(...)
[<c04116ec>] (strlen) from [<c00ead80>] (kstrdup+0x1c/0x4c)
[<c00ead80>] (kstrdup) from [<c04591d8>] (__clk_register+0x44/0x37c)
[<c04591d8>] (__clk_register) from [<c04595ec>] (clk_hw_register+0x20/0x44)
[<c04595ec>] (clk_hw_register) from [<c045bfa8>] (__clk_hw_register_mux+0x198/0x1e4)
[<c045bfa8>] (__clk_hw_register_mux) from [<c045c050>] (clk_register_mux_table+0x5c/0x6c)
[<c045c050>] (clk_register_mux_table) from [<c0acf3e0>] (kirkwood_clk_muxing_setup.constprop.0+0x13c/0x1ac)
[<c0acf3e0>] (kirkwood_clk_muxing_setup.constprop.0) from [<c0aceae0>] (of_clk_init+0x12c/0x214)
[<c0aceae0>] (of_clk_init) from [<c0ab576c>] (time_init+0x20/0x2c)
[<c0ab576c>] (time_init) from [<c0ab3d18>] (start_kernel+0x3dc/0x56c)
[<c0ab3d18>] (start_kernel) from [<00000000>] (0x0)
Code: e3130020 1afffffb e12fff1e c08a1078 (e5d03000)
This is because the "powersave" mux clock 0 was provided in an unterminated
array, which is required by the loop in the driver:
/* Count, allocate, and register clock muxes */
for (n = 0; desc[n].name;)
n++;
Here n will go out of bounds and then call clk_register_mux() on random
memory contents after the mux clock.
Fix this by terminating the array with a blank entry.
Fixes: 105299381d87 ("cpufreq: kirkwood: use the powersave multiplexer")
Cc: stable@vger.kernel.org
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: Gregory CLEMENT <gregory.clement@bootlin.com>
Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210814235514.403426-1-linus.walleij@linaro.org
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d827bd2396a5ebb86a89b93938f32ccc681f8504
Author: Helge Deller <deller@gmx.de>
Date: Thu Sep 2 23:24:42 2021 +0200
parisc: Fix unaligned-access crash in bootloader
commit c42813b71a06a2ff4a155aa87ac609feeab76cf3 upstream.
Kernel v5.14 has various changes to optimize unaligned memory accesses,
e.g. commit 0652035a5794 ("asm-generic: unaligned: remove byteshift helpers").
Those changes triggered an unalignment-exception and thus crashed the
bootloader on parisc because the unaligned "output_len" variable now suddenly
was read word-wise while it was read byte-wise in the past.
Fix this issue by declaring the external output_len variable as char which then
forces the compiler to generate byte-accesses.
Signed-off-by: Helge Deller <deller@gmx.de>
Cc: Arnd Bergmann <arnd@kernel.org>
Cc: John David Anglin <dave.anglin@bell.net>
Bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102162
Fixes: 8c031ba63f8f ("parisc: Unbreak bootloader due to gcc-7 optimizations")
Fixes: 0652035a5794 ("asm-generic: unaligned: remove byteshift helpers")
Cc: <stable@vger.kernel.org> # v5.14+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d06f58625753eb62fcd17d8e2bc53a85f91c1bc0
Author: Daniel Thompson <daniel.thompson@linaro.org>
Date: Thu Jul 22 15:46:23 2021 +0100
backlight: pwm_bl: Improve bootloader/kernel device handover
commit 79fad92f2e596f5a8dd085788a24f540263ef887 upstream.
Currently there are (at least) two problems in the way pwm_bl starts
managing the enable_gpio pin. Both occur when the backlight is initially
off and the driver finds the pin not already in output mode and, as a
result, unconditionally switches it to output-mode and asserts the signal.
Problem 1: This could cause the backlight to flicker since, at this stage
in driver initialisation, we have no idea what the PWM and regulator are
doing (an unconfigured PWM could easily "rest" at 100% duty cycle).
Problem 2: This will cause us not to correctly honour the
post_pwm_on_delay (which also risks flickers).
Fix this by moving the code to configure the GPIO output mode until after
we have examines the handover state. That allows us to initialize
enable_gpio to off if the backlight is currently off and on if the
backlight is on.
Cc: stable@vger.kernel.org
Reported-by: Marek Vasut <marex@denx.de>
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Marek Vasut <marex@denx.de>
Tested-by: Marek Vasut <marex@denx.de>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ac16137d64bb0844b22ea90967bfc54360683be8
Author: Julio Faracco <jcfaracco@gmail.com>
Date: Sun Sep 5 00:54:38 2021 +0900
bootconfig: Fix missing return check of xbc_node_compose_key function
commit 903bd067faa837fddb6e5c8b740c3374dc582f04 upstream.
The function `xbc_show_list should` handle the keys during the
composition. Even the errors returned by the compose function. Instead
of removing the `ret` variable, it should save the value and show the
exact error. This missing variable is causing a compilation issue also.
Link: https://lkml.kernel.org/r/163077087861.222577.12884543474750968146.stgit@devnote2
Fixes: e5efaeb8a8f5 ("bootconfig: Support mixing a value and subkeys under a key")
Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Cc: stable@vger.kernel.org
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fbc0d19393cbf49c28f538b7fdd94f92655f7870
Author: Niklas Schnelle <schnelle@linux.ibm.com>
Date: Wed Sep 8 10:18:48 2021 +0200
RDMA/mlx5: Fix number of allocated XLT entries
commit 9660dcbe0d9186976917c94bce4e69dbd8d7a974 upstream.
In commit 8010d74b9965b ("RDMA/mlx5: Split the WR setup out of
mlx5_ib_update_xlt()") the allocation logic was split out of
mlx5_ib_update_xlt() and the logic was changed to enable better OOM
handling. Sadly this change introduced a miscalculation of the number of
entries that were actually allocated when under memory pressure where it
can actually become 0 which on s390 lets dma_map_single() fail.
It can also lead to corruption of the free pages list when the wrong
number of entries is used in the calculation of sg->length which is used
as argument for free_pages().
Fix this by using the allocation size instead of misusing get_order(size).
Cc: stable@vger.kernel.org
Fixes: 8010d74b9965 ("RDMA/mlx5: Split the WR setup out of mlx5_ib_update_xlt()")
Link: https://lore.kernel.org/r/20210908081849.7948-1-schnelle@linux.ibm.com
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e364e3b5e4cf5d203fd12a75752a146edb245e4a
Author: Aubrey Li <aubrey.li@intel.com>
Date: Wed Sep 8 18:55:45 2021 +0800
ACPI: PRM: Find PRMT table before parsing it
commit 3265cc3ec52e75fc8daf189954cebda27ad26b2e upstream.
Find and verify PRMT before parsing it, which eliminates a
warning on machines without PRMT:
[ 7.197173] ACPI: PRMT not present
Fixes: cefc7ca46235 ("ACPI: PRM: implement OperationRegion handler for the PlatformRtMechanism subtype")
Signed-off-by: Aubrey Li <aubrey.li@linux.intel.com>
Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: 5.14+ <stable@vger.kernel.org> # 5.14+
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5c0d1ef1aa30e58bf2142b334d79e642831b8597
Author: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date: Wed Sep 8 19:27:49 2021 +0900
fbmem: don't allow too huge resolutions
commit 8c28051cdcbe9dfcec6bd0a4709d67a09df6edae upstream.
syzbot is reporting page fault at vga16fb_fillrect() [1], for
vga16fb_check_var() is failing to detect multiplication overflow.
if (vxres * vyres > maxmem) {
vyres = maxmem / vxres;
if (vyres < yres)
return -ENOMEM;
}
Since no module would accept too huge resolutions where multiplication
overflow happens, let's reject in the common path.
Link: https://syzkaller.appspot.com/bug?extid=04168c8063cfdde1db5e [1]
Reported-by: syzbot <syzbot+04168c8063cfdde1db5e@syzkaller.appspotmail.com>
Debugged-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/185175d6-227a-7b55-433d-b070929b262c@i-love.sakura.ne.jp
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 457715b6adedeb92acc1237548e91759bec8cd0c
Author: THOBY Simon <Simon.THOBY@viveris.fr>
Date: Mon Aug 16 08:10:59 2021 +0000
IMA: remove the dependency on CRYPTO_MD5
commit 8510505d55e194d3f6c9644c9f9d12c4f6b0395a upstream.
MD5 is a weak digest algorithm that shouldn't be used for cryptographic
operation. It hinders the efficiency of a patch set that aims to limit
the digests allowed for the extended file attribute namely security.ima.
MD5 is no longer a requirement for IMA, nor should it be used there.
The sole place where we still use the MD5 algorithm inside IMA is setting
the ima_hash algorithm to MD5, if the user supplies 'ima_hash=md5'
parameter on the command line. With commit ab60368ab6a4 ("ima: Fallback
to the builtin hash algorithm"), setting "ima_hash=md5" fails gracefully
when CRYPTO_MD5 is not set:
ima: Can not allocate md5 (reason: -2)
ima: Allocating md5 failed, going to use default hash algorithm sha256
Remove the CRYPTO_MD5 dependency for IMA.
Signed-off-by: THOBY Simon <Simon.THOBY@viveris.fr>
Reviewed-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
[zohar@linux.ibm.com: include commit number in patch description for
stable.]
Cc: stable@vger.kernel.org # 4.17
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 81c1cd0e4c76a85b4596207e540caa69b3a40838
Author: Austin Kim <austin.kim@lge.com>
Date: Tue Jun 29 14:50:50 2021 +0100
IMA: remove -Wmissing-prototypes warning
commit a32ad90426a9c8eb3915eed26e08ce133bd9e0da upstream.
With W=1 build, the compiler throws warning message as below:
security/integrity/ima/ima_mok.c:24:12: warning:
no previous prototype for ‘ima_mok_init’ [-Wmissing-prototypes]
__init int ima_mok_init(void)
Silence the warning by adding static keyword to ima_mok_init().
Signed-off-by: Austin Kim <austin.kim@lge.com>
Fixes: 41c89b64d718 ("IMA: create machine owner and blacklist keyrings")
Cc: stable@vger.kernel.org
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 76784e993feb784791e7783d91982ee4903fa7b9
Author: Miklos Szeredi <mszeredi@redhat.com>
Date: Wed Sep 1 12:39:02 2021 +0200
fuse: wait for writepages in syncfs
commit 660585b56e63ca034ad506ea53c807c5cdca3196 upstream.
In case of fuse the MM subsystem doesn't guarantee that page writeback
completes by the time ->sync_fs() is called. This is because fuse
completes page writeback immediately to prevent DoS of memory reclaim by
the userspace file server.
This means that fuse itself must ensure that writes are synced before
sending the SYNCFS request to the server.
Introduce sync buckets, that hold a counter for the number of outstanding
write requests. On syncfs replace the current bucket with a new one and
wait until the old bucket's counter goes down to zero.
It is possible to have multiple syncfs calls in parallel, in which case
there could be more than one waited-on buckets. Descendant buckets must
not complete until the parent completes. Add a count to the child (new)
bucket until the (parent) old bucket completes.
Use RCU protection to dereference the current bucket and to wake up an
emptied bucket. Use fc->lock to protect against parallel assignments to
the current bucket.
This leaves just the counter to be a possible scalability issue. The
fc->num_waiting counter has a similar issue, so both should be addressed at
the same time.
Reported-by: Amir Goldstein <amir73il@gmail.com>
Fixes: 2d82ab251ef0 ("virtiofs: propagate sync() to file server")
Cc: <stable@vger.kernel.org> # v5.14
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 84378e3a64c18d8b17e8c23efd463525bc0a76fa
Author: Miklos Szeredi <mszeredi@redhat.com>
Date: Tue Aug 31 14:18:08 2021 +0200
fuse: flush extending writes
commit 59bda8ecee2ffc6a602b7bf2b9e43ca669cdbdcd upstream.
Callers of fuse_writeback_range() assume that the file is ready for
modification by the server in the supplied byte range after the call
returns.
If there's a write that extends the file beyond the end of the supplied
range, then the file needs to be extended to at least the end of the range,
but currently that's not done.
There are at least two cases where this can cause problems:
- copy_file_range() will return short count if the file is not extended
up to end of the source range.
- FALLOC_FL_ZERO_RANGE | FALLOC_FL_KEEP_SIZE will not extend the file,
hence the region may not be fully allocated.
Fix by flushing writes from the start of the range up to the end of the
file. This could be optimized if the writes are non-extending, etc, but
it's probably not worth the trouble.
Fixes: a2bc92362941 ("fuse: fix copy_file_range() in the writeback case")
Fixes: 6b1bdb56b17c ("fuse: allow fallocate(FALLOC_FL_ZERO_RANGE)")
Cc: <stable@vger.kernel.org> # v5.2
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e9d6698e54949ebda76973680b185478cbd6b377
Author: Miklos Szeredi <mszeredi@redhat.com>
Date: Tue Aug 17 21:05:16 2021 +0200
fuse: truncate pagecache on atomic_o_trunc
commit 76224355db7570cbe6b6f75c8929a1558828dd55 upstream.
fuse_finish_open() will be called with FUSE_NOWRITE in case of atomic
O_TRUNC. This can deadlock with fuse_wait_on_page_writeback() in
fuse_launder_page() triggered by invalidate_inode_pages2().
Fix by replacing invalidate_inode_pages2() in fuse_finish_open() with a
truncate_pagecache() call. This makes sense regardless of FOPEN_KEEP_CACHE
or fc->writeback cache, so do it unconditionally.
Reported-by: Xie Yongji <xieyongji@bytedance.com>
Reported-and-tested-by: syzbot+bea44a5189836d956894@syzkaller.appspotmail.com
Fixes: e4648309b85a ("fuse: truncate pending writes on O_TRUNC")
Cc: <stable@vger.kernel.org>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2d2c7d860fc7d5e6ef4fa4335302504832837ecd
Author: Adrian Ratiu <adrian.ratiu@collabora.com>
Date: Tue Jul 27 20:13:12 2021 +0300
char: tpm: Kconfig: remove bad i2c cr50 select
commit 847fdae1579f4ee930b01f24a7847b8043bf468c upstream.
This fixes a minor bug which went unnoticed during the initial
driver upstreaming review: TCG_CR50 does not exist in mainline
kernels, so remove it.
Fixes: 3a253caaad11 ("char: tpm: add i2c driver for cr50")
Cc: stable@vger.kernel.org
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Adrian Ratiu <adrian.ratiu@collabora.com>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2539d2c07fb8bc44a9a043b0696d3a027ec4d1df
Author: Xiao Ni <xni@redhat.com>
Date: Wed Aug 18 13:57:48 2021 +0800
md/raid10: Remove unnecessary rcu_dereference in raid10_handle_discard
commit 46d4703b1db4c86ab5acb2331b10df999f005e8e upstream.
We are seeing the following warning in raid10_handle_discard.
[ 695.110751] =============================
[ 695.131439] WARNING: suspicious RCU usage
[ 695.151389] 4.18.0-319.el8.x86_64+debug #1 Not tainted
[ 695.174413] -----------------------------
[ 695.192603] drivers/md/raid10.c:1776 suspicious
rcu_dereference_check() usage!
[ 695.225107] other info that might help us debug this:
[ 695.260940] rcu_scheduler_active = 2, debug_locks = 1
[ 695.290157] no locks held by mkfs.xfs/10186.
In the first loop of function raid10_handle_discard. It already
determines which disk need to handle discard request and add the
rdev reference count rdev->nr_pending. So the conf->mirrors will
not change until all bios come back from underlayer disks. It
doesn't need to use rcu_dereference to get rdev.
Cc: stable@vger.kernel.org
Fixes: d30588b2731f ('md/raid10: improve raid10 discard request')
Signed-off-by: Xiao Ni <xni@redhat.com>
Acked-by: Guoqing Jiang <guoqing.jiang@linux.dev>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4b646423e43b6e49e670ff88ef87fede903b1ac0
Author: Jens Axboe <axboe@kernel.dk>
Date: Sun Aug 29 16:13:03 2021 -0600
io-wq: check max_worker limits if a worker transitions bound state
commit ecc53c48c13d995e6fe5559e30ffee48d92784fd upstream.
For the two places where new workers are created, we diligently check if
we are allowed to create a new worker. If we're currently at the limit
of how many workers of a given type we can have, then we don't create
any new ones.
If you have a mixed workload with various types of bound and unbounded
work, then it can happen that a worker finishes one type of work and
is then transitioned to the other type. For this case, we don't check
if we are actually allowed to do so. This can cause io-wq to temporarily
exceed the allowed number of workers for a given type.
When retrieving work, check that the types match. If they don't, check
if we are allowed to transition to the other type. If not, then don't
handle the new work.
Cc: stable@vger.kernel.org
Reported-by: Johannes Lundberg <johalun0@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a87bb0c99c788577d38c127d9a87d2120901bcfa
Author: Claudiu Beznea <claudiu.beznea@microchip.com>
Date: Tue Jul 27 10:40:05 2021 +0300
ARM: dts: at91: add pinctrl-{names, 0} for all gpios
commit bf781869e5cf3e4ec1a47dad69b6f0df97629cbd upstream.
Add pinctrl-names and pinctrl-0 properties on controllers that claims to
use pins to avoid failures due to
commit 2ab73c6d8323 ("gpio: Support GPIO controllers without pin-ranges")
and also to avoid using pins that may be claimed my other IPs.
Fixes: b7c2b6157079 ("ARM: at91: add Atmel's SAMA5D3 Xplained board")
Fixes: 1e5f532c2737 ("ARM: dts: at91: sam9x60: add device tree for soc and board")
Fixes: 38153a017896 ("ARM: at91/dt: sama5d4: add dts for sama5d4 xplained board")
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20210727074006.1609989-1-claudiu.beznea@microchip.com
Cc: <stable@vger.kernel.org> # v5.7+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d0fbad1db9e55f1406a65b805a7b233b13f56a13
Author: Marc Zyngier <maz@kernel.org>
Date: Thu Aug 19 19:03:05 2021 +0100
KVM: arm64: vgic: Resample HW pending state on deactivation
commit 3134cc8beb69d0db9de651081707c4651c011621 upstream.
When a mapped level interrupt (a timer, for example) is deactivated
by the guest, the corresponding host interrupt is equally deactivated.
However, the fate of the pending state still needs to be dealt
with in SW.
This is specially true when the interrupt was in the active+pending
state in the virtual distributor at the point where the guest
was entered. On exit, the pending state is potentially stale
(the guest may have put the interrupt in a non-pending state).
If we don't do anything, the interrupt will be spuriously injected
in the guest. Although this shouldn't have any ill effect (spurious
interrupts are always possible), we can improve the emulation by
detecting the deactivation-while-pending case and resample the
interrupt.
While we're at it, move the logic into a common helper that can
be shared between the two GIC implementations.
Fixes: e40cc57bac79 ("KVM: arm/arm64: vgic: Support level-triggered mapped interrupts")
Reported-by: Raghavendra Rao Ananta <rananta@google.com>
Tested-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Oliver Upton <oupton@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210819180305.1670525-1-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 03ccb2d2c973e624181297916cdae5f121116bb5
Author: Marc Zyngier <maz@kernel.org>
Date: Mon Aug 2 13:38:30 2021 +0100
KVM: arm64: Unregister HYP sections from kmemleak in protected mode
commit 47e6223c841e029bfc23c3ce594dac5525cebaf8 upstream.
Booting a KVM host in protected mode with kmemleak quickly results
in a pretty bad crash, as kmemleak doesn't know that the HYP sections
have been taken away. This is specially true for the BSS section,
which is part of the kernel BSS section and registered at boot time
by kmemleak itself.
Unregister the HYP part of the BSS before making that section
HYP-private. The rest of the HYP-specific data is obtained via
the page allocator or lives in other sections, none of which is
subjected to kmemleak.
Fixes: 90134ac9cabb ("KVM: arm64: Protect the .hyp sections from the host")
Reviewed-by: Quentin Perret <qperret@google.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org # 5.13
Link: https://lore.kernel.org/r/20210802123830.2195174-3-maz@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ea9407f484c6b3c577b58a73fc2919539a564cab
Author: Sean Christopherson <seanjc@google.com>
Date: Tue Aug 10 07:45:26 2021 -0700
KVM: nVMX: Unconditionally clear nested.pi_pending on nested VM-Enter
commit f7782bb8d818d8f47c26b22079db10599922787a upstream.
Clear nested.pi_pending on nested VM-Enter even if L2 will run without
posted interrupts enabled. If nested.pi_pending is left set from a
previous L2, vmx_complete_nested_posted_interrupt() will pick up the
stale flag and exit to userspace with an "internal emulation error" due
the new L2 not having a valid nested.pi_desc.
Arguably, vmx_complete_nested_posted_interrupt() should first check for
posted interrupts being enabled, but it's also completely reasonable that
KVM wouldn't screw up a fundamental flag. Not to mention that the mere
existence of nested.pi_pending is a long-standing bug as KVM shouldn't
move the posted interrupt out of the IRR until it's actually processed,
e.g. KVM effectively drops an interrupt when it performs a nested VM-Exit
with a "pending" posted interrupt. Fixing the mess is a future problem.
Prior to vmx_complete_nested_posted_interrupt() interpreting a null PI
descriptor as an error, this was a benign bug as the null PI descriptor
effectively served as a check on PI not being enabled. Even then, the
new flow did not become problematic until KVM started checking the result
of kvm_check_nested_events().
Fixes: 705699a13994 ("KVM: nVMX: Enable nested posted interrupt processing")
Fixes: 966eefb89657 ("KVM: nVMX: Disable vmcs02 posted interrupts if vmcs12 PID isn't mappable")
Fixes: 47d3530f86c0 ("KVM: x86: Exit to userspace when kvm_check_nested_events fails")
Cc: stable@vger.kernel.org
Cc: Jim Mattson <jmattson@google.com>
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210810144526.2662272-1-seanjc@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 69303a10f8e23636b3d8b627c85e30b9986d6e52
Author: Maxim Levitsky <mlevitsk@redhat.com>
Date: Thu Aug 26 12:57:49 2021 +0300
KVM: VMX: avoid running vmx_handle_exit_irqoff in case of emulation
commit 81b4b56d4f8130bbb99cf4e2b48082e5b4cfccb9 upstream.
If we are emulating an invalid guest state, we don't have a correct
exit reason, and thus we shouldn't do anything in this function.
Signed-off-by: Maxim Levitsky <mlevitsk@redhat.com>
Message-Id: <20210826095750.1650467-2-mlevitsk@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 95b5a48c4f2b ("KVM: VMX: Handle NMIs, #MCs and async #PFs in common irqs-disabled fn", 2019-06-18)
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f28529f40355d231c131c98d63b3f84b5043e600
Author: Sean Christopherson <seanjc@google.com>
Date: Mon Aug 2 21:46:06 2021 -0700
KVM: x86/mmu: Avoid collision with !PRESENT SPTEs in TDP MMU lpage stats
commit 088acd23526647844aec1c39db4ad02552c86c7b upstream.
Factor in whether or not the old/new SPTEs are shadow-present when
adjusting the large page stats in the TDP MMU. A modified MMIO SPTE can
toggle the page size bit, as bit 7 is used to store the MMIO generation,
i.e. is_large_pte() can get a false positive when called on a MMIO SPTE.
Ditto for nuking SPTEs with REMOVED_SPTE, which sets bit 7 in its magic
value.
Opportunistically move the logic below the check to verify at least one
of the old/new SPTEs is shadow present.
Use is/was_leaf even though is/was_present would suffice. The code
generation is roughly equivalent since all flags need to be computed
prior to the code in question, and using the *_leaf flags will minimize
the diff in a future enhancement to account all pages, i.e. will change
the check to "is_leaf != was_leaf".
Reviewed-by: David Matlack <dmatlack@google.com>
Reviewed-by: Ben Gardon <bgardon@google.com>
Fixes: 1699f65c8b65 ("kvm/x86: Fix 'lpages' kvm stat for TDM MMU")
Cc: stable@vger.kernel.org
Signed-off-by: Sean Christopherson <seanjc@google.com>
Signed-off-by: Mingwei Zhang <mizhang@google.com>
Message-Id: <20210803044607.599629-3-mizhang@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ea570e70e3ea99ed4ecdad4b03a6781af5dd60a0
Author: Paolo Bonzini <pbonzini@redhat.com>
Date: Fri Aug 6 07:05:58 2021 -0400
KVM: x86: clamp host mapping level to max_level in kvm_mmu_max_mapping_level
commit ec607a564f70519b340f7eb4cfc0f4a6b55285ac upstream.
This change started as a way to make kvm_mmu_hugepage_adjust a bit simpler,
but it does fix two bugs as well.
One bug is in zapping collapsible PTEs. If a large page size is
disallowed but not all of them, kvm_mmu_max_mapping_level will return the
host mapping level and the small PTEs will be zapped up to that level.
However, if e.g. 1GB are prohibited, we can still zap 4KB mapping and
preserve the 2MB ones. This can happen for example when NX huge pages
are in use.
The second would happen when userspace backs guest memory
with a 1gb hugepage but only assign a subset of the page to
the guest. 1gb pages would be disallowed by the memslot, but
not 2mb. kvm_mmu_max_mapping_level() would fall through to the
host_pfn_mapping_level() logic, see the 1gb hugepage, and map the whole
thing into the guest.
Fixes: 2f57b7051fe8 ("KVM: x86/mmu: Persist gfn_lpage_is_disallowed() to max_level")
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 150360a6678afafbb1c25ec947bed2e4002baf87
Author: Zelin Deng <zelin.deng@linux.alibaba.com>
Date: Wed Apr 28 10:22:01 2021 +0800
KVM: x86: Update vCPU's hv_clock before back to guest when tsc_offset is adjusted
commit d9130a2dfdd4b21736c91b818f87dbc0ccd1e757 upstream.
When MSR_IA32_TSC_ADJUST is written by guest due to TSC ADJUST feature
especially there's a big tsc warp (like a new vCPU is hot-added into VM
which has been up for a long time), tsc_offset is added by a large value
then go back to guest. This causes system time jump as tsc_timestamp is
not adjusted in the meantime and pvclock monotonic character.
To fix this, just notify kvm to update vCPU's guest time before back to
guest.
Cc: stable@vger.kernel.org
Signed-off-by: Zelin Deng <zelin.deng@linux.alibaba.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Message-Id: <1619576521-81399-2-git-send-email-zelin.deng@linux.alibaba.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f8c655627a1d79c00ee33866bed46de60f1d2bcf
Author: Halil Pasic <pasic@linux.ibm.com>
Date: Fri Aug 27 14:54:29 2021 +0200
KVM: s390: index kvm->arch.idle_mask by vcpu_idx
commit a3e03bc1368c1bc16e19b001fc96dc7430573cc8 upstream.
While in practice vcpu->vcpu_idx == vcpu->vcp_id is often true, it may
not always be, and we must not rely on this. Reason is that KVM decides
the vcpu_idx, userspace decides the vcpu_id, thus the two might not
match.
Currently kvm->arch.idle_mask is indexed by vcpu_id, which implies
that code like
for_each_set_bit(vcpu_id, kvm->arch.idle_mask, online_vcpus) {
vcpu = kvm_get_vcpu(kvm, vcpu_id);
do_stuff(vcpu);
}
is not legit. Reason is that kvm_get_vcpu expects an vcpu_idx, not an
vcpu_id. The trouble is, we do actually use kvm->arch.idle_mask like
this. To fix this problem we have two options. Either use
kvm_get_vcpu_by_id(vcpu_id), which would loop to find the right vcpu_id,
or switch to indexing via vcpu_idx. The latter is preferable for obvious
reasons.
Let us make switch from indexing kvm->arch.idle_mask by vcpu_id to
indexing it by vcpu_idx. To keep gisa_int.kicked_mask indexed by the
same index as idle_mask lets make the same change for it as well.
Fixes: 1ee0bc559dc3 ("KVM: s390: get rid of local_int array")
Signed-off-by: Halil Pasic <pasic@linux.ibm.com>
Reviewed-by: Christian Bornträger <borntraeger@de.ibm.com>
Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: <stable@vger.kernel.org> # 3.15+
Link: https://lore.kernel.org/r/20210827125429.1912577-1-pasic@linux.ibm.com
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9d52658ef6ebd387ad0c32f09061dee32a7cc92b
Author: Sean Christopherson <seanjc@google.com>
Date: Tue Aug 31 09:42:22 2021 -0700
Revert "KVM: x86: mmu: Add guest physical address check in translate_gpa()"
commit e7177339d7b5f9594b316842122b5fda9513d5e2 upstream.
Revert a misguided illegal GPA check when "translating" a non-nested GPA.
The check is woefully incomplete as it does not fill in @exception as
expected by all callers, which leads to KVM attempting to inject a bogus
exception, potentially exposing kernel stack information in the process.
WARNING: CPU: 0 PID: 8469 at arch/x86/kvm/x86.c:525 exception_type+0x98/0xb0 arch/x86/kvm/x86.c:525
CPU: 1 PID: 8469 Comm: syz-executor531 Not tainted 5.14.0-rc7-syzkaller #0
RIP: 0010:exception_type+0x98/0xb0 arch/x86/kvm/x86.c:525
Call Trace:
x86_emulate_instruction+0xef6/0x1460 arch/x86/kvm/x86.c:7853
kvm_mmu_page_fault+0x2f0/0x1810 arch/x86/kvm/mmu/mmu.c:5199
handle_ept_misconfig+0xdf/0x3e0 arch/x86/kvm/vmx/vmx.c:5336
__vmx_handle_exit arch/x86/kvm/vmx/vmx.c:6021 [inline]
vmx_handle_exit+0x336/0x1800 arch/x86/kvm/vmx/vmx.c:6038
vcpu_enter_guest+0x2a1c/0x4430 arch/x86/kvm/x86.c:9712
vcpu_run arch/x86/kvm/x86.c:9779 [inline]
kvm_arch_vcpu_ioctl_run+0x47d/0x1b20 arch/x86/kvm/x86.c:10010
kvm_vcpu_ioctl+0x49e/0xe50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3652
The bug has escaped notice because practically speaking the GPA check is
useless. The GPA check in question only comes into play when KVM is
walking guest page tables (or "translating" CR3), and KVM already handles
illegal GPA checks by setting reserved bits in rsvd_bits_mask for each
PxE, or in the case of CR3 for loading PTDPTRs, manually checks for an
illegal CR3. This particular failure doesn't hit the existing reserved
bits checks because syzbot sets guest.MAXPHYADDR=1, and IA32 architecture
simply doesn't allow for such an absurd MAXPHYADDR, e.g. 32-bit paging
doesn't define any reserved PA bits checks, which KVM emulates by only
incorporating the reserved PA bits into the "high" bits, i.e. bits 63:32.
Simply remove the bogus check. There is zero meaningful value and no
architectural justification for supporting guest.MAXPHYADDR < 32, and
properly filling the exception would introduce non-trivial complexity.
This reverts commit ec7771ab471ba6a945350353617e2e3385d0e013.
Fixes: ec7771ab471b ("KVM: x86: mmu: Add guest physical address check in translate_gpa()")
Cc: stable@vger.kernel.org
Reported-by: syzbot+200c08e88ae818f849ce@syzkaller.appspotmail.com
Signed-off-by: Sean Christopherson <seanjc@google.com>
Message-Id: <20210831164224.1119728-2-seanjc@google.com>
Reviewed-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b26902fdd6127061d5e024ab1d2257c7626b3188
Author: Alexander Antonov <alexander.antonov@linux.intel.com>
Date: Tue Jul 6 12:07:23 2021 +0300
perf/x86/intel/uncore: Fix IIO cleanup mapping procedure for SNR/ICX
commit 3f2cbe3810a60111a33f5f6267bd5a237b826fc9 upstream.
skx_iio_cleanup_mapping() is re-used for snr and icx, but in those
cases it fails to use the appropriate XXX_iio_mapping_group and as
such fails to free previously allocated resources, leading to memory
leaks.
Fixes: 10337e95e04c ("perf/x86/intel/uncore: Enable I/O stacks to IIO PMON mapping on ICX")
Signed-off-by: Alexander Antonov <alexander.antonov@linux.intel.com>
[peterz: Changelog]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Kan Liang <kan.liang@linux.intel.com>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20210706090723.41850-1-alexander.antonov@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 4a7017b3c88231b6fc11c17ec3d63c8c3596e89d
Author: Nguyen Dinh Phi <phind.uet@gmail.com>
Date: Mon Aug 23 08:06:41 2021 +0800
tty: Fix data race between tiocsti() and flush_to_ldisc()
commit bb2853a6a421a052268eee00fd5d3f6b3504b2b1 upstream.
The ops->receive_buf() may be accessed concurrently from these two
functions. If the driver flushes data to the line discipline
receive_buf() method while tiocsti() is waiting for the
ops->receive_buf() to finish its work, the data race will happen.
For example:
tty_ioctl |tty_ldisc_receive_buf
->tioctsi | ->tty_port_default_receive_buf
| ->tty_ldisc_receive_buf
->hci_uart_tty_receive | ->hci_uart_tty_receive
->h4_recv | ->h4_recv
In this case, the h4 receive buffer will be overwritten by the
latecomer, and we will lost the data.
Hence, change tioctsi() function to use the exclusive lock interface
from tty_buffer to avoid the data race.
Reported-by: syzbot+97388eb9d31b997fe1d0@syzkaller.appspotmail.com
Reviewed-by: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
Link: https://lore.kernel.org/r/20210823000641.2082292-1-phind.uet@gmail.com
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2fa92ae9e9be0a3a454c14f5d5525c105b629a65
Author: Steve French <stfrench@microsoft.com>
Date: Mon Aug 23 13:52:12 2021 -0500
smb3: fix posix extensions mount option
commit 7321be2663da5922343cc121f1ff04924cee2e76 upstream.
We were incorrectly initializing the posix extensions in the
conversion to the new mount API.
CC: <stable@vger.kernel.org> # 5.11+
Reported-by: Christian Brauner <christian.brauner@ubuntu.com>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Suggested-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 87f961747d98c09f09246310478f8b3792dd8491
Author: Ronnie Sahlberg <lsahlber@redhat.com>
Date: Wed Aug 25 21:16:56 2021 +1000
cifs: Do not leak EDEADLK to dgetents64 for STATUS_USER_SESSION_DELETED
commit 3998f0b8bc49ec784990971dc1f16bf367b19078 upstream.
RHBZ: 1994393
If we hit a STATUS_USER_SESSION_DELETED for the Create part in the
Create/QueryDirectory compound that starts a directory scan
we will leak EDEADLK back to userspace and surprise glibc and the application.
Pick this up initiate_cifs_search() and retry a small number of tries before we
return an error to userspace.
Cc: stable@vger.kernel.org
Reported-by: Xiaoli Feng <xifeng@redhat.com>
Signed-off-by: Ronnie Sahlberg <lsahlber@redhat.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 17f220a74b51f8fbd878611266720ff95b859a5f
Author: Guoqing Jiang <jiangguoqing@kylinos.cn>
Date: Tue Aug 24 09:16:54 2021 +0800
raid1: ensure write behind bio has less than BIO_MAX_VECS sectors
commit 6607cd319b6b91bff94e90f798a61c031650b514 upstream.
We can't split write behind bio with more than BIO_MAX_VECS sectors,
otherwise the below call trace was triggered because we could allocate
oversized write behind bio later.
[ 8.097936] bvec_alloc+0x90/0xc0
[ 8.098934] bio_alloc_bioset+0x1b3/0x260
[ 8.099959] raid1_make_request+0x9ce/0xc50 [raid1]
[ 8.100988] ? __bio_clone_fast+0xa8/0xe0
[ 8.102008] md_handle_request+0x158/0x1d0 [md_mod]
[ 8.103050] md_submit_bio+0xcd/0x110 [md_mod]
[ 8.104084] submit_bio_noacct+0x139/0x530
[ 8.105127] submit_bio+0x78/0x1d0
[ 8.106163] ext4_io_submit+0x48/0x60 [ext4]
[ 8.107242] ext4_writepages+0x652/0x1170 [ext4]
[ 8.108300] ? do_writepages+0x41/0x100
[ 8.109338] ? __ext4_mark_inode_dirty+0x240/0x240 [ext4]
[ 8.110406] do_writepages+0x41/0x100
[ 8.111450] __filemap_fdatawrite_range+0xc5/0x100
[ 8.112513] file_write_and_wait_range+0x61/0xb0
[ 8.113564] ext4_sync_file+0x73/0x370 [ext4]
[ 8.114607] __x64_sys_fsync+0x33/0x60
[ 8.115635] do_syscall_64+0x33/0x40
[ 8.116670] entry_SYSCALL_64_after_hwframe+0x44/0xae
Thanks for the comment from Christoph.
[1]. https://bugs.archlinux.org/task/70992
Cc: stable@vger.kernel.org # v5.12+
Reported-by: Jens Stutte <jens@chianterastutte.eu>
Tested-by: Jens Stutte <jens@chianterastutte.eu>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Guoqing Jiang <jiangguoqing@kylinos.cn>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f9c88ee8e217e3594ad008126b10dcd6d1575e41
Author: Pavel Begunkov <asml.silence@gmail.com>
Date: Mon Jul 19 11:53:00 2021 +0100
bio: fix page leak bio_add_hw_page failure
commit d9cf3bd531844ffbfe94b16e417037a16efc988d upstream.
__bio_iov_append_get_pages() doesn't put not appended pages on
bio_add_hw_page() failure, so potentially leaking them, fix it. Also, do
the same for __bio_iov_iter_get_pages(), even though it looks like it
can't be triggered by userspace in this case.
Fixes: 0512a75b98f8 ("block: Introduce REQ_OP_ZONE_APPEND")
Cc: stable@vger.kernel.org # 5.8+
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://lore.kernel.org/r/1edfa6a2ffd66d55e6345a477df5387d2c1415d0.1626653825.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 86939a43e0f57bdb505f6faf3b9616003f934d81
Author: Pavel Begunkov <asml.silence@gmail.com>
Date: Thu Sep 9 13:56:27 2021 +0100
io_uring: fail links of cancelled timeouts
commit 2ae2eb9dde18979b40629dd413b9adbd6c894cdf upstream.
When we cancel a timeout we should mark it with REQ_F_FAIL, so
linked requests are cancelled as well, but not queued for further
execution.
Cc: stable@vger.kernel.org
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://lore.kernel.org/r/fff625b44eeced3a5cae79f60e6acf3fbdf8f990.1631192135.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7faeaed2f29a7b61827cdfaa3f9ad8a3608eac54
Author: Jens Axboe <axboe@kernel.dk>
Date: Fri Sep 3 16:55:26 2021 -0600
io_uring: io_uring_complete() trace should take an integer
commit 2fc2a7a62eb58650e71b4550cf6fa6cc0a75b2d2 upstream.
It currently takes a long, and while that's normally OK, the io_uring
limit is an int. Internally in io_uring it's an int, but sometimes it's
passed as a long. That can yield confusing results where a completions
seems to generate a huge result:
ou-sqp-1297-1298 [001] ...1 788.056371: io_uring_complete: ring 000000000e98e046, user_data 0x0, result 4294967171, cflags 0
which is due to -ECANCELED being stored in an unsigned, and then passed
in as a long. Using the right int type, the trace looks correct:
iou-sqp-338-339 [002] ...1 15.633098: io_uring_complete: ring 00000000e0ac60cf, user_data 0x0, result -125, cflags 0
Cc: stable@vger.kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1ae179a0d7151cb17b1176b5e5d9c79a95850923
Author: Jens Axboe <axboe@kernel.dk>
Date: Mon Aug 30 19:37:41 2021 -0600
io_uring: IORING_OP_WRITE needs hash_reg_file set
commit 7b3188e7ed54102a5dcc73d07727f41fb528f7c8 upstream.
During some testing, it became evident that using IORING_OP_WRITE doesn't
hash buffered writes like the other writes commands do. That's simply
an oversight, and can cause performance regressions when doing buffered
writes with this command.
Correct that and add the flag, so that buffered writes are correctly
hashed when using the non-iovec based write command.
Cc: stable@vger.kernel.org
Fixes: 3a6820f2bb8a ("io_uring: add non-vectored read/write commands")
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 917342c3714358991d8ac2bd29bff8f6ea62f077
Author: Pavel Begunkov <asml.silence@gmail.com>
Date: Fri Aug 20 10:36:35 2021 +0100
io_uring: limit fixed table size by RLIMIT_NOFILE
commit 3a1b8a4e843f96b636431450d8d79061605cf74b upstream.
Limit the number of files in io_uring fixed tables by RLIMIT_NOFILE,
that's the first and the simpliest restriction that we should impose.
Cc: stable@vger.kernel.org
Suggested-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Link: https://lore.kernel.org/r/b2756c340aed7d6c0b302c26dab50c6c5907f4ce.1629451684.git.asml.silence@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1b19425f8e2af878840897d09b3d2759b254d04e
Author: Lars Poeschel <poeschel@lemonage.de>
Date: Wed Jul 14 13:02:28 2021 +0200
auxdisplay: hd44780: Fix oops on module unloading
commit 333ff32d54cdefc2e479892e7f15ac91e026b57d upstream.
Fixes: 718e05ed92ec ("auxdisplay: Introduce hd44780_common.[ch]")
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/lkml/CAHp75VfKyqy+vM0XkP9Yb+znGOTVT4zYCRY3A3nQ7C3WNUVN0g@mail.gmail.com/
Reported-By: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Lars Poeschel <poeschel@lemonage.de>
Tested-by: Andy Shevchenko <andy.shevchenko@gmail.com>
[added Link, Fixes, Cc stable tags, edited message]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 528521f72b8f615e0930ba4b07d508ec73b07837
Author: Lukas Hannen <lukas.hannen@opensource.tttech-industrial.com>
Date: Wed Aug 25 10:12:43 2021 +0000
time: Handle negative seconds correctly in timespec64_to_ns()
commit 39ff83f2f6cc5cc1458dfcea9697f96338210beb upstream.
timespec64_ns() prevents multiplication overflows by comparing the seconds
value of the timespec to KTIME_SEC_MAX. If the value is greater or equal it
returns KTIME_MAX.
But that check casts the signed seconds value to unsigned which makes the
comparision true for all negative values and therefore return wrongly
KTIME_MAX.
Negative second values are perfectly valid and required in some places,
e.g. ptp_clock_adjtime().
Remove the cast and add a check for the negative boundary which is required
to prevent undefined behaviour due to multiplication underflow.
Fixes: cb47755725da ("time: Prevent undefined behaviour in timespec64_to_ns()")'
Signed-off-by: Lukas Hannen <lukas.hannen@opensource.tttech-industrial.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/AM6PR01MB541637BD6F336B8FFB72AF80EEC69@AM6PR01MB5416.eurprd01.prod.exchangelabs.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 889008de3ea2b84aaa9bf354d55fe2d032b60167
Author: Jaegeuk Kim <jaegeuk@kernel.org>
Date: Thu Aug 19 14:00:57 2021 -0700
f2fs: guarantee to write dirty data when enabling checkpoint back
commit dddd3d65293a52c2c3850c19b1e5115712e534d8 upstream.
We must flush all the dirty data when enabling checkpoint back. Let's guarantee
that first by adding a retry logic on sync_inodes_sb(). In addition to that,
this patch adds to flush data in fsync when checkpoint is disabled, which can
mitigate the sync_inodes_sb() failures in advance.
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 307726060e64273627b6a77020eb479ba420f1b1
Author: Justin M. Forbes <jforbes@fedoraproject.org>
Date: Fri Jul 2 17:31:53 2021 -0500
iwlwifi Add support for ax201 in Samsung Galaxy Book Flex2 Alpha
commit 2f32c147a3816d789722c0bd242a9431332ec3ed upstream.
The Samsung Galaxy Book Flex2 Alpha uses an ax201 with the ID a0f0/6074.
This works fine with the existing driver once it knows to claim it.
Simple patch to add the device.
Signed-off-by: Justin M. Forbes <jforbes@fedoraproject.org>
Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210702223155.1981510-1-jforbes@fedoraproject.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1ede75c4f5bd11569e79382630882a4f27634d47
Author: Douglas Anderson <dianders@chromium.org>
Date: Fri Aug 13 07:34:05 2021 -0700
ASoC: rt5682: Remove unused variable in rt5682_i2c_remove()
commit a1ea05723c27a6f77894a60038a7b2b12fcec9a7 upstream.
In commit 772d44526e20 ("ASoC: rt5682: Properly turn off regulators if
wrong device ID") I deleted code but forgot to delete a variable
that's now unused. Delete it.
Fixes: 772d44526e20 ("ASoC: rt5682: Properly turn off regulators if wrong device ID")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210813073402.1.Iaa9425cfab80f5233afa78b32d02b6dc23256eb3@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 808b4c3ca23d9fe85d7e1a3134d21eabfb45431b
Author: Eric Dumazet <edumazet@google.com>
Date: Mon Aug 30 19:02:10 2021 -0700
ipv4: fix endianness issue in inet_rtm_getroute_build_skb()
[ Upstream commit 92548b0ee220e000d81c27ac9a80e0ede895a881 ]
The UDP length field should be in network order.
This removes the following sparse error:
net/ipv4/route.c:3173:27: warning: incorrect type in assignment (different base types)
net/ipv4/route.c:3173:27: expected restricted __be16 [usertype] len
net/ipv4/route.c:3173:27: got unsigned long
Fixes: 404eb77ea766 ("ipv4: support sport, dport and ip_proto in RTM_GETROUTE")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Roopa Prabhu <roopa@nvidia.com>
Cc: David Ahern <dsahern@kernel.org>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f996358d94d529376bd1ea6bada78c274088a016
Author: Sunil Goutham <sgoutham@marvell.com>
Date: Mon Aug 30 23:30:46 2021 +0530
octeontx2-af: Set proper errorcode for IPv4 checksum errors
[ Upstream commit 1e4428b6dba9b683dc2ec0a56ed7879de3200cce ]
With current config, for packets with IPv4 checksum errors,
errorcode is being set to UNKNOWN. Hence added a separate
errorcodes for outer and inner IPv4 checksum and changed
NPC configuration accordingly.
Also turn on L2 multicast address check in NPC protocol check block.
Fixes: 6b3321bacc5a ("octeontx2-af: Enable packet length and csum validation")
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 934bf63ce4b570384aa3b4f034815795f6da6a42
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date: Mon Aug 30 23:30:45 2021 +0530
octeontx2-af: Fix static code analyzer reported issues
[ Upstream commit 698a82ebfb4b2f2014baf31b7324b328a2a6366e ]
This patch fixes the static code analyzer reported issues
in rvu_npc.c. The reported errors are different sizes of
operands in bitops and returning uninitialized values.
Fixes: 651cd2652339 ("octeontx2-af: MCAM entry installation support")
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a991d7f1d52b2859da95b3102c3f853b83e5ca2e
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date: Mon Aug 30 23:30:44 2021 +0530
octeontx2-af: Fix mailbox errors in nix_rss_flowkey_cfg
[ Upstream commit f2e4568ec95166605c77577953b2787c7f909978 ]
In npc_update_vf_flow_entry function the loop cursor
'index' is being changed inside the loop causing
the loop to spin forever. This in turn hogs the kworker
thread forever and no other mbox message is processed
by AF driver after that. Fix this by using
another variable in the loop.
Fixes: 55307fcb9258 ("octeontx2-af: Add mbox messages to install and delete MCAM rules")
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1fc7fd26a6285032b9a7502854b3f176d6b9edf2
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date: Mon Aug 30 23:30:43 2021 +0530
octeontx2-af: Fix loop in free and unmap counter
[ Upstream commit 6537e96d743b89294b397b4865c6c061abae31b0 ]
When the given counter does not belong to the entry
then code ends up in infinite loop because the loop
cursor, entry is not getting updated further. This
patch fixes that by updating entry for every iteration.
Fixes: a958dd59f9ce ("octeontx2-af: Map or unmap NPC MCAM entry and counter")
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit edc029f2e0d2296f2224ffd81c2c622ccecc1be9
Author: Stefan Wahren <stefan.wahren@i2se.com>
Date: Sat Aug 28 16:23:15 2021 +0200
net: qualcomm: fix QCA7000 checksum handling
[ Upstream commit 429205da6c834447a57279af128bdd56ccd5225e ]
Based on tests the QCA7000 doesn't support checksum offloading. So assume
ip_summed is CHECKSUM_NONE and let the kernel take care of the checksum
handling. This fixes data transfer issues in noisy environments.
Reported-by: Michael Heimpold <michael.heimpold@in-tech.com>
Fixes: 291ab06ecf67 ("net: qualcomm: new Ethernet over SPI driver for QCA7000")
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8ea4229e9cc6f607b5c42843f5749d1cdf04aaa8
Author: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Date: Sun Aug 29 23:58:01 2021 +0800
net: sched: Fix qdisc_rate_table refcount leak when get tcf_block failed
[ Upstream commit c66070125837900163b81a03063ddd657a7e9bfb ]
The reference counting issue happens in one exception handling path of
cbq_change_class(). When failing to get tcf_block, the function forgets
to decrease the refcount of "rtab" increased by qdisc_put_rtab(),
causing a refcount leak.
Fix this issue by jumping to "failure" label when get tcf_block failed.
Fixes: 6529eaba33f0 ("net: sched: introduce tcf block infractructure")
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Reviewed-by: Cong Wang <cong.wang@bytedance.com>
Link: https://lore.kernel.org/r/1630252681-71588-1-git-send-email-xiyuyang19@fudan.edu.cn
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3b9cd2a38308467f6613f8ae6a7c2c7a9f9eea9b
Author: Maxim Mikityanskiy <maximmi@nvidia.com>
Date: Thu Aug 26 14:54:25 2021 +0300
sch_htb: Fix inconsistency when leaf qdisc creation fails
[ Upstream commit ca49bfd90a9dde175d2929dc1544b54841e33804 ]
In HTB offload mode, qdiscs of leaf classes are grafted to netdev
queues. sch_htb expects the dev_queue field of these qdiscs to point to
the corresponding queues. However, qdisc creation may fail, and in that
case noop_qdisc is used instead. Its dev_queue doesn't point to the
right queue, so sch_htb can lose track of used netdev queues, which will
cause internal inconsistencies.
This commit fixes this bug by keeping track of the netdev queue inside
struct htb_class. All reads of cl->leaf.q->dev_queue are replaced by the
new field, the two values are synced on writes, and WARNs are added to
assert equality of the two values.
The driver API has changed: when TC_HTB_LEAF_DEL needs to move a queue,
the driver used to pass the old and new queue IDs to sch_htb. Now that
there is a new field (offload_queue) in struct htb_class that needs to
be updated on this operation, the driver will pass the old class ID to
sch_htb instead (it already knows the new class ID).
Fixes: d03b195b5aa0 ("sch_htb: Hierarchical QoS hardware offload")
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://lore.kernel.org/r/20210826115425.1744053-1-maximmi@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3f38cc1ba1e289306f52cb7238406f38ecbfa21a
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon Aug 30 11:37:17 2021 +0300
net: qrtr: make checks in qrtr_endpoint_post() stricter
[ Upstream commit aaa8e4922c887ff47ad66ef918193682bccc1905 ]
These checks are still not strict enough. The main problem is that if
"cb->type == QRTR_TYPE_NEW_SERVER" is true then "len - hdrlen" is
guaranteed to be 4 but we need to be at least 16 bytes. In fact, we
can reject everything smaller than sizeof(*pkt) which is 20 bytes.
Also I don't like the ALIGN(size, 4). It's better to just insist that
data is needs to be aligned at the start.
Fixes: 0baa99ee353c ("net: qrtr: Allow non-immediate node routing")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4589a12dcf80af31137ef202be1ff4a321707a73
Author: Eric Dumazet <edumazet@google.com>
Date: Sun Aug 29 15:16:15 2021 -0700
ipv4: make exception cache less predictible
[ Upstream commit 67d6d681e15b578c1725bad8ad079e05d1c48a8e ]
Even after commit 6457378fe796 ("ipv4: use siphash instead of Jenkins in
fnhe_hashfun()"), an attacker can still use brute force to learn
some secrets from a victim linux host.
One way to defeat these attacks is to make the max depth of the hash
table bucket a random value.
Before this patch, each bucket of the hash table used to store exceptions
could contain 6 items under attack.
After the patch, each bucket would contains a random number of items,
between 6 and 10. The attacker can no longer infer secrets.
This is slightly increasing memory size used by the hash table,
by 50% in average, we do not expect this to be a problem.
This patch is more complex than the prior one (IPv6 equivalent),
because IPv4 was reusing the oldest entry.
Since we need to be able to evict more than one entry per
update_or_create_fnhe() call, I had to replace
fnhe_oldest() with fnhe_remove_oldest().
Also note that we will queue extra kfree_rcu() calls under stress,
which hopefully wont be a too big issue.
Fixes: 4895c771c7f0 ("ipv4: Add FIB nexthop exceptions.")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Keyu Man <kman001@ucr.edu>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: David S. Miller <davem@davemloft.net>
Reviewed-by: David Ahern <dsahern@kernel.org>
Tested-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 55938482a1461a35087c6f3051f8447662889ea8
Author: Eric Dumazet <edumazet@google.com>
Date: Sun Aug 29 15:16:14 2021 -0700
ipv6: make exception cache less predictible
[ Upstream commit a00df2caffed3883c341d5685f830434312e4a43 ]
Even after commit 4785305c05b2 ("ipv6: use siphash in rt6_exception_hash()"),
an attacker can still use brute force to learn some secrets from a victim
linux host.
One way to defeat these attacks is to make the max depth of the hash
table bucket a random value.
Before this patch, each bucket of the hash table used to store exceptions
could contain 6 items under attack.
After the patch, each bucket would contains a random number of items,
between 6 and 10. The attacker can no longer infer secrets.
This is slightly increasing memory size used by the hash table,
we do not expect this to be a problem.
Following patch is dealing with the same issue in IPv4.
Fixes: 35732d01fe31 ("ipv6: introduce a hash table to store dst cache")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Keyu Man <kman001@ucr.edu>
Cc: Wei Wang <weiwan@google.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f0ab781abc3d403c92385832c921f19b9ffa98e5
Author: Ahmad Fatoum <a.fatoum@pengutronix.de>
Date: Tue Aug 17 08:35:22 2021 +0200
brcmfmac: pcie: fix oops on failure to resume and reprobe
[ Upstream commit d745ca4f2c4ae9f1bd8cf7d8ac6e22d739bffd19 ]
When resuming from suspend, brcmf_pcie_pm_leave_D3 will first attempt a
hot resume and then fall back to removing the PCI device and then
reprobing. If this probe fails, the kernel will oops, because brcmf_err,
which is called to report the failure will dereference the stale bus
pointer. Open code and use the default bus-less brcmf_err to avoid this.
Fixes: 8602e62441ab ("brcmfmac: pass bus to the __brcmf_err() in pcie.c")
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210817063521.22450-1-a.fatoum@pengutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6bca1333130d94490bed930d1f212a23338e5904
Author: Zenghui Yu <yuzenghui@huawei.com>
Date: Tue Jul 27 10:52:31 2021 +0800
bcma: Fix memory leak for internally-handled cores
[ Upstream commit b63aed3ff195130fef12e0af590f4838cf0201d8 ]
kmemleak reported that dev_name() of internally-handled cores were leaked
on driver unbinding. Let's use device_initialize() to take refcounts for
them and put_device() to properly free the related stuff.
While looking at it, there's another potential issue for those which should
be *registered* into driver core. If device_register() failed, we put
device once and freed bcma_device structures. In bcma_unregister_cores(),
they're treated as unregistered and we hit both UAF and double-free. That
smells not good and has also been fixed now.
Fixes: ab54bc8460b5 ("bcma: fill core details for every device")
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210727025232.663-2-yuzenghui@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 351956183ab86cbda5dbe85d4f8ffe60ae8ba21c
Author: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Date: Fri Aug 27 04:52:25 2021 -0700
atlantic: Fix driver resume flow.
[ Upstream commit 57f780f1c43362b86fd23d20bd940e2468237716 ]
Driver crashes when restoring from the Hibernate. In the resume flow,
driver need to clean up the older nic/vec objects and re-initialize them.
Fixes: 8aaa112a57c1d ("net: atlantic: refactoring pm logic")
Signed-off-by: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Signed-off-by: Igor Russkikh <irusskikh@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 47ccf5d4fe23ad169b7e54ef0acd7b3b7117e85a
Author: Takashi Iwai <tiwai@suse.de>
Date: Sun Aug 29 09:38:30 2021 +0200
ALSA: usb-audio: Add lowlatency module option
[ Upstream commit 4801bee7d5a36c199b734a28cde5259183aff822 ]
For making user to switch back to the old playback mode, this patch
adds a new module option 'lowlatency' to snd-usb-audio driver.
When user face a regression due to the recent low-latency playback
support, they can test easily by passing lowlatency=0 option without
rebuilding the kernel.
Fixes: 307cc9baac5c ("ALSA: usb-audio: Reduce latency at playback start, take#2")
Link: https://lore.kernel.org/r/20210829073830.22686-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1559dd2bef662a6704b34bad3bdf4c7252219750
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri Aug 13 14:34:38 2021 +0300
ath6kl: wmi: fix an error code in ath6kl_wmi_sync_point()
[ Upstream commit fd6729ec534cffbbeb3917761e6d1fe6a412d3fe ]
This error path is unlikely because of it checked for NULL and
returned -ENOMEM earlier in the function. But it should return
an error code here as well if we ever do hit it because of a
race condition or something.
Fixes: bdcd81707973 ("Add ath6kl cleaned up driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210813113438.GB30697@kili
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c5fa6437b81ef5c8a615c362404beae63fc97657
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri Aug 27 15:25:41 2021 +0200
net: phy: marvell10g: fix broken PHY interrupts for anyone after us in the driver probe list
[ Upstream commit 0d55649d2ad7296acfda9127e1d05518d025734a ]
Enabling interrupts via device tree for the internal PHYs on the
mv88e6390 DSA switch does not work. The driver insists to use poll mode.
Stage one debugging shows that the fwnode_mdiobus_phy_device_register
function calls fwnode_irq_get properly, and phy->irq is set to a valid
interrupt line initially.
But it is then cleared.
Stage two debugging shows that it is cleared here:
phy_probe:
/* Disable the interrupt if the PHY doesn't support it
* but the interrupt is still a valid one
*/
if (!phy_drv_supports_irq(phydrv) && phy_interrupt_is_valid(phydev))
phydev->irq = PHY_POLL;
Okay, so does the "Marvell 88E6390 Family" PHY driver not have the
.config_intr and .handle_interrupt function pointers? Yes it does.
Stage three debugging shows that the PHY device does not attempt a probe
against the "Marvell 88E6390 Family" driver, but against the "mv88x3310"
driver.
Okay, so why does the "mv88x3310" driver match on a mv88x6390 internal
PHY? The PHY IDs (MARVELL_PHY_ID_88E6390_FAMILY vs
MARVELL_PHY_ID_88X3310) are way different.
Stage four debugging has us looking through:
phy_device_register
-> device_add
-> bus_probe_device
-> device_initial_probe
-> __device_attach
-> bus_for_each_drv
-> driver_match_device
-> drv->bus->match
-> phy_bus_match
Okay, so as we said, the MII_PHYSID1 of mv88e6390 does not match the
mv88x3310 driver's PHY mask & ID, so why would phy_bus_match return...
Ahh, phy_bus_match calls a shortcircuit method,
phydrv->match_phy_device, and does not even bother to compare the PHY ID
if that is implemented.
So of course, we go inside the marvell10g.c driver and sure enough, it
implements .match_phy_device and does not bother to check the PHY ID.
What's interesting though is that at the end of the device_add() from
phy_device_register(), the driver for the internal PHYs _is_ the proper
"Marvell 88E6390 Family". This is because "mv88x3310" ends up failing to
probe after all, and __device_attach_driver(), to quote:
/*
* Ignore errors returned by ->probe so that the next driver can try
* its luck.
*/
The next (and only other) driver that matches is the 6390 driver. For
this one, phy_probe doesn't fail, and everything expects to work as
normal, EXCEPT phydev->irq has already been cleared by the previous
unsuccessful probe of a driver which did not implement PHY interrupts,
and therefore cleared that IRQ.
Okay, so it is not just Marvell 6390 that has PHY interrupts broken.
Stuff like Atheros, Aquantia, Broadcom, Qualcomm work because they are
lexicographically before Marvell, and stuff like NXP, Realtek, Vitesse
are broken.
This goes to show how fragile it is to reset phydev->irq = PHY_POLL from
the actual beginning of phy_probe itself. That seems like an actual bug
of its own too, since phy_probe has side effects which are not restored
on probe failure, but the line of thought probably was, the same driver
will attempt probe again, so it doesn't matter. Well, looks like it
does.
Maybe it would make more sense to move the phydev->irq clearing after
the actual device_add() in phy_device_register() completes, and the
bound driver is the actual final one.
(also, a bit frightening that drivers are permitted to bypass the MDIO
bus matching in such a trivial way and perform PHY reads and writes from
the .match_phy_device method, on devices that do not even belong to
them. In the general case it might not be guaranteed that the MDIO
accesses one driver needs to make to figure out whether to match on a
device is safe for all other PHY devices)
Fixes: a5de4be0aaaa ("net: phy: marvell10g: fix differentiation of 88X3310 from 88X3340")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Tested-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Marek Behún <kabel@kernel.org>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/20210827132541.28953-1-kabel@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 229d09ac89198ae8473fc4e8cf937ef3b33fef2f
Author: Brett Creeley <brett.creeley@intel.com>
Date: Tue Aug 24 12:27:53 2021 -0700
ice: Only lock to update netdev dev_addr
[ Upstream commit b357d9717be7f95fde2c6c4650b186a995b71e59 ]
commit 3ba7f53f8bf1 ("ice: don't remove netdev->dev_addr from uc sync
list") introduced calls to netif_addr_lock_bh() and
netif_addr_unlock_bh() in the driver's ndo_set_mac() callback. This is
fine since the driver is updated the netdev's dev_addr, but since this
is a spinlock, the driver cannot sleep when the lock is held.
Unfortunately the functions to add/delete MAC filters depend on a mutex.
This was causing a trace with the lock debug kernel config options
enabled when changing the mac address via iproute.
[ 203.273059] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:281
[ 203.273065] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 6698, name: ip
[ 203.273068] Preemption disabled at:
[ 203.273068] [<ffffffffc04aaeab>] ice_set_mac_address+0x8b/0x1c0 [ice]
[ 203.273097] CPU: 31 PID: 6698 Comm: ip Tainted: G S W I 5.14.0-rc4 #2
[ 203.273100] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
[ 203.273102] Call Trace:
[ 203.273107] dump_stack_lvl+0x33/0x42
[ 203.273113] ? ice_set_mac_address+0x8b/0x1c0 [ice]
[ 203.273124] ___might_sleep.cold.150+0xda/0xea
[ 203.273131] mutex_lock+0x1c/0x40
[ 203.273136] ice_remove_mac+0xe3/0x180 [ice]
[ 203.273155] ? ice_fltr_add_mac_list+0x20/0x20 [ice]
[ 203.273175] ice_fltr_prepare_mac+0x43/0xa0 [ice]
[ 203.273194] ice_set_mac_address+0xab/0x1c0 [ice]
[ 203.273206] dev_set_mac_address+0xb8/0x120
[ 203.273210] dev_set_mac_address_user+0x2c/0x50
[ 203.273212] do_setlink+0x1dd/0x10e0
[ 203.273217] ? __nla_validate_parse+0x12d/0x1a0
[ 203.273221] __rtnl_newlink+0x530/0x910
[ 203.273224] ? __kmalloc_node_track_caller+0x17f/0x380
[ 203.273230] ? preempt_count_add+0x68/0xa0
[ 203.273236] ? _raw_spin_lock_irqsave+0x1f/0x30
[ 203.273241] ? kmem_cache_alloc_trace+0x4d/0x440
[ 203.273244] rtnl_newlink+0x43/0x60
[ 203.273245] rtnetlink_rcv_msg+0x13a/0x380
[ 203.273248] ? rtnl_calcit.isra.40+0x130/0x130
[ 203.273250] netlink_rcv_skb+0x4e/0x100
[ 203.273256] netlink_unicast+0x1a2/0x280
[ 203.273258] netlink_sendmsg+0x242/0x490
[ 203.273260] sock_sendmsg+0x58/0x60
[ 203.273263] ____sys_sendmsg+0x1ef/0x260
[ 203.273265] ? copy_msghdr_from_user+0x5c/0x90
[ 203.273268] ? ____sys_recvmsg+0xe6/0x170
[ 203.273270] ___sys_sendmsg+0x7c/0xc0
[ 203.273272] ? copy_msghdr_from_user+0x5c/0x90
[ 203.273274] ? ___sys_recvmsg+0x89/0xc0
[ 203.273276] ? __netlink_sendskb+0x50/0x50
[ 203.273278] ? mod_objcg_state+0xee/0x310
[ 203.273282] ? __dentry_kill+0x114/0x170
[ 203.273286] ? get_max_files+0x10/0x10
[ 203.273288] __sys_sendmsg+0x57/0xa0
[ 203.273290] do_syscall_64+0x37/0x80
[ 203.273295] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 203.273296] RIP: 0033:0x7f8edf96e278
[ 203.273298] Code: 89 02 48 c7 c0 ff ff ff ff eb b5 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 25 63 2c 00 8b 00 85 c0 75 17 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 41 89 d4 55
[ 203.273300] RSP: 002b:00007ffcb8bdac08 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[ 203.273303] RAX: ffffffffffffffda RBX: 000000006115e0ae RCX: 00007f8edf96e278
[ 203.273304] RDX: 0000000000000000 RSI: 00007ffcb8bdac70 RDI: 0000000000000003
[ 203.273305] RBP: 0000000000000000 R08: 0000000000000001 R09: 00007ffcb8bda5b0
[ 203.273306] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
[ 203.273306] R13: 0000555e10092020 R14: 0000000000000000 R15: 0000000000000005
Fix this by only locking when changing the netdev->dev_addr. Also, make
sure to restore the old netdev->dev_addr on any failures.
Fixes: 3ba7f53f8bf1 ("ice: don't remove netdev->dev_addr from uc sync list")
Signed-off-by: Brett Creeley <brett.creeley@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6320503b6763b855701579f88d1abe1bde983bbc
Author: Jacob Keller <jacob.e.keller@intel.com>
Date: Mon Aug 23 17:01:49 2021 -0700
ice: restart periodic outputs around time changes
[ Upstream commit 9ee313433c483e4a6ecd517c38c0f8aee1962c53 ]
When we enabled auxiliary input/output support for the E810 device, we
forgot to add logic to restart the output when we change time. This is
important as the periodic output will be incorrect after a time change
otherwise.
This unfortunately includes the adjust time function, even though it
uses an atomic hardware interface. The atomic adjustment can still cause
the pin output to stall permanently, so we need to stop and restart it.
Introduce wrapper functions to temporarily disable and then re-enable
the clock outputs.
Fixes: 172db5f91d5f ("ice: add support for auxiliary input/output pins")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Sunitha D Mekala <sunithax.d.mekala@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 46720ac66c21bf85e08823664b7b314b85e43f26
Author: Jacob Keller <jacob.e.keller@intel.com>
Date: Mon Aug 23 17:01:48 2021 -0700
ice: add lock around Tx timestamp tracker flush
[ Upstream commit 4dd0d5c33c3ebf24a07cae6141648aeb7ba56072 ]
The driver didn't take the lock while flushing the Tx tracker, which
could cause a race where one thread is trying to read timestamps out
while another thread is trying to read the tracker to check the
timestamps.
Avoid this by ensuring that flushing is locked against read accesses.
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c0e94a8dfc0decd02315b305c68eee2b2db291f2
Author: Jacob Keller <jacob.e.keller@intel.com>
Date: Mon Aug 23 17:01:46 2021 -0700
ice: fix Tx queue iteration for Tx timestamp enablement
[ Upstream commit 84c5fb8c4264ec12ef9d21905c562d2297a0234e ]
The driver accidentally copied the ice_for_each_rxq iterator when
implementing enablement of the ptp_tx bit for the Tx rings. We still
load the Tx rings and set the ptp_tx field, but we iterate over the
count of the num_rxq.
If the number of Tx and Rx queues differ, this could either cause
a buffer overrun when accessing the tx_rings list if num_txq is greater
than num_rxq, or it could cause us to fail to enable Tx timestamps for
some rings.
This was not noticed originally as we generally have the same number of
Tx and Rx queues.
Fixes: ea9b847cda64 ("ice: enable transmit timestamps for E810 devices")
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit fafe6489218672a4d420110160ec3fb00dcdcbe4
Author: Mihai Carabas <mihai.carabas@oracle.com>
Date: Thu Aug 19 18:12:26 2021 +0300
misc/pvpanic: fix set driver data
[ Upstream commit a99009bc4f2f0b46e6c553704fda0b67e04395f5 ]
Add again dev_set_drvdata(), but this time in devm_pvpanic_probe(), in order
for dev_get_drvdata() to not return NULL.
Fixes: 394febc9d0a6 ("misc/pvpanic: Make 'pvpanic_probe()' resource managed")
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Mihai Carabas <mihai.carabas@oracle.com>
Link: https://lore.kernel.org/r/1629385946-4584-2-git-send-email-mihai.carabas@oracle.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7778fe1a6a6c069a460e4e3ff8ed3722392a4b5b
Author: Dmytro Linkin <dlinkin@nvidia.com>
Date: Thu Jun 24 13:37:36 2021 +0300
net/mlx5e: Use correct eswitch for stack devices with lag
[ Upstream commit f9d196bd632b8b79261ec3366c30ec3923ea9a02 ]
If link aggregation is used within stack devices driver rejects encap
rules if PF of the VF tunnel device is down. This happens because route
resolved for other PF and its eswitch instance is used to determine
correct vport.
To fix that use devcom feature to retrieve other eswitch instance if
failed to find vport for the 1st eswitch and LAG is active.
Fixes: 10742efc20a4 ("net/mlx5e: VF tunnel TX traffic offloading")
Signed-off-by: Dmytro Linkin <dlinkin@nvidia.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 01c090847ec1e96e029e0b26c20f0886698c540c
Author: Maor Dickman <maord@nvidia.com>
Date: Thu Aug 12 14:30:39 2021 +0300
net/mlx5: E-Switch, Set vhca id valid flag when creating indir fwd group
[ Upstream commit ca6891f9b27db7764bba0798202b0a21d0dc909c ]
When indirect forward group is created, flow is added with vhca id but
without setting vhca id valid flag which violates the PRM.
Fix by setting the missing flag, vhca id valid.
Fixes: 34ca65352ddf ("net/mlx5: E-Switch, Indirect table infrastructure")
Signed-off-by: Maor Dickman <maord@nvidia.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4e2db33107a40ffc7e10500c7768df954cad09cb
Author: Roi Dayan <roid@nvidia.com>
Date: Sun Aug 22 10:14:58 2021 +0300
net/mlx5e: Fix possible use-after-free deleting fdb rule
[ Upstream commit 9a5f9cc794e17cf6ed2a5bb215d2e8b6832db444 ]
After neigh-update-add failure we are still with a slow path rule but
the driver always assume the rule is an fdb rule.
Fix neigh-update-del by checking slow path tc flag on the flow.
Also fix neigh-update-add for when neigh-update-del fails the same.
Fixes: 5dbe906ff1d5 ("net/mlx5e: Use a slow path rule instead if vxlan neighbour isn't available")
Signed-off-by: Roi Dayan <roid@nvidia.com>
Reviewed-by: Paul Blakey <paulb@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d0cb888bfb391a81ef9e9d34461db08816da4079
Author: Leon Romanovsky <leon@kernel.org>
Date: Sat Aug 21 15:05:11 2021 +0300
net/mlx5: Remove all auxiliary devices at the unregister event
[ Upstream commit 8e7e2e8ed0e251138926838b7933f8eb6dd56b12 ]
The call to mlx5_unregister_device() means that mlx5_core driver is
removed. In such scenario, we need to disregard all other flags like
attach/detach and forcibly remove all auxiliary devices.
Fixes: a5ae8fc9058e ("net/mlx5e: Don't create devices during unload flow")
Tested-and-Reported-by: Yicong Yang <yangyicong@hisilicon.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3f55a410b2327dd0a709e08729ffd963a5b78dd7
Author: Dima Chumak <dchumak@nvidia.com>
Date: Wed Jun 30 14:56:32 2021 +0300
net/mlx5: Lag, fix multipath lag activation
[ Upstream commit 2f8b6161cca5fb34b0065e2eac8bb2b61b7bfe87 ]
When handling FIB_EVENT_ENTRY_REPLACE event for a new multipath route,
lag activation can be missed if a stale (struct lag_mp)->mfi pointer
exists, which was associated with an older multipath route that had been
removed.
Normally, when a route is removed, it triggers mlx5_lag_fib_event(),
which handles FIB_EVENT_ENTRY_DEL and clears mfi pointer. But, if
mlx5_lag_check_prereq() condition isn't met, for example when eswitch is
in legacy mode, the fib event is skipped and mfi pointer becomes stale.
Fix by resetting mfi pointer to NULL in mlx5_deactivate_lag().
Fixes: 8a66e4585979 ("net/mlx5: Change ownership model for lag")
Signed-off-by: Dima Chumak <dchumak@nvidia.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f615082ad3195a20c9b019416303910c86b3cd10
Author: Abhishek Naik <abhishek.naik@intel.com>
Date: Thu Aug 5 14:21:53 2021 +0300
iwlwifi: skip first element in the WTAS ACPI table
[ Upstream commit 19426d54302e199b3fd2d575f926a13af66be2b9 ]
By mistake we were considering the first element of the WTAS wifi
package as part of the data we want to rid, but that element is the wifi
package signature (always 0x07), so it should be skipped.
Change the code to read the data starting from element 1 instead.
Signed-off-by: Abhishek Naik <abhishek.naik@intel.com>
Fixes: 28dd7ccdc56f ("iwlwifi: acpi: read TAS table from ACPI and send it to the FW")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20210805141826.ff8148197b15.I70636c04e37b2b57a5df3ce611511f62203d27a7@changeid
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b2a70f9a2d58bc3149a638968499a00820cef8d3
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Mon Aug 16 07:25:28 2021 +0200
ASoC: wcd9335: Disable irq on slave ports in the remove function
[ Upstream commit d3efd26af2e044ff2b48d38bb871630282d77e60 ]
The probe calls 'wcd9335_setup_irqs()' to enable interrupts on all slave
ports.
This must be undone in the remove function.
Add a 'wcd9335_teardown_irqs()' function that undoes 'wcd9335_setup_irqs()'
function, and call it from the remove function.
Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Message-Id: <8f761244d79bd4c098af8a482be9121d3a486d1b.1629091028.git.christophe.jaillet@wanadoo.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 27759b8ac582624c4adcea27730fa26852f4d22b
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Mon Aug 16 07:25:20 2021 +0200
ASoC: wcd9335: Fix a memory leak in the error handling path of the probe function
[ Upstream commit fc6fc81caa63900cef9ebb8b2e365c3ed5a9effb ]
If 'wcd9335_setup_irqs()' fails, me must release the memory allocated in
'wcd_clsh_ctrl_alloc()', as already done in the remove function.
Add an error handling path and the missing 'wcd_clsh_ctrl_free()' call.
Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Message-Id: <6dc12372f09fabb70bf05941dbe6a1382dc93e43.1629091028.git.christophe.jaillet@wanadoo.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e502c911d005a4ddb69dd73dcd41b3f19d54d101
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Mon Aug 16 07:25:10 2021 +0200
ASoC: wcd9335: Fix a double irq free in the remove function
[ Upstream commit 7a6a723e98aa45f393e6add18f7309dfffa1b0e2 ]
There is no point in calling 'free_irq()' explicitly for
'WCD9335_IRQ_SLIMBUS' in the remove function.
The irqs are requested in 'wcd9335_setup_irqs()' using a resource managed
function (i.e. 'devm_request_threaded_irq()').
'wcd9335_setup_irqs()' requests all what is defined in the 'wcd9335_irqs'
structure.
This structure has only one entry for 'WCD9335_IRQ_SLIMBUS'.
So 'devm_request...irq()' + explicit 'free_irq()' would lead to a double
free.
Remove the unneeded 'free_irq()' from the remove function.
Fixes: 20aedafdf492 ("ASoC: wcd9335: add support to wcd9335 codec")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Message-Id: <0614d63bc00edd7e81dd367504128f3d84f72efa.1629091028.git.christophe.jaillet@wanadoo.fr>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 84c5c968b41f4578dd9b82e6d988ba2bb111129b
Author: Andy Duan <fugang.duan@nxp.com>
Date: Thu Aug 19 10:10:33 2021 +0800
tty: serial: fsl_lpuart: fix the wrong mapbase value
[ Upstream commit d5c38948448abc2bb6b36dbf85a554bf4748885e ]
Register offset needs to be applied on mapbase also.
dma_tx/rx_request use the physical address of UARTDATA.
Register offset is currently only applied to membase (the
corresponding virtual addr) but not on mapbase.
Fixes: 24b1e5f0e83c ("tty: serial: lpuart: add imx7ulp support")
Reviewed-by: Leonard Crestez <leonard.crestez@nxp.com>
Signed-off-by: Adriana Reus <adriana.reus@nxp.com>
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Signed-off-by: Andy Duan <fugang.duan@nxp.com>
Link: https://lore.kernel.org/r/20210819021033.32606-1-sherry.sun@nxp.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1a5d70b891cbabb37392cb5b17a25717a7477b2c
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Wed Aug 18 21:32:49 2021 +0200
usb: bdc: Fix a resource leak in the error handling path of 'bdc_probe()'
[ Upstream commit 6f15a2a09cecb7a2faba4a75bbd101f6f962294b ]
If an error occurs after a successful 'clk_prepare_enable()' call, it must
be undone by a corresponding 'clk_disable_unprepare()' call.
This call is already present in the remove function.
Add this call in the error handling path and reorder the code so that the
'clk_prepare_enable()' call happens later in the function.
The goal is to have as much managed resources functions as possible
before the 'clk_prepare_enable()' call in order to keep the error handling
path simple.
While at it, remove the now unneeded 'clk' variable.
Fixes: c87dca047849 ("usb: bdc: Add clock enable for new chips with a separate BDC clock")
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/f8a4a6897deb0c8cb2e576580790303550f15fcd.1629314734.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 77fe737810d1ef15604b0a7a80ec4df523a572e3
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Wed Aug 18 21:32:38 2021 +0200
usb: bdc: Fix an error handling path in 'bdc_probe()' when no suitable DMA config is available
[ Upstream commit d2f42e09393c774ab79088d8e3afcc62b3328fc9 ]
If no suitable DMA configuration is available, a previous 'bdc_phy_init()'
call must be undone by a corresponding 'bdc_phy_exit()' call.
Branch to the existing error handling path instead of returning
directly.
Fixes: cc29d4f67757 ("usb: bdc: Add support for USB phy")
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/0c5910979f39225d5d8fe68c9ab1c147c68ddee1.1629314734.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 14cb81a7563cafccce1e185cadbd696f6c373fe0
Author: Evgeny Novikov <novikov@ispras.ru>
Date: Wed Aug 25 20:09:02 2021 +0300
usb: ehci-orion: Handle errors of clk_prepare_enable() in probe
[ Upstream commit 4720f1bf4ee4a784d9ece05420ba33c9222a3004 ]
ehci_orion_drv_probe() did not account for possible errors of
clk_prepare_enable() that in particular could cause invocation of
clk_disable_unprepare() on clocks that were not prepared/enabled yet,
e.g. in remove or on handling errors of usb_add_hcd() in probe. Though,
there were several patches fixing different issues with clocks in this
driver, they did not solve this problem.
Add handling of errors of clk_prepare_enable() in ehci_orion_drv_probe()
to avoid calls of clk_disable_unprepare() without previous successful
invocation of clk_prepare_enable().
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 8c869edaee07 ("ARM: Orion: EHCI: Add support for enabling clocks")
Co-developed-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
Signed-off-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
Link: https://lore.kernel.org/r/20210825170902.11234-1-novikov@ispras.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 39df08f3b239430bdbf281e3e6997b1d56c1c41a
Author: Yang Yingliang <yangyingliang@huawei.com>
Date: Wed Aug 25 14:34:47 2021 +0800
octeontx2-pf: cn10k: Fix error return code in otx2_set_flowkey_cfg()
[ Upstream commit 5e8243e66b4d80eeaf9ed8cb0235ff133630a014 ]
If otx2_mbox_get_rsp() fails, otx2_set_flowkey_cfg() need return an
error code.
Fixes: e7938365459f ("octeontx2-pf: Fix algorithm index in MCAM rules with RSS action")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit bf412d951948143fcb97d6a09e0986ad4cd427b5
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Sun Jul 4 17:47:54 2021 +0300
i2c: xlp9xx: fix main IRQ check
[ Upstream commit 661e8a88e8317eb9ffe69c69d6cb4876370fe7e2 ]
Iff platform_get_irq() returns 0 for the main IRQ, the driver's probe()
method will return 0 early (as if the method's call was successful).
Let's consider IRQ0 valid for simplicity -- devm_request_irq() can always
override that decision...
Fixes: 2bbd681ba2b ("i2c: xlp9xx: Driver for Netlogic XLP9XX/5XX I2C controller")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: George Cherian <george.cherian@marvell.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6f2221ec81793b47e3050e4823292e0102dca29d
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Sun Jul 4 17:38:45 2021 +0300
i2c: mt65xx: fix IRQ check
[ Upstream commit 58fb7c643d346e2364404554f531cfa6a1a3917c ]
Iff platform_get_irq() returns 0, the driver's probe() method will return 0
early (as if the method's call was successful). Let's consider IRQ0 valid
for simplicity -- devm_request_irq() can always override that decision...
Fixes: ce38815d39ea ("I2C: mediatek: Add driver for MediaTek I2C controller")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Reviewed-by: Qii Wang <qii.wang@mediatek.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c41dd61c86482ab34f6f039b13296308018fd99b
Author: Len Baker <len.baker@gmx.com>
Date: Tue Aug 17 12:27:09 2021 +0200
CIFS: Fix a potencially linear read overflow
[ Upstream commit f980d055a0f858d73d9467bb0b570721bbfcdfb8 ]
strlcpy() reads the entire source buffer first. This read may exceed the
destination size limit. This is both inefficient and can lead to linear
read overflows if a source string is not NUL-terminated.
Also, the strnlen() call does not avoid the read overflow in the strlcpy
function when a not NUL-terminated string is passed.
So, replace this block by a call to kstrndup() that avoids this type of
overflow and does the same.
Fixes: 066ce6899484d ("cifs: rename cifs_strlcpy_to_host and make it use new functions")
Signed-off-by: Len Baker <len.baker@gmx.com>
Reviewed-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1707cfa165be62089eff9fa34c2281433474fc3b
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date: Wed Aug 25 15:38:57 2021 +0200
hv_utils: Set the maximum packet size for VSS driver to the length of the receive buffer
[ Upstream commit 9d68cd9120e4e3af38f843e165631c323b86b4e4 ]
Commit adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V out
of the ring buffer") introduced a notion of maximum packet size and for
KVM and FCOPY drivers set it to the length of the receive buffer. VSS
driver wasn't updated, this means that the maximum packet size is now
VMBUS_DEFAULT_MAX_PKT_SIZE (4k). Apparently, this is not enough. I'm
observing a packet of 6304 bytes which is being truncated to 4096. When
VSS driver tries to read next packet from ring buffer it starts from the
wrong offset and receives garbage.
Set the maximum packet size to 'HV_HYP_PAGE_SIZE * 2' in VSS driver. This
matches the length of the receive buffer and is in line with other utils
drivers.
Fixes: adae1e931acd ("Drivers: hv: vmbus: Copy packets sent by Hyper-V out of the ring buffer")
Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20210825133857.847866-1-vkuznets@redhat.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b0d7d8029720ceaea02e272353afc55e301b25bf
Author: Andrey Ignatov <rdna@fb.com>
Date: Fri Aug 20 09:39:35 2021 -0700
bpf: Fix possible out of bound write in narrow load handling
[ Upstream commit d7af7e497f0308bc97809cc48b58e8e0f13887e1 ]
Fix a verifier bug found by smatch static checker in [0].
This problem has never been seen in prod to my best knowledge. Fixing it
still seems to be a good idea since it's hard to say for sure whether
it's possible or not to have a scenario where a combination of
convert_ctx_access() and a narrow load would lead to an out of bound
write.
When narrow load is handled, one or two new instructions are added to
insn_buf array, but before it was only checked that
cnt >= ARRAY_SIZE(insn_buf)
And it's safe to add a new instruction to insn_buf[cnt++] only once. The
second try will lead to out of bound write. And this is what can happen
if `shift` is set.
Fix it by making sure that if the BPF_RSH instruction has to be added in
addition to BPF_AND then there is enough space for two more instructions
in insn_buf.
The full report [0] is below:
kernel/bpf/verifier.c:12304 convert_ctx_accesses() warn: offset 'cnt' incremented past end of array
kernel/bpf/verifier.c:12311 convert_ctx_accesses() warn: offset 'cnt' incremented past end of array
kernel/bpf/verifier.c
12282
12283 insn->off = off & ~(size_default - 1);
12284 insn->code = BPF_LDX | BPF_MEM | size_code;
12285 }
12286
12287 target_size = 0;
12288 cnt = convert_ctx_access(type, insn, insn_buf, env->prog,
12289 &target_size);
12290 if (cnt == 0 || cnt >= ARRAY_SIZE(insn_buf) ||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
Bounds check.
12291 (ctx_field_size && !target_size)) {
12292 verbose(env, "bpf verifier is misconfigured\n");
12293 return -EINVAL;
12294 }
12295
12296 if (is_narrower_load && size < target_size) {
12297 u8 shift = bpf_ctx_narrow_access_offset(
12298 off, size, size_default) * 8;
12299 if (ctx_field_size <= 4) {
12300 if (shift)
12301 insn_buf[cnt++] = BPF_ALU32_IMM(BPF_RSH,
^^^^^
increment beyond end of array
12302 insn->dst_reg,
12303 shift);
--> 12304 insn_buf[cnt++] = BPF_ALU32_IMM(BPF_AND, insn->dst_reg,
^^^^^
out of bounds write
12305 (1 << size * 8) - 1);
12306 } else {
12307 if (shift)
12308 insn_buf[cnt++] = BPF_ALU64_IMM(BPF_RSH,
12309 insn->dst_reg,
12310 shift);
12311 insn_buf[cnt++] = BPF_ALU64_IMM(BPF_AND, insn->dst_reg,
^^^^^^^^^^^^^^^
Same.
12312 (1ULL << size * 8) - 1);
12313 }
12314 }
12315
12316 new_prog = bpf_patch_insn_data(env, i + delta, insn_buf, cnt);
12317 if (!new_prog)
12318 return -ENOMEM;
12319
12320 delta += cnt - 1;
12321
12322 /* keep walking new program and skip insns we just inserted */
12323 env->prog = new_prog;
12324 insn = new_prog->insnsi + i + delta;
12325 }
12326
12327 return 0;
12328 }
[0] https://lore.kernel.org/bpf/20210817050843.GA21456@kili/
v1->v2:
- clarify that problem was only seen by static checker but not in prod;
Fixes: 46f53a65d2de ("bpf: Allow narrow loads with offset > 0")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Andrey Ignatov <rdna@fb.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20210820163935.1902398-1-rdna@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 227a6207aeefa74a81e9cd99716b35addb473a4c
Author: Charles Keepax <ckeepax@opensource.cirrus.com>
Date: Tue Aug 24 11:15:52 2021 +0100
ASoC: wm_adsp: Put debugfs_remove_recursive back in
[ Upstream commit e6d0b92ac00b53121a35b2a1ce8d393dc9179fdf ]
This patch reverts commit acbf58e53041 ("ASoC: wm_adsp: Let
soc_cleanup_component_debugfs remove debugfs"), and adds an
alternate solution to the issue. That patch removes the call to
debugfs_remove_recursive, which cleans up the DSPs debugfs. The
intention was to avoid an unbinding issue on an out of tree
driver/platform.
The issue with the patch is it means the driver no longer cleans up
its own debugfs, instead relying on ASoC to remove recurive on the
parent debugfs node. This is conceptually rather unclean, but also it
would prevent DSPs being added/removed independently of ASoC and soon
we are going to be upstreaming some non-audio parts with these DSPs,
which will require this.
Finally, it seems the issue on the platform is a result of the
wm_adsp2_cleanup_debugfs getting called twice. This is very likely a
problem on the platform side and will be resolved there. But in the mean
time make the code a little more robust to such issues, and again
conceptually a bit nicer, but clearing the debugfs_root variable in the
DSP structure when the debugfs is removed.
Fixes: acbf58e53041 ("ASoC: wm_adsp: Let soc_cleanup_component_debugfs remove debugfs"
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20210824101552.1119-1-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 20497b6f0f0e27c13fccb9dc83c56931e74347db
Author: Tony Lindgren <tony@atomide.com>
Date: Tue Aug 10 11:16:44 2021 +0300
mmc: moxart: Fix issue with uninitialized dma_slave_config
[ Upstream commit ee5165354d498e5bceb0b386e480ac84c5f8c28c ]
Depending on the DMA driver being used, the struct dma_slave_config may
need to be initialized to zero for the unused data.
For example, we have three DMA drivers using src_port_window_size and
dst_port_window_size. If these are left uninitialized, it can cause DMA
failures.
For moxart, this is probably not currently an issue but is still good to
fix though.
Fixes: 1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver")
Cc: Jonas Jensen <jonas.jensen@gmail.com>
Cc: Vinod Koul <vkoul@kernel.org>
Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20210810081644.19353-3-tony@atomide.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3c9598cd852cdb4f23377473fdfe14489cf8089f
Author: Tony Lindgren <tony@atomide.com>
Date: Tue Aug 10 11:16:43 2021 +0300
mmc: dw_mmc: Fix issue with uninitialized dma_slave_config
[ Upstream commit c3ff0189d3bc9c03845fe37472c140f0fefd0c79 ]
Depending on the DMA driver being used, the struct dma_slave_config may
need to be initialized to zero for the unused data.
For example, we have three DMA drivers using src_port_window_size and
dst_port_window_size. If these are left uninitialized, it can cause DMA
failures.
For dw_mmc, this is probably not currently an issue but is still good to
fix though.
Fixes: 3fc7eaef44db ("mmc: dw_mmc: Add external dma interface support")
Cc: Shawn Lin <shawn.lin@rock-chips.com>
Cc: Jaehoon Chung <jh80.chung@samsung.com>
Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Cc: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20210810081644.19353-2-tony@atomide.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e9886a3448b13e88ce20eac7162d5a2f7b938638
Author: Tony Lindgren <tony@atomide.com>
Date: Tue Aug 10 11:16:42 2021 +0300
mmc: sdhci: Fix issue with uninitialized dma_slave_config
[ Upstream commit 522654d534d315d540710124c57b49ca22ac5f72 ]
Depending on the DMA driver being used, the struct dma_slave_config may
need to be initialized to zero for the unused data.
For example, we have three DMA drivers using src_port_window_size and
dst_port_window_size. If these are left uninitialized, it can cause DMA
failures at least if external TI SDMA is ever configured for sdhci.
For other external DMA cases, this is probably not currently an issue but
is still good to fix though.
Fixes: 18e762e3b7a7 ("mmc: sdhci: add support for using external DMA devices")
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Chunyan Zhang <zhang.chunyan@linaro.org>
Cc: Faiz Abbas <faiz_abbas@ti.com>
Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Cc: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Link: https://lore.kernel.org/r/20210810081644.19353-1-tony@atomide.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ba8e10ad2d86b74730ef5b6c20ab130929123737
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date: Wed Aug 18 09:57:35 2021 +0200
ASoC: Intel: Skylake: Fix module resource and format selection
[ Upstream commit e8b374b649afe756c2470e0e6668022e90bf8518 ]
Module configuration may differ between its instances depending on
resources required and input and output audio format. Available
parameters to select from are stored in module resource and interface
(format) lists. These come from topology, together with description of
each of pipe's modules.
Ignoring index value provided by topology and relying always on 0th
entry leads to unexpected module behavior due to under/overbudged
resources assigned or impropper format selection. Fix by taking entry at
index specified by topology.
Fixes: f6fa56e22559 ("ASoC: Intel: Skylake: Parse and update module config structure")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Tested-by: Lukasz Majczak <lma@semihalf.com>
Link: https://lore.kernel.org/r/20210818075742.1515155-5-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 237684b24ce87bd0eabab865dc52edacaf796ed2
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date: Wed Aug 18 09:57:33 2021 +0200
ASoC: Intel: Skylake: Leave data as is when invoking TLV IPCs
[ Upstream commit 126b3422adc80f29d2129db7f61e0113a8a526c6 ]
Advancing pointer initially fixed issue for some users but caused
regression for others. Leave data as it to make it easier for end users
to adjust their topology files if needed.
Fixes: a8cd7066f042 ("ASoC: Intel: Skylake: Strip T and L from TLV IPCs")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Tested-by: Lukasz Majczak <lma@semihalf.com>
Link: https://lore.kernel.org/r/20210818075742.1515155-3-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 15f9fce811345ec8e81cdb9e2dfa322d5f342f62
Author: Cezary Rojewski <cezary.rojewski@intel.com>
Date: Wed Aug 18 09:57:32 2021 +0200
ASoC: Intel: kbl_da7219_max98927: Fix format selection for max98373
[ Upstream commit 6d41bbf2fd3615c56dbf2b67f6cbf9e83d14a2e2 ]
Contrary to what is said in board's file, topology targeting
kbl_da7219_max98373 expects format 16b, not 24/32b. Partially revert
changes added in 'ASoC: Intel: Boards: Add Maxim98373 support' to bring
old behavior back, aligning with topology expectations.
Fixes: 716d53cc7837 ("ASoC: Intel: Boards: Add Maxim98373 support")
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Tested-by: Lukasz Majczak <lma@semihalf.com>
Link: https://lore.kernel.org/r/20210818075742.1515155-2-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9490301f2f973616d3bd29136cc7dcf9a427a76d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu Jul 29 15:27:03 2021 +0300
m68k: coldfire: return success for clk_enable(NULL)
[ Upstream commit f6a4f0b424df957d84fa7b9f2d02981234ff5828 ]
The clk_enable is supposed work when CONFIG_HAVE_CLK is false, but it
returns -EINVAL. That means some drivers fail during probe.
[ 1.680000] flexcan: probe of flexcan.0 failed with error -22
Fixes: c1fb1bf64bb6 ("m68k: let clk_enable() return immediately if clk is NULL")
Fixes: bea8bcb12da0 ("m68knommu: Add support for the Coldfire m5441x.")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a181e99b0ba520dba7dcb3311ceb28b22db6ca60
Author: Geetha sowjanya <gakula@marvell.com>
Date: Sun Aug 22 17:32:27 2021 +0530
octeontx2-af: cn10k: Use FLIT0 register instead of FLIT1
[ Upstream commit 623da5ca70b70f01cd483585f5cd4c463cf2f2da ]
RVU SMMU widget stores the final translated PA at
RVU_AF_SMMU_TLN_FLIT0<57:18> instead of FLIT1 register. This patch
fixes the address translation logic to use the correct register.
Fixes: 893ae97214c3 ("octeontx2-af: cn10k: Support configurable LMTST regions")
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 392faa331b1190eebb00870ba1bc4423828a72e5
Author: Sunil Goutham <sgoutham@marvell.com>
Date: Sun Aug 22 17:32:26 2021 +0530
octeontx2-pf: Fix algorithm index in MCAM rules with RSS action
[ Upstream commit e7938365459f3a6d4edf212f435c4ad635621450 ]
Otherthan setting action as RSS in NPC MCAM entry, RSS flowkey
algorithm index also needs to be set. Otherwise whatever algorithm
is defined at flowkey index '0' will be considered by HW and pkt
flows will be distributed as such.
Fix this by saving the flowkey index sent by admin function while
initializing RSS and then use it when framing MCAM rules.
Fixes: 81a4362016e7 ("octeontx2-pf: Add RSS multi group support")
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 301e0b3c77c06fae3b208e27e7f8c3f41a81104e
Author: Sunil Goutham <sgoutham@marvell.com>
Date: Sun Aug 22 17:32:25 2021 +0530
octeontx2-pf: Don't install VLAN offload rule if netdev is down
[ Upstream commit 05209e3570e452cdaa644e8398a8875b6a91051d ]
Whenever user changes interface MAC address both default DMAC based
MCAM rule and VLAN offload (for strip) rules are updated with new
MAC address. To update or install VLAN offload rule PF driver needs
interface's receive channel info, which is retrieved from admin
function at the time of NIXLF initialization.
If user changes MAC address before interface is UP, VLAN offload rule
installation will fail and throw error as receive channel is not valid.
To avoid this, skip VLAN offload rule installation if netdev is not UP.
This rule will anyway be reinslatted as part of open() call.
Fixes: fd9d7859db6c ("octeontx2-pf: Implement ingress/egress VLAN offload")
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit edb20aa264e1a779f8ec2905a30fc57ad3600a2c
Author: Geetha sowjanya <gakula@marvell.com>
Date: Sun Aug 22 17:32:24 2021 +0530
octeontx2-af: Check capability flag while freeing ipolicer memory
[ Upstream commit 07cccffdbdd37820ba13c645af8e74a78a266557 ]
Bandwidth profiles (ipolicer structure)is implemented only on CN10K
platform. But current code try to free the ipolicer memory without
checking the capibility flag leading to driver crash on OCTEONTX2
platform. This patch fixes the issue by add capability flag check.
Fixes: e8e095b3b3700 ("octeontx2-af: cn10k: Bandwidth profiles config support")
Signed-off-by: Geetha sowjanya <gakula@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5e0f8ea99fb6058b531dd4b5b9d3bdb7dd7220ca
Author: Naveen Mamindlapalli <naveenm@marvell.com>
Date: Sun Aug 22 17:32:22 2021 +0530
octeontx2-pf: send correct vlan priority mask to npc_install_flow_req
[ Upstream commit 10df5a13ac6785b409ad749c4b10d4b220cc7e71 ]
This patch corrects the erroneous vlan priority mask field that was
send to npc_install_flow_req.
Fixes: 1d4d9e42c240 ("octeontx2-pf: Add tc flower hardware offload on ingress traffic")
Signed-off-by: Naveen Mamindlapalli <naveenm@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 869b01f4645c0bee527addbd399556bb4afbd936
Author: Subbaraya Sundeep <sbhatta@marvell.com>
Date: Sun Aug 22 17:32:19 2021 +0530
octeontx2-af: cn10k: Fix SDP base channel number
[ Upstream commit 477b53f3f95ba5341b4320f8b7a92cedc5a67650 ]
As per hardware the base channel number configured
for programmable channels of a block must be multiple
of number of channels of that block. This condition
is not met for SDP base channel currently. Hence this
patch ensures all the base channel numbers of all
blocks are multiple of number of channels present in
the blocks. Also instead of hardcoding SDP number
of channels the same is read from the NIX_AF_CONST1
register.
Fixes: 242da439214b ("octeontx2-af: cn10k: Add support for programmable")
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 844f3a8b90560d3c0136ed14969e11d802cd3ac1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon Aug 16 21:39:47 2021 +0300
rsi: fix an error code in rsi_probe()
[ Upstream commit 9adcdf6758d7c4c9bdaf22d78eb9fcae260ed113 ]
Return -ENODEV instead of success for unsupported devices.
Fixes: 54fdb318c111 ("rsi: add new device model for 9116")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210816183947.GA2119@kili
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d505abdba83d54bf188706baf8dcc416cb81b5f3
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Thu Aug 5 13:37:46 2021 +0300
rsi: fix error code in rsi_load_9116_firmware()
[ Upstream commit d0f8430332a16c7baa80ce2886339182c5d85f37 ]
This code returns success if the kmemdup() fails, but obviously it
should return -ENOMEM instead.
Fixes: e5a1ecc97e5f ("rsi: add firmware loading for 9116 device")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20210805103746.GA26417@kili
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d029b4a9ebaa87d2ce0697413f4afd4a3e84d8fa
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date: Tue Jun 15 17:21:53 2021 +0000
drm/exynos: g2d: fix missing unlock on error in g2d_runqueue_worker()
[ Upstream commit b74a29fac6de62f39b594e8f545b3a26db7edb5e ]
Add the missing unlock before return from function g2d_runqueue_worker()
in the error handling case.
Fixes: 445d3bed75de ("drm/exynos: use pm_runtime_resume_and_get()")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 15ccc20637e46b2b8aa03b32c142e14c8556a1f5
Author: Bob Peterson <rpeterso@redhat.com>
Date: Fri May 14 07:42:33 2021 -0500
gfs2: init system threads before freeze lock
[ Upstream commit a28dc123fa66ba7f3eca7cffc4b01d96bfd35c27 ]
Patch 96b1454f2e ("gfs2: move freeze glock outside the make_fs_rw and _ro
functions") changed the gfs2 mount sequence so that it holds the freeze
lock before calling gfs2_make_fs_rw. Before this patch, gfs2_make_fs_rw
called init_threads to initialize the quotad and logd threads. That is a
problem if the system needs to withdraw due to IO errors early in the
mount sequence, for example, while initializing the system statfs inode:
1. An IO error causes the statfs glock to not sync properly after
recovery, and leaves items on the ail list.
2. The leftover items on the ail list causes its do_xmote call to fail,
which makes it want to withdraw. But since the glock code cannot
withdraw (because the withdraw sequence uses glocks) it relies upon
the logd daemon to initiate the withdraw.
3. The withdraw can never be performed by the logd daemon because all
this takes place before the logd daemon is started.
This patch moves function init_threads from super.c to ops_fstype.c
and it changes gfs2_fill_super to start its threads before holding the
freeze lock, and if there's an error, stop its threads after releasing
it. This allows the logd to run unblocked by the freeze lock. Thus,
the logd daemon can perform its withdraw sequence properly.
Fixes: 96b1454f2e8e ("gfs2: move freeze glock outside the make_fs_rw and _ro functions")
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5bfb5e6553b8b4813aff96e9520f933a422378f5
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Sun Jul 4 17:35:54 2021 +0300
i2c: hix5hd2: fix IRQ check
[ Upstream commit f9b459c2ba5edfe247e86b45ad5dea8da542f3ea ]
Iff platform_get_irq() returns 0, the driver's probe() method will return 0
early (as if the method's call was successful). Let's consider IRQ0 valid
for simplicity -- devm_request_irq() can always override that decision...
Fixes: 15ef27756b23 ("i2c: hix5hd2: add i2c controller driver")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 536b5e919baea9b8d2f31a89b20f92acda9e001b
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Sun Jul 4 17:45:25 2021 +0300
i2c: s3c2410: fix IRQ check
[ Upstream commit d6840a5e370b7ea4fde16ce2caf431bcc87f9a75 ]
Iff platform_get_irq() returns 0, the driver's probe() method will return 0
early (as if the method's call was successful). Let's consider IRQ0 valid
for simplicity -- devm_request_irq() can always override that decision...
Fixes: e0d1ec97853f ("i2c-s3c2410: Change IRQ to be plain integer.")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 11732946b8de88dfbbcd0b1b49d1afc8091143b2
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Thu Aug 12 23:35:09 2021 +0300
i2c: iop3xx: fix deferred probing
[ Upstream commit a1299505162ad00def3573260c2c68b9c8e8d697 ]
When adding the code to handle platform_get_irq*() errors in the commit
489447380a29 ("handle errors returned by platform_get_irq*()"), the
actual error code was enforced to be -ENXIO in the driver for some
strange reason. This didn't matter much until the deferred probing was
introduced -- which requires an actual error code to be propagated
upstream from the failure site.
While fixing this, also stop overriding the errors from request_irq() to
-EIO (done since the pre-git era).
Fixes: 489447380a29 ("[PATCH] handle errors returned by platform_get_irq*()")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 78fded4c45292e2667151f91747f06bd283cde03
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Thu Aug 19 18:15:21 2021 +0300
Bluetooth: add timeout sanity check to hci_inquiry
[ Upstream commit f41a4b2b5eb7872109723dab8ae1603bdd9d9ec1 ]
Syzbot hit "task hung" bug in hci_req_sync(). The problem was in
unreasonable huge inquiry timeout passed from userspace.
Fix it by adding sanity check for timeout value to hci_inquiry().
Since hci_inquiry() is the only user of hci_req_sync() with user
controlled timeout value, it makes sense to check timeout value in
hci_inquiry() and don't touch hci_req_sync().
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-and-tested-by: syzbot+be2baed593ea56c6a84c@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 210e073c4e88f67c14fba8d88d80b586e617700d
Author: Kevin Mitchell <kevmitch@arista.com>
Date: Wed Aug 18 19:29:39 2021 -0700
lkdtm: replace SCSI_DISPATCH_CMD with SCSI_QUEUE_RQ
[ Upstream commit d1f278da6b11585f05b2755adfc8851cbf14a1ec ]
When scsi_dispatch_cmd was moved to scsi_lib.c and made static, some
compilers (i.e., at least gcc 8.4.0) decided to compile this
inline. This is a problem for lkdtm.ko, which inserted a kprobe
on this function for the SCSI_DISPATCH_CMD crashpoint.
Move this crashpoint one function up the call chain to
scsi_queue_rq. Though this is also a static function, it should never be
inlined because it is assigned as a structure entry. Therefore,
kprobe_register should always be able to find it.
Fixes: 82042a2cdb55 ("scsi: move scsi_dispatch_cmd to scsi_lib.c")
Acked-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Kevin Mitchell <kevmitch@arista.com>
Link: https://lore.kernel.org/r/20210819022940.561875-2-kevmitch@arista.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3885e0c66406663c63e5bf70a89461cb1ad828b3
Author: Xu Yu <xuyu@linux.alibaba.com>
Date: Wed Aug 18 12:47:52 2021 -0700
mm/swap: consider max pages in iomap_swapfile_add_extent
[ Upstream commit 36ca7943ac18aebf8aad4c50829eb2ea5ec847df ]
When the max pages (last_page in the swap header + 1) is smaller than
the total pages (inode size) of the swapfile, iomap_swapfile_activate
overwrites sis->max with total pages.
However, frontswap_map is a swap page state bitmap allocated using the
initial sis->max page count read from the swap header. If swapfile
activation increases sis->max, it's possible for the frontswap code to
walk off the end of the bitmap, thereby corrupting kernel memory.
[djwong: modify the description a bit; the original paragraph reads:
"However, frontswap_map is allocated using max pages. When test and clear
the sis offset, which is larger than max pages, of frontswap_map in
__frontswap_invalidate_page(), neighbors of frontswap_map may be
overwritten, i.e., slab is polluted."
Note also that this bug resulted in a behavioral change: activating a
swap file that was formatted and later extended results in all pages
being activated, not the number of pages recorded in the swap header.]
This fixes the issue by considering the limitation of max pages of swap
info in iomap_swapfile_add_extent().
To reproduce the case, compile kernel with slub RED ZONE, then run test:
$ sudo stress-ng -a 1 -x softlockup,resources -t 72h --metrics --times \
--verify -v -Y /root/tmpdir/stress-ng/stress-statistic-12.yaml \
--log-file /root/tmpdir/stress-ng/stress-logfile-12.txt \
--temp-path /root/tmpdir/stress-ng/
We'll get the error log as below:
[ 1151.015141] =============================================================================
[ 1151.016489] BUG kmalloc-16 (Not tainted): Right Redzone overwritten
[ 1151.017486] -----------------------------------------------------------------------------
[ 1151.017486]
[ 1151.018997] Disabling lock debugging due to kernel taint
[ 1151.019873] INFO: 0x0000000084e43932-0x0000000098d17cae @offset=7392. First byte 0x0 instead of 0xcc
[ 1151.021303] INFO: Allocated in __do_sys_swapon+0xcf6/0x1170 age=43417 cpu=9 pid=3816
[ 1151.022538] __slab_alloc+0xe/0x20
[ 1151.023069] __kmalloc_node+0xfd/0x4b0
[ 1151.023704] __do_sys_swapon+0xcf6/0x1170
[ 1151.024346] do_syscall_64+0x33/0x40
[ 1151.024925] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1151.025749] INFO: Freed in put_cred_rcu+0xa1/0xc0 age=43424 cpu=3 pid=2041
[ 1151.026889] kfree+0x276/0x2b0
[ 1151.027405] put_cred_rcu+0xa1/0xc0
[ 1151.027949] rcu_do_batch+0x17d/0x410
[ 1151.028566] rcu_core+0x14e/0x2b0
[ 1151.029084] __do_softirq+0x101/0x29e
[ 1151.029645] asm_call_irq_on_stack+0x12/0x20
[ 1151.030381] do_softirq_own_stack+0x37/0x40
[ 1151.031037] do_softirq.part.15+0x2b/0x30
[ 1151.031710] __local_bh_enable_ip+0x4b/0x50
[ 1151.032412] copy_fpstate_to_sigframe+0x111/0x360
[ 1151.033197] __setup_rt_frame+0xce/0x480
[ 1151.033809] arch_do_signal+0x1a3/0x250
[ 1151.034463] exit_to_user_mode_prepare+0xcf/0x110
[ 1151.035242] syscall_exit_to_user_mode+0x27/0x190
[ 1151.035970] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1151.036795] INFO: Slab 0x000000003b9de4dc objects=44 used=9 fp=0x00000000539e349e flags=0xfffffc0010201
[ 1151.038323] INFO: Object 0x000000004855ba01 @offset=7376 fp=0x0000000000000000
[ 1151.038323]
[ 1151.039683] Redzone 000000008d0afd3d: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc ................
[ 1151.041180] Object 000000004855ba01: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
[ 1151.042714] Redzone 0000000084e43932: 00 00 00 c0 cc cc cc cc ........
[ 1151.044120] Padding 000000000864c042: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZZZZZZZZZ
[ 1151.045615] CPU: 5 PID: 3816 Comm: stress-ng Tainted: G B 5.10.50+ #7
[ 1151.046846] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 1151.048633] Call Trace:
[ 1151.049072] dump_stack+0x57/0x6a
[ 1151.049585] check_bytes_and_report+0xed/0x110
[ 1151.050320] check_object+0x1eb/0x290
[ 1151.050924] ? __x64_sys_swapoff+0x39a/0x540
[ 1151.051646] free_debug_processing+0x151/0x350
[ 1151.052333] __slab_free+0x21a/0x3a0
[ 1151.052938] ? _cond_resched+0x2d/0x40
[ 1151.053529] ? __vunmap+0x1de/0x220
[ 1151.054139] ? __x64_sys_swapoff+0x39a/0x540
[ 1151.054796] ? kfree+0x276/0x2b0
[ 1151.055307] kfree+0x276/0x2b0
[ 1151.055832] __x64_sys_swapoff+0x39a/0x540
[ 1151.056466] do_syscall_64+0x33/0x40
[ 1151.057084] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 1151.057866] RIP: 0033:0x150340b0ffb7
[ 1151.058481] Code: Unable to access opcode bytes at RIP 0x150340b0ff8d.
[ 1151.059537] RSP: 002b:00007fff7f4ee238 EFLAGS: 00000246 ORIG_RAX: 00000000000000a8
[ 1151.060768] RAX: ffffffffffffffda RBX: 00007fff7f4ee66c RCX: 0000150340b0ffb7
[ 1151.061904] RDX: 000000000000000a RSI: 0000000000018094 RDI: 00007fff7f4ee860
[ 1151.063033] RBP: 00007fff7f4ef980 R08: 0000000000000000 R09: 0000150340a672bd
[ 1151.064135] R10: 00007fff7f4edca0 R11: 0000000000000246 R12: 0000000000018094
[ 1151.065253] R13: 0000000000000005 R14: 000000000160d930 R15: 00007fff7f4ee66c
[ 1151.066413] FIX kmalloc-16: Restoring 0x0000000084e43932-0x0000000098d17cae=0xcc
[ 1151.066413]
[ 1151.067890] FIX kmalloc-16: Object at 0x000000004855ba01 not freed
Fixes: 67482129cdab ("iomap: add a swapfile activation function")
Fixes: a45c0eccc564 ("iomap: move the swapfile code into a separate file")
Signed-off-by: Gang Deng <gavin.dg@linux.alibaba.com>
Signed-off-by: Xu Yu <xuyu@linux.alibaba.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f820d670a06b78127da3adb792a02283fb4c1183
Author: Nadezda Lutovinova <lutovinova@ispras.ru>
Date: Wed Aug 18 17:12:47 2021 +0300
usb: gadget: mv_u3d: request_irq() after initializing UDC
[ Upstream commit 2af0c5ffadaf9d13eca28409d4238b4e672942d3 ]
If IRQ occurs between calling request_irq() and mv_u3d_eps_init(),
then null pointer dereference occurs since u3d->eps[] wasn't
initialized yet but used in mv_u3d_nuke().
The patch puts registration of the interrupt handler after
initializing of neccesery data.
Found by Linux Driver Verification project (linuxtesting.org).
Fixes: 90fccb529d24 ("usb: gadget: Gadget directory cleanup - group UDC drivers")
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Nadezda Lutovinova <lutovinova@ispras.ru>
Link: https://lore.kernel.org/r/20210818141247.4794-1-lutovinova@ispras.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 40c1cc3f3d0cecb6c5b05c70fa7dc903cf04ebdd
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Fri Aug 6 08:46:11 2021 +0200
firmware: raspberrypi: Fix a leak in 'rpi_firmware_get()'
[ Upstream commit 09cbd1df7d2615c19e40facbe31fdcb5f1ebfa96 ]
The reference taken by 'of_find_device_by_node()' must be released when
not needed anymore.
Add the corresponding 'put_device()' in the normal and error handling
paths.
Fixes: 4e3d60656a72 ("ARM: bcm2835: Add the Raspberry Pi firmware driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/5e17e5409b934cd08bf6f9279c73be5c1cb11cce.1628232242.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b4c76476360cdca55e5e5bf964069085125191bb
Author: Shengjiu Wang <shengjiu.wang@nxp.com>
Date: Wed Aug 18 14:03:34 2021 +0800
ASoC: fsl_rpmsg: Check -EPROBE_DEFER for getting clocks
[ Upstream commit 2fbbcffea5b6adbfe90ffc842a6b3eb2d7e381ed ]
The devm_clk_get() may return -EPROBE_DEFER, then clocks
will be assigned to NULL wrongly. As the clocks are
optional so we can use devm_clk_get_optional() instead of
devm_clk_get().
Fixes: b73d9e6225e8 ("ASoC: fsl_rpmsg: Add CPU DAI driver for audio base on rpmsg")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1629266614-6942-1-git-send-email-shengjiu.wang@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b8c03f2c4f1c9ad2459d661a4fd9ae0e0aa33a5c
Author: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Date: Tue Aug 17 10:48:11 2021 +0200
hwmon: remove amd_energy driver in Makefile
[ Upstream commit b3a7ab2d4376726178909e27b6956c012277ac4e ]
Commit 9049572fb145 ("hwmon: Remove amd_energy driver") removes the driver,
but misses to adjust the Makefile.
Hence, ./scripts/checkkconfigsymbols.py warns:
SENSORS_AMD_ENERGY
Referencing files: drivers/hwmon/Makefile
Remove the missing piece of this driver removal.
Fixes: 9049572fb145 ("hwmon: Remove amd_energy driver")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20210817084811.10673-1-lukas.bulwahn@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 22df141dbb06db6fc4521f21612b8cf4a3b1ef67
Author: Chris Packham <chris.packham@alliedtelesis.co.nz>
Date: Thu Aug 12 13:39:59 2021 +1200
hwmon: (pmbus/bpa-rs600) Don't use rated limits as warn limits
[ Upstream commit 7a8c68c57fd09541377f6971f25efdeb9a926c37 ]
In the initial implementation a number of PMBUS_x_WARN_LIMITs were
mapped to MFR fields. This was incorrect as these MFR limits reflect the
rated limit as opposed to a limit which will generate warning. Instead
return -ENXIO like we were already doing for other WARN_LIMITs.
Subsequently these rated limits have been exposed generically as new
fields in the sysfs ABI so the values are still available.
Fixes: 15b2703e5e02 ("hwmon: (pmbus) Add driver for BluTek BPA-RS600")
Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
Link: https://lore.kernel.org/r/20210812014000.26293-2-chris.packham@alliedtelesis.co.nz
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9e354badcbb6b6faab64c9e4d27a1089fa02bf63
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Thu Aug 12 23:39:11 2021 +0300
i2c: synquacer: fix deferred probing
[ Upstream commit 8d744da241b81f4211f4813b0d3c1981326fa9ca ]
The driver overrides the error codes returned by platform_get_irq() to
-ENODEV, so if it returns -EPROBE_DEFER, the driver will fail the probe
permanently instead of the deferred probing. Switch to propagating the
error codes upstream.
Fixes: 0d676a6c4390 ("i2c: add support for Socionext SynQuacer I2C controller")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omprussia.ru>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 45b7eb4928c9572d6fb48cb314fc54cf90de5e4e
Author: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Date: Tue Aug 17 12:54:04 2021 +0200
clk: staging: correct reference to config IOMEM to config HAS_IOMEM
[ Upstream commit cbfa6f33e3a685c329d78e06b0cf1dcb23c9d849 ]
Commit 0a0a66c984b3 ("clk: staging: Specify IOMEM dependency for Xilinx
Clocking Wizard driver") introduces a dependency on the non-existing config
IOMEM, which basically makes it impossible to include this driver into any
build. Fortunately, ./scripts/checkkconfigsymbols.py warns:
IOMEM
Referencing files: drivers/staging/clocking-wizard/Kconfig
The config for IOMEM support is called HAS_IOMEM. Correct this reference to
the intended config.
Fixes: 0a0a66c984b3 ("clk: staging: Specify IOMEM dependency for Xilinx Clocking Wizard driver")
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Link: https://lore.kernel.org/r/20210817105404.13146-1-lukas.bulwahn@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit dccc1d90cb4eba8f3d0757dcc7ffbd20bd6c8776
Author: Pali Rohár <pali@kernel.org>
Date: Thu Jun 24 23:55:46 2021 +0200
arm64: dts: marvell: armada-37xx: Extend PCIe MEM space
[ Upstream commit 514ef1e62d6521c2199d192b1c71b79d2aa21d5a ]
Current PCIe MEM space of size 16 MB is not enough for some combination
of PCIe cards (e.g. NVMe disk together with ath11k wifi card). ARM Trusted
Firmware for Armada 3700 platform already assigns 128 MB for PCIe window,
so extend PCIe MEM space to the end of 128 MB PCIe window which allows to
allocate more PCIe BARs for more PCIe cards.
Without this change some combination of PCIe cards cannot be used and
kernel show error messages in dmesg during initialization:
pci 0000:00:00.0: BAR 8: no space for [mem size 0x01800000]
pci 0000:00:00.0: BAR 8: failed to assign [mem size 0x01800000]
pci 0000:00:00.0: BAR 6: assigned [mem 0xe8000000-0xe80007ff pref]
pci 0000:01:00.0: BAR 8: no space for [mem size 0x01800000]
pci 0000:01:00.0: BAR 8: failed to assign [mem size 0x01800000]
pci 0000:02:03.0: BAR 8: no space for [mem size 0x01000000]
pci 0000:02:03.0: BAR 8: failed to assign [mem size 0x01000000]
pci 0000:02:07.0: BAR 8: no space for [mem size 0x00100000]
pci 0000:02:07.0: BAR 8: failed to assign [mem size 0x00100000]
pci 0000:03:00.0: BAR 0: no space for [mem size 0x01000000 64bit]
pci 0000:03:00.0: BAR 0: failed to assign [mem size 0x01000000 64bit]
Due to bugs in U-Boot port for Turris Mox, the second range in Turris Mox
kernel DTS file for PCIe must start at 16 MB offset. Otherwise U-Boot
crashes during loading of kernel DTB file. This bug is present only in
U-Boot code for Turris Mox and therefore other Armada 3700 devices are not
affected by this bug. Bug is fixed in U-Boot version 2021.07.
To not break booting new kernels on existing versions of U-Boot on Turris
Mox, use first 16 MB range for IO and second range with rest of PCIe window
for MEM.
Signed-off-by: Pali Rohár <pali@kernel.org>
Fixes: 76f6386b25cc ("arm64: dts: marvell: Add Aardvark PCIe support for Armada 3700")
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 75b9d8bdb8c7590fd6eb40c6797be1514ae4c9be
Author: J. Bruce Fields <bfields@redhat.com>
Date: Thu Aug 12 16:41:43 2021 -0400
nfsd4: Fix forced-expiry locking
[ Upstream commit f7104cc1a9159cd0d3e8526cb638ae0301de4b61 ]
This should use the network-namespace-wide client_lock, not the
per-client cl_lock.
You shouldn't see any bugs unless you're actually using the
forced-expiry interface introduced by 89c905beccbb.
Fixes: 89c905beccbb "nfsd: allow forced expiration of NFSv4 clients"
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e1af5db1b481ef1b8d6a6cba55e1f96f9a98cb27
Author: Chuck Lever <chuck.lever@oracle.com>
Date: Thu Aug 5 15:11:24 2021 -0400
SUNRPC: Fix a NULL pointer deref in trace_svc_stats_latency()
[ Upstream commit 5c11720767f70d34357d00a15ba5a0ad052c40fe ]
Some paths through svc_process() leave rqst->rq_procinfo set to
NULL, which triggers a crash if tracing happens to be enabled.
Fixes: 89ff87494c6e ("SUNRPC: Display RPC procedure names instead of proc numbers")
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit af938908015427893e77aefdc32cb0dde01efce9
Author: Benjamin Coddington <bcodding@redhat.com>
Date: Mon Jul 26 09:33:28 2021 -0400
lockd: Fix invalid lockowner cast after vfs_test_lock
[ Upstream commit cd2d644ddba183ec7b451b7c20d5c7cc06fcf0d7 ]
After calling vfs_test_lock() the pointer to a conflicting lock can be
returned, and that lock is not guarunteed to be owned by nlm. In that
case, we cannot cast it to struct nlm_lockowner. Instead return the pid
of that conflicting lock.
Fixes: 646d73e91b42 ("lockd: Show pid of lockd for remote locks")
Signed-off-by: Benjamin Coddington <bcodding@redhat.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d308735c443244efebd682a0d1570fc9d923b1e4
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Sun Aug 15 23:27:37 2021 +0200
locking/local_lock: Add missing owner initialization
[ Upstream commit d8bbd97ad0b99a9394f2cd8410b884c48e218cf0 ]
If CONFIG_DEBUG_LOCK_ALLOC=y is enabled then local_lock_t has an 'owner'
member which is checked for consistency, but nothing initialized it to
zero explicitly.
The static initializer does so implicit, and the run time allocated per CPU
storage is usually zero initialized as well, but relying on that is not
really good practice.
Fixes: 91710728d172 ("locking: Introduce local_lock()")
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20210815211301.969975279@linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d2c14405f6a3294dd7f2f7b31b4fa771d496b6cd
Author: Chih-Kang Chang <gary.chang@realtek.com>
Date: Mon Aug 16 16:51:28 2021 +0800
mac80211: Fix insufficient headroom issue for AMSDU
[ Upstream commit f50d2ff8f016b79a2ff4acd5943a1eda40c545d4 ]
ieee80211_amsdu_realloc_pad() fails to account for extra_tx_headroom,
the original reserved headroom might be eaten. Add the necessary
extra_tx_headroom.
Fixes: 6e0456b54545 ("mac80211: add A-MSDU tx support")
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://lore.kernel.org/r/20210816085128.10931-2-pkshih@realtek.com
[fix indentation]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit da4416392f73a0fd04f0292aa0877f2c6a70db53
Author: Andrii Nakryiko <andrii@kernel.org>
Date: Sun Aug 15 00:06:00 2021 -0700
libbpf: Re-build libbpf.so when libbpf.map changes
[ Upstream commit 61c7aa5020e98ac2fdcf07d07eec1baf2e9f0a08 ]
Ensure libbpf.so is re-built whenever libbpf.map is modified. Without this,
changes to libbpf.map are not detected and versioned symbols mismatch error
will be reported until `make clean && make` is used, which is a suboptimal
developer experience.
Fixes: 306b267cb3c4 ("libbpf: Verify versioned symbols")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/20210815070609.987780-8-andrii@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b45f0d0105a0f50e681dc8fac4b32e1192de34f2
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Fri Aug 13 23:32:38 2021 +0300
usb: phy: tahvo: add IRQ check
[ Upstream commit 0d45a1373e669880b8beaecc8765f44cb0241e47 ]
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to request_threaded_irq() (which
takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding an
original error code. Stop calling request_threaded_irq() with the invalid
IRQ #s.
Fixes: 9ba96ae5074c ("usb: omap1: Tahvo USB transceiver driver")
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/8280d6a4-8e9a-7cfe-1aa9-db586dc9afdf@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 78b339b95489aaaff1a8902e182cafcbb6d34228
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Fri Aug 13 23:30:18 2021 +0300
usb: host: ohci-tmio: add IRQ check
[ Upstream commit 4ac5132e8a4300637a2da8f5d6bc7650db735b8a ]
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to usb_add_hcd() (which takes
*unsigned* IRQ #), causing request_irq() that it calls to fail with
-EINVAL, overriding an original error code. Stop calling usb_add_hcd()
with the invalid IRQ #s.
Fixes: 78c73414f4f6 ("USB: ohci: add support for tmio-ohci cell")
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/402e1a45-a0a4-0e08-566a-7ca1331506b1@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f4a79b7d8bd6171ce60902a5d3ef9badec397ab3
Author: Valentin Schneider <valentin.schneider@arm.com>
Date: Wed Aug 11 21:14:31 2021 +0100
PM: cpu: Make notifier chain use a raw_spinlock_t
[ Upstream commit b2f6662ac08d0e7c25574ce53623c71bdae9dd78 ]
Invoking atomic_notifier_chain_notify() requires acquiring a spinlock_t,
which can block under CONFIG_PREEMPT_RT. Notifications for members of the
cpu_pm notification chain will be issued by the idle task, which can never
block.
Making *all* atomic_notifiers use a raw_spinlock is too big of a hammer, as
only notifications issued by the idle task are problematic.
Special-case cpu_pm_notifier_chain by kludging a raw_notifier and
raw_spinlock_t together, matching the atomic_notifier behavior with a
raw_spinlock_t.
Fixes: 70d932985757 ("notifier: Fix broken error handling pattern")
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6f1dfdeeaa70896328336c9a62723413826259e8
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date: Tue Aug 10 12:53:15 2021 +0800
Bluetooth: Move shutdown callback before flushing tx and rx queue
[ Upstream commit 0ea53674d07fb6db2dd7a7ec2fdc85a12eb246c2 ]
Commit 0ea9fd001a14 ("Bluetooth: Shutdown controller after workqueues
are flushed or cancelled") introduced a regression that makes mtkbtsdio
driver stops working:
[ 36.593956] Bluetooth: hci0: Firmware already downloaded
[ 46.814613] Bluetooth: hci0: Execution of wmt command timed out
[ 46.814619] Bluetooth: hci0: Failed to send wmt func ctrl (-110)
The shutdown callback depends on the result of hdev->rx_work, so we
should call it before flushing rx_work:
-> btmtksdio_shutdown()
-> mtk_hci_wmt_sync()
-> __hci_cmd_send()
-> wait for BTMTKSDIO_TX_WAIT_VND_EVT gets cleared
-> btmtksdio_recv_event()
-> hci_recv_frame()
-> queue_work(hdev->workqueue, &hdev->rx_work)
-> clears BTMTKSDIO_TX_WAIT_VND_EVT
So move the shutdown callback before flushing TX/RX queue to resolve the
issue.
Reported-and-tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
Tested-by: Hsin-Yi Wang <hsinyi@chromium.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Fixes: 0ea9fd001a14 ("Bluetooth: Shutdown controller after workqueues are flushed or cancelled")
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6034f6f3958a0ddce8a3e92d62ca4abc22643b99
Author: Voon Weifeng <weifeng.voon@intel.com>
Date: Mon Aug 16 14:15:58 2021 +0800
net: stmmac: fix INTR TBU status affecting irq count statistic
[ Upstream commit 1975df880b959e30f28d66148a12d77b458abd76 ]
DMA channel status "Transmit buffer unavailable(TBU)" bit is not
considered as a successful dma tx. Hence, it should not affect
all the irq count statistic.
Fixes: 1103d3a5531c ("net: stmmac: dwmac4: Also use TBU interrupt to clean TX path")
Signed-off-by: Voon Weifeng <weifeng.voon@intel.com>
Signed-off-by: Vijayakannan Ayyathurai <vijayakannan.ayyathurai@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e801e140ae6cfea80e9377e754e49bc11d1ec166
Author: Juhee Kang <claudiajkang@gmail.com>
Date: Fri Aug 13 00:08:13 2021 +0900
samples: pktgen: add missing IPv6 option to pktgen scripts
[ Upstream commit 0f0c4f1b72e090b23131700bb155944cc28b2a7b ]
Currently, "sample04" and "sample05" are not working properly when
running with an IPv6 option("-6"). The commit 0f06a6787e05 ("samples:
Add an IPv6 "-6" option to the pktgen scripts") has omitted the addition
of this option at "sample04" and "sample05".
In order to support IPv6 option, this commit adds logic related to IPv6
option.
Fixes: 0f06a6787e05 ("samples: Add an IPv6 "-6" option to the pktgen scripts")
Signed-off-by: Juhee Kang <claudiajkang@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5eb9d59b73f6ec20f939daa4939bbbe5eaf1e8e3
Author: Leon Romanovsky <leon@kernel.org>
Date: Sat Aug 14 12:57:30 2021 +0300
devlink: Clear whole devlink_flash_notify struct
[ Upstream commit ed43fbac717882165a2a4bd64f7b1f56f7467bb7 ]
The { 0 } doesn't clear all fields in the struct, but tells to the
compiler to set all fields to zero and doesn't touch any sub-fields
if they exists.
The {} is an empty initialiser that instructs to fully initialize whole
struct including sub-fields, which is error-prone for future
devlink_flash_notify extensions.
Fixes: 6700acc5f1fe ("devlink: collect flash notify params into a struct")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1b703f43b3bf74ad74b36ef0e8d6438147f6e832
Author: Ilya Leoshkevich <iii@linux.ibm.com>
Date: Fri Aug 13 00:48:14 2021 +0200
selftests/bpf: Fix test_core_autosize on big-endian machines
[ Upstream commit d164dd9a5c08c16a883b3de97d13948c7be7fa4d ]
The "probed" part of test_core_autosize copies an integer using
bpf_core_read() into an integer of a potentially different size.
On big-endian machines a destination offset is required for this to
produce a sensible result.
Fixes: 888d83b961f6 ("selftests/bpf: Validate libbpf's auto-sizing of LD/ST/STX instructions")
Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210812224814.187460-1-iii@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 949f35e1952189fc714396ae8c4c0964abc21c3b
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Wed Aug 11 17:52:54 2021 +0200
usb: gadget: udc: renesas_usb3: Fix soc_device_match() abuse
[ Upstream commit cea45a3bd2dd4d9c35581328f571afd32b3c9f48 ]
soc_device_match() is intended as a last resort, to handle e.g. quirks
that cannot be handled by matching based on a compatible value.
As the device nodes for the Renesas USB 3.0 Peripheral Controller on
R-Car E3 and RZ/G2E do have SoC-specific compatible values, the latter
can and should be used to match against these devices.
This also fixes support for the USB 3.0 Peripheral Controller on the
R-Car E3e (R8A779M6) SoC, which is a different grading of the R-Car E3
(R8A77990) SoC, using the same SoC-specific compatible value.
Fixes: 30025efa8b5e75f5 ("usb: gadget: udc: renesas_usb3: add support for r8a77990")
Fixes: 546970fdab1da5fe ("usb: gadget: udc: renesas_usb3: add support for r8a774c0")
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/760981fb4cd110d7cbfc9dcffa365e7c8b25c6e5.1628696960.git.geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 201d3d9d318694b963b7fad495103a228dde5f49
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Mon Aug 9 23:53:16 2021 +0300
usb: phy: twl6030: add IRQ checks
[ Upstream commit 0881e22c06e66af0b64773c91c8868ead3d01aa1 ]
The driver neglects to check the result of platform_get_irq()'s calls and
blithely passes the negative error codes to request_threaded_irq() (which
takes *unsigned* IRQ #), causing them both to fail with -EINVAL, overriding
an original error code. Stop calling request_threaded_irq() with the
invalid IRQ #s.
Fixes: c33fad0c3748 ("usb: otg: Adding twl6030-usb transceiver driver for OMAP4430")
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/9507f50b-50f1-6dc4-f57c-3ed4e53a1c25@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5f3b70852c373fa196b7b708c7b1010b8861578b
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Mon Aug 9 23:50:18 2021 +0300
usb: phy: fsl-usb: add IRQ check
[ Upstream commit ecc2f30dbb25969908115c81ec23650ed982b004 ]
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to request_irq() (which takes
*unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original
error code. Stop calling request_irq() with the invalid IRQ #s.
Fixes: 0807c500a1a6 ("USB: add Freescale USB OTG Transceiver driver")
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/b0a86089-8b8b-122e-fd6d-73e8c2304964@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5e8f88a2b6fc25bf171f25bd6e14bb5338718efe
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Mon Aug 9 23:45:15 2021 +0300
usb: misc: brcmstb-usb-pinmap: add IRQ check
[ Upstream commit 711087f342914e831269438ff42cf59bb0142c71 ]
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_irq() (which takes
*unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original
error code. Stop calling devm_request_irq() with the invalid IRQ #s.
Fixes: 517c4c44b323 ("usb: Add driver to allow any GPIO to be used for 7211 USB signals")
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/806d0b1a-365b-93d9-3fc1-922105ca5e61@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f32c136de123fea69a471de64ddf4e1b1d285884
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon Jun 28 13:10:38 2021 +0300
mac80211: remove unnecessary NULL check in ieee80211_register_hw()
[ Upstream commit 4a11174d6dbd0bde6d5a1d6efb0d70f58811db55 ]
The address "&sband->iftype_data[i]" points to an array at the end of
struct. It can't be NULL and so the check can be removed.
Fixes: bac2fd3d7534 ("mac80211: remove use of ieee80211_get_he_sta_cap()")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/YNmgHi7Rh3SISdog@mwanda
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a23f057d7063643019cbe28ad9722d0ff9501a66
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Mon Aug 9 23:35:11 2021 +0300
usb: gadget: udc: s3c2410: add IRQ check
[ Upstream commit ecff88e819e31081d41cd05bb199b9bd10e13e90 ]
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to request_irq() (which takes
*unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original
error code. Stop calling request_irq() with the invalid IRQ #s.
Fixes: 188db4435ac6 ("usb: gadget: s3c: use platform resources")
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/bd69b22c-b484-5a1f-c798-78d4b78405f2@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a57702636e15b7a74c7af6b51b6debda3d133240
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Mon Aug 9 23:27:28 2021 +0300
usb: gadget: udc: at91: add IRQ check
[ Upstream commit 50855c31573b02963f0aa2aacfd4ea41c31ae0e0 ]
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_irq() (which takes
*unsigned* IRQ #), causing it to fail with -EINVAL, overriding an original
error code. Stop calling devm_request_irq() with the invalid IRQ #s.
Fixes: 8b2e76687b39 ("USB: AT91 UDC updates, mostly power management")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Acked-by: Felipe Balbi <balbi@kernel.org>
Link: https://lore.kernel.org/r/6654a224-739a-1a80-12f0-76d920f87b6c@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 083976715d07eff31064203b5037c53c03ec82fb
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Mon Aug 9 23:23:51 2021 +0300
usb: dwc3: qcom: add IRQ check
[ Upstream commit 175006956740f70ca23394c58f8d7804776741bd ]
In dwc3_qcom_acpi_register_core(), the driver neglects to check the result
of platform_get_irq()'s call and blithely assigns the negative error codes
to the allocated child device's IRQ resource and then passing this resource
to platform_device_add_resources() and later causing dwc3_otg_get_irq() to
fail anyway. Stop calling platform_device_add_resources() with the invalid
IRQ #s, so that there's less complexity in the IRQ error checking.
Fixes: 2bc02355f8ba ("usb: dwc3: qcom: Add support for booting with ACPI")
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/45fec3da-1679-5bfe-5d74-219ca3fb28e7@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f4d35572fa738949f793c19791a9236791b9e302
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Mon Aug 9 23:21:14 2021 +0300
usb: dwc3: meson-g12a: add IRQ check
[ Upstream commit baa2986bda3f7b2386607587a4185e3dff8f98df ]
The driver neglects to check the result of platform_get_irq()'s call and
blithely passes the negative error codes to devm_request_threaded_irq()
(which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding
an original error code. Stop calling devm_request_threaded_irq() with the
invalid IRQ #s.
Fixes: f90db10779ad ("usb: dwc3: meson-g12a: Add support for IRQ based OTG switching")
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Link: https://lore.kernel.org/r/96106462-5538-0b2f-f2ab-ee56e4853912@omp.ru
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7331e96735d03f3cf7e8a65acebe4e80253c6ff0
Author: Douglas Anderson <dianders@chromium.org>
Date: Wed Aug 11 08:17:56 2021 -0700
ASoC: rt5682: Properly turn off regulators if wrong device ID
[ Upstream commit 772d44526e203c062171786e514373f129616278 ]
When I booted up on a board that had a slightly different codec
stuffed on it, I got this message at bootup:
rt5682 9-001a: Device with ID register 6749 is not rt5682
That's normal/expected, but what wasn't normal was the splat that I
got after:
WARNING: CPU: 7 PID: 176 at drivers/regulator/core.c:2151 _regulator_put+0x150/0x158
pc : _regulator_put+0x150/0x158
...
Call trace:
_regulator_put+0x150/0x158
regulator_bulk_free+0x48/0x70
devm_regulator_bulk_release+0x20/0x2c
release_nodes+0x1cc/0x244
devres_release_all+0x44/0x60
really_probe+0x17c/0x378
...
This is because the error paths don't turn off the regulator. Let's
fix that.
Fixes: 0ddce71c21f0 ("ASoC: rt5682: add rt5682 codec driver")
Fixes: 87b42abae99d ("ASoC: rt5682: Implement remove callback")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210811081751.v2.1.I4a1d9aa5d99e05aeee15c2768db600158d76cab8@changeid
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 06b7035bcf1dd3e0f34012234c9f9efb2cfe7436
Author: Parav Pandit <parav@nvidia.com>
Date: Tue Aug 10 16:24:21 2021 +0300
net/mlx5: Fix unpublish devlink parameters
[ Upstream commit 6f35723864b42ec9e9bb95a503449633395c4975 ]
Cleanup routine missed to unpublish the parameters. Add it.
Fixes: e890acd5ff18 ("net/mlx5: Add devlink flow_steering_mode parameter")
Signed-off-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4b61014b3eb19fb05321f5f5c85201a6c477b96f
Author: Kuogee Hsieh <khsieh@codeaurora.org>
Date: Thu Aug 5 13:44:53 2021 -0700
drm/msm/dp: replug event is converted into an unplug followed by an plug events
[ Upstream commit 7e10bf427850f2d7133fd091999abd5fc1755cdb ]
Remove special handling of replug interrupt and instead treat replug event
as a sequential unplug followed by a plugin event. This is needed to meet
the requirements of DP Link Layer CTS test case 4.2.1.3.
Changes in V2:
-- add fixes statement
Changes in V3:
-- delete EV_HPD_REPLUG_INT
Fixes: f21c8a276c2d ("drm/msm/dp: handle irq_hpd with sink_count = 0 correctly")
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1628196295-7382-5-git-send-email-khsieh@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5854fabe40d226fb7239e32b5ff8de791b9f7a07
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Fri Aug 6 11:15:13 2021 +0200
drm/msm/dsi: Fix some reference counted resource leaks
[ Upstream commit 6977cc89c87506ff17e6c05f0e37f46752256e82 ]
'of_find_device_by_node()' takes a reference that must be released when
not needed anymore.
This is expected to be done in 'dsi_destroy()'.
However, there are 2 issues in 'dsi_get_phy()'.
First, if 'of_find_device_by_node()' succeeds but 'platform_get_drvdata()'
returns NULL, 'msm_dsi->phy_dev' will still be NULL, and the reference
won't be released in 'dsi_destroy()'.
Secondly, as 'of_find_device_by_node()' already takes a reference, there is
no need for an additional 'get_device()'.
Move the assignment to 'msm_dsi->phy_dev' a few lines above and remove the
unneeded 'get_device()' to solve both issues.
Fixes: ec31abf6684e ("drm/msm/dsi: Separate PHY to another platform device")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/f15bc57648a00e7c99f943903468a04639d50596.1628241097.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0b9da4bde0d59c61b3675bdd80a05a726beb875a
Author: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Date: Tue Aug 10 12:14:10 2021 +0800
Bluetooth: fix repeated calls to sco_sock_kill
[ Upstream commit e1dee2c1de2b4dd00eb44004a4bda6326ed07b59 ]
In commit 4e1a720d0312 ("Bluetooth: avoid killing an already killed
socket"), a check was added to sco_sock_kill to skip killing a socket
if the SOCK_DEAD flag was set.
This was done after a trace for a use-after-free bug showed that the
same sock pointer was being killed twice.
Unfortunately, this check prevents sco_sock_kill from running on any
socket. sco_sock_kill kills a socket only if it's zapped and orphaned,
however sock_orphan announces that the socket is dead before detaching
it. i.e., orphaned sockets have the SOCK_DEAD flag set.
To fix this, we remove the check for SOCK_DEAD, and avoid repeated
calls to sco_sock_kill by removing incorrect calls in:
1. sco_sock_timeout. The socket should not be killed on timeout as
further processing is expected to be done. For example,
sco_sock_connect sets the timer then waits for the socket to be
connected or for an error to be returned.
2. sco_conn_del. This function should clean up resources for the
connection, but the socket itself should be cleaned up in
sco_sock_release.
3. sco_sock_close. Calls to sco_sock_close in sco_sock_cleanup_listen
and sco_sock_release are followed by sco_sock_kill. Hence the
duplicated call should be removed.
Fixes: 4e1a720d0312 ("Bluetooth: avoid killing an already killed socket")
Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 533959ce47f88b7f78ebd04267c6703362a1231b
Author: Curtis Malainey <cujomalainey@chromium.org>
Date: Mon Aug 9 14:35:39 2021 -0700
ASoC: Intel: Fix platform ID matching
[ Upstream commit f4eeaed04e861b95f1f2c911263f2fcaa959c078 ]
Sparse warnings triggered truncating the IDs of some platform device
tables. Unfortunately some of the IDs in the match tables were missed
which breaks audio. The KBL change has been verified to fix audio, the
CML change was not tested as it was found through grepping the broken
changes and found to match the same situation in anticipation that it
should also be fixed.
Fixes: 94efd726b947 ("ASoC: Intel: kbl_da7219_max98357a: shrink platform_id below 20 characters")
Fixes: 24e46fb811e9 ("ASoC: Intel: bxt_da7219_max98357a: shrink platform_id below 20 characters")
Signed-off-by: Curtis Malainey <cujomalainey@chromium.org>
Tested-by: Matt Davis <mattedavis@google.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20210809213544.1682444-1-cujomalainey@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b3d3890ed59ead6c95b4586e32a6adad01716013
Author: Waiman Long <longman@redhat.com>
Date: Tue Jul 20 10:18:28 2021 -0400
cgroup/cpuset: Fix violation of cpuset locking rule
[ Upstream commit 6ba34d3c73674e46d9e126e4f0cee79e5ef2481c ]
The cpuset fields that manage partition root state do not strictly
follow the cpuset locking rule that update to cpuset has to be done
with both the callback_lock and cpuset_mutex held. This is now fixed
by making sure that the locking rule is upheld.
Fixes: 3881b86128d0 ("cpuset: Add an error state to cpuset.sched.partition")
Fixes: 4b842da276a8 ("cpuset: Make CPU hotplug work with partition")
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3f75d4793ca75f2018037bc9e255d36e820e340b
Author: Waiman Long <longman@redhat.com>
Date: Tue Jul 20 10:18:26 2021 -0400
cgroup/cpuset: Miscellaneous code cleanup
[ Upstream commit 0f3adb8a1e5f36e792598c1d77a2cfac9c90a4f9 ]
Use more descriptive variable names for update_prstate(), remove
unnecessary code and fix some typos. There is no functional change.
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit dec410d06ba4e34022c1972312a1b35611c59141
Author: William Breathitt Gray <vilhelm.gray@gmail.com>
Date: Tue Aug 3 21:06:11 2021 +0900
counter: 104-quad-8: Return error when invalid mode during ceiling_write
[ Upstream commit 728246e8f7269ecd35a2c6e6795323e6d8f48db7 ]
The 104-QUAD-8 only has two count modes where a ceiling value makes
sense: Range Limit and Modulo-N. Outside of these two modes, setting a
ceiling value is an invalid operation -- so let's report it as such by
returning -EINVAL.
Fixes: fc069262261c ("counter: 104-quad-8: Add lock guards - generic interface")
Acked-by: Syed Nayyar Waris <syednwaris@gmail.com>
Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Link: https://lore.kernel.org/r/a2147f022829b66839a1db5530a7fada47856847.1627990337.git.vilhelm.gray@gmail.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 56dda6a699bec39a71250e517768aa73985fcfdb
Author: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Date: Thu Aug 5 09:21:10 2021 +0200
arm64: dts: exynos: correct GIC CPU interfaces address range on Exynos7
[ Upstream commit 01c72cad790cb6cd3ccbe4c1402b6cb6c6bbffd0 ]
The GIC-400 CPU interfaces address range is defined as 0x2000-0x3FFF (by
ARM).
Reported-by: Sam Protsenko <semen.protsenko@linaro.org>
Reported-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Fixes: b9024cbc937d ("arm64: dts: Add initial device tree support for exynos7")
Link: https://lore.kernel.org/r/20210805072110.4730-1-krzysztof.kozlowski@canonical.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2ac60cf6a02f1f160b51b23e0fb572b90ef28046
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date: Mon Jul 5 02:05:19 2021 +0300
drm/msm/dpu: make dpu_hw_ctl_clear_all_blendstages clear necessary LMs
[ Upstream commit a41cdb693595ae1904dd793fc15d6954f4295e27 ]
dpu_hw_ctl_clear_all_blendstages() clears settings for the few first LMs
instead of mixers actually used for the CTL. Change it to clear
necessary data, using provided mixer ids.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210704230519.4081467-1-dmitry.baryshkov@linaro.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit cc371f6aa1cbda3b6ba0167d0afd8a8d1ebbba5d
Author: Kuogee Hsieh <khsieh@codeaurora.org>
Date: Wed Aug 4 08:51:01 2021 -0700
drm/msm/dp: update is_connected status base on sink count at dp_pm_resume()
[ Upstream commit e8a767e04dbc7b201cb17ab99dca723a3488b6d4 ]
Currently at dp_pm_resume() is_connected state is decided base on hpd connection
status only. This will put is_connected in wrongly "true" state at the scenario
that dongle attached to DUT but without hmdi cable connecting to it. Fix this
problem by adding read sink count from dongle and decided is_connected state base
on both sink count and hpd connection status.
Changes in v2:
-- remove dp_get_sink_count() cand call drm_dp_read_sink_count()
Changes in v3:
-- delete status local variable from dp_pm_resume()
Changes in v4:
-- delete un necessary comment at dp_pm_resume()
Fixes: d9aa6571b28ba ("drm/msm/dp: check sink_count before update is_connected status")
Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org>
Link: https://lore.kernel.org/r/1628092261-32346-1-git-send-email-khsieh@codeaurora.org
Tested-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3691e5f2d3d54d71278c9908d35279d8a1a0e22a
Author: David Heidelberg <david@ixit.cz>
Date: Tue Jul 6 01:16:41 2021 +0200
drm/msm/mdp4: move HW revision detection to earlier phase
[ Upstream commit 4af4fc92939dc811ef291c0673946555aa4fb71f ]
Fixes if condition, which never worked inside mdp4_kms_init, since
HW detection has been done later in mdp4_hw_init.
Fixes: eb2b47bb9a03 ("drm/msm/mdp4: only use lut_clk on mdp4.2+")
Signed-off-by: David Heidelberg <david@ixit.cz>
Link: https://lore.kernel.org/r/20210705231641.315804-2-david@ixit.cz
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 94b8906dd236e38bec816b256cf0ccc431400039
Author: David Heidelberg <david@ixit.cz>
Date: Tue Jul 6 01:16:40 2021 +0200
drm/msm/mdp4: refactor HW revision detection into read_mdp_hw_revision
[ Upstream commit 4d319afe666b0fc9a9855ba9bdf9ae3710ecf431 ]
Inspired by MDP5 code.
Also use DRM_DEV_INFO for MDP version as MDP5 does.
Cosmetic change: uint32_t -> u32 - checkpatch suggestion.
Signed-off-by: David Heidelberg <david@ixit.cz>
Link: https://lore.kernel.org/r/20210705231641.315804-1-david@ixit.cz
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0f9c7df36db24a23191f1c5094a888cca765e180
Author: Wei Li <liwei391@huawei.com>
Date: Mon Jul 5 21:43:02 2021 +0800
drm/msm: Fix error return code in msm_drm_init()
[ Upstream commit bfddcfe155a2fe448fee0169c5cbc82c7fa73491 ]
When it fail to create crtc_event kthread, it just jump to err_msm_uninit,
while the 'ret' is not updated. So assign the return code before that.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Li <liwei391@huawei.com>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20210705134302.315813-1-liwei391@huawei.com
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 881a8a363b0889a8892d3ff9ac9b28b92a5a3021
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Thu Aug 5 14:26:19 2021 +0300
leds: lgm-sso: Propagate error codes from callee to caller
[ Upstream commit 9cbc861095375793a69858f91f3ac4e817f320f0 ]
The one of the latest change to the driver reveals the problem that
the error codes from callee aren't propagated to the caller of
__sso_led_dt_parse(). Fix this accordingly.
Fixes: 9999908ca1ab ("leds: lgm-sso: Put fwnode in any case during ->probe()")
Fixes: c3987cd2bca3 ("leds: lgm: Add LED controller driver for LGM SoC")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5aa656c92197d2ad07d8dfc062b8c0e828418908
Author: Jose Blanquicet <josebl@microsoft.com>
Date: Thu Aug 5 18:40:36 2021 +0200
selftests/bpf: Fix bpf-iter-tcp4 test to print correctly the dest IP
[ Upstream commit 277b134057036df8c657079ca92c3e5e7d10aeaf ]
Currently, this test is incorrectly printing the destination port in
place of the destination IP.
Fixes: 2767c97765cb ("selftests/bpf: Implement sample tcp/tcp6 bpf_iter programs")
Signed-off-by: Jose Blanquicet <josebl@microsoft.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/20210805164044.527903-1-josebl@microsoft.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2fa4fef6fe49864d335bc1b3f9121105701a5e15
Author: Lukasz Luba <lukasz.luba@arm.com>
Date: Tue Aug 3 11:27:43 2021 +0100
PM: EM: Increase energy calculation precision
[ Upstream commit 7fcc17d0cb12938d2b3507973a6f93fc9ed2c7a1 ]
The Energy Model (EM) provides useful information about device power in
each performance state to other subsystems like: Energy Aware Scheduler
(EAS). The energy calculation in EAS does arithmetic operation based on
the EM em_cpu_energy(). Current implementation of that function uses
em_perf_state::cost as a pre-computed cost coefficient equal to:
cost = power * max_frequency / frequency.
The 'power' is expressed in milli-Watts (or in abstract scale).
There are corner cases when the EAS energy calculation for two Performance
Domains (PDs) return the same value. The EAS compares these values to
choose smaller one. It might happen that this values are equal due to
rounding error. In such scenario, we need better resolution, e.g. 1000
times better. To provide this possibility increase the resolution in the
em_perf_state::cost for 64-bit architectures. The cost of increasing
resolution on 32-bit is pretty high (64-bit division) and is not justified
since there are no new 32bit big.LITTLE EAS systems expected which would
benefit from this higher resolution.
This patch allows to avoid the rounding to milli-Watt errors, which might
occur in EAS energy estimation for each PD. The rounding error is common
for small tasks which have small utilization value.
There are two places in the code where it makes a difference:
1. In the find_energy_efficient_cpu() where we are searching for
best_delta. We might suffer there when two PDs return the same result,
like in the example below.
Scenario:
Low utilized system e.g. ~200 sum_util for PD0 and ~220 for PD1. There
are quite a few small tasks ~10-15 util. These tasks would suffer for
the rounding error. These utilization values are typical when running games
on Android. One of our partners has reported 5..10mA less battery drain
when running with increased resolution.
Some details:
We have two PDs: PD0 (big) and PD1 (little)
Let's compare w/o patch set ('old') and w/ patch set ('new')
We are comparing energy w/ task and w/o task placed in the PDs
a) 'old' w/o patch set, PD0
task_util = 13
cost = 480
sum_util_w/o_task = 215
sum_util_w_task = 228
scale_cpu = 1024
energy_w/o_task = 480 * 215 / 1024 = 100.78 => 100
energy_w_task = 480 * 228 / 1024 = 106.87 => 106
energy_diff = 106 - 100 = 6
(this is equal to 'old' PD1's energy_diff in 'c)')
b) 'new' w/ patch set, PD0
task_util = 13
cost = 480 * 1000 = 480000
sum_util_w/o_task = 215
sum_util_w_task = 228
energy_w/o_task = 480000 * 215 / 1024 = 100781
energy_w_task = 480000 * 228 / 1024 = 106875
energy_diff = 106875 - 100781 = 6094
(this is not equal to 'new' PD1's energy_diff in 'd)')
c) 'old' w/o patch set, PD1
task_util = 13
cost = 160
sum_util_w/o_task = 283
sum_util_w_task = 293
scale_cpu = 355
energy_w/o_task = 160 * 283 / 355 = 127.55 => 127
energy_w_task = 160 * 296 / 355 = 133.41 => 133
energy_diff = 133 - 127 = 6
(this is equal to 'old' PD0's energy_diff in 'a)')
d) 'new' w/ patch set, PD1
task_util = 13
cost = 160 * 1000 = 160000
sum_util_w/o_task = 283
sum_util_w_task = 293
scale_cpu = 355
energy_w/o_task = 160000 * 283 / 355 = 127549
energy_w_task = 160000 * 296 / 355 = 133408
energy_diff = 133408 - 127549 = 5859
(this is not equal to 'new' PD0's energy_diff in 'b)')
2. Difference in the 6% energy margin filter at the end of
find_energy_efficient_cpu(). With this patch the margin comparison also
has better resolution, so it's possible to have better task placement
thanks to that.
Fixes: 27871f7a8a341ef ("PM: Introduce an Energy Model management framework")
Reported-by: CCJ Yeh <CCj.Yeh@mediatek.com>
Reviewed-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8d9a2021b182a4ca982e54bd636d9eaa03c68454
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri Aug 6 03:20:08 2021 +0300
net: dsa: don't disable multicast flooding to the CPU even without an IGMP querier
[ Upstream commit c73c57081b3d59aa99093fbedced32ea02620cd3 ]
Commit 08cc83cc7fd8 ("net: dsa: add support for BRIDGE_MROUTER
attribute") added an option for users to turn off multicast flooding
towards the CPU if they turn off the IGMP querier on a bridge which
already has enslaved ports (echo 0 > /sys/class/net/br0/bridge/multicast_router).
And commit a8b659e7ff75 ("net: dsa: act as passthrough for bridge port flags")
simply papered over that issue, because it moved the decision to flood
the CPU with multicast (or not) from the DSA core down to individual drivers,
instead of taking a more radical position then.
The truth is that disabling multicast flooding to the CPU is simply
something we are not prepared to do now, if at all. Some reasons:
- ICMP6 neighbor solicitation messages are unregistered multicast
packets as far as the bridge is concerned. So if we stop flooding
multicast, the outside world cannot ping the bridge device's IPv6
link-local address.
- There might be foreign interfaces bridged with our DSA switch ports
(sending a packet towards the host does not necessarily equal
termination, but maybe software forwarding). So if there is no one
interested in that multicast traffic in the local network stack, that
doesn't mean nobody is.
- PTP over L4 (IPv4, IPv6) is multicast, but is unregistered as far as
the bridge is concerned. This should reach the CPU port.
- The switch driver might not do FDB partitioning. And since we don't
even bother to do more fine-grained flood disabling (such as "disable
flooding _from_port_N_ towards the CPU port" as opposed to "disable
flooding _from_any_port_ towards the CPU port"), this breaks standalone
ports, or even multiple bridges where one has an IGMP querier and one
doesn't.
Reverting the logic makes all of the above work.
Fixes: a8b659e7ff75 ("net: dsa: act as passthrough for bridge port flags")
Fixes: 08cc83cc7fd8 ("net: dsa: add support for BRIDGE_MROUTER attribute")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3e409ec9b1f1c161427ee8b3da44025e5d17ee82
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri Aug 6 03:20:07 2021 +0300
net: dsa: mt7530: remove the .port_set_mrouter implementation
[ Upstream commit cbbf09b5771e6e9da268bc0d2fb6e428afa787bc ]
DSA's idea of optimizing out multicast flooding to the CPU port leaves
quite a few holes open, so it should be reverted.
The mt7530 driver is the only new driver which added a .port_set_mrouter
implementation after the reorg from commit a8b659e7ff75 ("net: dsa: act
as passthrough for bridge port flags"), so it needs to be reverted
separately so that the other revert commit can go a bit further down the
git history.
Fixes: 5a30833b9a16 ("net: dsa: mt7530: support MDB and bridge flag operations")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6fb8c4fd03656f84c04b43de2d1eb2bcb365af51
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Fri Aug 6 03:20:06 2021 +0300
net: dsa: stop syncing the bridge mcast_router attribute at join time
[ Upstream commit 7df4e7449489d82cee6813dccbb4ae4f3f26ef7b ]
Qingfang points out that when a bridge with the default settings is
created and a port joins it:
ip link add br0 type bridge
ip link set swp0 master br0
DSA calls br_multicast_router() on the bridge to see if the br0 device
is a multicast router port, and if it is, it enables multicast flooding
to the CPU port, otherwise it disables it.
If we look through the multicast_router_show() sysfs or at the
IFLA_BR_MCAST_ROUTER netlink attribute, we see that the default mrouter
attribute for the bridge device is "1" (MDB_RTR_TYPE_TEMP_QUERY).
However, br_multicast_router() will return "0" (MDB_RTR_TYPE_DISABLED),
because an mrouter port in the MDB_RTR_TYPE_TEMP_QUERY state may not be
actually _active_ until it receives an actual IGMP query. So, the
br_multicast_router() function should really have been called
br_multicast_router_active() perhaps.
When/if an IGMP query is received, the bridge device will transition via
br_multicast_mark_router() into the active state until the
ip4_mc_router_timer expires after an multicast_querier_interval.
Of course, this does not happen if the bridge is created with an
mcast_router attribute of "2" (MDB_RTR_TYPE_PERM).
The point is that in lack of any IGMP query messages, and in the default
bridge configuration, unregistered multicast packets will not be able to
reach the CPU port through flooding, and this breaks many use cases
(most obviously, IPv6 ND, with its ICMP6 neighbor solicitation multicast
messages).
Leave the multicast flooding setting towards the CPU port down to a driver
level decision.
Fixes: 010e269f91be ("net: dsa: sync up switchdev objects and port attributes when joining the bridge")
Reported-by: DENG Qingfang <dqfext@gmail.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e2645f3e6a51777ebe5c2ad2430a922687e0d046
Author: Vignesh Raghavendra <vigneshr@ti.com>
Date: Fri Aug 6 01:55:31 2021 +0300
net: ti: am65-cpsw-nuss: fix RX IRQ state after .ndo_stop()
[ Upstream commit 47bfc4d128dedd9e828e33b70b87b591a6d59edf ]
On TI K3 am64x platform the issue with RX IRQ is observed - it's become
disabled forever after .ndo_stop(). The K3 CPSW driver manipulates RX IRQ
by using standard Linux enable_irq()/disable_irq_nosync() API as there is
no IRQ enable/disable options in CPSW HW itself, as result during
.ndo_stop() following sequence happens
phy_stop()
teardown TX/RX channels
wait for TX tdown complete
napi_disable(TX)
clean up TX channels
(a)
napi_disable(RX)
At point (a) it's not possible to predict if RX IRQ was triggered or not.
if RX IRQ was triggered then it also not possible to definitely say if RX
NAPI was run or only scheduled and immediately canceled by
napi_disable(RX). Actually the last case causes RX IRQ to be permanently
disabled.
Another observed issue is that RX IRQ enable counter become unbalanced if
(gro_flush_timeout =! 0) while (napi_defer_hard_irqs == 0):
Unbalanced enable for IRQ 44
WARNING: CPU: 0 PID: 10 at ../kernel/irq/manage.c:776 __enable_irq+0x38/0x80
__enable_irq+0x38/0x80
enable_irq+0x54/0xb0
am65_cpsw_nuss_rx_poll+0x2f4/0x368
__napi_poll+0x34/0x1b8
net_rx_action+0xe4/0x220
_stext+0x11c/0x284
run_ksoftirqd+0x4c/0x60
To avoid above issues introduce flag indicating if RX was actually disabled
before enabling it in am65_cpsw_nuss_rx_poll() and restore RX IRQ state in
.ndo_open()
Fixes: 4f7cce272403 ("net: ethernet: ti: am65-cpsw: add support for am64x cpsw3g")
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7a3569fc93f2a8cf9254161f4cc3b1b157c35885
Author: Robert Foss <robert.foss@linaro.org>
Date: Thu Aug 5 20:50:39 2021 +0200
drm: bridge: it66121: Check drm_bridge_attach retval
[ Upstream commit bd03d440e2589b9c328f40ce60203adf2b19d2e2 ]
The return value of drm_bridge_attach() is ignored during
the it66121_bridge_attach() call, which is incorrect.
Fixes: 988156dc2fc9 ("drm: bridge: add it66121 driver")
Signed-off-by: Robert Foss <robert.foss@linaro.org>
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210805185039.402178-1-robert.foss@linaro.org
Link: https://patchwork.freedesktop.org/patch/msgid/20210805185039.402178-1-robert.foss@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e06cd6d88b8aaf3d35d6b4cbf8491f133c608b4a
Author: Alex Elder <elder@linaro.org>
Date: Wed Aug 4 16:02:14 2021 -0500
arm64: dts: qcom: sm8350: fix IPA interconnects
[ Upstream commit 84173ca359787abd720d150d3d0d7edabf9db46c ]
There should only be two interconnects defined for IPA on the
QUalcomm SM8350 SoC. The names should also match those specified by
the IPA Device Tree binding.
Fixes: f11d3e7da32e ("arm64: dts: qcom: sm8350: add IPA information")
Signed-off-by: Alex Elder <elder@linaro.org>
Link: https://lore.kernel.org/r/20210804210214.1891755-5-elder@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 331e9f9a19e5501e19aa4cb32e1a6adb5ddd6798
Author: Sibi Sankar <sibis@codeaurora.org>
Date: Thu Jul 29 23:34:44 2021 +0530
arm64: dts: qcom: sc7280: Fixup the cpufreq node
[ Upstream commit 11e03d692101e484df9322f892a8b6e111a82bfd ]
Fixup the register regions used by the cpufreq node on SC7280 SoC to
support per core L3 DCVS.
Fixes: 7dbd121a2c58 ("arm64: dts: qcom: sc7280: Add cpufreq hw node")
Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/1627581885-32165-4-git-send-email-sibis@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5c25501cfe7acec284db2676c831b6c2353180f3
Author: Colin Ian King <colin.king@canonical.com>
Date: Wed Aug 4 16:09:51 2021 +0100
Bluetooth: increase BTNAMSIZ to 21 chars to fix potential buffer overflow
[ Upstream commit 713baf3dae8f45dc8ada4ed2f5fdcbf94a5c274d ]
An earlier commit replaced using batostr to using %pMR sprintf for the
construction of session->name. Static analysis detected that this new
method can use a total of 21 characters (including the trailing '\0')
so we need to increase the BTNAMSIZ from 18 to 21 to fix potential
buffer overflows.
Addresses-Coverity: ("Out-of-bounds write")
Fixes: fcb73338ed53 ("Bluetooth: Use %pMR in sprintf/seq_printf instead of batostr")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1e923017e26f075eef764dc129c17de4f77092ee
Author: Sven Eckelmann <sven@narfation.org>
Date: Mon Aug 2 18:24:44 2021 +0200
debugfs: Return error during {full/open}_proxy_open() on rmmod
[ Upstream commit 112cedc8e600b668688eb809bf11817adec58ddc ]
If a kernel module gets unloaded then it printed report about a leak before
commit 275678e7a9be ("debugfs: Check module state before warning in
{full/open}_proxy_open()"). An additional check was added in this commit to
avoid this printing. But it was forgotten that the function must return an
error in this case because it was not actually opened.
As result, the systems started to crash or to hang when a module was
unloaded while something was trying to open a file.
Fixes: 275678e7a9be ("debugfs: Check module state before warning in {full/open}_proxy_open()")
Cc: Taehee Yoo <ap420073@gmail.com>
Reported-by: Mário Lopes <ml@simonwunderlich.de>
Signed-off-by: Sven Eckelmann <sven@narfation.org>
Link: https://lore.kernel.org/r/20210802162444.7848-1-sven@narfation.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 203baf2a84d30b468ae80868344e7685b8f4124b
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Thu Aug 5 14:36:12 2021 +0300
net: dsa: tag_sja1105: optionally build as module when switch driver is module if PTP is enabled
[ Upstream commit f8b17a0bd96065e4511858689916bb729dbb881b ]
TX timestamps are sent by SJA1110 as Ethernet packets containing
metadata, so they are received by the tagging driver but must be
processed by the switch driver - the one that is stateful since it
keeps the TX timestamp queue.
This means that there is an sja1110_process_meta_tstamp() symbol
exported by the switch driver which is called by the tagging driver.
There is a shim definition for that function when the switch driver is
not compiled, which does nothing, but that shim is not effective when
the tagging protocol driver is built-in and the switch driver is a
module, because built-in code cannot call symbols exported by modules.
So add an optional dependency between the tagger and the switch driver,
if PTP support is enabled in the switch driver. If PTP is not enabled,
sja1110_process_meta_tstamp() will translate into the shim "do nothing
with these meta frames" function.
Fixes: 566b18c8b752 ("net: dsa: sja1105: implement TX timestamping for SJA1110")
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 15a6a8a56c990859d1e3c59c99bd329afa0b24fe
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
Date: Mon Jul 19 20:14:47 2021 +0300
net: dsa: build tag_8021q.c as part of DSA core
[ Upstream commit 8b6e638b4be2ad77f61fb93b4e1776c6ccc2edab ]
Upcoming patches will add tag_8021q related logic to switch.c and
port.c, in order to allow it to make use of cross-chip notifiers.
In addition, a struct dsa_8021q_context *ctx pointer will be added to
struct dsa_switch.
It seems fairly low-reward to #ifdef the *ctx from struct dsa_switch and
to provide shim implementations of the entire tag_8021q.c calling
surface (not even clear what to do about the tag_8021q cross-chip
notifiers to avoid compiling them). The runtime overhead for switches
which don't use tag_8021q is fairly small because all helpers will check
for ds->tag_8021q_ctx being a NULL pointer and stop there.
So let's make it part of dsa_core.o.
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 314560f407211d8f3ed2fc4021bf9c93da1711bd
Author: Stephan Gerhold <stephan@gerhold.net>
Date: Mon Jul 12 15:57:03 2021 +0200
soc: qcom: smsm: Fix missed interrupts if state changes while masked
[ Upstream commit e3d4571955050736bbf3eda0a9538a09d9fcfce8 ]
The SMSM driver detects interrupt edges by tracking the last state
it has seen (and has triggered the interrupt handler for). This works
fine, but only if the interrupt does not change state while masked.
For example, if an interrupt is unmasked while the state is HIGH,
the stored last_value for that interrupt might still be LOW. Then,
when the remote processor triggers smsm_intr() we assume that nothing
has changed, even though the state might have changed from HIGH to LOW.
Attempt to fix this by checking the current remote state before
unmasking an IRQ. Use atomic operations to avoid the interrupt handler
from interfering with the unmask function.
This fixes modem crashes in some edge cases with the BAM-DMUX driver.
Specifically, the BAM-DMUX interrupt handler is not called for the
HIGH -> LOW smsm state transition if the BAM-DMUX driver is loaded
(and therefore unmasks the interrupt) after the modem was already started:
qcom-q6v5-mss 4080000.remoteproc: fatal error received: a2_task.c:3188:
Assert FALSE failed: A2 DL PER deadlock timer expired waiting for Apps ACK
Fixes: c97c4090ff72 ("soc: qcom: smsm: Add driver for Qualcomm SMSM")
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210712135703.324748-2-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 598d745a827d6155b9106964f9a9cc432f4e044a
Author: Matthew Cover <werekraken@gmail.com>
Date: Fri Jul 30 17:56:32 2021 -0700
bpf, samples: Add missing mprog-disable to xdp_redirect_cpu's optstring
[ Upstream commit 34ad6d9d8c27293e1895b448af7d6cf5d351ad8d ]
Commit ce4dade7f12a ("samples/bpf: xdp_redirect_cpu: Load a eBPF program
on cpumap") added the following option, but missed adding it to optstring:
- mprog-disable: disable loading XDP program on cpumap entries
Fix it and add the missing option character.
Fixes: ce4dade7f12a ("samples/bpf: xdp_redirect_cpu: Load a eBPF program on cpumap")
Signed-off-by: Matthew Cover <matthew.cover@stackpath.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Link: https://lore.kernel.org/bpf/20210731005632.13228-1-matthew.cover@stackpath.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ef0d6ba3159e81c30ac35792ffde845d0c345cb3
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Thu Jul 29 16:49:10 2021 +0200
PCI: PM: Enable PME if it can be signaled from D3cold
[ Upstream commit 0e00392a895c95c6d12d42158236c8862a2f43f2 ]
PME signaling is only enabled by __pci_enable_wake() if the target
device can signal PME from the given target power state (to avoid
pointless reconfiguration of the device), but if the hierarchy above
the device goes into D3cold, the device itself will end up in D3cold
too, so if it can signal PME from D3cold, it should be enabled to
do so in __pci_enable_wake().
[Note that if the device does not end up in D3cold and it cannot
signal PME from the original target power state, it will not signal
PME, so in that case the behavior does not change.]
Link: https://lore.kernel.org/linux-pm/3149540.aeNJFYEL58@kreacher/
Fixes: 5bcc2fb4e815 ("PCI PM: Simplify PCI wake-up code")
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reported-by: Utkarsh H Patel <utkarsh.h.patel@intel.com>
Reported-by: Koba Ko <koba.ko@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8082da1e1f97c0f40ab24cd433bc63f0f77ceb98
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Thu Jul 29 17:54:28 2021 +0200
PCI: PM: Avoid forcing PCI_D0 for wakeup reasons inconsistently
[ Upstream commit da9f2150684ea684a7ddd6d7f0e38b2bdf43dcd8 ]
It is inconsistent to return PCI_D0 from pci_target_state() instead
of the original target state if 'wakeup' is true and the device
cannot signal PME from D0.
This only happens when the device cannot signal PME from the original
target state and any shallower power states (including D0) and that
case is effectively equivalent to the one in which PME singaling is
not supported at all. Since the original target state is returned in
the latter case, make the function do that in the former one too.
Link: https://lore.kernel.org/linux-pm/3149540.aeNJFYEL58@kreacher/
Fixes: 666ff6f83e1d ("PCI/PM: Avoid using device_may_wakeup() for runtime PM")
Reported-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Reported-by: Utkarsh H Patel <utkarsh.h.patel@intel.com>
Reported-by: Koba Ko <koba.ko@canonical.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit bf90444b28337786c04b9468e4e8d6ccc7fe1724
Author: CK Hu <ck.hu@mediatek.com>
Date: Thu Jul 29 09:05:49 2021 +0200
soc: mmsys: mediatek: add mask to mmsys routes
[ Upstream commit 7bdcead7a75e3eab5e711c2da78c2a0360e7f2a4 ]
SOUT has many bits and need to be cleared before set new value.
Write only could do the clear, but for MOUT, it clears bits that
should not be cleared. So use a mask to reset only the needed bits.
this fixes HDMI issues on MT7623/BPI-R2 since 5.13
Fixes: 440147639ac7 ("soc: mediatek: mmsys: Use an array for setting the routing registers")
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Signed-off-by: CK Hu <ck.hu@mediatek.com>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Reviewed-by: Hsin-Yi Wang <hsinyi@chromium.org>
Link: https://lore.kernel.org/r/20210729070549.5514-1-linux@fw-web.de
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9f6d8514257aa320e98bf97e15cbfde36c91090e
Author: Mansur Alisha Shaik <mansur@codeaurora.org>
Date: Tue Jul 6 18:21:22 2021 +0200
media: venus: helper: do not set constrained parameters for UBWC
[ Upstream commit 1ac61faf6ebbce59fccbb53d7faf25576e9897ab ]
Plane constraints firmware interface is to override the default
alignment for a given color format. By default venus hardware has
alignments as 128x32, but NV12 was defined differently to meet
various usecases. Compressed NV12 has always been aligned as 128x32,
hence not needed to override the default alignment.
Fixes: bc28936bbba9 ("media: venus: helpers, hfi, vdec: Set actual plane constraints to FW")
Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit de9fdb6070eab269d736126b941bd57056f8eaae
Author: Colin Ian King <colin.king@canonical.com>
Date: Fri Jul 9 14:30:25 2021 +0200
media: venus: venc: Fix potential null pointer dereference on pointer fmt
[ Upstream commit 09ea9719a423fc675d40dd05407165e161ea0c48 ]
Currently the call to find_format can potentially return a NULL to
fmt and the nullpointer is later dereferenced on the assignment of
pixmp->num_planes = fmt->num_planes. Fix this by adding a NULL pointer
check and returning NULL for the failure case.
Addresses-Coverity: ("Dereference null return")
Fixes: aaaa93eda64b ("[media] media: venus: venc: add video encoder files")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 157e1bcf4097d96936c54aadd9b882dd930b47a8
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Wed Jul 7 09:45:17 2021 +0200
media: venus: hfi: fix return value check in sys_get_prop_image_version()
[ Upstream commit 331e06bbde5856059b7a6bb183f12878ed4decb1 ]
In case of error, the function qcom_smem_get() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Fixes: d566e78dd6af ("media: venus : hfi: add venus image info into smem")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Stanimir Varbanov <stanimir.varbanov@linaro.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f2e2c4d132b3c2814f9ac1b027f7c981cace63ed
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date: Wed Apr 7 16:37:33 2021 +0200
media: omap3isp: Fix missing unlock in isp_subdev_notifier_complete()
[ Upstream commit 0368e7d2cd84a90d0518753fac33795e13df553f ]
Add the missing unlock before return from function
isp_subdev_notifier_complete() in the init error
handling case.
Fixes: ba689d933361 ("media: omap3isp: Acquire graph mutex for graph traversal")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 714ab54f388aa93b7933a6488fb88e51dc9cebd2
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date: Wed Jul 7 11:34:09 2021 +0200
media: em28xx-input: fix refcount bug in em28xx_usb_disconnect
[ Upstream commit 6fa54bc713c262e1cfbc5613377ef52280d7311f ]
If em28xx_ir_init fails, it would decrease the refcount of dev. However,
in the em28xx_ir_fini, when ir is NULL, it goes to ref_put and decrease
the refcount of dev. This will lead to a refcount bug.
Fix this bug by removing the kref_put in the error handling code
of em28xx_ir_init.
refcount_t: underflow; use-after-free.
WARNING: CPU: 0 PID: 7 at lib/refcount.c:28 refcount_warn_saturate+0x18e/0x1a0 lib/refcount.c:28
Modules linked in:
CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.13.0 #3
Workqueue: usb_hub_wq hub_event
RIP: 0010:refcount_warn_saturate+0x18e/0x1a0 lib/refcount.c:28
Call Trace:
kref_put.constprop.0+0x60/0x85 include/linux/kref.h:69
em28xx_usb_disconnect.cold+0xd7/0xdc drivers/media/usb/em28xx/em28xx-cards.c:4150
usb_unbind_interface+0xbf/0x3a0 drivers/usb/core/driver.c:458
__device_release_driver drivers/base/dd.c:1201 [inline]
device_release_driver_internal+0x22a/0x230 drivers/base/dd.c:1232
bus_remove_device+0x108/0x160 drivers/base/bus.c:529
device_del+0x1fe/0x510 drivers/base/core.c:3540
usb_disable_device+0xd1/0x1d0 drivers/usb/core/message.c:1419
usb_disconnect+0x109/0x330 drivers/usb/core/hub.c:2221
hub_port_connect drivers/usb/core/hub.c:5151 [inline]
hub_port_connect_change drivers/usb/core/hub.c:5440 [inline]
port_event drivers/usb/core/hub.c:5586 [inline]
hub_event+0xf81/0x1d40 drivers/usb/core/hub.c:5668
process_one_work+0x2c9/0x610 kernel/workqueue.c:2276
process_scheduled_works kernel/workqueue.c:2338 [inline]
worker_thread+0x333/0x5b0 kernel/workqueue.c:2424
kthread+0x188/0x1d0 kernel/kthread.c:319
ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295
Reported-by: Dongliang Mu <mudongliangabcd@gmail.com>
Fixes: ac5688637144 ("media: em28xx: Fix possible memory leak of em28xx struct")
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a0f0e72ed1b3f2882fc4a10516bf6dc4da4f04ce
Author: Hans de Goede <hdegoede@redhat.com>
Date: Sun Feb 21 12:52:08 2021 +0100
leds: trigger: audio: Add an activate callback to ensure the initial brightness is set
[ Upstream commit 64f67b5240db79eceb0bd57dae8e591fd3103ba0 ]
Some 2-in-1s with a detachable (USB) keyboard(dock) have mute-LEDs in
the speaker- and/or mic-mute keys on the keyboard.
Examples of this are the Lenovo Thinkpad10 tablet (with its USB kbd-dock)
and the HP x2 10 series.
The detachable nature of these keyboards means that the keyboard and
thus the mute LEDs may show up after the user (or userspace restoring
old mixer settings) has muted the speaker and/or mic.
Current LED-class devices with a default_trigger of "audio-mute" or
"audio-micmute" initialize the brightness member of led_classdev with
ledtrig_audio_get() before registering the LED.
This makes the software state after attaching the keyboard match the
actual audio mute state, e.g. cat /sys/class/leds/foo/brightness will
show the right value.
But before this commit nothing was actually calling the led_classdev's
brightness_set[_blocking] callback so the value returned by
ledtrig_audio_get() was never actually being sent to the hw, leading
to the mute LEDs staying in their default power-on state, after
attaching the keyboard, even if ledtrig_audio_get() returned a different
state.
This could be fixed by having the individual LED drivers call
brightness_set[_blocking] themselves after registering the LED,
but this really is something which should be done by a led-trigger
activate callback.
Add an activate callback for this, fixing the issue of the
mute LEDs being out of sync after (re)attaching the keyboard.
Cc: Takashi Iwai <tiwai@suse.de>
Fixes: faa2541f5b1a ("leds: trigger: Introduce audio mute LED trigger")
Reviewed-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0425d56d7e1637b49f39a93a0aea461143f99f2c
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Sat May 29 14:19:34 2021 +0300
leds: rt8515: Put fwnode in any case during ->probe()
[ Upstream commit 8aa41952ef245449df79100e1942b5e6288b098a ]
fwnode_get_next_available_child_node() bumps a reference counting of
a returned variable. We have to balance it whenever we return to
the caller.
Fixes: e1c6edcbea13 ("leds: rt8515: Add Richtek RT8515 LED driver")
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7feddda8e719c824db03ef4ceec5811f76920152
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Sat May 29 14:19:33 2021 +0300
leds: lt3593: Put fwnode in any case during ->probe()
[ Upstream commit 7e1baaaa2407a642ea19b58e214fab9a69cda1d7 ]
device_get_next_child_node() bumps a reference counting of a returned variable.
We have to balance it whenever we return to the caller.
Fixes: 8cd7d6daba93 ("leds: lt3593: Add device tree probing glue")
Cc: Daniel Mack <daniel@zonque.org>
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 66d33719d8f076627327c8eb9264960031cdb8a3
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Sat May 29 14:19:27 2021 +0300
leds: lgm-sso: Don't spam logs when probe is deferred
[ Upstream commit 1ed4d05e0a0b23ba15e0affcff4008dd537ae3ee ]
When requesting GPIO line the probe can be deferred.
In such case don't spam logs with an error message.
This can be achieved by switching to dev_err_probe().
Fixes: c3987cd2bca3 ("leds: lgm: Add LED controller driver for LGM SoC")
Cc: Amireddy Mallikarjuna reddy <mallikarjunax.reddy@linux.intel.com>
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 129d481c9cc0fbb0145432a674ad84c09a86372e
Author: Andy Shevchenko <andy.shevchenko@gmail.com>
Date: Sat May 29 14:19:26 2021 +0300
leds: lgm-sso: Put fwnode in any case during ->probe()
[ Upstream commit 9999908ca1abee7aa518a4f6a3739517c137acbf ]
fwnode_get_next_child_node() bumps a reference counting of a returned variable.
We have to balance it whenever we return to the caller.
All the same in fwnode_for_each_child_node() case.
Fixes: c3987cd2bca3 ("leds: lgm: Add LED controller driver for LGM SoC")
Cc: Amireddy Mallikarjuna reddy <mallikarjunax.reddy@linux.intel.com>
Signed-off-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3cae4290ac5f1b7a951b419d102e0a6c5219be97
Author: Sergey Shtylyov <s.shtylyov@omp.ru>
Date: Sun May 30 22:13:45 2021 +0300
i2c: highlander: add IRQ check
[ Upstream commit f16a3bb69aa6baabf8f0aca982c8cf21e2a4f6bc ]
The driver is written as if platform_get_irq() returns 0 on errors (while
actually it returns a negative error code), blithely passing these error
codes to request_irq() (which takes *unsigned* IRQ #) -- which fails with
-EINVAL. Add the necessary error check to the pre-existing *if* statement
forcing the driver into the polling mode...
Fixes: 4ad48e6ab18c ("i2c: Renesas Highlander FPGA SMBus support")
Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e383f1804a3b4f7a7279b5b33aca9a7ff1d4a12a
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date: Thu Jul 22 17:58:16 2021 +0800
net/mlx5: Fix missing return value in mlx5_devlink_eswitch_inline_mode_set()
[ Upstream commit bcd68c04c7692416206414dc8971730aa140eba7 ]
The return value is missing in this code scenario, add the return value
'0' to the return value 'err'.
Eliminate the follow smatch warning:
drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c:3083
mlx5_devlink_eswitch_inline_mode_set() warn: missing error code 'err'.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Fixes: 8e0aa4bc959c ("net/mlx5: E-switch, Protect eswitch mode changes")
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5f06ca1b7a664458ed24365cb269b562759e057e
Author: Biju Das <biju.das.jz@bp.renesas.com>
Date: Wed Jul 21 19:06:32 2021 +0100
arm64: dts: renesas: hihope-rzg2-ex: Add EtherAVB internal rx delay
[ Upstream commit c96ca5604a889a142d6b60889cc6da48498806e9 ]
Hihope boards use Realtek PHY. From the very beginning it use only
tx delays. However the phy driver commit bbc4d71d63549bcd003
("net: phy: realtek: fix rtl8211e rx/tx delay config") introduced
NFS mount failure. Now it needs rx delay inaddition to tx delay
for NFS mount to work. This patch fixes NFS mount failure issue
by adding MAC internal rx delay.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Fixes: bbc4d71d63549bcd ("net: phy: realtek: fix rtl8211e rx/tx delay config")
Link: https://lore.kernel.org/r/20210721180632.15080-1-biju.das.jz@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d75d6b94aa32692b9ae982206327721a0e650fba
Author: Quentin Monnet <quentin@isovalent.com>
Date: Thu Jul 29 17:20:24 2021 +0100
tools: Free BTF objects at various locations
[ Upstream commit 369e955b3d1c12f6ec2e51a95911bb80ada55d79 ]
Make sure to call btf__free() (and not simply free(), which does not
free all pointers stored in the struct) on pointers to struct btf
objects retrieved at various locations.
These were found while updating the calls to btf__get_from_id().
Fixes: 999d82cbc044 ("tools/bpf: enhance test_btf file testing to test func info")
Fixes: 254471e57a86 ("tools/bpf: bpftool: add support for func types")
Fixes: 7b612e291a5a ("perf tools: Synthesize PERF_RECORD_* for loaded BPF programs")
Fixes: d56354dc4909 ("perf tools: Save bpf_prog_info and BTF of new BPF programs")
Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command")
Fixes: fa853c4b839e ("perf stat: Enable counting events for BPF programs")
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210729162028.29512-5-quentin@isovalent.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3d79bc7e88a22371df575bb61fa2e18c61e08c58
Author: Quentin Monnet <quentin@isovalent.com>
Date: Thu Jul 29 17:20:21 2021 +0100
libbpf: Return non-null error on failures in libbpf_find_prog_btf_id()
[ Upstream commit 6d2d73cdd673d493f9f3751188757129b1d23fb7 ]
Variable "err" is initialised to -EINVAL so that this error code is
returned when something goes wrong in libbpf_find_prog_btf_id().
However, a recent change in the function made use of the variable in
such a way that it is set to 0 if retrieving linear information on the
program is successful, and this 0 value remains if we error out on
failures at later stages.
Let's fix this by setting err to -EINVAL later in the function.
Fixes: e9fc3ce99b34 ("libbpf: Streamline error reporting for high-level APIs")
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210729162028.29512-2-quentin@isovalent.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b3bf0743a6cc4667931fae6551751ec23ed487d2
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Tue Jul 27 18:01:32 2021 +0300
lib/test_scanf: Handle n_bits == 0 in random tests
[ Upstream commit fe8e3ee0d588566c1f44f28a555042ef50eba491 ]
UBSAN reported (via LKP)
[ 11.021349][ T1] UBSAN: shift-out-of-bounds in lib/test_scanf.c:275:51
[ 11.022782][ T1] shift exponent 32 is too large for 32-bit type 'unsigned int'
When n_bits == 0, the shift is out of range. Switch code to use GENMASK
to handle this case.
Fixes: 50f530e176ea ("lib: test_scanf: Add tests for sscanf number conversion")
Reported-by: kernel test robot <oliver.sang@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/20210727150132.28920-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 148bef1825ae82114a40c759d738ae243c29499d
Author: Luben Tuikov <luben.tuikov@amd.com>
Date: Wed Jul 28 11:07:03 2021 -0400
drm/amd/pm: Fix a bug in semaphore double-lock
[ Upstream commit 544dcd74b7093ad4befac99b11d90331aa73348e ]
Fix a bug in smu_cmn_send_msg_without_waiting() in
that this function does not need to take the
smu->message_lock mutex in order to send a message
down to the SMU. The mutex is acquired by the
caller of this function instead.
Cc: Alex Deucher <Alexander.Deucher@amd.com>
Cc: Changfeng Zhu <Changfeng.Zhu@amd.com>
Cc: Huang Rui <ray.huang@amd.com>
Fixes: 5810323ba69289 ("drm/amd/pm: Fix a bug communicating with the SMU (v5)")
Signed-off-by: Luben Tuikov <luben.tuikov@amd.com>
Reviewed-by: Alex Deucher <Alexander.Deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d589ff1e808f0fe3ce2e790c042bd98c29a717c6
Author: Tedd Ho-Jeong An <tedd.an@intel.com>
Date: Mon Jul 26 13:22:36 2021 -0700
Bluetooth: mgmt: Fix wrong opcode in the response for add_adv cmd
[ Upstream commit a25fca4d3c18766b6f7a3c95fa8faec23ef464c5 ]
This patch fixes the MGMT add_advertising command repsones with the
wrong opcode when it is trying to return the not supported error.
Fixes: cbbdfa6f33198 ("Bluetooth: Enable controller RPA resolution using Experimental feature")
Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit fba3b4fb4a823d84ab89a376d879e85fde9423a8
Author: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Date: Tue Mar 23 02:09:53 2021 +0200
drm: rcar-du: Don't put reference to drm_device in rcar_du_remove()
[ Upstream commit c29b6b0b126e9ee69a5d6339475e831a149295bd ]
The reference to the drm_device that was acquired by
devm_drm_dev_alloc() is released automatically by the devres
infrastructure. It must not be released manually, as that causes a
reference underflow..
Fixes: ea6aae151887 ("drm: rcar-du: Embed drm_device in rcar_du_device")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1eaee3960114d3889f658e54006284a58d709f41
Author: Leon Romanovsky <leon@kernel.org>
Date: Wed Jul 28 10:33:45 2021 +0300
net: ti: am65-cpsw-nuss: fix wrong devlink release order
[ Upstream commit acf34954efd17d4f65c7bb3e614381e6afc33222 ]
The commit that introduced devlink support released devlink resources in
wrong order, that made an unwind flow to be asymmetrical. In addition,
the am65-cpsw-nuss used internal to devlink core field - registered.
In order to fix the unwind flow and remove such access to the
registered field, rewrite the code to call devlink_port_unregister only
on registered ports.
Fixes: 58356eb31d60 ("net: ti: am65-cpsw-nuss: Add devlink support")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 082ef18abc0e42261a6ed4bc97bbffdd0cf1bff7
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Tue Jul 27 19:35:30 2021 +0300
net: cipso: fix warnings in netlbl_cipsov4_add_std
[ Upstream commit 8ca34a13f7f9b3fa2c464160ffe8cc1a72088204 ]
Syzbot reported warning in netlbl_cipsov4_add(). The
problem was in too big doi_def->map.std->lvl.local_size
passed to kcalloc(). Since this value comes from userpace there is
no need to warn if value is not correct.
The same problem may occur with other kcalloc() calls in
this function, so, I've added __GFP_NOWARN flag to all
kcalloc() calls there.
Reported-and-tested-by: syzbot+cdd51ee2e6b0b2e18c0d@syzkaller.appspotmail.com
Fixes: 96cb8e3313c7 ("[NetLabel]: CIPSOv4 and Unlabeled packet integration")
Acked-by: Paul Moore <paul@paul-moore.com>
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4b1bfdfb26f17eb4e3420f56111d41c914e5e9ad
Author: Marek Vasut <marex@denx.de>
Date: Mon Jun 21 00:49:46 2021 +0200
drm: mxsfb: Clear FIFO_CLEAR bit
[ Upstream commit 5e23c98178eb1a2cdb7c4fee9a39baf8cabf282d ]
Make sure the FIFO_CLEAR bit is latched in when configuring the
controller, so that the FIFO is really cleared. And then clear
the FIFO_CLEAR bit, since it is not self-clearing.
Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Daniel Abrecht <public@danielabrecht.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Stefan Agner <stefan@agner.ch>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Tested-by: Jagan Teki <jagan@amarulasolutions.com> # i.Core MX8MM
Acked-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210620224946.189524-1-marex@denx.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 539da3d1a784ee1442e6f56c4b80ac1bdfb8b0ad
Author: Marek Vasut <marex@denx.de>
Date: Mon Jun 21 00:47:59 2021 +0200
drm: mxsfb: Increase number of outstanding requests on V4 and newer HW
[ Upstream commit 9891cb54445bc65bf156bda416b6215048c7f617 ]
In case the DRAM is under high load, the MXSFB FIFO might underflow
and that causes visible artifacts. This could be triggered on i.MX8MM
using e.g. "$ memtester 128M" on a device with 1920x1080 panel. The
first "Stuck Address" test of the memtester will completely corrupt
the image on the panel and leave the MXSFB FIFO in odd state.
To avoid this underflow, increase number of outstanding requests to
DRAM from 2 to 16, which is the maximum. This mitigates the issue
and it can no longer be triggered.
Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Daniel Abrecht <public@danielabrecht.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Stefan Agner <stefan@agner.ch>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210620224759.189351-1-marex@denx.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f63e885b984ec21b5b902d2a67aa6f096ff80154
Author: Marek Vasut <marex@denx.de>
Date: Mon Jun 21 00:47:01 2021 +0200
drm: mxsfb: Enable recovery on underflow
[ Upstream commit 0c9856e4edcdcac22d65618e8ceff9eb41447880 ]
There is some sort of corner case behavior of the controller,
which could rarely be triggered at least on i.MX6SX connected
to 800x480 DPI panel and i.MX8MM connected to DPI->DSI->LVDS
bridged 1920x1080 panel (and likely on other setups too), where
the image on the panel shifts to the right and wraps around.
This happens either when the controller is enabled on boot or
even later during run time. The condition does not correct
itself automatically, i.e. the display image remains shifted.
It seems this problem is known and is due to sporadic underflows
of the LCDIF FIFO. While the LCDIF IP does have underflow/overflow
IRQs, neither of the IRQs trigger and neither IRQ status bit is
asserted when this condition occurs.
All known revisions of the LCDIF IP have CTRL1 RECOVER_ON_UNDERFLOW
bit, which is described in the reference manual since i.MX23 as
"
Set this bit to enable the LCDIF block to recover in the next
field/frame if there was an underflow in the current field/frame.
"
Enable this bit to mitigate the sporadic underflows.
Fixes: 45d59d704080 ("drm: Add new driver for MXSFB controller")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Daniel Abrecht <public@danielabrecht.ch>
Cc: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: Stefan Agner <stefan@agner.ch>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20210620224701.189289-1-marex@denx.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5e99b869007b05cf9e71b323929ff02b44e84e90
Author: Waiman Long <longman@redhat.com>
Date: Tue Jul 20 10:18:27 2021 -0400
cgroup/cpuset: Fix a partition bug with hotplug
[ Upstream commit 15d428e6fe77fffc3f4fff923336036f5496ef17 ]
In cpuset_hotplug_workfn(), the detection of whether the cpu list
has been changed is done by comparing the effective cpus of the top
cpuset with the cpu_active_mask. However, in the rare case that just
all the CPUs in the subparts_cpus are offlined, the detection fails
and the partition states are not updated correctly. Fix it by forcing
the cpus_updated flag to true in this particular case.
Fixes: 4b842da276a8 ("cpuset: Make CPU hotplug work with partition")
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2e50a90eb91dc6199b42dd34a0e541bb8778e544
Author: Maxim Mikityanskiy <maximmi@nvidia.com>
Date: Fri Apr 23 20:34:48 2021 +0300
net/mlx5e: Block LRO if firmware asks for tunneled LRO
[ Upstream commit 26ab7b384525ccfa678c518577f7f0d841209c8b ]
This commit does a cleanup in LRO configuration.
LRO is a parameter of an RQ, but its state is changed by modifying a TIR
related to the RQ.
The current status: LRO for tunneled packets is not supported in the
driver, inner TIRs may enable LRO on creation, but LRO status of inner
TIRs isn't changed in mlx5e_modify_tirs_lro(). This is inconsistent, but
as long as the firmware doesn't declare support for tunneled LRO, it
works, because the same RQs are shared between the inner and outer TIRs.
This commit does two fixes:
1. If the firmware has the tunneled LRO capability, LRO is blocked
altogether, because it's not possible to block it for inner TIRs only,
when the same RQs are shared between inner and outer TIRs, and the
driver won't be able to handle tunneled LRO traffic.
2. mlx5e_modify_tirs_lro() is patched to modify LRO state for all TIRs,
including inner ones, because all TIRs related to an RQ should agree on
their LRO state.
Fixes: 7b3722fa9ef6 ("net/mlx5e: Support RSS for GRE tunneled packets")
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 032e4c8927e4d4065ed24e09406ec79a0e8fc1b0
Author: Maxim Mikityanskiy <maximmi@nvidia.com>
Date: Thu Apr 8 17:20:04 2021 +0300
net/mlx5e: Prohibit inner indir TIRs in IPoIB
[ Upstream commit 9c43f3865c2a03be104f1c1d5e9129c2a2bdba88 ]
TIR's rx_hash_field_selector_inner can be enabled only when
tunneled_offload_en = 1. tunneled_offload_en is filled according to the
tunneled_offload_en field in struct mlx5e_params, which is false in the
IPoIB profile. On the other hand, the IPoIB profile passes inner_ttc =
true to mlx5e_create_indirect_tirs, which potentially allows the latter
function to attempt to create inner indirect TIRs without having
tunneled_offload_en set.
This commit prohibits this behavior by passing inner_ttc = false to
mlx5e_create_indirect_tirs. The latter function won't attempt to create
inner indirect TIRs.
As inner indirect TIRs are not created in the IPoIB profile (this commit
blocks it explicitly, and even before they would have failed to be
created), the call to mlx5e_create_inner_ttc_table in
mlx5i_create_flow_steering is a no-op and can be removed.
Fixes: 46dc933cee82 ("net/mlx5e: Provide explicit directive if to create inner indirect tirs")
Fixes: 458821c72bd0 ("net/mlx5e: IPoIB, Add inner TTC table to IPoIB flow steering")
Signed-off-by: Maxim Mikityanskiy <maximmi@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f79d617e8f5c1c0608000c6008d84bec1cbe667b
Author: Anand Moon <linux.amoon@gmail.com>
Date: Mon Jul 5 11:23:55 2021 +0000
ARM: dts: meson8b: ec100: Fix the pwm regulator supply properties
[ Upstream commit 72ccc373b064ae3ac0c5b5f2306069b60ca118df ]
After enabling CONFIG_REGULATOR_DEBUG=y we observer below debug logs.
Changes help link VCCK and VDDEE pwm regulator to 5V regulator supply
instead of dummy regulator.
[ 7.117140] pwm-regulator regulator-vcck: Looking up pwm-supply from device tree
[ 7.117153] pwm-regulator regulator-vcck: Looking up pwm-supply property in node /regulator-vcck failed
[ 7.117184] VCCK: supplied by regulator-dummy
[ 7.117194] regulator-dummy: could not add device link regulator.8: -ENOENT
[ 7.117266] VCCK: 860 <--> 1140 mV at 986 mV, enabled
[ 7.118498] VDDEE: will resolve supply early: pwm
[ 7.118515] pwm-regulator regulator-vddee: Looking up pwm-supply from device tree
[ 7.118526] pwm-regulator regulator-vddee: Looking up pwm-supply property in node /regulator-vddee failed
[ 7.118553] VDDEE: supplied by regulator-dummy
[ 7.118563] regulator-dummy: could not add device link regulator.9: -ENOENT
Fixes: 087a1d8b4e4c ("ARM: dts: meson8b: ec100: add the VDDEE regulator")
Fixes: 3e7db1c1b7a3 ("ARM: dts: meson8b: ec100: improve the description of the regulators")
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20210705112358.3554-4-linux.amoon@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d7001996940320dfb0e116e3f7e08714d7929062
Author: Anand Moon <linux.amoon@gmail.com>
Date: Mon Jul 5 11:23:54 2021 +0000
ARM: dts: meson8b: mxq: Fix the pwm regulator supply properties
[ Upstream commit 632062e540becbbcb067523ec8bcadb1239d9578 ]
After enabling CONFIG_REGULATOR_DEBUG=y we observer below debug logs.
Changes help link VCCK and VDDEE pwm regulator to 5V regulator supply
instead of dummy regulator.
Add missing pwm-supply for regulator-vcck regulator node.
[ 7.117140] pwm-regulator regulator-vcck: Looking up pwm-supply from device tree
[ 7.117153] pwm-regulator regulator-vcck: Looking up pwm-supply property in node /regulator-vcck failed
[ 7.117184] VCCK: supplied by regulator-dummy
[ 7.117194] regulator-dummy: could not add device link regulator.8: -ENOENT
[ 7.117266] VCCK: 860 <--> 1140 mV at 986 mV, enabled
[ 7.118498] VDDEE: will resolve supply early: pwm
[ 7.118515] pwm-regulator regulator-vddee: Looking up pwm-supply from device tree
[ 7.118526] pwm-regulator regulator-vddee: Looking up pwm-supply property in node /regulator-vddee failed
[ 7.118553] VDDEE: supplied by regulator-dummy
[ 7.118563] regulator-dummy: could not add device link regulator.9: -ENOENT
Fixes: dee51cd0d2e8 ("ARM: dts: meson8b: mxq: add the VDDEE regulator")
Fixes: d94f60e3dfa0 ("ARM: dts: meson8b: mxq: improve support for the TRONFY MXQ S805")
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20210705112358.3554-3-linux.amoon@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 15e54b8c0be6bf457811f4a800834ac41bb4de1f
Author: Anand Moon <linux.amoon@gmail.com>
Date: Mon Jul 5 11:23:53 2021 +0000
ARM: dts: meson8b: odroidc1: Fix the pwm regulator supply properties
[ Upstream commit 876228e9f935f19c7afc7ba394d17e2ec9143b65 ]
After enabling CONFIG_REGULATOR_DEBUG=y we observe below debug logs.
Changes help link VCCK and VDDEE pwm regulator to 5V regulator supply
instead of dummy regulator.
[ 7.117140] pwm-regulator regulator-vcck: Looking up pwm-supply from device tree
[ 7.117153] pwm-regulator regulator-vcck: Looking up pwm-supply property in node /regulator-vcck failed
[ 7.117184] VCCK: supplied by regulator-dummy
[ 7.117194] regulator-dummy: could not add device link regulator.8: -ENOENT
[ 7.117266] VCCK: 860 <--> 1140 mV at 986 mV, enabled
[ 7.118498] VDDEE: will resolve supply early: pwm
[ 7.118515] pwm-regulator regulator-vddee: Looking up pwm-supply from device tree
[ 7.118526] pwm-regulator regulator-vddee: Looking up pwm-supply property in node /regulator-vddee failed
[ 7.118553] VDDEE: supplied by regulator-dummy
[ 7.118563] regulator-dummy: could not add device link regulator.9: -ENOENT
Fixes: 524d96083b66 ("ARM: dts: meson8b: odroidc1: add the CPU voltage regulator")
Fixes: 8bdf38be712d ("ARM: dts: meson8b: odroidc1: add the VDDEE regulator")
Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
[narmstrong: fixed typo in commit s/observer/observe/]
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20210705112358.3554-2-linux.amoon@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9e179ea19c78123a8a67355b36a2c55b2bb7bf04
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date: Sun Jul 11 23:40:23 2021 +0200
ARM: dts: meson8: Use a higher default GPU clock frequency
[ Upstream commit 44cf630bcb8c5ec78125805c9447dd5766792224 ]
We are seeing "imprecise external abort (0x1406)" errors during boot
(which then cause the whole board to hang) on Meson8 (but not Meson8m2).
These are observed while trying to access the GPU's registers when the
MALI clock is running at it's default setting of 24MHz. The 3.10 vendor
kernel uses 318.75MHz as "default" GPU frequency. Using that makes the
"imprecise external aborts" go away.
Add the assigned-clocks and assigned-clock-rates properties to also bump
the MALI clock to 318.75MHz before accessing any of it's registers.
Fixes: 7d3f6b536e72c9 ("ARM: dts: meson8: add the Mali-450 MP6 GPU")
Reported-by: Demetris Ierokipides <ierokipides.dem@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20210711214023.2163565-1-martin.blumenstingl@googlemail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f0719908efd37cac70770fc278543f51f52c19a0
Author: Martin KaFai Lau <kafai@fb.com>
Date: Thu Jul 1 13:05:41 2021 -0700
tcp: seq_file: Avoid skipping sk during tcp_seek_last_pos
[ Upstream commit 525e2f9fd0229eb10cb460a9e6d978257f24804e ]
st->bucket stores the current bucket number.
st->offset stores the offset within this bucket that is the sk to be
seq_show(). Thus, st->offset only makes sense within the same
st->bucket.
These two variables are an optimization for the common no-lseek case.
When resuming the seq_file iteration (i.e. seq_start()),
tcp_seek_last_pos() tries to continue from the st->offset
at bucket st->bucket.
However, it is possible that the bucket pointed by st->bucket
has changed and st->offset may end up skipping the whole st->bucket
without finding a sk. In this case, tcp_seek_last_pos() currently
continues to satisfy the offset condition in the next (and incorrect)
bucket. Instead, regardless of the offset value, the first sk of the
next bucket should be returned. Thus, "bucket == st->bucket" check is
added to tcp_seek_last_pos().
The chance of hitting this is small and the issue is a decade old,
so targeting for the next tree.
Fixes: a8b690f98baf ("tcp: Fix slowness in read /proc/net/tcp")
Signed-off-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Acked-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/bpf/20210701200541.1033917-1-kafai@fb.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit cd098c0ad545bd5871dc53c77167244bcaec7acf
Author: Luben Tuikov <luben.tuikov@amd.com>
Date: Fri Jul 9 23:33:11 2021 -0400
drm/amd/pm: Fix a bug communicating with the SMU (v5)
[ Upstream commit 5810323ba692895b045e3f1b3e107605c3717dab ]
This fixes a bug which if we probe a non-existing
I2C device, and the SMU returns 0xFF, from then on
we can never communicate with the SMU, because the
code before this patch reads and interprets 0xFF
as a terminal error, and thus we never write 0
into register 90 to clear the status (and
subsequently send a new command to the SMU.)
It is not an error that the SMU returns status
0xFF. This means that the SMU executed the last
command successfully (execution status), but the
command result is an error of some sort (execution
result), depending on what the command was.
When doing a status check of the SMU, before we
send a new command, the only status which
precludes us from sending a new command is 0--the
SMU hasn't finished executing a previous command,
and 0xFC--the SMU is busy.
This bug was seen as the following line in the
kernel log,
amdgpu: Msg issuing pre-check failed(0xff) and SMU may be not in the right state!
when subsequent SMU commands, not necessarily
related to I2C, were sent to the SMU.
This patch fixes this bug.
v2: Add a comment to the description of
__smu_cmn_poll_stat() to explain why we're NOT
defining the SMU FW return codes as macros, but
are instead hard-coding them. Such a change, can
be followed up by a subsequent patch.
v3: The changes are,
a) Add comments to break labels in
__smu_cmn_reg2errno().
b) When an unknown/unspecified/undefined result is
returned back from the SMU, map that to
-EREMOTEIO, to distinguish failure at the SMU
FW.
c) Add kernel-doc to
smu_cmn_send_msg_without_waiting(),
smu_cmn_wait_for_response(),
smu_cmn_send_smc_msg_with_param().
d) In smu_cmn_send_smc_msg_with_param(), since we
wait for completion of the command, if the
result of the completion is
undefined/unknown/unspecified, we print that to
the kernel log.
v4: a) Add macros as requested, though redundant, to
be removed when SMU consolidates for all
ASICs--see comment in code.
b) Get out if the SMU code is unknown.
v5: Rename the macro names.
Cc: Alex Deucher <Alexander.Deucher@amd.com>
Cc: Evan Quan <evan.quan@amd.com>
Cc: Lijo Lazar <Lijo.Lazar@amd.com>
Fixes: fcb1fe9c9e0031 ("drm/amd/powerplay: pre-check the SMU state before issuing message")
Signed-off-by: Luben Tuikov <luben.tuikov@amd.com>
Reviewed-by: Alex Deucher <Alexander.Deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit daa6b1e28c4ba7e853ae7a36915682e2ca4c5564
Author: Kai-Heng Feng <kai.heng.feng@canonical.com>
Date: Wed Jul 21 01:22:15 2021 +0800
drm/amdgpu/acp: Make PM domain really work
[ Upstream commit aff890288de2d818e4f83ec40c9315e2d735df07 ]
Devices created by mfd_add_hotplug_devices() don't really increase the
index of its name, so get_mfd_cell_dev() cannot find any device, hence a
NULL dev is passed to pm_genpd_add_device():
[ 56.974926] (NULL device *): amdgpu: device acp_audio_dma.0.auto added to pm domain
[ 56.974933] (NULL device *): amdgpu: Failed to add dev to genpd
[ 56.974941] [drm:amdgpu_device_ip_init [amdgpu]] *ERROR* hw_init of IP block <acp_ip> failed -22
[ 56.975810] amdgpu 0000:00:01.0: amdgpu: amdgpu_device_ip_init failed
[ 56.975839] amdgpu 0000:00:01.0: amdgpu: Fatal error during GPU init
[ 56.977136] ------------[ cut here ]------------
[ 56.977143] kernel BUG at mm/slub.c:4206!
[ 56.977158] invalid opcode: 0000 [#1] SMP NOPTI
[ 56.977167] CPU: 1 PID: 1648 Comm: modprobe Not tainted 5.12.0-051200rc8-generic #202104182230
[ 56.977175] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./FM2A68M-HD+, BIOS P5.20 02/13/2019
[ 56.977180] RIP: 0010:kfree+0x3bf/0x410
[ 56.977195] Code: 89 e7 48 d3 e2 f7 da e8 5f 0d 02 00 80 e7 02 75 3e 44 89 ee 4c 89 e7 e8 ef 5f fd ff e9 fa fe ff ff 49 8b 44 24 08 a8 01 75 b7 <0f> 0b 4c 8b 4d b0 48 8b 4d a8 48 89 da 4c 89 e6 41 b8 01 00 00 00
[ 56.977202] RSP: 0018:ffffa48640ff79f0 EFLAGS: 00010246
[ 56.977210] RAX: 0000000000000000 RBX: ffff9286127d5608 RCX: 0000000000000000
[ 56.977215] RDX: 0000000000000000 RSI: ffffffffc099d0fb RDI: ffff9286127d5608
[ 56.977220] RBP: ffffa48640ff7a48 R08: 0000000000000001 R09: 0000000000000001
[ 56.977224] R10: 0000000000000000 R11: ffff9286087d8458 R12: fffff3ae0449f540
[ 56.977229] R13: 0000000000000000 R14: dead000000000122 R15: dead000000000100
[ 56.977234] FS: 00007f9de5929540(0000) GS:ffff928612e80000(0000) knlGS:0000000000000000
[ 56.977240] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 56.977245] CR2: 00007f697dd97160 CR3: 00000001110f0000 CR4: 00000000001506e0
[ 56.977251] Call Trace:
[ 56.977261] amdgpu_dm_encoder_destroy+0x1b/0x30 [amdgpu]
[ 56.978056] drm_mode_config_cleanup+0x4f/0x2e0 [drm]
[ 56.978147] ? kfree+0x3dd/0x410
[ 56.978157] ? drm_managed_release+0xc8/0x100 [drm]
[ 56.978232] drm_mode_config_init_release+0xe/0x10 [drm]
[ 56.978311] drm_managed_release+0x9d/0x100 [drm]
[ 56.978388] devm_drm_dev_init_release+0x4d/0x70 [drm]
[ 56.978450] devm_action_release+0x15/0x20
[ 56.978459] release_nodes+0x77/0xc0
[ 56.978469] devres_release_all+0x3f/0x50
[ 56.978477] really_probe+0x245/0x460
[ 56.978485] driver_probe_device+0xe9/0x160
[ 56.978492] device_driver_attach+0xab/0xb0
[ 56.978499] __driver_attach+0x8f/0x150
[ 56.978506] ? device_driver_attach+0xb0/0xb0
[ 56.978513] bus_for_each_dev+0x7e/0xc0
[ 56.978521] driver_attach+0x1e/0x20
[ 56.978528] bus_add_driver+0x135/0x1f0
[ 56.978534] driver_register+0x91/0xf0
[ 56.978540] __pci_register_driver+0x54/0x60
[ 56.978549] amdgpu_init+0x77/0x1000 [amdgpu]
[ 56.979246] ? 0xffffffffc0dbc000
[ 56.979254] do_one_initcall+0x48/0x1d0
[ 56.979265] ? kmem_cache_alloc_trace+0x120/0x230
[ 56.979274] ? do_init_module+0x28/0x280
[ 56.979282] do_init_module+0x62/0x280
[ 56.979288] load_module+0x71c/0x7a0
[ 56.979296] __do_sys_finit_module+0xc2/0x120
[ 56.979305] __x64_sys_finit_module+0x1a/0x20
[ 56.979311] do_syscall_64+0x38/0x90
[ 56.979319] entry_SYSCALL_64_after_hwframe+0x44/0xae
[ 56.979328] RIP: 0033:0x7f9de54f989d
[ 56.979335] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 f5 0c 00 f7 d8 64 89 01 48
[ 56.979342] RSP: 002b:00007ffe3c395a28 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
[ 56.979350] RAX: ffffffffffffffda RBX: 0000560df3ef4330 RCX: 00007f9de54f989d
[ 56.979355] RDX: 0000000000000000 RSI: 0000560df3a07358 RDI: 000000000000000f
[ 56.979360] RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000
[ 56.979365] R10: 000000000000000f R11: 0000000000000246 R12: 0000560df3a07358
[ 56.979369] R13: 0000000000000000 R14: 0000560df3ef4460 R15: 0000560df3ef4330
[ 56.979377] Modules linked in: amdgpu(+) iommu_v2 gpu_sched drm_ttm_helper ttm drm_kms_helper cec rc_core i2c_algo_bit fb_sys_fops syscopyarea sysfillrect sysimgblt nft_counter xt_tcpudp ipt_REJECT nf_reject_ipv4 xt_conntrack iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_mangle iptable_raw iptable_security ip_set nf_tables libcrc32c nfnetlink ip6_tables iptable_filter bpfilter input_leds binfmt_misc edac_mce_amd kvm_amd ccp kvm snd_hda_codec_realtek snd_hda_codec_generic crct10dif_pclmul snd_hda_codec_hdmi ledtrig_audio ghash_clmulni_intel aesni_intel snd_hda_intel snd_intel_dspcfg snd_seq_midi crypto_simd snd_intel_sdw_acpi cryptd snd_hda_codec snd_seq_midi_event snd_rawmidi snd_hda_core snd_hwdep snd_seq fam15h_power k10temp snd_pcm snd_seq_device snd_timer snd mac_hid soundcore sch_fq_codel nct6775 hwmon_vid drm ip_tables x_tables autofs4 dm_mirror dm_region_hash dm_log hid_generic usbhid hid uas usb_storage r8169 crc32_pclmul realtek ahci xhci_pci i2c_piix4
[ 56.979521] xhci_pci_renesas libahci video
[ 56.979541] ---[ end trace cb8f6a346f18da7b ]---
Instead of finding MFD hotplugged device by its name, simply iterate
over the child devices to avoid the issue.
Squash in unused variable removal (Alex)
BugLink: https://bugs.launchpad.net/bugs/1920674
Fixes: 25030321ba28 ("drm/amd: add pm domain for ACP IP sub blocks")
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 28573ba98c23cb0713e1cf6919e1476689416c24
Author: Colin Ian King <colin.king@canonical.com>
Date: Mon Jul 12 13:14:40 2021 +0100
6lowpan: iphc: Fix an off-by-one check of array index
[ Upstream commit 9af417610b6142e826fd1ee8ba7ff3e9a2133a5a ]
The bounds check of id is off-by-one and the comparison should
be >= rather >. Currently the WARN_ON_ONCE check does not stop
the out of range indexing of &ldev->ctx.table[id] so also add
a return path if the bounds are out of range.
Addresses-Coverity: ("Illegal address computation").
Fixes: 5609c185f24d ("6lowpan: iphc: add support for stateful compression")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 336e972af9a911e69612f84b25655bb95bf03194
Author: Jun Miao <jun.miao@windriver.com>
Date: Fri Jul 9 21:46:25 2021 +0800
Bluetooth: btusb: Fix a unspported condition to set available debug features
[ Upstream commit 20a831f04f1526f2c3442efd3dece8630216b5d2 ]
When reading the support debug features failed, there are not available
features init. Continue to set the debug features is illogical, we should
skip btintel_set_debug_features(), even if check it by "if (!features)".
Fixes: c453b10c2b28 ("Bluetooth: btusb: Configure Intel debug feature based on available support")
Signed-off-by: Jun Miao <jun.miao@windriver.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit de5f8501a44baa1fbf436349b4e140bc3fa8e495
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri Jun 25 18:00:09 2021 +0300
Bluetooth: sco: prevent information leak in sco_conn_defer_accept()
[ Upstream commit 59da0b38bc2ea570ede23a3332ecb3e7574ce6b2 ]
Smatch complains that some of these struct members are not initialized
leading to a stack information disclosure:
net/bluetooth/sco.c:778 sco_conn_defer_accept() warn:
check that 'cp.retrans_effort' doesn't leak information
This seems like a valid warning. I've added a default case to fix
this issue.
Fixes: 2f69a82acf6f ("Bluetooth: Use voice setting in deferred SCO connection request")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 41067abfa180e2f46fcd5ab302fe1b35745002ae
Author: Yizhuo <yzhai003@ucr.edu>
Date: Fri Jun 25 07:38:56 2021 +0200
media: atomisp: fix the uninitialized use and rename "retvalue"
[ Upstream commit c275e5d349b0d2b1143607d28b9c7c14a8a0a9b4 ]
Inside function mt9m114_detect(), variable "retvalue" could
be uninitialized if mt9m114_read_reg() returns error, however, it
is used in the later if statement, which is potentially unsafe.
The local variable "retvalue" is renamed to "model" to avoid
confusion.
Link: https://lore.kernel.org/linux-media/20210625053858.3862-1-yzhai003@ucr.edu
Fixes: ad85094 (media / atomisp: fix the uninitialized use of model ID)
Signed-off-by: Yizhuo <yzhai003@ucr.edu>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 01705a96ced41be40f9fb2b5025b3f5bd2f162b7
Author: Philipp Zabel <p.zabel@pengutronix.de>
Date: Mon Jul 19 16:57:08 2021 +0200
media: coda: fix frame_mem_ctrl for YUV420 and YVU420 formats
[ Upstream commit 44693d74f5653f82cd7ca0fe730eed0f6b83306a ]
The frame memory control register value is currently determined
before userspace selects the final capture format and never corrected.
Update ctx->frame_mem_ctrl in __coda_start_decoding() to fix decoding
into YUV420 or YVU420 capture buffers.
Reported-by: Andrej Picej <andrej.picej@norik.com>
Fixes: 497e6b8559a6 ("media: coda: add sequence initialization work")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 82a1b7e2da77bfb622496b120f239e479202bab7
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue Jul 13 11:24:10 2021 +0200
media: rockchip/rga: fix error handling in probe
[ Upstream commit e58430e1d4fd01b74475d2fbe2e25b5817b729a9 ]
There are a few bugs in this code. 1) No checks for whether
dma_alloc_attrs() or __get_free_pages() failed. 2) If
video_register_device() fails it doesn't clean up the dma attrs or the
free pages. 3) The video_device_release() function frees "vfd" which
leads to a use after free on the next line. The call to
video_unregister_device() is not required so I have just removed that.
Fixes: f7e7b48e6d79 ("[media] rockchip/rga: v4l2 m2m support")
Reported-by: Dongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 71135cffe27d794daf9c1696676cf51f41d6d79d
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue Jun 22 16:31:53 2021 +0200
media: v4l2-subdev: fix some NULL vs IS_ERR() checks
[ Upstream commit ba7a93e507f88306d7a19a1dcb53b857b790cfb8 ]
The v4l2_subdev_alloc_state() function returns error pointers, it
doesn't return NULL.
Fixes: 0d346d2a6f54 ("media: v4l2-subdev: add subdev-wide state struct")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f4ec46dcf1dcdff832ff3f778a2f8899c06e23e0
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Sun Jun 20 21:45:42 2021 +0200
media: go7007: remove redundant initialization
[ Upstream commit 6f5885a7750545973bf1a942d2f0f129aef0aa06 ]
In go7007_alloc() kzalloc() is used for struct go7007
allocation. It means that there is no need in zeroing
any members, because kzalloc will take care of it.
Removing these reduntant initialization steps increases
execution speed a lot:
Before:
+ 86.802 us | go7007_alloc();
After:
+ 29.595 us | go7007_alloc();
Fixes: 866b8695d67e8 ("Staging: add the go7007 video driver")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit bddf4b364bb5e4e46bc1f27929f396de1a6d107d
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Sun Jun 20 21:45:02 2021 +0200
media: go7007: fix memory leak in go7007_usb_probe
[ Upstream commit 47d94dad8e64b2fc1d8f66ce7acf714f9462c60f ]
In commit 137641287eb4 ("go7007: add sanity checking for endpoints")
endpoint sanity check was introduced, but if check fails it simply
returns with leaked pointers.
Cutted log from my local syzbot instance:
BUG: memory leak
unreferenced object 0xffff8880209f0000 (size 8192):
comm "kworker/0:4", pid 4916, jiffies 4295263583 (age 29.310s)
hex dump (first 32 bytes):
30 b0 27 22 80 88 ff ff 75 73 62 2d 64 75 6d 6d 0.'"....usb-dumm
79 5f 68 63 64 2e 33 2d 31 00 00 00 00 00 00 00 y_hcd.3-1.......
backtrace:
[<ffffffff860ca856>] kmalloc include/linux/slab.h:556 [inline]
[<ffffffff860ca856>] kzalloc include/linux/slab.h:686 [inline]
[<ffffffff860ca856>] go7007_alloc+0x46/0xb40 drivers/media/usb/go7007/go7007-driver.c:696
[<ffffffff860de74e>] go7007_usb_probe+0x13e/0x2200 drivers/media/usb/go7007/go7007-usb.c:1114
[<ffffffff854a5f74>] usb_probe_interface+0x314/0x7f0 drivers/usb/core/driver.c:396
[<ffffffff845a7151>] really_probe+0x291/0xf60 drivers/base/dd.c:576
BUG: memory leak
unreferenced object 0xffff88801e2f2800 (size 512):
comm "kworker/0:4", pid 4916, jiffies 4295263583 (age 29.310s)
hex dump (first 32 bytes):
00 87 40 8a ff ff ff ff 00 00 00 00 00 00 00 00 ..@.............
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff860de794>] kmalloc include/linux/slab.h:556 [inline]
[<ffffffff860de794>] kzalloc include/linux/slab.h:686 [inline]
[<ffffffff860de794>] go7007_usb_probe+0x184/0x2200 drivers/media/usb/go7007/go7007-usb.c:1118
[<ffffffff854a5f74>] usb_probe_interface+0x314/0x7f0 drivers/usb/core/driver.c:396
[<ffffffff845a7151>] really_probe+0x291/0xf60 drivers/base/dd.c:576
Fixes: 137641287eb4 ("go7007: add sanity checking for endpoints")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 68b8b58abb5df91eb3addf8c393ae813e1d47b0e
Author: Oleksij Rempel <linux@rempel-privat.de>
Date: Thu Jul 22 09:32:24 2021 +0200
net: usb: asix: ax88772: add missing stop
[ Upstream commit 9c2670951ed03f8fc6c701d66f5c765929cf1f23 ]
Add missing stop and let phylib framework suspend attached PHY.
Fixes: e532a096be0e ("net: usb: asix: ax88772: add phylib support")
Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 90d3c48c15d016c2e3abaf86e19f045f1be43e08
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date: Mon Jun 21 07:07:28 2021 +0200
media: dvb-usb: Fix error handling in dvb_usb_i2c_init
[ Upstream commit 131ae388b88e3daf4cb0721ed4b4cb8bfc201465 ]
In dvb_usb_i2c_init, if i2c_add_adapter fails, it only prints an error
message, and then continues to set DVB_USB_STATE_I2C. This affects the
logic of dvb_usb_i2c_exit, which leads to that, the deletion of i2c_adap
even if the i2c_add_adapter fails.
Fix this by returning at the failure of i2c_add_adapter and then move
dvb_usb_i2c_exit out of the error handling code of dvb_usb_i2c_init.
Fixes: 13a79f14ab28 ("media: dvb-usb: Fix memory leak at error in dvb_usb_device_init()")
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 039fe2394bc493754470aae022f578f072f4cd74
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date: Fri Jun 25 07:59:04 2021 +0200
media: dvb-usb: fix uninit-value in vp702x_read_mac_addr
[ Upstream commit 797c061ad715a9a1480eb73f44b6939fbe3209ed ]
If vp702x_usb_in_op fails, the mac address is not initialized.
And vp702x_read_mac_addr does not handle this failure, which leads to
the uninit-value in dvb_usb_adapter_dvb_init.
Fix this by handling the failure of vp702x_usb_in_op.
Fixes: 786baecfe78f ("[media] dvb-usb: move it to drivers/media/usb/dvb-usb")
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0b5f1434f9b1e7565350f3d3637987fb0f6e7154
Author: Dongliang Mu <mudongliangabcd@gmail.com>
Date: Fri Jun 25 07:33:27 2021 +0200
media: dvb-usb: fix uninit-value in dvb_usb_adapter_dvb_init
[ Upstream commit c5453769f77ce19a5b03f1f49946fd3f8a374009 ]
If dibusb_read_eeprom_byte fails, the mac address is not initialized.
And nova_t_read_mac_address does not handle this failure, which leads to
the uninit-value in dvb_usb_adapter_dvb_init.
Fix this by handling the failure of dibusb_read_eeprom_byte.
Reported-by: syzbot+e27b4fd589762b0b9329@syzkaller.appspotmail.com
Fixes: 786baecfe78f ("[media] dvb-usb: move it to drivers/media/usb/dvb-usb")
Signed-off-by: Dongliang Mu <mudongliangabcd@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6a4ad754e5c8b11afde0f9c4df898bc7541e36fd
Author: Leon Romanovsky <leon@kernel.org>
Date: Wed Jul 21 15:39:44 2021 +0300
ionic: cleanly release devlink instance
[ Upstream commit c2255ff47768c94a0ebc3968f007928bb47ea43b ]
The failure to register devlink will leave the system with dangled
devlink resource, which is not cleaned if devlink_port_register() fails.
In order to remove access to ".registered" field of struct devlink_port,
require both devlink_register and devlink_port_register to success and
check it through device pointer.
Fixes: fbfb8031533c ("ionic: Add hardware init and device commands")
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Acked-by: Shannon Nelson <snelson@pensando.io>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit dbd9f85376e5958a4a579b3787d7718dd47cd328
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Wed Jul 7 15:43:01 2021 +0800
driver core: Fix error return code in really_probe()
[ Upstream commit f04948dea236b000da09c466a7ec931ecd8d7867 ]
In the case of error handling, the error code returned by the subfunction
should be propagated instead of 0.
Fixes: 1901fb2604fb ("Driver core: fix "driver" symlink timing")
Fixes: 23b6904442d0 ("driver core: add dev_groups to all drivers")
Fixes: 8fd456ec0cf0 ("driver core: Add state_synced sysfs file for devices that support it")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20210707074301.2722-1-thunder.leizhen@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d99c820a7a0853739e043f06591197d4ae573c41
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Mon Jul 19 14:45:31 2021 +0800
firmware: fix theoretical UAF race with firmware cache and resume
[ Upstream commit 3ecc8cb7c092b2f50e21d2aaaae35b8221ee7214 ]
This race was discovered when I carefully analyzed the code to locate
another firmware-related UAF issue. It can be triggered only when the
firmware load operation is executed during suspend. This possibility is
almost impossible because there are few firmware load and suspend actions
in the actual environment.
CPU0 CPU1
__device_uncache_fw_images(): assign_fw():
fw_cache_piggyback_on_request()
<----- P0
spin_lock(&fwc->name_lock);
...
list_del(&fce->list);
spin_unlock(&fwc->name_lock);
uncache_firmware(fce->name);
<----- P1
kref_get(&fw_priv->ref);
If CPU1 is interrupted at position P0, the new 'fce' has been added to the
list fwc->fw_names by the fw_cache_piggyback_on_request(). In this case,
CPU0 executes __device_uncache_fw_images() and will be able to see it when
it traverses list fwc->fw_names. Before CPU1 executes kref_get() at P1, if
CPU0 further executes uncache_firmware(), the count of fw_priv->ref may
decrease to 0, causing fw_priv to be released in advance.
Move kref_get() to the lock protection range of fwc->name_lock to fix it.
Fixes: ac39b3ea73aa ("firmware loader: let caching firmware piggyback on loading firmware")
Acked-by: Luis Chamberlain <mcgrof@kernel.org>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Link: https://lore.kernel.org/r/20210719064531.3733-2-thunder.leizhen@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 590a120b867d79419d40304bc6cc06202d01d970
Author: John Fastabend <john.fastabend@gmail.com>
Date: Tue Jul 20 11:48:32 2021 -0700
bpf, selftests: Fix test_maps now that sockmap supports UDP
[ Upstream commit c39aa21599748f3845a47645f482d94099b11460 ]
UDP socket support was added recently so testing UDP insert failure is no
longer correct and causes test_maps failure. The fix is easy though, we
simply need to test that UDP is correctly added instead of blocked.
Fixes: 122e6c79efe1c ("sock_map: Update sock type checks for UDP")
Reported-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: John Fastabend <john.fastabend@gmail.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210720184832.452430-1-john.fastabend@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7cbed4315b74b7094602fe396b781e9870b346e1
Author: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Date: Wed Jul 7 00:07:01 2021 +0100
arm64: dts: qcom: sm8250: fix usb2 qmp phy node
[ Upstream commit 63fa4322469648ae1023bb92a8b0d6a2f4bdaf2c ]
Use 'lanes' as SuperSpeed lanes device node instead of just 'lane' to
fix issues with TypeC support.
Fixes: 46a6f297d7dd ("arm64: dts: qcom: sm8250: Add USB and PHY device nodes")
Cc: robh+dt@kernel.org
Cc: devicetree@vger.kernel.org
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20210706230702.299047-2-bryan.odonoghue@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9e46d7c03b82e2158ccac12be841002a0ba92bab
Author: Colin Ian King <colin.king@canonical.com>
Date: Mon Jul 12 17:24:30 2021 +0100
gfs2: Fix memory leak of object lsi on error return path
[ Upstream commit a6579cbfd7216b071008db13360c322a6b21400b ]
In the case where IS_ERR(lsi->si_sc_inode) is true the error exit path
to free_local does not kfree the allocated object lsi leading to a memory
leak. Fix this by kfree'ing lst before taking the error exit path.
Addresses-Coverity: ("Resource leak")
Fixes: 97fd734ba17e ("gfs2: lookup local statfs inodes prior to journal recovery")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4bf71f9275ce86e55a3155be41486c353106518b
Author: Martynas Pumputis <m@lambda.lt>
Date: Mon Jul 19 19:38:37 2021 +0200
libbpf: Fix removal of inner map in bpf_object__create_map
[ Upstream commit a21ab4c59e09c2a9994a6e393b7484e3b3f78a99 ]
If creating an outer map of a BTF-defined map-in-map fails (via
bpf_object__create_map()), then the previously created its inner map
won't be destroyed.
Fix this by ensuring that the destroy routines are not bypassed in the
case of a failure.
Fixes: 646f02ffdd49c ("libbpf: Add BTF-defined map-in-map support")
Reported-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Martynas Pumputis <m@lambda.lt>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Link: https://lore.kernel.org/bpf/20210719173838.423148-2-m@lambda.lt
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ee3867d50c8a9239dc1a4043d78230e758ef0442
Author: Bjorn Andersson <bjorn.andersson@linaro.org>
Date: Fri Jul 2 17:54:15 2021 -0700
soc: qcom: rpmhpd: Use corner in power_off
[ Upstream commit d43b3a989bc8c06fd4bbb69a7500d180db2d68e8 ]
rpmhpd_aggregate_corner() takes a corner as parameter, but in
rpmhpd_power_off() the code requests the level of the first corner
instead.
In all (known) current cases the first corner has level 0, so this
change should be a nop, but in case that there's a power domain with a
non-zero lowest level this makes sure that rpmhpd_power_off() actually
requests the lowest level - which is the closest to "power off" we can
get.
While touching the code, also skip the unnecessary zero-initialization
of "ret".
Fixes: 279b7e8a62cc ("soc: qcom: rpmhpd: Add RPMh power domain driver")
Reviewed-by: Rajendra Nayak <rnayak@codeaurora.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Tested-by: Sibi Sankar <sibis@codeaurora.org>
Link: https://lore.kernel.org/r/20210703005416.2668319-2-bjorn.andersson@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b3f1921fa2afb16ecebf65c4d288c4c5712eb5e1
Author: Judy Hsiao <judyhsiao@chromium.org>
Date: Thu Jul 8 17:08:10 2021 +0800
arm64: dts: qcom: sc7180: Set adau wakeup delay to 80 ms
[ Upstream commit a8c7f3100e708d5f55692f0607ca80c5dcd21ce8 ]
Set audu wakeup delay to 80 ms for fixing pop noise during capture begin.
Fixes: ba5f9b5d7ff3 ("arm64: dts: qcom: sc7180: Add wakeup delay for adau codec")
Signed-off-by: Judy Hsiao <judyhsiao@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210708090810.174767-1-judyhsiao@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 32b7d543f311093b470077f2044905a2725ae22a
Author: Stefan Assmann <sassmann@kpanic.de>
Date: Thu Mar 4 10:34:30 2021 +0100
i40e: improve locking of mac_filter_hash
[ Upstream commit 8b4b06919fd66caf49fdf4fe59f9d6312cf7956d ]
i40e_config_vf_promiscuous_mode() calls
i40e_getnum_vf_vsi_vlan_filters() without acquiring the
mac_filter_hash_lock spinlock.
This is unsafe because mac_filter_hash may get altered in another thread
while i40e_getnum_vf_vsi_vlan_filters() traverses the hashes.
Simply adding the spinlock in i40e_getnum_vf_vsi_vlan_filters() is not
possible as it already gets called in i40e_get_vlan_list_sync() with the
spinlock held. Therefore adding a wrapper that acquires the spinlock and
call the correct function where appropriate.
Fixes: 37d318d7805f ("i40e: Remove scheduling while atomic possibility")
Fix-suggested-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Stefan Assmann <sassmann@kpanic.de>
Tested-by: Konrad Jankowski <konrad0.jankowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e18fdcae5851d6f0a3aaef7cdea604746e8da48e
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Thu Jul 1 12:15:50 2021 +0200
arm64: dts: renesas: r8a77995: draak: Remove bogus adv7511w properties
[ Upstream commit 4ec82a7bb3db8c6005e715c63224c32d458917a2 ]
The "max-clock" and "min-vrefresh" properties fail to validate with
commit cfe34bb7a770c5d8 ("dt-bindings: drm: bridge: adi,adv7511.txt:
convert to yaml"). Drop them, as they are parts of an out-of-tree
workaround that is not needed upstream.
Fixes: bcf3003438ea4645 ("arm64: dts: renesas: r8a77995: draak: Enable HDMI display output")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
Link: https://lore.kernel.org/r/975b6686bc423421b147d367fe7fb9a0db99c5af.1625134398.git.geert+renesas@glider.be
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8de2164c557bf8c23b42fafc4516b27707b586ef
Author: Andrew Jeffery <andrew@aj.id.au>
Date: Tue Jul 13 09:06:42 2021 +0930
ARM: dts: everest: Add phase corrections for eMMC
[ Upstream commit ded3e2864c735f33ba5abbbe2d7b1c6605242f9b ]
The values were determined via scope measurements.
With the patch we can write and read data without issue where as booting
the system without the patch failed at the point of mounting the rootfs.
Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Link: https://lore.kernel.org/r/20210712233642.3119722-1-andrew@aj.id.au
Fixes: faffd1b2bde3 ("ARM: dts: everest: Add phase corrections for eMMC")
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit c67e3613d76af7327d6b6942536c9f797f6a4ba1
Author: Dylan Hung <dylan_hung@aspeedtech.com>
Date: Thu Oct 29 14:27:23 2020 +0800
ARM: dts: aspeed-g6: Fix HVI3C function-group in pinctrl dtsi
[ Upstream commit 8c295b7f3d01359ff4336fcb6e406e6ed37957d6 ]
The HVI3C shall be a group of I3C function, not an independent function.
Correct the function name from "HVI3C" to "I3C".
Signed-off-by: Dylan Hung <dylan_hung@aspeedtech.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Fixes: f510f04c8c83 ("ARM: dts: aspeed: Add AST2600 pinmux nodes")
Link: https://lore.kernel.org/r/20201029062723.20798-1-dylan_hung@aspeedtech.com
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2584c6673a794a8dfc55e39f72f3ba3413ec9db7
Author: Shuyi Cheng <chengshuyi@linux.alibaba.com>
Date: Tue Jul 13 20:42:38 2021 +0800
libbpf: Fix the possible memory leak on error
[ Upstream commit 18353c87e0e0440d4c7c746ed740738bbc1b538e ]
If the strdup() fails then we need to call bpf_object__close(obj) to
avoid a resource leak.
Fixes: 166750bc1dd2 ("libbpf: Support libbpf-provided extern variables")
Signed-off-by: Shuyi Cheng <chengshuyi@linux.alibaba.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/1626180159-112996-3-git-send-email-chengshuyi@linux.alibaba.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0d2fde4c31b8ba2fc8de292abad8451e6fa85ab3
Author: Haiyue Wang <haiyue.wang@intel.com>
Date: Wed Jul 14 15:34:59 2021 +0800
gve: fix the wrong AdminQ buffer overflow check
[ Upstream commit 63a9192b8fa1ea55efeba1f18fad52bb24d9bf12 ]
The 'tail' pointer is also free-running count, so it needs to be masked
as 'adminq_prod_cnt' does, to become an index value of AdminQ buffer.
Fixes: 5cdad90de62c ("gve: Batch AQ commands for creating and destroying queues.")
Signed-off-by: Haiyue Wang <haiyue.wang@intel.com>
Reviewed-by: Catherine Sullivan <csully@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 33440b9b857486e522ee902c59afa35c09c0bccd
Author: Steven Price <steven.price@arm.com>
Date: Wed Jul 14 15:33:00 2021 +0100
drm/of: free the iterator object on failure
[ Upstream commit 6f9223a56fabc840836b49de27dc7b27642c6a32 ]
When bailing out due to the sanity check the iterator value needs to be
freed because the early return prevents for_each_child_of_node() from
doing the dereference itself.
Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
Signed-off-by: Steven Price <steven.price@arm.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210714143300.20632-1-steven.price@arm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 746f0ad44bc965e4064201eb42fc7b0b3d21c770
Author: He Fengqing <hefengqing@huawei.com>
Date: Wed Jul 14 10:18:15 2021 +0000
bpf: Fix potential memleak and UAF in the verifier.
[ Upstream commit 75f0fc7b48ad45a2e5736bcf8de26c8872fe8695 ]
In bpf_patch_insn_data(), we first use the bpf_patch_insn_single() to
insert new instructions, then use adjust_insn_aux_data() to adjust
insn_aux_data. If the old env->prog have no enough room for new inserted
instructions, we use bpf_prog_realloc to construct new_prog and free the
old env->prog.
There have two errors here. First, if adjust_insn_aux_data() return
ENOMEM, we should free the new_prog. Second, if adjust_insn_aux_data()
return ENOMEM, bpf_patch_insn_data() will return NULL, and env->prog has
been freed in bpf_prog_realloc, but we will use it in bpf_check().
So in this patch, we make the adjust_insn_aux_data() never fails. In
bpf_patch_insn_data(), we first pre-malloc memory for the new
insn_aux_data, then call bpf_patch_insn_single() to insert new
instructions, at last call adjust_insn_aux_data() to adjust
insn_aux_data.
Fixes: 8041902dae52 ("bpf: adjust insn_aux_data when patching insns")
Signed-off-by: He Fengqing <hefengqing@huawei.com>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20210714101815.164322-1-hefengqing@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2883ec806cc23cd8704ca102742b355db5fcf70c
Author: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Date: Wed Jul 14 21:43:17 2021 +0900
bpf: Fix a typo of reuseport map in bpf.h.
[ Upstream commit f170acda7ffaf0473d06e1e17c12cd9fd63904f5 ]
Fix s/BPF_MAP_TYPE_REUSEPORT_ARRAY/BPF_MAP_TYPE_REUSEPORT_SOCKARRAY/ typo
in bpf.h.
Fixes: 2dbb9b9e6df6 ("bpf: Introduce BPF_PROG_TYPE_SK_REUSEPORT")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Acked-by: John Fastabend <john.fastabend@gmail.com>
Link: https://lore.kernel.org/bpf/20210714124317.67526-1-kuniyu@amazon.co.jp
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 02367ab4562947dfa10dce4a611d50512b27feae
Author: Julia Lawall <Julia.Lawall@inria.fr>
Date: Fri Jul 9 22:07:17 2021 +0200
drm/of: free the right object
[ Upstream commit b557a5f8da5798d27370ed6b73e673aae33efd55 ]
There is no need to free a NULL value. Instead, free the object
that is leaking due to the iterator.
The semantic patch that finds this problem is as follows:
// <smpl>
@@
expression x,e;
identifier f;
@@
x = f(...);
if (x == NULL) {
... when any
when != x = e
* of_node_put(x);
...
}
// </smpl>
Fixes: 6529007522de ("drm: of: Add drm_of_lvds_get_dual_link_pixel_order")
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210709200717.3676376-1-Julia.Lawall@inria.fr
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9543eefc9c50bcb65bca087d520c3ba2100460f3
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Thu Jun 10 21:54:31 2021 +0200
media: cxd2880-spi: Fix an error handling path
[ Upstream commit dcb0145821017e929a733e2271c85c6f82b9c9f8 ]
If an error occurs after a successful 'regulator_enable()' call,
'regulator_disable()' must be called.
Fix the error handling path of the probe accordingly.
Fixes: cb496cd472af ("media: cxd2880-spi: Add optional vcc regulator")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a2696604850dabc0116e065461a1bf6c77001a83
Author: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Mon Feb 8 15:38:55 2021 +0100
soc: rockchip: ROCKCHIP_GRF should not default to y, unconditionally
[ Upstream commit 2a1c55d4762dd34a8b0f2e36fb01b7b16b60735b ]
Merely enabling CONFIG_COMPILE_TEST should not enable additional code.
To fix this, restrict the automatic enabling of ROCKCHIP_GRF to
ARCH_ROCKCHIP, and ask the user in case of compile-testing.
Fixes: 4c58063d4258f6be ("soc: rockchip: add driver handling grf setup")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20210208143855.418374-1-geert+renesas@glider.be
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b8e518cdbafb4e0d3031459b3c92d16f969eb157
Author: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Date: Tue Jun 1 19:09:03 2021 +0800
leds: is31fl32xx: Fix missing error code in is31fl32xx_parse_dt()
[ Upstream commit e642197562cd9781453f835e1406cfe0feeb917e ]
The error code is missing in this code scenario, add the error code
'-EINVAL' to the return value 'ret'.
Eliminate the follow smatch warning:
drivers/leds/leds-is31fl32xx.c:388 is31fl32xx_parse_dt() warn: missing
error code 'ret'.
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Jiapeng Chong <jiapeng.chong@linux.alibaba.com>
Fixes: 9d7cffaf99f5 ("leds: Add driver for the ISSI IS31FL32xx family of LED controllers")
Acked-by: David Rivshin <drivshin@allworx.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 620eba1bf99e2a649ffabf970ea390a65be7c584
Author: Krzysztof Hałasa <khalasa@piap.pl>
Date: Wed Jun 16 07:13:55 2021 +0200
media: TDA1997x: enable EDID support
[ Upstream commit ea3e1c36e38810427485f06c2becc1f29e54521d ]
Without this patch, the TDA19971 chip's EDID is inactive.
EDID never worked with this driver, it was all tested with HDMI signal
sources which don't need EDID support.
Signed-off-by: Krzysztof Halasa <khalasa@piap.pl>
Fixes: 9ac0038db9a7 ("media: i2c: Add TDA1997x HDMI receiver driver")
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5ae0160d46312324c258dee7d7d850682cab7249
Author: Eugen Hristev <eugen.hristev@microchip.com>
Date: Wed Jun 9 15:00:28 2021 +0200
media: atmel: atmel-sama5d2-isc: fix YUYV format
[ Upstream commit 123aaf816b952e5b6ee754335596b01ba1f6c830 ]
SAMA5D2 does not have the YCYC field for the RLP (rounding, limiting,
packaging) module.
The YCYC field is supposed to work with interleaved YUV formats like YUYV.
In SAMA5D2, we have to use YYCC field, which is used for both planar
formats like YUV420 and interleaved formats like YUYV.
Fix the according rlp callback to replace the generic YCYC field (which
makes more sense from a logical point of view) with the required YYCC
field.
Fixes: debfa496871c ("media: atmel: atmel-isc-base: add support for more formats and additional pipeline modules")
Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4c280566de035f4aa4b1f2ced4738dc05d27b7d8
Author: Marek Vasut <marex@denx.de>
Date: Thu Jul 8 11:12:29 2021 +0200
ASoC: tlv320aic32x4: Fix TAS2505/TAS2521 channel count
[ Upstream commit 3694f996be5cb8374bd224f4e5462c945d359843 ]
The TAS2505/TAS2521 does support up to two channels, LEFT and RIGHT,
which are being alternated on the audio data bus by Word Clock, WCLK.
This is documented in TI slau472 2.7.1 Digital Audio Interface. Note
that both the LEFT and RIGHT channels are only used for audio INPUT,
while only the LEFT channel is used for audio OUTPUT.
Fixes: b4525b6196cd7 ("ASoC: tlv320aic32x4: add support for TAS2505")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Claudius Heine <ch@denx.de>
Cc: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210708091229.56443-1-marex@denx.de
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ce87ed92ade973947ce93ba404c566717192b752
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date: Fri Jun 18 22:11:04 2021 +0800
ASoC: mediatek: mt8183: Fix Unbalanced pm_runtime_enable in mt8183_afe_pcm_dev_probe
[ Upstream commit 19f479c37f76e926a6c0bec974a4d09826e32fc6 ]
Add missing pm_runtime_disable() when probe error out. It could
avoid pm_runtime implementation complains when removing and probing
again the driver.
Fixes:a94aec035a122 ("ASoC: mediatek: mt8183: add platform driver")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20210618141104.105047-3-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 21b014dc13b5b3fba0c163c3b21543d671da1f33
Author: Zhang Qilong <zhangqilong3@huawei.com>
Date: Fri Jun 18 22:11:03 2021 +0800
ASoC: mediatek: mt8192:Fix Unbalanced pm_runtime_enable in mt8192_afe_pcm_dev_probe
[ Upstream commit 2af2f861edd21c1456ef7dbec52122ce1b581568 ]
Add missing pm_runtime_disable() when probe error out. It could
avoid pm_runtime implementation complains when removing and probing
again the driver.
Fixes:125ab5d588b0b ("ASoC: mediatek: mt8192: add platform driver")
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Link: https://lore.kernel.org/r/20210618141104.105047-2-zhangqilong3@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d33f8b4e1b0dc7de7b37e8009ba363ab8f1bbcba
Author: Harshvardhan Jha <harshvardhan.jha@oracle.com>
Date: Fri Jul 9 13:09:59 2021 +0530
drm/gma500: Fix end of loop tests for list_for_each_entry
[ Upstream commit ea9a897b8affa0f7b4c90182b785dded74e434aa ]
The list_for_each_entry() iterator, "connector" in this code, can never be
NULL. If we exit the loop without finding the correct connector then
"connector" points invalid memory that is an offset from the list head.
This will eventually lead to memory corruption and presumably a kernel
crash.
Fixes: 9bd81acdb648 ("gma500: Convert Oaktrail to work with new output handling")
Signed-off-by: Harshvardhan Jha <harshvardhan.jha@oracle.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20210709073959.11443-1-harshvardhan.jha@oracle.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d031746f556b344d87033bc9dcee1a65dd6a56a3
Author: Wei Yongjun <weiyongjun1@huawei.com>
Date: Tue Jun 8 14:38:56 2021 +0000
drm/panfrost: Fix missing clk_disable_unprepare() on error in panfrost_clk_init()
[ Upstream commit f42498705965bd4b026953c1892c686d8b1138e4 ]
Fix the missing clk_disable_unprepare() before return
from panfrost_clk_init() in the error handling case.
Fixes: b681af0bc1cc ("drm: panfrost: add optional bus_clock")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Signed-off-by: Steven Price <steven.price@arm.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210608143856.4154766-1-weiyongjun1@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 6736a763ef97fbb17b59e151b55ad78404b18609
Author: Quanyang Wang <quanyang.wang@windriver.com>
Date: Thu Aug 26 08:59:30 2021 +0800
spi: spi-zynq-qspi: use wait_for_completion_timeout to make zynq_qspi_exec_mem_op not interruptible
[ Upstream commit 26cfc0dbe43aae60dc03af27077775244f26c167 ]
The function wait_for_completion_interruptible_timeout will return
-ERESTARTSYS immediately when receiving SIGKILL signal which is sent
by "jffs2_gcd_mtd" during umounting jffs2. This will break the SPI memory
operation because the data transmitting may begin before the command or
address transmitting completes. Use wait_for_completion_timeout to prevent
the process from being interruptible.
Fixes: 67dca5e580f1 ("spi: spi-mem: Add support for Zynq QSPI controller")
Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com>
Link: https://lore.kernel.org/r/20210826005930.20572-1-quanyang.wang@windriver.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit da47a32661f78d77f942c186b307f61b541a07d7
Author: Chunyan Zhang <chunyan.zhang@unisoc.com>
Date: Thu Aug 26 17:15:46 2021 +0800
spi: sprd: Fix the wrong WDG_LOAD_VAL
[ Upstream commit 245ca2cc212bb2a078332ec99afbfbb202f44c2d ]
Use 50ms as default timeout value and the time clock is 32768HZ.
The original value of WDG_LOAD_VAL is not correct, so this patch
fixes it.
Fixes: ac1775012058 ("spi: sprd: Add the support of restarting the system")
Signed-off-by: Chunyan Zhang <chunyan.zhang@unisoc.com>
Link: https://lore.kernel.org/r/20210826091549.2138125-2-zhang.lyra@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit cd3da578f98f4ada35889df6fe8addee96bc4997
Author: Chen-Yu Tsai <wenst@chromium.org>
Date: Wed Aug 25 11:37:04 2021 +0800
regulator: vctrl: Avoid lockdep warning in enable/disable ops
[ Upstream commit 21e39809fd7c4b8ff3662f23e0168e87594c8ca8 ]
vctrl_enable() and vctrl_disable() call regulator_enable() and
regulator_disable(), respectively. However, vctrl_* are regulator ops
and should not be calling the locked regulator APIs. Doing so results in
a lockdep warning.
Instead of exporting more internal regulator ops, model the ctrl supply
as an actual supply to vctrl-regulator. At probe time this driver still
needs to use the consumer API to fetch its constraints, but otherwise
lets the regulator core handle the upstream supply for it.
The enable/disable/is_enabled ops are not removed, but now only track
state internally. This preserves the original behavior with the ops
being available, but one could argue that the original behavior was
already incorrect: the internal state would not match the upstream
supply if that supply had another consumer that enabled the supply,
while vctrl-regulator was not enabled.
The lockdep warning is as follows:
WARNING: possible circular locking dependency detected
5.14.0-rc6 #2 Not tainted
------------------------------------------------------
swapper/0/1 is trying to acquire lock:
ffffffc011306d00 (regulator_list_mutex){+.+.}-{3:3}, at:
regulator_lock_dependent (arch/arm64/include/asm/current.h:19
include/linux/ww_mutex.h:111
drivers/regulator/core.c:329)
but task is already holding lock:
ffffff8004a77160 (regulator_ww_class_mutex){+.+.}-{3:3}, at:
regulator_lock_recursive (drivers/regulator/core.c:156
drivers/regulator/core.c:263)
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (regulator_ww_class_mutex){+.+.}-{3:3}:
__mutex_lock_common (include/asm-generic/atomic-instrumented.h:606
include/asm-generic/atomic-long.h:29
kernel/locking/mutex.c:103
kernel/locking/mutex.c:144
kernel/locking/mutex.c:963)
ww_mutex_lock (kernel/locking/mutex.c:1199)
regulator_lock_recursive (drivers/regulator/core.c:156
drivers/regulator/core.c:263)
regulator_lock_dependent (drivers/regulator/core.c:343)
regulator_enable (drivers/regulator/core.c:2808)
set_machine_constraints (drivers/regulator/core.c:1536)
regulator_register (drivers/regulator/core.c:5486)
devm_regulator_register (drivers/regulator/devres.c:196)
reg_fixed_voltage_probe (drivers/regulator/fixed.c:289)
platform_probe (drivers/base/platform.c:1427)
[...]
-> #1 (regulator_ww_class_acquire){+.+.}-{0:0}:
regulator_lock_dependent (include/linux/ww_mutex.h:129
drivers/regulator/core.c:329)
regulator_enable (drivers/regulator/core.c:2808)
set_machine_constraints (drivers/regulator/core.c:1536)
regulator_register (drivers/regulator/core.c:5486)
devm_regulator_register (drivers/regulator/devres.c:196)
reg_fixed_voltage_probe (drivers/regulator/fixed.c:289)
[...]
-> #0 (regulator_list_mutex){+.+.}-{3:3}:
__lock_acquire (kernel/locking/lockdep.c:3052 (discriminator 4)
kernel/locking/lockdep.c:3174 (discriminator 4)
kernel/locking/lockdep.c:3789 (discriminator 4)
kernel/locking/lockdep.c:5015 (discriminator 4))
lock_acquire (arch/arm64/include/asm/percpu.h:39
kernel/locking/lockdep.c:438
kernel/locking/lockdep.c:5627)
__mutex_lock_common (include/asm-generic/atomic-instrumented.h:606
include/asm-generic/atomic-long.h:29
kernel/locking/mutex.c:103
kernel/locking/mutex.c:144
kernel/locking/mutex.c:963)
mutex_lock_nested (kernel/locking/mutex.c:1125)
regulator_lock_dependent (arch/arm64/include/asm/current.h:19
include/linux/ww_mutex.h:111
drivers/regulator/core.c:329)
regulator_enable (drivers/regulator/core.c:2808)
vctrl_enable (drivers/regulator/vctrl-regulator.c:400)
_regulator_do_enable (drivers/regulator/core.c:2617)
_regulator_enable (drivers/regulator/core.c:2764)
regulator_enable (drivers/regulator/core.c:308
drivers/regulator/core.c:2809)
_set_opp (drivers/opp/core.c:819 drivers/opp/core.c:1072)
dev_pm_opp_set_rate (drivers/opp/core.c:1164)
set_target (drivers/cpufreq/cpufreq-dt.c:62)
__cpufreq_driver_target (drivers/cpufreq/cpufreq.c:2216
drivers/cpufreq/cpufreq.c:2271)
cpufreq_online (drivers/cpufreq/cpufreq.c:1488 (discriminator 2))
cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1563)
subsys_interface_register (drivers/base/bus.c:?)
cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2819)
dt_cpufreq_probe (drivers/cpufreq/cpufreq-dt.c:344)
[...]
other info that might help us debug this:
Chain exists of:
regulator_list_mutex --> regulator_ww_class_acquire --> regulator_ww_class_mutex
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(regulator_ww_class_mutex);
lock(regulator_ww_class_acquire);
lock(regulator_ww_class_mutex);
lock(regulator_list_mutex);
*** DEADLOCK ***
6 locks held by swapper/0/1:
#0: ffffff8002d32188 (&dev->mutex){....}-{3:3}, at:
__device_driver_lock (drivers/base/dd.c:1030)
#1: ffffffc0111a0520 (cpu_hotplug_lock){++++}-{0:0}, at:
cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2792 (discriminator 2))
#2: ffffff8002a8d918 (subsys mutex#9){+.+.}-{3:3}, at:
subsys_interface_register (drivers/base/bus.c:1033)
#3: ffffff800341bb90 (&policy->rwsem){+.+.}-{3:3}, at:
cpufreq_online (include/linux/bitmap.h:285
include/linux/cpumask.h:405
drivers/cpufreq/cpufreq.c:1399)
#4: ffffffc011f0b7b8 (regulator_ww_class_acquire){+.+.}-{0:0}, at:
regulator_enable (drivers/regulator/core.c:2808)
#5: ffffff8004a77160 (regulator_ww_class_mutex){+.+.}-{3:3}, at:
regulator_lock_recursive (drivers/regulator/core.c:156
drivers/regulator/core.c:263)
stack backtrace:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.14.0-rc6 #2 7c8f8996d021ed0f65271e6aeebf7999de74a9fa
Hardware name: Google Scarlet (DT)
Call trace:
dump_backtrace (arch/arm64/kernel/stacktrace.c:161)
show_stack (arch/arm64/kernel/stacktrace.c:218)
dump_stack_lvl (lib/dump_stack.c:106 (discriminator 2))
dump_stack (lib/dump_stack.c:113)
print_circular_bug (kernel/locking/lockdep.c:?)
check_noncircular (kernel/locking/lockdep.c:?)
__lock_acquire (kernel/locking/lockdep.c:3052 (discriminator 4)
kernel/locking/lockdep.c:3174 (discriminator 4)
kernel/locking/lockdep.c:3789 (discriminator 4)
kernel/locking/lockdep.c:5015 (discriminator 4))
lock_acquire (arch/arm64/include/asm/percpu.h:39
kernel/locking/lockdep.c:438
kernel/locking/lockdep.c:5627)
__mutex_lock_common (include/asm-generic/atomic-instrumented.h:606
include/asm-generic/atomic-long.h:29
kernel/locking/mutex.c:103
kernel/locking/mutex.c:144
kernel/locking/mutex.c:963)
mutex_lock_nested (kernel/locking/mutex.c:1125)
regulator_lock_dependent (arch/arm64/include/asm/current.h:19
include/linux/ww_mutex.h:111
drivers/regulator/core.c:329)
regulator_enable (drivers/regulator/core.c:2808)
vctrl_enable (drivers/regulator/vctrl-regulator.c:400)
_regulator_do_enable (drivers/regulator/core.c:2617)
_regulator_enable (drivers/regulator/core.c:2764)
regulator_enable (drivers/regulator/core.c:308
drivers/regulator/core.c:2809)
_set_opp (drivers/opp/core.c:819 drivers/opp/core.c:1072)
dev_pm_opp_set_rate (drivers/opp/core.c:1164)
set_target (drivers/cpufreq/cpufreq-dt.c:62)
__cpufreq_driver_target (drivers/cpufreq/cpufreq.c:2216
drivers/cpufreq/cpufreq.c:2271)
cpufreq_online (drivers/cpufreq/cpufreq.c:1488 (discriminator 2))
cpufreq_add_dev (drivers/cpufreq/cpufreq.c:1563)
subsys_interface_register (drivers/base/bus.c:?)
cpufreq_register_driver (drivers/cpufreq/cpufreq.c:2819)
dt_cpufreq_probe (drivers/cpufreq/cpufreq-dt.c:344)
[...]
Reported-by: Brian Norris <briannorris@chromium.org>
Fixes: f8702f9e4aa7 ("regulator: core: Use ww_mutex for regulators locking")
Fixes: e9153311491d ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20210825033704.3307263-3-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b8c55ecd2b35c78c0f645cb2a7c027d0d9da682e
Author: Chen-Yu Tsai <wenst@chromium.org>
Date: Wed Aug 25 11:37:03 2021 +0800
regulator: vctrl: Use locked regulator_get_voltage in probe path
[ Upstream commit 98e47570ba985f2310586c80409238200fa3170f ]
In commit e9153311491d ("regulator: vctrl-regulator: Avoid deadlock getting
and setting the voltage"), all calls to get/set the voltage of the
control regulator were switched to unlocked versions to avoid deadlocks.
However, the call in the probe path is done without regulator locks
held. In this case the locked version should be used.
Switch back to the locked regulator_get_voltage() in the probe path to
avoid any mishaps.
Fixes: e9153311491d ("regulator: vctrl-regulator: Avoid deadlock getting and setting the voltage")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20210825033704.3307263-2-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 9ea94e02ac381845381c93dc1ad07d0cd5700026
Author: Eric Biggers <ebiggers@google.com>
Date: Tue Aug 24 22:59:18 2021 -0700
blk-crypto: fix check for too-large dun_bytes
[ Upstream commit cc40b7225151f611ef837f6403cfaeadc7af214a ]
dun_bytes needs to be less than or equal to the IV size of the
encryption mode, not just less than or equal to BLK_CRYPTO_MAX_IV_SIZE.
Currently this doesn't matter since blk_crypto_init_key() is never
actually passed invalid values, but we might as well fix this.
Fixes: a892c8d52c02 ("block: Inline encryption support for blk-mq")
Signed-off-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20210825055918.51975-1-ebiggers@kernel.org
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 81ff155555f61c9625ceb7ff90b04d1cc86a19ee
Author: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com>
Date: Tue Aug 24 11:25:56 2021 +0200
spi: davinci: invoke chipselect callback
[ Upstream commit ea4ab99cb58cc9f8d64c0961ff9a059825f304cf ]
Davinci needs to configure chipselect on transfer.
Fixes: 4a07b8bcd503 ("spi: bitbang: Make chipselect callback optional")
Signed-off-by: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nokia.com>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Link: https://lore.kernel.org/r/735fb7b0-82aa-5b9b-85e4-53f0c348cc0e@nokia.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 97ffb7a107905c62cb658f319876ae170833d9e4
Author: Borislav Petkov <bp@alien8.de>
Date: Mon Aug 23 17:31:29 2021 -0700
x86/mce: Defer processing of early errors
[ Upstream commit 3bff147b187d5dfccfca1ee231b0761a89f1eff5 ]
When a fatal machine check results in a system reset, Linux does not
clear the error(s) from machine check bank(s) - hardware preserves the
machine check banks across a warm reset.
During initialization of the kernel after the reboot, Linux reads, logs,
and clears all machine check banks.
But there is a problem. In:
5de97c9f6d85 ("x86/mce: Factor out and deprecate the /dev/mcelog driver")
the call to mce_register_decode_chain() moved later in the boot
sequence. This means that /dev/mcelog doesn't see those early error
logs.
This was partially fixed by:
cd9c57cad3fe ("x86/MCE: Dump MCE to dmesg if no consumers")
which made sure that the logs were not lost completely by printing
to the console. But parsing console logs is error prone. Users of
/dev/mcelog should expect to find any early errors logged to standard
places.
Add a new flag MCP_QUEUE_LOG to machine_check_poll() to be used in early
machine check initialization to indicate that any errors found should
just be queued to genpool. When mcheck_late_init() is called it will
call mce_schedule_work() to actually log and flush any errors queued in
the genpool.
[ Based on an original patch, commit message by and completely
productized by Tony Luck. ]
Fixes: 5de97c9f6d85 ("x86/mce: Factor out and deprecate the /dev/mcelog driver")
Reported-by: Sumanth Kamatala <skamatala@juniper.net>
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20210824003129.GA1642753@agluck-desk2.amr.corp.intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4304127d63f2b46ce8df80264f986efe2e44ccfb
Author: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Date: Wed Aug 18 10:57:00 2021 -0700
EDAC/i10nm: Fix NVDIMM detection
[ Upstream commit 2294a7299f5e51667b841f63c6d69474491753fb ]
MCDDRCFG is a per-channel register and uses bit{0,1} to indicate
the NVDIMM presence on DIMM slot{0,1}. Current i10nm_edac driver
wrongly uses MCDDRCFG as per-DIMM register and fails to detect
the NVDIMM.
Fix it by reading MCDDRCFG as per-channel register and using its
bit{0,1} to check whether the NVDIMM is populated on DIMM slot{0,1}.
Fixes: d4dc89d069aa ("EDAC, i10nm: Add a driver for Intel 10nm server processors")
Reported-by: Fan Du <fan.du@intel.com>
Tested-by: Wen Jin <wen.jin@intel.com>
Signed-off-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/r/20210818175701.1611513-2-tony.luck@intel.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 196f5d734acdd3f3c6dbd57066415091db6bec99
Author: Stefan Berger <stefanb@linux.ibm.com>
Date: Thu Aug 12 22:45:48 2021 +0300
tpm: ibmvtpm: Avoid error message when process gets signal while waiting
[ Upstream commit 047d4226b0bca1cda5267dc68bc8291cce5364ac ]
When rngd is run as root then lots of these types of message will appear
in the kernel log if the TPM has been configured to provide random bytes:
[ 7406.275163] tpm tpm0: tpm_transmit: tpm_recv: error -4
The issue is caused by the following call that is interrupted while
waiting for the TPM's response.
sig = wait_event_interruptible(ibmvtpm->wq, !ibmvtpm->tpm_processing_cmd);
Rather than waiting for the response in the low level driver, have it use
the polling loop in tpm_try_transmit() that uses a command's duration to
poll until a result has been returned by the TPM, thus ending when the
timeout has occurred but not responding to signals and ctrl-c anymore. To
stay in this polling loop extend tpm_ibmvtpm_status() to return
'true' for as long as the vTPM is indicated as being busy in
tpm_processing_cmd. Since the loop requires the TPM's timeouts, get them
now using tpm_get_timeouts() after setting the TPM2 version flag on the
chip.
To recreat the resolved issue start rngd like this:
sudo rngd -r /dev/hwrng -t
sudo rngd -r /dev/tpm0 -t
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1981473
Fixes: 6674ff145eef ("tpm_ibmvtpm: properly handle interrupted packet receptions")
Cc: Nayna Jain <nayna@linux.ibm.com>
Cc: George Wilson <gcwilson@linux.ibm.com>
Reported-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Tested-by: Nageswara R Sastry <rnsastry@linux.ibm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4ff3fe1bd4310263807448c8455e738010300616
Author: Stefan Berger <stefanb@linux.ibm.com>
Date: Tue Jun 29 17:34:20 2021 -0400
certs: Trigger creation of RSA module signing key if it's not an RSA key
[ Upstream commit ea35e0d5df6c92fa2e124bb1b91d09b2240715ba ]
Address a kbuild issue where a developer created an ECDSA key for signing
kernel modules and then builds an older version of the kernel, when bi-
secting the kernel for example, that does not support ECDSA keys.
If openssl is installed, trigger the creation of an RSA module signing
key if it is not an RSA key.
Fixes: cfc411e7fff3 ("Move certificate handling to its own directory")
Cc: David Howells <dhowells@redhat.com>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Tested-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Jarkko Sakkinen <jarkko@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 4014261e3edba37032ccc4d45368bbedbd008e44
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Mon Aug 9 13:29:03 2021 +0200
m68k: Fix asm register constraints for atomic ops
[ Upstream commit 87d93029fe83e326d5b906e12e95600b157d2c0d ]
Depending on register assignment by the compiler:
{standard input}:3084: Error: operands mismatch -- statement `andl %a1,%d1' ignored
{standard input}:3145: Error: operands mismatch -- statement `orl %a1,%d1' ignored
{standard input}:3195: Error: operands mismatch -- statement `eorl %a1,%d1' ignored
Indeed, the first operand must not be an address register. However, it
can be an immediate value. Fix this by adjusting the register
constraint from "g" (general purpose register) to "di" (data register or
immediate).
Fixes: e39d88ea3ce4a471 ("locking/atomic, arch/m68k: Implement atomic_fetch_{add,sub,and,or,xor}()")
Fixes: d839bae4269aea46 ("locking,arch,m68k: Fold atomic_ops")
Fixes: 1da177e4c3f41524 ("Linux-2.6.12-rc2")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Reported-by: Alexander Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Tested-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210809112903.3898660-1-geert@linux-m68k.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a582ad6639849d6d8ef29ea89f082bcbf922d116
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date: Thu Aug 12 21:21:10 2021 +0100
crypto: qat - use proper type for vf_mask
[ Upstream commit 462354d986b6a89c6449b85f17aaacf44e455216 ]
Replace vf_mask type with unsigned long to avoid a stack-out-of-bound.
This is to fix the following warning reported by KASAN the first time
adf_msix_isr_ae() gets called.
[ 692.091987] BUG: KASAN: stack-out-of-bounds in find_first_bit+0x28/0x50
[ 692.092017] Read of size 8 at addr ffff88afdf789e60 by task swapper/32/0
[ 692.092076] Call Trace:
[ 692.092089] <IRQ>
[ 692.092101] dump_stack+0x9c/0xcf
[ 692.092132] print_address_description.constprop.0+0x18/0x130
[ 692.092164] ? find_first_bit+0x28/0x50
[ 692.092185] kasan_report.cold+0x7f/0x111
[ 692.092213] ? static_obj+0x10/0x80
[ 692.092234] ? find_first_bit+0x28/0x50
[ 692.092262] find_first_bit+0x28/0x50
[ 692.092288] adf_msix_isr_ae+0x16e/0x230 [intel_qat]
Fixes: ed8ccaef52fa ("crypto: qat - Add support for SRIOV")
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Marco Chiappero <marco.chiappero@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7880c9f91b79d4e36093371d0de5e58f49a9350b
Author: Chen-Yu Tsai <wenst@chromium.org>
Date: Thu Aug 12 01:15:05 2021 +0800
irqchip/gic-v3: Fix priority comparison when non-secure priorities are used
[ Upstream commit 8d474deaba2c4dd33a5e2f5be82e6798ffa6b8a5 ]
When non-secure priorities are used, compared to the raw priority set,
the value read back from RPR is also right-shifted by one and the
highest bit set.
Add a macro to do the modifications to the raw priority when doing the
comparison against the RPR value. This corrects the pseudo-NMI behavior
when non-secure priorities in the GIC are used. Tested on 5.10 with
the "IPI as pseudo-NMI" series [1] applied on MT8195.
[1] https://lore.kernel.org/linux-arm-kernel/1604317487-14543-1-git-send-email-sumit.garg@linaro.org/
Fixes: 336780590990 ("irqchip/gic-v3: Support pseudo-NMIs when SCR_EL3.FIQ == 0")
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
[maz: Added comment contributed by Alex]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210811171505.1502090-1-wenst@chromium.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 37d6a4fc71961a1d646a39fe5598954d3ff70aa4
Author: Sven Peter <sven@svenpeter.dev>
Date: Thu Aug 12 12:09:42 2021 +0200
irqchip/apple-aic: Fix irq_disable from within irq handlers
[ Upstream commit 60a1cd10b222e004f860d14651e80089c77e8e6b ]
When disable_irq_nosync for an interrupt is called from within its
interrupt handler, this interrupt is only marked as disabled with the
intention to mask it when it triggers again.
The AIC hardware however automatically masks the interrupt when it is read.
aic_irq_eoi then unmasks it again if it's not disabled *and* not masked.
This results in a state mismatch between the hardware state and the
state kept in irq_data: The hardware interrupt is masked but
IRQD_IRQ_MASKED is not set. Any further calls to unmask_irq will directly
return and the interrupt can never be enabled again.
Fix this by keeping the hardware and irq_data state in sync by unmasking in
aic_irq_eoi if and only if the irq_data state also assumes the interrupt to
be unmasked.
Fixes: 76cde2639411 ("irqchip/apple-aic: Add support for the Apple Interrupt Controller")
Signed-off-by: Sven Peter <sven@svenpeter.dev>
Acked-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210812100942.17206-1-sven@svenpeter.dev
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 280bbb7044680831779e5e113ca2f50df9eed1ab
Author: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Date: Wed Aug 18 22:55:56 2021 +0200
spi: coldfire-qspi: Use clk_disable_unprepare in the remove function
[ Upstream commit d68f4c73d729245a47e70eb216fa24bc174ed2e2 ]
'clk_prepare_enable()' is used in the probe, so 'clk_disable_unprepare()'
should be used in the remove function to be consistent.
Fixes: 499de01c5c0b ("spi: coldfire-qspi: Use clk_prepare_enable and clk_disable_unprepare")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/ee91792ddba61342b0d3284cd4558a2b0016c4e7.1629319838.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 33bbe22d117e82e5712b562f68a34719ad7f4476
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Thu Aug 12 12:15:01 2021 +0300
block: nbd: add sanity check for first_minor
[ Upstream commit b1a811633f7321cf1ae2bb76a66805b7720e44c9 ]
Syzbot hit WARNING in internal_create_group(). The problem was in
too big disk->first_minor.
disk->first_minor is initialized by value, which comes from userspace
and there wasn't any sanity checks about value correctness. It can cause
duplicate creation of sysfs files/links, because disk->first_minor will
be passed to MKDEV() which causes truncation to byte. Since maximum
minor value is 0xff, let's check if first_minor is correct minor number.
NOTE: the root case of the reported warning was in wrong error handling
in register_disk(), but we can avoid passing knowingly wrong values to
sysfs API, because sysfs error messages can confuse users. For example:
user passed 1048576 as index, but sysfs complains about duplicate
creation of /dev/block/43:0. It's not obvious how 1048576 becomes 0.
Log and reproducer for above example can be found on syzkaller bug
report page.
Link: https://syzkaller.appspot.com/bug?id=03c2ae9146416edf811958d5fd7acfab75b143d1
Fixes: b0d9111a2d53 ("nbd: use an idr to keep track of nbd devices")
Reported-by: syzbot+9937dc42271cd87d4b98@syzkaller.appspotmail.com
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 972b911023193d804682a4a0a6f90a6e2005bed3
Author: Hou Tao <houtao1@huawei.com>
Date: Wed Aug 11 14:44:23 2021 +0200
nbd: do del_gendisk() asynchronously for NBD_DESTROY_ON_DISCONNECT
[ Upstream commit 68c9417b193d0d174b0ada013602272177e61303 ]
Now open_mutex is used to synchronize partition operations (e.g,
blk_drop_partitions() and blkdev_reread_part()), however it makes
nbd driver broken, because nbd may call del_gendisk() in nbd_release()
or nbd_genl_disconnect() if NBD_CFLAG_DESTROY_ON_DISCONNECT is enabled,
and deadlock occurs, as shown below:
// AB-BA dead-lock
nbd_genl_disconnect blkdev_open
nbd_disconnect_and_put
lock bd_mutex
// last ref
nbd_put
lock nbd_index_mutex
del_gendisk
nbd_open
try lock nbd_index_mutex
try lock bd_mutex
or
// AA dead-lock
nbd_release
lock bd_mutex
nbd_put
try lock bd_mutex
Instead of fixing block layer (e.g, introduce another lock), fixing
the nbd driver to call del_gendisk() in a kworker when
NBD_DESTROY_ON_DISCONNECT is enabled. When NBD_DESTROY_ON_DISCONNECT
is disabled, nbd device will always be destroy through module removal,
and there is no risky of deadlock.
To ensure the reuse of nbd index succeeds, moving the calling of
idr_remove() after del_gendisk(), so if the reused index is not found
in nbd_index_idr, the old disk must have been deleted. And reusing
the existing destroy_complete mechanism to ensure nbd_genl_connect()
will wait for the completion of del_gendisk().
Also adding a new workqueue for nbd removal, so nbd_cleanup()
can ensure all removals complete before exits.
Reported-by: syzbot+0fe7752e52337864d29b@syzkaller.appspotmail.com
Fixes: c76f48eb5c08 ("block: take bd_mutex around delete_partitions in del_gendisk")
Signed-off-by: Hou Tao <houtao1@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Link: https://lore.kernel.org/r/20210811124428.2368491-2-hch@lst.de
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 762b449fad981aa9cb97e246213640d664dd339d
Author: Phong Hoang <phong.hoang.wz@renesas.com>
Date: Thu Apr 22 14:34:43 2021 +0200
clocksource/drivers/sh_cmt: Fix wrong setting if don't request IRQ for clock source channel
[ Upstream commit be83c3b6e7b8ff22f72827a613bf6f3aa5afadbb ]
If CMT instance has at least two channels, one channel will be used
as a clock source and another one used as a clock event device.
In that case, IRQ is not requested for clock source channel so
sh_cmt_clock_event_program_verify() might work incorrectly.
Besides, when a channel is only used for clock source, don't need to
re-set the next match_value since it should be maximum timeout as
it still is.
On the other hand, due to no IRQ, total_cycles is not counted up
when reaches compare match time (timer counter resets to zero),
so sh_cmt_clocksource_read() returns unexpected value.
Therefore, use 64-bit clocksoure's mask for 32-bit or 16-bit variants
will also lead to wrong delta calculation. Hence, this mask should
correspond to timer counter width, and above function just returns
the raw value of timer counter register.
Fixes: bfa76bb12f23 ("clocksource: sh_cmt: Request IRQ for clock event device only")
Fixes: 37e7742c55ba ("clocksource/drivers/sh_cmt: Fix clocksource width for 32-bit machines")
Signed-off-by: Phong Hoang <phong.hoang.wz@renesas.com>
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/20210422123443.73334-1-niklas.soderlund+renesas@ragnatech.se
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1351a4663c14321ce31dfb604e5aadee25ac717d
Author: Hongbo Li <herberthbli@tencent.com>
Date: Thu Aug 5 16:53:32 2021 +0800
lib/mpi: use kcalloc in mpi_resize
[ Upstream commit b6f756726e4dfe75be1883f6a0202dcecdc801ab ]
We should set the additional space to 0 in mpi_resize().
So use kcalloc() instead of kmalloc_array().
In lib/mpi/ec.c:
/****************
* Resize the array of A to NLIMBS. the additional space is cleared
* (set to 0) [done by m_realloc()]
*/
int mpi_resize(MPI a, unsigned nlimbs)
Like the comment of kernel's mpi_resize() said, the additional space
need to be set to 0, but when a->d is not NULL, it does not set.
The kernel's mpi lib is from libgcrypt, the mpi resize in libgcrypt
is _gcry_mpi_resize() which set the additional space to 0.
This bug may cause mpi api which use mpi_resize() get wrong result
under the condition of using the additional space without initiation.
If this condition is not met, the bug would not be triggered.
Currently in kernel, rsa, sm2 and dh use mpi lib, and they works well,
so the bug is not triggered in these cases.
add_points_edwards() use the additional space directly, so it will
get a wrong result.
Fixes: cdec9cb5167a ("crypto: GnuPG based MPI lib - source files (part 1)")
Signed-off-by: Hongbo Li <herberthbli@tencent.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b40d83924a2b4997c669800fc3a9651189e6f4f5
Author: Huacai Chen <chenhuacai@kernel.org>
Date: Thu Aug 5 21:22:16 2021 +0800
irqchip/loongson-pch-pic: Improve edge triggered interrupt support
[ Upstream commit e5dec38ac5d05d17a7110c8045aa101015281e4d ]
Edge-triggered mode and level-triggered mode need different handlers,
and edge-triggered mode need a specific ack operation. So improve it.
Fixes: ef8c01eb64ca6719da449dab0 ("irqchip: Add Loongson PCH PIC controller")
Signed-off-by: Chen Zhu <zhuchen@loongson.cn>
Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210805132216.3539007-1-chenhuacai@loongson.cn
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 21862736617125d0828587835999853c5a4e559c
Author: Zhen Lei <thunder.leizhen@huawei.com>
Date: Wed Aug 11 17:33:32 2021 +0800
genirq/timings: Fix error return code in irq_timings_test_irqs()
[ Upstream commit 290fdc4b7ef14e33d0e30058042b0e9bfd02b89b ]
Return a negative error code from the error handling case instead of 0, as
done elsewhere in this function.
Fixes: f52da98d900e ("genirq/timings: Add selftest for irqs circular buffer")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210811093333.2376-1-thunder.leizhen@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 15a728f31e16b5b946ba1598474462f01d8d487e
Author: Tony Lindgren <tony@atomide.com>
Date: Tue Aug 10 11:17:27 2021 +0300
spi: spi-pic32: Fix issue with uninitialized dma_slave_config
[ Upstream commit 976c1de1de147bb7f4e0d87482f375221c05aeaf ]
Depending on the DMA driver being used, the struct dma_slave_config may
need to be initialized to zero for the unused data.
For example, we have three DMA drivers using src_port_window_size and
dst_port_window_size. If these are left uninitialized, it can cause DMA
failures.
For spi-pic32, this is probably not currently an issue but is still good to
fix though.
Fixes: 1bcb9f8ceb67 ("spi: spi-pic32: Add PIC32 SPI master driver")
Cc: Purna Chandra Mandal <purna.mandal@microchip.com>
Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Cc: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20210810081727.19491-2-tony@atomide.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5fa0ea507fae78540172b6818a5f6c64d6d24787
Author: Tony Lindgren <tony@atomide.com>
Date: Tue Aug 10 11:17:26 2021 +0300
spi: spi-fsl-dspi: Fix issue with uninitialized dma_slave_config
[ Upstream commit 209ab223ad5b18e437289235e3bde12593b94ac4 ]
Depending on the DMA driver being used, the struct dma_slave_config may
need to be initialized to zero for the unused data.
For example, we have three DMA drivers using src_port_window_size and
dst_port_window_size. If these are left uninitialized, it can cause DMA
failures.
For spi-fsl-dspi, this is probably not currently an issue but is still
good to fix though.
Fixes: 90ba37033cb9 ("spi: spi-fsl-dspi: Add DMA support for Vybrid")
Cc: Sanchayan Maity <maitysanchayan@gmail.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Cc: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20210810081727.19491-1-tony@atomide.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f845a7caf953271385315418bb54ea8b9be6770e
Author: Ming Lei <ming.lei@redhat.com>
Date: Thu Jul 29 11:42:26 2021 +0800
block: return ELEVATOR_DISCARD_MERGE if possible
[ Upstream commit 866663b7b52d2da267b28e12eed89ee781b8fed1 ]
When merging one bio to request, if they are discard IO and the queue
supports multi-range discard, we need to return ELEVATOR_DISCARD_MERGE
because both block core and related drivers(nvme, virtio-blk) doesn't
handle mixed discard io merge(traditional IO merge together with
discard merge) well.
Fix the issue by returning ELEVATOR_DISCARD_MERGE in this situation,
so both blk-mq and drivers just need to handle multi-range discard.
Reported-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Tested-by: Oleksandr Natalenko <oleksandr@natalenko.name>
Fixes: 2705dfb20947 ("block: fix discard request merge")
Link: https://lore.kernel.org/r/20210729034226.1591070-1-ming.lei@redhat.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit acfa62bd28ae895338f77d1f6c0377e48050167e
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Sun Jul 25 12:44:13 2021 +0200
m68k: Fix invalid RMW_INSNS on CPUs that lack CAS
[ Upstream commit 2189e928b62e91d8efbc9826ae7c0968f0d55790 ]
When enabling CONFIG_RMW_INSNS in e.g. a Coldfire build:
{standard input}:3068: Error: invalid instruction for this architecture; needs 68020 or higher (68020 [68k, 68ec020], 68030 [68ec030], 68040 [68ec040], 68060 [68ec060]) -- statement `casl %d4,%d0,(%a6)' ignored
Fix this by (a) adding a new config symbol to track if support for any
CPU that lacks the CAS instruction is enabled, and (b) making
CONFIG_RMW_INSNS depend on the new symbol not being set.
Fixes: 0e152d80507b75c0 ("m68k: reorganize Kconfig options to improve mmu/non-mmu selections")
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210725104413.318932-1-geert@linux-m68k.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8af14fb35efc7279d390fc7e7c6054b59c65b167
Author: Yanfei Xu <yanfei.xu@windriver.com>
Date: Sun May 16 17:50:10 2021 +0800
rcu: Fix stall-warning deadlock due to non-release of rcu_node ->lock
[ Upstream commit dc87740c8a6806bd2162bfb441770e4e53be5601 ]
If rcu_print_task_stall() is invoked on an rcu_node structure that does
not contain any tasks blocking the current grace period, it takes an
early exit that fails to release that rcu_node structure's lock. This
results in a self-deadlock, which is detected by lockdep.
To reproduce this bug:
tools/testing/selftests/rcutorture/bin/kvm.sh --allcpus --duration 3 --trust-make --configs "TREE03" --kconfig "CONFIG_PROVE_LOCKING=y" --bootargs "rcutorture.stall_cpu=30 rcutorture.stall_cpu_block=1 rcutorture.fwd_progress=0 rcutorture.test_boost=0"
This will also result in other complaints, including RCU's scheduler
hook complaining about blocking rather than preemption and an rcutorture
writer stall.
Only a partial RCU CPU stall warning message will be printed because of
the self-deadlock.
This commit therefore releases the lock on the rcu_print_task_stall()
function's early exit path.
Fixes: c583bcb8f5ed ("rcu: Don't invoke try_invoke_on_locked_down_task() with irqs disabled")
Tested-by: Qais Yousef <qais.yousef@arm.com>
Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0133d52e0eb243c98880a4dcb0d00d350eeb6449
Author: Yanfei Xu <yanfei.xu@windriver.com>
Date: Sun May 16 00:45:11 2021 +0800
rcu: Fix to include first blocked task in stall warning
[ Upstream commit e6a901a44f76878ed1653626c9ff4cfc5a3f58f8 ]
The for loop in rcu_print_task_stall() always omits ts[0], which points
to the first task blocking the stalled grace period. This in turn fails
to count this first task, which means that ndetected will be equal to
zero when all CPUs have passed through their quiescent states and only
one task is blocking the stalled grace period. This zero value for
ndetected will in turn result in an incorrect "All QSes seen" message:
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: Tasks blocked on level-1 rcu_node (CPUs 12-23):
(detected by 15, t=6504 jiffies, g=164777, q=9011209)
rcu: All QSes seen, last rcu_preempt kthread activity 1 (4295252379-4295252378), jiffies_till_next_fqs=1, root ->qsmask 0x2
BUG: sleeping function called from invalid context at include/linux/uaccess.h:156
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 70613, name: msgstress04
INFO: lockdep is turned off.
Preemption disabled at:
[<ffff8000104031a4>] create_object.isra.0+0x204/0x4b0
CPU: 15 PID: 70613 Comm: msgstress04 Kdump: loaded Not tainted
5.12.2-yoctodev-standard #1
Hardware name: Marvell OcteonTX CN96XX board (DT)
Call trace:
dump_backtrace+0x0/0x2cc
show_stack+0x24/0x30
dump_stack+0x110/0x188
___might_sleep+0x214/0x2d0
__might_sleep+0x7c/0xe0
This commit therefore fixes the loop to include ts[0].
Fixes: c583bcb8f5ed ("rcu: Don't invoke try_invoke_on_locked_down_task() with irqs disabled")
Tested-by: Qais Yousef <qais.yousef@arm.com>
Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ba3396c359a0fdefe1860667f2a5947192f4eea0
Author: Quentin Perret <qperret@google.com>
Date: Thu Aug 5 11:21:53 2021 +0100
sched: Fix UCLAMP_FLAG_IDLE setting
[ Upstream commit ca4984a7dd863f3e1c0df775ae3e744bff24c303 ]
The UCLAMP_FLAG_IDLE flag is set on a runqueue when dequeueing the last
uclamp active task (that is, when buckets.tasks reaches 0 for all
buckets) to maintain the last uclamp.max and prevent blocked util from
suddenly becoming visible.
However, there is an asymmetry in how the flag is set and cleared which
can lead to having the flag set whilst there are active tasks on the rq.
Specifically, the flag is cleared in the uclamp_rq_inc() path, which is
called at enqueue time, but set in uclamp_rq_dec_id() which is called
both when dequeueing a task _and_ in the update_uclamp_active() path. As
a result, when both uclamp_rq_{dec,ind}_id() are called from
update_uclamp_active(), the flag ends up being set but not cleared,
hence leaving the runqueue in a broken state.
Fix this by clearing the flag in update_uclamp_active() as well.
Fixes: e496187da710 ("sched/uclamp: Enforce last task's UCLAMP_MAX")
Reported-by: Rick Yiu <rickyiu@google.com>
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Qais Yousef <qais.yousef@arm.com>
Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Link: https://lore.kernel.org/r/20210805102154.590709-2-qperret@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 54ae668378baed204fb019d682735e0d6d71a369
Author: Mika Penttilä <mika.penttila@gmail.com>
Date: Thu Jul 22 09:39:46 2021 +0300
sched/numa: Fix is_core_idle()
[ Upstream commit 1c6829cfd3d5124b125e6df41158665aea413b35 ]
Use the loop variable instead of the function argument to test the
other SMT siblings for idle.
Fixes: ff7db0bf24db ("sched/numa: Prefer using an idle CPU as a migration target instead of comparing tasks")
Signed-off-by: Mika Penttilä <mika.penttila@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Acked-by: Pankaj Gupta <pankaj.gupta@ionos.com>
Link: https://lkml.kernel.org/r/20210722063946.28951-1-mika.penttila@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7f64bb547139ebc4914e28ee62cac1f497b84fcf
Author: Mian Yousaf Kaukab <ykaukab@suse.de>
Date: Wed Jul 21 10:39:05 2021 +0200
crypto: ecc - handle unaligned input buffer in ecc_swap_digits
[ Upstream commit 0469dede0eeeefe12a9a2fd76078f4a266513457 ]
ecdsa_set_pub_key() makes an u64 pointer at 1 byte offset of the key.
This results in an unaligned u64 pointer. This pointer is passed to
ecc_swap_digits() which assumes natural alignment.
This causes a kernel crash on an armv7 platform:
[ 0.409022] Unhandled fault: alignment exception (0x001) at 0xc2a0a6a9
...
[ 0.416982] PC is at ecdsa_set_pub_key+0xdc/0x120
...
[ 0.491492] Backtrace:
[ 0.492059] [<c07c266c>] (ecdsa_set_pub_key) from [<c07c75d4>] (test_akcipher_one+0xf4/0x6c0)
Handle unaligned input buffer in ecc_swap_digits() by replacing
be64_to_cpu() to get_unaligned_be64(). Change type of in pointer to
void to reflect it doesn’t necessarily need to be aligned.
Fixes: 4e6602916bc6 ("crypto: ecdsa - Add support for ECDSA signature verification")
Reported-by: Guillaume Gardet <guillaume.gardet@arm.com>
Suggested-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de>
Tested-by: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ff945fafb3511bc9daeb0b0f5664c051ba182b3a
Author: Ard Biesheuvel <ardb@kernel.org>
Date: Fri Jul 16 18:54:03 2021 +0200
crypto: x86/aes-ni - add missing error checks in XTS code
[ Upstream commit 821720b9f34ec54106ebf012a712ba73bbcf47c2 ]
The updated XTS code fails to check the return code of skcipher_walk_virt,
which may lead to skcipher_walk_abort() or skcipher_walk_done() being called
while the walk argument is in an inconsistent state.
So check the return value after each such call, and bail on errors.
Fixes: 2481104fe98d ("crypto: x86/aes-ni-xts - rewrite and drop indirections via glue helper")
Reported-by: Dave Hansen <dave.hansen@intel.com>
Reported-by: syzbot <syzbot+5d1bad8042a8f0e8117a@syzkaller.appspotmail.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit bbeb9bbf610d0fae00bc659aad23d1a46e8cacc4
Author: Pavel Skripkin <paskripkin@gmail.com>
Date: Mon Jul 5 23:47:27 2021 +0300
m68k: emu: Fix invalid free in nfeth_cleanup()
[ Upstream commit 761608f5cf70e8876c2f0e39ca54b516bdcb7c12 ]
In the for loop all nfeth_dev array members should be freed, not only
the first one. Freeing only the first array member can cause
double-free bugs and memory leaks.
Fixes: 9cd7b148312f ("m68k/atari: ARAnyM - Add support for network access")
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Link: https://lore.kernel.org/r/20210705204727.10743-1-paskripkin@gmail.com
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ed8c625a63a11eec622526f9465dd0854d0f4055
Author: Peter Robinson <pbrobinson@gmail.com>
Date: Thu Jul 1 23:05:16 2021 +0100
power: supply: cw2015: use dev_err_probe to allow deferred probe
[ Upstream commit ad1abe476995d97bfe7546ea91bb4f3dcdfbf3ab ]
Deal with deferred probe using dev_err_probe so the error is handled
and avoid logging lots probe defer information like the following:
[ 9.125121] cw2015 4-0062: Failed to register power supply
[ 9.211131] cw2015 4-0062: Failed to register power supply
Fixes: b4c7715c10c1 ("power: supply: add CellWise cw2015 fuel gauge driver")
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d2964558f741790b8d0f8bcdc2ab669875a431c6
Author: Valentin Schneider <valentin.schneider@arm.com>
Date: Tue May 18 14:07:25 2021 +0100
sched/debug: Don't update sched_domain debug directories before sched_debug_init()
[ Upstream commit 459b09b5a3254008b63382bf41a9b36d0b590f57 ]
Since CPU capacity asymmetry can stem purely from maximum frequency
differences (e.g. Pixel 1), a rebuild of the scheduler topology can be
issued upon loading cpufreq, see:
arch_topology.c::init_cpu_capacity_callback()
Turns out that if this rebuild happens *before* sched_debug_init() is
run (which is a late initcall), we end up messing up the sched_domain debug
directory: passing a NULL parent to debugfs_create_dir() ends up creating
the directory at the debugfs root, which in this case creates
/sys/kernel/debug/domains (instead of /sys/kernel/debug/sched/domains).
This currently doesn't happen on asymmetric systems which use cpufreq-scpi
or cpufreq-dt drivers, as those are loaded via
deferred_probe_initcall() (it is also a late initcall, but appears to be
ordered *after* sched_debug_init()).
Ionela has been working on detecting maximum frequency asymmetry via ACPI,
and that actually happens via a *device* initcall, thus before
sched_debug_init(), and causes the aforementionned debugfs mayhem.
One option would be to punt sched_debug_init() down to
fs_initcall_sync(). Preventing update_sched_domain_debugfs() from running
before sched_debug_init() appears to be the safer option.
Fixes: 3b87f136f8fc ("sched,debug: Convert sysctl sched_domains to debugfs")
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: http://lore.kernel.org/r/20210514095339.12979-1-ionela.voinescu@arm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ab6999a4e0f677df9dc91d4b0a4b41988019f900
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date: Tue Aug 24 15:30:21 2021 +0200
s390/smp: enable DAT before CPU restart callback is called
[ Upstream commit 915fea04f9320d0f4ab6ecbb6bf759eebcd2c41d ]
The restart interrupt is triggered whenever a secondary CPU is
brought online, a remote function call dispatched from another
CPU or a manual PSW restart is initiated and causes the system
to kdump. The handling routine is always called with DAT turned
off. It then initializes the stack frame and invokes a callback.
The existing callbacks handle DAT as follows:
* __do_restart() and __machine_kexec() turn in on upon entry;
* __ipl_run(), __reipl_run() and __dump_run() do not turn it
right away, but all of them call diag308() - which turns DAT
on, but only if kasan is enabled;
In addition to the described complexity all callbacks (and the
functions they call) should avoid kasan instrumentation while
DAT is off.
This update enables DAT in the assembler restart handler and
relieves any callbacks (which are mostly C functions) from
dealing with DAT altogether.
There are four types of CPU restart that initialize control
registers in different ways:
1. Start of secondary CPU on boot - control registers are
inherited from the IPL CPU;
2. Restart of online CPU - control registers of the CPU being
restarted are kept;
3. Hotplug of offline CPU - control registers are inherited
from the starting CPU;
4. Start of offline CPU triggered by manual PSW restart -
the control registers are read from the absolute lowcore
and contain the boot time IPL CPU values updated with all
follow-up calls of smp_ctl_set_bit() and smp_ctl_clear_bit()
routines;
In first three cases contents of the control registers is the
most recent. In the latter case control registers are good
enough to facilitate successful completion of kdump operation.
Suggested-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 1409e626dcad39d30669b5191949c53ca829ace8
Author: Harald Freudenberger <freude@linux.ibm.com>
Date: Wed Aug 25 10:55:02 2021 +0200
s390/ap: fix state machine hang after failure to enable irq
[ Upstream commit cabebb697c98fb1f05cc950a747a9b6ec61a5b01 ]
If for any reason the interrupt enable for an ap queue fails the
state machine run for the queue returned wrong return codes to the
caller. So the caller assumed interrupt support for this queue in
enabled and thus did not re-establish the high resolution timer used
for polling. In the end this let to a hang for the user space process
waiting "forever" for the reply.
This patch reworks these return codes to return correct indications
for the caller to re-establish the timer when a queue runs without
interrupt support.
Please note that this is fixing a wrong behavior after a first
failure (enable interrupt support for the queue) failed. However,
looks like this occasionally happens on KVM systems.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit e234f66168f0d50c0d28154fb983a14e85c3c526
Author: Peter Oberparleiter <oberpar@linux.ibm.com>
Date: Fri Aug 13 15:05:03 2021 +0200
s390/debug: fix debug area life cycle
[ Upstream commit 9372a82892c2caa6bccab9a4081166fa769699f8 ]
Currently allocation and registration of s390dbf debug areas are tied
together. As a result, a debug area cannot be unregistered and
re-registered while any process has an associated debugfs file open.
Fix this by splitting alloc/release from register/unregister.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f14e3cc5a6f1c1abb92a043d9363491c12fb96f9
Author: Peter Oberparleiter <oberpar@linux.ibm.com>
Date: Fri Aug 13 15:05:02 2021 +0200
s390/debug: keep debug data on resize
[ Upstream commit 1204777867e8486a88dbb4793fe256b31ea05eeb ]
Any previously recorded s390dbf debug data is reset when a debug area
is resized using the 'pages' sysfs attribute. This can make
live-debugging unnecessarily complex.
Fix this by copying existing debug data to the newly allocated debug
area when resizing.
Signed-off-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3c0866f9dfd450f2be27e75bcea1e124752cc5a2
Author: Niklas Schnelle <schnelle@linux.ibm.com>
Date: Wed Jul 21 19:58:54 2021 +0200
s390/pci: fix misleading rc in clp_set_pci_fn()
[ Upstream commit f7addcdd527a6dddfebe20c358b87bdb95624612 ]
Currently clp_set_pci_fn() always returns 0 as long as the CLP request
itself succeeds even if the operation itself returns a response code
other than CLP_RC_OK or CLP_RC_SETPCIFN_ALRDY. This is highly misleading
because calling code assumes that a zero rc means that the operation was
successful.
Fix this by returning the response code or cc on failure with the
exception of the special handling for CLP_RC_SETPCIFN_ALRDY. Also let's
not assume that the returned function handle for CLP_RC_SETPCIFN_ALRDY
is 0, we don't need it anyway.
Reviewed-by: Matthew Rosato <mjrosato@linux.ibm.com>
Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 79481aee9b548cad4d67c714fdf4f794ef8b7654
Author: Alexander Gordeev <agordeev@linux.ibm.com>
Date: Fri Aug 6 12:55:08 2021 +0200
s390/kasan: fix large PMD pages address alignment check
[ Upstream commit ddd63c85ef67ea9ea7282ad35eafb6568047126e ]
It is currently possible to initialize a large PMD page when
the address is not aligned on page boundary.
Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
Reviewed-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 115540457feae9a215e5c16e434f71b80860038f
Author: Jens Axboe <axboe@kernel.dk>
Date: Wed Aug 4 08:37:25 2021 -0600
io-wq: remove GFP_ATOMIC allocation off schedule out path
[ Upstream commit d3e9f732c415cf22faa33d6f195e291ad82dc92e ]
Daniel reports that the v5.14-rc4-rt4 kernel throws a BUG when running
stress-ng:
| [ 90.202543] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:35
| [ 90.202549] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2047, name: iou-wrk-2041
| [ 90.202555] CPU: 5 PID: 2047 Comm: iou-wrk-2041 Tainted: G W 5.14.0-rc4-rt4+ #89
| [ 90.202559] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
| [ 90.202561] Call Trace:
| [ 90.202577] dump_stack_lvl+0x34/0x44
| [ 90.202584] ___might_sleep.cold+0x87/0x94
| [ 90.202588] rt_spin_lock+0x19/0x70
| [ 90.202593] ___slab_alloc+0xcb/0x7d0
| [ 90.202598] ? newidle_balance.constprop.0+0xf5/0x3b0
| [ 90.202603] ? dequeue_entity+0xc3/0x290
| [ 90.202605] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202610] ? pick_next_task_fair+0xb9/0x330
| [ 90.202612] ? __schedule+0x670/0x1410
| [ 90.202615] ? io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202618] kmem_cache_alloc_trace+0x79/0x1f0
| [ 90.202621] io_wqe_dec_running.isra.0+0x98/0xe0
| [ 90.202625] io_wq_worker_sleeping+0x37/0x50
| [ 90.202628] schedule+0x30/0xd0
| [ 90.202630] schedule_timeout+0x8f/0x1a0
| [ 90.202634] ? __bpf_trace_tick_stop+0x10/0x10
| [ 90.202637] io_wqe_worker+0xfd/0x320
| [ 90.202641] ? finish_task_switch.isra.0+0xd3/0x290
| [ 90.202644] ? io_worker_handle_work+0x670/0x670
| [ 90.202646] ? io_worker_handle_work+0x670/0x670
| [ 90.202649] ret_from_fork+0x22/0x30
which is due to the RT kernel not liking a GFP_ATOMIC allocation inside
a raw spinlock. Besides that not working on RT, doing any kind of
allocation from inside schedule() is kind of nasty and should be avoided
if at all possible.
This particular path happens when an io-wq worker goes to sleep, and we
need a new worker to handle pending work. We currently allocate a small
data item to hold the information we need to create a new worker, but we
can instead include this data in the io_worker struct itself and just
protect it with a single bit lock. We only really need one per worker
anyway, as we will have run pending work between to sleep cycles.
https://lore.kernel.org/lkml/20210804082418.fbibprcwtzyt5qax@beryllium.lan/
Reported-by: Daniel Wagner <dwagner@suse.de>
Tested-by: Daniel Wagner <dwagner@suse.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 037b5744772eb738b2c9372d36dff240472d22bc
Author: Stian Skjelstad <stian.skjelstad@gmail.com>
Date: Sun Aug 22 11:33:32 2021 +0200
udf_get_extendedattr() had no boundary checks.
[ Upstream commit 58bc6d1be2f3b0ceecb6027dfa17513ec6aa2abb ]
When parsing the ExtendedAttr data, malicous or corrupt attribute length
could cause kernel hangs and buffer overruns in some special cases.
Link: https://lore.kernel.org/r/20210822093332.25234-1-stian.skjelstad@gmail.com
Signed-off-by: Stian Skjelstad <stian.skjelstad@gmail.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 3511a749b9d37e9ffee8fb35d3abea49595cdef6
Author: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Date: Fri Jul 2 17:18:31 2021 +0800
fcntl: fix potential deadlock for &fasync_struct.fa_lock
[ Upstream commit 2f488f698fda820f8e6fa0407630154eceb145d6 ]
There is an existing lock hierarchy of
&dev->event_lock --> &fasync_struct.fa_lock --> &f->f_owner.lock
from the following call chain:
input_inject_event():
spin_lock_irqsave(&dev->event_lock,...);
input_handle_event():
input_pass_values():
input_to_handler():
evdev_events():
evdev_pass_values():
spin_lock(&client->buffer_lock);
__pass_event():
kill_fasync():
kill_fasync_rcu():
read_lock(&fa->fa_lock);
send_sigio():
read_lock_irqsave(&fown->lock,...);
&dev->event_lock is HARDIRQ-safe, so interrupts have to be disabled
while grabbing &fasync_struct.fa_lock, otherwise we invert the lock
hierarchy. However, since kill_fasync which calls kill_fasync_rcu is
an exported symbol, it may not necessarily be called with interrupts
disabled.
As kill_fasync_rcu may be called with interrupts disabled (for
example, in the call chain above), we replace calls to
read_lock/read_unlock on &fasync_struct.fa_lock in kill_fasync_rcu
with read_lock_irqsave/read_unlock_irqrestore.
Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit d633a4b724423438de294637574a51cb2b4a86ec
Author: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Date: Fri Jul 2 17:18:30 2021 +0800
fcntl: fix potential deadlocks for &fown_struct.lock
[ Upstream commit f671a691e299f58835d4660d642582bf0e8f6fda ]
Syzbot reports a potential deadlock in do_fcntl:
========================================================
WARNING: possible irq lock inversion dependency detected
5.12.0-syzkaller #0 Not tainted
--------------------------------------------------------
syz-executor132/8391 just changed the state of lock:
ffff888015967bf8 (&f->f_owner.lock){.+..}-{2:2}, at: f_getown_ex fs/fcntl.c:211 [inline]
ffff888015967bf8 (&f->f_owner.lock){.+..}-{2:2}, at: do_fcntl+0x8b4/0x1200 fs/fcntl.c:395
but this lock was taken by another, HARDIRQ-safe lock in the past:
(&dev->event_lock){-...}-{2:2}
and interrupts could create inverse lock ordering between them.
other info that might help us debug this:
Chain exists of:
&dev->event_lock --> &new->fa_lock --> &f->f_owner.lock
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&f->f_owner.lock);
local_irq_disable();
lock(&dev->event_lock);
lock(&new->fa_lock);
<Interrupt>
lock(&dev->event_lock);
*** DEADLOCK ***
This happens because there is a lock hierarchy of
&dev->event_lock --> &new->fa_lock --> &f->f_owner.lock
from the following call chain:
input_inject_event():
spin_lock_irqsave(&dev->event_lock,...);
input_handle_event():
input_pass_values():
input_to_handler():
evdev_events():
evdev_pass_values():
spin_lock(&client->buffer_lock);
__pass_event():
kill_fasync():
kill_fasync_rcu():
read_lock(&fa->fa_lock);
send_sigio():
read_lock_irqsave(&fown->lock,...);
However, since &dev->event_lock is HARDIRQ-safe, interrupts have to be
disabled while grabbing &f->f_owner.lock, otherwise we invert the lock
hierarchy.
Hence, we replace calls to read_lock/read_unlock on &f->f_owner.lock,
with read_lock_irq/read_unlock_irq.
Reported-and-tested-by: syzbot+e6d5398a02c516ce5e70@syzkaller.appspotmail.com
Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit fbb3d1a9ac8fbf65c39acfb182088203ff53fc2a
Author: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Date: Fri Aug 13 15:55:06 2021 +0800
crypto: tcrypt - Fix missing return value check
[ Upstream commit 7b3d52683b3a47c0ba1dfd6b5994a3a795b06972 ]
There are several places where the return value check of crypto_aead_setkey
and crypto_aead_setauthsize were lost. It is necessary to add these checks.
At the same time, move the crypto_aead_setauthsize() call out of the loop,
and only need to call it once after load transform.
Fixee: 53f52d7aecb4 ("crypto: tcrypt - Added speed tests for AEAD crypto alogrithms in tcrypt test suite")
Signed-off-by: Tianjia Zhang <tianjia.zhang@linux.alibaba.com>
Reviewed-by: Vitaly Chikunov <vt@altlinux.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 16f6b6a202cd7cc285005e89b1aeba32e72722d3
Author: Kai Ye <yekai13@huawei.com>
Date: Fri Aug 13 15:41:02 2021 +0800
crypto: hisilicon/sec - modify the hardware endian configuration
[ Upstream commit a52626106d6f7edf3d106c065e13a0313cfeb82f ]
When the endian configuration of the hardware is abnormal, it will
cause the SEC engine is faulty that reports empty message. And it
will affect the normal function of the hardware. Currently the soft
configuration method can't restore the faulty device. The endian
needs to be configured according to the system properties. So fix it.
Signed-off-by: Kai Ye <yekai13@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit df099323d1cef189f24516168a6b3c60d0cf9633
Author: Kai Ye <yekai13@huawei.com>
Date: Fri Aug 13 15:41:01 2021 +0800
crypto: hisilicon/sec - fix the abnormal exiting process
[ Upstream commit 90367a027a22c3a9ca8b8bac15df34d9e859fc11 ]
Because the algs registration process has added a judgment.
So need to add the judgment for the abnormal exiting process.
Signed-off-by: Kai Ye <yekai13@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit bd7614178780a8605157fb4fd09c4d31641b9517
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date: Thu Aug 12 21:21:28 2021 +0100
crypto: qat - do not export adf_iov_putmsg()
[ Upstream commit 645ae0af1840199086c33e4f841892ebee73f615 ]
The function adf_iov_putmsg() is only used inside the intel_qat module
therefore should not be exported.
Remove EXPORT_SYMBOL for the function adf_iov_putmsg().
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 890ac26f7ed508e22eaf91a7c8f8c699eb0c8f1e
Author: Marco Chiappero <marco.chiappero@intel.com>
Date: Thu Aug 12 21:21:22 2021 +0100
crypto: qat - fix naming for init/shutdown VF to PF notifications
[ Upstream commit b90c1c4d3fa8cd90f4e8245b13564380fd0bfad1 ]
At start and shutdown, VFs notify the PF about their state. These
notifications are carried out through a message exchange using the PFVF
protocol.
Function names lead to believe they do perform init or shutdown logic.
This is to fix the naming to better reflect their purpose.
Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
Co-developed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2e575a675d9dcaa69974c6da5f174201e5b3024c
Author: Marco Chiappero <marco.chiappero@intel.com>
Date: Thu Aug 12 21:21:19 2021 +0100
crypto: qat - fix reuse of completion variable
[ Upstream commit 3d655732b0199562267a05c7ff69ecdd11632939 ]
Use reinit_completion() to set to a clean state a completion variable,
used to coordinate the VF to PF request-response flow, before every
new VF request.
Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
Co-developed-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f31f371f385f30c2e59306d474926e902d337fbb
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date: Thu Aug 12 21:21:14 2021 +0100
crypto: qat - handle both source of interrupt in VF ISR
[ Upstream commit 0a73c762e1eee33a5e5dc0e3488f1b7cd17249b3 ]
The top half of the VF drivers handled only a source at the time.
If an interrupt for PF2VF and bundle occurred at the same time, the ISR
scheduled only the bottom half for PF2VF.
This patch fixes the VF top half so that if both sources of interrupt
trigger at the same time, both bottom halves are scheduled.
This patch is based on earlier work done by Conor McLoughlin.
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Marco Chiappero <marco.chiappero@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2f66c3551eca9e33de0d38b50563fb24a05162e5
Author: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Date: Thu Aug 12 21:21:13 2021 +0100
crypto: qat - do not ignore errors from enable_vf2pf_comms()
[ Upstream commit 5147f0906d50a9d26f2b8698cd06b5680e9867ff ]
The function adf_dev_init() ignores the error code reported by
enable_vf2pf_comms(). If the latter fails, e.g. the VF is not compatible
with the pf, then the load of the VF driver progresses.
This patch changes adf_dev_init() so that the error code from
enable_vf2pf_comms() is returned to the caller.
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Reviewed-by: Marco Chiappero <marco.chiappero@intel.com>
Reviewed-by: Fiona Trahe <fiona.trahe@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit b8b8c7969a7c25a204c9616a393579eb4d9fa00f
Author: Ben Hutchings <ben.hutchings@mind.be>
Date: Wed Aug 11 02:06:09 2021 +0200
crypto: omap - Fix inconsistent locking of device lists
[ Upstream commit fe4d55773b879c785ae61da9b1c2160f0110f67e ]
lockdep complains that in omap-aes, the list_lock is taken both with
softirqs enabled at probe time, and also in softirq context, which
could lead to a deadlock:
================================
WARNING: inconsistent lock state
5.14.0-rc1-00035-gc836005b01c5-dirty #69 Not tainted
--------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
ksoftirqd/0/7 [HC0[0]:SC1[3]:HE1:SE0] takes:
bf00e014 (list_lock){+.?.}-{2:2}, at: omap_aes_find_dev+0x18/0x54 [omap_aes_driver]
{SOFTIRQ-ON-W} state was registered at:
_raw_spin_lock+0x40/0x50
omap_aes_probe+0x1d4/0x664 [omap_aes_driver]
platform_probe+0x58/0xb8
really_probe+0xbc/0x314
__driver_probe_device+0x80/0xe4
driver_probe_device+0x30/0xc8
__driver_attach+0x70/0xf4
bus_for_each_dev+0x70/0xb4
bus_add_driver+0xf0/0x1d4
driver_register+0x74/0x108
do_one_initcall+0x84/0x2e4
do_init_module+0x5c/0x240
load_module+0x221c/0x2584
sys_finit_module+0xb0/0xec
ret_fast_syscall+0x0/0x2c
0xbed90b30
irq event stamp: 111800
hardirqs last enabled at (111800): [<c02a21e4>] __kmalloc+0x484/0x5ec
hardirqs last disabled at (111799): [<c02a21f0>] __kmalloc+0x490/0x5ec
softirqs last enabled at (111776): [<c01015f0>] __do_softirq+0x2b8/0x4d0
softirqs last disabled at (111781): [<c0135948>] run_ksoftirqd+0x34/0x50
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(list_lock);
<Interrupt>
lock(list_lock);
*** DEADLOCK ***
2 locks held by ksoftirqd/0/7:
#0: c0f5e8c8 (rcu_read_lock){....}-{1:2}, at: netif_receive_skb+0x6c/0x260
#1: c0f5e8c8 (rcu_read_lock){....}-{1:2}, at: ip_local_deliver_finish+0x2c/0xdc
stack backtrace:
CPU: 0 PID: 7 Comm: ksoftirqd/0 Not tainted 5.14.0-rc1-00035-gc836005b01c5-dirty #69
Hardware name: Generic AM43 (Flattened Device Tree)
[<c010e6e0>] (unwind_backtrace) from [<c010b9d0>] (show_stack+0x10/0x14)
[<c010b9d0>] (show_stack) from [<c017c640>] (mark_lock.part.17+0x5bc/0xd04)
[<c017c640>] (mark_lock.part.17) from [<c017d9e4>] (__lock_acquire+0x960/0x2fa4)
[<c017d9e4>] (__lock_acquire) from [<c0180980>] (lock_acquire+0x10c/0x358)
[<c0180980>] (lock_acquire) from [<c093d324>] (_raw_spin_lock_bh+0x44/0x58)
[<c093d324>] (_raw_spin_lock_bh) from [<bf00b258>] (omap_aes_find_dev+0x18/0x54 [omap_aes_driver])
[<bf00b258>] (omap_aes_find_dev [omap_aes_driver]) from [<bf00b328>] (omap_aes_crypt+0x94/0xd4 [omap_aes_driver])
[<bf00b328>] (omap_aes_crypt [omap_aes_driver]) from [<c08ac6d0>] (esp_input+0x1b0/0x2c8)
[<c08ac6d0>] (esp_input) from [<c08c9e90>] (xfrm_input+0x410/0x1290)
[<c08c9e90>] (xfrm_input) from [<c08b6374>] (xfrm4_esp_rcv+0x54/0x11c)
[<c08b6374>] (xfrm4_esp_rcv) from [<c0838840>] (ip_protocol_deliver_rcu+0x48/0x3bc)
[<c0838840>] (ip_protocol_deliver_rcu) from [<c0838c50>] (ip_local_deliver_finish+0x9c/0xdc)
[<c0838c50>] (ip_local_deliver_finish) from [<c0838dd8>] (ip_local_deliver+0x148/0x1b0)
[<c0838dd8>] (ip_local_deliver) from [<c0838f5c>] (ip_rcv+0x11c/0x180)
[<c0838f5c>] (ip_rcv) from [<c077e3a4>] (__netif_receive_skb_one_core+0x54/0x74)
[<c077e3a4>] (__netif_receive_skb_one_core) from [<c077e588>] (netif_receive_skb+0xa8/0x260)
[<c077e588>] (netif_receive_skb) from [<c068d6d4>] (cpsw_rx_handler+0x224/0x2fc)
[<c068d6d4>] (cpsw_rx_handler) from [<c0688ccc>] (__cpdma_chan_process+0xf4/0x188)
[<c0688ccc>] (__cpdma_chan_process) from [<c068a0c0>] (cpdma_chan_process+0x3c/0x5c)
[<c068a0c0>] (cpdma_chan_process) from [<c0690e14>] (cpsw_rx_mq_poll+0x44/0x98)
[<c0690e14>] (cpsw_rx_mq_poll) from [<c0780810>] (__napi_poll+0x28/0x268)
[<c0780810>] (__napi_poll) from [<c0780c64>] (net_rx_action+0xcc/0x204)
[<c0780c64>] (net_rx_action) from [<c0101478>] (__do_softirq+0x140/0x4d0)
[<c0101478>] (__do_softirq) from [<c0135948>] (run_ksoftirqd+0x34/0x50)
[<c0135948>] (run_ksoftirqd) from [<c01583b8>] (smpboot_thread_fn+0xf4/0x1d8)
[<c01583b8>] (smpboot_thread_fn) from [<c01546dc>] (kthread+0x14c/0x174)
[<c01546dc>] (kthread) from [<c010013c>] (ret_from_fork+0x14/0x38)
...
The omap-des and omap-sham drivers appear to have a similar issue.
Fix this by using spin_{,un}lock_bh() around device list access in all
the probe and remove functions.
Signed-off-by: Ben Hutchings <ben.hutchings@mind.be>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 34c033400a88625519f640b845e9cb51a8fa945b
Author: Valentin Schneider <valentin.schneider@arm.com>
Date: Wed Aug 18 13:13:33 2021 +0530
sched/topology: Skip updating masks for non-online nodes
[ Upstream commit 0083242c93759dde353a963a90cb351c5c283379 ]
The scheduler currently expects NUMA node distances to be stable from
init onwards, and as a consequence builds the related data structures
once-and-for-all at init (see sched_init_numa()).
Unfortunately, on some architectures node distance is unreliable for
offline nodes and may very well change upon onlining.
Skip over offline nodes during sched_init_numa(). Track nodes that have
been onlined at least once, and trigger a build of a node's NUMA masks
when it is first onlined post-init.
Reported-by: Geetika Moolchandani <Geetika.Moolchandani1@ibm.com>
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Signed-off-by: Valentin Schneider <valentin.schneider@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20210818074333.48645-1-srikar@linux.vnet.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit a3a9bd95ea987df87e39f5a3747ceb4280bf3a3c
Author: Damien Le Moal <damien.lemoal@wdc.com>
Date: Mon Aug 16 10:44:47 2021 +0900
libata: fix ata_host_start()
[ Upstream commit 355a8031dc174450ccad2a61c513ad7222d87a97 ]
The loop on entry of ata_host_start() may not initialize host->ops to a
non NULL value. The test on the host_stop field of host->ops must then
be preceded by a check that host->ops is not NULL.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Damien Le Moal <damien.lemoal@wdc.com>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Link: https://lore.kernel.org/r/20210816014456.2191776-3-damien.lemoal@wdc.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 258e7b70fa82b8e6de832191d0464d7c418a2324
Author: Harald Freudenberger <freude@linux.ibm.com>
Date: Fri Aug 6 12:02:00 2021 +0200
s390/zcrypt: fix wrong offset index for APKA master key valid state
[ Upstream commit 8617bb74006252cb2286008afe7d6575a6425857 ]
Tests showed a mismatch between what the CCA tool reports about
the APKA master key state and what's displayed by the zcrypt dd
in sysfs. After some investigation, we found out that the
documentation which was the source for the zcrypt dd implementation
lacks the listing of 3 fields. So this patch now moves the
evaluation of the APKA master key state to the correct offset.
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit ef9522b7a41e72d863e5234c70bf2a053a3264be
Author: Vineeth Vijayan <vneethv@linux.ibm.com>
Date: Sun Apr 25 10:52:38 2021 +0200
s390/cio: add dev_busid sysfs entry for each subchannel
[ Upstream commit d3683c055212bf910d4e318f7944910ce10dbee6 ]
Introduce dev_busid, which exports the device-id associated with the
io-subchannel (and message-subchannel). The dev_busid indicates that of
the device which may be physically installed on the corrosponding
subchannel. The dev_busid value "none" indicates that the subchannel
is not valid, there is no I/O device currently associated with the
subchannel.
The dev_busid information would be helpful to write device-specific
udev-rules associated with the subchannel. The dev_busid interface would
be available even when the sch is not bound to any driver or if there is
no operational device connected on it. Hence this attribute can be used to
write udev-rules which are specific to the device associated with the
subchannel.
Signed-off-by: Vineeth Vijayan <vneethv@linux.ibm.com>
Reviewed-by: Peter Oberparleiter <oberpar@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7438a7621eae5fa0a1377b9f788935b1b6122ddf
Author: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Date: Mon Aug 16 18:50:14 2021 +0200
power: supply: max17042_battery: fix typo in MAx17042_TOFF
[ Upstream commit ed0d0a0506025f06061325cedae1bbebd081620a ]
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 22403769d61ea8dc1be3150199fcb8dd559eb93f
Author: Dmitry Osipenko <digetx@gmail.com>
Date: Sat Jul 31 20:38:38 2021 +0300
power: supply: smb347-charger: Add missing pin control activation
[ Upstream commit efe2175478d5237949e33c84d9a722fc084b218c ]
Pin control needs to be activated by setting the enable bit, otherwise
hardware rejects all pin changes. Previously this stayed unnoticed on
Nexus 7 because pin control was enabled by default after rebooting from
downstream kernel, which uses driver that enables the bit and charger
registers are non-volatile until power supply (battery) is disconnected.
Configure the pin control enable bit. This fixes the potentially
never-enabled charging on devices that use pin control.
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 764ba1607795a3f036d99f5a9add4500feee4d8d
Author: Amit Engel <amit.engel@dell.com>
Date: Sun Aug 8 09:20:14 2021 +0300
nvmet: pass back cntlid on successful completion
[ Upstream commit e804d5abe2d74cfe23f5f83be580d1cdc9307111 ]
According to the NVMe specification, the response dword 0 value of the
Connect command is based on status code: return cntlid for successful
compeltion return IPO and IATTR for connect invalid parameters. Fix
a missing error information for a zero sized queue, and return the
cntlid also for I/O queue Connect commands.
Signed-off-by: Amit Engel <amit.engel@dell.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8869a2d67882b868b37cf8e038290817c1ef068a
Author: Ruozhu Li <liruozhu@huawei.com>
Date: Wed Jul 28 17:41:20 2021 +0800
nvme-rdma: don't update queue count when failing to set io queues
[ Upstream commit 85032874f80ba17bf187de1d14d9603bf3f582b8 ]
We update ctrl->queue_count and schedule another reconnect when io queue
count is zero.But we will never try to create any io queue in next reco-
nnection, because ctrl->queue_count already set to zero.We will end up
having an admin-only session in Live state, which is exactly what we try
to avoid in the original patch.
Update ctrl->queue_count after queue_count zero checking to fix it.
Signed-off-by: Ruozhu Li <liruozhu@huawei.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 923c1c5ca5a81958a8bfd891bc16c319c4bb9e6d
Author: Ruozhu Li <liruozhu@huawei.com>
Date: Sat Aug 7 11:50:23 2021 +0800
nvme-tcp: don't update queue count when failing to set io queues
[ Upstream commit 664227fde63844d69e9ec9e90a8a7801e6ff072d ]
We update ctrl->queue_count and schedule another reconnect when io queue
count is zero.But we will never try to create any io queue in next reco-
nnection, because ctrl->queue_count already set to zero.We will end up
having an admin-only session in Live state, which is exactly what we try
to avoid in the original patch.
Update ctrl->queue_count after queue_count zero checking to fix it.
Signed-off-by: Ruozhu Li <liruozhu@huawei.com>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2d69306c23cba4f9d9b6bb64609ea4b70a6a0395
Author: Chunguang Xu <brookxu@tencent.com>
Date: Mon Aug 2 11:51:56 2021 +0800
blk-throtl: optimize IOPS throttle for large IO scenarios
[ Upstream commit 4f1e9630afe6332de7286820fedd019f19eac057 ]
After patch 54efd50 (block: make generic_make_request handle
arbitrarily sized bios), the IO through io-throttle may be larger,
and these IOs may be further split into more small IOs. However,
IOPS throttle does not seem to be aware of this change, which
makes the calculation of IOPS of large IOs incomplete, resulting
in disk-side IOPS that does not meet expectations. Maybe we should
fix this problem.
We can reproduce it by set max_sectors_kb of disk to 128, set
blkio.write_iops_throttle to 100, run a dd instance inside blkio
and use iostat to watch IOPS:
dd if=/dev/zero of=/dev/sdb bs=1M count=1000 oflag=direct
As a result, without this change the average IOPS is 1995, with
this change the IOPS is 98.
Signed-off-by: Chunguang Xu <brookxu@tencent.com>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lore.kernel.org/r/65869aaad05475797d63b4c3fed4f529febe3c26.1627876014.git.brookxu@tencent.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 923114984711f949ecad6d89fd36a59320fbb606
Author: Baokun Li <libaokun1@huawei.com>
Date: Wed Aug 4 10:12:12 2021 +0800
nbd: add the check to prevent overflow in __nbd_ioctl()
[ Upstream commit fad7cd3310db3099f95dd34312c77740fbc455e5 ]
If user specify a large enough value of NBD blocks option, it may trigger
signed integer overflow which may lead to nbd->config->bytesize becomes a
large or small value, zero in particular.
UBSAN: Undefined behaviour in drivers/block/nbd.c:325:31
signed integer overflow:
1024 * 4611686155866341414 cannot be represented in type 'long long int'
[...]
Call trace:
[...]
handle_overflow+0x188/0x1dc lib/ubsan.c:192
__ubsan_handle_mul_overflow+0x34/0x44 lib/ubsan.c:213
nbd_size_set drivers/block/nbd.c:325 [inline]
__nbd_ioctl drivers/block/nbd.c:1342 [inline]
nbd_ioctl+0x998/0xa10 drivers/block/nbd.c:1395
__blkdev_driver_ioctl block/ioctl.c:311 [inline]
[...]
Although it is not a big deal, still silence the UBSAN by limit
the input value.
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Baokun Li <libaokun1@huawei.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20210804021212.990223-1-libaokun1@huawei.com
[axboe: dropped unlikely()]
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit eeb7f00f6021626247d8870506edf5ae7b303e52
Author: Christoph Hellwig <hch@lst.de>
Date: Mon Aug 9 08:40:26 2021 +0200
bcache: add proper error unwinding in bcache_device_init
[ Upstream commit 224b0683228c5f332f9cee615d85e75e9a347170 ]
Except for the IDA none of the allocations in bcache_device_init is
unwound on error, fix that.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Acked-by: Coly Li <colyli@suse.de>
Link: https://lore.kernel.org/r/20210809064028.1198327-7-hch@lst.de
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 2fa6bb6d9a35a621b685d0a0fa5271b102f0889f
Author: Pali Rohár <pali@kernel.org>
Date: Sun Aug 8 18:24:37 2021 +0200
isofs: joliet: Fix iocharset=utf8 mount option
[ Upstream commit 28ce50f8d96ec9035f60c9348294ea26b94db944 ]
Currently iocharset=utf8 mount option is broken. To use UTF-8 as iocharset,
it is required to use utf8 mount option.
Fix iocharset=utf8 mount option to use be equivalent to the utf8 mount
option.
If UTF-8 as iocharset is used then s_nls_iocharset is set to NULL. So
simplify code around, remove s_utf8 field as to distinguish between UTF-8
and non-UTF-8 it is needed just to check if s_nls_iocharset is set to NULL
or not.
Link: https://lore.kernel.org/r/20210808162453.1653-5-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 796c0a620178d68900fb2f4bf987cd89a9b38090
Author: Pali Rohár <pali@kernel.org>
Date: Sun Aug 8 18:24:36 2021 +0200
udf: Fix iocharset=utf8 mount option
[ Upstream commit b645333443712d2613e4e863f81090d5dc509657 ]
Currently iocharset=utf8 mount option is broken. To use UTF-8 as iocharset,
it is required to use utf8 mount option.
Fix iocharset=utf8 mount option to use be equivalent to the utf8 mount
option.
If UTF-8 as iocharset is used then s_nls_map is set to NULL. So simplify
code around, remove UDF_FLAG_NLS_MAP and UDF_FLAG_UTF8 flags as to
distinguish between UTF-8 and non-UTF-8 it is needed just to check if
s_nls_map set to NULL or not.
Link: https://lore.kernel.org/r/20210808162453.1653-4-pali@kernel.org
Signed-off-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 96c8dba7eb5c4a8dcba52d0ff4fa3d4d37fd539f
Author: Jan Kara <jack@suse.cz>
Date: Mon May 3 11:39:03 2021 +0200
udf: Check LVID earlier
[ Upstream commit 781d2a9a2fc7d0be53a072794dc03ef6de770f3d ]
We were checking validity of LVID entries only when getting
implementation use information from LVID in udf_sb_lvidiu(). However if
the LVID is suitably corrupted, it can cause problems also to code such
as udf_count_free() which doesn't use udf_sb_lvidiu(). So check validity
of LVID already when loading it from the disk and just disable LVID
altogether when it is not valid.
Reported-by: syzbot+7fbfe5fed73ebb675748@syzkaller.appspotmail.com
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit add6659e3785c798d04a524d7eada83b09a5c6e6
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Tue Jul 13 15:39:48 2021 +0200
hrtimer: Ensure timerfd notification for HIGHRES=n
[ Upstream commit 8c3b5e6ec0fee18bc2ce38d1dfe913413205f908 ]
If high resolution timers are disabled the timerfd notification about a
clock was set event is not happening for all cases which use
clock_was_set_delayed() because that's a NOP for HIGHRES=n, which is wrong.
Make clock_was_set_delayed() unconditially available to fix that.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210713135158.196661266@linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 0d7541f439be37dabb7546889503d16ac59ec29f
Author: Thomas Gleixner <tglx@linutronix.de>
Date: Tue Jul 13 15:39:46 2021 +0200
hrtimer: Avoid double reprogramming in __hrtimer_start_range_ns()
[ Upstream commit 627ef5ae2df8eeccb20d5af0e4cfa4df9e61ed28 ]
If __hrtimer_start_range_ns() is invoked with an already armed hrtimer then
the timer has to be canceled first and then added back. If the timer is the
first expiring timer then on removal the clockevent device is reprogrammed
to the next expiring timer to avoid that the pending expiry fires needlessly.
If the new expiry time ends up to be the first expiry again then the clock
event device has to reprogrammed again.
Avoid this by checking whether the timer is the first to expire and in that
case, keep the timer on the current CPU and delay the reprogramming up to
the point where the timer has been enqueued again.
Reported-by: Lorenzo Colitti <lorenzo@google.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210713135157.873137732@linutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 564005805aadec9cb7e5dc4e14071b8f87cd6b58
Author: Frederic Weisbecker <frederic@kernel.org>
Date: Mon Jul 26 14:55:10 2021 +0200
posix-cpu-timers: Force next expiration recalc after itimer reset
[ Upstream commit 406dd42bd1ba0c01babf9cde169bb319e52f6147 ]
When an itimer deactivates a previously armed expiration, it simply doesn't
do anything. As a result the process wide cputime counter keeps running and
the tick dependency stays set until it reaches the old ghost expiration
value.
This can be reproduced with the following snippet:
void trigger_process_counter(void)
{
struct itimerval n = {};
n.it_value.tv_sec = 100;
setitimer(ITIMER_VIRTUAL, &n, NULL);
n.it_value.tv_sec = 0;
setitimer(ITIMER_VIRTUAL, &n, NULL);
}
Fix this with resetting the relevant base expiration. This is similar to
disarming a timer.
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20210726125513.271824-4-frederic@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f02146cf84e6165cae177aea30acdea7b8d76cf3
Author: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Date: Mon Jun 28 12:27:40 2021 -0500
EDAC/mce_amd: Do not load edac_mce_amd module on guests
[ Upstream commit 767f4b620edadac579c9b8b6660761d4285fa6f9 ]
Hypervisors likely do not expose the SMCA feature to the guest and
loading this module leads to false warnings. This module should not be
loaded in guests to begin with, but people tend to do so, especially
when testing kernels in VMs. And then they complain about those false
warnings.
Do the practical thing and do not load this module when running as a
guest to avoid all that complaining.
[ bp: Rewrite commit message. ]
Suggested-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Yazen Ghannam <yazen.ghannam@amd.com>
Tested-by: Kim Phillips <kim.phillips@amd.com>
Link: https://lkml.kernel.org/r/20210628172740.245689-1-Smita.KoralahalliChannabasappa@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit f08a6566aaa460721fc1156ec24386a851a8d566
Author: Sergey Senozhatsky <senozhatsky@chromium.org>
Date: Sat May 22 00:56:23 2021 +0900
rcu/tree: Handle VM stoppage in stall detection
[ Upstream commit ccfc9dd6914feaa9a81f10f9cce56eb0f7712264 ]
The soft watchdog timer function checks if a virtual machine
was suspended and hence what looks like a lockup in fact
is a false positive.
This is what kvm_check_and_clear_guest_paused() does: it
tests guest PVCLOCK_GUEST_STOPPED (which is set by the host)
and if it's set then we need to touch all watchdogs and bail
out.
Watchdog timer function runs from IRQ, so PVCLOCK_GUEST_STOPPED
check works fine.
There is, however, one more watchdog that runs from IRQ, so
watchdog timer fn races with it, and that watchdog is not aware
of PVCLOCK_GUEST_STOPPED - RCU stall detector.
apic_timer_interrupt()
smp_apic_timer_interrupt()
hrtimer_interrupt()
__hrtimer_run_queues()
tick_sched_timer()
tick_sched_handle()
update_process_times()
rcu_sched_clock_irq()
This triggers RCU stalls on our devices during VM resume.
If tick_sched_handle()->rcu_sched_clock_irq() runs on a VCPU
before watchdog_timer_fn()->kvm_check_and_clear_guest_paused()
then there is nothing on this VCPU that touches watchdogs and
RCU reads stale gp stall timestamp and new jiffies value, which
makes it think that RCU has stalled.
Make RCU stall watchdog aware of PVCLOCK_GUEST_STOPPED and
don't report RCU stalls when we resume the VM.
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit daf2ceb70199283fc350365a61aa3adfd9ab7c23
Author: Dietmar Eggemann <dietmar.eggemann@arm.com>
Date: Wed Aug 4 15:59:25 2021 +0200
sched/deadline: Fix missing clock update in migrate_task_rq_dl()
[ Upstream commit b4da13aa28d4fd0071247b7b41c579ee8a86c81a ]
A missing clock update is causing the following warning:
rq->clock_update_flags < RQCF_ACT_SKIP
WARNING: CPU: 112 PID: 2041 at kernel/sched/sched.h:1453
sub_running_bw.isra.0+0x190/0x1a0
...
CPU: 112 PID: 2041 Comm: sugov:112 Tainted: G W 5.14.0-rc1 #1
Hardware name: WIWYNN Mt.Jade Server System
B81.030Z1.0007/Mt.Jade Motherboard, BIOS 1.6.20210526 (SCP:
1.06.20210526) 2021/05/26
...
Call trace:
sub_running_bw.isra.0+0x190/0x1a0
migrate_task_rq_dl+0xf8/0x1e0
set_task_cpu+0xa8/0x1f0
try_to_wake_up+0x150/0x3d4
wake_up_q+0x64/0xc0
__up_write+0xd0/0x1c0
up_write+0x4c/0x2b0
cppc_set_perf+0x120/0x2d0
cppc_cpufreq_set_target+0xe0/0x1a4 [cppc_cpufreq]
__cpufreq_driver_target+0x74/0x140
sugov_work+0x64/0x80
kthread_worker_fn+0xe0/0x230
kthread+0x138/0x140
ret_from_fork+0x10/0x18
The task causing this is the `cppc_fie` DL task introduced by
commit 1eb5dde674f5 ("cpufreq: CPPC: Add support for frequency
invariance").
With CONFIG_ACPI_CPPC_CPUFREQ_FIE=y and schedutil cpufreq governor on
slow-switching system (like on this Ampere Altra WIWYNN Mt. Jade Arm
Server):
DL task `curr=sugov:112` lets `p=cppc_fie` migrate and since the latter
is in `non_contending` state, migrate_task_rq_dl() calls
sub_running_bw()->__sub_running_bw()->cpufreq_update_util()->
rq_clock()->assert_clock_updated()
on p.
Fix this by updating the clock for a non_contending task in
migrate_task_rq_dl() before calling sub_running_bw().
Reported-by: Bruno Goncalves <bgoncalv@redhat.com>
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Daniel Bristot de Oliveira <bristot@kernel.org>
Acked-by: Juri Lelli <juri.lelli@redhat.com>
Link: https://lore.kernel.org/r/20210804135925.3734605-1-dietmar.eggemann@arm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 7e26d2d6b3a3443898576547052d34db0b4593fd
Author: Tony Lindgren <tony@atomide.com>
Date: Tue Jul 27 13:23:34 2021 +0300
crypto: omap-sham - clear dma flags only after omap_sham_update_dma_stop()
[ Upstream commit fe28140b3393b0ba1eb95cc109f974a7e58b26fd ]
We should not clear FLAGS_DMA_ACTIVE before omap_sham_update_dma_stop() is
done calling dma_unmap_sg(). We already clear FLAGS_DMA_ACTIVE at the
end of omap_sham_update_dma_stop().
The early clearing of FLAGS_DMA_ACTIVE is not causing issues as we do not
need to defer anything based on FLAGS_DMA_ACTIVE currently. So this can be
applied as clean-up.
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Tero Kristo <kristo@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 5187fcb1ebfd472570eaba2d85c4cf38ec5ed14f
Author: Hans de Goede <hdegoede@redhat.com>
Date: Sun Aug 1 15:30:59 2021 +0200
power: supply: axp288_fuel_gauge: Report register-address on readb / writeb errors
[ Upstream commit caa534c3ba40c6e8352b42cbbbca9ba481814ac8 ]
When fuel_gauge_reg_readb()/_writeb() fails, report which register we
were trying to read / write when the error happened.
Also reword the message a bit:
- Drop the axp288 prefix, dev_err() already prints this
- Switch from telegram / abbreviated style to a normal sentence, aligning
the message with those from fuel_gauge_read_*bit_word()
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 82e0f5ad8e9627447d8d94978ba891af33d43b49
Author: Quentin Perret <qperret@google.com>
Date: Tue Jul 27 11:11:01 2021 +0100
sched/deadline: Fix reset_on_fork reporting of DL tasks
[ Upstream commit f95091536f78971b269ec321b057b8d630b0ad8a ]
It is possible for sched_getattr() to incorrectly report the state of
the reset_on_fork flag when called on a deadline task.
Indeed, if the flag was set on a deadline task using sched_setattr()
with flags (SCHED_FLAG_RESET_ON_FORK | SCHED_FLAG_KEEP_PARAMS), then
p->sched_reset_on_fork will be set, but __setscheduler() will bail out
early, which means that the dl_se->flags will not get updated by
__setscheduler_params()->__setparam_dl(). Consequently, if
sched_getattr() is then called on the task, __getparam_dl() will
override kattr.sched_flags with the now out-of-date copy in dl_se->flags
and report the stale value to userspace.
To fix this, make sure to only copy the flags that are relevant to
sched_deadline to and from the dl_se->flags field.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20210727101103.2729607-2-qperret@google.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 575d990c3da1e72bb8399e92ec174cce57bbb665
Author: Sean Anderson <sean.anderson@seco.com>
Date: Thu Jul 1 14:56:37 2021 -0400
crypto: mxs-dcp - Check for DMA mapping errors
[ Upstream commit df6313d707e575a679ada3313358289af24454c0 ]
After calling dma_map_single(), we must also call dma_mapping_error().
This fixes the following warning when compiling with CONFIG_DMA_API_DEBUG:
[ 311.241478] WARNING: CPU: 0 PID: 428 at kernel/dma/debug.c:1027 check_unmap+0x79c/0x96c
[ 311.249547] DMA-API: mxs-dcp 2280000.crypto: device driver failed to check map error[device address=0x00000000860cb080] [size=32 bytes] [mapped as single]
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Reviewed-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 8ba99591a9d8268f1cfea8bc526e7bd17829cac9
Author: Dmitry Osipenko <digetx@gmail.com>
Date: Mon Jul 5 23:12:11 2021 +0300
regulator: tps65910: Silence deferred probe error
[ Upstream commit e301df76472cc929fa62d923bc3892931f7ad71d ]
The TPS65910 regulator now gets a deferred probe until supply regulator is
registered. Silence noisy error message about the deferred probe.
Reported-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30
Tested-by: Matt Merhar <mattmerhar@protonmail.com> # Ouya T30
Signed-off-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/20210705201211.16082-1-digetx@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 87105472bbb710e9d455f647f9151ac0892ca0d4
Author: Jeongtae Park <jeongtae.park@gmail.com>
Date: Thu Jul 1 23:26:30 2021 +0900
regmap: fix the offset of register error log
[ Upstream commit 1852f5ed358147095297a09cc3c6f160208a676d ]
This patch fixes the offset of register error log
by using regmap_get_offset().
Signed-off-by: Jeongtae Park <jeongtae.park@gmail.com>
Link: https://lore.kernel.org/r/20210701142630.44936-1-jeongtae.park@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit 73c080d740b3929039e0045a1562a2ee48215481
Author: Peter Zijlstra <peterz@infradead.org>
Date: Wed Jun 30 17:35:18 2021 +0200
locking/mutex: Fix HANDOFF condition
[ Upstream commit 048661a1f963e9517630f080687d48af79ed784c ]
Yanfei reported that setting HANDOFF should not depend on recomputing
@first, only on @first state. Which would then give:
if (ww_ctx || !first)
first = __mutex_waiter_is_first(lock, &waiter);
if (first)
__mutex_set_flag(lock, MUTEX_FLAG_HANDOFF);
But because 'ww_ctx || !first' is basically 'always' and the test for
first is relatively cheap, omit that first branch entirely.
Reported-by: Yanfei Xu <yanfei.xu@windriver.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Waiman Long <longman@redhat.com>
Reviewed-by: Yanfei Xu <yanfei.xu@windriver.com>
Link: https://lore.kernel.org/r/20210630154114.896786297@infradead.org
Signed-off-by: Sasha Levin <sashal@kernel.org>