Received-SPF: pass (google.com: domain of linux-kernel+bounces-40118-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Message-ID: <97660d80-fbea-4eb8-83af-78f59a6302c7@paragon-software.com>
Date: Fri, 26 Jan 2024 15:57:35 +0300
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [regressions] ntfs3: empty file on update without forced cache
 drop
Content-Language: en-US
To: Linux regressions mailing list <regressions@lists.linux.dev>, Alexander
 Viro <viro@zeniv.linux.org.uk>, Christian Brauner <brauner@kernel.org>
CC: <ntfs3@lists.linux.dev>, Kari Argillander
	<kari.argillander@stargateuniverse.net>, Linux-fsdevel
	<linux-fsdevel@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>, Anton
 Altaparmakov <anton@tuxera.com>, Linus Torvalds
	<torvalds@linux-foundation.org>
References: <138ed123-0f84-4d7a-8a17-67fe2418cf29@leemhuis.info>
 <24aa7a8b-40ed-449b-a722-df4abf65f114@leemhuis.info>
 <d5f4c2d7-0a98-4ff8-9848-a34133199450@leemhuis.info>
From: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
In-Reply-To: <d5f4c2d7-0a98-4ff8-9848-a34133199450@leemhuis.info>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit

On 21.01.2024 12:14, Thorsten Leemhuis wrote:
> On 05.12.23 13:49, Linux regression tracking (Thorsten Leemhuis) wrote:
>> [adding a bunch of people and two lists to the recipients, as Konstantin
>> 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]
> [CCing Linus now as well]
>
> 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@paragon-software.com/
>
> 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, 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 :
>> Konstantin, are you still around? Would be great if you could look into
>> this regression, as this sounds somewhat worrying.
>>
>>>> The problem I am facing is the following:
>>>> 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
>>> See the ticket for more details. It according to the report happens
>>> 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@google.com/
>>> https://lore.kernel.org/all/00000000000062174006016bc386@google.com/
>>> [...]
> --
> 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
Hello Thorsten,

I apologize for the horrible delay in responding to the bug. I was able 
to reproduce it in a scenario involving a compressed file. The patch 
will be ready within the next few days (the response in Bugzilla will 
also follow).

Best regards,
Konstantin