[LTP] [PATCH v1] libswap.c: Improve caculate swap dev number

Li Wang liwang@redhat.com
Mon Mar 4 11:04:08 CET 2024


On Mon, Mar 4, 2024 at 5:19 PM Yang Xu (Fujitsu) <xuyang2018.jy@fujitsu.com>
wrote:

> Hi  Li,
>
> >
> >
> > On Sun, Mar 3, 2024 at 9:14 PM Petr Vorel <pvorel@suse.cz
> > <mailto:pvorel@suse.cz>> wrote:
> >
> >     Hi Wei, Xu,
> >
> >      > Hi  Wei
> >
> >      > > I encounter a dead loop on following code in our test on ppc64
> >     machine:
> >      > > while ((c = fgetc(fp)) != EOF)
> >
> >      > > I think "/proc/swaps" is not normal file and can not get EOF in
> >     some situation,
> >      > > so i use fgets a line and caculate swap dev number.
> >
> >     I guess the problem has been fixed by another patch [1], thus
> >     closing it in
> >     patchwork. Please let me know if not.
> >
> >
> > Seems not, the patch [1] below is mainly to count the free disk size.
> >
> > But Wei's work here is to calculate swap-dev numbers correctly
> > (especially get rid of EOF affection to some degree).
> >
> > Xu Yang, what do you think? or did I miss anything here?
> >
> >
>
> I still think we can use the same way in ipc libs to get rid of the EOF
> problem instead of
> searching "dev" keyword. We just don't need to  calcualte "/proc/swaps"
> header.
>

Sounds good to me. At least it counts right lines.

It'd be great to have a patch by that way.



>
> int get_used_sysvipc(const char *file, const int lineno, const char
> *sysvipc_file)
> {
>         FILE *fp;
>         int used = -1;
>         char buf[BUFSIZE];
>
>         fp = safe_fopen(file, lineno, NULL, sysvipc_file, "r");
>
>         while (fgets(buf, BUFSIZE, fp) != NULL)
>                 used++;
>
>         fclose(fp);
>
>         if (used < 0) {
>                 tst_brk(TBROK, "can't read %s to get used sysvipc resource
> total at "
>                         "%s:%d", sysvipc_file, file, lineno);
>         }
>
>         return used;
> }
>
> But we don't get the actual reason, I still wonder why this deadloop
> exists o ppcc64 instead of
> other architecture(ie x86_64).
>

Ok, I think we can just apply your suggested method to see if that deadloop
disappears.



-- 
Regards,
Li Wang


More information about the ltp mailing list