From: Chuck Lever III <chuck.lever@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Chuck Lever <cel@kernel.org>, Hugh Dickens <hughd@google.com>,
Christian Brauner <brauner@kernel.org>,
Al Viro <viro@zeniv.linux.org.uk>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
linux-mm <linux-mm@kvack.org>, "yukuai (C)" <yukuai3@huawei.com>,
"yangerkun@huaweicloud.com" <yangerkun@huaweicloud.com>
Subject: Re: [RFC PATCH v2 0/5] Improve simple directory offset wrap behavior
Date: Tue, 26 Nov 2024 16:59:29 +0000 [thread overview]
Message-ID: <06324349-4C36-427C-AEFB-70ABC1DF4E7D@oracle.com> (raw)
In-Reply-To: <Z0X2PAZy04JGjjFN@infradead.org>
> On Nov 26, 2024, at 11:24 AM, Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Nov 26, 2024 at 10:54:39AM -0500, cel@kernel.org wrote:
>> From: Chuck Lever <chuck.lever@oracle.com>
>>
>> This series attempts to narrow some gaps in the current tmpfs
>> directory offset mechanism that relate to misbehaviors reported by
>> Yu Kuai <yukuai3@huawei.com> and Yang Erkun <yangerkun@huawei.com>.
>
> Any chance you could write xfstests test cases to exercise these
> corner cases?
generic/736 exercises the readdir loop after rename.
Kuai's test requires kernel code changes to reduce the
range of directory offset values that tmpfs can assign.
Triggering an offset value wrap with the mtree offset
allocator is not possible in millions of years.
I'll have to think about how that can be made into an
automatible test.
--
Chuck Lever
prev parent reply other threads:[~2024-11-26 17:00 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-26 15:54 cel
2024-11-26 15:54 ` [RFC PATCH v2 1/5] libfs: Return ENOSPC when the directory offset range is exhausted cel
2024-11-27 3:11 ` yangerkun
2024-11-26 15:54 ` [RFC PATCH v2 2/5] libfs: Check dentry before locking in simple_offset_empty() cel
2024-11-27 3:09 ` yangerkun
2024-11-27 14:36 ` Chuck Lever
2024-11-29 8:17 ` yangerkun
2024-11-30 17:03 ` Chuck Lever
2024-11-26 15:54 ` [RFC PATCH v2 3/5] Revert "libfs: fix infinite directory reads for offset dir" cel
2024-11-26 15:54 ` [RFC PATCH v2 4/5] libfs: Refactor end-of-directory detection for simple_offset directories cel
2024-11-26 15:54 ` [RFC PATCH v2 5/5] libfs: Refactor offset_iterate_dir() cel
2024-11-26 16:24 ` [RFC PATCH v2 0/5] Improve simple directory offset wrap behavior Christoph Hellwig
2024-11-26 16:59 ` Chuck Lever III [this message]
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=06324349-4C36-427C-AEFB-70ABC1DF4E7D@oracle.com \
--to=chuck.lever@oracle.com \
--cc=brauner@kernel.org \
--cc=cel@kernel.org \
--cc=hch@infradead.org \
--cc=hughd@google.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=viro@zeniv.linux.org.uk \
--cc=yangerkun@huaweicloud.com \
--cc=yukuai3@huawei.com \
/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