My best guess so far is that this change caused the regression:
$ git show ab7362d04d7
commit ab7362d04d7c14923420c1e19e889da512a65cd7
Author: David Howells <dhowells@xxxxxxxxxx>
Date: Fri Feb 24 14:31:15 2023 +0000
cifs: Fix cifs_writepages_region()
Fix the cifs_writepages_region() to just jump over members of the batch
that have been cleaned up rather than counting them as skipped.
Unlike the other "skip_write" cases, this situation happens even for
WB_SYNC_ALL, simply because the page has either been cleaned by somebody
else, or was truncated.
So in this case we're not "skipping" the write, we simply no longer need
any write at all, so it's very different from the other skip_write cases.
And we definitely shouldn't stop writing the rest just because of too
many of these cases (or because we want to be rescheduled).
Fixes: 3822a7c40997 ("Merge tag 'mm-stable-2023-02-20-13-37' of
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm")
Signed-off-by: David Howells <dhowells@xxxxxxxxxx>
Link: https://lore.kernel.org/lkml/2213409.1677249075@xxxxxxxxxxxxxxxxxxxxxx/
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 5365a3299088..ebfcaae8c437 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -2893,8 +2893,9 @@ static int cifs_writepages_region(struct
address_space *mapping,
if (folio_mapping(folio) != mapping ||
!folio_test_dirty(folio)) {
+ start += folio_size(folio);
folio_unlock(folio);
- goto skip_write;
+ continue;
}
if (folio_test_writeback(folio) ||
On Tue, Feb 6, 2024 at 2:22 AM David Howells <dhowells@xxxxxxxxxx> wrote:
>
> R. Diez <rdiez-2006@xxxxxxx> wrote:
>
> > > Out of interest, are you able to try an arbitrary kernel?
> >
> > I'm afraid that is beyond my Linux Kernel abilities. I am just a user able to poke in some configuration files, and maybe fight a little with Synaptic / APT.
> >
> > But maybe the Ubuntu guys can. You can reach the guy doing some extra testing here:
> >
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2049634
>
> No worries. Steve can probably try that.
>
> Thanks,
> David
>
--
Thanks,
Steve
