Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Wed, 12 Apr 2023 11:23:27 +0200
From:   Michal Hocko <mhocko@suse.com>
To:     Jaewon Kim <jaewon31.kim@samsung.com>
Cc:     "jstultz@google.com" <jstultz@google.com>,
        "tjmercier@google.com" <tjmercier@google.com>,
        "sumit.semwal@linaro.org" <sumit.semwal@linaro.org>,
        "daniel.vetter@ffwll.ch" <daniel.vetter@ffwll.ch>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "hannes@cmpxchg.org" <hannes@cmpxchg.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 v3] dma-buf/heaps: system_heap: avoid too much allocation
Message-ID: <ZDZ4j7UdBt32j28J@dhcp22.suse.cz>
References: <ZDZqYTSHBNGLq0zI@dhcp22.suse.cz>
 <20230410073228.23043-1-jaewon31.kim@samsung.com>
 <CGME20230410073304epcas1p4cf3079b096994d69472b7801bd530bc7@epcms1p7>
 <20230412085726epcms1p7d2bec2526e47bd10a3b6ea6a113c9cc3@epcms1p7>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230412085726epcms1p7d2bec2526e47bd10a3b6ea6a113c9cc3@epcms1p7>
Precedence: bulk

On Wed 12-04-23 17:57:26, Jaewon Kim wrote:
> >Sorry for being late. I know there was some pre-existing discussion
> >around that but I didn't have time to participate.
> >
> >On Mon 10-04-23 16:32:28, Jaewon Kim wrote:
> >> @@ -350,6 +350,9 @@ static struct dma_buf *system_heap_allocate(struct dma_heap *heap,
> >>  	struct page *page, *tmp_page;
> >>  	int i, ret = -ENOMEM;
> >>  
> >> +	if (len / PAGE_SIZE > totalram_pages())
> >> +		return ERR_PTR(-ENOMEM);
> >> +
> >
> >This is an antipattern imho. Check 7661809d493b ("mm: don't allow
> >oversized kvmalloc() calls") how kvmalloc has dealt with a similar
> 
> Hello Thank you for the information.
> 
> I tried to search the macro of INT_MAX.
> 
> include/vdso/limits.h
> #define INT_MAX         ((int)(~0U >> 1))
> 
> AFAIK the dma-buf system heap user can request that huge size more than 2GB.

Do you have any pointers? This all is unreclaimable memory, right? How
are those users constrained to not go overboard?

> So
> I think totalram_pages() is better than INT_MAX in this case.
> 
> >issue. totalram_pages doesn't really tell you anything about incorrect
> >users. You might be on a low memory system where the request size is
> >sane normally, it just doesn't fit into memory on that particular
> >machine.
> 
> Sorry maybe I'm not fully understand what you meant. User may requested
> a huge size like 3GB on 2GB ram device. But I think that should be rejected
> because it is bigger than the device ram size.

Even totalram_pages/10 can be just unfeasible amount of data to be
allocated without a major disruption. totalram_pages is no measure of
the memory availability.
If you want to have a ballpark estimation then si_mem_available might be
something you are looking for. But I thought the sole purpose of this
patch is to catch obviously buggy callers (like sign overflow lenght
etc) rather than any memory consumption sanity check.

-- 
Michal Hocko
SUSE Labs