[PATCH libdrm 1/2] amdgpu: prevent an integer wraparound of cpu_map_count

[Marek Olšák]

On Fri, Nov 2, 2018 at 3:39 AM Koenig, Christian <Christian.Koenig at amd.com>
wrote:

> Am 31.10.18 um 23:12 schrieb Marek Olšák:
>
> On Wed, Oct 31, 2018 at 3:59 AM Koenig, Christian <
> Christian.Koenig at amd.com> wrote:
>
>> Am 30.10.18 um 16:59 schrieb Michel Dänzer:
>> > On 2018-10-30 4:52 p.m., Marek Olšák wrote:
>> >> On Tue, Oct 30, 2018, 11:49 AM Marek Olšák <maraeo at gmail.com> wrote:
>> >>> On Tue, Oct 30, 2018, 4:20 AM Michel Dänzer <michel at daenzer.net>
>> wrote:
>> >>>
>> >>>> On 2018-10-29 10:15 p.m., Marek Olšák wrote:
>> >>>>> You and I discussed this extensively internally a while ago. It's
>> >>>> expected
>> >>>>> and correct behavior. Mesa doesn't unmap some buffers and never
>> will.
>> >>>> It doesn't need to keep mapping the same buffer over and over again
>> >>>> though, does it?
>> >>>>
>> >>> It doesnt map it again. It just doesnt unmap. So the next map call
>> just
>> >>> returns the pointer. It's correct to stop the counter wraparound.
>> >>>
>> >> Mesa doesn't track whether a buffer is already mapped. Libdrm tracks
>> that.
>> >> It's a feature of libdrm to return the same pointer and expect infinite
>> >> number of map calls.
>> > That's not what the reference counting in libdrm is intended for. It's
>> > for keeping track of how many independent callers have mapped the
>> > buffer. Mesa should remember that it mapped a buffer and not map it
>> again.
>>
>> Well if Mesa just wants to query the existing mapping then why not add a
>> amdgpu_bo_get_cpu_ptr() which just queries if a CPU mapping exists and
>> if yes returns the appropriate pointer or NULL otherwise?
>>
>> I mean when we want to abstract everything in libdrm then we just need
>> to add the functions we need to use this abstraction.
>>
>
> That can be future work for the sake of cleanliness and clarity, but it
> would be a waste of time and wouldn't help old Mesa.
>
>
> That it doesn't help old Mesa is unfortunate, but this is clearly a bug in
> Mesa.
>
> If old Mesa is broken then we should fix it by updating it and not add
> workarounds for specific clients in libdrm.
>

It's not a workaround. We made a decision with amdgpu to share code by
moving portions of the Mesa winsys into libdrm. The map_count is part of
that. It's highly desirable to continue with code sharing. There is nothing
broken with Mesa. Mesa won't check whether a buffer is already mapped.
That's the responsibility of libdrm as part of code sharing and we don't
want to duplicate the same logic in Mesa. It's all part of the intended
design.

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20181102/25d5b062/attachment.html>