[LTP] [PATCH] fzsync: skip test when avaliable CPUs less than 2

Li Wang
2020-11-30T09:03:32Z

Hi Joerg,

On Mon, Nov 30, 2020 at 4:39 PM Joerg Vehlow <lkml@jv-coder.de> wrote:

> Hi Li,
>
> On 11/30/2020 9:14 AM, Li Wang wrote:
> > Hi Joerg,
> >
> > On Mon, Nov 30, 2020 at 3:53 PM Joerg Vehlow <lkml@jv-coder.de
> > <mailto:lkml@jv-coder.de>> wrote:
> >
> > Hi,
> > >> No, af_alg07 requires 2 CPUs, otherwise it'll report false
> > positives.
> > >> The test will pass only if fchownat() hits a half-closed socket
> and
> > >> returns error. But IIRC the half-closed socket will be
> > destroyed during
> > >> reschedule which means there's no race window to hit anymore.
> > But it
> > >> would be better to put the TCONF condition into the test itself.
> > > Interesting, I wonder if this is also true for the real-time
> > kernel with
> > > the threads set to RT priority?
> > It looks like the test can fail even with more than one cpu. I've
> > seen
> > this sporadic failure on different hardware with more than two
> > cores, at
> > least on intel denverton (x86_64) and renesas r-car (aarch64)
> > systems.
> > Both with kernel 4.19 with the fix included, on the denverton
> > system the
> > rt parches were included and on the r-car not. The test passes
> > most of
> > the time, but sometimes fails with the message Li posted.
> >
> > It also seems to fail sporadically on other systems as well:
> > https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1892860
> > <https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1892860>
> >
> > Additionally I tested on qemu-x86 with 4.19 with and without rt
> > patches.
> > The test succeeds even with only one virtualized cpu. So either
> > Martin's
> > assumption is wrong or it holds only for newer kernel versions?
> >
> >
> > No, Mertin is not wrong, and you are also right.
> >
> > They are totally two different issues of af_alg07, the test on 1CPU
> > should be fixed with TCONF. But the fail with aarch64 is more like a
> > hardware issue, Chunyu has a drafted patch to add init delay value for
> > such a system.
> I think you misunderstood something. I see random fails with "TFAIL:
> fchownat() failed to fail, kernel may be vulnerable" on both x86_64 and
> aarch64 with more than one cpu core (4 for x86_64 and 2 or 4 for aarch64).
>

Well, seems I was somewhat arbitrary on this problem a moment ago.

Probably I was missing the 4cores fails on x86_64 you mentioned, we just
observed that FAIL on 1CPU x86_64 and hpe_moonshot(aarch64) so far.
The tentative conclusion of our debugging result:

1. FAIL with 1CPU KVM x86_64 is false positives
2. FAIL with hpe_moonshot aarch64 is caused by cache line design

>
> I see no error ("TPASS: fchownat() failed successfully: ENOENT (2)") on
> single core qemu-x86. This is why I think Martin's assumption may be
> wrong. If it was right, it should never succeed on a single core system
> right?
>

Hmm, it's hard to say never, it is also possible to create a race window on
a single-core system.
Anyway, we need to do more investigation.

--
Regards,
Li Wang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linux.it/pipermail/ltp/attachments/20201130/14a94947/attachment-0001.htm>