From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 19B7FC77B6E for ; Wed, 12 Apr 2023 11:07:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C2EF6B0074; Wed, 12 Apr 2023 07:07:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9744C900003; Wed, 12 Apr 2023 07:07:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 83C41900002; Wed, 12 Apr 2023 07:07:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7628E6B0074 for ; Wed, 12 Apr 2023 07:07:31 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1C6951C68F0 for ; Wed, 12 Apr 2023 11:03:34 +0000 (UTC) X-FDA: 80672453148.06.5192681 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf16.hostedemail.com (Postfix) with ESMTP id 0F444180077 for ; Wed, 12 Apr 2023 11:03:01 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=QHcDT0FR; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1681297382; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=fNN7SNZCqWM5pixcyzb+RtLg6Zm4j6Y+uXTVrtsJ//8=; b=13y9oNfOBmURY0ShMSxuOyOBadzLcIyyTN9fmatOY69l1pcj4PScqTO9R5oIRKi/V3a+1H hdEvOG5AAxpZGI8jmYPXUwfONW43aS6r2N8MjAsX3D+G9cKkw8d+6xDuw2qhQSRrMoSZXg thzKkK9icjSaw1sxAx4i18Rb8vLwItY= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=QHcDT0FR; spf=pass (imf16.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1681297382; a=rsa-sha256; cv=none; b=6f40/AJfqKh1eVtJXQSQIXMFfQIDjUh5hAb6IUEJN1zlbm8+wI75hNjEJGgr/Gsog9hsvD XIhjNbT7fceFG7VGmkxME2biOM7apIXfaXRwjcdHocdB8ZOYVoTx4hFV3o41MbZjLh6r5I NuXcJnW3ZgwSjKMG2Wu3LrFYb3jDCdc= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id B0FE41F890; Wed, 12 Apr 2023 11:03:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1681297380; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fNN7SNZCqWM5pixcyzb+RtLg6Zm4j6Y+uXTVrtsJ//8=; b=QHcDT0FRQxGosX0TleQ+60spnNEYZaxrvNfQxFMKfoFHy1YedQ4UuIJVhLg9Sy2BjRg73E mzxJcenfsNUGsVQ5JRJ4Tw6Abl9xPUxAGjLZ2WtAZoIg0nSqWQG2/T4UE4ULcVwVJ53US4 tXfbDI37740XXMRRexPgxLPhb05lAV8= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 8EA8413498; Wed, 12 Apr 2023 11:03:00 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id yEzaH+SPNmRVKwAAMHmgww (envelope-from ); Wed, 12 Apr 2023 11:03:00 +0000 Date: Wed, 12 Apr 2023 13:02:59 +0200 From: Michal Hocko To: Jaewon Kim Cc: "jstultz@google.com" , "tjmercier@google.com" , "sumit.semwal@linaro.org" , "daniel.vetter@ffwll.ch" , "akpm@linux-foundation.org" , "hannes@cmpxchg.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "jaewon31.kim@gmail.com" Subject: Re: [PATCH v3] dma-buf/heaps: system_heap: avoid too much allocation Message-ID: References: <20230410073228.23043-1-jaewon31.kim@samsung.com> <20230412085726epcms1p7d2bec2526e47bd10a3b6ea6a113c9cc3@epcms1p7> <20230412094440epcms1p445319579ead0d0576bb616ebb07501b4@epcms1p4> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230412094440epcms1p445319579ead0d0576bb616ebb07501b4@epcms1p4> X-Stat-Signature: ytax1ki179gg4ybj487szxpr7377p6zp X-Rspam-User: X-Rspamd-Queue-Id: 0F444180077 X-Rspamd-Server: rspam06 X-HE-Tag: 1681297381-973456 X-HE-Meta: U2FsdGVkX1+mO83nveh+CXRDfrn5YSI/5LO9JnyIyjdqe3a2Q5W8A0nYwUTiUeboHk+FViIl2Zpxhv3HOVFy3OSYm066zo/4OCMh95KsK8oHzxhHcKVMt1az3Vbr1FBO1X0XQNYWP/ToC24ZLnoKIGIZThI2rp+tJNTZfzGvjb8C0ENYZ4bxwF1PHQoQCsUhlmtTKTtnk4aRF7ssNF8X1zgJUS9oeA467keer3AMyu/joZEDW+wRQ9o/2L48jqyo9QsThj63E3NIVZbiZHUmskIovbiFp9OdJ4CuZW7TFbvS6ezQ9iegihkV2I0nIekoy9PLnTClILqwtGspc1YgLa2B0BldLxY+gRAZB7Y/k+m3kqSKBX03SPNJR8/0mOsoO2+NNxBnO6GzyhZ0gXAHLsV/9TxLnQfyi3lV6VXTz6csOYRs3D012qLOJ8p4JG1BX5xALafjxWsxBgTnOjxU2tvYB4u9NXPRFUD4feDSpkR4aLZ3wwJlHXP6FwX02Ak7gHlIxWFgCJ8iLgJWst5SZCbGXv19QO7S5n0ATxPDzbYc+p2QiAz9jSir97tsTbqyySyGb/L5vhRx8fSMhWrSeB1xp2KgwFMn1gDoORk7Vd+ULBNACoguXpm/Cq+BLTxA4rht48DR3YBAO5l6796fwzwdzF21mADi6aIkitCRxneagD+RkZDzL8wyHCmm3vh/3pe1ghb6FRBcwdcuh3FSahKVTEnIBjCO5Jw9J85h2kZYaFfI58OQwQ2wSz/QIOuXlY4eOPRQKxpeLBcReQLCgX2vWK00HVim+9f0ybZ6CKJio2nMFFQ4LIjKynZAuyL+BlvRVrlh11aCkpc/EFcGhYKT7bLrM7LMilc5GWjw1ucSc9XyF9bPQ79lQXdbGM0yOQzF3VKj/nfnPG60NMCH+jOc5U3x8RdeMz3FhMruunKQDv07VibpjoYanSjA3M+RgCTXdSm84ZhI8tRuH4u SfuyUzB9 BHnzGfY7EQH2kNlXFROy+vLhxnd/dy0MNTAZQGHvpVb7qvV3yHPvnbzlS+Kh8srz63BzPgGhrpFWXkbOkAzKyEpJLnUD1GbP3mNU2QHPksbmzjASq48c5C/x9pg0GXB933kw1JA5l+Kvh4hjc0u8YBGaf/8eVPmdr8zkRoU0oncSTsPrlNKC7geVyNzHrAF7JdqydkwalK5ywMMePvRbd6JoxAsMUDM5AYA2ru3mHGAzQrAD5T79OwW0vXjjkoyVDLtVShxEVxEZQZlPsJZdJzFdZzXg4K/B8mVMq37dJ/AvY2wHvomtGhzaYaj31lxxfOIfmF/Q0CLsyy14= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed 12-04-23 18:44:40, Jaewon Kim wrote: > >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? > > Correct dma-buf system heap memory is unreclaimable. To avoid that huge request, > this patch includes __GFP_RETRY_MAYFAIL. __GFP_RETRY_MAYFAIL doesn't avoud huge requests. It will drain the free available memory to the edge of OOM (especially for low order requests) so effectively anybody else requesting any memory (GFP_KERNEL like req.) will hit the oom killer very likely). > #define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_RETRY_MAYFAIL) > > > > >> 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. > > Yes if we want to avoid some big size, si_mem_available could be one option. > Actually I tried to do totalram_pages() / 2 like the old ion system heap in > the previous patch version. Anyway totalram_pages in this patch is used to > avoid the buggy size. So let me repeat that totalram_pages is a wrong thing to do(tm). This is not a subsystem I would feel like nacking a patch, but consider this feedback as strong of a rejection as somebody external can give you. A mm internal allocator would get an outright nack. What you are doing is just wrong and an antipattern to what other allocators do. Either use something like INT_MAX to catch overflows or do not try to catch buggy code but pretend a better memory consumer citizen by using something like si_mem_available (ideally think of other potential memory users so do not allow any request to use all of it). The later might require much more involved interface and I do rememeber some attempts to account and limit dmabuf memory better. > And as we discussed in v2 patch, __GFP_RETRY_MAYFAIL was added. And I think > the gfp makes us feel better in memory perspective. wishful thinking that is. -- Michal Hocko SUSE Labs