--- /dev/null
+From def33fb1191207f5afa6dcb681d71fef2a6c1293 Mon Sep 17 00:00:00 2001
+From: Dragan Simic <dsimic@manjaro.org>
+Date: Mon, 15 Jul 2024 19:44:20 +0200
+Subject: arm64: dts: rockchip: Correct the Pinebook Pro battery design capacity
+
+From: Dragan Simic <dsimic@manjaro.org>
+
+commit def33fb1191207f5afa6dcb681d71fef2a6c1293 upstream.
+
+All batches of the Pine64 Pinebook Pro, except the latest batch (as of 2024)
+whose hardware design was revised due to the component shortage, use a 1S
+lithium battery whose nominal/design capacity is 10,000 mAh, according to the
+battery datasheet. [1][2] Let's correct the design full-charge value in the
+Pinebook Pro board dts, to improve the accuracy of the hardware description,
+and to hopefully improve the accuracy of the fuel gauge a bit on all units
+that don't belong to the latest batch.
+
+The above-mentioned latest batch uses a different 1S lithium battery with
+a slightly lower capacity, more precisely 9,600 mAh. To make the fuel gauge
+work reliably on the latest batch, a sample battery would need to be sent to
+CellWise, to obtain its proprietary battery profile, whose data goes into
+"cellwise,battery-profile" in the Pinebook Pro board dts. Without that data,
+the fuel gauge reportedly works unreliably, so changing the design capacity
+won't have any negative effects on the already unreliable operation of the
+fuel gauge in the Pinebook Pros that belong to the latest batch.
+
+According to the battery datasheet, its voltage can go as low as 2.75 V while
+discharging, but it's better to leave the current 3.0 V value in the dts file,
+because of the associated Pinebook Pro's voltage regulation issues.
+
+[1] https://wiki.pine64.org/index.php/Pinebook_Pro#Battery
+[2] https://files.pine64.org/doc/datasheet/pinebook/40110175P%203.8V%2010000mAh%E8%A7%84%E6%A0%BC%E4%B9%A6-14.pdf
+
+Fixes: c7c4d698cd28 ("arm64: dts: rockchip: add fuel gauge to Pinebook Pro dts")
+Cc: stable@vger.kernel.org
+Cc: Marek Kraus <gamiee@pine64.org>
+Signed-off-by: Dragan Simic <dsimic@manjaro.org>
+Link: https://lore.kernel.org/r/731f8ef9b1a867bcc730d19ed277c8c0534c0842.1721065172.git.dsimic@manjaro.org
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+@@ -30,7 +30,7 @@
+
+ bat: battery {
+ compatible = "simple-battery";
+- charge-full-design-microamp-hours = <9800000>;
++ charge-full-design-microamp-hours = <10000000>;
+ voltage-max-design-microvolt = <4350000>;
+ voltage-min-design-microvolt = <3000000>;
+ };
--- /dev/null
+From 8c51521de18755d4112a77a598a348b38d0af370 Mon Sep 17 00:00:00 2001
+From: Dragan Simic <dsimic@manjaro.org>
+Date: Sun, 4 Aug 2024 23:10:24 +0200
+Subject: arm64: dts: rockchip: Raise Pinebook Pro's panel backlight PWM frequency
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Dragan Simic <dsimic@manjaro.org>
+
+commit 8c51521de18755d4112a77a598a348b38d0af370 upstream.
+
+Increase the frequency of the PWM signal that drives the LED backlight of
+the Pinebook Pro's panel, from about 1.35 KHz (which equals to the PWM
+period of 740,740 ns), to exactly 8 kHz (which equals to the PWM period of
+125,000 ns). Using a higher PWM frequency for the panel backlight, which
+reduces the flicker, can only be beneficial to the end users' eyes.
+
+On top of that, increasing the backlight PWM signal frequency reportedly
+eliminates the buzzing emitted from the Pinebook Pro's built-in speakers
+when certain backlight levels are set, which cause some weird interference
+with some of the components of the Pinebook Pro's audio chain.
+
+The old value for the backlight PWM period, i.e. 740,740 ns, is pretty much
+an arbitrary value that was selected during the very early bring-up of the
+Pinebook Pro, only because that value seemed to minimize horizontal line
+distortion on the display, which resulted from the old X.org drivers causing
+screen tearing when dragging windows around. That's no longer an issue, so
+there are no reasons to stick with the old PWM period value.
+
+The lower and the upper backlight PWM frequency limits for the Pinebook Pro's
+panel, according to its datasheet, are 200 Hz and 10 kHz, respectively. [1]
+These changes still leave some headroom, which may have some positive effects
+on the lifetime expectancy of the panel's backlight LEDs.
+
+[1] https://files.pine64.org/doc/datasheet/PinebookPro/NV140FHM-N49_Rev.P0_20160804_201710235838.pdf
+
+Fixes: 5a65505a6988 ("arm64: dts: rockchip: Add initial support for Pinebook Pro")
+Cc: stable@vger.kernel.org
+Reported-by: Nikola Radojevic <nikola@radojevic.rs>
+Signed-off-by: Dragan Simic <dsimic@manjaro.org>
+Tested-by: Nikola Radojević <nikola@radojevic.rs>
+Link: https://lore.kernel.org/r/2a23b6cfd8c0513e5b233b4006ee3d3ed09b824f.1722805655.git.dsimic@manjaro.org
+Signed-off-by: Heiko Stuebner <heiko@sntech.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
++++ b/arch/arm64/boot/dts/rockchip/rk3399-pinebook-pro.dts
+@@ -25,7 +25,7 @@
+ backlight: edp-backlight {
+ compatible = "pwm-backlight";
+ power-supply = <&vcc_12v>;
+- pwms = <&pwm0 0 740740 0>;
++ pwms = <&pwm0 0 125000 0>;
+ };
+
+ bat: battery {
--- /dev/null
+From 50438dbc483ca6a133d2bce9d5d6747bcee38371 Mon Sep 17 00:00:00 2001
+From: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
+Date: Wed, 24 Jul 2024 10:51:58 -0700
+Subject: f2fs: avoid potential int overflow in sanity_check_area_boundary()
+
+From: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
+
+commit 50438dbc483ca6a133d2bce9d5d6747bcee38371 upstream.
+
+While calculating the end addresses of main area and segment 0, u32
+may be not enough to hold the result without the danger of int
+overflow.
+
+Just in case, play it safe and cast one of the operands to a
+wider type (u64).
+
+Found by Linux Verification Center (linuxtesting.org) with static
+analysis tool SVACE.
+
+Fixes: fd694733d523 ("f2fs: cover large section in sanity check of super")
+Cc: stable@vger.kernel.org
+Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/super.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/f2fs/super.c
++++ b/fs/f2fs/super.c
+@@ -2754,9 +2754,9 @@ static inline bool sanity_check_area_bou
+ u32 segment_count = le32_to_cpu(raw_super->segment_count);
+ u32 log_blocks_per_seg = le32_to_cpu(raw_super->log_blocks_per_seg);
+ u64 main_end_blkaddr = main_blkaddr +
+- (segment_count_main << log_blocks_per_seg);
++ ((u64)segment_count_main << log_blocks_per_seg);
+ u64 seg_end_blkaddr = segment0_blkaddr +
+- (segment_count << log_blocks_per_seg);
++ ((u64)segment_count << log_blocks_per_seg);
+
+ if (segment0_blkaddr != cp_blkaddr) {
+ f2fs_info(sbi, "Mismatch start address, segment0(%u) cp_blkaddr(%u)",
--- /dev/null
+From 47f268f33dff4a5e31541a990dc09f116f80e61c Mon Sep 17 00:00:00 2001
+From: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
+Date: Wed, 24 Jul 2024 10:05:44 -0700
+Subject: f2fs: prevent possible int overflow in dir_block_index()
+
+From: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
+
+commit 47f268f33dff4a5e31541a990dc09f116f80e61c upstream.
+
+The result of multiplication between values derived from functions
+dir_buckets() and bucket_blocks() *could* technically reach
+2^30 * 2^2 = 2^32.
+
+While unlikely to happen, it is prudent to ensure that it will not
+lead to integer overflow. Thus, use mul_u32_u32() as it's more
+appropriate to mitigate the issue.
+
+Found by Linux Verification Center (linuxtesting.org) with static
+analysis tool SVACE.
+
+Fixes: 3843154598a0 ("f2fs: introduce large directory support")
+Cc: stable@vger.kernel.org
+Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru>
+Reviewed-by: Chao Yu <chao@kernel.org>
+Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/f2fs/dir.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/f2fs/dir.c
++++ b/fs/f2fs/dir.c
+@@ -183,7 +183,8 @@ static unsigned long dir_block_index(uns
+ unsigned long bidx = 0;
+
+ for (i = 0; i < level; i++)
+- bidx += dir_buckets(i, dir_level) * bucket_blocks(i);
++ bidx += mul_u32_u32(dir_buckets(i, dir_level),
++ bucket_blocks(i));
+ bidx += idx * bucket_blocks(level);
+ return bidx;
+ }
--- /dev/null
+From 26f204380a3c182e5adf1a798db0724d6111b597 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Micka=C3=ABl=20Sala=C3=BCn?= <mic@digikod.net>
+Date: Wed, 21 Aug 2024 11:56:05 +0200
+Subject: fs: Fix file_set_fowner LSM hook inconsistencies
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Mickaël Salaün <mic@digikod.net>
+
+commit 26f204380a3c182e5adf1a798db0724d6111b597 upstream.
+
+The fcntl's F_SETOWN command sets the process that handle SIGIO/SIGURG
+for the related file descriptor. Before this change, the
+file_set_fowner LSM hook was always called, ignoring the VFS logic which
+may not actually change the process that handles SIGIO (e.g. TUN, TTY,
+dnotify), nor update the related UID/EUID.
+
+Moreover, because security_file_set_fowner() was called without lock
+(e.g. f_owner.lock), concurrent F_SETOWN commands could result to a race
+condition and inconsistent LSM states (e.g. SELinux's fown_sid) compared
+to struct fown_struct's UID/EUID.
+
+This change makes sure the LSM states are always in sync with the VFS
+state by moving the security_file_set_fowner() call close to the
+UID/EUID updates and using the same f_owner.lock .
+
+Rename f_modown() to __f_setown() to simplify code.
+
+Cc: stable@vger.kernel.org
+Cc: Al Viro <viro@zeniv.linux.org.uk>
+Cc: Casey Schaufler <casey@schaufler-ca.com>
+Cc: Christian Brauner <brauner@kernel.org>
+Cc: James Morris <jmorris@namei.org>
+Cc: Jann Horn <jannh@google.com>
+Cc: Ondrej Mosnacek <omosnace@redhat.com>
+Cc: Paul Moore <paul@paul-moore.com>
+Cc: Serge E. Hallyn <serge@hallyn.com>
+Cc: Stephen Smalley <stephen.smalley.work@gmail.com>
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Mickaël Salaün <mic@digikod.net>
+Signed-off-by: Paul Moore <paul@paul-moore.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/fcntl.c | 14 ++++----------
+ 1 file changed, 4 insertions(+), 10 deletions(-)
+
+--- a/fs/fcntl.c
++++ b/fs/fcntl.c
+@@ -84,8 +84,8 @@ static int setfl(int fd, struct file * f
+ return error;
+ }
+
+-static void f_modown(struct file *filp, struct pid *pid, enum pid_type type,
+- int force)
++void __f_setown(struct file *filp, struct pid *pid, enum pid_type type,
++ int force)
+ {
+ write_lock_irq(&filp->f_owner.lock);
+ if (force || !filp->f_owner.pid) {
+@@ -95,19 +95,13 @@ static void f_modown(struct file *filp,
+
+ if (pid) {
+ const struct cred *cred = current_cred();
++ security_file_set_fowner(filp);
+ filp->f_owner.uid = cred->uid;
+ filp->f_owner.euid = cred->euid;
+ }
+ }
+ write_unlock_irq(&filp->f_owner.lock);
+ }
+-
+-void __f_setown(struct file *filp, struct pid *pid, enum pid_type type,
+- int force)
+-{
+- security_file_set_fowner(filp);
+- f_modown(filp, pid, type, force);
+-}
+ EXPORT_SYMBOL(__f_setown);
+
+ int f_setown(struct file *filp, unsigned long arg, int force)
+@@ -143,7 +137,7 @@ EXPORT_SYMBOL(f_setown);
+
+ void f_delown(struct file *filp)
+ {
+- f_modown(filp, NULL, PIDTYPE_TGID, 1);
++ __f_setown(filp, NULL, PIDTYPE_TGID, 1);
+ }
+
+ pid_t f_getown(struct file *filp)
--- /dev/null
+From 4b7acc85de14ee8a2236f54445dc635d47eceac0 Mon Sep 17 00:00:00 2001
+From: Gaosheng Cui <cuigaosheng1@huawei.com>
+Date: Sat, 3 Aug 2024 14:49:23 +0800
+Subject: hwrng: cctrng - Add missing clk_disable_unprepare in cctrng_resume
+
+From: Gaosheng Cui <cuigaosheng1@huawei.com>
+
+commit 4b7acc85de14ee8a2236f54445dc635d47eceac0 upstream.
+
+Add the missing clk_disable_unprepare() before return in
+cctrng_resume().
+
+Fixes: a583ed310bb6 ("hwrng: cctrng - introduce Arm CryptoCell driver")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/hw_random/cctrng.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/char/hw_random/cctrng.c
++++ b/drivers/char/hw_random/cctrng.c
+@@ -679,6 +679,7 @@ static int __maybe_unused cctrng_resume(
+ /* wait for Cryptocell reset completion */
+ if (!cctrng_wait_for_reset_completion(drvdata)) {
+ dev_err(dev, "Cryptocell reset not completed");
++ clk_disable_unprepare(drvdata->clk);
+ return -EBUSY;
+ }
+
--- /dev/null
+From 78cb66caa6ab5385ac2090f1aae5f3c19e08f522 Mon Sep 17 00:00:00 2001
+From: Guoqing Jiang <guoqing.jiang@canonical.com>
+Date: Mon, 26 Aug 2024 15:04:15 +0800
+Subject: hwrng: mtk - Use devm_pm_runtime_enable
+
+From: Guoqing Jiang <guoqing.jiang@canonical.com>
+
+commit 78cb66caa6ab5385ac2090f1aae5f3c19e08f522 upstream.
+
+Replace pm_runtime_enable with the devres-enabled version which
+can trigger pm_runtime_disable.
+
+Otherwise, the below appears during reload driver.
+
+mtk_rng 1020f000.rng: Unbalanced pm_runtime_enable!
+
+Fixes: 81d2b34508c6 ("hwrng: mtk - add runtime PM support")
+Cc: <stable@vger.kernel.org>
+Suggested-by: Chen-Yu Tsai <wenst@chromium.org>
+Signed-off-by: Guoqing Jiang <guoqing.jiang@canonical.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/char/hw_random/mtk-rng.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/char/hw_random/mtk-rng.c
++++ b/drivers/char/hw_random/mtk-rng.c
+@@ -142,7 +142,7 @@ static int mtk_rng_probe(struct platform
+ dev_set_drvdata(&pdev->dev, priv);
+ pm_runtime_set_autosuspend_delay(&pdev->dev, RNG_AUTOSUSPEND_TIMEOUT);
+ pm_runtime_use_autosuspend(&pdev->dev);
+- pm_runtime_enable(&pdev->dev);
++ devm_pm_runtime_enable(&pdev->dev);
+
+ dev_info(&pdev->dev, "registered RNG driver\n");
+
--- /dev/null
+From 8f6a7c9467eaf39da4c14e5474e46190ab3fb529 Mon Sep 17 00:00:00 2001
+From: Li Lingfeng <lilingfeng3@huawei.com>
+Date: Wed, 4 Sep 2024 20:34:57 +0800
+Subject: nfs: fix memory leak in error path of nfs4_do_reclaim
+
+From: Li Lingfeng <lilingfeng3@huawei.com>
+
+commit 8f6a7c9467eaf39da4c14e5474e46190ab3fb529 upstream.
+
+Commit c77e22834ae9 ("NFSv4: Fix a potential sleep while atomic in
+nfs4_do_reclaim()") separate out the freeing of the state owners from
+nfs4_purge_state_owners() and finish it outside the rcu lock.
+However, the error path is omitted. As a result, the state owners in
+"freeme" will not be released.
+Fix it by adding freeing in the error path.
+
+Fixes: c77e22834ae9 ("NFSv4: Fix a potential sleep while atomic in nfs4_do_reclaim()")
+Signed-off-by: Li Lingfeng <lilingfeng3@huawei.com>
+Cc: stable@vger.kernel.org # v5.3+
+Signed-off-by: Anna Schumaker <anna.schumaker@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/nfs/nfs4state.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/fs/nfs/nfs4state.c
++++ b/fs/nfs/nfs4state.c
+@@ -1948,6 +1948,7 @@ restart:
+ set_bit(ops->owner_flag_bit, &sp->so_flags);
+ nfs4_put_state_owner(sp);
+ status = nfs4_recovery_handle_error(clp, status);
++ nfs4_free_state_owners(&freeme);
+ return (status != 0) ? status : -EAGAIN;
+ }
+
--- /dev/null
+From 9a22b2812393d93d84358a760c347c21939029a6 Mon Sep 17 00:00:00 2001
+From: VanGiang Nguyen <vangiang.nguyen@rohde-schwarz.com>
+Date: Fri, 9 Aug 2024 06:21:42 +0000
+Subject: padata: use integer wrap around to prevent deadlock on seq_nr overflow
+
+From: VanGiang Nguyen <vangiang.nguyen@rohde-schwarz.com>
+
+commit 9a22b2812393d93d84358a760c347c21939029a6 upstream.
+
+When submitting more than 2^32 padata objects to padata_do_serial, the
+current sorting implementation incorrectly sorts padata objects with
+overflowed seq_nr, causing them to be placed before existing objects in
+the reorder list. This leads to a deadlock in the serialization process
+as padata_find_next cannot match padata->seq_nr and pd->processed
+because the padata instance with overflowed seq_nr will be selected
+next.
+
+To fix this, we use an unsigned integer wrap around to correctly sort
+padata objects in scenarios with integer overflow.
+
+Fixes: bfde23ce200e ("padata: unbind parallel jobs from specific CPUs")
+Cc: <stable@vger.kernel.org>
+Co-developed-by: Christian Gafert <christian.gafert@rohde-schwarz.com>
+Signed-off-by: Christian Gafert <christian.gafert@rohde-schwarz.com>
+Co-developed-by: Max Ferger <max.ferger@rohde-schwarz.com>
+Signed-off-by: Max Ferger <max.ferger@rohde-schwarz.com>
+Signed-off-by: Van Giang Nguyen <vangiang.nguyen@rohde-schwarz.com>
+Acked-by: Daniel Jordan <daniel.m.jordan@oracle.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ kernel/padata.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/kernel/padata.c
++++ b/kernel/padata.c
+@@ -409,7 +409,8 @@ void padata_do_serial(struct padata_priv
+ /* Sort in ascending order of sequence number. */
+ list_for_each_prev(pos, &reorder->list) {
+ cur = list_entry(pos, struct padata_priv, list);
+- if (cur->seq_nr < padata->seq_nr)
++ /* Compare by difference to consider integer wrap around */
++ if ((signed int)(cur->seq_nr - padata->seq_nr) < 0)
+ break;
+ }
+ list_add(&padata->list, pos);
perf-x86-intel-pt-fix-sampling-synchronization.patch
wifi-rtw88-8822c-fix-reported-rx-band-width.patch
debugobjects-fix-conditions-in-fill_pool.patch
+f2fs-prevent-possible-int-overflow-in-dir_block_index.patch
+f2fs-avoid-potential-int-overflow-in-sanity_check_area_boundary.patch
+hwrng-mtk-use-devm_pm_runtime_enable.patch
+hwrng-cctrng-add-missing-clk_disable_unprepare-in-cctrng_resume.patch
+arm64-dts-rockchip-raise-pinebook-pro-s-panel-backlight-pwm-frequency.patch
+arm64-dts-rockchip-correct-the-pinebook-pro-battery-design-capacity.patch
+vfs-fix-race-between-evice_inodes-and-find_inode-iput.patch
+fs-fix-file_set_fowner-lsm-hook-inconsistencies.patch
+nfs-fix-memory-leak-in-error-path-of-nfs4_do_reclaim.patch
+padata-use-integer-wrap-around-to-prevent-deadlock-on-seq_nr-overflow.patch
--- /dev/null
+From 88b1afbf0f6b221f6c5bb66cc80cd3b38d696687 Mon Sep 17 00:00:00 2001
+From: Julian Sun <sunjunchao2870@gmail.com>
+Date: Fri, 23 Aug 2024 21:07:30 +0800
+Subject: vfs: fix race between evice_inodes() and find_inode()&iput()
+
+From: Julian Sun <sunjunchao2870@gmail.com>
+
+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@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=67ba3c42bcbb4665d3ad
+CC: stable@vger.kernel.org
+Fixes: 63997e98a3be ("split invalidate_inodes()")
+Signed-off-by: Julian Sun <sunjunchao2870@gmail.com>
+Link: https://lore.kernel.org/r/20240823130730.658881-1-sunjunchao2870@gmail.com
+Reviewed-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Christian Brauner <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/inode.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/fs/inode.c
++++ b/fs/inode.c
+@@ -670,6 +670,10 @@ again:
+ 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;
projects / thirdparty / kernel / stable-queue.git / commitdiff
