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: <b887c355-14db-ad37-0e93-733ff2249967@samsung.com>
Date:   Fri, 8 May 2020 09:12:13 +0200
From:   Marek Szyprowski <m.szyprowski@...sung.com>
To:     Christoph Hellwig <hch@....de>
Cc:     dri-devel@...ts.freedesktop.org, iommu@...ts.linux-foundation.org,
        linaro-mm-sig@...ts.linaro.org, linux-kernel@...r.kernel.org,
        Robin Murphy <robin.murphy@....com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
        linux-arm-kernel@...ts.infradead.org,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
        Maxime Ripard <mripard@...nel.org>,
        Thomas Zimmermann <tzimmermann@...e.de>
Subject: Re: [PATCH v3 02/25] drm: core: fix common struct sg_table related
 issues

Hi Christoph,

On 05.05.2020 13:09, Christoph Hellwig wrote:
> On Tue, May 05, 2020 at 12:51:58PM +0200, Marek Szyprowski wrote:
>> On 05.05.2020 12:15, Christoph Hellwig wrote:
>>>> -		for_each_sg_page(st->sgl, &sg_iter, st->nents, 0)
>>>> +		for_each_sg_page(st->sgl, &sg_iter, st->orig_nents, 0)
>>> Would it make sense to also add a for_each_sgtable_page helper that
>>> hides the use of orig_nents?  To be used like:
>>>
>>> 		for_each_sgtable_page(st, &sg_iter, 0) {
>> We would need two helpers:
>>
>> for_each_sgtable_cpu_page() and for_each_sgtable_dma_page().
>>
>> I considered them, but then I found that there are already
>> for_each_sg_page(), for_each_sg_dma_page() and various special iterators
>> like sg_page_iter, sg_dma_page_iter and sg_mapping_iter. Too bad that
>> they are almost not used, at least in the DRM subsystem. I wonder if it
>> make sense to apply them or simply provide the two above mentioned
>> wrappers?
> None of the helpers helps with passing the right parameters from the
> sg_table.  So in doube we'd need wrappers for all of the above, or
> none..

I've played a bit with the code and the existing scatterlist iterators - 
for_each_sg_page() and for_each_sg_dma_page(). I've found them quite handy!

The biggest advantage of them is that they always iterate over 
scatterlist in PAGE_SIZE units, what should make the code much easier to 
understand. Here is example of their application to the function that 
started this thread:

int drm_prime_sg_to_page_addr_arrays(struct sg_table *sgt, struct page 
**pages,
                                      dma_addr_t *addrs, int max_entries)
{
         struct sg_dma_page_iter dma_iter;
         struct sg_page_iter page_iter;

         if (addrs)
                 for_each_sgtable_dma_page(sgt, &dma_iter, 0)
                         *addrs++ = sg_page_iter_dma_address(&dma_iter);
         if (pages)
                 for_each_sgtable_page(sgt, &page_iter, 0)
                         *pages++ = sg_page_iter_page(&page_iter);
         return 0;
}

After applying those iterators where possible (they can be used only for 
reading the scatterlist), we would just need to add 2 trivial wrappers 
to use them with sg_table objects:

#define for_each_sgtable_page(sgt, piter, pgoffset)    \
        for_each_sg_page(sgt->sgl, piter, sgt->orig_nents, pgoffset)

#define for_each_sgtable_dma_page(sgt, dma_iter, pgoffset)     \
        for_each_sg_dma_page(sgt->sgl, dma_iter, sgt->nents, pgoffset)

Then we would just need one more helper to construct scatterlist, as the 
above two are read-only don't allow to modify scatterlist:

#define for_each_sgtable_sg(sgt, sg, i)                \
        for_each_sg(sgt->sgl, sg, sgt->orig_nents, i)

With the above 3 helpers we can probably get rid of all instances of 
sg_table->{nents,orig_nents} from the DRM code. I will prepare patches soon.

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ