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

[Li Wang]

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>