linux-kernel - Re: dma-buf: Add selftests for dma-fence

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Tue, 27 Aug 2019 13:36:26 +0100
From:   Chris Wilson <chris@...is-wilson.co.uk>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     DRI Development <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:KERNEL SELFTEST FRAMEWORK" 
        <linux-kselftest@...r.kernel.org>
Subject: Re: dma-buf: Add selftests for dma-fence

Quoting Geert Uytterhoeven (2019-08-27 13:30:04)
> Hi Chris,
> 
> When running the new dmabuf-selftests on two different systems, I get:
> 
>     dma-buf: Running sanitycheck
>     dma-buf: Running dma_fence
>     sizeof(dma_fence)=48
>     dma-buf: Running dma_fence/sanitycheck
>     dma-buf: Running dma_fence/test_signaling
>     dma-buf: Running dma_fence/test_add_callback
>     dma-buf: Running dma_fence/test_late_add_callback
>     dma-buf: Running dma_fence/test_rm_callback
>     dma-buf: Running dma_fence/test_late_rm_callback
>     dma-buf: Running dma_fence/test_status
>     dma-buf: Running dma_fence/test_error
>     dma-buf: Running dma_fence/test_wait
>     dma-buf: Running dma_fence/test_wait_timeout
>     dma-buf: Running dma_fence/test_stub
>     dma-buf: Running dma_fence/race_signal_callback
>     thread_signal_callback[0] completed 28855 passes, 3929 misses
>     thread_signal_callback[1] completed 28846 passes, 3918 misses
>     thread_signal_callback[0] completed 37179 passes, 37179 misses
>     thread_signal_callback[1] completed 37184 passes, 37183 misses
> 
> and
> 
>     dma-buf: Running sanitycheck
>     dma-buf: Running dma_fence
>     sizeof(dma_fence)=64
>     dma-buf: Running dma_fence/sanitycheck
>     dma-buf: Running dma_fence/test_signaling
>     dma-buf: Running dma_fence/test_add_callback
>     dma-buf: Running dma_fence/test_late_add_callback
>     dma-buf: Running dma_fence/test_rm_callback
>     dma-buf: Running dma_fence/test_late_rm_callback
>     dma-buf: Running dma_fence/test_status
>     dma-buf: Running dma_fence/test_error
>     dma-buf: Running dma_fence/test_wait
>     dma-buf: Running dma_fence/test_wait_timeout
>     dma-buf: Running dma_fence/test_stub
>     dma-buf: Running dma_fence/race_signal_callback
>     thread_signal_callback[0] completed 3423 passes, 2148 misses
>     thread_signal_callback[1] completed 2360 passes, 9 misses
>     thread_signal_callback[0] completed 4028 passes, 4028 misses
>     thread_signal_callback[1] completed 8080 passes, 8079 misses
> 
> Unfortunately it is not clear to me if this is good or bad?
> Perhaps the test output can be improved, e.g. with a clear PASS/FAIL output?

It's communicated via the error code, along with failure messages. For
more complex persistent selftest modules, we use an modparam to report
the error code.

See igt/dmabuf for the test runner.
-Chris