On 05.12.23 13:49, Linux regression tracking (Thorsten Leemhuis) wrote:Hello Thorsten,
[adding a bunch of people and two lists to the recipients, as Konstantin[CCing Linus now as well]
apparently hasn't sent any mail to any lists archived on lore for ~six
weeks; maybe someone knows what's up or is willing to help out]
JFYI for the VFS maintainers and everyone else who might care:
Konstantin afaics still did not look into below regression. Neither did
anyone else afaics.
But Konstantin is still around, as he recently showed up to post a patch
for review:
https://lore.kernel.org/all/667a5bc4-8cb5-47ce-a7f1-749479b25bec@xxxxxxxxxxxxxxxxxxxx/
I replied to it in the hope of catch his attention and make him look at
this regression, but that did not work out.
So it seems we sadly are kinda stuck here. :-/
Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
On 27.11.23 07:18, Thorsten Leemhuis wrote:--
Hi, Thorsten here, the Linux kernel's regression tracker.Konstantin, are you still around? Would be great if you could look into
Konstantin, I noticed a regression report in bugzilla.kernel.org.
Apparently it's cause by a change of yours.
As many (most?) kernel developers don't keep an eye on bugzilla, I
decided to forward it by mail. Note, you have to use bugzilla to reach
the reporter, as I sadly[1] can not CCed them in mails like this.
Quoting from https://bugzilla.kernel.org/show_bug.cgi?id=218180 :
this regression, as this sounds somewhat worrying.
The problem I am facing is the following:See the ticket for more details. It according to the report happens
1. I mount an NTFS partition via NTFS3
2. I create a file
3. I write to the file
4. The file is empty
5. I remount the partition
6. The file has the changes I made before the remount
I can avoid the remount by doing:
sudo sysctl vm.drop_caches=3
still happens with 6.7-rc2, but not with 6.1.y. The reporter bisected
the problem to ad26a9c84510af ("fs/ntfs3: Fixing wrong logic in
attr_set_size and ntfs_fallocate") [v6.2-rc1].
Side note: while briefly checking lore for existing problems caused by
that change I noticed two syzbot reports about it that apparently nobody
looked into:
https://lore.kernel.org/all/000000000000bdf37505f1a7fc09@xxxxxxxxxx/
https://lore.kernel.org/all/00000000000062174006016bc386@xxxxxxxxxx/
[...]
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.
#regzbot poke