From: Shuah Khan <skhan@linuxfoundation.org>
To: zhouyuhang <zhouyuhang1010@163.com>,
brauner@kernel.org, sforshee@kernel.org, shuah@kernel.org
Cc: linux-fsdevel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-kernel@vger.kernel.org, zhouyuhang <zhouyuhang@kylinos.cn>,
Shuah Khan <skhan@linuxfoundation.org>
Subject: Re: [PATCH] selftests/mount_setattr: fix idmap_mount_tree_invalid failed to run
Date: Sat, 26 Oct 2024 18:21:23 -0600 [thread overview]
Message-ID: <f8dbd839-9072-4159-970d-bb87fe2ebf04@linuxfoundation.org> (raw)
In-Reply-To: <afe66b04-3990-457c-ad43-9b5370a815d6@163.com>
On 10/25/24 02:08, zhouyuhang wrote:
>
>
> 在 2024/10/24 22:26, Shuah Khan 写道:
>> On 10/24/24 03:50, zhouyuhang wrote:
>>> From: zhouyuhang <zhouyuhang@kylinos.cn>
>>>
>>> Test case idmap_mount_tree_invalid failed to run on the newer kernel
>>> with the following output:
>>>
>>> # RUN mount_setattr_idmapped.idmap_mount_tree_invalid ...
>>> # mount_setattr_test.c:1428:idmap_mount_tree_invalid:Expected sys_mount_setattr(open_tree_fd, "", AT_EMPTY_PATH, &attr, sizeof(attr)) (0) ! = 0 (0)
>>> # idmap_mount_tree_invalid: Test terminated by assertion
>>>
>>> This is because tmpfs is mounted at "/mnt/A", and tmpfs already
>>> contains the flag FS_ALLOW_IDMAP after the commit 7a80e5b8c6fa ("shmem:
>>> support idmapped mounts for tmpfs"). So calling sys_mount_setattr here
>>> returns 0 instead of -EINVAL as expected.
>>>
>>> Ramfs is mounted at "/mnt/B" and does not support idmap mounts.
>>> So we can use "/mnt/B" instead of "/mnt/A" to make the test run
>>> successfully with the following output:
>>>
>>> # Starting 1 tests from 1 test cases.
>>> # RUN mount_setattr_idmapped.idmap_mount_tree_invalid ...
>>> # OK mount_setattr_idmapped.idmap_mount_tree_invalid
>>> ok 1 mount_setattr_idmapped.idmap_mount_tree_invalid
>>> # PASSED: 1 / 1 tests passed.
>>>
>>
>> Sounds like this code is testing this very condition passing
>> in invalid mount to see what happens. If that is the intent
>> this patch is incorrect.
>>
>
> I think I probably understand what you mean, what you're saying is that the output of this line of errors is the condition,
> and the main purpose of the test case is to see what happens when it invalid mount. But it's valid now, isn't it?
> So we need to fix it. I don't think that constructing this error with ramfs will have any impact on the code that follows.
> If you feel that using "/mnt/B" is unreliable, I think we can temporarily mount ramfs to "/mnt/A" here and continue using "/mnt/A".
> Do you think this is feasible? Looking forward to your reply, thank you.
>
What I am saying is if this test is intended to test invalid mounts, passing
"/mnt/A" makes perfect sense.
>>> Signed-off-by: zhouyuhang <zhouyuhang@kylinos.cn>
>>> ---
>>> tools/testing/selftests/mount_setattr/mount_setattr_test.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/tools/testing/selftests/mount_setattr/mount_setattr_test.c b/tools/testing/selftests/mount_setattr/mount_setattr_test.c
>>> index c6a8c732b802..54552c19bc24 100644
>>> --- a/tools/testing/selftests/mount_setattr/mount_setattr_test.c
>>> +++ b/tools/testing/selftests/mount_setattr/mount_setattr_test.c
>>> @@ -1414,7 +1414,7 @@ TEST_F(mount_setattr_idmapped, idmap_mount_tree_invalid)
>>> ASSERT_EQ(expected_uid_gid(-EBADF, "/tmp/B/b", 0, 0, 0), 0);
>>> ASSERT_EQ(expected_uid_gid(-EBADF, "/tmp/B/BB/b", 0, 0, 0), 0);
>>> - open_tree_fd = sys_open_tree(-EBADF, "/mnt/A",
>>> + open_tree_fd = sys_open_tree(-EBADF, "/mnt/B",
>>> AT_RECURSIVE |
>>> AT_EMPTY_PATH |
>>> AT_NO_AUTOMOUNT |
>>
>> thanks,
>> -- Shuah
>
thanks,
-- Shuah
prev parent reply other threads:[~2024-10-27 0:21 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-24 9:50 [PATCH] selftests/mount_setattr: fix idmap_mount_tree_invalid failed to run zhouyuhang
2024-10-24 14:26 ` Shuah Khan
2024-10-25 8:08 ` zhouyuhang
2024-10-27 0:21 ` Shuah Khan [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=f8dbd839-9072-4159-970d-bb87fe2ebf04@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=brauner@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=sforshee@kernel.org \
--cc=shuah@kernel.org \
--cc=zhouyuhang1010@163.com \
--cc=zhouyuhang@kylinos.cn \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.