[LTP] LTP: mount02 was expected EINVAL(22) but got ENOENT(2): No such file or directory

[Xiao Yang]

On 2019/03/14 16:23, Jan Stancek wrote:
> ----- Original Message -----
>> Hi Jan,
>>
>> Thanks for looking into this.
>>
>> On Wed, 13 Mar 2019 at 20:59, Jan Stancek<jstancek@redhat.com>  wrote:
>>>
>>> ----- Original Message -----
>>>> LTP syscalls mount02 failed on mainline (Linux version 5.0.0) for all
>>>> devices.
>>>>
>>>> Results comparison link,
>>>> https://qa-reports.linaro.org/lkft/linux-mainline-oe/tests/ltp-syscalls-tests/mount02
>>>> you could see good and bad commit id in the above link.
>>> OK, so it's not "5.0.0" that fails, it's 5.0.0+ (5.0.0 + patches for
>>> 5.1.0-rc1)
>>>
>>> I'm guessing this part:
>>>    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/fs/super.c#n1470
>>> called by do_new_mount().
>>>
>> You are guess is right,
>> Here is the kernel commit changing the error code from EINVAL to ENOENT.
> (TLDR version)
> We are talking about this:
>    mount(NULL, "mntpoint", "ext2", 0, NULL) = -1 EINVAL (Invalid argument)
> now giving ENOENT.
>
> Per man-page, ENOTBLK seems to fit more:
>    ENOTBLK - source is not a block device (and a device was required).
>
>> With this change we have to modify our test code.
> And probably just accept both errnos (when this makes it to 5.1)
Hi Jan,

Does you or Al Viro plan to replace ENOENT with ENOTBLK recently?
It seems that ENOENT still exists on v5.1-rc5.

Best Regards,
Xiao Yang
>>  From f3a09c92018a91ad0981146a4ac59414f814d801 Mon Sep 17 00:00:00 2001
>> From: Al Viro<viro@zeniv.linux.org.uk>
>> Date: Sun, 23 Dec 2018 18:55:56 -0500
>> Subject: introduce fs_context methods
>>
>> Signed-off-by: Al Viro<viro@zeniv.linux.org.uk>
>> ---
>>   fs/super.c | 36 ++++++++++++++++++++++++++++--------
>>   1 file changed, 28 insertions(+), 8 deletions(-)
>>
>> (limited to 'fs/super.c')
>>
>> diff --git a/fs/super.c b/fs/super.c
>> index 5055323..76b3181 100644
>> --- a/fs/super.c
>> +++ b/fs/super.c
>> @@ -894,13 +894,15 @@ int reconfigure_super(struct fs_context *fc)
>>    }
>>    }
>>
>> - retval = legacy_reconfigure(fc);
>> - if (retval) {
>> - if (!force)
>> - goto cancel_readonly;
>> - /* If forced remount, go ahead despite any errors */
>> - WARN(1, "forced remount of a %s fs returned %i\n",
>> -     sb->s_type->name, retval);
>> + if (fc->ops->reconfigure) {
>> + retval = fc->ops->reconfigure(fc);
>> + if (retval) {
>> + if (!force)
>> + goto cancel_readonly;
>> + /* If forced remount, go ahead despite any errors */
>> + WARN(1, "forced remount of a %s fs returned %i\n",
>> +     sb->s_type->name, retval);
>> + }
>>    }
>>
>>    WRITE_ONCE(sb->s_flags, ((sb->s_flags&  ~fc->sb_flags_mask) |
>> @@ -1294,10 +1296,28 @@ int vfs_get_tree(struct fs_context *fc)
>>    struct super_block *sb;
>>    int error;
>>
>> - error = legacy_get_tree(fc);
>> + if (fc->fs_type->fs_flags&  FS_REQUIRES_DEV&&  !fc->source)
>> + return -ENOENT;
>> +
>> + if (fc->root)
>> + return -EBUSY;
>> +
>> + /* Get the mountable root in fc->root, with a ref on the root and a ref
>> + * on the superblock.
>> + */
>> + error = fc->ops->get_tree(fc);
>>    if (error<  0)
>>    return error;
>>
>> + if (!fc->root) {
>> + pr_err("Filesystem %s get_tree() didn't set fc->root\n",
>> +       fc->fs_type->name);
>> + /* We don't know what the locking state of the superblock is -
>> + * if there is a superblock.
>> + */
>> + BUG();
>> + }
>> +
>>    sb = fc->root->d_sb;
>>    WARN_ON(!sb->s_bdi);
>>
>>
>> --
>> cgit v1.1
>>