- Jan 14, 2023
-
-
Yuan Can authored
[ Upstream commit 7a4efe18 ] A problem about modprobe vhost_vsock failed is triggered with the following log given: modprobe: ERROR: could not insert 'vhost_vsock': Device or resource busy The reason is that vhost_vsock_init() returns misc_register() directly without checking its return value, if misc_register() failed, it returns without calling vsock_core_unregister() on vhost_transport, resulting the vhost_vsock can never be installed later. A simple call graph is shown as below: vhost_vsock_init() vsock_core_register() # register vhost_transport misc_register() device_create_with_groups() device_create_groups_vargs() dev = kzalloc(...) # OOM happened # return without unregister vhost_transport Fix by calling vsock_core_unregister() when misc_register() returns error. Fixes: 433fc58e ("VSOCK: Introduce vhost_vsock.ko") Signed-off-by:
Yuan Can <yuancan@huawei.com> Message-Id: <20221108101705.45981-1-yuancan@huawei.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Reviewed-by:
Stefano Garzarella <sgarzare@redhat.com> Acked-by:
Jason Wang <jasowang@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Miaoqian Lin authored
[ Upstream commit df49908f ] nfc_get_device() take reference for the device, add missing nfc_put_device() to release it when not need anymore. Also fix the style warnning by use error EOPNOTSUPP instead of ENOTSUPP. Fixes: 5ce3f32b ("NFC: netlink: SE API implementation") Fixes: 29e76924 ("nfc: netlink: Add capability to reply to vendor_cmd with data") Signed-off-by:
Miaoqian Lin <linmq006@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Daniil Tatianin authored
[ Upstream commit 13a7c896 ] adapter->dcb would get silently freed inside qlcnic_dcb_enable() in case qlcnic_dcb_attach() would return an error, which always happens under OOM conditions. This would lead to use-after-free because both of the existing callers invoke qlcnic_dcb_get_info() on the obtained pointer, which is potentially freed at that point. Propagate errors from qlcnic_dcb_enable(), and instead free the dcb pointer at callsite using qlcnic_dcb_free(). This also removes the now unused qlcnic_clear_dcb_ops() helper, which was a simple wrapper around kfree() also causing memory leaks for partially initialized dcb. Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool. Fixes: 3c44bba1 ("qlcnic: Disable DCB operations from SR-IOV VFs") Reviewed-by:
Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Signed-off-by:
Daniil Tatianin <d-tatianin@yandex-team.ru> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Hawkins Jiawei authored
[ Upstream commit 399ab7fe ] Syzkaller reports a memory leak as follows: ==================================== BUG: memory leak unreferenced object 0xffff88810c287f00 (size 256): comm "syz-executor105", pid 3600, jiffies 4294943292 (age 12.990s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814cf9f0>] kmalloc_trace+0x20/0x90 mm/slab_common.c:1046 [<ffffffff839c9e07>] kmalloc include/linux/slab.h:576 [inline] [<ffffffff839c9e07>] kmalloc_array include/linux/slab.h:627 [inline] [<ffffffff839c9e07>] kcalloc include/linux/slab.h:659 [inline] [<ffffffff839c9e07>] tcf_exts_init include/net/pkt_cls.h:250 [inline] [<ffffffff839c9e07>] tcindex_set_parms+0xa7/0xbe0 net/sched/cls_tcindex.c:342 [<ffffffff839caa1f>] tcindex_change+0xdf/0x120 net/sched/cls_tcindex.c:553 [<ffffffff8394db62>] tc_new_tfilter+0x4f2/0x1100 net/sched/cls_api.c:2147 [<ffffffff8389e91c>] rtnetlink_rcv_msg+0x4dc/0x5d0 net/core/rtnetlink.c:6082 [<ffffffff839eba67>] netlink_rcv_skb+0x87/0x1d0 net/netlink/af_netlink.c:2540 [<ffffffff839eab87>] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] [<ffffffff839eab87>] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345 [<ffffffff839eb046>] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921 [<ffffffff8383e796>] sock_sendmsg_nosec net/socket.c:714 [inline] [<ffffffff8383e796>] sock_sendmsg+0x56/0x80 net/socket.c:734 [<ffffffff8383eb08>] ____sys_sendmsg+0x178/0x410 net/socket.c:2482 [<ffffffff83843678>] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536 [<ffffffff838439c5>] __sys_sendmmsg+0x105/0x330 net/socket.c:2622 [<ffffffff83843c14>] __do_sys_sendmmsg net/socket.c:2651 [inline] [<ffffffff83843c14>] __se_sys_sendmmsg net/socket.c:2648 [inline] [<ffffffff83843c14>] __x64_sys_sendmmsg+0x24/0x30 net/socket.c:2648 [<ffffffff84605fd5>] do_syscall_x64 arch/x86/entry/common.c:50 [inline] [<ffffffff84605fd5>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84800087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd ==================================== Kernel uses tcindex_change() to change an existing filter properties. Yet the problem is that, during the process of changing, if `old_r` is retrieved from `p->perfect`, then kernel uses tcindex_alloc_perfect_hash() to newly allocate filter results, uses tcindex_filter_result_init() to clear the old filter result, without destroying its tcf_exts structure, which triggers the above memory leak. To be more specific, there are only two source for the `old_r`, according to the tcindex_lookup(). `old_r` is retrieved from `p->perfect`, or `old_r` is retrieved from `p->h`. * If `old_r` is retrieved from `p->perfect`, kernel uses tcindex_alloc_perfect_hash() to newly allocate the filter results. Then `r` is assigned with `cp->perfect + handle`, which is newly allocated. So condition `old_r && old_r != r` is true in this situation, and kernel uses tcindex_filter_result_init() to clear the old filter result, without destroying its tcf_exts structure * If `old_r` is retrieved from `p->h`, then `p->perfect` is NULL according to the tcindex_lookup(). Considering that `cp->h` is directly copied from `p->h` and `p->perfect` is NULL, `r` is assigned with `tcindex_lookup(cp, handle)`, whose value should be the same as `old_r`, so condition `old_r && old_r != r` is false in this situation, kernel ignores using tcindex_filter_result_init() to clear the old filter result. So only when `old_r` is retrieved from `p->perfect` does kernel use tcindex_filter_result_init() to clear the old filter result, which triggers the above memory leak. Considering that there already exists a tc_filter_wq workqueue to destroy the old tcindex_data by tcindex_partial_destroy_work() at the end of tcindex_set_parms(), this patch solves this memory leak bug by removing this old filter result clearing part and delegating it to the tc_filter_wq workqueue. Note that this patch doesn't introduce any other issues. If `old_r` is retrieved from `p->perfect`, this patch just delegates old filter result clearing part to the tc_filter_wq workqueue; If `old_r` is retrieved from `p->h`, kernel doesn't reach the old filter result clearing part, so removing this part has no effect. [Thanks to the suggestion from Jakub Kicinski, Cong Wang, Paolo Abeni and Dmitry Vyukov] Fixes: b9a24bb7 ("net_sched: properly handle failure case of tcf_exts_init()") Link: https://lore.kernel.org/all/0000000000001de5c505ebc9ec59@google.com/ Reported-by:
<syzbot+232ebdbd36706c965ebf@syzkaller.appspotmail.com> Tested-by:
<syzbot+232ebdbd36706c965ebf@syzkaller.appspotmail.com> Cc: Cong Wang <cong.wang@bytedance.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Dmitry Vyukov <dvyukov@google.com> Acked-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Hawkins Jiawei <yin31149@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jie Wang authored
[ Upstream commit 09e6b30e ] Currently keep alive message between PF and VF may be lost and the VF is unalive in PF. So the VF will not do reset during PF FLR reset process. This would make the allocated interrupt resources of VF invalid and VF would't receive or respond to PF any more. So this patch adds VF interrupts re-initialization during VF FLR for VF recovery in above cases. Fixes: 862d969a ("net: hns3: do VF's pci re-initialization while PF doing FLR") Signed-off-by:
Jie Wang <wangjie125@huawei.com> Signed-off-by:
Hao Lan <lanhao@huawei.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jeff Layton authored
[ Upstream commit 789e1e10 ] Currently, we shut down the filecache before trying to clean up the stateids that depend on it. This leads to the kernel trying to free an nfsd_file twice, and a refcount overput on the nf_mark. Change the shutdown procedure to tear down all of the stateids prior to shutting down the filecache. Reported-and-tested-by:
Wang Yugui <wangyugui@e16-tech.com> Signed-off-by:
Jeff Layton <jlayton@kernel.org> Fixes: 5e113224 ("nfsd: nfsd_file cache entries should be per net namespace") Signed-off-by:
Chuck Lever <chuck.lever@oracle.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Shawn Bohrer authored
[ Upstream commit fa349e39 ] When AF_XDP is used on on a veth interface the RX ring is updated in two steps. veth_xdp_rcv() removes packet descriptors from the FILL ring fills them and places them in the RX ring updating the cached_prod pointer. Later xdp_do_flush() syncs the RX ring prod pointer with the cached_prod pointer allowing user-space to see the recently filled in descriptors. The rings are intended to be SPSC, however the existing order in veth_poll allows the xdp_do_flush() to run concurrently with another CPU creating a race condition that allows user-space to see old or uninitialized descriptors in the RX ring. This bug has been observed in production systems. To summarize, we are expecting this ordering: CPU 0 __xsk_rcv_zc() CPU 0 __xsk_map_flush() CPU 2 __xsk_rcv_zc() CPU 2 __xsk_map_flush() But we are seeing this order: CPU 0 __xsk_rcv_zc() CPU 2 __xsk_rcv_zc() CPU 0 __xsk_map_flush() CPU 2 __xsk_map_flush() This occurs because we rely on NAPI to ensure that only one napi_poll handler is running at a time for the given veth receive queue. napi_schedule_prep() will prevent multiple instances from getting scheduled. However calling napi_complete_done() signals that this napi_poll is complete and allows subsequent calls to napi_schedule_prep() and __napi_schedule() to succeed in scheduling a concurrent napi_poll before the xdp_do_flush() has been called. For the veth driver a concurrent call to napi_schedule_prep() and __napi_schedule() can occur on a different CPU because the veth xmit path can additionally schedule a napi_poll creating the race. The fix as suggested by Magnus Karlsson, is to simply move the xdp_do_flush() call before napi_complete_done(). This syncs the producer ring pointers before another instance of napi_poll can be scheduled on another CPU. It will also slightly improve performance by moving the flush closer to when the descriptors were placed in the RX ring. Fixes: d1396004 ("veth: Add XDP TX and REDIRECT") Suggested-by:
Magnus Karlsson <magnus.karlsson@gmail.com> Signed-off-by:
Shawn Bohrer <sbohrer@cloudflare.com> Link: https://lore.kernel.org/r/20221220185903.1105011-1-sbohrer@cloudflare.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ronak Doshi authored
[ Upstream commit 3d8f2c42 ] Commit dacce2be ("vmxnet3: add geneve and vxlan tunnel offload support") added support for encapsulation offload. However, the pathc did not report correctly the csum_level for encapsulated packet. This patch fixes this issue by reporting correct csum level for the encapsulated packet. Fixes: dacce2be ("vmxnet3: add geneve and vxlan tunnel offload support") Signed-off-by:
Ronak Doshi <doshir@vmware.com> Acked-by:
Peng Li <lpeng@vmware.com> Link: https://lore.kernel.org/r/20221220202556.24421-1-doshir@vmware.com Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Steven Price authored
[ Upstream commit 4217c6ac ] panfrost_gem_create_with_handle() previously returned a BO but with the only reference being from the handle, which user space could in theory guess and release, causing a use-after-free. Additionally if the call to panfrost_gem_mapping_get() in panfrost_ioctl_create_bo() failed then a(nother) reference on the BO was dropped. The _create_with_handle() is a problematic pattern, so ditch it and instead create the handle in panfrost_ioctl_create_bo(). If the call to panfrost_gem_mapping_get() fails then this means that user space has indeed gone behind our back and freed the handle. In which case just return an error code. Reported-by:
Rob Clark <robdclark@chromium.org> Fixes: f3ba9122 ("drm/panfrost: Add initial panfrost driver") Signed-off-by:
Steven Price <steven.price@arm.com> Reviewed-by:
Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221219140130.410578-1-steven.price@arm.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jakub Kicinski authored
[ Upstream commit 54c3f1a8 ] Anand hit a BUG() when pulling off headers on egress to a SW tunnel. We get to skb_checksum_help() with an invalid checksum offset (commit d7ea0d9d ("net: remove two BUG() from skb_checksum_help()") converted those BUGs to WARN_ONs()). He points out oddness in how skb_postpull_rcsum() gets used. Indeed looks like we should pull before "postpull", otherwise the CHECKSUM_PARTIAL fixup from skb_postpull_rcsum() will not be able to do its job: if (skb->ip_summed == CHECKSUM_PARTIAL && skb_checksum_start_offset(skb) < 0) skb->ip_summed = CHECKSUM_NONE; Reported-by:
Anand Parthasarathy <anpartha@meta.com> Fixes: 6578171a ("bpf: add bpf_skb_change_proto helper") Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Acked-by:
Stanislav Fomichev <sdf@google.com> Link: https://lore.kernel.org/r/20221220004701.402165-1-kuba@kernel.org Signed-off-by:
Martin KaFai Lau <martin.lau@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
minoura makoto authored
[ Upstream commit b18cba09 ] Commit 9130b8db ("SUNRPC: allow for upcalls for the same uid but different gss service") introduced `auth` argument to __gss_find_upcall(), but in gss_pipe_downcall() it was left as NULL since it (and auth->service) was not (yet) determined. When multiple upcalls with the same uid and different service are ongoing, it could happen that __gss_find_upcall(), which returns the first match found in the pipe->in_downcall list, could not find the correct gss_msg corresponding to the downcall we are looking for. Moreover, it might return a msg which is not sent to rpc.gssd yet. We could see mount.nfs process hung in D state with multiple mount.nfs are executed in parallel. The call trace below is of CentOS 7.9 kernel-3.10.0-1160.24.1.el7.x86_64 but we observed the same hang w/ elrepo kernel-ml-6.0.7-1.el7. PID: 71258 TASK: ffff91ebd4be0000 CPU: 36 COMMAND: "mount.nfs" #0 [ffff9203ca3234f8] __schedule at ffffffffa3b8899f #1 [ffff9203ca323580] schedule at ffffffffa3b88eb9 #2 [ffff9203ca323590] gss_cred_init at ffffffffc0355818 [auth_rpcgss] #3 [ffff9203ca323658] rpcauth_lookup_credcache at ffffffffc0421ebc [sunrpc] #4 [ffff9203ca3236d8] gss_lookup_cred at ffffffffc0353633 [auth_rpcgss] #5 [ffff9203ca3236e8] rpcauth_lookupcred at ffffffffc0421581 [sunrpc] #6 [ffff9203ca323740] rpcauth_refreshcred at ffffffffc04223d3 [sunrpc] #7 [ffff9203ca3237a0] call_refresh at ffffffffc04103dc [sunrpc] #8 [ffff9203ca3237b8] __rpc_execute at ffffffffc041e1c9 [sunrpc] #9 [ffff9203ca323820] rpc_execute at ffffffffc0420a48 [sunrpc] The scenario is like this. Let's say there are two upcalls for services A and B, A -> B in pipe->in_downcall, B -> A in pipe->pipe. When rpc.gssd reads pipe to get the upcall msg corresponding to service B from pipe->pipe and then writes the response, in gss_pipe_downcall the msg corresponding to service A will be picked because only uid is used to find the msg and it is before the one for B in pipe->in_downcall. And the process waiting for the msg corresponding to service A will be woken up. Actual scheduing of that process might be after rpc.gssd processes the next msg. In rpc_pipe_generic_upcall it clears msg->errno (for A). The process is scheduled to see gss_msg->ctx == NULL and gss_msg->msg.errno == 0, therefore it cannot break the loop in gss_create_upcall and is never woken up after that. This patch adds a simple check to ensure that a msg which is not sent to rpc.gssd yet is not chosen as the matching upcall upon receiving a downcall. Signed-off-by:
minoura makoto <minoura@valinux.co.jp> Signed-off-by:
Hiroshi Shimamoto <h-shimamoto@nec.com> Tested-by:
Hiroshi Shimamoto <h-shimamoto@nec.com> Cc: Trond Myklebust <trondmy@hammerspace.com> Fixes: 9130b8db ("SUNRPC: allow for upcalls for same uid but different gss service") Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jan Kara authored
[ Upstream commit a44e84a9 ] When manipulating xattr blocks, we can deadlock infinitely looping inside ext4_xattr_block_set() where we constantly keep finding xattr block for reuse in mbcache but we are unable to reuse it because its reference count is too big. This happens because cache entry for the xattr block is marked as reusable (e_reusable set) although its reference count is too big. When this inconsistency happens, this inconsistent state is kept indefinitely and so ext4_xattr_block_set() keeps retrying indefinitely. The inconsistent state is caused by non-atomic update of e_reusable bit. e_reusable is part of a bitfield and e_reusable update can race with update of e_referenced bit in the same bitfield resulting in loss of one of the updates. Fix the problem by using atomic bitops instead. This bug has been around for many years, but it became *much* easier to hit after commit 65f8b800 ("ext4: fix race when reusing xattr blocks"). Cc: stable@vger.kernel.org Fixes: 6048c64b ("mbcache: add reusable flag to cache entries") Fixes: 65f8b800 ("ext4: fix race when reusing xattr blocks") Reported-and-tested-by:
Jeremi Piotrowski <jpiotrowski@linux.microsoft.com> Reported-by:
Thilo Fromm <t-lo@linux.microsoft.com> Link: https://lore.kernel.org/r/c77bf00f-4618-7149-56f1-b8d1664b9d07@linux.microsoft.com/ Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Link: https://lore.kernel.org/r/20221123193950.16758-1-jack@suse.cz Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jan Kara authored
[ Upstream commit 307af6c8 ] Use the fact that entries with elevated refcount are not removed from the hash and just move removal of the entry from the hash to the entry freeing time. When doing this we also change the generic code to hold one reference to the cache entry, not two of them, which makes code somewhat more obvious. Signed-off-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220712105436.32204-10-jack@suse.cz Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Stable-dep-of: a44e84a9 ("ext4: fix deadlock due to mbcache entry corruption") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jan Kara authored
[ Upstream commit 65f8b800 ] When ext4_xattr_block_set() decides to remove xattr block the following race can happen: CPU1 CPU2 ext4_xattr_block_set() ext4_xattr_release_block() new_bh = ext4_xattr_block_cache_find() lock_buffer(bh); ref = le32_to_cpu(BHDR(bh)->h_refcount); if (ref == 1) { ... mb_cache_entry_delete(); unlock_buffer(bh); ext4_free_blocks(); ... ext4_forget(..., bh, ...); jbd2_journal_revoke(..., bh); ext4_journal_get_write_access(..., new_bh, ...) do_get_write_access() jbd2_journal_cancel_revoke(..., new_bh); Later the code in ext4_xattr_block_set() finds out the block got freed and cancels reusal of the block but the revoke stays canceled and so in case of block reuse and journal replay the filesystem can get corrupted. If the race works out slightly differently, we can also hit assertions in the jbd2 code. Fix the problem by making sure that once matching mbcache entry is found, code dropping the last xattr block reference (or trying to modify xattr block in place) waits until the mbcache entry reference is dropped. This way code trying to reuse xattr block is protected from someone trying to drop the last reference to xattr block. Reported-and-tested-by:
Ritesh Harjani <ritesh.list@gmail.com> CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220712105436.32204-5-jack@suse.cz Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Stable-dep-of: a44e84a9 ("ext4: fix deadlock due to mbcache entry corruption") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jan Kara authored
[ Upstream commit fd48e9ac ] Remove unnecessary else (and thus indentation level) from a code block in ext4_xattr_block_set(). It will also make following code changes easier. No functional changes. CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220712105436.32204-4-jack@suse.cz Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Stable-dep-of: a44e84a9 ("ext4: fix deadlock due to mbcache entry corruption") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jan Kara authored
[ Upstream commit 6bc0d63d ] Currently we remove EA inode from mbcache as soon as its xattr refcount drops to zero. However there can be pending attempts to reuse the inode and thus refcount handling code has to handle the situation when refcount increases from zero anyway. So save some work and just keep EA inode in mbcache until it is getting evicted. At that moment we are sure following iget() of EA inode will fail anyway (or wait for eviction to finish and load things from the disk again) and so removing mbcache entry at that moment is fine and simplifies the code a bit. CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220712105436.32204-3-jack@suse.cz Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Stable-dep-of: a44e84a9 ("ext4: fix deadlock due to mbcache entry corruption") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jan Kara authored
[ Upstream commit 3dc96bba ] Add function mb_cache_entry_delete_or_get() to delete mbcache entry if it is unused and also add a function to wait for entry to become unused - mb_cache_entry_wait_unused(). We do not share code between the two deleting function as one of them will go away soon. CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220712105436.32204-2-jack@suse.cz Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Stable-dep-of: a44e84a9 ("ext4: fix deadlock due to mbcache entry corruption") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jan Kara authored
[ Upstream commit 58318914 ] Do not reclaim entries that are currently used by somebody from a shrinker. Firstly, these entries are likely useful. Secondly, we will need to keep such entries to protect pending increment of xattr block refcount. CC: stable@vger.kernel.org Fixes: 82939d79 ("ext4: convert to mbcache2") Signed-off-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20220712105436.32204-1-jack@suse.cz Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Stable-dep-of: a44e84a9 ("ext4: fix deadlock due to mbcache entry corruption") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Shuqi Zhang authored
[ Upstream commit 4efd9f0d ] Replace kmalloc + memcpy with kmemdup() Signed-off-by:
Shuqi Zhang <zhangshuqi3@huawei.com> Reviewed-by:
Ritesh Harjani <ritesh.list@gmail.com> Link: https://lore.kernel.org/r/20220525030120.803330-1-zhangshuqi3@huawei.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Stable-dep-of: a44e84a9 ("ext4: fix deadlock due to mbcache entry corruption") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Eric Biggers authored
[ Upstream commit 594bc43b ] When space at the end of fast-commit journal blocks is unused, make sure to zero it out so that uninitialized memory is not leaked to disk. Fixes: aa75f4d3 ("ext4: main fast-commit commit path") Cc: <stable@vger.kernel.org> # v5.10+ Signed-off-by:
Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20221106224841.279231-4-ebiggers@kernel.org Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Bhaskar Chowdhury authored
[ Upstream commit 3088e5a5 ] Signed-off-by:
Bhaskar Chowdhury <unixbhaskar@gmail.com> Link: https://lore.kernel.org/r/cover.1616840203.git.unixbhaskar@gmail.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jan Kara authored
[ Upstream commit 02a7780e ] We convert errno's to ext4 on-disk format error codes in save_error_info(). Add a function and a bit of macro magic to make this simpler. Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Link: https://lore.kernel.org/r/20201127113405.26867-7-jack@suse.cz Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jan Kara authored
[ Upstream commit 40676623 ] Just move error info related functions in super.c close to ext4_handle_error(). We'll want to combine save_error_info() with ext4_handle_error() and this makes change more obvious and saves a forward declaration as well. No functional change. Signed-off-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Andreas Dilger <adilger@dilger.ca> Link: https://lore.kernel.org/r/20201127113405.26867-6-jack@suse.cz Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Alexander Potapenko authored
[ Upstream commit 956510c0 ] When aops->write_begin() does not initialize fsdata, KMSAN reports an error passing the latter to aops->write_end(). Fix this by unconditionally initializing fsdata. Cc: Eric Biggers <ebiggers@kernel.org> Fixes: c93d8f88 ("ext4: add basic fs-verity support") Reported-by:
<syzbot+9767be679ef5016b6082@syzkaller.appspotmail.com> Signed-off-by:
Alexander Potapenko <glider@google.com> Reviewed-by:
Eric Biggers <ebiggers@google.com> Link: https://lore.kernel.org/r/20221121112134.407362-1-glider@google.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chaitanya Kulkarni authored
[ Upstream commit bd256fda ] Signed-off-by:
Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Link: https://lore.kernel.org/r/20210207190425.38107-7-chaitanya.kulkarni@wdc.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Stable-dep-of: 956510c0 ("fs: ext4: initialize fsdata in pagecache_write()") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Ira Weiny authored
[ Upstream commit bb90d4bc ] Working through a conversion to a call kmap_local_page() instead of kmap() revealed many places where the pattern kmap/memcpy/kunmap occurred. Eric Biggers, Matthew Wilcox, Christoph Hellwig, Dan Williams, and Al Viro all suggested putting this code into helper functions. Al Viro further pointed out that these functions already existed in the iov_iter code.[1] Various locations for the lifted functions were considered. Headers like mm.h or string.h seem ok but don't really portray the functionality well. pagemap.h made some sense but is for page cache functionality.[2] Another alternative would be to create a new header for the promoted memcpy functions, but it masks the fact that these are designed to copy to/from pages using the kernel direct mappings and complicates matters with a new header. Placing these functions in 'highmem.h' is suboptimal especially with the changes being proposed in the functionality of kmap. From a caller perspective including/using 'highmem.h' implies that the functions defined in that header are only required when highmem is in use which is increasingly not the case with modern processors. However, highmem.h is where all the current functions like this reside (zero_user(), clear_highpage(), clear_user_highpage(), copy_user_highpage(), and copy_highpage()). So it makes the most sense even though it is distasteful for some.[3] Lift memcpy_to_page() and memcpy_from_page() to pagemap.h. [1] https://lore.kernel.org/lkml/20201013200149.GI3576660@ZenIV.linux.org.uk/ https://lore.kernel.org/lkml/20201013112544.GA5249@infradead.org/ [2] https://lore.kernel.org/lkml/20201208122316.GH7338@casper.infradead.org/ [3] https://lore.kernel.org/lkml/20201013200149.GI3576660@ZenIV.linux.org.uk/#t https://lore.kernel.org/lkml/20201208163814.GN1563847@iweiny-DESK2.sc.intel.com/ Cc: Boris Pismenny <borisp@mellanox.com> Cc: Or Gerlitz <gerlitz.or@gmail.com> Cc: Dave Hansen <dave.hansen@intel.com> Suggested-by:
Matthew Wilcox <willy@infradead.org> Suggested-by:
Christoph Hellwig <hch@infradead.org> Suggested-by:
Dan Williams <dan.j.williams@intel.com> Suggested-by:
Al Viro <viro@zeniv.linux.org.uk> Suggested-by:
Eric Biggers <ebiggers@kernel.org> Reviewed-by:
Chaitanya Kulkarni <chaitanya.kulkarni@wdc.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Ira Weiny <ira.weiny@intel.com> Signed-off-by:
David Sterba <dsterba@suse.com> Stable-dep-of: 956510c0 ("fs: ext4: initialize fsdata in pagecache_write()") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Baokun Li authored
[ Upstream commit 89481b5f ] When we used the journal_async_commit mounting option in nojournal mode, the kernel told me that "can't mount with journal_checksum", was very confusing. I find that when we mount with journal_async_commit, both the JOURNAL_ASYNC_COMMIT and EXPLICIT_JOURNAL_CHECKSUM flags are set. However, in the error branch, CHECKSUM is checked before ASYNC_COMMIT. As a result, the above inconsistency occurs, and the ASYNC_COMMIT branch becomes dead code that cannot be executed. Therefore, we exchange the positions of the two judgments to make the error msg more accurate. Signed-off-by:
Baokun Li <libaokun1@huawei.com> Reviewed-by:
Jan Kara <jack@suse.cz> Link: https://lore.kernel.org/r/20221109074343.4184862-1-libaokun1@huawei.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Cc: stable@kernel.org Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Jason Yan authored
[ Upstream commit 43bd6f1b ] Before these two branches neither loaded the journal nor created the xattr cache. So the right label to goto is 'failed_mount3a'. Although this did not cause any issues because the error handler validated if the pointer is null. However this still made me confused when reading the code. So it's still worth to modify to goto the right label. Signed-off-by:
Jason Yan <yanaijie@huawei.com> Reviewed-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Ritesh Harjani (IBM) <ritesh.list@gmail.com> Link: https://lore.kernel.org/r/20220916141527.1012715-2-yanaijie@huawei.com Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Stable-dep-of: 89481b5f ("ext4: correct inconsistent error msg in nojournal mode") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Guo Ren authored
[ Upstream commit 5c3022e4 ] The 'retp' is a pointer to the return address on the stack, so we must pass the current return address pointer as the 'retp' argument to ftrace_push_return_trace(). Not parent function's return address on the stack. Fixes: b785ec12 ("riscv/ftrace: Add HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support") Signed-off-by:
Guo Ren <guoren@linux.alibaba.com> Signed-off-by:
Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20221109064937.3643993-2-guoren@kernel.org Cc: stable@vger.kernel.org Signed-off-by:
Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Chen Huang authored
[ Upstream commit f766f77a ] When a function doesn't have a callee, then it will not push ra into the stack, such as lkdtm_BUG() function, addi sp,sp,-16 sd s0,8(sp) addi s0,sp,16 ebreak The struct stackframe use {fp,ra} to get information from stack, if walk_stackframe() with pr_regs, we will obtain wrong value and bad stacktrace, [<ffffffe00066c56c>] lkdtm_BUG+0x6/0x8 ---[ end trace 18da3fbdf08e25d5 ]--- Correct the next fp and pc, after that, full stacktrace shown as expects, [<ffffffe00066c56c>] lkdtm_BUG+0x6/0x8 [<ffffffe0008b24a4>] lkdtm_do_action+0x14/0x1c [<ffffffe00066c372>] direct_entry+0xc0/0x10a [<ffffffe000439f86>] full_proxy_write+0x42/0x6a [<ffffffe000309626>] vfs_write+0x7e/0x214 [<ffffffe00030992a>] ksys_write+0x98/0xc0 [<ffffffe000309960>] sys_write+0xe/0x16 [<ffffffe0002014bc>] ret_from_syscall+0x0/0x2 ---[ end trace 61917f3d9a9fadcd ]--- Signed-off-by:
Chen Huang <chenhuang5@huawei.com> Signed-off-by:
Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by:
Palmer Dabbelt <palmerdabbelt@google.com> Stable-dep-of: 5c3022e4 ("riscv: stacktrace: Fixup ftrace_graph_ret_addr retp argument") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Biju Das authored
[ Upstream commit c72a7e42 ] This patch fixes the error "ravb 11c20000.ethernet eth0: failed to switch device to config mode" during unbind. We are doing register access after pm_runtime_put_sync(). We usually do cleanup in reverse order of init. Currently in remove(), the "pm_runtime_put_sync" is not in reverse order. Probe reset_control_deassert(rstc); pm_runtime_enable(&pdev->dev); pm_runtime_get_sync(&pdev->dev); remove pm_runtime_put_sync(&pdev->dev); unregister_netdev(ndev); .. ravb_mdio_release(priv); pm_runtime_disable(&pdev->dev); Consider the call to unregister_netdev() unregister_netdev->unregister_netdevice_queue->rollback_registered_many that calls the below functions which access the registers after pm_runtime_put_sync() 1) ravb_get_stats 2) ravb_close Fixes: c156633f ("Renesas Ethernet AVB driver proper") Cc: stable@vger.kernel.org Signed-off-by:
Biju Das <biju.das.jz@bp.renesas.com> Reviewed-by:
Leon Romanovsky <leonro@nvidia.com> Link: https://lore.kernel.org/r/20221214105118.2495313-1-biju.das.jz@bp.renesas.com Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Luca Ceresoli authored
[ Upstream commit c4d34416 ] At probe time this code path is followed: * tegra_csi_init * tegra_csi_channels_alloc * for_each_child_of_node(node, channel) -- iterates over channels * automatically gets 'channel' * tegra_csi_channel_alloc() * saves into chan->of_node a pointer to the channel OF node * automatically gets and puts 'channel' * now the node saved in chan->of_node has refcount 0, can disappear * tegra_csi_channels_init * iterates over channels * tegra_csi_channel_init -- uses chan->of_node After that, chan->of_node keeps storing the node until the device is removed. of_node_get() the node and of_node_put() it during teardown to avoid any risk. Fixes: 1ebaeb09 ("media: tegra-video: Add support for external sensor capture") Cc: stable@vger.kernel.org Cc: Sowjanya Komatineni <skomatineni@nvidia.com> Signed-off-by:
Luca Ceresoli <luca.ceresoli@bootlin.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Masami Hiramatsu (Google) authored
[ Upstream commit 63dc6325 ] Since the CONFIG_RETHUNK and CONFIG_SLS will use INT3 for stopping speculative execution after function return, kprobe jump optimization always fails on the functions with such INT3 inside the function body. (It already checks the INT3 padding between functions, but not inside the function) To avoid this issue, as same as kprobes, check whether the INT3 comes from kgdb or not, and if so, stop decoding and make it fail. The other INT3 will come from CONFIG_RETHUNK/CONFIG_SLS and those can be treated as a one-byte instruction. Fixes: e463a09a ("x86: Add straight-line-speculation mitigation") Suggested-by:
Peter Zijlstra <peterz@infradead.org> Signed-off-by:
Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/167146051929.1374301.7419382929328081706.stgit@devnote3 Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Borislav Petkov authored
[ Upstream commit 77e768ec ] Simplify code, improve decoding error checking. Signed-off-by:
Borislav Petkov <bp@suse.de> Acked-by:
Masami Hiramatsu <mhiramat@kernel.org> Link: https://lkml.kernel.org/r/20210304174237.31945-12-bp@alien8.de Stable-dep-of: 63dc6325 ("x86/kprobes: Fix optprobe optimization check with CONFIG_RETHUNK") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Masami Hiramatsu (Google) authored
[ Upstream commit a9dfc46c ] DWARF version 5 standard Sec 2.14 says that Any debugging information entry representing the declaration of an object, module, subprogram or type may have DW_AT_decl_file, DW_AT_decl_line and DW_AT_decl_column attributes, each of whose value is an unsigned integer constant. So it should be an unsigned integer data. Also, even though the standard doesn't clearly say the DW_AT_call_file is signed or unsigned, the elfutils (eu-readelf) interprets it as unsigned integer data and it is natural to handle it as unsigned integer data as same as DW_AT_decl_file. This changes the DW_AT_call_file as unsigned integer data too. Fixes: 3f4460a2 ("perf probe: Filter out redundant inline-instances") Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Acked-by:
Namhyung Kim <namhyung@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: stable@vger.kernel.org Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/166761727445.480106.3738447577082071942.stgit@devnote3 Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Masami Hiramatsu (Google) authored
[ Upstream commit f828929a ] Use dwarf_attr_integrate() instead of dwarf_attr() for generic attribute acccessor functions, so that it can find the specified attribute from abstact origin DIE etc. Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Acked-by:
Namhyung Kim <namhyung@kernel.org> Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/166731051988.2100653.13595339994343449770.stgit@devnote3 Signed-off-by:
Arnaldo Carvalho de Melo <acme@redhat.com> Stable-dep-of: a9dfc46c ("perf probe: Fix to get the DW_AT_decl_file and DW_AT_call_file as unsinged data") Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Smitha T Murthy authored
[ Upstream commit 06710cd5 ] Few of the H264 encoder registers written were not getting reflected since the read values were not stored and getting overwritten. Fixes: 6a9c6f68 ("[media] s5p-mfc: Add variants to access mfc registers") Cc: stable@vger.kernel.org Cc: linux-fsd@tesla.com Signed-off-by:
Smitha T Murthy <smitha.t@samsung.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Smitha T Murthy authored
[ Upstream commit d3f3c2fe ] During error on CLOSE_INSTANCE command, ctx_work_bits was not getting cleared. During consequent mfc execution NULL pointer dereferencing of this context led to kernel panic. This patch fixes this issue by making sure to clear ctx_work_bits always. Fixes: 818cd91a ("[media] s5p-mfc: Extract open/close MFC instance commands") Cc: stable@vger.kernel.org Cc: linux-fsd@tesla.com Signed-off-by:
Smitha T Murthy <smitha.t@samsung.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Smitha T Murthy authored
[ Upstream commit d8a46bc4 ] On receiving last buffer driver puts MFC to MFCINST_FINISHING state which in turn skips transferring of frame from SRC to REF queue. This causes driver to stop MFC encoding and last frame is lost. This patch guarantees safe handling of frames during MFCINST_FINISHING and correct clearing of workbit to avoid early stopping of encoding. Fixes: af935746 ("[media] MFC: Add MFC 5.1 V4L2 driver") Cc: stable@vger.kernel.org Cc: linux-fsd@tesla.com Signed-off-by:
Smitha T Murthy <smitha.t@samsung.com> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Yazen Ghannam authored
[ Upstream commit bc1b705b ] AMD's MCA Thresholding feature counts errors of all severity levels, not just correctable errors. If a deferred error causes the threshold limit to be reached (it was the error that caused the overflow), then both a deferred error interrupt and a thresholding interrupt will be triggered. The order of the interrupts is not guaranteed. If the threshold interrupt handler is executed first, then it will clear MCA_STATUS for the error. It will not check or clear MCA_DESTAT which also holds a copy of the deferred error. When the deferred error interrupt handler runs it will not find an error in MCA_STATUS, but it will find the error in MCA_DESTAT. This will cause two errors to be logged. Check for deferred errors when handling a threshold interrupt. If a bank contains a deferred error, then clear the bank's MCA_DESTAT register. Define a new helper function to do the deferred error check and clearing of MCA_DESTAT. [ bp: Simplify, convert comment to passive voice. ] Fixes: 37d43acf ("x86/mce/AMD: Redo error logging from APIC LVT interrupt handlers") Signed-off-by:
Yazen Ghannam <yazen.ghannam@amd.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20220621155943.33623-1-yazen.ghannam@amd.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-