[Mesa-dev] [PATCH 1/3] anv/device: Don't even try to map memory with a size of 0

[Jason Ekstrand]

On Tue, Nov 8, 2016 at 1:46 PM, Nanley Chery <nanleychery at gmail.com> wrote:

> On Mon, Nov 07, 2016 at 05:28:12PM -0800, Jason Ekstrand wrote:
> > Signed-off-by: Jason Ekstrand <jason at jlekstrand.net>
> > Cc: "12.0 13.0" <mesa-dev at lists.freedesktop.org>
> > ---
> >  src/intel/vulkan/anv_device.c | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/src/intel/vulkan/anv_device.c
> b/src/intel/vulkan/anv_device.c
> > index 5393144..8055893 100644
> > --- a/src/intel/vulkan/anv_device.c
> > +++ b/src/intel/vulkan/anv_device.c
> > @@ -1258,6 +1258,11 @@ VkResult anv_MapMemory(
> >     if (size == VK_WHOLE_SIZE)
> >        size = mem->bo.size - offset;
> >
> > +   if (size == 0) {
>
> The user isn't allowed to make such a call. Does this fix a CTS test?
>

Heh, so they aren't.  It doesn't fix anything, it just ensures that you
never hit the ioctl with a size of zero.  How about I replace it with an
assert?


> > +      *ppData = NULL;
> > +      return VK_SUCCESS;
> > +   }
> > +
> >     /* FIXME: Is this supposed to be thread safe? Since vkUnmapMemory()
> only
> >      * takes a VkDeviceMemory pointer, it seems like only one map of the
> memory
> >      * at a time is valid. We could just mmap up front and return an
> offset
> > --
> > 2.5.0.400.gff86faf
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20161108/7a139173/attachment.html>