Bernard Metzler [Mon, 7 Nov 2022 14:50:57 +0000 (15:50 +0100)]
RDMA/siw: Fix immediate work request flush to completion queue
[ Upstream commit
bdf1da5df9da680589a7f74448dd0a94dd3e1446 ]
Correctly set send queue element opcode during immediate work request
flushing in post sendqueue operation, if the QP is in ERROR state.
An undefined ocode value results in out-of-bounds access to an array
for mapping the opcode between siw internal and RDMA core representation
in work completion generation. It resulted in a KASAN BUG report
of type 'global-out-of-bounds' during NFSoRDMA testing.
This patch further fixes a potential case of a malicious user which may
write undefined values for completion queue elements status or opcode,
if the CQ is memory mapped to user land. It avoids the same out-of-bounds
access to arrays for status and opcode mapping as described above.
Fixes:
303ae1cdfdf7 ("rdma/siw: application interface")
Fixes:
b0fff7317bb4 ("rdma/siw: completion queue methods")
Reported-by: Olga Kornievskaia <kolga@netapp.com>
Reviewed-by: Tom Talpey <tom@talpey.com>
Signed-off-by: Bernard Metzler <bmt@zurich.ibm.com>
Link: https://lore.kernel.org/r/20221107145057.895747-1-bmt@zurich.ibm.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bart Van Assche [Mon, 31 Oct 2022 22:48:18 +0000 (15:48 -0700)]
scsi: qla2xxx: Fix set-but-not-used variable warnings
[ Upstream commit
4fb2169d66b837a2986f569f5d5b81f79e6e4a4c ]
Fix the following two compiler warnings:
drivers/scsi/qla2xxx/qla_init.c: In function ‘qla24xx_async_abort_cmd’:
drivers/scsi/qla2xxx/qla_init.c:171:17: warning: variable ‘bail’ set but not used [-Wunused-but-set-variable]
171 | uint8_t bail;
| ^~~~
drivers/scsi/qla2xxx/qla_init.c: In function ‘qla2x00_async_tm_cmd’:
drivers/scsi/qla2xxx/qla_init.c:2023:17: warning: variable ‘bail’ set but not used [-Wunused-but-set-variable]
2023 | uint8_t bail;
| ^~~~
Cc: Arun Easi <arun.easi@qlogic.com>
Cc: Giridhar Malavali <giridhar.malavali@qlogic.com>
Fixes:
feafb7b1714c ("[SCSI] qla2xxx: Fix vport delete issues")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20221031224818.2607882-1-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Shiraz Saleem [Fri, 4 Nov 2022 23:49:57 +0000 (18:49 -0500)]
RDMA/irdma: Report the correct link speed
[ Upstream commit
4eace75e0853273755b878ffa9cce6de84df975a ]
The active link speed is currently hard-coded in irdma_query_port due
to which the port rate in ibstatus does reflect the active link speed.
Call ib_get_eth_speed in irdma_query_port to get the active link speed.
Fixes:
b48c24c2d710 ("RDMA/irdma: Implement device supported verb APIs")
Reported-by: Kamal Heib <kamalheib1@gmail.com>
Signed-off-by: Shiraz Saleem <shiraz.saleem@intel.com>
Link: https://lore.kernel.org/r/20221104234957.1135-1-shiraz.saleem@intel.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chao Yu [Fri, 28 Oct 2022 09:30:26 +0000 (17:30 +0800)]
f2fs: fix to destroy sbi->post_read_wq in error path of f2fs_fill_super()
[ Upstream commit
7b02b2201893a71b881026cf574902019ab00db5 ]
In error path of f2fs_fill_super(), this patch fixes to call
f2fs_destroy_post_read_wq() once if we fail in f2fs_start_ckpt_thread().
Fixes:
261eeb9c1585 ("f2fs: introduce checkpoint_merge mount option")
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dongdong Zhang [Tue, 25 Oct 2022 09:40:36 +0000 (17:40 +0800)]
f2fs: fix normal discard process
[ Upstream commit
b5f1a218ae5e4339130d6e733f0e63d623e09a2c ]
In the DPOLICY_BG mode, there is a conflict between
the two conditions "i + 1 < dpolicy->granularity" and
"i < DEFAULT_DISCARD_GRANULARITY". If i = 15, the first
condition is false, it will enter the second condition
and dispatch all small granularity discards in function
__issue_discard_cmd_orderly. The restrictive effect
of the first condition to small discards will be
invalidated. These two conditions should align.
Fixes:
20ee4382322c ("f2fs: issue small discard by LBA order")
Signed-off-by: Dongdong Zhang <zhangdongdong1@oppo.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chao Yu [Fri, 21 Oct 2022 02:34:22 +0000 (10:34 +0800)]
f2fs: fix to invalidate dcc->f2fs_issue_discard in error path
[ Upstream commit
91586ce0d39a05f88795aa8814fb99b1387236b3 ]
Syzbot reports a NULL pointer dereference issue as below:
__refcount_add include/linux/refcount.h:193 [inline]
__refcount_inc include/linux/refcount.h:250 [inline]
refcount_inc include/linux/refcount.h:267 [inline]
get_task_struct include/linux/sched/task.h:110 [inline]
kthread_stop+0x34/0x1c0 kernel/kthread.c:703
f2fs_stop_discard_thread+0x3c/0x5c fs/f2fs/segment.c:1638
kill_f2fs_super+0x5c/0x194 fs/f2fs/super.c:4522
deactivate_locked_super+0x70/0xe8 fs/super.c:332
deactivate_super+0xd0/0xd4 fs/super.c:363
cleanup_mnt+0x1f8/0x234 fs/namespace.c:1186
__cleanup_mnt+0x20/0x30 fs/namespace.c:1193
task_work_run+0xc4/0x14c kernel/task_work.c:177
exit_task_work include/linux/task_work.h:38 [inline]
do_exit+0x26c/0xbe0 kernel/exit.c:795
do_group_exit+0x60/0xe8 kernel/exit.c:925
__do_sys_exit_group kernel/exit.c:936 [inline]
__se_sys_exit_group kernel/exit.c:934 [inline]
__wake_up_parent+0x0/0x40 kernel/exit.c:934
__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]
invoke_syscall arch/arm64/kernel/syscall.c:52 [inline]
el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142
do_el0_svc+0x48/0x164 arch/arm64/kernel/syscall.c:206
el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:636
el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:654
el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581
The root cause of this issue is in error path of f2fs_start_discard_thread(),
it missed to invalidate dcc->f2fs_issue_discard, later kthread_stop() may
access invalid pointer.
Fixes:
4d67490498ac ("f2fs: Don't create discard thread when device doesn't support realtime discard")
Reported-by: syzbot+035a381ea1afb63f098d@syzkaller.appspotmail.com
Reported-by: syzbot+729c925c2d9fc495ddee@syzkaller.appspotmail.com
Signed-off-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiu Jianfeng [Fri, 28 Oct 2022 12:33:20 +0000 (20:33 +0800)]
apparmor: Fix memleak in alloc_ns()
[ Upstream commit
e9e6fa49dbab6d84c676666f3fe7d360497fd65b ]
After changes in commit
a1bd627b46d1 ("apparmor: share profile name on
replacement"), the hname member of struct aa_policy is not valid slab
object, but a subset of that, it can not be freed by kfree_sensitive(),
use aa_policy_destroy() to fix it.
Fixes:
a1bd627b46d1 ("apparmor: share profile name on replacement")
Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Corentin Labbe [Tue, 27 Sep 2022 07:54:48 +0000 (07:54 +0000)]
crypto: rockchip - rework by using crypto_engine
[ Upstream commit
57d67c6e8219b2a034c16d6149e30fb40fd39935 ]
Instead of doing manual queue management, let's use the crypto/engine
for that.
In the same time, rework the requests handling to be easier to
understand (and fix all bugs related to them).
Fixes:
ce0183cb6464b ("crypto: rockchip - switch to skcipher API")
Reviewed-by: John Keeping <john@metanate.com>
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Corentin Labbe [Tue, 27 Sep 2022 07:54:47 +0000 (07:54 +0000)]
crypto: rockchip - remove non-aligned handling
[ Upstream commit
bb3c7b73363c9a149b12b74c44ae94b73a8fddf8 ]
Now driver have fallback for un-aligned cases, remove all code handling
those cases.
Fixes:
ce0183cb6464b ("crypto: rockchip - switch to skcipher API")
Reviewed-by: John Keeping <john@metanate.com>
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Corentin Labbe [Tue, 27 Sep 2022 07:54:46 +0000 (07:54 +0000)]
crypto: rockchip - better handle cipher key
[ Upstream commit
d6b23ccef82816050c2fd458c9dabfa0e0af09b9 ]
The key should not be set in hardware too much in advance, this will
fail it 2 TFM with different keys generate alternative requests.
The key should be stored and used just before doing cipher operations.
Fixes:
ce0183cb6464b ("crypto: rockchip - switch to skcipher API")
Reviewed-by: John Keeping <john@metanate.com>
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Corentin Labbe [Tue, 27 Sep 2022 07:54:45 +0000 (07:54 +0000)]
crypto: rockchip - add fallback for ahash
[ Upstream commit
816600485cb597b3ff7d6806a95a78512839f775 ]
Adds a fallback for all case hardware cannot handle.
Fixes:
ce0183cb6464b ("crypto: rockchip - switch to skcipher API")
Reviewed-by: John Keeping <john@metanate.com>
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Corentin Labbe [Tue, 27 Sep 2022 07:54:44 +0000 (07:54 +0000)]
crypto: rockchip - add fallback for cipher
[ Upstream commit
68ef8af09a1a912a5ed2cfaa4cca7606f52cef90 ]
The hardware does not handle 0 size length request, let's add a
fallback.
Furthermore fallback will be used for all unaligned case the hardware
cannot handle.
Fixes:
ce0183cb6464b ("crypto: rockchip - switch to skcipher API")
Reviewed-by: John Keeping <john@metanate.com>
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Corentin Labbe [Tue, 27 Sep 2022 07:54:43 +0000 (07:54 +0000)]
crypto: rockchip - do not store mode globally
[ Upstream commit
87e356c4966444866186f68f05832fdcc0f351a3 ]
Storing the mode globally does not work if 2 requests are handled in the
same time.
We should store it in a request context.
Fixes:
ce0183cb6464b ("crypto: rockchip - switch to skcipher API")
Reviewed-by: John Keeping <john@metanate.com>
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Corentin Labbe [Tue, 27 Sep 2022 07:54:41 +0000 (07:54 +0000)]
crypto: rockchip - do not do custom power management
[ Upstream commit
c50ef1411c8cbad0c7db100c477126076b6e3348 ]
The clock enable/disable at tfm init/exit is fragile,
if 2 tfm are init in the same time and one is removed just after,
it will leave the hardware uncloked even if a user remains.
Instead simply enable clocks at probe time.
We will do PM later.
Fixes:
ce0183cb6464b ("crypto: rockchip - switch to skcipher API")
Reviewed-by: John Keeping <john@metanate.com>
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Qilong [Tue, 18 Oct 2022 02:45:32 +0000 (10:45 +0800)]
f2fs: Fix the race condition of resize flag between resizefs
[ Upstream commit
28fc4e9077ce59ab28c89c20dc6be5154473218f ]
Because the set/clear SBI_IS_RESIZEFS flag not between any locks,
In the following case:
thread1 thread2
->ioctl(resizefs)
->set RESIZEFS flag ->ioctl(resizefs)
... ->set RESIZEFS flag
->clear RESIZEFS flag
->resizefs stream
# No RESIZEFS flag in the stream
Also before freeze_super, the resizefs not started, we should not set
the SBI_IS_RESIZEFS flag.
So move the set/clear SBI_IS_RESIZEFS flag between the cp_mutex and
gc_lock.
Fixes:
b4b10061ef98 ("f2fs: refactor resize_fs to avoid meta updates in progress")
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Zhang Qilong <zhangqilong3@huawei.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kunihiko Hayashi [Thu, 25 Aug 2022 09:01:01 +0000 (18:01 +0900)]
PCI: pci-epf-test: Register notifier if only core_init_notifier is enabled
[ Upstream commit
6acd25cc98ce0c9ee4fefdaf44fc8bca534b26e5 ]
The pci_epf_test_notifier function should be installed also if only
core_init_notifier is enabled. Fix the current logic.
Link: https://lore.kernel.org/r/20220825090101.20474-1-hayashi.kunihiko@socionext.com
Fixes:
5e50ee27d4a5 ("PCI: pci-epf-test: Add support to defer core initialization")
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Acked-by: Om Prakash Singh <omp@nvidia.com>
Acked-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Leon Romanovsky [Tue, 25 Oct 2022 07:37:13 +0000 (10:37 +0300)]
RDMA/core: Fix order of nldev_exit call
[ Upstream commit
4508d32ccced24c972bc4592104513e1ff8439b5 ]
Create symmetrical exit flow by calling to nldev_exit() after
call to rdma_nl_unregister(RDMA_NL_LS).
Fixes:
6c80b41abe22 ("RDMA/netlink: Add nldev initialization flows")
Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
Link: https://lore.kernel.org/r/64e676774a53a406f4cde265d5a4cfd6b8e97df9.1666683334.git.leonro@nvidia.com
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vidya Sagar [Mon, 26 Sep 2022 11:19:23 +0000 (16:49 +0530)]
PCI: dwc: Fix n_fts[] array overrun
[ Upstream commit
66110361281b2f7da0c8bd51eaf1f152f4236035 ]
commit
aeaa0bfe89654 ("PCI: dwc: Move N_FTS setup to common setup")
incorrectly uses pci->link_gen in deriving the index to the
n_fts[] array also introducing the issue of accessing beyond the
boundaries of array for greater than Gen-2 speeds. This change fixes
that issue.
Link: https://lore.kernel.org/r/20220926111923.22487-1-vidyas@nvidia.com
Fixes:
aeaa0bfe8965 ("PCI: dwc: Move N_FTS setup to common setup")
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
Signed-off-by: Lorenzo Pieralisi <lpieralisi@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Jingoo Han <jingoohan1@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiu Jianfeng [Fri, 21 Oct 2022 00:46:04 +0000 (08:46 +0800)]
apparmor: Use pointer to struct aa_label for lbs_cred
[ Upstream commit
37923d4321b1e38170086da2c117f78f2b0f49c6 ]
According to the implementations of cred_label() and set_cred_label(),
we should use pointer to struct aa_label for lbs_cred instead of struct
aa_task_ctx, this patch fixes it.
Fixes:
bbd3662a8348 ("Infrastructure management of the cred security blob")
Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bart Van Assche [Tue, 18 Oct 2022 20:29:49 +0000 (13:29 -0700)]
scsi: core: Fix a race between scsi_done() and scsi_timeout()
[ Upstream commit
978b7922d3dca672b41bb4b8ce6c06ab77112741 ]
If there is a race between scsi_done() and scsi_timeout() and if
scsi_timeout() loses the race, scsi_timeout() should not reset the request
timer. Hence change the return value for this case from BLK_EH_RESET_TIMER
into BLK_EH_DONE.
Although the block layer holds a reference on a request (req->ref) while
calling a timeout handler, restarting the timer (blk_add_timer()) while a
request is being completed is racy.
Reviewed-by: Mike Christie <michael.christie@oracle.com>
Cc: Keith Busch <kbusch@kernel.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ming Lei <ming.lei@redhat.com>
Cc: John Garry <john.garry@huawei.com>
Cc: Hannes Reinecke <hare@suse.de>
Reported-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes:
15f73f5b3e59 ("blk-mq: move failure injection out of blk_mq_complete_request")
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Link: https://lore.kernel.org/r/20221018202958.1902564-2-bvanassche@acm.org
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Natalia Petrova [Wed, 28 Sep 2022 10:25:05 +0000 (13:25 +0300)]
crypto: nitrox - avoid double free on error path in nitrox_sriov_init()
[ Upstream commit
094528b6a5a755b1195a01e10b13597d67d1a0e6 ]
If alloc_workqueue() fails in nitrox_mbox_init() it deallocates
ndev->iov.vfdev and returns error code, but then nitrox_sriov_init()
calls nitrox_sriov_cleanup() where ndev->iov.vfdev is deallocated
again.
Fix this by nulling ndev->iov.vfdev after the first deallocation.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes:
9e5de3e06e54 ("crypto: cavium/nitrox - Add mailbox...")
Signed-off-by: Natalia Petrova <n.petrova@fintech.ru>
Signed-off-by: Alexey Khoroshilov <khoroshilov@ispras.ru>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Corentin Labbe [Tue, 27 Sep 2022 08:55:55 +0000 (08:55 +0000)]
crypto: sun8i-ss - use dma_addr instead u32
[ Upstream commit
839b8ae2fc10f205317bcc32c9de18456756e1f5 ]
The DMA address need to be stored in a dma_addr_t
Fixes:
359e893e8af4 ("crypto: sun8i-ss - rework handling of IV")
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Weili Qian [Sat, 13 Aug 2022 10:34:52 +0000 (18:34 +0800)]
crypto: hisilicon/qm - fix missing destroy qp_idr
[ Upstream commit
116be08f6e4e385733d42360a33c3d883d2dd702 ]
In the function hisi_qm_memory_init(), if resource alloc fails after
idr_init, the initialized qp_idr needs to be destroyed.
Signed-off-by: Weili Qian <qianweili@huawei.com>
Signed-off-by: Yang Shen <shenyang39@huawei.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Sasha Levin <sashal@kernel.org>
John Johansen [Sat, 7 May 2022 01:57:12 +0000 (18:57 -0700)]
apparmor: Fix abi check to include v8 abi
[ Upstream commit
1b5a6198f5a9d0aa5497da0dc4bcd4fc166ee516 ]
The v8 abi is supported by the kernel but the userspace supported
version check does not allow for it. This was missed when v8 was added
due to a bug in the userspace compiler which was setting an older abi
version for v8 encoding (which is forward compatible except on the
network encoding). However it is possible to detect the network
encoding by checking the policydb network support which the code
does. The end result was that missing the abi flag worked until
userspace was fixed and began correctly checking for the v8 abi
version.
Fixes:
56974a6fcfef ("apparmor: add base infastructure for socket mediation")
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
John Johansen [Tue, 6 Sep 2022 10:39:55 +0000 (03:39 -0700)]
apparmor: fix lockdep warning when removing a namespace
[ Upstream commit
9c4557efc558a68e4cd973490fd936d6e3414db8 ]
Fix the following lockdep warning
[ 1119.158984] ============================================
[ 1119.158988] WARNING: possible recursive locking detected
[ 1119.158996] 6.0.0-rc1+ #257 Tainted: G E N
[ 1119.158999] --------------------------------------------
[ 1119.159001] bash/80100 is trying to acquire lock:
[ 1119.159007]
ffff88803e79b4a0 (&ns->lock/1){+.+.}-{4:4}, at: destroy_ns.part.0+0x43/0x140
[ 1119.159028]
but task is already holding lock:
[ 1119.159030]
ffff8881009764a0 (&ns->lock/1){+.+.}-{4:4}, at: aa_remove_profiles+0x3f0/0x640
[ 1119.159040]
other info that might help us debug this:
[ 1119.159042] Possible unsafe locking scenario:
[ 1119.159043] CPU0
[ 1119.159045] ----
[ 1119.159047] lock(&ns->lock/1);
[ 1119.159051] lock(&ns->lock/1);
[ 1119.159055]
*** DEADLOCK ***
Which is caused by an incorrect lockdep nesting notation
Fixes:
feb3c766a3ab ("apparmor: fix possible recursive lock warning in __aa_create_ns")
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gaosheng Cui [Tue, 23 Aug 2022 01:15:03 +0000 (09:15 +0800)]
apparmor: fix a memleak in multi_transaction_new()
[ Upstream commit
c73275cf6834787ca090317f1d20dbfa3b7f05aa ]
In multi_transaction_new(), the variable t is not freed or passed out
on the failure of copy_from_user(t->data, buf, size), which could lead
to a memleak.
Fix this bug by adding a put_multi_transaction(t) in the error path.
Fixes:
1dea3b41e84c5 ("apparmor: speed up transactional queries")
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vladimir Oltean [Fri, 9 Dec 2022 23:52:42 +0000 (01:52 +0200)]
net: dsa: tag_8021q: avoid leaking ctx on dsa_tag_8021q_register() error path
[ Upstream commit
e095493091e850d5292ad01d8fbf5cde1d89ac53 ]
If dsa_tag_8021q_setup() fails, for example due to the inability of the
device to install a VLAN, the tag_8021q context of the switch will leak.
Make sure it is freed on the error path.
Fixes:
328621f6131f ("net: dsa: tag_8021q: absorb dsa_8021q_setup into dsa_tag_8021q_{,un}register")
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20221209235242.480344-1-vladimir.oltean@nxp.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bartosz Staszewski [Fri, 9 Dec 2022 18:54:11 +0000 (10:54 -0800)]
i40e: Fix the inability to attach XDP program on downed interface
[ Upstream commit
0c87b545a2ed5cd8a6318011f1c92b188c2d74bc ]
Whenever trying to load XDP prog on downed interface, function i40e_xdp
was passing vsi->rx_buf_len field to i40e_xdp_setup() which was equal 0.
i40e_open() calls i40e_vsi_configure_rx() which configures that field,
but that only happens when interface is up. When it is down, i40e_open()
is not being called, thus vsi->rx_buf_len is not set.
Solution for this is calculate buffer length in newly created
function - i40e_calculate_vsi_rx_buf_len() that return actual buffer
length. Buffer length is being calculated based on the same rules
applied previously in i40e_vsi_configure_rx() function.
Fixes:
613142b0bb88 ("i40e: Log error for oversized MTU on device")
Fixes:
0c8493d90b6b ("i40e: add XDP support for pass and drop actions")
Signed-off-by: Bartosz Staszewski <bartoszx.staszewski@intel.com>
Signed-off-by: Mateusz Palczewski <mateusz.palczewski@intel.com>
Tested-by: Shwetha Nagaraju <Shwetha.nagaraju@intel.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Reviewed-by: Saeed Mahameed <saeed@kernel.com>
Link: https://lore.kernel.org/r/20221209185411.2519898-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Piergiorgio Beruto [Sat, 10 Dec 2022 22:37:22 +0000 (23:37 +0100)]
stmmac: fix potential division by 0
[ Upstream commit
ede5a389852d3640a28e7187fb32b7f204380901 ]
When the MAC is connected to a 10 Mb/s PHY and the PTP clock is derived
from the MAC reference clock (default), the clk_ptp_rate becomes too
small and the calculated sub second increment becomes 0 when computed by
the stmmac_config_sub_second_increment() function within
stmmac_init_tstamp_counter().
Therefore, the subsequent div_u64 in stmmac_init_tstamp_counter()
operation triggers a divide by 0 exception as shown below.
[ 95.062067] socfpga-dwmac
ff700000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0
[ 95.076440] socfpga-dwmac
ff700000.ethernet eth0: PHY [stmmac-0:08] driver [NCN26000] (irq=49)
[ 95.095964] dwmac1000: Master AXI performs any burst length
[ 95.101588] socfpga-dwmac
ff700000.ethernet eth0: No Safety Features support found
[ 95.109428] Division by zero in kernel.
[ 95.113447] CPU: 0 PID: 239 Comm: ifconfig Not tainted 6.1.0-rc7-centurion3-1.0.3.0-01574-gb624218205b7-dirty #77
[ 95.123686] Hardware name: Altera SOCFPGA
[ 95.127695] unwind_backtrace from show_stack+0x10/0x14
[ 95.132938] show_stack from dump_stack_lvl+0x40/0x4c
[ 95.137992] dump_stack_lvl from Ldiv0+0x8/0x10
[ 95.142527] Ldiv0 from __aeabi_uidivmod+0x8/0x18
[ 95.147232] __aeabi_uidivmod from div_u64_rem+0x1c/0x40
[ 95.152552] div_u64_rem from stmmac_init_tstamp_counter+0xd0/0x164
[ 95.158826] stmmac_init_tstamp_counter from stmmac_hw_setup+0x430/0xf00
[ 95.165533] stmmac_hw_setup from __stmmac_open+0x214/0x2d4
[ 95.171117] __stmmac_open from stmmac_open+0x30/0x44
[ 95.176182] stmmac_open from __dev_open+0x11c/0x134
[ 95.181172] __dev_open from __dev_change_flags+0x168/0x17c
[ 95.186750] __dev_change_flags from dev_change_flags+0x14/0x50
[ 95.192662] dev_change_flags from devinet_ioctl+0x2b4/0x604
[ 95.198321] devinet_ioctl from inet_ioctl+0x1ec/0x214
[ 95.203462] inet_ioctl from sock_ioctl+0x14c/0x3c4
[ 95.208354] sock_ioctl from vfs_ioctl+0x20/0x38
[ 95.212984] vfs_ioctl from sys_ioctl+0x250/0x844
[ 95.217691] sys_ioctl from ret_fast_syscall+0x0/0x4c
[ 95.222743] Exception stack(0xd0ee1fa8 to 0xd0ee1ff0)
[ 95.227790] 1fa0:
00574c4f be9aeca4 00000003 00008914 be9aeca4 be9aec50
[ 95.235945] 1fc0:
00574c4f be9aeca4 0059f078 00000036 be9aee8c be9aef7a 00000015 00000000
[ 95.244096] 1fe0:
005a01f0 be9aec38 004d7484 b6e67d74
Signed-off-by: Piergiorgio Beruto <piergiorgio.beruto@gmail.com>
Fixes:
91a2559c1dc5 ("net: stmmac: Fix sub-second increment")
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/de4c64ccac9084952c56a06a8171d738604c4770.1670678513.git.piergiorgio.beruto@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 7 Dec 2022 02:18:35 +0000 (10:18 +0800)]
Bluetooth: RFCOMM: don't call kfree_skb() under spin_lock_irqsave()
[ Upstream commit
0ba18967d4544955b2eff2fbc4f2a8750c4df90a ]
It is not allowed to call kfree_skb() from hardware interrupt
context or with interrupts being disabled. So replace kfree_skb()
with dev_kfree_skb_irq() under spin_lock_irqsave().
Fixes:
81be03e026dc ("Bluetooth: RFCOMM: Replace use of memcpy_from_msg with bt_skb_sendmmsg")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 7 Dec 2022 02:18:34 +0000 (10:18 +0800)]
Bluetooth: hci_core: don't call kfree_skb() under spin_lock_irqsave()
[ Upstream commit
39c1eb6fcbae8ce9bb71b2ac5cb609355a2b181b ]
It is not allowed to call kfree_skb() from hardware interrupt
context or with interrupts being disabled. So replace kfree_skb()
with dev_kfree_skb_irq() under spin_lock_irqsave().
Fixes:
9238f36a5a50 ("Bluetooth: Add request cmd_complete and cmd_status functions")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 7 Dec 2022 02:18:33 +0000 (10:18 +0800)]
Bluetooth: hci_bcsp: don't call kfree_skb() under spin_lock_irqsave()
[ Upstream commit
7b503e339c1a80bf0051ec2d19c3bc777014ac61 ]
It is not allowed to call kfree_skb() from hardware interrupt
context or with interrupts being disabled. So replace kfree_skb()
with dev_kfree_skb_irq() under spin_lock_irqsave().
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 7 Dec 2022 02:18:32 +0000 (10:18 +0800)]
Bluetooth: hci_h5: don't call kfree_skb() under spin_lock_irqsave()
[ Upstream commit
383630cc6758d619874c2e8bb2f68a61f3f9ef6e ]
It is not allowed to call kfree_skb() from hardware interrupt
context or with interrupts being disabled. So replace kfree_skb()
with dev_kfree_skb_irq() under spin_lock_irqsave().
Fixes:
43eb12d78960 ("Bluetooth: Fix/implement Three-wire reliable packet sending")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 7 Dec 2022 02:18:31 +0000 (10:18 +0800)]
Bluetooth: hci_ll: don't call kfree_skb() under spin_lock_irqsave()
[ Upstream commit
8f458f783dfbb19c1f1cb58ed06eeb701f52091b ]
It is not allowed to call kfree_skb() from hardware interrupt
context or with interrupts being disabled. So replace kfree_skb()
with dev_kfree_skb_irq() under spin_lock_irqsave().
Fixes:
166d2f6a4332 ("[Bluetooth] Add UART driver for Texas Instruments' BRF63xx chips")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 7 Dec 2022 02:18:30 +0000 (10:18 +0800)]
Bluetooth: hci_qca: don't call kfree_skb() under spin_lock_irqsave()
[ Upstream commit
df4cfc91208e0a98f078223793f5871b1a82cc54 ]
It is not allowed to call kfree_skb() from hardware interrupt
context or with interrupts being disabled. So replace kfree_skb()
with dev_kfree_skb_irq() under spin_lock_irqsave().
Fixes:
0ff252c1976d ("Bluetooth: hciuart: Add support QCA chipset for UART")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 6 Dec 2022 12:59:10 +0000 (20:59 +0800)]
Bluetooth: btusb: don't call kfree_skb() under spin_lock_irqsave()
[ Upstream commit
b15a6bd3c80c77faec8317319b97f976b1a08332 ]
It is not allowed to call kfree_skb() from hardware interrupt
context or with interrupts being disabled. So replace kfree_skb()
with dev_kfree_skb_irq() under spin_lock_irqsave().
Fixes:
803b58367ffb ("Bluetooth: btusb: Implement driver internal packet reassembly")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang ShaoBo [Mon, 5 Dec 2022 13:53:57 +0000 (21:53 +0800)]
Bluetooth: btintel: Fix missing free skb in btintel_setup_combined()
[ Upstream commit
cee50ce899de415baf4da3ed38b7d4f13c3170d1 ]
skb allocated by __hci_cmd_sync would not be used whether in checking
for supported iBT hardware variants or after, we should free it in all
error branches, this patch makes the case read version failed or default
error case free skb before return.
Fixes:
c86c7285bb08 ("Bluetooth: btintel: Fix the legacy bootloader returns tlv based version")
Fixes:
019a1caa7fd2 ("Bluetooth: btintel: Refactoring setup routine for bootloader devices")
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
Reviewed-by: Tedd Ho-Jeong An <tedd.an@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Inga Stotland [Sat, 22 Oct 2022 00:48:56 +0000 (17:48 -0700)]
Bluetooth: MGMT: Fix error report for ADD_EXT_ADV_PARAMS
[ Upstream commit
3b1c7c00b8c22b3cb79532252c59eb0b287bb86d ]
When validating the parameter length for MGMT_OP_ADD_EXT_ADV_PARAMS
command, use the correct op code in error status report:
was MGMT_OP_ADD_ADVERTISING, changed to MGMT_OP_ADD_EXT_ADV_PARAMS.
Fixes:
12410572833a2 ("Bluetooth: Break add adv into two mgmt commands")
Signed-off-by: Inga Stotland <inga.stotland@intel.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Firo Yang [Fri, 9 Dec 2022 05:48:54 +0000 (13:48 +0800)]
sctp: sysctl: make extra pointers netns aware
[ Upstream commit
da05cecc4939c0410d56c29e252998b192756318 ]
Recently, a customer reported that from their container whose
net namespace is different to the host's init_net, they can't set
the container's net.sctp.rto_max to any value smaller than
init_net.sctp.rto_min.
For instance,
Host:
sudo sysctl net.sctp.rto_min
net.sctp.rto_min = 1000
Container:
echo 100 > /mnt/proc-net/sctp/rto_min
echo 400 > /mnt/proc-net/sctp/rto_max
echo: write error: Invalid argument
This is caused by the check made from this'commit
4f3fdf3bc59c
("sctp: add check rto_min and rto_max in sysctl")'
When validating the input value, it's always referring the boundary
value set for the init_net namespace.
Having container's rto_max smaller than host's init_net.sctp.rto_min
does make sense. Consider that the rto between two containers on the
same host is very likely smaller than it for two hosts.
So to fix this problem, as suggested by Marcelo, this patch makes the
extra pointers of rto_min, rto_max, pf_retrans, and ps_retrans point
to the corresponding variables from the newly created net namespace while
the new net namespace is being registered in sctp_sysctl_net_register.
Fixes:
4f3fdf3bc59c ("sctp: add check rto_min and rto_max in sysctl")
Reviewed-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Reviewed-by: Jakub Kicinski <kuba@kernel.org>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: Firo Yang <firo.yang@suse.com>
Link: https://lore.kernel.org/r/20221209054854.23889-1-firo.yang@suse.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Eric Pilmore [Fri, 9 Dec 2022 00:06:59 +0000 (16:06 -0800)]
ntb_netdev: Use dev_kfree_skb_any() in interrupt context
[ Upstream commit
5f7d78b2b12a9d561f48fa00bab29b40f4616dad ]
TX/RX callback handlers (ntb_netdev_tx_handler(),
ntb_netdev_rx_handler()) can be called in interrupt
context via the DMA framework when the respective
DMA operations have completed. As such, any calls
by these routines to free skb's, should use the
interrupt context safe dev_kfree_skb_any() function.
Previously, these callback handlers would call the
interrupt unsafe version of dev_kfree_skb(). This has
not presented an issue on Intel IOAT DMA engines as
that driver utilizes tasklets rather than a hard
interrupt handler, like the AMD PTDMA DMA driver.
On AMD systems, a kernel WARNING message is
encountered, which is being issued from
skb_release_head_state() due to in_hardirq()
being true.
Besides the user visible WARNING from the kernel,
the other symptom of this bug was that TCP/IP performance
across the ntb_netdev interface was very poor, i.e.
approximately an order of magnitude below what was
expected. With the repair to use dev_kfree_skb_any(),
kernel WARNINGs from skb_release_head_state() ceased
and TCP/IP performance, as measured by iperf, was on
par with expected results, approximately 20 Gb/s on
AMD Milan based server. Note that this performance
is comparable with Intel based servers.
Fixes:
765ccc7bc3d91 ("ntb_netdev: correct skb leak")
Fixes:
548c237c0a997 ("net: Add support for NTB virtual ethernet device")
Signed-off-by: Eric Pilmore <epilmore@gigaio.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20221209000659.8318-1-epilmore@gigaio.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jerry Ray [Fri, 9 Dec 2022 15:35:02 +0000 (09:35 -0600)]
net: lan9303: Fix read error execution path
[ Upstream commit
8964916d206071b058c6351f88b1966bd58cbde0 ]
This patch fixes an issue where a read failure of a port statistic counter
will return unknown results. While it is highly unlikely the read will
ever fail, it is much cleaner to return a zero for the stat count.
Fixes:
a1292595e006 ("net: dsa: add new DSA switch driver for the SMSC-LAN9303")
Signed-off-by: Jerry Ray <jerry.ray@microchip.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Link: https://lore.kernel.org/r/20221209153502.7429-1-jerry.ray@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Markus Schneider-Pargmann [Tue, 6 Dec 2022 11:57:26 +0000 (12:57 +0100)]
can: tcan4x5x: Fix use of register error status mask
[ Upstream commit
67727a17a6b375d68fe569b77e6516b034b834c0 ]
TCAN4X5X_ERROR_STATUS is not a status register that needs clearing
during interrupt handling. Instead this is a masking register that masks
error interrupts. Writing TCAN4X5X_CLEAR_ALL_INT to this register
effectively masks everything.
Rename the register and mask all error interrupts only once by writing
to the register in tcan4x5x_init.
Fixes:
5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel")
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/all/20221206115728.1056014-10-msp@baylibre.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Vivek Yadav [Wed, 7 Dec 2022 10:06:31 +0000 (15:36 +0530)]
can: m_can: Call the RAM init directly from m_can_chip_config
[ Upstream commit
eaacfeaca7ad0804b9a6eff7afeba93a87db7638 ]
When we try to access the mcan message ram addresses during the probe,
hclk is gated by any other drivers or disabled, because of that probe
gets failed.
Move the mram init functionality to mcan chip config called by
m_can_start from mcan open function, by that time clocks are
enabled.
Suggested-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Vivek Yadav <vivek.2311@samsung.com>
Link: https://lore.kernel.org/all/20221207100632.96200-2-vivek.2311@samsung.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Stable-dep-of:
67727a17a6b3 ("can: tcan4x5x: Fix use of register error status mask")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Markus Schneider-Pargmann [Tue, 6 Dec 2022 11:57:25 +0000 (12:57 +0100)]
can: tcan4x5x: Remove invalid write in clear_interrupts
[ Upstream commit
40c9e4f676abbe194541d88e796341c92d5a13c0 ]
Register 0x824 TCAN4X5X_MCAN_INT_REG is a read-only register. Any writes
to this register do not have any effect.
Remove this write. The m_can driver aldready clears the interrupts in
m_can_isr() by writing to M_CAN_IR which is translated to register
0x1050 which is a writable version of this register.
Fixes:
5443c226ba91 ("can: tcan4x5x: Add tcan4x5x driver to the kernel")
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/all/20221206115728.1056014-9-msp@baylibre.com
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tom Lendacky [Thu, 8 Dec 2022 16:22:25 +0000 (10:22 -0600)]
net: amd-xgbe: Check only the minimum speed for active/passive cables
[ Upstream commit
f8ab263d4d48e6dab752029bf562f20a2ee630ed ]
There are cables that exist that can support speeds in excess of 10GbE.
The driver, however, restricts the EEPROM advertised nominal bitrate to
a specific range, which can prevent usage of cables that can support,
for example, up to 25GbE.
Rather than checking that an active or passive cable supports a specific
range, only check for a minimum supported speed.
Fixes:
abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tom Lendacky [Thu, 8 Dec 2022 16:22:24 +0000 (10:22 -0600)]
net: amd-xgbe: Fix logic around active and passive cables
[ Upstream commit
4998006c73afe44e2f639d55bd331c6c26eb039f ]
SFP+ active and passive cables are copper cables with fixed SFP+ end
connectors. Due to a misinterpretation of this, SFP+ active cables could
end up not being recognized, causing the driver to fail to establish a
connection.
Introduce a new enum in SFP+ cable types, XGBE_SFP_CABLE_FIBER, that is
the default cable type, and handle active and passive cables when they are
specifically detected.
Fixes:
abf0a1c2b26a ("amd-xgbe: Add support for SFP+ modules")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Thu, 8 Dec 2022 15:01:58 +0000 (23:01 +0800)]
af_unix: call proto_unregister() in the error path in af_unix_init()
[ Upstream commit
73e341e0281a35274629e9be27eae2f9b1b492bf ]
If register unix_stream_proto returns error, unix_dgram_proto needs
be unregistered.
Fixes:
94531cfcbe79 ("af_unix: Add unix_stream_proto for sockmap")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Thu, 8 Dec 2022 14:21:47 +0000 (22:21 +0800)]
net: amd: lance: don't call dev_kfree_skb() under spin_lock_irqsave()
[ Upstream commit
6151d105dfce8c23edf30eed35e97f3d9b96a35c ]
It is not allowed to call kfree_skb() or consume_skb() from hardware
interrupt context or with hardware interrupts being disabled.
It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
The difference between them is free reason, dev_kfree_skb_irq() means
the SKB is dropped in error and dev_consume_skb_irq() means the SKB
is consumed in normal.
In these two cases, dev_kfree_skb() is called consume the xmited SKB,
so replace it with dev_consume_skb_irq().
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Thu, 8 Dec 2022 14:21:46 +0000 (22:21 +0800)]
hamradio: don't call dev_kfree_skb() under spin_lock_irqsave()
[ Upstream commit
3727f742915f04f6fc550b80cf406999bd4e90d0 ]
It is not allowed to call kfree_skb() or consume_skb() from hardware
interrupt context or with hardware interrupts being disabled.
It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
The difference between them is free reason, dev_kfree_skb_irq() means
the SKB is dropped in error and dev_consume_skb_irq() means the SKB
is consumed in normal.
In scc_discard_buffers(), dev_kfree_skb() is called to discard the SKBs,
so replace it with dev_kfree_skb_irq().
In scc_net_tx(), dev_kfree_skb() is called to drop the SKB that exceed
queue length, so replace it with dev_kfree_skb_irq().
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Thu, 8 Dec 2022 14:21:45 +0000 (22:21 +0800)]
net: ethernet: dnet: don't call dev_kfree_skb() under spin_lock_irqsave()
[ Upstream commit
f07fadcbee2a5e84caa67c7c445424200bffb60b ]
It is not allowed to call kfree_skb() or consume_skb() from hardware
interrupt context or with hardware interrupts being disabled.
In this case, the lock is used to protected 'bp', so we can move
dev_kfree_skb() after the spin_unlock_irqrestore().
Fixes:
4796417417a6 ("dnet: Dave DNET ethernet controller driver (updated)")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Thu, 8 Dec 2022 14:21:44 +0000 (22:21 +0800)]
net: emaclite: don't call dev_kfree_skb() under spin_lock_irqsave()
[ Upstream commit
d1678bf45f21fa5ae4a456f821858679556ea5f8 ]
It is not allowed to call kfree_skb() or consume_skb() from hardware
interrupt context or with hardware interrupts being disabled.
It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
The difference between them is free reason, dev_kfree_skb_irq() means
the SKB is dropped in error and dev_consume_skb_irq() means the SKB
is consumed in normal.
In this case, dev_kfree_skb() is called in xemaclite_tx_timeout() to
drop the SKB, when tx timeout, so replace it with dev_kfree_skb_irq().
Fixes:
bb81b2ddfa19 ("net: add Xilinx emac lite device driver")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Thu, 8 Dec 2022 13:37:35 +0000 (21:37 +0800)]
net: apple: bmac: don't call dev_kfree_skb() under spin_lock_irqsave()
[ Upstream commit
5fe02e046e6422c4adfdbc50206ec7186077da24 ]
It is not allowed to call kfree_skb() or consume_skb() from hardware
interrupt context or with hardware interrupts being disabled.
It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
The difference between them is free reason, dev_kfree_skb_irq() means
the SKB is dropped in error and dev_consume_skb_irq() means the SKB
is consumed in normal.
In this case, dev_kfree_skb() is called in bmac_tx_timeout() to drop
the SKB, when tx timeout, so replace it with dev_kfree_skb_irq().
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Thu, 8 Dec 2022 13:37:34 +0000 (21:37 +0800)]
net: apple: mace: don't call dev_kfree_skb() under spin_lock_irqsave()
[ Upstream commit
3dfe3486c1cd4f82b466b7d307f23777137b8acc ]
It is not allowed to call kfree_skb() or consume_skb() from hardware
interrupt context or with hardware interrupts being disabled.
It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
The difference between them is free reason, dev_kfree_skb_irq() means
the SKB is dropped in error and dev_consume_skb_irq() means the SKB
is consumed in normal.
In this case, dev_kfree_skb() is called in mace_tx_timeout() to drop
the SKB, when tx timeout, so replace it with dev_kfree_skb_irq().
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Hangbin Liu [Thu, 8 Dec 2022 12:04:52 +0000 (20:04 +0800)]
net/tunnel: wait until all sk_user_data reader finish before releasing the sock
[ Upstream commit
3cf7203ca620682165706f70a1b12b5194607dce ]
There is a race condition in vxlan that when deleting a vxlan device
during receiving packets, there is a possibility that the sock is
released after getting vxlan_sock vs from sk_user_data. Then in
later vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got
NULL pointer dereference. e.g.
#0 [
ffffa25ec6978a38] machine_kexec at
ffffffff8c669757
#1 [
ffffa25ec6978a90] __crash_kexec at
ffffffff8c7c0a4d
#2 [
ffffa25ec6978b58] crash_kexec at
ffffffff8c7c1c48
#3 [
ffffa25ec6978b60] oops_end at
ffffffff8c627f2b
#4 [
ffffa25ec6978b80] page_fault_oops at
ffffffff8c678fcb
#5 [
ffffa25ec6978bd8] exc_page_fault at
ffffffff8d109542
#6 [
ffffa25ec6978c00] asm_exc_page_fault at
ffffffff8d200b62
[exception RIP: vxlan_ecn_decapsulate+0x3b]
RIP:
ffffffffc1014e7b RSP:
ffffa25ec6978cb0 RFLAGS:
00010246
RAX:
0000000000000008 RBX:
ffff8aa000888000 RCX:
0000000000000000
RDX:
000000000000000e RSI:
ffff8a9fc7ab803e RDI:
ffff8a9fd1168700
RBP:
ffff8a9fc7ab803e R8:
0000000000700000 R9:
00000000000010ae
R10:
ffff8a9fcb748980 R11:
0000000000000000 R12:
ffff8a9fd1168700
R13:
ffff8aa000888000 R14:
00000000002a0000 R15:
00000000000010ae
ORIG_RAX:
ffffffffffffffff CS: 0010 SS: 0018
#7 [
ffffa25ec6978ce8] vxlan_rcv at
ffffffffc10189cd [vxlan]
#8 [
ffffa25ec6978d90] udp_queue_rcv_one_skb at
ffffffff8cfb6507
#9 [
ffffa25ec6978dc0] udp_unicast_rcv_skb at
ffffffff8cfb6e45
#10 [
ffffa25ec6978dc8] __udp4_lib_rcv at
ffffffff8cfb8807
#11 [
ffffa25ec6978e20] ip_protocol_deliver_rcu at
ffffffff8cf76951
#12 [
ffffa25ec6978e48] ip_local_deliver at
ffffffff8cf76bde
#13 [
ffffa25ec6978ea0] __netif_receive_skb_one_core at
ffffffff8cecde9b
#14 [
ffffa25ec6978ec8] process_backlog at
ffffffff8cece139
#15 [
ffffa25ec6978f00] __napi_poll at
ffffffff8ceced1a
#16 [
ffffa25ec6978f28] net_rx_action at
ffffffff8cecf1f3
#17 [
ffffa25ec6978fa0] __softirqentry_text_start at
ffffffff8d4000ca
#18 [
ffffa25ec6978ff0] do_softirq at
ffffffff8c6fbdc3
Reproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh
Fix this by waiting for all sk_user_data reader to finish before
releasing the sock.
Reported-by: Jianlin Shi <jishi@redhat.com>
Suggested-by: Jakub Sitnicki <jakub@cloudflare.com>
Fixes:
6a93cc905274 ("udp-tunnel: Add a few more UDP tunnel APIs")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Li Zetao [Thu, 8 Dec 2022 12:05:40 +0000 (20:05 +0800)]
net: farsync: Fix kmemleak when rmmods farsync
[ Upstream commit
2f623aaf9f31de968dea6169849706a2f9be444c ]
There are two memory leaks reported by kmemleak:
unreferenced object 0xffff888114b20200 (size 128):
comm "modprobe", pid 4846, jiffies
4295146524 (age 401.345s)
hex dump (first 32 bytes):
e0 62 57 09 81 88 ff ff e0 62 57 09 81 88 ff ff .bW......bW.....
01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<
ffffffff815bcd82>] kmalloc_trace+0x22/0x60
[<
ffffffff83d35c78>] __hw_addr_add_ex+0x198/0x6c0
[<
ffffffff83d3989d>] dev_addr_init+0x13d/0x230
[<
ffffffff83d1063d>] alloc_netdev_mqs+0x10d/0xe50
[<
ffffffff82b4a06e>] alloc_hdlcdev+0x2e/0x80
[<
ffffffffa016a741>] fst_add_one+0x601/0x10e0 [farsync]
...
unreferenced object 0xffff88810b85b000 (size 1024):
comm "modprobe", pid 4846, jiffies
4295146523 (age 401.346s)
hex dump (first 32 bytes):
00 00 b0 02 00 c9 ff ff 00 70 0a 00 00 c9 ff ff .........p......
00 00 00 f2 00 00 00 f3 0a 00 00 00 02 00 00 00 ................
backtrace:
[<
ffffffff815bcd82>] kmalloc_trace+0x22/0x60
[<
ffffffffa016a294>] fst_add_one+0x154/0x10e0 [farsync]
[<
ffffffff82060e83>] local_pci_probe+0xd3/0x170
...
The root cause is traced to the netdev and fst_card_info are not freed
when removes one fst in fst_remove_one(), which may trigger oom if
repeated insmod and rmmod module.
Fix it by adding free_netdev() and kfree() in fst_remove_one(), just as
the operations on the error handling path in fst_add_one().
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Li Zetao <lizetao1@huawei.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Thu, 8 Dec 2022 12:01:21 +0000 (20:01 +0800)]
ethernet: s2io: don't call dev_kfree_skb() under spin_lock_irqsave()
[ Upstream commit
6cee96e09df54ae17784c0f38a49e0ed8229b825 ]
It is not allowed to call kfree_skb() or consume_skb() from hardware
interrupt context or with hardware interrupts being disabled.
It should use dev_kfree_skb_irq() or dev_consume_skb_irq() instead.
The difference between them is free reason, dev_kfree_skb_irq() means
the SKB is dropped in error and dev_consume_skb_irq() means the SKB
is consumed in normal.
In this case, dev_kfree_skb() is called in free_tx_buffers() to drop
the SKBs in tx buffers, when the card is down, so replace it with
dev_kfree_skb_irq() here.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ruanjinjie [Sun, 11 Dec 2022 02:33:37 +0000 (10:33 +0800)]
of: overlay: fix null pointer dereferencing in find_dup_cset_node_entry() and find_dup_cset_prop()
[ Upstream commit
ee9d7a0e754568180a2f8ebc4aad226278a9116f ]
When kmalloc() fail to allocate memory in kasprintf(), fn_1 or fn_2 will
be NULL, and strcmp() will cause null pointer dereference.
Fixes:
2fe0e8769df9 ("of: overlay: check prevents multiple fragments touching same property")
Signed-off-by: ruanjinjie <ruanjinjie@huawei.com>
Link: https://lore.kernel.org/r/20221211023337.592266-1-ruanjinjie@huawei.com
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yuan Can [Wed, 7 Dec 2022 08:54:10 +0000 (08:54 +0000)]
drivers: net: qlcnic: Fix potential memory leak in qlcnic_sriov_init()
[ Upstream commit
01de1123322e4fe1bbd0fcdf0982511b55519c03 ]
If vp alloc failed in qlcnic_sriov_init(), all previously allocated vp
needs to be freed.
Fixes:
f197a7aa6288 ("qlcnic: VF-PF communication channel implementation")
Signed-off-by: Yuan Can <yuancan@huawei.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gaosheng Cui [Wed, 7 Dec 2022 08:34:13 +0000 (16:34 +0800)]
net: stmmac: fix possible memory leak in stmmac_dvr_probe()
[ Upstream commit
a137f3f27f9290933fe7e40e6dc8a445781c31a2 ]
The bitmap_free() should be called to free priv->af_xdp_zc_qps
when create_singlethread_workqueue() fails, otherwise there will
be a memory leak, so we add the err path error_wq_init to fix it.
Fixes:
bba2556efad6 ("net: stmmac: Enable RX via AF_XDP zero-copy")
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Changzhong [Wed, 7 Dec 2022 08:31:59 +0000 (16:31 +0800)]
net: stmmac: selftests: fix potential memleak in stmmac_test_arpoffload()
[ Upstream commit
f150b63f3fa5fdd81e0dd6151e8850268e29438c ]
The skb allocated by stmmac_test_get_arp_skb() hasn't been released in
some error handling case, which will lead to a memory leak. Fix this up
by adding kfree_skb() to release skb.
Compile tested only.
Fixes:
5e3fb0a6e2b3 ("net: stmmac: selftests: Implement the ARP Offload test")
Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yongqiang Liu [Wed, 7 Dec 2022 07:20:45 +0000 (07:20 +0000)]
net: defxx: Fix missing err handling in dfx_init()
[ Upstream commit
ae18dcdff0f8d7e84cd3fd9f496518b5e72d185d ]
When eisa_driver_register() or tc_register_driver() failed,
the modprobe defxx would fail with some err log as follows:
Error: Driver 'defxx' is already registered, aborting...
Fix this issue by adding err hanling in dfx_init().
Fixes:
e89a2cfb7d7b5 ("[TC] defxx: TURBOchannel support")
Signed-off-by: Yongqiang Liu <liuyongqiang13@huawei.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Artem Chernyshev [Tue, 6 Dec 2022 06:58:34 +0000 (09:58 +0300)]
net: vmw_vsock: vmci: Check memcpy_from_msg()
[ Upstream commit
44aa5a6dba8283bfda28b1517af4de711c5652a4 ]
vmci_transport_dgram_enqueue() does not check the return value
of memcpy_from_msg(). If memcpy_from_msg() fails, it is possible that
uninitialized memory contents are sent unintentionally instead of user's
message in the datagram to the destination. Return with an error if
memcpy_from_msg() fails.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes:
0f7db23a07af ("vmci_transport: switch ->enqeue_dgram, ->enqueue_stream and ->dequeue_stream to msghdr")
Signed-off-by: Artem Chernyshev <artem.chernyshev@red-soft.ru>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Reviewed-by: Vishnu Dasa <vdasa@vmware.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiu Jianfeng [Wed, 23 Nov 2022 03:16:22 +0000 (11:16 +0800)]
clk: socfpga: Fix memory leak in socfpga_gate_init()
[ Upstream commit
0b8ba891ad4d1ef6bfa4c72efc83f9f9f855f68b ]
Free @socfpga_clk and @ops on the error path to avoid memory leak issue.
Fixes:
a30a67be7b6e ("clk: socfpga: Don't have get_parent for single parent ops")
Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Link: https://lore.kernel.org/r/20221123031622.63171-1-xiujianfeng@huawei.com
Acked-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Björn Töpel [Wed, 7 Dec 2022 10:35:40 +0000 (11:35 +0100)]
bpf: Do not zero-extend kfunc return values
[ Upstream commit
d35af0a7feb077c43ff0233bba5a8c6e75b73e35 ]
In BPF all global functions, and BPF helpers return a 64-bit
value. For kfunc calls, this is not the case, and they can return
e.g. 32-bit values.
The return register R0 for kfuncs calls can therefore be marked as
subreg_def != DEF_NOT_SUBREG. In general, if a register is marked with
subreg_def != DEF_NOT_SUBREG, some archs (where bpf_jit_needs_zext()
returns true) require the verifier to insert explicit zero-extension
instructions.
For kfuncs calls, however, the caller should do sign/zero extension
for return values. In other words, the compiler is responsible to
insert proper instructions, not the verifier.
An example, provided by Yonghong Song:
$ cat t.c
extern unsigned foo(void);
unsigned bar1(void) {
return foo();
}
unsigned bar2(void) {
if (foo()) return 10; else return 20;
}
$ clang -target bpf -mcpu=v3 -O2 -c t.c && llvm-objdump -d t.o
t.o: file format elf64-bpf
Disassembly of section .text:
0000000000000000 <bar1>:
0: 85 10 00 00 ff ff ff ff call -0x1
1: 95 00 00 00 00 00 00 00 exit
0000000000000010 <bar2>:
2: 85 10 00 00 ff ff ff ff call -0x1
3: bc 01 00 00 00 00 00 00 w1 = w0
4: b4 00 00 00 14 00 00 00 w0 = 0x14
5: 16 01 01 00 00 00 00 00 if w1 == 0x0 goto +0x1 <LBB1_2>
6: b4 00 00 00 0a 00 00 00 w0 = 0xa
0000000000000038 <LBB1_2>:
7: 95 00 00 00 00 00 00 00 exit
If the return value of 'foo()' is used in the BPF program, the proper
zero-extension will be done.
Currently, the verifier correctly marks, say, a 32-bit return value as
subreg_def != DEF_NOT_SUBREG, but will fail performing the actual
zero-extension, due to a verifier bug in
opt_subreg_zext_lo32_rnd_hi32(). load_reg is not properly set to R0,
and the following path will be taken:
if (WARN_ON(load_reg == -1)) {
verbose(env, "verifier bug. zext_dst is set, but no reg is defined\n");
return -EFAULT;
}
A longer discussion from v1 can be found in the link below.
Correct the verifier by avoiding doing explicit zero-extension of R0
for kfunc calls. Note that R0 will still be marked as a sub-register
for return values smaller than 64-bit.
Fixes:
83a2881903f3 ("bpf: Account for BPF_FETCH in insn_has_def32()")
Link: https://lore.kernel.org/bpf/20221202103620.1915679-1-bjorn@kernel.org/
Suggested-by: Yonghong Song <yhs@meta.com>
Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
Acked-by: Yonghong Song <yhs@fb.com>
Link: https://lore.kernel.org/r/20221207103540.396496-1-bjorn@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Jihong [Tue, 22 Nov 2022 04:04:10 +0000 (12:04 +0800)]
blktrace: Fix output non-blktrace event when blk_classic option enabled
[ Upstream commit
f596da3efaf4130ff61cd029558845808df9bf99 ]
When the blk_classic option is enabled, non-blktrace events must be
filtered out. Otherwise, events of other types are output in the blktrace
classic format, which is unexpected.
The problem can be triggered in the following ways:
# echo 1 > /sys/kernel/debug/tracing/options/blk_classic
# echo 1 > /sys/kernel/debug/tracing/events/enable
# echo blk > /sys/kernel/debug/tracing/current_tracer
# cat /sys/kernel/debug/tracing/trace_pipe
Fixes:
c71a89615411 ("blktrace: add ftrace plugin")
Signed-off-by: Yang Jihong <yangjihong1@huawei.com>
Link: https://lore.kernel.org/r/20221122040410.85113-1-yangjihong1@huawei.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang Yufen [Fri, 2 Dec 2022 05:35:42 +0000 (13:35 +0800)]
wifi: brcmfmac: Fix error return code in brcmf_sdio_download_firmware()
[ Upstream commit
c2f2924bc7f9ea75ef8d95863e710168f8196256 ]
Fix to return a negative error code instead of 0 when
brcmf_chip_set_active() fails. In addition, change the return
value for brcmf_pcie_exit_download_state() to keep consistent.
Fixes:
d380ebc9b6fb ("brcmfmac: rename chip download functions")
Signed-off-by: Wang Yufen <wangyufen@huawei.com>
Reviewed-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/1669959342-27144-1-git-send-email-wangyufen@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bitterblue Smith [Thu, 1 Dec 2022 14:15:08 +0000 (16:15 +0200)]
wifi: rtl8xxxu: Fix the channel width reporting
[ Upstream commit
76c16af2cb10282274596e21add2c9f0b95c941b ]
The gen 2 chips RTL8192EU and RTL8188FU periodically send the driver
reports about the TX rate, and the driver passes these reports to
sta_statistics. The reports from RTL8192EU may or may not include the
channel width. The reports from RTL8188FU do not include it.
Only access the c2h->ra_report.bw field if the report (skb) is big
enough.
The other problem fixed here is that the code was actually never
changing the channel width initially reported by
rtl8xxxu_bss_info_changed because the value of RATE_INFO_BW_20 is 0.
Fixes:
0985d3a410ac ("rtl8xxxu: Feed current txrate information for mac80211")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/5b41f1ae-72e7-6b7a-2459-b736399a1c40@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bitterblue Smith [Thu, 1 Dec 2022 14:13:57 +0000 (16:13 +0200)]
wifi: rtl8xxxu: Add __packed to struct rtl8723bu_c2h
[ Upstream commit
dd469a754afdb782ba3033cee102147493dc39f4 ]
This struct is used to access a sequence of bytes received from the
wifi chip. It must not have any padding bytes between the members.
This doesn't change anything on my system, possibly because currently
none of the members need more than byte alignment.
Fixes:
b2b43b7837ba ("rtl8xxxu: Initial functionality to handle C2H events for 8723bu")
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/1a270918-da22-ff5f-29fc-7855f740c5ba@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kris Bahnsen [Wed, 7 Dec 2022 23:08:53 +0000 (15:08 -0800)]
spi: spi-gpio: Don't set MOSI as an input if not 3WIRE mode
[ Upstream commit
3a6f994f848a69deb2bf3cd9d130dd0c09730e55 ]
The addition of 3WIRE support would affect MOSI direction even
when still in standard (4 wire) mode. This can lead to MOSI being
at an invalid logic level when a device driver sets an SPI
message with a NULL tx_buf.
spi.h states that if tx_buf is NULL then "zeros will be shifted
out ... " If MOSI is tristated then the data shifted out is subject
to pull resistors, keepers, or in the absence of those, noise.
This issue came to light when using spi-gpio connected to an
ADS7843 touchscreen controller. MOSI pulled high when clocking
MISO data in caused the SPI device to interpret this as a command
which would put the device in an unexpected and non-functional
state.
Fixes:
4b859db2c606 ("spi: spi-gpio: add SPI_3WIRE support")
Fixes:
5132b3d28371 ("spi: gpio: Support 3WIRE high-impedance turn-around")
Signed-off-by: Kris Bahnsen <kris@embeddedTS.com>
Link: https://lore.kernel.org/r/20221207230853.6174-1-kris@embeddedTS.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiu Jianfeng [Wed, 23 Nov 2022 03:20:15 +0000 (11:20 +0800)]
clk: samsung: Fix memory leak in _samsung_clk_register_pll()
[ Upstream commit
5174e5b0d1b669a489524192b6adcbb3c54ebc72 ]
If clk_register() fails, @pll->rate_table may have allocated memory by
kmemdup(), so it needs to be freed, otherwise will cause memory leak
issue, this patch fixes it.
Fixes:
3ff6e0d8d64d ("clk: samsung: Add support to register rate_table for samsung plls")
Signed-off-by: Xiu Jianfeng <xiujianfeng@huawei.com>
Link: https://lore.kernel.org/r/20221123032015.63980-1-xiujianfeng@huawei.com
Reviewed-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Thu, 17 Nov 2022 07:02:36 +0000 (15:02 +0800)]
media: coda: Add check for kmalloc
[ Upstream commit
6e5e5defdb8b0186312c2f855ace175aee6daf9b ]
As the kmalloc may return NULL pointer,
it should be better to check the return value
in order to avoid NULL poineter dereference,
same as the others.
Fixes:
cb1d3a336371 ("[media] coda: add CODA7541 JPEG support")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Thu, 17 Nov 2022 06:56:52 +0000 (14:56 +0800)]
media: coda: Add check for dcoda_iram_alloc
[ Upstream commit
6b8082238fb8bb20f67e46388123e67a5bbc558d ]
As the coda_iram_alloc may return NULL pointer,
it should be better to check the return value
in order to avoid NULL poineter dereference,
same as the others.
Fixes:
b313bcc9a467 ("[media] coda: simplify IRAM setup")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Liang He [Tue, 19 Jul 2022 14:10:23 +0000 (22:10 +0800)]
media: c8sectpfe: Add of_node_put() when breaking out of loop
[ Upstream commit
63ff05a1ad242a5a0f897921c87b70d601bda59c ]
In configure_channels(), we should call of_node_put() when breaking
out of for_each_child_of_node() which will automatically increase
and decrease the refcount.
Fixes:
c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support")
Signed-off-by: Liang He <windhl@126.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yuan Can [Sat, 3 Dec 2022 06:21:09 +0000 (06:21 +0000)]
regulator: qcom-labibb: Fix missing of_node_put() in qcom_labibb_regulator_probe()
[ Upstream commit
cf34ac6aa2b12fb0c3aacfdcae8acd7904b949ec ]
The reg_node needs to be released through of_node_put() in the error
handling path when of_irq_get_byname() failed.
Fixes:
390af53e0411 ("regulator: qcom-labibb: Implement short-circuit and over-current IRQs")
Signed-off-by: Yuan Can <yuancan@huawei.com>
Link: https://lore.kernel.org/r/20221203062109.115043-1-yuancan@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhen Lei [Wed, 30 Nov 2022 13:49:20 +0000 (21:49 +0800)]
mmc: core: Normalize the error handling branch in sd_read_ext_regs()
[ Upstream commit
fc02e2b52389c8fde02852b2f959c0b45f042bbd ]
Let's use pr_err() to output the error messages and let's extend a comment
to clarify why returning 0 (success) in one case make sense.
Fixes:
c784f92769ae ("mmc: core: Read the SD function extension registers for power management")
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
[Ulf: Clarified the comment and the commit-msg]
Link: https://lore.kernel.org/r/20221130134920.2109-1-thunder.leizhen@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jiasheng Jiang [Sat, 26 Nov 2022 01:25:58 +0000 (09:25 +0800)]
memstick/ms_block: Add check for alloc_ordered_workqueue
[ Upstream commit
4f431a047a5c8698ed4b67e2760cfbeb5fffb69d ]
As the alloc_ordered_workqueue may return NULL pointer, it should be better
to add check for the return value. Moreover, the msb->io_queue should be
freed if error occurs later.
Fixes:
0ab30494bc4f ("memstick: add support for legacy memorysticks")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Link: https://lore.kernel.org/r/20221126012558.34374-1-jiasheng@iscas.ac.cn
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luis Chamberlain [Thu, 2 Sep 2021 17:40:58 +0000 (10:40 -0700)]
memstick: ms_block: Add error handling support for add_disk()
[ Upstream commit
2304c55fd506fcd5e1a59ae21a306ee82507340b ]
We never checked for errors on add_disk() as this function returned void.
Now that this is fixed, use the shiny new error handling.
Contrary to the typical removal which delays the put_disk() until later,
since we are failing on a probe we immediately put the disk on failure from
add_disk by using blk_cleanup_disk().
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Link: https://lore.kernel.org/r/20210902174105.2418771-3-mcgrof@kernel.org
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Stable-dep-of:
4f431a047a5c ("memstick/ms_block: Add check for alloc_ordered_workqueue")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wolfram Sang [Sun, 20 Nov 2022 11:34:54 +0000 (12:34 +0100)]
mmc: renesas_sdhi: alway populate SCC pointer
[ Upstream commit
3d4f9898c1c74323dd61d6a8a0efca9401232ad4 ]
We need the SCC pointer to reset the device, so populate it even when we
don't need it for tuning.
Fixes:
45bffc371fef ("mmc: renesas_sdhi: only reset SCC when its pointer is populated")
Signed-off-by: Takeshi Saito <takeshi.saito.xv@renesas.com>
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20221120113457.42010-2-wsa+renesas@sang-engineering.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 9 Nov 2022 13:35:39 +0000 (21:35 +0800)]
mmc: mmci: fix return value check of mmc_add_host()
[ Upstream commit
b38a20f29a49ae04d23750d104b25400b792b98c ]
mmc_add_host() may return error, if we ignore its return value,
it will lead two issues:
1. The memory that allocated in mmc_alloc_host() is leaked.
2. In the remove() path, mmc_remove_host() will be called to
delete device, but it's not added yet, it will lead a kernel
crash because of null-ptr-deref in device_del().
So fix this by checking the return value and goto error path which
will call mmc_free_host().
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221109133539.3275664-1-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Wed, 9 Nov 2022 13:32:37 +0000 (21:32 +0800)]
mmc: wbsd: fix return value check of mmc_add_host()
[ Upstream commit
dc5b9b50fc9d1334407e316e6e29a5097ef833bd ]
mmc_add_host() may return error, if we ignore its return value,
it will lead two issues:
1. The memory that allocated in mmc_alloc_host() is leaked.
2. In the remove() path, mmc_remove_host() will be called to
delete device, but it's not added yet, it will lead a kernel
crash because of null-ptr-deref in device_del().
So fix this by checking the return value and goto error path which
will call mmc_free_host(), besides, other resources also need be
released.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221109133237.3273558-1-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 8 Nov 2022 13:09:49 +0000 (21:09 +0800)]
mmc: via-sdmmc: fix return value check of mmc_add_host()
[ Upstream commit
e4e46fb61e3bb4628170810d3f2b996b709b90d9 ]
mmc_add_host() may return error, if we ignore its return value,
it will lead two issues:
1. The memory that allocated in mmc_alloc_host() is leaked.
2. In the remove() path, mmc_remove_host() will be called to
delete device, but it's not added yet, it will lead a kernel
crash because of null-ptr-deref in device_del().
Fix this by checking the return value and goto error path which
will call mmc_free_host().
Fixes:
f0bf7f61b840 ("mmc: Add new via-sdmmc host controller driver")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221108130949.1067699-1-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 8 Nov 2022 12:34:17 +0000 (20:34 +0800)]
mmc: meson-gx: fix return value check of mmc_add_host()
[ Upstream commit
90935f16f2650ab7416fa2ffbe5c28cb39cf3f1e ]
mmc_add_host() may return error, if we ignore its return value,
it will lead two issues:
1. The memory that allocated in mmc_alloc_host() is leaked.
2. In the remove() path, mmc_remove_host() will be called to
delete device, but it's not added yet, it will lead a kernel
crash because of null-ptr-deref in device_del().
Fix this by checking the return value and goto error path which
will call mmc_free_host().
Fixes:
51c5d8447bd7 ("MMC: meson: initial support for GX platforms")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20221108123417.479045-1-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 8 Nov 2022 12:13:16 +0000 (20:13 +0800)]
mmc: omap_hsmmc: fix return value check of mmc_add_host()
[ Upstream commit
a525cad241c339ca00bf7ebf03c5180f2a9b767c ]
mmc_add_host() may return error, if we ignore its return value,
it will lead two issues:
1. The memory that allocated in mmc_alloc_host() is leaked.
2. In the remove() path, mmc_remove_host() will be called to
delete device, but it's not added yet, it will lead a kernel
crash because of null-ptr-deref in device_del().
Fix this by checking the return value and goto error path wihch
will call mmc_free_host().
Fixes:
a45c6cb81647 ("[ARM] 5369/1: omap mmc: Add new omap hsmmc controller for 2430 and 34xx, v3")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221108121316.340354-1-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 8 Nov 2022 12:28:19 +0000 (20:28 +0800)]
mmc: atmel-mci: fix return value check of mmc_add_host()
[ Upstream commit
9e6e8c43726673ca2abcaac87640b9215fd72f4c ]
mmc_add_host() may return error, if we ignore its return value,
it will lead two issues:
1. The memory that allocated in mmc_alloc_host() is leaked.
2. In the remove() path, mmc_remove_host() will be called to
delete device, but it's not added yet, it will lead a kernel
crash because of null-ptr-deref in device_del().
So fix this by checking the return value and calling mmc_free_host()
in the error path.
Fixes:
7d2be0749a59 ("atmel-mci: Driver for Atmel on-chip MMC controllers")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221108122819.429975-1-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 1 Nov 2022 06:30:23 +0000 (14:30 +0800)]
mmc: wmt-sdmmc: fix return value check of mmc_add_host()
[ Upstream commit
29276d56f6ed138db0f38cd31aedc0b725c8c76c ]
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and goto error path which will call
mmc_free_host(), besides, clk_disable_unprepare() also needs be called.
Fixes:
3a96dff0f828 ("mmc: SD/MMC Host Controller for Wondermedia WM8505/WM8650")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221101063023.1664968-10-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 1 Nov 2022 06:30:22 +0000 (14:30 +0800)]
mmc: vub300: fix return value check of mmc_add_host()
[ Upstream commit
0613ad2401f88bdeae5594c30afe318e93b14676 ]
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and goto error path which will call
mmc_free_host(), besides, the timer added before mmc_add_host() needs be del.
And this patch fixes another missing call mmc_free_host() if usb_control_msg()
fails.
Fixes:
88095e7b473a ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221101063023.1664968-9-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 1 Nov 2022 06:30:21 +0000 (14:30 +0800)]
mmc: toshsd: fix return value check of mmc_add_host()
[ Upstream commit
f670744a316ea983113a65313dcd387b5a992444 ]
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and goto error path which will call
mmc_free_host(), besides, free_irq() also needs be called.
Fixes:
a5eb8bbd66cc ("mmc: add Toshiba PCI SD controller driver")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221101063023.1664968-8-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 1 Nov 2022 06:30:20 +0000 (14:30 +0800)]
mmc: rtsx_usb_sdmmc: fix return value check of mmc_add_host()
[ Upstream commit
fc38a5a10e9e5a75eb9189854abeb8405b214cc9 ]
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and calling mmc_free_host() in the
error path, besides, led_classdev_unregister() and pm_runtime_disable() also
need be called.
Fixes:
c7f6558d84af ("mmc: Add realtek USB sdmmc host driver")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221101063023.1664968-7-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 1 Nov 2022 06:30:19 +0000 (14:30 +0800)]
mmc: rtsx_pci: fix return value check of mmc_add_host()
[ Upstream commit
0c87db77423a282b3b38b8a6daf057b822680516 ]
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and calling mmc_free_host() in the
error path, beside, runtime PM also needs be disabled.
Fixes:
ff984e57d36e ("mmc: Add realtek pcie sdmmc host driver")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221101063023.1664968-6-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 1 Nov 2022 06:30:18 +0000 (14:30 +0800)]
mmc: pxamci: fix return value check of mmc_add_host()
[ Upstream commit
80e1ef3afb8bfbe768380b70ffe1b6cab87d1a3b ]
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and goto error path which will call
mmc_free_host(), besides, ->exit() need be called to uninit the pdata.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221101063023.1664968-5-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 1 Nov 2022 06:30:17 +0000 (14:30 +0800)]
mmc: mxcmmc: fix return value check of mmc_add_host()
[ Upstream commit
cde600af7b413c9fe03e85c58c4279df90e91d13 ]
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and goto error path which will call
mmc_free_host().
Fixes:
d96be879ff46 ("mmc: Add a MX2/MX3 specific SDHC driver")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221101063023.1664968-4-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 1 Nov 2022 06:30:16 +0000 (14:30 +0800)]
mmc: moxart: fix return value check of mmc_add_host()
[ Upstream commit
0ca18d09c744fb030ae9bc5836c3e357e0237dea ]
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and goto error path which will call
mmc_free_host().
Fixes:
1b66e94e6b99 ("mmc: moxart: Add MOXA ART SD/MMC driver")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221101063023.1664968-3-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Tue, 1 Nov 2022 06:30:15 +0000 (14:30 +0800)]
mmc: alcor: fix return value check of mmc_add_host()
[ Upstream commit
e93d1468f429475a753d6baa79b853b7ee5ef8c0 ]
mmc_add_host() may return error, if we ignore its return value, the memory
that allocated in mmc_alloc_host() will be leaked and it will lead a kernel
crash because of deleting not added device in the remove path.
So fix this by checking the return value and calling mmc_free_host() in the
error path.
Fixes:
c5413ad815a6 ("mmc: add new Alcor Micro Cardreader SD/MMC driver")
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Link: https://lore.kernel.org/r/20221101063023.1664968-2-yangyingliang@huawei.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Pu Lehui [Tue, 6 Dec 2022 09:14:10 +0000 (17:14 +0800)]
riscv, bpf: Emit fixed-length instructions for BPF_PSEUDO_FUNC
[ Upstream commit
b54b6003612a376e7be32cbc5c1af3754bbbbb3d ]
For BPF_PSEUDO_FUNC instruction, verifier will refill imm with
correct addresses of bpf_calls and then run last pass of JIT.
Since the emit_imm of RV64 is variable-length, which will emit
appropriate length instructions accorroding to the imm, it may
broke ctx->offset, and lead to unpredictable problem, such as
inaccurate jump. So let's fix it with fixed-length instructions.
Fixes:
69c087ba6225 ("bpf: Add bpf_for_each_map_elem() helper")
Suggested-by: Björn Töpel <bjorn@rivosinc.com>
Signed-off-by: Pu Lehui <pulehui@huawei.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Björn Töpel <bjorn@kernel.org>
Acked-by: Björn Töpel <bjorn@kernel.org>
Link: https://lore.kernel.org/bpf/20221206091410.1584784-1-pulehui@huaweicloud.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trond Myklebust [Tue, 6 Dec 2022 17:42:59 +0000 (12:42 -0500)]
NFSv4.x: Fail client initialisation if state manager thread can't run
[ Upstream commit
b4e4f66901658fae0614dea5bf91062a5387eda7 ]
If the state manager thread fails to start, then we should just mark the
client initialisation as failed so that other processes or threads don't
get stuck in nfs_wait_client_init_complete().
Reported-by: ChenXiaoSong <chenxiaosong2@huawei.com>
Fixes:
4697bd5e9419 ("NFSv4: Fix a race in the net namespace mount notification")
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang ShaoBo [Thu, 24 Nov 2022 09:23:42 +0000 (17:23 +0800)]
SUNRPC: Fix missing release socket in rpc_sockname()
[ Upstream commit
50fa355bc0d75911fe9d5072a5ba52cdb803aff7 ]
socket dynamically created is not released when getting an unintended
address family type in rpc_sockname(), direct to out_release for calling
sock_release().
Fixes:
2e738fdce22f ("SUNRPC: Add API to acquire source address")
Signed-off-by: Wang ShaoBo <bobo.shaobowang@huawei.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhang Xiaoxu [Sun, 20 Nov 2022 07:34:29 +0000 (15:34 +0800)]
xprtrdma: Fix regbuf data not freed in rpcrdma_req_create()
[ Upstream commit
9181f40fb2952fd59ecb75e7158620c9c669eee3 ]
If rdma receive buffer allocate failed, should call rpcrdma_regbuf_free()
to free the send buffer, otherwise, the buffer data will be leaked.
Fixes:
bb93a1ae2bf4 ("xprtrdma: Allocate req's regbufs at xprt create time")
Signed-off-by: Zhang Xiaoxu <zhangxiaoxu5@huawei.com>
Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Gaosheng Cui [Tue, 6 Dec 2022 06:10:04 +0000 (14:10 +0800)]
ALSA: mts64: fix possible null-ptr-defer in snd_mts64_interrupt
[ Upstream commit
cf2ea3c86ad90d63d1c572b43e1ca9276b0357ad ]
I got a null-ptr-defer error report when I do the following tests
on the qemu platform:
make defconfig and CONFIG_PARPORT=m, CONFIG_PARPORT_PC=m,
CONFIG_SND_MTS64=m
Then making test scripts:
cat>test_mod1.sh<<EOF
modprobe snd-mts64
modprobe snd-mts64
EOF
Executing the script, perhaps several times, we will get a null-ptr-defer
report, as follow:
syzkaller:~# ./test_mod.sh
snd_mts64: probe of snd_mts64.0 failed with error -5
modprobe: ERROR: could not insert 'snd_mts64': No such device
BUG: kernel NULL pointer dereference, address:
0000000000000000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP PTI
CPU: 0 PID: 205 Comm: modprobe Not tainted 6.1.0-rc8-00588-g76dcd734eca2 #6
Call Trace:
<IRQ>
snd_mts64_interrupt+0x24/0xa0 [snd_mts64]
parport_irq_handler+0x37/0x50 [parport]
__handle_irq_event_percpu+0x39/0x190
handle_irq_event_percpu+0xa/0x30
handle_irq_event+0x2f/0x50
handle_edge_irq+0x99/0x1b0
__common_interrupt+0x5d/0x100
common_interrupt+0xa0/0xc0
</IRQ>
<TASK>
asm_common_interrupt+0x22/0x40
RIP: 0010:_raw_write_unlock_irqrestore+0x11/0x30
parport_claim+0xbd/0x230 [parport]
snd_mts64_probe+0x14a/0x465 [snd_mts64]
platform_probe+0x3f/0xa0
really_probe+0x129/0x2c0
__driver_probe_device+0x6d/0xc0
driver_probe_device+0x1a/0xa0
__device_attach_driver+0x7a/0xb0
bus_for_each_drv+0x62/0xb0
__device_attach+0xe4/0x180
bus_probe_device+0x82/0xa0
device_add+0x550/0x920
platform_device_add+0x106/0x220
snd_mts64_attach+0x2e/0x80 [snd_mts64]
port_check+0x14/0x20 [parport]
bus_for_each_dev+0x6e/0xc0
__parport_register_driver+0x7c/0xb0 [parport]
snd_mts64_module_init+0x31/0x1000 [snd_mts64]
do_one_initcall+0x3c/0x1f0
do_init_module+0x46/0x1c6
load_module+0x1d8d/0x1e10
__do_sys_finit_module+0xa2/0xf0
do_syscall_64+0x37/0x90
entry_SYSCALL_64_after_hwframe+0x63/0xcd
</TASK>
Kernel panic - not syncing: Fatal exception in interrupt
Rebooting in 1 seconds..
The mts wa not initialized during interrupt, we add check for
mts to fix this bug.
Fixes:
68ab801e32bb ("[ALSA] Add snd-mts64 driver for ESI Miditerminal 4140")
Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
Link: https://lore.kernel.org/r/20221206061004.1222966-1-cuigaosheng1@huawei.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Liu Shixin [Sat, 26 Nov 2022 11:31:26 +0000 (11:31 +0000)]
media: saa7164: fix missing pci_disable_device()
[ Upstream commit
57fb35d7542384cac8f198cd1c927540ad38b61a ]
Add missing pci_disable_device() in the error path in saa7164_initdev().
Fixes:
443c1228d505 ("V4L/DVB (12923): SAA7164: Add support for the NXP SAA7164 silicon")
Signed-off-by: Liu Shixin <liushixin2@huawei.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Takashi Iwai [Mon, 5 Dec 2022 13:21:22 +0000 (14:21 +0100)]
ALSA: pcm: Set missing stop_operating flag at undoing trigger start
[ Upstream commit
5c8cc93b06d1ff860327a273abf3ac006290d242 ]
When a PCM trigger-start fails at snd_pcm_do_start(), PCM core tries
to undo the action at snd_pcm_undo_start() by issuing the trigger STOP
manually. At that point, we forgot to set the stop_operating flag,
hence the sync-stop won't be issued at the next prepare or other
calls.
This patch adds the missing stop_operating flag at
snd_pcm_undo_start().
Fixes:
1e850beea278 ("ALSA: pcm: Add the support for sync-stop operation")
Link: https://lore.kernel.org/r/b4e71631-4a94-613-27b2-fb595792630@carlh.net
Link: https://lore.kernel.org/r/20221205132124.11585-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
projects / platform / kernel / linux-rpi.git / log