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: <CALAqxLU35HJJYukMzYuHpPpPToeKs=ceCR7mGBNj9bnSwcJzMg@mail.gmail.com>
Date:   Wed, 13 Mar 2019 15:49:13 -0700
From:   John Stultz <john.stultz@...aro.org>
To:     Liam Mark <lmark@...eaurora.org>
Cc:     lkml <linux-kernel@...r.kernel.org>,
        Laura Abbott <labbott@...hat.com>,
        Benjamin Gaignard <benjamin.gaignard@...aro.org>,
        Greg KH <gregkh@...uxfoundation.org>,
        Sumit Semwal <sumit.semwal@...aro.org>,
        Brian Starkey <Brian.Starkey@....com>,
        "Andrew F . Davis" <afd@...com>, Chenbo Feng <fengc@...gle.com>,
        Alistair Strachan <astrachan@...gle.com>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Vincent Donnefort <Vincent.Donnefort@....com>,
        Marissa Wall <marissaw@...gle.com>
Subject: Re: [RFC][PATCH 3/5 v2] dma-buf: heaps: Add system heap to dmabuf heaps

On Wed, Mar 13, 2019 at 1:20 PM Liam Mark <lmark@...eaurora.org> wrote:
> On Tue, 5 Mar 2019, John Stultz wrote:
> > +
> > +             page = alloc_page(GFP_KERNEL);
>
> Need to zero the allocation (add __GFP_ZERO)

Ah! Thanks! Fixed now.

> > +             if (!page)
> > +                     goto err2;
> > +             sg_set_page(sg, page, PAGE_SIZE, 0);
> > +     }
> > +
>
> Can always be done later, but it may be helpful to also move this common
> code from here (and from the cma heap) to the heap helpers file as it
> reduces code but will also make it easier to introduce future debug
> features such as making the dma buf names unique
> to help make it easier to track down the source of memory leaks.

I think this is a good suggestion, but I do want to be careful to try
to make sure we add debugging tools to the larger dmabuf
infrastructure, rather then just the heap code (though having some
heap specific usage info would still be good). I think there's a
separate patchset to dmabufs originally from Greg Hackmann that
provides names that is supposed to help with what your suggesting.
  https://lists.freedesktop.org/archives/dri-devel/2019-February/208759.html

thanks!
-john

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ