On Thu, Feb 06, 2025 at 06:45:42PM GMT, David Sterba wrote:
> On Thu, Feb 06, 2025 at 03:31:02PM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Feb 06, 2025 at 08:41:33PM +0900, Koichiro Den wrote:
> > > On Mon, Dec 30, 2024 at 04:43:39PM GMT, Greg Kroah-Hartman wrote:
> > > >
> > >
> > > Hi, please let me confirm; is this backport really ok? I mean, should the
> > > cond_resched() be added to btrfs_swap_activate() loop? I was able to
> > > reproduce the same situation:
> > >
> > > $ git rev-parse HEAD
> > > 319addc2ad901dac4d6cc931d77ef35073e0942f
> > > $ b4 mbox --single-message c37ea7a8de12e996091ba295b2f201fbe680c96c.1733929328.git.fdmanana@xxxxxxxx
> > > 1 messages in the thread
> > > Saved ./c37ea7a8de12e996091ba295b2f201fbe680c96c.1733929328.git.fdmanana@xxxxxxxxxxxx
> > > $ patch -p1 < ./c37ea7a8de12e996091ba295b2f201fbe680c96c.1733929328.git.fdmanana@xxxxxxxxxxxx
> > > patching file fs/btrfs/inode.c
> > > Hunk #1 succeeded at 7117 with fuzz 1 (offset -2961 lines).
> > > $ git diff
> > > diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> > > index 58ffe78132d9..6fe2ac620464 100644
> > > --- a/fs/btrfs/inode.c
> > > +++ b/fs/btrfs/inode.c
> > > @@ -7117,6 +7117,8 @@ noinline int can_nocow_extent(struct inode *inode, u64 offset, u64 *len,
> > > ret = -EAGAIN;
> > > goto out;
> > > }
> > > +
> > > + cond_resched();
> > > }
> > >
> > > if (file_extent)
> > >
> > > The same goes for all the other stable branches applied. Sorry if I'm
> > > missing something.
> >
> > Hm, looks like patch messed this up :(
>
> The fix is part of 4 patch series. The stable tree 6.12 has only 3 and
> in different order, so this one fails to apply due to missing context
> and got applied to the wrong function.
>
> Applying all 4 in order to 6.12.y (same base commit f6279a98db132da0cff)
> works without conflicts.
>
> $ git cherry-pick 0525064bb82e50d59543b62b9d41a606198a4a44
> Auto-merging fs/btrfs/inode.c
> [detached HEAD 0466e0dbbb99] btrfs: fix race with memory mapped writes when activating swap file
> Author: Filipe Manana <fdmanana@xxxxxxxx>
> Date: Fri Nov 29 12:25:30 2024 +0000
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> $ git cherry-pick 03018e5d8508254534511d40fb57bc150e6a87f2
> Auto-merging fs/btrfs/inode.c
> [detached HEAD 1715e6abcf46] btrfs: fix swap file activation failure due to extents that used to be shared
> Author: Filipe Manana <fdmanana@xxxxxxxx>
> Date: Mon Dec 9 12:54:14 2024 +0000
> 1 file changed, 69 insertions(+), 27 deletions(-)
>
> $ git cherry-pick 9a45022a0efadd99bcc58f7f1cc2b6fb3b808c40
> Auto-merging fs/btrfs/inode.c
> [detached HEAD 78d50f8c8827] btrfs: allow swap activation to be interruptible
> Author: Filipe Manana <fdmanana@xxxxxxxx>
> Date: Mon Dec 9 16:31:41 2024 +0000
> 1 file changed, 5 insertions(+)
>
> $ git cherry-pick 2c8507c63f5498d4ee4af404a8e44ceae4345056
> Auto-merging fs/btrfs/inode.c
> [detached HEAD a162d2371965] btrfs: avoid monopolizing a core when activating a swap file
> Author: Filipe Manana <fdmanana@xxxxxxxx>
> Date: Mon Dec 9 16:43:44 2024 +0000
> 1 file changed, 2 insertions(+)
>
> I have more trust in git patch logic than 'patch', this can happen in the
> future again.
As a side node, I just recently observed a quite similar pattern elsewhere.
Unfortunately, by the time I discovered it, the 6.11.y had already reached
EOL, so I didn't have an opportunity to report it for fixing.
The following upstream commits landed in the stable queue and were applied to 6.11.y
in reverse order (i.e. applied as #2 then #1):
#1. f3fe8c52c580 ("iio: adc: ti-lmp92064: add missing select REGMAP_SPI in Kconfig")
#2. a985576af824 ("iio: adc: ti-lmp92064: add missing select IIO_(TRIGGERED_)BUFFER in Kconfig")
that appears to have resulted in the backport for #2 being broken.
(see https://lore.kernel.org/stable/20241021102302.767569469@xxxxxxxxxxxxxxxxxxx/)
Since there seems no "FAILED to apply" announcement, I assume this was
handled by normal patch(1) usage. Just as an extra side note, #2 seems to
have been applied twice on the branch.
So, even though the patch reordering and patch application strategy are
essentially seperate issues, I tend to agree that when the latter causes
problems, it sometimes indicates that an issue with the former is lurking.
Thanks,
Koichiro
