linux-kernel - Re: [regression] getdents() does not list entries created after opening the directory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b8089429-cff1-41f3-a3ee-a3c345f2289a@heusel.eu>
Date: Tue, 1 Oct 2024 20:59:09 +0200
From: Christian Heusel <christian@...sel.eu>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Krzysztof Małysa <varqox@...il.com>, 
	yangerkun <yangerkun@...wei.com>, Christian Brauner <brauner@...nel.org>, 
	linux-fsdevel@...r.kernel.org, Alexander Viro <viro@...iv.linux.org.uk>, 
	LKML <linux-kernel@...r.kernel.org>, Matthew Wilcox <willy@...radead.org>, 
	linux-btrfs@...r.kernel.org
Subject: Re: [regression] getdents() does not list entries created after
 opening the directory

On 24/10/01 02:49PM, Linux regression tracking (Thorsten Leemhuis) wrote:
> On 01.10.24 14:18, Matthew Wilcox wrote:
> > On Tue, Oct 01, 2024 at 01:29:09PM +0200, Linux regression tracking (Thorsten Leemhuis) wrote:
> >>> 	DIR* dir = opendir("/tmp/dirent-problems-test-dir");
> >>>
> >>> 	fd = creat("/tmp/dirent-problems-test-dir/after", 0644);
> > 
> > "If a file is removed from or added to the directory after the most
> > recent call to opendir() or rewinddir(), whether a subsequent call to
> > readdir() returns an entry for that file is unspecified."
> > 
> > https://pubs.opengroup.org/onlinepubs/007904975/functions/readdir.html
> > 
> > That said, if there's an easy fix here, it'd be a nice improvement to
> > QoI to do it, but the test-case as written is incorrect.
> 
> Many thx Willy!
> 
> Which leads to a question:
> 
> Krzysztof, how did you find the problem? Was there a practical use case
> (some software or workload) with this behavior that broke and made your
> write that test-case? Or is that a test-program older and part of your
> CI tests or something like that?

The above message and the mentioned patch reminded me of an [old
issue][0] that is bothering us in the Arch Linux Infrastructure Team
which makes files vanish if modified during an rsync transaction (which
breaks our mirror infrastructure because it makes the package sync
databases [go missing][1]).

The issue was previously discussed with the BTRFS developers after they
implemented a [similar patch][2] (atleast judging from the title of
both) for their filesystem who also pointed to the standards compliance
after we have complained.

The workload and the issue with it (and how the new behaviour breaks
rsync for our usecase) was [nicely explained][3] by one of the BTRFS
developers.

So going back to the initial question: There could be a practical
usecase this causes a regression for, atleast if the patch has the same
implications as the BTRFS patch has. While we will have to sort out our
issue separately with the BTRFS folks I thought I'd still leave this
information in this thread.

> Ciao, Thorsten

Cheers,
Chris

[0]: https://lore.kernel.org/linux-btrfs/00ed09b9-d60c-4605-b3b6-f4e79bf92fca@foutras.com/
[1]: https://gitlab.archlinux.org/archlinux/infrastructure/-/issues/585
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=9b378f6ad48c
[3]: https://lore.kernel.org/linux-btrfs/ZP8AWKMVYOY0mAwq@debian0.Home/

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)