Re: [LTP] [PATCH] statvfs01: Convert to new LTP API

[Richard Palethorpe <rpalethorpe@suse.de>]

Hello,

Li Wang <liwang@redhat.com> writes:

> On Thu, Nov 24, 2022 at 7:42 PM Avinesh Kumar <akumar@suse.de> wrote:
>
>  Also I've removed the TINFO statements, I'm not sure if only
>  printing the data in logs is helpful in anyway.
>
> Removing the printing is OK, but I am just wondering that
> can we find a way to check if the returned value in 'buf' is
> indeed correct?
>
> As you can see the ‘struct statvfs‘ includes many fs key
> values that we need to trust when using them.
>
> struct statvfs {
>         unsigned long  f_bsize;    /* Filesystem block size */
>         unsigned long  f_frsize;   /* Fragment size */
>         fsblkcnt_t     f_blocks;   /* Size of fs in f_frsize units */
>         fsblkcnt_t     f_bfree;    /* Number of free blocks */
>         fsblkcnt_t     f_bavail;   /* Number of free blocks for
>                                              unprivileged users */
>         fsfilcnt_t     f_files;    /* Number of inodes */
>         fsfilcnt_t     f_ffree;    /* Number of free inodes */
>         fsfilcnt_t     f_favail;   /* Number of free inodes for
>                                              unprivileged users */
>         unsigned long  f_fsid;     /* Filesystem ID */
>         unsigned long  f_flag;     /* Mount flags */
>         unsigned long  f_namemax;  /* Maximum filename length */
>  };

I suppose previously printing the values at least accessed the memory.
Actually validating the values could be a separate patch though.

We (probably) know that maximum filename should be less than 255 chars
(for e.g.), but I think there is a good chance that trying to validate
this will result in false positives and stuff we might want to revert.

-- 
Thank you,
Richard.

-- 
Mailing list info: https://lists.linux.it/listinfo/ltp