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

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

[Naresh Kamboju]

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.

Error log,
mount02 5 TFAIL : mount02.c:117: mount() was expected to fail with
EINVAL(22): TEST_ERRNO=ENOENT(2): No such file or directory

Failure full log on x15 armv7,
https://lkft.validation.linaro.org/scheduler/job/638009#L7462

structure Inputs,
{&null, &mntpoint, &fs_type, 0, EINVAL, NULL, NULL},

Snippet  test code:
--------------------------
TEST(mount(*tc->device, *tc->mntpoint, *tc->fs_type, tc->flag, NULL));

if (TEST_RETURN != -1) {
tst_resm(TFAIL, "mount() succeded unexpectedly (ret=%li)",
         TEST_RETURN);
goto cleanup;
}

if (TEST_ERRNO != tc->exp_errno) {
tst_resm(TFAIL | TTERRNO,
         "mount() was expected to fail with %s(%i)",
         tst_strerrno(tc->exp_errno), tc->exp_errno);
goto cleanup;
}

do you notice this mount02 failure on mainline kernel ?

Best regards
Naresh Kamboju

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

[Jan Stancek]

----- 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().

> 
> Error log,
> mount02 5 TFAIL : mount02.c:117: mount() was expected to fail with
> EINVAL(22): TEST_ERRNO=ENOENT(2): No such file or directory
> 
> Failure full log on x15 armv7,
> https://lkft.validation.linaro.org/scheduler/job/638009#L7462
> 
> structure Inputs,
> {&null, &mntpoint, &fs_type, 0, EINVAL, NULL, NULL},
> 
> Snippet  test code:
> --------------------------
> TEST(mount(*tc->device, *tc->mntpoint, *tc->fs_type, tc->flag, NULL));
> 
> if (TEST_RETURN != -1) {
> tst_resm(TFAIL, "mount() succeded unexpectedly (ret=%li)",
>          TEST_RETURN);
> goto cleanup;
> }
> 
> if (TEST_ERRNO != tc->exp_errno) {
> tst_resm(TFAIL | TTERRNO,
>          "mount() was expected to fail with %s(%i)",
>          tst_strerrno(tc->exp_errno), tc->exp_errno);
> goto cleanup;
> }
> 
> do you notice this mount02 failure on mainline kernel ?

5.0.0 looks fine on my x86 VM:

# uname -r
5.0.0

# ./mount02 
mount02     0  TINFO  :  Found free device '/dev/loop0'
mount02     0  TINFO  :  Formatting /dev/loop0 with ext2 opts='' extra opts=''
mke2fs 1.44.3 (10-July-2018)
mount02     1  TPASS  :  mount() failed expectedly: TEST_ERRNO=ENODEV(19): No such device
mount02     2  TPASS  :  mount() failed expectedly: TEST_ERRNO=ENOTBLK(15): Block device required
mount02     3  TPASS  :  mount() failed expectedly: TEST_ERRNO=EBUSY(16): Device or resource busy
mount02     4  TPASS  :  mount() failed expectedly: TEST_ERRNO=EBUSY(16): Device or resource busy
mount02     5  TPASS  :  mount() failed expectedly: TEST_ERRNO=EINVAL(22): Invalid argument
mount02     6  TPASS  :  mount() failed expectedly: TEST_ERRNO=EINVAL(22): Invalid argument
mount02     7  TPASS  :  mount() failed expectedly: TEST_ERRNO=EINVAL(22): Invalid argument
mount02     8  TPASS  :  mount() failed expectedly: TEST_ERRNO=EFAULT(14): Bad address
mount02     9  TPASS  :  mount() failed expectedly: TEST_ERRNO=EFAULT(14): Bad address
mount02    10  TPASS  :  mount() failed expectedly: TEST_ERRNO=ENAMETOOLONG(36): File name too long
mount02    11  TPASS  :  mount() failed expectedly: TEST_ERRNO=ENOENT(2): No such file or directory
mount02    12  TPASS  :  mount() failed expectedly: TEST_ERRNO=ENOTDIR(20): Not a directory

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

[Naresh Kamboju]

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.
With this change we have to modify our test code.

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

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

[Jan Stancek]

----- 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)

> 
> 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
> 

[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
>>

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

[Al Viro]

On Thu, Apr 18, 2019 at 03:14:33PM +0800, Xiao Yang wrote:

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

I am; I'm sorting the next pile of mount patches at the moment,
and fix for that is going to be in the very beginning.

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

[Xiao Yang]

On 2019/04/18 15:24, Al Viro wrote:
> On Thu, Apr 18, 2019 at 03:14:33PM +0800, Xiao Yang wrote:
>
>> Does you or Al Viro plan to replace ENOENT with ENOTBLK recently?
>> It seems that ENOENT still exists on v5.1-rc5.
> I am; I'm sorting the next pile of mount patches at the moment,
> and fix for that is going to be in the very beginning.
>
>
Hi Al，

Got it, thanks for your quick reply.

Best Regards,
Xiao Yang