Hi Yabin,
FYI, the error/warning still remains.
tree: https://gitee.com/openeuler/kernel.git OLK-6.6
head: e7bc79687a034a22f94328123d5cf8c4d4436c35
commit: c74ae2c5da57becf3f41c596d79b3dd30fa1baa6 [13479/15255] hct: add mediated ccp driver support for hygon crypto technology.
config: x86_64-buildonly-randconfig-006-20241024 (https://download.01.org/0day-ci/archive/20241024/202410241021.mDLDP8B3-lkp@…)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241024/202410241021.mDLDP8B3-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/202410241021.mDLDP8B3-lkp@intel.com/
All errors (new ones prefixed by >>):
drivers/crypto/ccp/hygon/hct.c:1333:15: warning: no previous prototype for 'hct_pin_memory' [-Wmissing-prototypes]
1333 | struct page **hct_pin_memory(struct hct_private *private, unsigned long uaddr,
| ^~~~~~~~~~~~~~
drivers/crypto/ccp/hygon/hct.c: In function 'hct_get_page':
>> drivers/crypto/ccp/hygon/hct.c:1730:51: error: 'struct device' has no member named 'numa_node'
1730 | *node = hct_data.iommu[page_idx].pdev->dev.numa_node;
| ^
vim +1730 drivers/crypto/ccp/hygon/hct.c
1713
1714 static struct page *hct_get_page(pgoff_t page_idx)
1715 {
1716 u64 *node;
1717
1718 mutex_lock(&hct_share.lock);
1719 if (!hct_share.pages[page_idx]) {
1720 hct_share.pages[page_idx] =
1721 alloc_pages(GFP_HIGHUSER | __GFP_ZERO, 0);
1722 if (!hct_share.pages[page_idx]) {
1723 mutex_unlock(&hct_share.lock);
1724 return NULL;
1725 }
1726 }
1727 get_page(hct_share.pages[page_idx]);
1728
1729 node = page_to_virt(hct_share.pages[page_idx]) + PAGE_SIZE - 8;
> 1730 *node = hct_data.iommu[page_idx].pdev->dev.numa_node;
1731 mutex_unlock(&hct_share.lock);
1732
1733 return hct_share.pages[page_idx];
1734 }
1735
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
From: Waiman Long <longman(a)redhat.com>
stable inclusion
from stable-v4.19.322
commit 6760357063f593a17613e015aed2051cfd4197c6
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/IAYN0Z
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id…
--------------------------------
[ Upstream commit 57b56d16800e8961278ecff0dc755d46c4575092 ]
The writing of css->cgroup associated with the cgroup root in
rebind_subsystems() is currently protected only by cgroup_mutex.
However, the reading of css->cgroup in both proc_cpuset_show() and
proc_cgroup_show() is protected just by css_set_lock. That makes the
readers susceptible to racing problems like data tearing or caching.
It is also a problem that can be reported by KCSAN.
This can be fixed by using READ_ONCE() and WRITE_ONCE() to access
css->cgroup. Alternatively, the writing of css->cgroup can be moved
under css_set_lock as well which is done by this patch.
Signed-off-by: Waiman Long <longman(a)redhat.com>
Signed-off-by: Tejun Heo <tj(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
Signed-off-by: Chen Ridong <chenridong(a)huawei.com>
---
kernel/cgroup/cgroup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index 1339b93f7054..7b3c1491cc88 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -1717,9 +1717,9 @@ int rebind_subsystems(struct cgroup_root *dst_root, u16 ss_mask)
RCU_INIT_POINTER(scgrp->subsys[ssid], NULL);
rcu_assign_pointer(dcgrp->subsys[ssid], css);
ss->root = dst_root;
- css->cgroup = dcgrp;
spin_lock_irq(&css_set_lock);
+ css->cgroup = dcgrp;
WARN_ON(!list_empty(&dcgrp->e_csets[ss->id]));
list_for_each_entry_safe(cset, cset_pos, &scgrp->e_csets[ss->id],
e_cset_node[ss->id]) {
--
2.34.1
From: Chao Yu <chao(a)kernel.org>
mainline inclusion
from mainline-v6.12-rc1
commit 930c6ab93492c4b15436524e704950b364b2930c
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/https://gitee.com/src-openeul…
CVE: CVE-2024-47689
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
--------------------------------
syzbot reports a f2fs bug as below:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 58 at kernel/rcu/sync.c:177 rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
CPU: 1 UID: 0 PID: 58 Comm: kworker/1:2 Not tainted 6.10.0-syzkaller-12562-g1722389b0d86 #0
Workqueue: events destroy_super_work
RIP: 0010:rcu_sync_dtor+0xcd/0x180 kernel/rcu/sync.c:177
Call Trace:
percpu_free_rwsem+0x41/0x80 kernel/locking/percpu-rwsem.c:42
destroy_super_work+0xec/0x130 fs/super.c:282
process_one_work kernel/workqueue.c:3231 [inline]
process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312
worker_thread+0x86d/0xd40 kernel/workqueue.c:3390
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
As Christian Brauner pointed out [1]: the root cause is f2fs sets
SB_RDONLY flag in internal function, rather than setting the flag
covered w/ sb->s_umount semaphore via remount procedure, then below
race condition causes this bug:
- freeze_super()
- sb_wait_write(sb, SB_FREEZE_WRITE)
- sb_wait_write(sb, SB_FREEZE_PAGEFAULT)
- sb_wait_write(sb, SB_FREEZE_FS)
- f2fs_handle_critical_error
- sb->s_flags |= SB_RDONLY
- thaw_super
- thaw_super_locked
- sb_rdonly() is true, so it skips
sb_freeze_unlock(sb, SB_FREEZE_FS)
- deactivate_locked_super
Since f2fs has almost the same logic as ext4 [2] when handling critical
error in filesystem if it mounts w/ errors=remount-ro option:
- set CP_ERROR_FLAG flag which indicates filesystem is stopped
- record errors to superblock
- set SB_RDONLY falg
Once we set CP_ERROR_FLAG flag, all writable interfaces can detect the
flag and stop any further updates on filesystem. So, it is safe to not
set SB_RDONLY flag, let's remove the logic and keep in line w/ ext4 [3].
[1] https://lore.kernel.org/all/20240729-himbeeren-funknetz-96e62f9c7aee@brauner
[2] https://lore.kernel.org/all/20240729132721.hxih6ehigadqf7wx@quack3
[3] https://lore.kernel.org/linux-ext4/20240805201241.27286-1-jack@suse.cz
Fixes: b62e71be2110 ("f2fs: support errors=remount-ro|continue|panic mountoption")
Reported-by: syzbot+20d7e439f76bbbd863a7(a)syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/000000000000b90a8e061e21d12f@google.com/
Cc: Jan Kara <jack(a)suse.cz>
Cc: Christian Brauner <brauner(a)kernel.org>
Signed-off-by: Chao Yu <chao(a)kernel.org>
Reviewed-by: Christian Brauner <brauner(a)kernel.org>
Signed-off-by: Jaegeuk Kim <jaegeuk(a)kernel.org>
Signed-off-by: Bowen You <youbowen2(a)huawei.com>
---
fs/f2fs/super.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index c062fd2bdb13..0bd97c63969a 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -4131,12 +4131,14 @@ void f2fs_handle_critical_error(struct f2fs_sb_info *sbi, unsigned char reason,
}
f2fs_warn(sbi, "Remounting filesystem read-only");
+
/*
- * Make sure updated value of ->s_mount_flags will be visible before
- * ->s_flags update
+ * We have already set CP_ERROR_FLAG flag to stop all updates
+ * to filesystem, so it doesn't need to set SB_RDONLY flag here
+ * because the flag should be set covered w/ sb->s_umount semaphore
+ * via remount procedure, otherwise, it will confuse code like
+ * freeze_super() which will lead to deadlocks and other problems.
*/
- smp_wmb();
- sb->s_flags |= SB_RDONLY;
}
static void f2fs_record_error_work(struct work_struct *work)
--
2.34.1
From: Marek Vasut <marex(a)denx.de>
stable inclusion
from stable-v5.10.227
commit 9b8bc33ad64192f54142396470cc34ce539a8940
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCQ
CVE: CVE-2024-49985
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id…
--------------------------------
commit 048bbbdbf85e5e00258dfb12f5e368f908801d7b upstream.
In case there is any sort of clock controller attached to this I2C bus
controller, for example Versaclock or even an AIC32x4 I2C codec, then
an I2C transfer triggered from the clock controller clk_ops .prepare
callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.
This is because the clock controller first grabs the prepare_lock mutex
and then performs the prepare operation, including its I2C access. The
I2C access resumes this I2C bus controller via .runtime_resume callback,
which calls clk_prepare_enable(), which attempts to grab the prepare_lock
mutex again and deadlocks.
Since the clock are already prepared since probe() and unprepared in
remove(), use simple clk_enable()/clk_disable() calls to enable and
disable the clock on runtime suspend and resume, to avoid hitting the
prepare_lock mutex.
Acked-by: Alain Volmat <alain.volmat(a)foss.st.com>
Signed-off-by: Marek Vasut <marex(a)denx.de>
Fixes: 4e7bca6fc07b ("i2c: i2c-stm32f7: add PM Runtime support")
Cc: <stable(a)vger.kernel.org> # v5.0+
Signed-off-by: Andi Shyti <andi.shyti(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com>
---
drivers/i2c/busses/i2c-stm32f7.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 0f4c0282028b..da3ff7802307 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -2275,7 +2275,7 @@ static int __maybe_unused stm32f7_i2c_runtime_suspend(struct device *dev)
struct stm32f7_i2c_dev *i2c_dev = dev_get_drvdata(dev);
if (!stm32f7_i2c_is_slave_registered(i2c_dev))
- clk_disable_unprepare(i2c_dev->clk);
+ clk_disable(i2c_dev->clk);
return 0;
}
@@ -2286,9 +2286,9 @@ static int __maybe_unused stm32f7_i2c_runtime_resume(struct device *dev)
int ret;
if (!stm32f7_i2c_is_slave_registered(i2c_dev)) {
- ret = clk_prepare_enable(i2c_dev->clk);
+ ret = clk_enable(i2c_dev->clk);
if (ret) {
- dev_err(dev, "failed to prepare_enable clock\n");
+ dev_err(dev, "failed to enable clock\n");
return ret;
}
}
--
2.34.1
From: Marek Vasut <marex(a)denx.de>
stable inclusion
from stable-v6.6.55
commit 22a1f8a5b56ba93d3e8b7a1dafa24e01c8bb48ba
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCQ
CVE: CVE-2024-49985
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id…
--------------------------------
commit 048bbbdbf85e5e00258dfb12f5e368f908801d7b upstream.
In case there is any sort of clock controller attached to this I2C bus
controller, for example Versaclock or even an AIC32x4 I2C codec, then
an I2C transfer triggered from the clock controller clk_ops .prepare
callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.
This is because the clock controller first grabs the prepare_lock mutex
and then performs the prepare operation, including its I2C access. The
I2C access resumes this I2C bus controller via .runtime_resume callback,
which calls clk_prepare_enable(), which attempts to grab the prepare_lock
mutex again and deadlocks.
Since the clock are already prepared since probe() and unprepared in
remove(), use simple clk_enable()/clk_disable() calls to enable and
disable the clock on runtime suspend and resume, to avoid hitting the
prepare_lock mutex.
Acked-by: Alain Volmat <alain.volmat(a)foss.st.com>
Signed-off-by: Marek Vasut <marex(a)denx.de>
Fixes: 4e7bca6fc07b ("i2c: i2c-stm32f7: add PM Runtime support")
Cc: <stable(a)vger.kernel.org> # v5.0+
Signed-off-by: Andi Shyti <andi.shyti(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com>
---
drivers/i2c/busses/i2c-stm32f7.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 887d55ae4096..b4f10ff31102 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -2394,7 +2394,7 @@ static int __maybe_unused stm32f7_i2c_runtime_suspend(struct device *dev)
struct stm32f7_i2c_dev *i2c_dev = dev_get_drvdata(dev);
if (!stm32f7_i2c_is_slave_registered(i2c_dev))
- clk_disable_unprepare(i2c_dev->clk);
+ clk_disable(i2c_dev->clk);
return 0;
}
@@ -2405,9 +2405,9 @@ static int __maybe_unused stm32f7_i2c_runtime_resume(struct device *dev)
int ret;
if (!stm32f7_i2c_is_slave_registered(i2c_dev)) {
- ret = clk_prepare_enable(i2c_dev->clk);
+ ret = clk_enable(i2c_dev->clk);
if (ret) {
- dev_err(dev, "failed to prepare_enable clock\n");
+ dev_err(dev, "failed to enable clock\n");
return ret;
}
}
--
2.34.1
From: Marek Vasut <marex(a)denx.de>
stable inclusion
from stable-v5.10.227
commit 9b8bc33ad64192f54142396470cc34ce539a8940
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/IAYRCQ
CVE: CVE-2024-49985
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id…
--------------------------------
commit 048bbbdbf85e5e00258dfb12f5e368f908801d7b upstream.
In case there is any sort of clock controller attached to this I2C bus
controller, for example Versaclock or even an AIC32x4 I2C codec, then
an I2C transfer triggered from the clock controller clk_ops .prepare
callback may trigger a deadlock on drivers/clk/clk.c prepare_lock mutex.
This is because the clock controller first grabs the prepare_lock mutex
and then performs the prepare operation, including its I2C access. The
I2C access resumes this I2C bus controller via .runtime_resume callback,
which calls clk_prepare_enable(), which attempts to grab the prepare_lock
mutex again and deadlocks.
Since the clock are already prepared since probe() and unprepared in
remove(), use simple clk_enable()/clk_disable() calls to enable and
disable the clock on runtime suspend and resume, to avoid hitting the
prepare_lock mutex.
Acked-by: Alain Volmat <alain.volmat(a)foss.st.com>
Signed-off-by: Marek Vasut <marex(a)denx.de>
Fixes: 4e7bca6fc07b ("i2c: i2c-stm32f7: add PM Runtime support")
Cc: <stable(a)vger.kernel.org> # v5.0+
Signed-off-by: Andi Shyti <andi.shyti(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com>
---
drivers/i2c/busses/i2c-stm32f7.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 7b9272f9cc21..0b4e73e63820 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -2278,7 +2278,7 @@ static int __maybe_unused stm32f7_i2c_runtime_suspend(struct device *dev)
struct stm32f7_i2c_dev *i2c_dev = dev_get_drvdata(dev);
if (!stm32f7_i2c_is_slave_registered(i2c_dev))
- clk_disable_unprepare(i2c_dev->clk);
+ clk_disable(i2c_dev->clk);
return 0;
}
@@ -2289,9 +2289,9 @@ static int __maybe_unused stm32f7_i2c_runtime_resume(struct device *dev)
int ret;
if (!stm32f7_i2c_is_slave_registered(i2c_dev)) {
- ret = clk_prepare_enable(i2c_dev->clk);
+ ret = clk_enable(i2c_dev->clk);
if (ret) {
- dev_err(dev, "failed to prepare_enable clock\n");
+ dev_err(dev, "failed to enable clock\n");
return ret;
}
}
--
2.34.1