[LTP] [PATCH] umip_basic_test.c: update umip basic test for new kernel v5.4

Li Wang liwang@redhat.com
Sun Sep 29 09:13:35 CEST 2019


Hi Pengfei,

Pengfei Xu <pengfei.xu@intel.com> wrote:

...
> >
> > My concern is that if an LTS distro backports the patch(commit
> e86c2c8b93),
> > then it will break this hardcode kernel-version comparing.
> >
> >
>   Ok, let's wait to confirm umip patch merged into Linux kernel main line,
>   and then merge the patch into LTP. :)
>

Sorry, I'm not talking merge time. I mean we have to consider more kernel
distros(RHEL, SLES, Ubuntu) when writing/amending LTP test.

Imagine that, if RHEL8(kernel base on v4.18) backports the kernel
patch(x86/umip: Add emulation (spoofing) for UMIP covered instructions in
64-bit processes) and what will happen after applying your patch in
this umip_basic_test.c test? It will fail since that kernel version is less
than 5.4. We probably need to find a way to solve this issue.

>
> > > +               #endif
> > > +       }
> > > +
> > >         if (WIFSIGNALED(status) && WTERMSIG(status) == SIGSEGV) {
> > > -               tst_res(TPASS, "Got SIGSEGV");
> > > +               tst_res(TPASS, "Got SIGSEGV\n\n");
> > >
> >
> > Why we need two '\n' here?
> >
>   Because it could help to split umip cases in LTP, there are 5 umip cases
>   in LTP tests, and we could check each umip case easily in LTP log,
>

It is unnecessary because each test shows TINFO before testing.
  e.g  "umip_basic_test.c:41: INFO: TEST sgdt, sgdt result save at
[0x7fff930bda8e]"

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


More information about the ltp mailing list