linux-kernel - Re: [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <501196c4-e5bd-476d-21a8-3450d804cd5b@redhat.com>
Date:   Fri, 15 Mar 2019 13:49:04 -0700
From:   Laura Abbott <labbott@...hat.com>
To:     John Stultz <john.stultz@...aro.org>
Cc:     Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Liam Mark <lmark@...eaurora.org>,
        Brian Starkey <Brian.Starkey@....com>,
        "Andrew F . Davis" <afd@...com>, Chenbo Feng <fengc@...gle.com>,
        Alistair Strachan <astrachan@...gle.com>,
        ML dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: [RFC][PATCH 5/5 v2] kselftests: Add dma-heap test

On 3/15/19 1:13 PM, John Stultz wrote:
> On Fri, Mar 15, 2019 at 1:07 PM Laura Abbott <labbott@...hat.com> wrote:
>>
>> On 3/6/19 9:01 AM, John Stultz wrote:
>>> On Wed, Mar 6, 2019 at 8:14 AM Benjamin Gaignard
>>> <benjamin.gaignard@...aro.org> wrote:
>>>> Le mar. 5 mars 2019 à 21:54, John Stultz <john.stultz@...aro.org> a écrit :
>>>>> +
>>>>> +       printf("Allocating 1 MEG\n");
>>>>> +       ret = dmabuf_heap_alloc(heap_fd, ONE_MEG, 0, &dmabuf_fd);
>>>>> +       if (ret)
>>>>> +               goto out;
>>>>> +
>>>>> +       /* DO SOMETHING WITH THE DMABUF HERE? */
>>>>
>>>> You can do a call to mmap and write a pattern in the buffer.
>>>
>>> Yea. I can also do some invalid allocations to make sure things fail properly.
>>>
>>> But I was talking a bit w/ Sumit about the lack of any general dmabuf
>>> tests, and am curious if we need to have a importer device driver that
>>> can validate its a real dmabuf and exercise more of the dmabuf ops.
>>>
>>> thanks
>>> -john
>>>
>>
>> There's the vgem driver in drm. I did some work to clean that
>> up so it could take an import af33a9190d02 ("drm/vgem: Enable dmabuf import
>> interfaces") . I mostly used it for private tests and never ended
>> up upstreaming any of the tests.
> 
> Thanks for the poitner, I'll check that out as well!  Also, if you
> still have them around, I'd be interested in checking out the tests to
> try to get something integrated into kselftest.
> 
> Talking with Brian yesterday, there was some thought that we should
> try to put together some sort of example dmabuf pipeline that isn't
> hardware dependent and can be used to demonstrate the usage model as
> well as validate the frameworks and maybe even benchmark some of the
> ideas floating around right now.  So suggestions here would be
> welcome!
> 

So the existing ion selftest (tools/testing/selftests/android/ion)
does make use of the import to do some very simple tests.
I can't seem to find the more complex tests I had though
they may have been lost during my last machine move :(

I do think building off of vgem would be a good first step
for a testing pipeline, although I worry we wouldn't be
able to measure caching effects without a real device since
setting up coherency testing otherwise seems error prone.

Thanks,
Laura

> thanks
> -john
>