From: David Sterba <dsterba@suse.cz>
To: fdmanana@kernel.org
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: fix infinite directory reads
Date: Mon, 14 Aug 2023 16:18:36 +0200 [thread overview]
Message-ID: <20230814141836.GD2420@twin.jikos.cz> (raw)
In-Reply-To: <c9ceb0e15d92d0634600603b38965d9b6d986b6d.1691923900.git.fdmanana@suse.com>
On Sun, Aug 13, 2023 at 12:34:08PM +0100, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> The readdir implementation currently processes always up to the last index
> it finds. This however can result in an infinite loop if the directory has
> a large number of entries such that they won't all fit in the given buffer
> passed to the readdir callback, that is, dir_emit() returns a non-zero
> value. Because in that case readdir() will be called again and if in the
> meanwhile new directory entries were added and we still can't put all the
> remaining entries in the buffer, we keep repeating this over and over.
>
> The following C program and test script reproduce the problem:
>
> $ cat /mnt/readdir_prog.c
> #include <sys/types.h>
> #include <dirent.h>
> #include <stdio.h>
>
> int main(int argc, char *argv[])
> {
> DIR *dir = opendir(".");
> struct dirent *dd;
>
> while ((dd = readdir(dir))) {
> printf("%s\n", dd->d_name);
> rename(dd->d_name, "TEMPFILE");
> rename("TEMPFILE", dd->d_name);
> }
> closedir(dir);
> }
>
> $ gcc -o /mnt/readdir_prog /mnt/readdir_prog.c
>
> $ cat test.sh
> #!/bin/bash
>
> DEV=/dev/sdi
> MNT=/mnt/sdi
>
> mkfs.btrfs -f $DEV &> /dev/null
> #mkfs.xfs -f $DEV &> /dev/null
> #mkfs.ext4 -F $DEV &> /dev/null
>
> mount $DEV $MNT
>
> mkdir $MNT/testdir
> for ((i = 1; i <= 2000; i++)); do
> echo -n > $MNT/testdir/file_$i
> done
>
> cd $MNT/testdir
> /mnt/readdir_prog
>
> cd /mnt
>
> umount $MNT
>
> This behaviour is surprising to applications and it's unlike ext4, xfs,
> tmpfs, vfat and other filesystems, which always finish. In this case where
> new entries were added due to renames, some file names may be reported
> more than once, but this varies according to each filesystem - for example
> ext4 never reported the same file more than once while xfs reports the
> first 13 file names twice.
>
> So change our readdir implementation to track the last index number when
> opendir() is called and then make readdir() never process beyond that
> index number. This gives the same behaviour as ext4.
>
> Reported-by: Rob Landley <rob@landley.net>
> Link: https://lore.kernel.org/linux-btrfs/2c8c55ec-04c6-e0dc-9c5c-8c7924778c35@landley.net/
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217681
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Added to misc-next, thanks.
next prev parent reply other threads:[~2023-08-14 14:25 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-13 11:34 [PATCH] btrfs: fix infinite directory reads fdmanana
2023-08-13 18:23 ` Filipe Manana
2023-08-14 14:18 ` David Sterba [this message]
2024-01-24 22:55 ` Eugeniu Rosca
2024-01-25 12:04 ` Filipe Manana
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230814141836.GD2420@twin.jikos.cz \
--to=dsterba@suse.cz \
--cc=fdmanana@kernel.org \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox