Andrii Nakryiko [Sat, 23 Oct 2021 00:31:57 +0000 (17:31 -0700)]
libbpf: Fix BTF header parsing checks
[ Upstream commit
c825f5fee19caf301d9821cd79abaa734322de26 ]
Original code assumed fixed and correct BTF header length. That's not
always the case, though, so fix this bug with a proper additional check.
And use actual header length instead of sizeof(struct btf_header) in
sanity checks.
Fixes:
8a138aed4a80 ("bpf: btf: Add BTF support to libbpf")
Reported-by: Evgeny Vereshchagin <evvers@ya.ru>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20211023003157.726961-2-andrii@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrii Nakryiko [Sat, 23 Oct 2021 00:31:56 +0000 (17:31 -0700)]
libbpf: Fix overflow in BTF sanity checks
[ Upstream commit
5245dafe3d49efba4d3285cf27ee1cc1eeafafc6 ]
btf_header's str_off+str_len or type_off+type_len can overflow as they
are u32s. This will lead to bypassing the sanity checks during BTF
parsing, resulting in crashes afterwards. Fix by using 64-bit signed
integers for comparison.
Fixes:
d8123624506c ("libbpf: Fix BTF data layout checks and allow empty BTF")
Reported-by: Evgeny Vereshchagin <evvers@ya.ru>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Link: https://lore.kernel.org/bpf/20211023003157.726961-1-andrii@kernel.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Quentin Monnet [Fri, 22 Oct 2021 09:47:43 +0000 (10:47 +0100)]
bpftool: Avoid leaking the JSON writer prepared for program metadata
[ Upstream commit
e89ef634f81c9d90e1824ab183721f3b361472e6 ]
Bpftool creates a new JSON object for writing program metadata in plain
text mode, regardless of metadata being present or not. Then this writer
is freed if any metadata has been found and printed, but it leaks
otherwise. We cannot destroy the object unconditionally, because the
destructor prints an undesirable line break. Instead, make sure the
writer is created only after we have found program metadata to print.
Found with valgrind.
Fixes:
aff52e685eb3 ("bpftool: Support dumping metadata")
Signed-off-by: Quentin Monnet <quentin@isovalent.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211022094743.11052-1-quentin@isovalent.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Mauricio Vásquez [Fri, 22 Oct 2021 20:20:35 +0000 (15:20 -0500)]
libbpf: Fix memory leak in btf__dedup()
[ Upstream commit
1000298c76830bc291358e98e8fa5baa3baa9b3a ]
Free btf_dedup if btf_ensure_modifiable() returns error.
Fixes:
919d2b1dbb07 ("libbpf: Allow modification of BTF and add btf__add_str API")
Signed-off-by: Mauricio Vásquez <mauricio@kinvolk.io>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20211022202035.48868-1-mauricio@kinvolk.io
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jim Mattson [Thu, 30 Sep 2021 00:36:49 +0000 (17:36 -0700)]
KVM: selftests: Fix nested SVM tests when built with clang
[ Upstream commit
ed290e1c20da19fa100a3e0f421aa31b65984960 ]
Though gcc conveniently compiles a simple memset to "rep stos," clang
prefers to call the libc version of memset. If a test is dynamically
linked, the libc memset isn't available in L1 (nor is the PLT or the
GOT, for that matter). Even if the test is statically linked, the libc
memset may choose to use some CPU features, like AVX, which may not be
enabled in L1. Note that __builtin_memset doesn't solve the problem,
because (a) the compiler is free to call memset anyway, and (b)
__builtin_memset may also choose to use features like AVX, which may
not be available in L1.
To avoid a myriad of problems, use an explicit "rep stos" to clear the
VMCB in generic_svm_setup(), which is called both from L0 and L1.
Reported-by: Ricardo Koller <ricarkol@google.com>
Signed-off-by: Jim Mattson <jmattson@google.com>
Fixes:
20ba262f8631a ("selftests: KVM: AMD Nested test infrastructure")
Message-Id: <
20210930003649.4026553-1-jmattson@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tetsuo Handa [Tue, 19 Oct 2021 11:27:26 +0000 (20:27 +0900)]
smackfs: use netlbl_cfg_cipsov4_del() for deleting cipso_v4_doi
[ Upstream commit
0934ad42bb2c5df90a1b9de690f93de735b622fe ]
syzbot is reporting UAF at cipso_v4_doi_search() [1], for smk_cipso_doi()
is calling kfree() without removing from the cipso_v4_doi_list list after
netlbl_cfg_cipsov4_map_add() returned an error. We need to use
netlbl_cfg_cipsov4_del() in order to remove from the list and wait for
RCU grace period before kfree().
Link: https://syzkaller.appspot.com/bug?extid=93dba5b91f0fed312cbd
Reported-by: syzbot <syzbot+93dba5b91f0fed312cbd@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Fixes:
6c2e8ac0953fccdd ("netlabel: Update kernel configuration API")
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Horia Geantă [Fri, 15 Oct 2021 07:39:18 +0000 (10:39 +0300)]
crypto: tcrypt - fix skcipher multi-buffer tests for 1420B blocks
[ Upstream commit
3ae88f676aa63366ffa9eebb8ae787c7e19f0c57 ]
Commit
ad6d66bcac77e ("crypto: tcrypt - include 1420 byte blocks in aead and skcipher benchmarks")
mentions:
> power-of-2 block size. So let's add 1420 bytes explicitly, and round
> it up to the next blocksize multiple of the algo in question if it
> does not support 1420 byte blocks.
but misses updating skcipher multi-buffer tests.
Fix this by using the proper (rounded) input size.
Fixes:
ad6d66bcac77e ("crypto: tcrypt - include 1420 byte blocks in aead and skcipher benchmarks")
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jessica Zhang [Wed, 20 Oct 2021 18:34:38 +0000 (11:34 -0700)]
drm/msm/dsi: fix wrong type in msm_dsi_host
[ Upstream commit
409af447c2a0a6e08ba190993a1153c91d3b11bd ]
Change byte_clk_rate, pixel_clk_rate, esc_clk_rate, and src_clk_rate
from u32 to unsigned long, since clk_get_rate() returns an unsigned long.
Fixes:
a6bcddbc2ee1 ("drm/msm: dsi: Handle dual-channel for 6G as well")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jessica Zhang <jesszhan@codeaurora.org>
Link: https://lore.kernel.org/r/20211020183438.32263-1-jesszhan@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jessica Zhang [Wed, 20 Oct 2021 17:57:33 +0000 (10:57 -0700)]
drm/msm: Fix potential NULL dereference in DPU SSPP
[ Upstream commit
8bf71a5719b6cc5b6ba358096081e5d50ea23ab6 ]
Move initialization of sblk in _sspp_subblk_offset() after NULL check to
avoid potential NULL pointer dereference.
Fixes:
25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Jessica Zhang <jesszhan@codeaurora.org>
Link: https://lore.kernel.org/r/20211020175733.3379-1-jesszhan@codeaurora.org
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Joerg Roedel [Thu, 21 Oct 2021 08:08:32 +0000 (10:08 +0200)]
x86/sev: Fix stack type check in vc_switch_off_ist()
[ Upstream commit
5681981fb788281b09a4ea14d310d30b2bd89132 ]
The value of STACK_TYPE_EXCEPTION_LAST points to the last _valid_
exception stack. Reflect that in the check done in the
vc_switch_off_ist() function.
Fixes:
a13644f3a53de ("x86/entry/64: Add entry code for #VC handler")
Reported-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20211021080833.30875-2-joro@8bytes.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kees Cook [Sat, 28 Aug 2021 17:57:47 +0000 (10:57 -0700)]
clocksource/drivers/timer-ti-dm: Select TIMER_OF
[ Upstream commit
eda9a4f7af6ee47e9e131f20e4f8a41a97379293 ]
When building OMAP_DM_TIMER without TIMER_OF, there are orphan sections
due to the use of TIMER_OF_DELCARE() without CONFIG_TIMER_OF. Select
CONFIG_TIMER_OF when enaling OMAP_DM_TIMER:
arm-linux-gnueabi-ld: warning: orphan section `__timer_of_table' from `drivers/clocksource/timer-ti-dm-systimer.o' being placed in section `__timer_of_table'
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/lkml/202108282255.tkdt4ani-lkp@intel.com/
Cc: Tony Lindgren <tony@atomide.com>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Cc: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Cc: Ladislav Michl <ladis@linux-mips.org>
Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: linux-omap@vger.kernel.org
Fixes:
52762fbd1c47 ("clocksource/drivers/timer-ti-dm: Add clockevent and clocksource support")
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20210828175747.3777891-1-keescook@chromium.org
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Anders Roxell [Thu, 7 Oct 2021 19:13:37 +0000 (21:13 +0200)]
PM: hibernate: fix sparse warnings
[ Upstream commit
01de5fcd8b1ac0ca28d2bb0921226a54fdd62684 ]
When building the kernel with sparse enabled 'C=1' the following
warnings shows up:
kernel/power/swap.c:390:29: warning: incorrect type in assignment (different base types)
kernel/power/swap.c:390:29: expected int ret
kernel/power/swap.c:390:29: got restricted blk_status_t
This is due to function hib_wait_io() returns a 'blk_status_t' which is
a bitwise u8. Commit
5416da01ff6e ("PM: hibernate: Remove
blk_status_to_errno in hib_wait_io") seemed to have mixed up the return
type. However, the
4e4cbee93d56 ("block: switch bios to blk_status_t")
actually broke the behaviour by returning the wrong type.
Rework so function hib_wait_io() returns a 'int' instead of
'blk_status_t' and make sure to call function
blk_status_to_errno(hb->error)' when returning from function
hib_wait_io() a int gets returned.
Fixes:
4e4cbee93d56 ("block: switch bios to blk_status_t")
Fixes:
5416da01ff6e ("PM: hibernate: Remove blk_status_to_errno in hib_wait_io")
Signed-off-by: Anders Roxell <anders.roxell@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Max Gurtovoy [Sun, 17 Oct 2021 08:58:16 +0000 (11:58 +0300)]
nvme-rdma: fix error code in nvme_rdma_setup_ctrl
[ Upstream commit
09748122009aed7bfaa7acc33c10c083a4758322 ]
In case that icdoff is not zero or mandatory keyed sgls are not
supported by the NVMe/RDMA target, we'll go to error flow but we'll
return 0 to the caller. Fix it by returning an appropriate error code.
Fixes:
c66e2998c8ca ("nvme-rdma: centralize controller setup sequence")
Signed-off-by: Max Gurtovoy <mgurtovoy@nvidia.com>
Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ye Bin [Wed, 20 Oct 2021 07:39:59 +0000 (15:39 +0800)]
nbd: Fix use-after-free in pid_show
[ Upstream commit
0c98057be9efa32de78dbc4685fc73da9d71faa1 ]
I got issue as follows:
[ 263.886511] BUG: KASAN: use-after-free in pid_show+0x11f/0x13f
[ 263.888359] Read of size 4 at addr
ffff8880bf0648c0 by task cat/746
[ 263.890479] CPU: 0 PID: 746 Comm: cat Not tainted 4.19.90-dirty #140
[ 263.893162] Call Trace:
[ 263.893509] dump_stack+0x108/0x15f
[ 263.893999] print_address_description+0xa5/0x372
[ 263.894641] kasan_report.cold+0x236/0x2a8
[ 263.895696] __asan_report_load4_noabort+0x25/0x30
[ 263.896365] pid_show+0x11f/0x13f
[ 263.897422] dev_attr_show+0x48/0x90
[ 263.898361] sysfs_kf_seq_show+0x24d/0x4b0
[ 263.899479] kernfs_seq_show+0x14e/0x1b0
[ 263.900029] seq_read+0x43f/0x1150
[ 263.900499] kernfs_fop_read+0xc7/0x5a0
[ 263.903764] vfs_read+0x113/0x350
[ 263.904231] ksys_read+0x103/0x270
[ 263.905230] __x64_sys_read+0x77/0xc0
[ 263.906284] do_syscall_64+0x106/0x360
[ 263.906797] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Reproduce this issue as follows:
1. nbd-server 8000 /tmp/disk
2. nbd-client localhost 8000 /dev/nbd1
3. cat /sys/block/nbd1/pid
Then trigger use-after-free in pid_show.
Reason is after do step '2', nbd-client progress is already exit. So
it's task_struct already freed.
To solve this issue, revert part of
6521d39a64b3's modify and remove
useless 'recv_task' member of nbd_device.
Fixes:
6521d39a64b3 ("nbd: Remove variable 'pid'")
Signed-off-by: Ye Bin <yebin10@huawei.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Link: https://lore.kernel.org/r/20211020073959.2679255-1-yebin10@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stefan Agner [Tue, 19 Oct 2021 19:16:47 +0000 (21:16 +0200)]
phy: micrel: ksz8041nl: do not use power down mode
[ Upstream commit
2641b62d2fab52648e34cdc6994b2eacde2d27c1 ]
Some Micrel KSZ8041NL PHY chips exhibit continuous RX errors after using
the power down mode bit (0.11). If the PHY is taken out of power down
mode in a certain temperature range, the PHY enters a weird state which
leads to continuously reporting RX errors. In that state, the MAC is not
able to receive or send any Ethernet frames and the activity LED is
constantly blinking. Since Linux is using the suspend callback when the
interface is taken down, ending up in that state can easily happen
during a normal startup.
Micrel confirmed the issue in errata DS80000700A [*], caused by abnormal
clock recovery when using power down mode. Even the latest revision (A4,
Revision ID 0x1513) seems to suffer that problem, and according to the
errata is not going to be fixed.
Remove the suspend/resume callback to avoid using the power down mode
completely.
[*] https://ww1.microchip.com/downloads/en/DeviceDoc/
80000700A.pdf
Fixes:
1a5465f5d6a2 ("phy/micrel: Add suspend/resume support to Micrel PHYs")
Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tim Gardner [Tue, 19 Oct 2021 18:19:50 +0000 (12:19 -0600)]
net: enetc: unmap DMA in enetc_send_cmd()
[ Upstream commit
cd4bc63de774eee95e9bac26a565cd80e0fca421 ]
Coverity complains of a possible dereference of a null return value.
5. returned_null: kzalloc returns NULL. [show details]
6. var_assigned: Assigning: si_data = NULL return value from kzalloc.
488 si_data = kzalloc(data_size, __GFP_DMA | GFP_KERNEL);
489 cbd.length = cpu_to_le16(data_size);
490
491 dma = dma_map_single(&priv->si->pdev->dev, si_data,
492 data_size, DMA_FROM_DEVICE);
While this kzalloc() is unlikely to fail, I did notice that the function
returned without unmapping si_data.
Fix this by refactoring the error paths and checking for kzalloc()
failure.
Fixes:
888ae5a3952ba ("net: enetc: add tc flower psfp offload driver")
Cc: Claudiu Manoil <claudiu.manoil@nxp.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org (open list)
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Sat, 16 Oct 2021 08:43:58 +0000 (11:43 +0300)]
iwlwifi: pnvm: read EFI data only if long enough
[ Upstream commit
e864a77f51d0d8113b49cf7d030bc9dc911c8176 ]
If the data we get from EFI is not even long enough for
the package struct we expect then ignore it entirely.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes:
a1a6a4cf49ec ("iwlwifi: pnvm: implement reading PNVM from UEFI")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20211016114029.33feba783518.I54a5cf33975d0330792b3d208b225d479e168f32@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Sat, 16 Oct 2021 08:43:57 +0000 (11:43 +0300)]
iwlwifi: pnvm: don't kmemdup() more than we have
[ Upstream commit
0f892441d8c353144e3669b7991fa5fe0bd353e9 ]
We shouldn't kmemdup() more data than we have, that might
cause the code to crash. Fix that by updating the length
before the kmemdup.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20211016114029.ab0e64c3fba9.Ic6a3295fc384750b51b4270bf0b7d94984a139f2@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Sat, 16 Oct 2021 08:43:55 +0000 (11:43 +0300)]
iwlwifi: mvm: reset PM state on unsuccessful resume
[ Upstream commit
2f629a7772e2a7bdaff25178917a40073f79702c ]
If resume fails for some reason, we need to set the PM state
back to normal so we're able to send commands during firmware
reset, rather than failing all of them because we're in D3.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Fixes:
708a39aaca22 ("iwlwifi: mvm: don't send commands during suspend\resume transition")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/iwlwifi.20211016114029.7ceb9eaca9f6.If0cbef38c6d07ec1ddce125878a4bdadcb35d2c9@changeid
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jonas Dreßler [Sat, 16 Oct 2021 15:32:43 +0000 (17:32 +0200)]
mwifiex: Send DELBA requests according to spec
[ Upstream commit
cc8a8bc37466f79b24d972555237f3d591150602 ]
While looking at on-air packets using Wireshark, I noticed we're never
setting the initiator bit when sending DELBA requests to the AP: While
we set the bit on our del_ba_param_set bitmask, we forget to actually
copy that bitmask over to the command struct, which means we never
actually set the initiator bit.
Fix that and copy the bitmask over to the host_cmd_ds_11n_delba command
struct.
Fixes:
5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Jonas Dreßler <verdre@v0yd.nl>
Acked-by: Pali Rohár <pali@kernel.org>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211016153244.24353-5-verdre@v0yd.nl
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ziyang Xuan [Fri, 15 Oct 2021 04:03:35 +0000 (12:03 +0800)]
rsi: stop thread firstly in rsi_91x_init() error handling
[ Upstream commit
515e7184bdf0a3ebf1757cc77fb046b4fe282189 ]
When fail to init coex module, free 'common' and 'adapter' directly, but
common->tx_thread which will access 'common' and 'adapter' is running at
the same time. That will trigger the UAF bug.
==================================================================
BUG: KASAN: use-after-free in rsi_tx_scheduler_thread+0x50f/0x520 [rsi_91x]
Read of size 8 at addr
ffff8880076dc000 by task Tx-Thread/124777
CPU: 0 PID: 124777 Comm: Tx-Thread Not tainted 5.15.0-rc5+ #19
Call Trace:
dump_stack_lvl+0xe2/0x152
print_address_description.constprop.0+0x21/0x140
? rsi_tx_scheduler_thread+0x50f/0x520
kasan_report.cold+0x7f/0x11b
? rsi_tx_scheduler_thread+0x50f/0x520
rsi_tx_scheduler_thread+0x50f/0x520
...
Freed by task 111873:
kasan_save_stack+0x1b/0x40
kasan_set_track+0x1c/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0x109/0x140
kfree+0x117/0x4c0
rsi_91x_init+0x741/0x8a0 [rsi_91x]
rsi_probe+0x9f/0x1750 [rsi_usb]
Stop thread before free 'common' and 'adapter' to fix it.
Fixes:
2108df3c4b18 ("rsi: add coex support")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211015040335.1021546-1-william.xuanziyang@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shayne Chen [Mon, 18 Oct 2021 08:07:04 +0000 (16:07 +0800)]
mt76: mt7915: fix muar_idx in mt7915_mcu_alloc_sta_req()
[ Upstream commit
161cc13912d3c3e8857001988dfba39be842454a ]
For broadcast/multicast wcid, the muar_idx should be 0xe.
Fixes:
e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shayne Chen [Mon, 18 Oct 2021 08:07:02 +0000 (16:07 +0800)]
mt76: mt7915: fix sta_rec_wtbl tag len
[ Upstream commit
afa0370f3a3a64af6d368da0bedd72ab2a026cd0 ]
Fix tag len error for sta_rec_wtbl, which causes fw parsing error for
the tags placed behind it.
Fixes:
e57b7901469f ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Thu, 14 Oct 2021 15:19:53 +0000 (17:19 +0200)]
mt76: connac: fix possible NULL pointer dereference in mt76_connac_get_phy_mode_v2
[ Upstream commit
b5f2ba8a4c794e8349c0e30036352b9f685164c4 ]
Fix the following NULL pointer dereference in mt76_connac_get_phy_mode_v2
routine triggered on mt7663s device when sta is NULL
[ 5.490700] mt7663s mmc0:0001:1: N9 Firmware Version: 3.1.1, Build Time:
20200604161656
[ 5.490815] mt7663s mmc0:0001:1: Region number: 0x4
[ 5.490868] mt7663s mmc0:0001:1: Parsing tailer Region: 0
[ 5.496251] mt7663s mmc0:0001:1: Region 0, override_addr = 0x00118000
[ 5.496419] mt7663s mmc0:0001:1: Parsing tailer Region: 1
[ 5.624027] mt7663s mmc0:0001:1: Parsing tailer Region: 2
[ 5.656999] mt7663s mmc0:0001:1: Parsing tailer Region: 3
[ 5.671876] mt7663s mmc0:0001:1: override_addr = 0x00118000, option = 3
[ 9.358658] BUG: kernel NULL pointer dereference, address:
0000000000000000
[ 9.358775] #PF: supervisor read access in kernel mode
[ 9.358831] #PF: error_code(0x0000) - not-present page
[ 9.358886] PGD 0 P4D 0
[ 9.358917] Oops: 0000 [#1] SMP
[ 9.358960] CPU: 0 PID: 235 Comm: NetworkManager Not tainted 5.15.0-rc4-kvm-02151-g39e333d657f4-dirty #769
[ 9.359057] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014
[ 9.359150] RIP: 0010:mt76_connac_get_phy_mode_v2+0xc9/0x11c
[ 9.359473] RAX:
0000000000000013 RBX:
0000000000000000 RCX:
0000000000000027
[ 9.359546] RDX:
ffff8881f9c17358 RSI:
0000000000000001 RDI:
ffff8881f9c17350
[ 9.359624] RBP:
ffff88810bac1ed4 R08:
ffffffff822a4a48 R09:
0000000000000003
[ 9.359697] R10:
ffffffff82234a60 R11:
ffffffff82234a60 R12:
ffff88810bac1eec
[ 9.359779] R13:
0000000000000000 R14:
ffff88810bad1648 R15:
ffff88810bac1eb8
[ 9.359859] FS:
00007f5f1e45bbc0(0000) GS:
ffff8881f9c00000(0000) knlGS:
0000000000000000
[ 9.359939] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 9.360003] CR2:
0000000000000000 CR3:
0000000105d5d000 CR4:
00000000000006b0
[ 9.360083] Call Trace:
[ 9.360116] mt76_connac_mcu_uni_add_bss.cold+0x21/0x250
[ 9.360175] ? schedule_preempt_disabled+0xa/0x10
[ 9.360232] ? __mutex_lock.constprop.0+0x2ab/0x460
[ 9.360286] mt7615_remove_interface+0x63/0x1d0
[ 9.360342] drv_remove_interface+0x32/0xe0
[ 9.360385] ieee80211_do_stop+0x5da/0x800
[ 9.360428] ? dev_reset_queue+0x30/0x90
[ 9.360472] ieee80211_stop+0x3b/0xb0
[ 9.360516] __dev_close_many+0x7a/0xd0
[ 9.360559] __dev_change_flags+0xd6/0x1f0
[ 9.360604] dev_change_flags+0x21/0x60
[ 9.360648] do_setlink+0x259/0xfb0
[ 9.360686] ? __nla_validate_parse+0x51/0xb80
[ 9.360742] __rtnl_newlink+0x5b3/0x960
[ 9.360785] ? inet6_fill_ifla6_attrs+0x41d/0x470
[ 9.360841] ? __kmalloc_track_caller+0x57/0x3c0
[ 9.360905] ? netlink_trim+0x8a/0xb0
[ 9.360949] ? skb_queue_tail+0x1b/0x50
Fixes:
67aa27431c7f8 ("mt76: mt7921: rely on mt76_connac_mcu common library")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ryder Lee [Mon, 27 Sep 2021 04:59:49 +0000 (12:59 +0800)]
mt76: mt7615: fix monitor mode tear down crash
[ Upstream commit
a6fdbdd1ac2996a58a84672ef37efb5cbb98fadf ]
[ 103.451600] CPU 3 Unable to handle kernel paging request at virtual address
00000003, epc ==
8576591c, ra ==
857659f0
[ 103.462226] Oops[#1]:
[ 103.464499] CPU: 3 PID: 9247 Comm: ifconfig Tainted: G W 5.4.143 #0
[ 103.472031] $ 0 :
00000000 00000001 83be3854 00000000
[ 103.477239] $ 4 :
8102a374 8102a374 8102f0b0 00000200
[ 103.482444] $ 8 :
0000002d 000001e4 64373765 5d206337
[ 103.487647] $12 :
00000000 00000005 00000000 0006d1df
[ 103.492853] $16 :
83be3848 853838a8 8743d600 00010000
[ 103.498059] $20 :
00000000 00000000 8553dec0 0000007f
[ 103.503266] $24 :
00000003 80382084
[ 103.508472] $28 :
831d4000 831d5bc0 00000001 857659f0
[ 103.513678] Hi :
00000122
[ 103.516543] Lo :
d1768000
[ 103.519452] epc :
8576591c mt7615_mcu_add_bss+0xd0/0x3c0 [mt7615_common]
[ 103.526306] ra :
857659f0 mt7615_mcu_add_bss+0x1a4/0x3c0 [mt7615_common]
[ 103.533232] Status:
11007c03 KERNEL EXL IE
[ 103.537402] Cause :
40800008 (ExcCode 02)
[ 103.541389] BadVA :
00000003
[ 103.544253] PrId :
0001992f (MIPS 1004Kc)
[ 103.797086] Call Trace:
[ 103.799562] [<
8576591c>] mt7615_mcu_add_bss+0xd0/0x3c0 [mt7615_common]
[ 103.806082] [<
85760a14>] mt7615_remove_interface+0x74/0x1e0 [mt7615_common]
[ 103.813280] [<
85603fcc>] drv_remove_interface+0x2c/0xa0 [mac80211]
[ 103.819612] [<
8561a8e4>] ieee80211_del_virtual_monitor.part.22+0x74/0xe8 [mac80211]
[ 103.827410] [<
8561b7f0>] ieee80211_do_stop+0x4a4/0x8a0 [mac80211]
[ 103.833671] [<
8561bc00>] ieee80211_stop+0x14/0x24 [mac80211]
[ 103.839405] [<
8045a328>] __dev_close_many+0x9c/0x10c
[ 103.844364] [<
80463de4>] __dev_change_flags+0x16c/0x1e4
[ 103.849569] [<
80463e84>] dev_change_flags+0x28/0x70
[ 103.854440] [<
80521e54>] devinet_ioctl+0x280/0x774
[ 103.859222] [<
80526248>] inet_ioctl+0xa4/0x1c8
[ 103.863674] [<
80436830>] sock_ioctl+0x2d8/0x4bc
[ 103.868201] [<
801adbb4>] do_vfs_ioctl+0xb8/0x7c0
[ 103.872804] [<
801ae30c>] ksys_ioctl+0x50/0xb4
[ 103.877156] [<
80014598>] syscall_common+0x34/0x58
Fixes:
04b8e65922f63 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets")
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sean Wang [Tue, 14 Sep 2021 15:50:22 +0000 (23:50 +0800)]
mt76: mt7921: fix retrying release semaphore without end
[ Upstream commit
02d1c7d494d8052288bc175e4ff54b56d08a3c5f ]
We should pass the error code to the caller immediately
to avoid the possible infinite retry to release the semaphore.
Fixes:
1c099ab44727 ("mt76: mt7921: add MCU support")
Co-developed-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Tue, 14 Sep 2021 16:42:51 +0000 (18:42 +0200)]
mt76: mt7915: fix possible infinite loop release semaphore
[ Upstream commit
e500c9470e26be66eb2bc6de773ae9091149118a ]
Fix possible infinite loop in mt7915_load_patch if
mt7915_mcu_patch_sem_ctrl always returns an error.
Fixes:
e57b7901469fc ("mt76: add mac80211 driver for MT7915 PCIe-based chipsets")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ryder Lee [Thu, 2 Sep 2021 05:52:04 +0000 (13:52 +0800)]
mt76: mt7615: fix hwmon temp sensor mem use-after-free
[ Upstream commit
0bb4e9187ea4a59dc6658a62978deda0c0dc4b28 ]
Without this change, garbage is seen in the hwmon name and sensors output
for mt7615 is garbled.
Fixes:
109e505ad944 ("mt76: mt7615: add thermal sensor device support")
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ben Greear [Thu, 2 Sep 2021 05:52:03 +0000 (13:52 +0800)]
mt76: mt7915: fix hwmon temp sensor mem use-after-free
[ Upstream commit
0ae3ff5684514d72357240f1033a7494c51f93ed ]
Without this change, garbage is seen in the hwmon name and sensors output
for mt7915 is garbled. It appears that the hwmon logic does not make a
copy of the incoming string, but instead just copies a char* and expects
it to never go away.
Fixes:
33fe9c639c13 ("mt76: mt7915: add thermal sensor device support")
Signed-off-by: Ben Greear <greearb@candelatech.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Wed, 18 Aug 2021 08:20:57 +0000 (10:20 +0200)]
mt76: mt7921: always wake device if necessary in debugfs
[ Upstream commit
569008744178b672ea3ad9047fa3098f1b73ca55 ]
Add missing device wakeup in debugfs code if we are accessing chip
registers.
Fixes:
1d8efc741df8 ("mt76: mt7921: introduce Runtime PM support")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sean Wang [Fri, 13 Aug 2021 18:09:18 +0000 (02:09 +0800)]
mt76: mt7921: fix kernel warning from cfg80211_calculate_bitrate
[ Upstream commit
8e695328a1006b7bab2d972e7d0111fa6e6faf51 ]
Fix the kernel warning from cfg80211_calculate_bitrate
due to the legacy rate is not parsed well in the current driver.
Also, zeros struct rate_info before we fill it out to avoid the old value
is kept such as rate->legacy.
[ 790.921560] WARNING: CPU: 7 PID: 970 at net/wireless/util.c:1298 cfg80211_calculate_bitrate+0x354/0x35c [cfg80211]
[ 790.987738] Hardware name: MediaTek Asurada rev1 board (DT)
[ 790.993298] pstate:
a0400009 (NzCv daif +PAN -UAO)
[ 790.998104] pc : cfg80211_calculate_bitrate+0x354/0x35c [cfg80211]
[ 791.004295] lr : cfg80211_calculate_bitrate+0x180/0x35c [cfg80211]
[ 791.010462] sp :
ffffffc0129c3880
[ 791.013765] x29:
ffffffc0129c3880 x28:
ffffffd38305bea8
[ 791.019065] x27:
ffffffc0129c3970 x26:
0000000000000013
[ 791.024364] x25:
00000000000003ca x24:
000000000000002f
[ 791.029664] x23:
00000000000000d0 x22:
ffffff8d108bc000
[ 791.034964] x21:
ffffff8d108bc0d0 x20:
ffffffc0129c39a8
[ 791.040264] x19:
ffffffc0129c39a8 x18:
00000000ffff0a10
[ 791.045563] x17:
0000000000000050 x16:
00000000000000ec
[ 791.050910] x15:
ffffffd3f9ebed9c x14:
0000000000000006
[ 791.056211] x13:
00000000000b2eea x12:
0000000000000000
[ 791.061511] x11:
00000000ffffffff x10:
0000000000000000
[ 791.066811] x9 :
0000000000000000 x8 :
0000000000000000
[ 791.072110] x7 :
0000000000000000 x6 :
ffffffd3fafa5a7b
[ 791.077409] x5 :
0000000000000000 x4 :
0000000000000000
[ 791.082708] x3 :
0000000000000000 x2 :
0000000000000000
[ 791.088008] x1 :
ffffff8d3f79c918 x0 :
0000000000000000
[ 791.093308] Call trace:
[ 791.095770] cfg80211_calculate_bitrate+0x354/0x35c [cfg80211]
[ 791.101615] nl80211_put_sta_rate+0x6c/0x2c0 [cfg80211]
[ 791.106853] nl80211_send_station+0x980/0xaa4 [cfg80211]
[ 791.112178] nl80211_get_station+0xb4/0x134 [cfg80211]
[ 791.117308] genl_rcv_msg+0x3a0/0x440
[ 791.120960] netlink_rcv_skb+0xcc/0x118
[ 791.124785] genl_rcv+0x34/0x48
[ 791.127916] netlink_unicast+0x144/0x1dc
Fixes:
1c099ab44727 ("mt76: mt7921: add MCU support")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sean Wang [Wed, 11 Aug 2021 05:58:24 +0000 (13:58 +0800)]
mt76: mt7921: fix firmware usage of RA info using legacy rates
[ Upstream commit
99b8e195994d9d77de3bfe0cb403c44a57c2cf79 ]
According to the firmware usage, OFDM rates should fill out bit 6 - 13
while CCK rates should fill out bit 0 - 3 in legacy field of RA info to
make the rate adaption runs propertly. Otherwise, a unicast frame might be
picking up the unsupported rate to send out.
Fixes:
1c099ab44727 ("mt76: mt7921: add MCU support")
Reported-by: Joshua Emele <jemele@chromium.org>
Co-developed-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: YN Chen <YN.Chen@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sean Wang [Thu, 12 Aug 2021 22:48:24 +0000 (06:48 +0800)]
mt76: mt7921: report HE MU radiotap
[ Upstream commit
4fee32153ab62356aeea9d152d8f33a5fd3a0086 ]
Report HE MU/BF radiotap.
That fixed HE MU packets dropped by mac80211 because they are missing the
ieee80211_radiotap_he_mu header.
Fixes:
163f4d22c118d ("mt76: mt7921: add MAC support")
Co-developed-by: Ryder Lee <ryder.lee@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
Co-developed-by: Eric-SY Chang <Eric-SY.Chang@mediatek.com>
Signed-off-by: Eric-SY Chang <Eric-SY.Chang@mediatek.com>
Tested-by: Eric-SY Chang <Eric-SY.Chang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Sun, 8 Aug 2021 19:11:49 +0000 (21:11 +0200)]
mt76: overwrite default reg_ops if necessary
[ Upstream commit
f6e1f59885dae5a2553f8bbd328be2cb1c80ccb2 ]
Introduce mt76_register_debugfs_fops routine in order to
define per-driver regs file operations and make sure the
device is up before reading or writing its registers
Fixes:
1d8efc741df8 ("mt76: mt7921: introduce Runtime PM support")
Fixes:
de5ff3c9d1a2 ("mt76: mt7615: introduce pm_power_save delayed work")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Leon Yen [Tue, 27 Jul 2021 22:59:16 +0000 (06:59 +0800)]
mt76: connac: fix GTK rekey offload failure on WPA mixed mode
[ Upstream commit
781f62960c635cfed55a8f8c0f909bdaf8268257 ]
Update the proper firmware programming sequence to fix GTK rekey
offload failure on WPA mixed mode.
In the mt76_connac_mcu_key_iter,
gtk_tlv->proto should be only set up on pairwise key
and gtk_tlk->group_cipher should be only set up on the group key.
Otherwise, those parameters required by firmware would be set
incorrectly to cause GTK rekey offload failure on WPA mixed mode
and then disconnection follows.
Fixes:
b47e21e75c80 ("mt76: mt7615: add gtk rekey offload support")
Co-developed-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Leon Yen <Leon.Yen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Deren Wu [Tue, 27 Jul 2021 09:47:09 +0000 (17:47 +0800)]
mt76: mt7921: fix dma hang in rmmod
[ Upstream commit
a23f80aa9c5e6ad4ec8df88037b7ffd4162b1ec4 ]
The dma would be broken after rmmod flow. There are two different
cases causing this issue.
1. dma access without privilege.
2. hw access sequence borken by another context.
This patch handle both cases to avoid hw crash.
Fixes:
2b9ea5a8cf1bd ("mt76: mt7921: add mt7921_dma_cleanup in mt7921_unregister_device")
Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shayne Chen [Tue, 20 Jul 2021 13:00:14 +0000 (21:00 +0800)]
mt76: mt7915: fix bit fields for HT rate idx
[ Upstream commit
47f1c08db7f3aaa2d13f8e56209375462ace7b8a ]
The bit fields of tx rate idx should be 6 bits, otherwise it might be
incorrect in HT mode.
For VHT/HE rates, only 4 bits are actually used by rate idx, the other
2 bits are used for other functions.
Fixes:
c31d94af1843 ("mt76: mt7915: fix tx rate related fields in tx descriptor")
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shayne Chen [Tue, 20 Jul 2021 02:48:32 +0000 (10:48 +0800)]
mt76: mt7915: fix potential overflow of eeprom page index
[ Upstream commit
82a980f82a511ce74ab57eb9f692d02225eb32f4 ]
If total eeprom size is divisible by per-page size, the i in for loop
will exceed max page index, which happens in our newer chipset.
Fixes:
26f18380e6ca ("mt76: mt7915: add support for flash mode")
Signed-off-by: Bo Jiao <bo.jiao@mediatek.com>
Signed-off-by: Shayne Chen <shayne.chen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Deren Wu [Wed, 14 Jul 2021 15:50:52 +0000 (23:50 +0800)]
mt76: mt7921: Fix out of order process by invalid event pkt
[ Upstream commit
cd3f387371e941e6806b455b4ba5b9f4ca4b77c6 ]
The acceptable event report should inlcude original CMD-ID. Otherwise,
drop unexpected result from fw.
Fixes:
1c099ab44727c ("mt76: mt7921: add MCU support")
Signed-off-by: Jimmy Hu <Jimmy.Hu@mediatek.com>
Signed-off-by: Deren Wu <deren.wu@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Tue, 22 Jun 2021 07:48:30 +0000 (09:48 +0200)]
mt76: mt76x02: fix endianness warnings in mt76x02_mac.c
[ Upstream commit
c33edef520213feccebc22c9474c685b9fb60611 ]
Fix the following sparse warning in mt76x02_mac_write_txwi and
mt76x02_mac_tx_rate_val routines:
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c:237:19:
warning: restricted __le16 degrades to intege
warning: cast from restricted __le16
drivers/net/wireless/mediatek/mt76/mt76x02_mac.c:383:28:
warning: incorrect type in assignment (different base types)
expected restricted __le16 [usertype] rate
got unsigned long
Fixes:
db9f11d3433f7 ("mt76: store wcid tx rate info in one u32 reduce locking")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Wed, 23 Jun 2021 13:19:19 +0000 (15:19 +0200)]
mt76: mt7921: fix survey-dump reporting
[ Upstream commit
64ed76d118c656907ec1155f2cdd24de778470a2 ]
Fix MIB tx-rx MIB counters for survey-dump reporting.
Fixes:
163f4d22c118d ("mt76: mt7921: add MAC support")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sean Wang [Sun, 20 Jun 2021 07:48:07 +0000 (15:48 +0800)]
mt76: fix build error implicit enumeration conversion
[ Upstream commit
adedbc643f02f5a3193b8dcc5cfca97b4c988667 ]
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c:114:10: error: implicit
conversion from enumeration type 'enum mt76_cipher_type' to different
enumeration type 'enum mcu_cipher_type' [-Werror,-Wenum-conversion]
return MT_CIPHER_NONE;
~~~~~~ ^~~~~~~~~~~~~~
drivers/net/wireless/mediatek/mt76/mt7921/mcu.c:114:10: error: implicit
conversion from enumeration type 'enum mt76_cipher_type' to different
enumeration type 'enum mcu_cipher_type' [-Werror,-Wenum-conversion]
return MT_CIPHER_NONE;
~~~~~~ ^~~~~~~~~~~~~~
Fixes:
c368362c36d3 ("mt76: fix iv and CCMP header insertion")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Leon Yen [Thu, 8 Jul 2021 04:29:06 +0000 (12:29 +0800)]
mt76: connac: fix mt76_connac_gtk_rekey_tlv usage
[ Upstream commit
d741abeafa47a7331cd4fe526e44db4ad3da0f62 ]
The mistaken structure is introduced since we added the GTK rekey offload
to mt7663. The patch fixes mt76_connac_gtk_rekey_tlv structure according
to the MT7663 and MT7921 firmware we have submitted into
linux-firmware.git.
Fixes:
b47e21e75c80 ("mt76: mt7615: add gtk rekey offload support")
Signed-off-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Leon Yen <Leon.Yen@mediatek.com>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Fri, 25 Jun 2021 14:58:54 +0000 (17:58 +0300)]
mt76: mt7915: fix info leak in mt7915_mcu_set_pre_cal()
[ Upstream commit
3924715ffe5e064a85f56490f77b7b2084230800 ]
Zero out all the unused members of "req" so that we don't disclose
stack information.
Fixes:
495184ac91bb ("mt76: mt7915: add support for applying pre-calibration data")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Mon, 21 Jun 2021 21:53:22 +0000 (23:53 +0200)]
mt76: mt7615: fix endianness warning in mt7615_mac_write_txwi
[ Upstream commit
d81bfb41e30c42531536c5d2baa4d275a8309715 ]
Fix the following sparse warning in mt7615_mac_write_txwi routine:
drivers/net/wireless/mediatek/mt76/mt7615/mac.c:758:17:
warning: incorrect type in assignment
expected restricted __le32 [usertype]
got unsigned long
Fixes:
04b8e65922f63 ("mt76: add mac80211 driver for MT7615 PCIe-based chipsets")
Fixes:
d4bf77bd74930 ("mt76: mt7615: introduce mt7663u support to mt7615_write_txwi")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Mon, 21 Jun 2021 09:18:58 +0000 (11:18 +0200)]
mt76: mt7921: fix endianness warning in mt7921_update_txs
[ Upstream commit
7fc167bbc9296e6aeaaa4063db3639e8a3db75f6 ]
Fix the following sparse warning in mt7921_update_txs routine:
drivers/net/wireless/mediatek/mt76/mt7921/mac.c:752:31:
warning: cast to restricted __le32
drivers/net/wireless/mediatek/mt76/mt7921/mac.c:752:31:
warning: restricted __le32 degrades to integer
Fixes:
e5bca8c5d2cd3 ("mt76: mt7921: improve code readability for mt7921_update_txs")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Mon, 21 Jun 2021 08:21:31 +0000 (10:21 +0200)]
mt76: mt7915: fix endianness warning in mt7915_mac_add_txs_skb
[ Upstream commit
08b3c8da87aed4200dab00906f149d675ca90f23 ]
Fix the following sparse warning in mt7915_mac_add_txs_skb routine:
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1235:29:
warning: cast to restricted __le32
drivers/net/wireless/mediatek/mt76/mt7915/mac.c:1235:23:
warning: restricted __le32 degrades to integer
Fixes:
3de4cb1756565 ("mt76: mt7915: add support for tx status reporting")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lorenzo Bianconi [Sat, 19 Jun 2021 18:18:19 +0000 (20:18 +0200)]
mt76: mt7921: fix endianness in mt7921_mcu_tx_done_event
[ Upstream commit
df040215c077de0c13aab12c222bd0360a0d3988 ]
Fix endianness in mt7921_mcu_tx_done_event event reported by the
firmware.
Fixes:
3cce2b98e0241 ("mt76: mt7921: introduce mac tx done handling")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lang Yu [Mon, 11 Oct 2021 05:57:25 +0000 (13:57 +0800)]
drm/amdkfd: Fix an inappropriate error handling in allloc memory of gpu
[ Upstream commit
5aeeac6fa38fca450faed9770f75b1470c0e2073 ]
We should unreference a gem object instead of an amdgpu bo here.
Fixes:
fd9a9f8801de ("drm/amdgpu: Use GEM obj reference for KFD BOs")
Signed-off-by: Lang Yu <lang.yu@amd.com>
Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rafael J. Wysocki [Sat, 16 Oct 2021 10:11:08 +0000 (12:11 +0200)]
ACPI: PM: Fix sharing of wakeup power resources
[ Upstream commit
a2d7b2e004af6b09f21ac3d10f8f4456c16a8ddf ]
If an ACPI wakeup power resource is shared between multiple devices,
it may not be managed correctly.
Suppose, for example, that two devices, A and B, share a wakeup power
resource P whose wakeup_enabled flag is 0 initially. Next, suppose
that wakeup power is enabled for A and B, in this order, and disabled
for B. When wakeup power is enabled for A, P will be turned on and
its wakeup_enabled flag will be set. Next, when wakeup power is
enabled for B, P will not be touched, because its wakeup_enabled flag
is set. Now, when wakeup power is disabled for B, P will be turned
off which is incorrect, because A will still need P in order to signal
wakeup.
Moreover, if wakeup power is enabled for A and then disabled for B,
the latter will cause P to be turned off incorrectly (it will be still
needed by A), because acpi_disable_wakeup_device_power() is allowed
to manipulate power resources when the wakeup.prepare_count counter
of the given device is 0.
While the first issue could be addressed by changing the
wakeup_enabled power resource flag into a counter, addressing the
second one requires modifying acpi_disable_wakeup_device_power() to
do nothing when the target device's wakeup.prepare_count reference
counter is zero and that would cause the new counter to be redundant.
Namely, if acpi_disable_wakeup_device_power() is modified as per the
above, every change of the new counter following a wakeup.prepare_count
change would be reflected by the analogous change of the main reference
counter of the given power resource.
Accordingly, modify acpi_disable_wakeup_device_power() to do nothing
when the target device's wakeup.prepare_count reference counter is
zero and drop the power resource wakeup_enabled flag altogether.
While at it, ensure that all of the power resources that can be
turned off will be turned off when disabling device wakeup due to
a power resource manipulation error, to prevent energy from being
wasted.
Fixes:
b5d667eb392e ("ACPI / PM: Take unusual configurations of power resources into account")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Rafael J. Wysocki [Fri, 15 Oct 2021 17:01:28 +0000 (19:01 +0200)]
ACPI: PM: Turn off unused wakeup power resources
[ Upstream commit
7a63296d6f579a02b2675b4b0fe5b1cd3235e8d3 ]
If an ACPI power resource is found to be "on" during the
initialization of the list of wakeup power resources of a device,
it is reference counted and its wakeup_enabled flag is set, which is
problematic if the deivce in question is the only user of the given
power resource, it is never runtime-suspended and it is not allowed
to wake up the system from sleep, because in that case the given
power resource will stay "on" until the system reboots and energy
will be wasted.
It is better to simply turn off wakeup power resources that are "on"
during the initialization unless their reference counters are not
zero, because that may be the only opportunity to prevent them from
staying in the "on" state all the time.
Fixes:
b5d667eb392e ("ACPI / PM: Take unusual configurations of power resources into account")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fei Shao [Thu, 14 Oct 2021 12:03:52 +0000 (20:03 +0800)]
mailbox: mtk-cmdq: Fix local clock ID usage
[ Upstream commit
0a5ad4322927ee4aaba6facc0e4faf1ab6c0d48e ]
In the probe function, the clock IDs were pointed to local variables
which should only be used in the same code block, and any access to them
after the probing stage becomes an use-after-free case.
Since there are only limited variants of the gce clock names so far, we
can just declare them as static constants to fix the issue.
Fixes:
85dfdbfc13ea ("mailbox: cmdq: add multi-gce clocks support for mt8195")
Signed-off-by: Fei Shao <fshao@chromium.org>
Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Fei Shao [Thu, 14 Oct 2021 12:03:51 +0000 (20:03 +0800)]
mailbox: mtk-cmdq: Validate alias_id on probe
[ Upstream commit
5c154b6a51c2d2d7f266b3ef49b7dd1dc8cb5b65 ]
of_alias_get_id() may return -ENODEV which leads to illegal access to
the cmdq->clocks array.
Adding a check over alias_id to prevent the unexpected behavior.
Fixes:
85dfdbfc13ea ("mailbox: cmdq: add multi-gce clocks support for mt8195")
Signed-off-by: Fei Shao <fshao@chromium.org>
Reviewed-by: Tzung-Bi Shih <tzungbi@google.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nathan Chancellor [Mon, 18 Oct 2021 18:25:37 +0000 (11:25 -0700)]
platform/x86: thinkpad_acpi: Fix bitwise vs. logical warning
[ Upstream commit
fd96e35ea7b95f1e216277805be89d66e4ae962d ]
A new warning in clang points out a use of bitwise OR with boolean
expressions in this driver:
drivers/platform/x86/thinkpad_acpi.c:9061:11: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical]
else if ((strlencmp(cmd, "level disengaged") == 0) |
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
||
drivers/platform/x86/thinkpad_acpi.c:9061:11: note: cast one or both operands to int to silence this warning
1 error generated.
This should clearly be a logical OR so change it to fix the warning.
Fixes:
fe98a52ce754 ("ACPI: thinkpad-acpi: add sysfs support to fan subdriver")
Link: https://github.com/ClangBuiltLinux/linux/issues/1476
Reported-by: Tor Vic <torvic9@mailbox.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/r/20211018182537.2316800-1-nathan@kernel.org
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Andrea Righi [Tue, 19 Oct 2021 09:20:26 +0000 (11:20 +0200)]
blk-wbt: prevent NULL pointer dereference in wb_timer_fn
[ Upstream commit
480d42dc001bbfe953825a92073012fcd5a99161 ]
The timer callback used to evaluate if the latency is exceeded can be
executed after the corresponding disk has been released, causing the
following NULL pointer dereference:
[ 119.987108] BUG: kernel NULL pointer dereference, address:
0000000000000098
[ 119.987617] #PF: supervisor read access in kernel mode
[ 119.987971] #PF: error_code(0x0000) - not-present page
[ 119.988325] PGD
7c4a4067 P4D
7c4a4067 PUD
7bf63067 PMD 0
[ 119.988697] Oops: 0000 [#1] SMP NOPTI
[ 119.988959] CPU: 1 PID: 9353 Comm: cloud-init Not tainted 5.15-rc5+arighi #rc5+arighi
[ 119.989520] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
[ 119.990055] RIP: 0010:wb_timer_fn+0x44/0x3c0
[ 119.990376] Code: 41 8b 9c 24 98 00 00 00 41 8b 94 24 b8 00 00 00 41 8b 84 24 d8 00 00 00 4d 8b 74 24 28 01 d3 01 c3 49 8b 44 24 60 48 8b 40 78 <4c> 8b b8 98 00 00 00 4d 85 f6 0f 84 c4 00 00 00 49 83 7c 24 30 00
[ 119.991578] RSP: 0000:
ffffb5f580957da8 EFLAGS:
00010246
[ 119.991937] RAX:
0000000000000000 RBX:
0000000000000000 RCX:
0000000000000004
[ 119.992412] RDX:
0000000000000000 RSI:
0000000000000000 RDI:
ffff88f476d7f780
[ 119.992895] RBP:
ffffb5f580957dd0 R08:
0000000000000000 R09:
0000000000000000
[ 119.993371] R10:
0000000000000004 R11:
0000000000000002 R12:
ffff88f476c84500
[ 119.993847] R13:
ffff88f4434390c0 R14:
0000000000000000 R15:
ffff88f4bdc98c00
[ 119.994323] FS:
00007fb90bcd9c00(0000) GS:
ffff88f4bdc80000(0000) knlGS:
0000000000000000
[ 119.994952] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 119.995380] CR2:
0000000000000098 CR3:
000000007c0d6000 CR4:
00000000000006e0
[ 119.995906] Call Trace:
[ 119.996130] ? blk_stat_free_callback_rcu+0x30/0x30
[ 119.996505] blk_stat_timer_fn+0x138/0x140
[ 119.996830] call_timer_fn+0x2b/0x100
[ 119.997136] __run_timers.part.0+0x1d1/0x240
[ 119.997470] ? kvm_clock_get_cycles+0x11/0x20
[ 119.997826] ? ktime_get+0x3e/0xa0
[ 119.998110] ? native_apic_msr_write+0x2c/0x30
[ 119.998456] ? lapic_next_event+0x20/0x30
[ 119.998779] ? clockevents_program_event+0x94/0xf0
[ 119.999150] run_timer_softirq+0x2a/0x50
[ 119.999465] __do_softirq+0xcb/0x26f
[ 119.999764] irq_exit_rcu+0x8c/0xb0
[ 120.000057] sysvec_apic_timer_interrupt+0x43/0x90
[ 120.000429] ? asm_sysvec_apic_timer_interrupt+0xa/0x20
[ 120.000836] asm_sysvec_apic_timer_interrupt+0x12/0x20
In this case simply return from the timer callback (no action
required) to prevent the NULL pointer dereference.
BugLink: https://bugs.launchpad.net/bugs/1947557
Link: https://lore.kernel.org/linux-mm/YWRNVTk9N8K0RMst@arighi-desktop/
Fixes:
34dbad5d26e2 ("blk-stat: convert to callback-based statistics reporting")
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Link: https://lore.kernel.org/r/YW6N2qXpBU3oc50q@arighi-desktop
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Schmitz [Tue, 19 Oct 2021 06:13:21 +0000 (19:13 +1300)]
block: ataflop: fix breakage introduced at blk-mq refactoring
[ Upstream commit
86d46fdaa12ae5befc16b8d73fc85a3ca0399ea6 ]
Refactoring of the Atari floppy driver when converting to blk-mq
has broken the state machine in not-so-subtle ways:
finish_fdc() must be called when operations on the floppy device
have completed. This is crucial in order to relase the ST-DMA
lock, which protects against concurrent access to the ST-DMA
controller by other drivers (some DMA related, most just related
to device register access - broken beyond compare, I know).
When rewriting the driver's old do_request() function, the fact
that finish_fdc() was called only when all queued requests had
completed appears to have been overlooked. Instead, the new
request function calls finish_fdc() immediately after the last
request has been queued. finish_fdc() executes a dummy seek after
most requests, and this overwrites the state machine's interrupt
hander that was set up to wait for completion of the read/write
request just prior. To make matters worse, finish_fdc() is called
before device interrupts are re-enabled, making certain that the
read/write interupt is missed.
Shifting the finish_fdc() call into the read/write request
completion handler ensures the driver waits for the request to
actually complete. With a queue depth of 2, we won't see long
request sequences, so calling finish_fdc() unconditionally just
adds a little overhead for the dummy seeks, and keeps the code
simple.
While we're at it, kill ataflop_commit_rqs() which does nothing
but run finish_fdc() unconditionally, again likely wiping out an
in-flight request.
Signed-off-by: Michael Schmitz <schmitzmic@gmail.com>
Fixes:
6ec3938cff95 ("ataflop: convert to blk-mq")
CC: linux-block@vger.kernel.org
CC: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Link: https://lore.kernel.org/r/20211019061321.26425-1-schmitzmic@gmail.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bixuan Cui [Sat, 11 Sep 2021 08:58:47 +0000 (16:58 +0800)]
io-wq: Remove duplicate code in io_workqueue_create()
[ Upstream commit
71e1cef2d794338cc7b979d4c6144e1dc12718b5 ]
While task_work_add() in io_workqueue_create() is true,
then duplicate code is executed:
-> clear_bit_unlock(0, &worker->create_state);
-> io_worker_release(worker);
-> atomic_dec(&acct->nr_running);
-> io_worker_ref_put(wq);
-> return false;
-> clear_bit_unlock(0, &worker->create_state); // back to io_workqueue_create()
-> io_worker_release(worker);
-> kfree(worker);
The io_worker_release() and clear_bit_unlock() are executed twice.
Fixes:
3146cba99aa2 ("io-wq: make worker creation resilient against signals")
Signed-off-by: Bixuan Cui <cuibixuan@huawei.com>
Link: https://lore.kernel.org/r/20210911085847.34849-1-cuibixuan@huawei.com
Reviwed-by: Hao Xu <haoxu@linux.alibaba.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Sat, 16 Oct 2021 06:21:44 +0000 (08:21 +0200)]
mmc: mxs-mmc: disable regulator on error and in the remove function
[ Upstream commit
ce5f6c2c9b0fcb4094f8e162cfd37fb4294204f7 ]
The 'reg_vmmc' regulator is enabled in the probe. It is never disabled.
Neither in the error handling path of the probe nor in the remove
function.
Register a devm_action to disable it when needed.
Fixes:
4dc5a79f1350 ("mmc: mxs-mmc: enable regulator for mmc slot")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Link: https://lore.kernel.org/r/4aadb3c97835f7b80f00819c3d549e6130384e67.1634365151.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sean Young [Wed, 13 Oct 2021 08:14:10 +0000 (09:14 +0100)]
media: ir_toy: assignment to be16 should be of correct type
[ Upstream commit
febfe985fc2ea052a363f6525ff624b8efd5273c ]
commit
f0c15b360fb6 ("media: ir_toy: prevent device from hanging during
transmit") removed a cpu_to_be16() cast, which causes a sparse warning.
Fixes:
f0c15b360fb6 ("media: ir_toy: prevent device from hanging during transmit")
Reported-by: Hans Verkuil <hverkuil@xs4all.nl>
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>
Randy Dunlap [Sun, 10 Oct 2021 19:38:36 +0000 (20:38 +0100)]
media: ivtv: fix build for UML
[ Upstream commit
6cb67bea945bdf0ad40e633cd2d9fbeb0855675b ]
Prevent the use of page table macros and types from 2 conflicting
places. This fixes multiple build errors and warnings, e.g.:
../arch/x86/include/asm/pgtable_64_types.h:21:34: error: conflicting types for ‘pte_t’
typedef struct { pteval_t pte; } pte_t;
^~~~~
In file included from ../include/linux/mm_types_task.h:16:0,
from ../include/linux/mm_types.h:5,
from ../include/linux/buildid.h:5,
from ../include/linux/module.h:14,
from ../drivers/media/pci/ivtv/ivtv-driver.h:40,
from ../drivers/media/pci/ivtv/ivtvfb.c:29:
../arch/um/include/asm/page.h:57:39: note: previous declaration of ‘pte_t’ was here
typedef struct { unsigned long pte; } pte_t;
../arch/x86/include/asm/pgtable_types.h:284:43: error: expected ‘)’ before ‘prot’
static inline pgprot_t pgprot_nx(pgprot_t prot)
^
../include/linux/pgtable.h:914:26: note: in definition of macro ‘pgprot_nx’
#define pgprot_nx(prot) (prot)
^~~~
In file included from ../arch/x86/include/asm/memtype.h:6:0,
from ../drivers/media/pci/ivtv/ivtvfb.c:40:
../arch/x86/include/asm/pgtable_types.h:288:0: warning: "pgprot_nx" redefined
#define pgprot_nx pgprot_nx
../arch/x86/include/asm/page_types.h:11:0: warning: "PAGE_SIZE" redefined
#define PAGE_SIZE (_AC(1,UL) << PAGE_SHIFT)
In file included from ../include/linux/mm_types_task.h:16:0,
from ../include/linux/mm_types.h:5,
from ../include/linux/buildid.h:5,
from ../include/linux/module.h:14,
from ../drivers/media/pci/ivtv/ivtv-driver.h:40,
from ../drivers/media/pci/ivtv/ivtvfb.c:29:
../arch/um/include/asm/page.h:14:0: note: this is the location of the previous definition
#define PAGE_SIZE (_AC(1, UL) << PAGE_SHIFT)
Fixes:
68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: Andy Walls <awalls@md.metrocast.net>
Cc: linux-um@lists.infradead.org
Cc: Richard Weinberger <richard@nod.at>
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>
jason-jh.lin [Wed, 29 Sep 2021 07:08:07 +0000 (15:08 +0800)]
mailbox: Remove WARN_ON for async_cb.cb in cmdq_exec_done
[ Upstream commit
ce1537fe288469bf68ee0aabdb860a790b4755ef ]
Because mtk_drm_crtc_update_config is not using cmdq_pkt_flush_async,
it won't have pkt->async_cb.cb anymore.
So remove the WARN_ON check of pkt->async_cb.cb at cmdq_exec_done.
Fixes:
1b6b0ce2240e ("mailbox: mtk-cmdq: Use mailbox rx_callback")
Signed-off-by: jason-jh.lin <jason-jh.lin@mediatek.com>
Reviewed-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Tested-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jackie Liu [Sat, 9 Oct 2021 01:58:53 +0000 (09:58 +0800)]
thermal/drivers/qcom/lmh: make QCOM_LMH depends on QCOM_SCM
[ Upstream commit
9e5a4fb8423081d0efbf165c71c7f4abdf5f918c ]
Without QCOM_SCM, build failed, avoid like below:
aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
aarch64-linux-gnu-ld: Unexpected run-time procedure linkages detected!
aarch64-linux-gnu-ld: drivers/thermal/qcom/lmh.o: in function `lmh_probe':
/data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:141: undefined reference to `qcom_scm_lmh_dcvsh_available'
aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:144: undefined reference to `qcom_scm_lmh_dcvsh'
aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:149: undefined reference to `qcom_scm_lmh_dcvsh'
aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:154: undefined reference to `qcom_scm_lmh_dcvsh'
aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:159: undefined reference to `qcom_scm_lmh_dcvsh'
aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:166: undefined reference to `qcom_scm_lmh_profile_change'
aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:173: undefined reference to `qcom_scm_lmh_dcvsh'
aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:180: undefined reference to `qcom_scm_lmh_dcvsh'
aarch64-linux-gnu-ld: /data/arm/workspace/kernel-build/linux/build/../drivers/thermal/qcom/lmh.c:187: undefined reference to `qcom_scm_lmh_dcvsh'
make[1]: *** [/data/arm/workspace/kernel-build/linux/Makefile:1183: vmlinux] Error 1
make[1]: Leaving directory '/data/arm/workspace/kernel-build/linux/build'
make: *** [Makefile:219: __sub-make] Error 2
make: Leaving directory '/data/arm/workspace/kernel-build/linux'
Fixes:
53bca371cdf7 ("thermal/drivers/qcom: Add support for LMh driver")
Signed-off-by: Jackie Liu <liuyun01@kylinos.cn>
Link: https://lore.kernel.org/r/20211009015853.3509559-1-liu.yun@linux.dev
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jakub Kicinski [Fri, 15 Oct 2021 13:37:39 +0000 (06:37 -0700)]
net: stream: don't purge sk_error_queue in sk_stream_kill_queues()
[ Upstream commit
24bcbe1cc69fa52dc4f7b5b2456678ed464724d8 ]
sk_stream_kill_queues() can be called on close when there are
still outstanding skbs to transmit. Those skbs may try to queue
notifications to the error queue (e.g. timestamps).
If sk_stream_kill_queues() purges the queue without taking
its lock the queue may get corrupted, and skbs leaked.
This shows up as a warning about an rmem leak:
WARNING: CPU: 24 PID: 0 at net/ipv4/af_inet.c:154 inet_sock_destruct+0x...
The leak is always a multiple of 0x300 bytes (the value is in
%rax on my builds, so RAX:
0000000000000300). 0x300 is truesize of
an empty sk_buff. Indeed if we dump the socket state at the time
of the warning the sk_error_queue is often (but not always)
corrupted. The ->next pointer points back at the list head,
but not the ->prev pointer. Indeed we can find the leaked skb
by scanning the kernel memory for something that looks like
an skb with ->sk = socket in question, and ->truesize = 0x300.
The contents of ->cb[] of the skb confirms the suspicion that
it is indeed a timestamp notification (as generated in
__skb_complete_tx_timestamp()).
Removing purging of sk_error_queue should be okay, since
inet_sock_destruct() does it again once all socket refs
are gone. Eric suggests this may cause sockets that go
thru disconnect() to maintain notifications from the
previous incarnations of the socket, but that should be
okay since the race was there anyway, and disconnect()
is not exactly dependable.
Thanks to Jonathan Lemon and Omar Sandoval for help at various
stages of tracing the issue.
Fixes:
cb9eff097831 ("net: new user space API for time stamping of incoming and outgoing packets")
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 13 Oct 2021 08:13:15 +0000 (11:13 +0300)]
drm/msm: uninitialized variable in msm_gem_import()
[ Upstream commit
2203bd0e5c12ffc53ffdd4fbd7b12d6ba27e0424 ]
The msm_gem_new_impl() function cleans up after itself so there is no
need to call drm_gem_object_put(). Conceptually, it does not make sense
to call a kref_put() function until after the reference counting has
been initialized which happens immediately after this call in the
drm_gem_(private_)object_init() functions.
In the msm_gem_import() function the "obj" pointer is uninitialized, so
it will lead to a crash.
Fixes:
05b849111c07 ("drm/msm: prime support")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211013081315.GG6010@kili
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 13 Oct 2021 08:11:33 +0000 (11:11 +0300)]
drm/msm: fix potential NULL dereference in cleanup
[ Upstream commit
027d052a36e56789a2134772bacb4fd0860f03a3 ]
The "msm_obj->node" list needs to be initialized earlier so that the
list_del() in msm_gem_free_object() doesn't experience a NULL pointer
dereference.
Fixes:
6ed0897cd800 ("drm/msm: Fix debugfs deadlock")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211013081133.GF6010@kili
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Mon, 11 Oct 2021 12:40:05 +0000 (15:40 +0300)]
drm/msm: unlock on error in get_sched_entity()
[ Upstream commit
7425e8167507fe512d8ac0825acda4aebf0a7ca0 ]
Add a missing unlock on the error path if drm_sched_entity_init() fails.
Fixes:
68002469e571 ("drm/msm: One sched entity per process per priority")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211011124005.GE15188@kili
Signed-off-by: Rob Clark <robdclark@chromium.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Mon, 4 Oct 2021 10:38:06 +0000 (13:38 +0300)]
drm/msm: potential error pointer dereference in init()
[ Upstream commit
b6816441a14bbe356ba8590de79cfea2de6a085c ]
The msm_iommu_new() returns error pointers on failure so check for that
to avoid an Oops.
Fixes:
ccac7ce373c1 ("drm/msm: Refactor address space initialization")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20211004103806.GD25015@kili
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>
Dan Carpenter [Mon, 4 Oct 2021 13:45:30 +0000 (16:45 +0300)]
drm/msm: Fix potential Oops in a6xx_gmu_rpmh_init()
[ Upstream commit
3d91e50ff58364f6572ad268b508175d27800e51 ]
There are two problems here:
1) The "seqptr" is used uninitalized when we free it at the end.
2) The a6xx_gmu_get_mmio() function returns error pointers. It never
returns true.
Fixes:
64245fc55172 ("drm/msm/a6xx: use AOP-initialized PDC for a650")
Fixes:
f8fc924e088e ("drm/msm/a6xx: Fix PDC register overlap")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20211004134530.GB11689@kili
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>
Dmitry Baryshkov [Sat, 2 Oct 2021 01:08:30 +0000 (04:08 +0300)]
drm/msm/dsi: do not enable irq handler before powering up the host
[ Upstream commit
bf94ec093d05e3ed3142d9291b876eeb9997ba5c ]
The DSI host might be left in some state by the bootloader. If this
state generates an IRQ, it might hang the system by holding the
interrupt line before the driver sets up the DSI host to the known
state.
Move the request_irq into msm_dsi_host_init and pass IRQF_NO_AUTOEN to
it. Call enable/disable_irq after msm_dsi_host_power_on/_off()
functions, so that we can be sure that the interrupt is delivered when
the host is in the known state.
It is not possible to defer the interrupt enablement to a later point,
because drm_panel_prepare might need to communicate with the panel over
the DSI link and that requires working interrupt.
Fixes:
a689554ba6ed ("drm/msm: Initial add DSI connector support")
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Abhinav Kumar <abhinavk@codeaurora.org>
Link: https://lore.kernel.org/r/20211002010830.647416-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>
Ziyang Xuan [Fri, 15 Oct 2021 02:45:04 +0000 (10:45 +0800)]
thermal/core: fix a UAF bug in __thermal_cooling_device_register()
[ Upstream commit
0a5c26712f963f0500161a23e0ffff8d29f742ab ]
When device_register() return failed, program will goto out_kfree_type
to release 'cdev->device' by put_device(). That will call thermal_release()
to free 'cdev'. But the follow-up processes access 'cdev' continually.
That trggers the UAF bug.
====================================================================
BUG: KASAN: use-after-free in __thermal_cooling_device_register+0x75b/0xa90
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
dump_stack_lvl+0xe2/0x152
print_address_description.constprop.0+0x21/0x140
? __thermal_cooling_device_register+0x75b/0xa90
kasan_report.cold+0x7f/0x11b
? __thermal_cooling_device_register+0x75b/0xa90
__thermal_cooling_device_register+0x75b/0xa90
? memset+0x20/0x40
? __sanitizer_cov_trace_pc+0x1d/0x50
? __devres_alloc_node+0x130/0x180
devm_thermal_of_cooling_device_register+0x67/0xf0
max6650_probe.cold+0x557/0x6aa
......
Freed by task 258:
kasan_save_stack+0x1b/0x40
kasan_set_track+0x1c/0x30
kasan_set_free_info+0x20/0x30
__kasan_slab_free+0x109/0x140
kfree+0x117/0x4c0
thermal_release+0xa0/0x110
device_release+0xa7/0x240
kobject_put+0x1ce/0x540
put_device+0x20/0x30
__thermal_cooling_device_register+0x731/0xa90
devm_thermal_of_cooling_device_register+0x67/0xf0
max6650_probe.cold+0x557/0x6aa [max6650]
Do not use 'cdev' again after put_device() to fix the problem like doing
in thermal_zone_device_register().
[dlezcano]: as requested by Rafael, change the affectation into two statements.
Fixes:
584837618100 ("thermal/drivers/core: Use a char pointer for the cooling device name")
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20211015024504.947520-1-william.xuanziyang@huawei.com
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ovidiu Panait [Sun, 10 Oct 2021 16:36:42 +0000 (19:36 +0300)]
crypto: octeontx2 - set assoclen in aead_do_fallback()
[ Upstream commit
06f6e365e2ecf799c249bb464aa9d5f055e88b56 ]
Currently, in case of aead fallback, no associated data info is set in the
fallback request. To fix this, call aead_request_set_ad() to pass the assoclen.
Fixes:
6f03f0e8b6c8 ("crypto: octeontx2 - register with linux crypto framework")
Signed-off-by: Ovidiu Panait <ovidiu.panait@windriver.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Dumazet [Thu, 14 Oct 2021 13:41:26 +0000 (06:41 -0700)]
tcp: switch orphan_count to bare per-cpu counters
[ Upstream commit
19757cebf0c5016a1f36f7fe9810a9f0b33c0832 ]
Use of percpu_counter structure to track count of orphaned
sockets is causing problems on modern hosts with 256 cpus
or more.
Stefan Bach reported a serious spinlock contention in real workloads,
that I was able to reproduce with a netfilter rule dropping
incoming FIN packets.
53.56% server [kernel.kallsyms] [k] queued_spin_lock_slowpath
|
---queued_spin_lock_slowpath
|
--53.51%--_raw_spin_lock_irqsave
|
--53.51%--__percpu_counter_sum
tcp_check_oom
|
|--39.03%--__tcp_close
| tcp_close
| inet_release
| inet6_release
| sock_close
| __fput
| ____fput
| task_work_run
| exit_to_usermode_loop
| do_syscall_64
| entry_SYSCALL_64_after_hwframe
| __GI___libc_close
|
--14.48%--tcp_out_of_resources
tcp_write_timeout
tcp_retransmit_timer
tcp_write_timer_handler
tcp_write_timer
call_timer_fn
expire_timers
__run_timers
run_timer_softirq
__softirqentry_text_start
As explained in commit
cf86a086a180 ("net/dst: use a smaller percpu_counter
batch for dst entries accounting"), default batch size is too big
for the default value of tcp_max_orphans (262144).
But even if we reduce batch sizes, there would still be cases
where the estimated count of orphans is beyond the limit,
and where tcp_too_many_orphans() has to call the expensive
percpu_counter_sum_positive().
One solution is to use plain per-cpu counters, and have
a timer to periodically refresh this cache.
Updating this cache every 100ms seems about right, tcp pressure
state is not radically changing over shorter periods.
percpu_counter was nice 15 years ago while hosts had less
than 16 cpus, not anymore by current standards.
v2: Fix the build issue for CONFIG_CRYPTO_DEV_CHELSIO_TLS=m,
reported by kernel test robot <lkp@intel.com>
Remove unused socket argument from tcp_too_many_orphans()
Fixes:
dd24c00191d5 ("net: Use a percpu_counter for orphan_count")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: Stefan Bach <sfb@google.com>
Cc: Neal Cardwell <ncardwell@google.com>
Acked-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Randy Dunlap [Thu, 14 Oct 2021 05:06:06 +0000 (22:06 -0700)]
net: tulip: winbond-840: fix build for UML
[ Upstream commit
a3d708925fcca1a2f7219bc9ce93e6341f85c1e0 ]
On i386, when builtin (not a loadable module), the winbond-840 driver
inspects boot_cpu_data to see what CPU family it is running on, and
then acts on that data. The "family" struct member (x86) does not exist
when running on UML, so prevent that test and do the default action.
Prevents this build error on UML + i386:
../drivers/net/ethernet/dec/tulip/winbond-840.c: In function ‘init_registers’:
../drivers/net/ethernet/dec/tulip/winbond-840.c:882:19: error: ‘struct cpuinfo_um’ has no member named ‘x86’
if (boot_cpu_data.x86 <= 4) {
Fixes:
68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-um@lists.infradead.org
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Link: https://lore.kernel.org/r/20211014050606.7288-1-rdunlap@infradead.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Randy Dunlap [Thu, 14 Oct 2021 05:05:16 +0000 (22:05 -0700)]
net: intel: igc_ptp: fix build for UML
[ Upstream commit
523994ba3ad1b7b55abe4a72e156897b5e2db825 ]
On a UML build, the igc_ptp driver uses CONFIG_X86_TSC for timestamp
conversion. The function that is used is not available on UML builds,
so have the function use the default system_counterval_t timestamp
instead for UML builds.
Prevents this build error on UML:
../drivers/net/ethernet/intel/igc/igc_ptp.c: In function ‘igc_device_tstamp_to_system’:
../drivers/net/ethernet/intel/igc/igc_ptp.c:777:9: error: implicit declaration of function ‘convert_art_ns_to_tsc’ [-Werror=implicit-function-declaration]
return convert_art_ns_to_tsc(tstamp);
../drivers/net/ethernet/intel/igc/igc_ptp.c:777:9: error: incompatible types when returning type ‘int’ but ‘struct system_counterval_t’ was expected
return convert_art_ns_to_tsc(tstamp);
Fixes:
68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-um@lists.infradead.org
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Cc: Jesse Brandeburg <jesse.brandeburg@intel.com>
Cc: Tony Nguyen <anthony.l.nguyen@intel.com>
Cc: intel-wired-lan@lists.osuosl.org
Link: https://lore.kernel.org/r/20211014050516.6846-1-rdunlap@infradead.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Randy Dunlap [Thu, 14 Oct 2021 05:05:00 +0000 (22:05 -0700)]
net: fealnx: fix build for UML
[ Upstream commit
cd2621d07d517473611b170c69beb6524c677740 ]
On i386, when builtin (not a loadable module), the fealnx driver
inspects boot_cpu_data to see what CPU family it is running on, and
then acts on that data. The "family" struct member (x86) does not exist
when running on UML, so prevent that test and do the default action.
Prevents this build error on UML + i386:
../drivers/net/ethernet/fealnx.c: In function ‘netdev_open’:
../drivers/net/ethernet/fealnx.c:861:19: error: ‘struct cpuinfo_um’ has no member named ‘x86’
Fixes:
68f5d3f3b654 ("um: add PCI over virtio emulation driver")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: linux-um@lists.infradead.org
Cc: Jeff Dike <jdike@addtoit.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com>
Link: https://lore.kernel.org/r/20211014050500.5620-1-rdunlap@infradead.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Qiao [Wed, 15 Sep 2021 06:40:30 +0000 (14:40 +0800)]
kernel/sched: Fix sched_fork() access an invalid sched_task_group
[ Upstream commit
4ef0c5c6b5ba1f38f0ea1cedad0cad722f00c14a ]
There is a small race between copy_process() and sched_fork()
where child->sched_task_group point to an already freed pointer.
parent doing fork() | someone moving the parent
| to another cgroup
-------------------------------+-------------------------------
copy_process()
+ dup_task_struct()<1>
parent move to another cgroup,
and free the old cgroup. <2>
+ sched_fork()
+ __set_task_cpu()<3>
+ task_fork_fair()
+ sched_slice()<4>
In the worst case, this bug can lead to "use-after-free" and
cause panic as shown above:
(1) parent copy its sched_task_group to child at <1>;
(2) someone move the parent to another cgroup and free the old
cgroup at <2>;
(3) the sched_task_group and cfs_rq that belong to the old cgroup
will be accessed at <3> and <4>, which cause a panic:
[] BUG: unable to handle kernel NULL pointer dereference at
0000000000000000
[] PGD
8000001fa0a86067 P4D
8000001fa0a86067 PUD
2029955067 PMD 0
[] Oops: 0000 [#1] SMP PTI
[] CPU: 7 PID: 648398 Comm: ebizzy Kdump: loaded Tainted: G OE --------- - - 4.18.0.x86_64+ #1
[] RIP: 0010:sched_slice+0x84/0xc0
[] Call Trace:
[] task_fork_fair+0x81/0x120
[] sched_fork+0x132/0x240
[] copy_process.part.5+0x675/0x20e0
[] ? __handle_mm_fault+0x63f/0x690
[] _do_fork+0xcd/0x3b0
[] do_syscall_64+0x5d/0x1d0
[] entry_SYSCALL_64_after_hwframe+0x65/0xca
[] RIP: 0033:0x7f04418cd7e1
Between cgroup_can_fork() and cgroup_post_fork(), the cgroup
membership and thus sched_task_group can't change. So update child's
sched_task_group at sched_post_fork() and move task_fork() and
__set_task_cpu() (where accees the sched_task_group) from sched_fork()
to sched_post_fork().
Fixes:
8323f26ce342 ("sched: Fix race in task_group")
Signed-off-by: Zhang Qiao <zhangqiao22@huawei.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Tejun Heo <tj@kernel.org>
Link: https://lkml.kernel.org/r/20210915064030.2231-1-zhangqiao22@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sven Eckelmann [Tue, 11 Jun 2019 17:21:31 +0000 (19:21 +0200)]
ath10k: fix max antenna gain unit
[ Upstream commit
0a491167fe0cf9f26062462de2a8688b96125d48 ]
Most of the txpower for the ath10k firmware is stored as twicepower (0.5 dB
steps). This isn't the case for max_antenna_gain - which is still expected
by the firmware as dB.
The firmware is converting it from dB to the internal (twicepower)
representation when it calculates the limits of a channel. This can be seen
in tpc_stats when configuring "12" as max_antenna_gain. Instead of the
expected 12 (6 dB), the tpc_stats shows 24 (12 dB).
Tested on QCA9888 and IPQ4019 with firmware 10.4-3.5.3-00057.
Fixes:
02256930d9b8 ("ath10k: use proper tx power unit")
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20190611172131.6064-1-sven@narfation.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zev Weiss [Tue, 28 Sep 2021 09:22:38 +0000 (02:22 -0700)]
hwmon: (pmbus/lm25066) Let compiler determine outer dimension of lm25066_coeff
[ Upstream commit
b7931a7b0e0df4d2a25fedd895ad32c746b77bc1 ]
Maintaining this manually is error prone (there are currently only
five chips supported, not six); gcc can do it for us automatically.
Signed-off-by: Zev Weiss <zev@bewilderbeest.net>
Fixes:
666c14906b49 ("hwmon: (pmbus/lm25066) Drop support for LM25063")
Link: https://lore.kernel.org/r/20210928092242.30036-5-zev@bewilderbeest.net
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 12 Oct 2021 11:27:58 +0000 (19:27 +0800)]
hwmon: Fix possible memleak in __hwmon_device_register()
[ Upstream commit
ada61aa0b1184a8fda1a89a340c7d6cc4e59aee5 ]
I got memory leak as follows when doing fault injection test:
unreferenced object 0xffff888102740438 (size 8):
comm "27", pid 859, jiffies
4295031351 (age 143.992s)
hex dump (first 8 bytes):
68 77 6d 6f 6e 30 00 00 hwmon0..
backtrace:
[<
00000000544b5996>] __kmalloc_track_caller+0x1a6/0x300
[<
00000000df0d62b9>] kvasprintf+0xad/0x140
[<
00000000d3d2a3da>] kvasprintf_const+0x62/0x190
[<
000000005f8f0f29>] kobject_set_name_vargs+0x56/0x140
[<
00000000b739e4b9>] dev_set_name+0xb0/0xe0
[<
0000000095b69c25>] __hwmon_device_register+0xf19/0x1e50 [hwmon]
[<
00000000a7e65b52>] hwmon_device_register_with_info+0xcb/0x110 [hwmon]
[<
000000006f181e86>] devm_hwmon_device_register_with_info+0x85/0x100 [hwmon]
[<
0000000081bdc567>] tmp421_probe+0x2d2/0x465 [tmp421]
[<
00000000502cc3f8>] i2c_device_probe+0x4e1/0xbb0
[<
00000000f90bda3b>] really_probe+0x285/0xc30
[<
000000007eac7b77>] __driver_probe_device+0x35f/0x4f0
[<
000000004953d43d>] driver_probe_device+0x4f/0x140
[<
000000002ada2d41>] __device_attach_driver+0x24c/0x330
[<
00000000b3977977>] bus_for_each_drv+0x15d/0x1e0
[<
000000005bf2a8e3>] __device_attach+0x267/0x410
When device_register() returns an error, the name allocated in
dev_set_name() will be leaked, the put_device() should be used
instead of calling hwmon_dev_release() to give up the device
reference, then the name will be freed in kobject_cleanup().
Reported-by: Hulk Robot <hulkci@huawei.com>
Fixes:
bab2243ce189 ("hwmon: Introduce hwmon_device_register_with_groups")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20211012112758.2681084-1-yangyingliang@huawei.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Daniel Borkmann [Mon, 11 Oct 2021 12:12:35 +0000 (14:12 +0200)]
net, neigh: Fix NTF_EXT_LEARNED in combination with NTF_USE
[ Upstream commit
e4400bbf5b15750e1b59bf4722d18d99be60c69f ]
The NTF_EXT_LEARNED neigh flag is usually propagated back to user space
upon dump of the neighbor table. However, when used in combination with
NTF_USE flag this is not the case despite exempting the entry from the
garbage collector. This results in inconsistent state since entries are
typically marked in neigh->flags with NTF_EXT_LEARNED, but here they are
not. Fix it by propagating the creation flag to ___neigh_create().
Before fix:
# ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn
# ./ip/ip n
192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a REACHABLE
[...]
After fix:
# ./ip/ip n replace 192.168.178.30 dev enp5s0 use extern_learn
# ./ip/ip n
192.168.178.30 dev enp5s0 lladdr f4:8c:50:5e:71:9a extern_learn REACHABLE
[...]
Fixes:
9ce33e46531d ("neighbour: support for NTF_EXT_LEARNED flag")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Mon, 11 Oct 2021 12:39:12 +0000 (15:39 +0300)]
memstick: jmb38x_ms: use appropriate free function in jmb38x_ms_alloc_host()
[ Upstream commit
beae4a6258e64af609ad5995cc6b6056eb0d898e ]
The "msh" pointer is device managed, meaning that memstick_alloc_host()
calls device_initialize() on it. That means that it can't be free
using kfree() but must instead be freed with memstick_free_host().
Otherwise it leads to a tiny memory leak of device resources.
Fixes:
60fdd931d577 ("memstick: add support for JMicron jmb38x MemoryStick host controller")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Link: https://lore.kernel.org/r/20211011123912.GD15188@kili
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Mon, 27 Sep 2021 09:44:47 +0000 (11:44 +0200)]
memstick: avoid out-of-range warning
[ Upstream commit
4853396f03c3019eccf5cd113e464231e9ddf0b3 ]
clang-14 complains about a sanity check that always passes when the
page size is 64KB or larger:
drivers/memstick/core/ms_block.c:1739:21: error: result of comparison of constant 65536 with expression of type 'unsigned short' is always false [-Werror,-Wtautological-constant-out-of-range-compare]
if (msb->page_size > PAGE_SIZE) {
~~~~~~~~~~~~~~ ^ ~~~~~~~~~
This is fine, it will still work on all architectures, so just shut
up that warning with a cast.
Fixes:
0ab30494bc4f ("memstick: add support for legacy memorysticks")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20210927094520.696665-1-arnd@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Tue, 21 Sep 2021 11:00:26 +0000 (14:00 +0300)]
mmc: sdhci-omap: Fix context restore
[ Upstream commit
d806e334d0390502cd2a820ad33d65d7f9bba618 ]
We need to restore context in a specified order with HCTL set in two
phases. This is similar to what omap_hsmmc_context_restore() is doing.
Otherwise SDIO can stop working on resume.
And for PM runtime and SDIO cards, we need to also save SYSCTL, IE and
ISE.
This should not be a problem currently, and these patches can be applied
whenever suitable.
Fixes:
ee0f309263a6 ("mmc: sdhci-omap: Add Support for Suspend/Resume")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20210921110029.21944-3-tony@atomide.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tony Lindgren [Tue, 21 Sep 2021 11:00:25 +0000 (14:00 +0300)]
mmc: sdhci-omap: Fix NULL pointer exception if regulator is not configured
[ Upstream commit
8e0e7bd38b1ec7f9e5d18725ad41828be4e09859 ]
If sdhci-omap is configured for an unused device instance and the device
is not set as disabled, we can get a NULL pointer dereference:
Unable to handle kernel NULL pointer dereference at virtual address
00000045
...
(regulator_set_voltage) from [<
c07d7008>] (mmc_regulator_set_ocr+0x44/0xd0)
(mmc_regulator_set_ocr) from [<
c07e2d80>] (sdhci_set_ios+0xa4/0x490)
(sdhci_set_ios) from [<
c07ea690>] (sdhci_omap_set_ios+0x124/0x160)
(sdhci_omap_set_ios) from [<
c07c8e94>] (mmc_power_up.part.0+0x3c/0x154)
(mmc_power_up.part.0) from [<
c07c9d20>] (mmc_start_host+0x88/0x9c)
(mmc_start_host) from [<
c07cad34>] (mmc_add_host+0x58/0x7c)
(mmc_add_host) from [<
c07e2574>] (__sdhci_add_host+0xf0/0x22c)
(__sdhci_add_host) from [<
c07eaf68>] (sdhci_omap_probe+0x318/0x72c)
(sdhci_omap_probe) from [<
c06a39d8>] (platform_probe+0x58/0xb8)
AFAIK we are not seeing this with the devices configured in the mainline
kernel but this can cause issues for folks bringing up their boards.
Fixes:
7d326930d352 ("mmc: sdhci-omap: Add OMAP SDHCI driver")
Signed-off-by: Tony Lindgren <tony@atomide.com>
Link: https://lore.kernel.org/r/20210921110029.21944-2-tony@atomide.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Catherine Sullivan [Mon, 11 Oct 2021 15:36:50 +0000 (08:36 -0700)]
gve: Track RX buffer allocation failures
[ Upstream commit
1b4d1c9bab091ac6e20a3ff80c30c5cefe192bf4 ]
The rx_buf_alloc_fail counter wasn't getting updated.
Fixes:
433e274b8f7b0 ("gve: Add stats for gve.")
Signed-off-by: Catherine Sullivan <csully@google.com>
Signed-off-by: Jeroen de Borst <jeroendb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
John Fraker [Mon, 11 Oct 2021 15:36:47 +0000 (08:36 -0700)]
gve: Recover from queue stall due to missed IRQ
[ Upstream commit
87a7f321bb6a45e54b7d6c90d032ee5636a6ad97 ]
Don't always reset the driver on a TX timeout. Attempt to
recover by kicking the queue in case an IRQ was missed.
Fixes:
9e5f7d26a4c08 ("gve: Add workqueue and reset support")
Signed-off-by: John Fraker <jfraker@google.com>
Signed-off-by: David Awogbemila <awogbemila@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 6 Oct 2021 07:36:22 +0000 (10:36 +0300)]
b43: fix a lower bounds test
[ Upstream commit
9b793db5fca44d01f72d3564a168171acf7c4076 ]
The problem is that "channel" is an unsigned int, when it's less 5 the
value of "channel - 5" is not a negative number as one would expect but
is very high positive value instead.
This means that "start" becomes a very high positive value. The result
of that is that we never enter the "for (i = start; i <= end; i++) {"
loop. Instead of storing the result from b43legacy_radio_aci_detect()
it just uses zero.
Fixes:
ef1a628d83fc ("b43: Implement dynamic PHY API")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Michael Büsch <m@bues.ch>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211006073621.GE8404@kili
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 6 Oct 2021 07:35:42 +0000 (10:35 +0300)]
b43legacy: fix a lower bounds test
[ Upstream commit
c1c8380b0320ab757e60ed90efc8b1992a943256 ]
The problem is that "channel" is an unsigned int, when it's less 5 the
value of "channel - 5" is not a negative number as one would expect but
is very high positive value instead.
This means that "start" becomes a very high positive value. The result
of that is that we never enter the "for (i = start; i <= end; i++) {"
loop. Instead of storing the result from b43legacy_radio_aci_detect()
it just uses zero.
Fixes:
75388acd0cd8 ("[B43LEGACY]: add mac80211-based driver for legacy BCM43xx devices")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Michael Büsch <m@bues.ch>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20211006073542.GD8404@kili
Signed-off-by: Sasha Levin <sashal@kernel.org>
liqiong [Sat, 9 Oct 2021 10:38:21 +0000 (18:38 +0800)]
ima: fix deadlock when traversing "ima_default_rules".
[ Upstream commit
eb0782bbdfd0d7c4786216659277c3fd585afc0e ]
The current IMA ruleset is identified by the variable "ima_rules"
that default to "&ima_default_rules". When loading a custom policy
for the first time, the variable is updated to "&ima_policy_rules"
instead. That update isn't RCU-safe, and deadlocks are possible.
Indeed, some functions like ima_match_policy() may loop indefinitely
when traversing "ima_default_rules" with list_for_each_entry_rcu().
When iterating over the default ruleset back to head, if the list
head is "ima_default_rules", and "ima_rules" have been updated to
"&ima_policy_rules", the loop condition (&entry->list != ima_rules)
stays always true, traversing won't terminate, causing a soft lockup
and RCU stalls.
Introduce a temporary value for "ima_rules" when iterating over
the ruleset to avoid the deadlocks.
Signed-off-by: liqiong <liqiong@nfschina.com>
Reviewed-by: THOBY Simon <Simon.THOBY@viveris.fr>
Fixes:
38d859f991f3 ("IMA: policy can now be updated multiple times")
Reported-by: kernel test robot <lkp@intel.com> (Fix sparse: incompatible types in comparison expression.)
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Markus Schneider-Pargmann [Thu, 30 Sep 2021 19:12:42 +0000 (21:12 +0200)]
hwrng: mtk - Force runtime pm ops for sleep ops
[ Upstream commit
b6f5f0c8f72d348b2d07b20d7b680ef13a7ffe98 ]
Currently mtk_rng_runtime_suspend/resume is called for both runtime pm
and system sleep operations.
This is wrong as these should only be runtime ops as the name already
suggests. Currently freezing the system will lead to a call to
mtk_rng_runtime_suspend even if the device currently isn't active. This
leads to a clock warning because it is disabled/unprepared although it
isn't enabled/prepared currently.
This patch fixes this by only setting the runtime pm ops and forces to
call the runtime pm ops from the system sleep ops as well if active but
not otherwise.
Fixes:
81d2b34508c6 ("hwrng: mtk - add runtime PM support")
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Giovanni Cabiddu [Tue, 28 Sep 2021 11:44:30 +0000 (12:44 +0100)]
crypto: qat - disregard spurious PFVF interrupts
[ Upstream commit
18fcba469ba5359c1de7e3fb16f7b9e8cd1b8e02 ]
Upon receiving a PFVF message, check if the interrupt bit is set in the
message. If it is not, that means that the interrupt was probably
triggered by a collision. In this case, disregard the message and
re-enable the interrupts.
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>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Giovanni Cabiddu [Tue, 28 Sep 2021 11:44:29 +0000 (12:44 +0100)]
crypto: qat - detect PFVF collision after ACK
[ Upstream commit
9b768e8a3909ac1ab39ed44a3933716da7761a6f ]
Detect a PFVF collision between the local and the remote function by
checking if the message on the PFVF CSR has been overwritten.
This is done after the remote function confirms that the message has
been received, by clearing the interrupt bit, or the maximum number of
attempts (ADF_IOV_MSG_ACK_MAX_RETRY) to check the CSR has been exceeded.
Fixes:
ed8ccaef52fa ("crypto: qat - Add support for SRIOV")
Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com>
Co-developed-by: Marco Chiappero <marco.chiappero@intel.com>
Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Mon, 27 Sep 2021 12:18:03 +0000 (14:18 +0200)]
crypto: ccree - avoid out-of-range warnings from clang
[ Upstream commit
cfd6fb45cfaf46fa9547421d8da387dc9c7997d4 ]
clang points out inconsistencies in the FIELD_PREP() invocation in
this driver that result from the 'mask' being a 32-bit value:
drivers/crypto/ccree/cc_driver.c:117:18: error: result of comparison of constant
18446744073709551615 with expression of type 'u32' (aka 'unsigned int') is always false [-Werror,-Wtautological-constant-out-of-range-compare]
cache_params |= FIELD_PREP(mask, val);
^~~~~~~~~~~~~~~~~~~~~
include/linux/bitfield.h:94:3: note: expanded from macro 'FIELD_PREP'
__BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include/linux/bitfield.h:52:28: note: expanded from macro '__BF_FIELD_CHECK'
BUILD_BUG_ON_MSG((_mask) > (typeof(_reg))~0ull, \
~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This does not happen in other places that just pass a constant here.
Work around the warnings by widening the type of the temporary variable.
Fixes:
05c2a705917b ("crypto: ccree - rework cache parameters handling")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Gilad ben-Yossef <gilad@benyossef.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Evgeny Novikov [Sun, 22 Aug 2021 09:48:03 +0000 (11:48 +0200)]
media: dvb-frontends: mn88443x: Handle errors of clk_prepare_enable()
[ Upstream commit
69a10678e2fba3d182e78ea041f2d1b1a6058764 ]
mn88443x_cmn_power_on() did not handle possible errors of
clk_prepare_enable() and always finished successfully so that its caller
mn88443x_probe() did not care about failed preparing/enabling of clocks
as well.
Add missed error handling in both mn88443x_cmn_power_on() and
mn88443x_probe(). This required to change the return value of the former
from "void" to "int".
Found by Linux Driver Verification project (linuxtesting.org).
Fixes:
0f408ce8941f ("media: dvb-frontends: add Socionext MN88443x ISDB-S/T demodulator driver")
Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
Co-developed-by: Kirill Shilimanov <kirill.shilimanov@huawei.com>
Signed-off-by: Kirill Shilimanov <kirill.shilimanov@huawei.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>
Mansur Alisha Shaik [Tue, 14 Sep 2021 03:57:07 +0000 (05:57 +0200)]
media: venus: fix vpp frequency calculation for decoder
[ Upstream commit
1444232152ea33f5ae41fc14bade3e74d642b634 ]
In existing video driver implementation vpp frequency calculation in
calculate_inst_freq() is always zero because the value of vpp_freq_per_mb
is always zero for decoder.
Fixed this by correcting the calculating the vpp frequency calculation for
decoder.
Fixes:
3cfe5815ce0e ("media: venus: Enable low power setting for encoder")
Signed-off-by: Mansur Alisha Shaik <mansur@codeaurora.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>
Pablo Neira Ayuso [Sat, 25 Sep 2021 20:40:26 +0000 (22:40 +0200)]
netfilter: nft_dynset: relax superfluous check on set updates
[ Upstream commit
7b1394892de8d95748d05e3ee41e85edb4abbfa1 ]
Relax this condition to make add and update commands idempotent for sets
with no timeout. The eval function already checks if the set element
timeout is available and updates it if the update command is used.
Fixes:
22fe54d5fefc ("netfilter: nf_tables: add support for dynamic set updates")
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Zijlstra [Tue, 28 Sep 2021 08:40:22 +0000 (10:40 +0200)]
rcu: Fix rcu_dynticks_curr_cpu_in_eqs() vs noinstr
[ Upstream commit
74aece72f95f399dd29363669dc32a1344c8fab4 ]
vmlinux.o: warning: objtool: rcu_nmi_enter()+0x36: call to __kasan_check_read() leaves .noinstr.text section
noinstr cannot have atomic_*() functions in because they're explicitly
annotated, use arch_atomic_*().
Fixes:
2be57f732889 ("rcu: Weaken ->dynticks accesses and updates")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Peter Zijlstra [Tue, 28 Sep 2021 08:40:21 +0000 (10:40 +0200)]
rcu: Always inline rcu_dynticks_task*_{enter,exit}()
[ Upstream commit
7663ad9a5dbcc27f3090e6bfd192c7e59222709f ]
RCU managed to grow a few noinstr violations:
vmlinux.o: warning: objtool: rcu_dynticks_eqs_enter()+0x0: call to rcu_dynticks_task_trace_enter() leaves .noinstr.text section
vmlinux.o: warning: objtool: rcu_dynticks_eqs_exit()+0xe: call to rcu_dynticks_task_trace_exit() leaves .noinstr.text section
Fix them by adding __always_inline to the relevant trivial functions.
Also replace the noinstr with __always_inline for the existing
rcu_dynticks_task_*() functions since noinstr would force noinline
them, even when empty, which seems silly.
Fixes:
7d0c9c50c5a1 ("rcu-tasks: Avoid IPIing userspace/idle tasks if kernel is so built")
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yazen Ghannam [Tue, 5 Oct 2021 15:44:19 +0000 (15:44 +0000)]
EDAC/amd64: Handle three rank interleaving mode
[ Upstream commit
9f4873fb6af7966de8fcbd95c36b61351c1c4b1f ]
AMD Rome systems and later support interleaving between three identical
ranks within a channel.
Check for this mode by counting the number of enabled chip selects and
comparing their masks. If there are exactly three enabled chip selects
and their masks are identical, then three rank interleaving is enabled.
The size of a rank is determined from its mask value. However, three
rank interleaving doesn't follow the method of swapping an interleave
bit with the most significant bit. Rather, the interleave bit is flipped
and the most significant bit remains the same. There is only a single
interleave bit in this case.
Account for this when determining the chip select size by keeping the
most significant bit at its original value and ignoring any zero bits.
This will return a full bitmask in [MSB:1].
Fixes:
e53a3b267fb0 ("EDAC/amd64: Find Chip Select memory size using Address Mask")
Signed-off-by: Yazen Ghannam <yazen.ghannam@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20211005154419.2060504-1-yazen.ghannam@amd.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Borislav Petkov [Wed, 29 Sep 2021 14:37:53 +0000 (16:37 +0200)]
x86/insn: Use get_unaligned() instead of memcpy()
[ Upstream commit
f96b4675839b66168f5a07bf964dde6c2f1c4885 ]
Use get_unaligned() instead of memcpy() to access potentially unaligned
memory, which, when accessed through a pointer, leads to undefined
behavior. get_unaligned() describes much better what is happening there
anyway even if memcpy() does the job.
In addition, since perf tool builds with -Werror, it would fire with:
util/intel-pt-decoder/../../../arch/x86/lib/insn.c: In function '__insn_get_emulate_prefix':
tools/include/../include/asm-generic/unaligned.h:10:15: error: packed attribute is unnecessary [-Werror=packed]
10 | const struct { type x; } __packed *__pptr = (typeof(__pptr))(ptr); \
because -Werror=packed would complain if the packed attribute would have
no effect on the layout of the structure.
In this case, that is intentional so disable the warning only for that
compilation unit.
That part is Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
No functional changes.
Fixes:
5ba1071f7554 ("x86/insn, tools/x86: Fix undefined behavior due to potential unaligned accesses")
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
Link: https://lkml.kernel.org/r/YVSsIkj9Z29TyUjE@zn.tnic
Signed-off-by: Sasha Levin <sashal@kernel.org>