linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: "T.J. Mercier" <tjmercier@google.com>
Cc: John Stultz <jstultz@google.com>,
	jaewon31.kim@samsung.com,
	"sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
	"daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
	"hannes@cmpxchg.org" <hannes@cmpxchg.org>,
	"mhocko@kernel.org" <mhocko@kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"jaewon31.kim@gmail.com" <jaewon31.kim@gmail.com>
Subject: Re: [PATCH v2] dma-buf/heaps: system_heap: Avoid DoS by limiting single allocations to half of all memory
Date: Thu, 6 Apr 2023 16:38:22 -0700	[thread overview]
Message-ID: <20230406163822.faae6a90b3aa4942df6e7442@linux-foundation.org> (raw)
In-Reply-To: <CABdmKX0ZnQX5BPEJjqxwUsx=c8ykcX8Bjitak50DAYvfti6VFw@mail.gmail.com>

On Thu, 6 Apr 2023 16:27:28 -0700 "T.J. Mercier" <tjmercier@google.com> wrote:

> > When you say "decide what's the largest reasonable size", I think it
> > is difficult as with the variety of RAM sizes and buffer sizes I don't
> > think there's a fixed limit. Systems with more ram will use larger
> > buffers for image/video capture buffers.  And yes, you're right that
> > ram/2-1 in a single allocation is just as broken, but I'm not sure how
> > to establish a better guard rail.
> >
> > thanks
> > -john
> 
> I like ENOMEM with the len / PAGE_SIZE > totalram_pages() check and
> WARN_ON. We know for sure that's an invalid request, and it's pretty
> cheap to check as opposed to trying a bunch of reclaim before failing.

Well, if some buggy caller has gone and requested eleventy bigabytes of
memory, doing a lot of reclaiming before failing isn't really a problem
- we don't want to optimize for this case!

> For buffers smaller than that I agree with John in that I'm not sure
> there's a definitive threshold.

Well...  why do we want to do _anything_ here?  Why cater for buggy
callers?  I think it's because "dma-buf behaves really badly with very
large allocation requests".  Again, can we fix that instead?



  reply	other threads:[~2023-04-06 23:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20230406000841epcas1p3630010a770682be0f1d540a448f3e00e@epcas1p3.samsung.com>
2023-04-06  0:08 ` Jaewon Kim
2023-04-06  0:25   ` Andrew Morton
     [not found]   ` <CGME20230406000841epcas1p3630010a770682be0f1d540a448f3e00e@epcms1p3>
2023-04-06  1:44     ` Jaewon Kim
2023-04-06  1:56       ` Andrew Morton
     [not found]       ` <CGME20230406000841epcas1p3630010a770682be0f1d540a448f3e00e@epcms1p2>
2023-04-06  2:17         ` Jaewon Kim
2023-04-06  3:09           ` Andrew Morton
2023-04-06  4:24             ` John Stultz
2023-04-06 23:27               ` T.J. Mercier
2023-04-06 23:38                 ` Andrew Morton [this message]
2023-04-07  0:00                   ` T.J. Mercier
     [not found]                   ` <CGME20230406000841epcas1p3630010a770682be0f1d540a448f3e00e@epcms1p4>
2023-04-07  2:24                     ` Jaewon Kim
2023-04-07  5:12                       ` T.J. Mercier
2023-04-07 13:03         ` Jaewon Kim
2023-04-06  3:46     ` 김재원

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=20230406163822.faae6a90b3aa4942df6e7442@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=daniel.vetter@ffwll.ch \
    --cc=hannes@cmpxchg.org \
    --cc=jaewon31.kim@gmail.com \
    --cc=jaewon31.kim@samsung.com \
    --cc=jstultz@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=sumit.semwal@linaro.org \
    --cc=tjmercier@google.com \
    /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