mailweb.openeuler.org
Manage this list

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

Kernel

Threads by month
  • ----- 2025 -----
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2021 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2020 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2019 -----
  • December
kernel@openeuler.org

  • 58 participants
  • 19270 discussions
[PATCH OLK-6.6] drm/exynos/vidi: fix memory leak in .get_modes()
by liwei 16 Jul '24

16 Jul '24
From: Jani Nikula <jani.nikula(a)intel.com> mainline inclusion from mainline-v6.10-rc4 commit 38e3825631b1f314b21e3ade00b5a4d737eb054e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACV3A CVE: CVE-2024-40932 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- The duplicated EDID is never freed. Fix it. Cc: stable(a)vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index fb941a8c99f0..e17f9c5c9c90 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -309,6 +309,7 @@ static int vidi_get_modes(struct drm_connector *connector) struct vidi_context *ctx = ctx_from_connector(connector); struct edid *edid; int edid_len; + int count; /* * the edid data comes from user side and it would be set @@ -328,7 +329,11 @@ static int vidi_get_modes(struct drm_connector *connector) drm_connector_update_edid_property(connector, edid); - return drm_add_edid_modes(connector, edid); + count = drm_add_edid_modes(connector, edid); + + kfree(edid); + + return count; } static const struct drm_connector_helper_funcs vidi_connector_helper_funcs = { -- 2.25.1
2 1
0 0
[PATCH openEuler-22.03-LTS-SP1] drm/exynos/vidi: fix memory leak in .get_modes()
by liwei 16 Jul '24

16 Jul '24
From: Jani Nikula <jani.nikula(a)intel.com> mainline inclusion from mainline-v6.10-rc4 commit 38e3825631b1f314b21e3ade00b5a4d737eb054e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACV3A CVE: CVE-2024-40932 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- The duplicated EDID is never freed. Fix it. Cc: stable(a)vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index e5662bdcbbde..d27a8d28aada 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -308,6 +308,7 @@ static int vidi_get_modes(struct drm_connector *connector) struct vidi_context *ctx = ctx_from_connector(connector); struct edid *edid; int edid_len; + int count; /* * the edid data comes from user side and it would be set @@ -327,7 +328,11 @@ static int vidi_get_modes(struct drm_connector *connector) drm_connector_update_edid_property(connector, edid); - return drm_add_edid_modes(connector, edid); + count = drm_add_edid_modes(connector, edid); + + kfree(edid); + + return count; } static const struct drm_connector_helper_funcs vidi_connector_helper_funcs = { -- 2.25.1
2 1
0 0
[PATCH OLK-5.10] drm/exynos/vidi: fix memory leak in .get_modes()
by liwei 16 Jul '24

16 Jul '24
From: Jani Nikula <jani.nikula(a)intel.com> mainline inclusion from mainline-v6.10-rc4 commit 38e3825631b1f314b21e3ade00b5a4d737eb054e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACV3A CVE: CVE-2024-40932 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- The duplicated EDID is never freed. Fix it. Cc: stable(a)vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index e96436e11a36..34becd87b9c4 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -308,6 +308,7 @@ static int vidi_get_modes(struct drm_connector *connector) struct vidi_context *ctx = ctx_from_connector(connector); struct edid *edid; int edid_len; + int count; /* * the edid data comes from user side and it would be set @@ -327,7 +328,11 @@ static int vidi_get_modes(struct drm_connector *connector) drm_connector_update_edid_property(connector, edid); - return drm_add_edid_modes(connector, edid); + count = drm_add_edid_modes(connector, edid); + + kfree(edid); + + return count; } static const struct drm_connector_helper_funcs vidi_connector_helper_funcs = { -- 2.25.1
2 1
0 0
[PATCH OLK-6.6] ocfs2: fix NULL pointer dereference in ocfs2_journal_dirty()
by Wang Zhaolong 16 Jul '24

16 Jul '24
From: Joseph Qi <joseph.qi(a)linux.alibaba.com> stable inclusion from stable-v6.6.36 commit 0550ad87711f815b3d73e487ec58ca7d8f56edbc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACSVC CVE: CVE-2024-40952 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 58f7e1e2c9e72c7974054c64c3abeac81c11f822 upstream. bdev->bd_super has been removed and commit 8887b94d9322 change the usage from bdev->bd_super to b_assoc_map->host->i_sb. This introduces the following NULL pointer dereference in ocfs2_journal_dirty() since b_assoc_map is still not initialized. This can be easily reproduced by running xfstests generic/186, which simulate no more credits. [ 134.351592] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 134.355341] RIP: 0010:ocfs2_journal_dirty+0x14f/0x160 [ocfs2] ... [ 134.365071] Call Trace: [ 134.365312] <TASK> [ 134.365524] ? __die_body+0x1e/0x60 [ 134.365868] ? page_fault_oops+0x13d/0x4f0 [ 134.366265] ? __pfx_bit_wait_io+0x10/0x10 [ 134.366659] ? schedule+0x27/0xb0 [ 134.366981] ? exc_page_fault+0x6a/0x140 [ 134.367356] ? asm_exc_page_fault+0x26/0x30 [ 134.367762] ? ocfs2_journal_dirty+0x14f/0x160 [ocfs2] [ 134.368305] ? ocfs2_journal_dirty+0x13d/0x160 [ocfs2] [ 134.368837] ocfs2_create_new_meta_bhs.isra.51+0x139/0x2e0 [ocfs2] [ 134.369454] ocfs2_grow_tree+0x688/0x8a0 [ocfs2] [ 134.369927] ocfs2_split_and_insert.isra.67+0x35c/0x4a0 [ocfs2] [ 134.370521] ocfs2_split_extent+0x314/0x4d0 [ocfs2] [ 134.371019] ocfs2_change_extent_flag+0x174/0x410 [ocfs2] [ 134.371566] ocfs2_add_refcount_flag+0x3fa/0x630 [ocfs2] [ 134.372117] ocfs2_reflink_remap_extent+0x21b/0x4c0 [ocfs2] [ 134.372994] ? inode_update_timestamps+0x4a/0x120 [ 134.373692] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2] [ 134.374545] ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2] [ 134.375393] ocfs2_reflink_remap_blocks+0xe4/0x4e0 [ocfs2] [ 134.376197] ocfs2_remap_file_range+0x1de/0x390 [ocfs2] [ 134.376971] ? security_file_permission+0x29/0x50 [ 134.377644] vfs_clone_file_range+0xfe/0x320 [ 134.378268] ioctl_file_clone+0x45/0xa0 [ 134.378853] do_vfs_ioctl+0x457/0x990 [ 134.379422] __x64_sys_ioctl+0x6e/0xd0 [ 134.379987] do_syscall_64+0x5d/0x170 [ 134.380550] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 134.381231] RIP: 0033:0x7fa4926397cb [ 134.381786] Code: 73 01 c3 48 8b 0d bd 56 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8d 56 38 00 f7 d8 64 89 01 48 [ 134.383930] RSP: 002b:00007ffc2b39f7b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 134.384854] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fa4926397cb [ 134.385734] RDX: 00007ffc2b39f7f0 RSI: 000000004020940d RDI: 0000000000000003 [ 134.386606] RBP: 0000000000000000 R08: 00111a82a4f015bb R09: 00007fa494221000 [ 134.387476] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 [ 134.388342] R13: 0000000000f10000 R14: 0000558e844e2ac8 R15: 0000000000f10000 [ 134.389207] </TASK> Fix it by only aborting transaction and journal in ocfs2_journal_dirty() now, and leave ocfs2_abort() later when detecting an aborted handle, e.g. start next transaction. Also log the handle details in this case. Link: https://lkml.kernel.org/r/20240530110630.3933832-1-joseph.qi@linux.alibaba.… Fixes: 8887b94d9322 ("ocfs2: stop using bdev->bd_super for journal error logging") Signed-off-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Reviewed-by: Heming Zhao <heming.zhao(a)suse.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Gang He <ghe(a)suse.com> Cc: Jun Piao <piaojun(a)huawei.com> Cc: <stable(a)vger.kernel.org> [6.6+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Wang Zhaolong <wangzhaolong1(a)huawei.com> --- fs/ocfs2/journal.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/fs/ocfs2/journal.c b/fs/ocfs2/journal.c index ce215565d061..d4fa52cbb33f 100644 --- a/fs/ocfs2/journal.c +++ b/fs/ocfs2/journal.c @@ -778,13 +778,15 @@ void ocfs2_journal_dirty(handle_t *handle, struct buffer_head *bh) if (!is_handle_aborted(handle)) { journal_t *journal = handle->h_transaction->t_journal; - mlog(ML_ERROR, "jbd2_journal_dirty_metadata failed. " - "Aborting transaction and journal.\n"); + mlog(ML_ERROR, "jbd2_journal_dirty_metadata failed: " + "handle type %u started at line %u, credits %u/%u " + "errcode %d. Aborting transaction and journal.\n", + handle->h_type, handle->h_line_no, + handle->h_requested_credits, + jbd2_handle_buffer_credits(handle), status); handle->h_err = status; jbd2_journal_abort_handle(handle); jbd2_journal_abort(journal, status); - ocfs2_abort(bh->b_assoc_map->host->i_sb, - "Journal already aborted.\n"); } } } -- 2.34.3
2 1
0 0
[PATCH OLK-6.6] liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
by Liu Jian 16 Jul '24

16 Jul '24
From: Aleksandr Mishin <amishin(a)t-argos.ru> stable inclusion from stable-v6.6.35 commit fd2b613bc4c508e55c1221c6595bb889812a4fea category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZW2 CVE: CVE-2024-39506 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… --------------------------- [ Upstream commit c44711b78608c98a3e6b49ce91678cd0917d5349 ] In lio_vf_rep_copy_packet() pg_info->page is compared to a NULL value, but then it is unconditionally passed to skb_add_rx_frag() which looks strange and could lead to null pointer dereference. lio_vf_rep_copy_packet() call trace looks like: octeon_droq_process_packets octeon_droq_fast_process_packets octeon_droq_dispatch_pkt octeon_create_recv_info ...search in the dispatch_list... ->disp_fn(rdisp->rinfo, ...) lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...) In this path there is no code which sets pg_info->page to NULL. So this check looks unneeded and doesn't solve potential problem. But I guess the author had reason to add a check and I have no such card and can't do real test. In addition, the code in the function liquidio_push_packet() in liquidio/lio_core.c does exactly the same. Based on this, I consider the most acceptable compromise solution to adjust this issue by moving skb_add_rx_frag() into conditional scope. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 1f233f327913 ("liquidio: switchdev support for LiquidIO NIC") Signed-off-by: Aleksandr Mishin <amishin(a)t-argos.ru> Reviewed-by: Simon Horman <horms(a)kernel.org> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Liu Jian <liujian56(a)huawei.com> --- drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c index 600de587d7a9..e70b9ccca380 100644 --- a/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c +++ b/drivers/net/ethernet/cavium/liquidio/lio_vf_rep.c @@ -272,13 +272,12 @@ lio_vf_rep_copy_packet(struct octeon_device *oct, pg_info->page_offset; memcpy(skb->data, va, MIN_SKB_SIZE); skb_put(skb, MIN_SKB_SIZE); + skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, + pg_info->page, + pg_info->page_offset + MIN_SKB_SIZE, + len - MIN_SKB_SIZE, + LIO_RXBUFFER_SZ); } - - skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, - pg_info->page, - pg_info->page_offset + MIN_SKB_SIZE, - len - MIN_SKB_SIZE, - LIO_RXBUFFER_SZ); } else { struct octeon_skb_page_info *pg_info = ((struct octeon_skb_page_info *)(skb->cb)); -- 2.34.1
2 1
0 0
[PATCH openEuler-1.0-LTS] drm/exynos/vidi: fix memory leak in .get_modes()
by liwei 16 Jul '24

16 Jul '24
From: Jani Nikula <jani.nikula(a)intel.com> mainline inclusion from mainline-v6.10-rc4 commit 38e3825631b1f314b21e3ade00b5a4d737eb054e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACV3A CVE: CVE-2024-40932 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… ---------------------------------- The duplicated EDID is never freed. Fix it. Cc: stable(a)vger.kernel.org Signed-off-by: Jani Nikula <jani.nikula(a)intel.com> Signed-off-by: Inki Dae <inki.dae(a)samsung.com> Signed-off-by: liwei <liwei728(a)huawei.com> --- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_vidi.c b/drivers/gpu/drm/exynos/exynos_drm_vidi.c index 19697c1362d8..362400eaa688 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_vidi.c +++ b/drivers/gpu/drm/exynos/exynos_drm_vidi.c @@ -302,6 +302,7 @@ static int vidi_get_modes(struct drm_connector *connector) struct vidi_context *ctx = ctx_from_connector(connector); struct edid *edid; int edid_len; + int count; /* * the edid data comes from user side and it would be set @@ -321,7 +322,11 @@ static int vidi_get_modes(struct drm_connector *connector) drm_connector_update_edid_property(connector, edid); - return drm_add_edid_modes(connector, edid); + count = drm_add_edid_modes(connector, edid); + + kfree(edid); + + return count; } static const struct drm_connector_helper_funcs vidi_connector_helper_funcs = { -- 2.25.1
2 1
0 0
[PATCH OLK-6.6] cachefiles: flush all requests after setting CACHEFILES_DEAD
by Long Li 16 Jul '24

16 Jul '24
From: Baokun Li <libaokun1(a)huawei.com> mainline inclusion from mainline-v6.9-rc3 commit 85e833cd7243bda7285492b0653c3abb1e2e757b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IACZXJ CVE: CVE-2024-40935 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In ondemand mode, when the daemon is processing an open request, if the kernel flags the cache as CACHEFILES_DEAD, the cachefiles_daemon_write() will always return -EIO, so the daemon can't pass the copen to the kernel. Then the kernel process that is waiting for the copen triggers a hung_task. Since the DEAD state is irreversible, it can only be exited by closing /dev/cachefiles. Therefore, after calling cachefiles_io_error() to mark the cache as CACHEFILES_DEAD, if in ondemand mode, flush all requests to avoid the above hungtask. We may still be able to read some of the cached data before closing the fd of /dev/cachefiles. Note that this relies on the patch that adds reference counting to the req, otherwise it may UAF. Fixes: c8383054506c ("cachefiles: notify the user daemon when looking up cookie") Signed-off-by: Baokun Li <libaokun1(a)huawei.com> Link: https://lore.kernel.org/r/20240522114308.2402121-12-libaokun@huaweicloud.com Acked-by: Jeff Layton <jlayton(a)kernel.org> Signed-off-by: Christian Brauner <brauner(a)kernel.org> Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/cachefiles/daemon.c | 2 +- fs/cachefiles/internal.h | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/cachefiles/daemon.c b/fs/cachefiles/daemon.c index 5f4df9588620..9072abfc154c 100644 --- a/fs/cachefiles/daemon.c +++ b/fs/cachefiles/daemon.c @@ -132,7 +132,7 @@ static int cachefiles_daemon_open(struct inode *inode, struct file *file) return 0; } -static void cachefiles_flush_reqs(struct cachefiles_cache *cache) +void cachefiles_flush_reqs(struct cachefiles_cache *cache) { struct xarray *xa = &cache->reqs; struct cachefiles_req *req; diff --git a/fs/cachefiles/internal.h b/fs/cachefiles/internal.h index 2ad58c465208..e0a15150ed89 100644 --- a/fs/cachefiles/internal.h +++ b/fs/cachefiles/internal.h @@ -173,6 +173,7 @@ extern int cachefiles_has_space(struct cachefiles_cache *cache, * daemon.c */ extern const struct file_operations cachefiles_daemon_fops; +extern void cachefiles_flush_reqs(struct cachefiles_cache *cache); extern void cachefiles_get_unbind_pincount(struct cachefiles_cache *cache); extern void cachefiles_put_unbind_pincount(struct cachefiles_cache *cache); @@ -367,6 +368,8 @@ do { \ pr_err("I/O Error: " FMT"\n", ##__VA_ARGS__); \ fscache_io_error((___cache)->cache); \ set_bit(CACHEFILES_DEAD, &(___cache)->flags); \ + if (cachefiles_in_ondemand_mode(___cache)) \ + cachefiles_flush_reqs(___cache); \ } while (0) #define cachefiles_io_error_obj(object, FMT, ...) \ -- 2.39.2
2 1
0 0
[PATCH openEuler-22.03-LTS-SP1 0/5] Ensure that NFS client returns a correct writeback error code
by Wang Zhaolong 16 Jul '24

16 Jul '24
Backport community mainline patch to make close and writeback return correct return values. Scott Mayhew (2): nfs: nfs_file_write() should check for writeback errors nfs: ensure correct writeback errors are returned on close() Trond Myklebust (2): NFS: Use of mapping_set_error() results in spurious errors NFS: Don't report ENOSPC write errors twice HULK solution to avoid residual error codes Wang Zhaolong (1): nfs: Ensure write and flush consume writeback errors fs/nfs/file.c | 39 +++++++++++++++++++-------------------- fs/nfs/nfs4file.c | 3 ++- fs/nfs/write.c | 5 ++++- 3 files changed, 25 insertions(+), 22 deletions(-) -- 2.34.3
2 6
0 0
[PATCH OLK-5.10 0/5] Ensure that NFS client returns a correct writeback error code
by Wang Zhaolong 16 Jul '24

16 Jul '24
Backport community mainline patch to make close and writeback return correct return values. Scott Mayhew (2): nfs: nfs_file_write() should check for writeback errors nfs: ensure correct writeback errors are returned on close() Trond Myklebust (2): NFS: Use of mapping_set_error() results in spurious errors NFS: Don't report ENOSPC write errors twice HULK solution to avoid residual error codes Wang Zhaolong (1): nfs: Ensure write and flush consume writeback errors fs/nfs/file.c | 39 +++++++++++++++++++-------------------- fs/nfs/nfs4file.c | 3 ++- fs/nfs/write.c | 5 ++++- 3 files changed, 25 insertions(+), 22 deletions(-) -- 2.34.3
2 6
0 0
[PATCH OLK-6.6] xfs: fix mount hung while sb recover fail
by Long Li 16 Jul '24

16 Jul '24
hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IAC63K CVE: NA -------------------------------- When I mount a corrupt xfs image, mount process hang all the time, the stack as follows: [root@testvm ~]# cat /proc/425/stack [<0>] xfs_wait_buftarg+0x5a/0x360 [<0>] xfs_mountfs+0x591/0xc90 [<0>] xfs_fc_fill_super+0x792/0xc80 [<0>] get_tree_bdev+0x1ec/0x3a0 [<0>] xfs_fc_get_tree+0x19/0x30 [<0>] vfs_get_tree+0x2f/0x110 [<0>] path_mount+0x8ab/0x1150 [<0>] do_mount+0x91/0xc0 [<0>] __se_sys_mount+0x14a/0x220 [<0>] __x64_sys_mount+0x29/0x40 [<0>] do_syscall_64+0x6c/0xe0 [<0>] entry_SYSCALL_64_after_hwframe+0x62/0xc7 During buffer recovery, if the superblock buffer is modified, we also need to update the content of the mount point (mp). In this situation, if we encounter an error, we will go to out_release and release the xfs_buf. However, this is not enough because the xfs_buf's log item has been initialized and is held by the buffer log item in xlog_recover_do_reg_buffer(). Fixing this issue is straightforward: we need to set the error and add the xfs_buf to the buffer_list in such situations. This allows it to be handled by the normal buffer write process. The filesystem will be shut down before submission in xlog_do_recovery_pass() because the log recovery encountered an error. As a result, the xfs_buf will be released correctly. Fixes: 6fb62b3ffacb ("xfs: fix the problem of mount failure caused by not refreshing mp->m_sb") Signed-off-by: Long Li <leo.lilong(a)huawei.com> --- fs/xfs/xfs_buf_item_recover.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_buf_item_recover.c b/fs/xfs/xfs_buf_item_recover.c index 2383cc2d0354..f78476180bb7 100644 --- a/fs/xfs/xfs_buf_item_recover.c +++ b/fs/xfs/xfs_buf_item_recover.c @@ -980,7 +980,7 @@ xlog_recover_buf_commit_pass2( bp->b_ops->verify_write(bp); error = bp->b_error; if (error) - goto out_release; + goto out_writebuf; if (be32_to_cpu(sb->sb_agcount) > mp->m_sb.sb_agcount) { error = xfs_initialize_perag(mp, @@ -988,13 +988,14 @@ xlog_recover_buf_commit_pass2( be64_to_cpu(sb->sb_dblocks), &mp->m_maxagi); if (error) - goto out_release; + goto out_writebuf; } xfs_sb_from_disk(&mp->m_sb, sb); } } +out_writebuf: /* * Perform delayed write on the buffer. Asynchronous writes will be * slower when taking into account all the buffers to be flushed. -- 2.31.1
2 1
0 0
  • ← Newer
  • 1
  • ...
  • 844
  • 845
  • 846
  • 847
  • 848
  • 849
  • 850
  • ...
  • 1927
  • Older →

HyperKitty Powered by HyperKitty