hulk inclusion
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/I9DN5Z
CVE: NA
--------------------------------
Since commit 7f6416dcd4a3f ("ext4: implement writeback iomap path"), the
order mode is removed in iomap framework, which lets ext4_mb_clear_bb()
free data blocks immediately. It may cause stale data read from truncated
file in power-cut case. Following is details:
P1 P2
vfs_truncate(file A)
ext4_setattr
EXT4_I(inode)->i_disksize = attr->ia_size // record in journal
ext4_truncate
ext4_mb_clear_bb
mb_free_blocks // free block i
vfs_write(file B) // get block i and writeback
>> powercut <<
In the next mount, inode size and extent tree is stale(before truncated),
the content in block i is file B.
Fix the problem by adding free data blocks in journal for iomap case.
Fixes: 7f6416dcd4a3 ("ext4: implement writeback iomap path")
Signed-off-by: Zhihao Cheng <chengzhihao1(a)huawei.com>
Signed-off-by: Zhihao Cheng <chengzhihao(a)huaweicloud.com>
---
fs/ext4/mballoc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index b138902fd42c..4d34e2b33fa0 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -6624,7 +6624,8 @@ static void ext4_mb_clear_bb(handle_t *handle, struct inode *inode,
*/
if (ext4_handle_valid(handle) &&
((flags & EXT4_FREE_BLOCKS_METADATA) ||
- !ext4_should_writeback_data(inode))) {
+ !ext4_should_writeback_data(inode) ||
+ ext4_test_inode_state(inode, EXT4_STATE_BUFFERED_IOMAP))) {
struct ext4_free_data *new_entry;
/*
* We use __GFP_NOFAIL because ext4_free_blocks() is not allowed
--
2.31.1
From: Rik van Riel <riel(a)surriel.com>
stable inclusion
from stable-v4.19.317
commit 7bdf1d550ddfcd9ab797087421f77b7aceddc8a7
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAJKLA
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
--------------------------------
commit 5cbcb62dddf5346077feb82b7b0c9254222d3445 upstream.
While taking a kernel core dump with makedumpfile on a larger system,
softlockup messages often appear.
While softlockup warnings can be harmless, they can also interfere with
things like RCU freeing memory, which can be problematic when the kdump
kexec image is configured with as little memory as possible.
Avoid the softlockup, and give things like work items and RCU a chance to
do their thing during __read_vmcore by adding a cond_resched.
Link: https://lkml.kernel.org/r/20240507091858.36ff767f@imladris.surriel.com
Signed-off-by: Rik van Riel <riel(a)surriel.com>
Acked-by: Baoquan He <bhe(a)redhat.com>
Cc: Dave Young <dyoung(a)redhat.com>
Cc: Vivek Goyal <vgoyal(a)redhat.com>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Xiaomeng Zhang <zhangxiaomeng13(a)huawei.com>
---
fs/proc/vmcore.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/proc/vmcore.c b/fs/proc/vmcore.c
index f5dfedc01552..cd384a1ebef5 100644
--- a/fs/proc/vmcore.c
+++ b/fs/proc/vmcore.c
@@ -359,6 +359,8 @@ static ssize_t __read_vmcore(char *buffer, size_t buflen, loff_t *fpos,
/* leave now if filled buffer already */
if (buflen == 0)
return acc;
+
+ cond_resched();
}
list_for_each_entry(m, &vmcore_list, list) {
--
2.34.1
From: Haifeng Xu <haifeng.xu(a)shopee.com>
stable inclusion
from stable-v4.19.317
commit c23ead9986a17c793d39be11ce6c084904c9c44a
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAJLGS
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
--------------------------------
[ Upstream commit 74751ef5c1912ebd3e65c3b65f45587e05ce5d36 ]
In our production environment, we found many hung tasks which are
blocked for more than 18 hours. Their call traces are like this:
[346278.191038] __schedule+0x2d8/0x890
[346278.191046] schedule+0x4e/0xb0
[346278.191049] perf_event_free_task+0x220/0x270
[346278.191056] ? init_wait_var_entry+0x50/0x50
[346278.191060] copy_process+0x663/0x18d0
[346278.191068] kernel_clone+0x9d/0x3d0
[346278.191072] __do_sys_clone+0x5d/0x80
[346278.191076] __x64_sys_clone+0x25/0x30
[346278.191079] do_syscall_64+0x5c/0xc0
[346278.191083] ? syscall_exit_to_user_mode+0x27/0x50
[346278.191086] ? do_syscall_64+0x69/0xc0
[346278.191088] ? irqentry_exit_to_user_mode+0x9/0x20
[346278.191092] ? irqentry_exit+0x19/0x30
[346278.191095] ? exc_page_fault+0x89/0x160
[346278.191097] ? asm_exc_page_fault+0x8/0x30
[346278.191102] entry_SYSCALL_64_after_hwframe+0x44/0xae
The task was waiting for the refcount become to 1, but from the vmcore,
we found the refcount has already been 1. It seems that the task didn't
get woken up by perf_event_release_kernel() and got stuck forever. The
below scenario may cause the problem.
Thread A Thread B
... ...
perf_event_free_task perf_event_release_kernel
...
acquire event->child_mutex
...
get_ctx
... release event->child_mutex
acquire ctx->mutex
...
perf_free_event (acquire/release event->child_mutex)
...
release ctx->mutex
wait_var_event
acquire ctx->mutex
acquire event->child_mutex
# move existing events to free_list
release event->child_mutex
release ctx->mutex
put_ctx
... ...
In this case, all events of the ctx have been freed, so we couldn't
find the ctx in free_list and Thread A will miss the wakeup. It's thus
necessary to add a wakeup after dropping the reference.
Fixes: 1cf8dfe8a661 ("perf/core: Fix race between close() and fork()")
Signed-off-by: Haifeng Xu <haifeng.xu(a)shopee.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org>
Reviewed-by: Frederic Weisbecker <frederic(a)kernel.org>
Acked-by: Mark Rutland <mark.rutland(a)arm.com>
Cc: stable(a)vger.kernel.org
Link: https://lkml.kernel.org/r/20240513103948.33570-1-haifeng.xu@shopee.com
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
Signed-off-by: Xiaomeng Zhang <zhangxiaomeng13(a)huawei.com>
---
kernel/events/core.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index b9667223b050..b7f4aaedb5ff 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -4664,6 +4664,7 @@ int perf_event_release_kernel(struct perf_event *event)
again:
mutex_lock(&event->child_mutex);
list_for_each_entry(child, &event->child_list, child_list) {
+ void *var = NULL;
/*
* Cannot change, child events are not migrated, see the
@@ -4704,11 +4705,23 @@ int perf_event_release_kernel(struct perf_event *event)
* this can't be the last reference.
*/
put_event(event);
+ } else {
+ var = &ctx->refcount;
}
mutex_unlock(&event->child_mutex);
mutex_unlock(&ctx->mutex);
put_ctx(ctx);
+
+ if (var) {
+ /*
+ * If perf_event_free_task() has deleted all events from the
+ * ctx while the child_mutex got released above, make sure to
+ * notify about the preceding put_ctx().
+ */
+ smp_mb(); /* pairs with wait_var_event() */
+ wake_up_var(var);
+ }
goto again;
}
mutex_unlock(&event->child_mutex);
--
2.34.1
tree: https://gitee.com/openeuler/kernel.git OLK-5.10
head: b7bed6628b750ffd687d1da0a170dece4b0c08bd
commit: 6cf173c15990725cb9c0c4570fbc90e937a757b4 [27098/30000] drivers: initial support for rnpvf drivers from Mucse Technology
config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20240903/202409031941.6m1LMpai-lkp@…)
compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240903/202409031941.6m1LMpai-lkp@…)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp(a)intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202409031941.6m1LMpai-lkp@intel.com/
All warnings (new ones prefixed by >>):
drivers/net/ethernet/mucse/rnpvf/rnpvf_main.c:112: warning: Function parameter or member 'rnpvf_queue' not described in 'rnpvf_set_ring_vector'
drivers/net/ethernet/mucse/rnpvf/rnpvf_main.c:112: warning: Function parameter or member 'rnpvf_msix_vector' not described in 'rnpvf_set_ring_vector'
>> drivers/net/ethernet/mucse/rnpvf/rnpvf_main.c:112: warning: Excess function parameter 'direction' description in 'rnpvf_set_ring_vector'
>> drivers/net/ethernet/mucse/rnpvf/rnpvf_main.c:112: warning: Excess function parameter 'queue' description in 'rnpvf_set_ring_vector'
>> drivers/net/ethernet/mucse/rnpvf/rnpvf_main.c:112: warning: Excess function parameter 'msix_vector' description in 'rnpvf_set_ring_vector'
drivers/net/ethernet/mucse/rnpvf/rnpvf_main.c:807: warning: Excess function parameter 'rx_ring' description in 'rnpvf_pull_tail'
drivers/net/ethernet/mucse/rnpvf/rnpvf_main.c:1030: warning: Excess function parameter 'skb' description in 'rnpvf_is_non_eop'
drivers/net/ethernet/mucse/rnpvf/rnpvf_main.c:2203: warning: Function parameter or member 'type' not described in 'rnpvf_update_itr'
drivers/net/ethernet/mucse/rnpvf/rnpvf_main.c:3922: warning: Function parameter or member 't' not described in 'rnpvf_watchdog'
drivers/net/ethernet/mucse/rnpvf/rnpvf_main.c:3922: warning: Excess function parameter 'data' description in 'rnpvf_watchdog'
vim +112 drivers/net/ethernet/mucse/rnpvf/rnpvf_main.c
102
103 /**
104 * rnpvf_set_ivar - set IVAR registers - maps interrupt causes to vectors
105 * @adapter: pointer to adapter struct
106 * @direction: 0 for Rx, 1 for Tx, -1 for other causes
107 * @queue: queue to map the corresponding interrupt to
108 * @msix_vector: the vector to map to the corresponding queue
109 */
110 static void rnpvf_set_ring_vector(struct rnpvf_adapter *adapter,
111 u8 rnpvf_queue, u8 rnpvf_msix_vector)
> 112 {
113 struct rnpvf_hw *hw = &adapter->hw;
114 u32 data = 0;
115
116 data = hw->vfnum << 24;
117 data |= (rnpvf_msix_vector << 8);
118 data |= (rnpvf_msix_vector << 0);
119 DPRINTK(IFUP, INFO,
120 "Set Ring-Vector queue:%d (reg:0x%x) <-- Rx-MSIX:%d, Tx-MSIX:%d\n",
121 rnpvf_queue, RING_VECTOR(rnpvf_queue), rnpvf_msix_vector,
122 rnpvf_msix_vector);
123
124 rnpvf_wr_reg(hw->ring_msix_base + RING_VECTOR(rnpvf_queue), data);
125 }
126
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki