linux-kernel - Re: [Xen-devel][PATCH 1/3] xen: Introduce shared buffer helpers for page directory...

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]

Message-ID: <ee394331-282e-9942-a576-73cf714b620e@gmail.com>
Date:   Fri, 30 Nov 2018 09:07:29 +0200
From:   Oleksandr Andrushchenko <andr2000@...il.com>
To:     Juergen Gross <jgross@...e.com>, xen-devel@...ts.xenproject.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        alsa-devel@...a-project.org, boris.ostrovsky@...cle.com
Cc:     Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
Subject: Re: [Xen-devel][PATCH 1/3] xen: Introduce shared buffer helpers for
 page directory...

On 11/30/18 8:50 AM, Juergen Gross wrote:
> On 29/11/2018 12:22, Oleksandr Andrushchenko wrote:
>> ping
>>
>> On 11/22/18 12:02 PM, Oleksandr Andrushchenko wrote:
>>> From: Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
>>>
>>> based frontends. Currently the frontends which implement
>>> similar code for sharing big buffers between frontend and
>>> backend are para-virtualized DRM and sound drivers.
>>> Both define the same way to share grant references of a
>>> data buffer with the corresponding backend with little
>>> differences.
>>>
>>> Move shared code into a helper module, so there is a single
>>> implementation of the same functionality for all.
>>>
>>> Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@...m.com>
> In general I'm fine with this approach.
>
> With the concerns raised for one of the other patches I wanted to wait
> for V2 of the series.
Ah, I waited for any comments before rolling v2 out ;)
>   Or won't the resulting change require a
> modification of this patch?

This patch won't change, it is only DRM related

The concern for the DRM patch is already resolved

and the corresponding patch is on review now [1]

>
> It would be nice if you could point out in the commit message whether
> you are doing code movement (with some renames) only, or if there are
> any functional changes involved (and which ones).
Sure, this is pure code movement, no functional changes
>   This would make the
> review much easier and less time consuming.
>
>
> Juergen

Thank you,

Oleksandr

[1] https://lkml.org/lkml/2018/11/27/811