On 10/16/22 19:21, Bagas Sanjaya wrote:
On 10/16/22 03:59, Phillip Lougher wrote:
Which identified the "squashfs: support reading fragments in readahead call" patch.
There is a race-condition introduced in that patch, which involves cache releasing and reuse.
The following diff will fix that race-condition. It would be great if someone could test and verify before sending it out as a patch.
Thanks
Phillip
diff --git a/fs/squashfs/file.c b/fs/squashfs/file.c index e56510964b22..6cc23178e9ad 100644 --- a/fs/squashfs/file.c +++ b/fs/squashfs/file.c @@ -506,8 +506,9 @@ static int squashfs_readahead_fragment(struct page **page, squashfs_i(inode)->fragment_size); struct squashfs_sb_info *msblk = inode->i_sb->s_fs_info; unsigned int n, mask = (1 << (msblk->block_log - PAGE_SHIFT)) - 1;
- int error = buffer->error;
- if (buffer->error)
- if (error) goto out;
expected += squashfs_i(inode)->fragment_offset; @@ -529,7 +530,7 @@ static int squashfs_readahead_fragment(struct page **page, out: squashfs_cache_put(buffer);
- return buffer->error;
- return error;
} static void squashfs_readahead(struct readahead_control *ractl)
No Verneed warnings so far. However, I need to test for a longer time (a day) to check if any warnings are reported.
Thanks.
Also, since this regression is also found on linux-6.0.y stable branch, don't forget to Cc stable list.
Thanks.
On 16.10.22 14:24, Bagas Sanjaya wrote:
On 10/16/22 19:21, Bagas Sanjaya wrote:
On 10/16/22 03:59, Phillip Lougher wrote:
Which identified the "squashfs: support reading fragments in readahead call" patch.
BTW, Phillip, sorry for specifying the wrong culprit in an earlier mail.
Also, since this regression is also found on linux-6.0.y stable branch, don't forget to Cc stable list.
FWIW, that's afaics not needed (and actually slightly confusing I'd say). That is only important when the problem was introduced in a stable release to make the stable team aware of it, as then they might be willing to revert the culprit if the problem is not present in mainline.
But this problem was introduced in the 6.0 mainline cycle and thus needs to be fixed there first.
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight.
P.P.S.:
#regzbot introduced: b09a7a036d2035b14636c
[Note: this mail is primarily send for documentation purposes and/or for regzbot, my Linux kernel regression tracking bot. That's why I removed most or all folks from the list of recipients, but left any that looked like a mailing lists. These mails usually contain '#forregzbot' in the subject, to make them easy to spot and filter out.]
On 16.10.22 14:43, Thorsten Leemhuis wrote:
#regzbot introduced: b09a7a036d2035b14636c
#regzbot fixed-by: e11c4e088be
linux-stable-mirror@lists.linaro.org