From: Sergey Matsievskiy <matsievskiysv(a)gmail.com>
mainline inclusion
from mainline-v6.12-rc4
commit 93b8ddc54507a227087c60a0013ed833b6ae7d3c
category: bugfix
bugzilla: https://gitee.com/src-openeuler/kernel/issues/IB2YX2
CVE: CVE-2024-50196
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id…
--------------------------------
The current implementation only calls chained_irq_enter() and
chained_irq_exit() if it detects pending interrupts.
```
for (i = 0; i < info->stride; i++) {
uregmap_read(info->map, id_reg + 4 * i, ®);
if (!reg)
continue;
chained_irq_enter(parent_chip, desc);
```
However, in case of GPIO pin configured in level mode and the parent
controller configured in edge mode, GPIO interrupt might be lowered by the
hardware. In the result, if the interrupt is short enough, the parent
interrupt is still pending while the GPIO interrupt is cleared;
chained_irq_enter() never gets called and the system hangs trying to
service the parent interrupt.
Moving chained_irq_enter() and chained_irq_exit() outside the for loop
ensures that they are called even when GPIO interrupt is lowered by the
hardware.
The similar code with chained_irq_enter() / chained_irq_exit() functions
wrapping interrupt checking loop may be found in many other drivers:
```
grep -r -A 10 chained_irq_enter drivers/pinctrl
```
Cc: stable(a)vger.kernel.org
Signed-off-by: Sergey Matsievskiy <matsievskiysv(a)gmail.com>
Reviewed-by: Alexandre Belloni <alexandre.belloni(a)bootlin.com>
Link: https://lore.kernel.org/20241012105743.12450-2-matsievskiysv@gmail.com
Signed-off-by: Linus Walleij <linus.walleij(a)linaro.org>
Conflicts:
drivers/pinctrl/pinctrl-ocelot.c
[Fix context conflicts.]
Signed-off-by: Zeng Heng <zengheng4(a)huawei.com>
---
drivers/pinctrl/pinctrl-ocelot.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-ocelot.c b/drivers/pinctrl/pinctrl-ocelot.c
index a4a1b00f7f0d..e8ee2ade5293 100644
--- a/drivers/pinctrl/pinctrl-ocelot.c
+++ b/drivers/pinctrl/pinctrl-ocelot.c
@@ -1097,22 +1097,21 @@ static void ocelot_irq_handler(struct irq_desc *desc)
unsigned int reg = 0, irq, i;
unsigned long irqs;
+ chained_irq_enter(parent_chip, desc);
+
for (i = 0; i < info->stride; i++) {
regmap_read(info->map, id_reg + 4 * i, ®);
if (!reg)
continue;
- chained_irq_enter(parent_chip, desc);
-
irqs = reg;
for_each_set_bit(irq, &irqs,
min(32U, info->desc->npins - 32 * i))
generic_handle_irq(irq_linear_revmap(chip->irq.domain,
irq + 32 * i));
-
- chained_irq_exit(parent_chip, desc);
}
+ chained_irq_exit(parent_chip, desc);
}
static int ocelot_gpiochip_register(struct platform_device *pdev,
--
2.25.1
Hi liuyun,
FYI, the error/warning still remains.
tree: https://gitee.com/openeuler/kernel.git OLK-6.6
head: e2e6e833f0e931accd24012488ed312ed9f63150
commit: 47a0b6f372d7f05822d021f86b21a34fd2142225 [1466/1466] cpufreq: Add cpufreq driver for LoongArch
config: loongarch-randconfig-r053-20241114 (https://download.01.org/0day-ci/archive/20241125/202411251114.dtutDKWn-lkp@…)
compiler: loongarch64-linux-gcc (GCC) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20241125/202411251114.dtutDKWn-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/202411251114.dtutDKWn-lkp@intel.com/
All errors (new ones prefixed by >>):
loongarch64-linux-ld: drivers/cpufreq/loongson3-acpi-cpufreq.o: in function `loongson3_cpufreq_cpu_exit':
>> loongson3-acpi-cpufreq.c:(.text+0x5b4): undefined reference to `acpi_processor_unregister_performance'
loongarch64-linux-ld: drivers/cpufreq/loongson3-acpi-cpufreq.o: in function `.L231':
>> loongson3-acpi-cpufreq.c:(.text+0x1ba8): undefined reference to `acpi_processor_register_performance'
loongarch64-linux-ld: drivers/cpufreq/loongson3-acpi-cpufreq.o: in function `.L276':
loongson3-acpi-cpufreq.c:(.text+0x225c): undefined reference to `acpi_processor_unregister_performance'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
From: Julian Sun <sunjunchao2870(a)gmail.com>
stable inclusion
from stable-v4.19.322
commit 6cc13a80a26e6b48f78c725c01b91987d61563ef
category: bugfix
bugzilla: https://gitee.com/openeuler/kernel/issues/IB6P4H
Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
--------------------------------
commit 88b1afbf0f6b221f6c5bb66cc80cd3b38d696687 upstream.
Hi, all
Recently I noticed a bug[1] in btrfs, after digged it into
and I believe it'a race in vfs.
Let's assume there's a inode (ie ino 261) with i_count 1 is
called by iput(), and there's a concurrent thread calling
generic_shutdown_super().
cpu0: cpu1:
iput() // i_count is 1
->spin_lock(inode)
->dec i_count to 0
->iput_final() generic_shutdown_super()
->__inode_add_lru() ->evict_inodes()
// cause some reason[2] ->if (atomic_read(inode->i_count)) continue;
// return before // inode 261 passed the above check
// list_lru_add_obj() // and then schedule out
->spin_unlock()
// note here: the inode 261
// was still at sb list and hash list,
// and I_FREEING|I_WILL_FREE was not been set
btrfs_iget()
// after some function calls
->find_inode()
// found the above inode 261
->spin_lock(inode)
// check I_FREEING|I_WILL_FREE
// and passed
->__iget()
->spin_unlock(inode) // schedule back
->spin_lock(inode)
// check (I_NEW|I_FREEING|I_WILL_FREE) flags,
// passed and set I_FREEING
iput() ->spin_unlock(inode)
->spin_lock(inode) ->evict()
// dec i_count to 0
->iput_final()
->spin_unlock()
->evict()
Now, we have two threads simultaneously evicting
the same inode, which may trigger the BUG(inode->i_state & I_CLEAR)
statement both within clear_inode() and iput().
To fix the bug, recheck the inode->i_count after holding i_lock.
Because in the most scenarios, the first check is valid, and
the overhead of spin_lock() can be reduced.
If there is any misunderstanding, please let me know, thanks.
[1]: https://lore.kernel.org/linux-btrfs/000000000000eabe1d0619c48986@google.com/
[2]: The reason might be 1. SB_ACTIVE was removed or 2. mapping_shrinkable()
return false when I reproduced the bug.
Reported-by: syzbot+67ba3c42bcbb4665d3ad(a)syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=67ba3c42bcbb4665d3ad
CC: stable(a)vger.kernel.org
Fixes: 63997e98a3be ("split invalidate_inodes()")
Signed-off-by: Julian Sun <sunjunchao2870(a)gmail.com>
Link: https://lore.kernel.org/r/20240823130730.658881-1-sunjunchao2870@gmail.com
Reviewed-by: Jan Kara <jack(a)suse.cz>
Signed-off-by: Christian Brauner <brauner(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Zizhi Wo <wozizhi(a)huawei.com>
---
fs/inode.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/fs/inode.c b/fs/inode.c
index ae9d7b84caf3..399d79043a39 100644
--- a/fs/inode.c
+++ b/fs/inode.c
@@ -616,6 +616,10 @@ void evict_inodes(struct super_block *sb)
continue;
spin_lock(&inode->i_lock);
+ if (atomic_read(&inode->i_count)) {
+ spin_unlock(&inode->i_lock);
+ continue;
+ }
if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE)) {
spin_unlock(&inode->i_lock);
continue;
--
2.46.1