[LTP] [PATCH] statvfs01: Convert to new LTP API
Richard Palethorpe
rpalethorpe@suse.de
Tue Nov 29 11:58:57 CET 2022
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.
More information about the ltp
mailing list