dri-devel.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Vetter <daniel@ffwll.ch>
To: Sumit Semwal <sumit.semwal@linaro.org>
Cc: "Hridya Valsaraju" <hridya@google.com>,
	"John Stultz" <john.stultz@linaro.org>,
	"Benjamin Gaignard" <benjamin.gaignard@linaro.org>,
	"Liam Mark" <lmark@codeaurora.org>,
	"Laura Abbott" <labbott@redhat.com>,
	"Brian Starkey" <Brian.Starkey@arm.com>,
	"Christian König" <christian.koenig@amd.com>,
	linux-media <linux-media@vger.kernel.org>,
	dri-devel <dri-devel@lists.freedesktop.org>,
	"moderated list:DMA BUFFER SHARING FRAMEWORK"
	<linaro-mm-sig@lists.linaro.org>,
	lkml <linux-kernel@vger.kernel.org>,
	"Android Kernel Team" <kernel-team@android.com>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>
Subject: Re: [PATCH] dma-buf: heaps: Set allocation limit for system heap
Date: Tue, 10 Aug 2021 10:40:18 +0200	[thread overview]
Message-ID: <YRI7cqWXM545iMzO@phenom.ffwll.local> (raw)
In-Reply-To: <CAO_48GFS5SsdNCwOp6Jb+nmZJ+SdNkQkq628VhxXRGSLVeP0Yg@mail.gmail.com>

On Tue, Aug 10, 2021 at 01:54:41PM +0530, Sumit Semwal wrote:
> Hi Hridya,
> 
> Apologies for the delay in responding.
> 
> On Wed, 4 Aug 2021 at 03:09, Hridya Valsaraju <hridya@google.com> wrote:
> 
> > On Mon, Aug 2, 2021 at 7:18 PM John Stultz <john.stultz@linaro.org> wrote:
> > >
> > > On Thu, Jul 22, 2021 at 12:07 PM Hridya Valsaraju <hridya@google.com>
> > wrote:
> > > > This patch limits the size of total memory that can be requested in a
> > > > single allocation from the system heap. This would prevent a
> > > > buggy/malicious client from depleting system memory by requesting for
> > an
> > > > extremely large allocation which might destabilize the system.
> > > >
> > > > The limit is set to half the size of the device's total RAM which is
> > the
> > > > same as what was set by the deprecated ION system heap.
> > > >
> > > > Signed-off-by: Hridya Valsaraju <hridya@google.com>
> > >
> > > Seems sane to me, unless folks have better suggestions for allocation
> > limits.
> > >
> > > Reviewed-by: John Stultz <john.stultz@linaro.org>
> >
> > Thank you for taking a look John!
> >
> Looks good to me; I will apply it to drm-misc today.

Please don't, this doesn't really solve anything:
- it's easy to bypass, just allocate more buffers to get over the limit
- resource limit plan is cgroups, not hand-rolled limits in every
  allocator
- the ttm "max half of system memory" is for pinned memory, to work around
  locking inversion issues between dma_resv_lock and core mm shrinkers. It
  does not actually impose an overall allocation limit, you can allocate
  ttm bo until your entire memory (and swap) are full. Christian König has
  merged a patch set to lift this by reworking the shrinker interaction,
  but it had to be reverted again because of some fallout I can't remember
  offhand. dma_resv_lock vs shrinkers is very tricky.

So if you want resource limits then you really want cgroups here.

Cheers, Daniel

> 
> 
> >
> > Regards,
> > Hridya
> >
> > >
> > > thanks
> > > -john
> >
> Best,
> Sumit.
> 
> -- 
> Thanks and regards,
> 
> Sumit Semwal (he / him)
> Tech Lead - LCG, Vertical Technologies
> Linaro.org │ Open source software for ARM SoCs

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

  reply	other threads:[~2021-08-10  8:40 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-22 19:07 [PATCH] dma-buf: heaps: Set allocation limit for system heap Hridya Valsaraju
2021-08-03  2:18 ` John Stultz
2021-08-03 21:39   ` Hridya Valsaraju
2021-08-10  8:24     ` Sumit Semwal
2021-08-10  8:40       ` Daniel Vetter [this message]
2021-08-10 17:48         ` Hridya Valsaraju
2021-08-10  8:26     ` Sumit Semwal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YRI7cqWXM545iMzO@phenom.ffwll.local \
    --to=daniel@ffwll.ch \
    --cc=Brian.Starkey@arm.com \
    --cc=benjamin.gaignard@linaro.org \
    --cc=christian.koenig@amd.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hridya@google.com \
    --cc=john.stultz@linaro.org \
    --cc=kernel-team@android.com \
    --cc=labbott@redhat.com \
    --cc=linaro-mm-sig@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=lmark@codeaurora.org \
    --cc=sumit.semwal@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).