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 D44D2C77B6E for ; Wed, 12 Apr 2023 09:35:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 21CAF900004; Wed, 12 Apr 2023 05:35:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1CCCC900002; Wed, 12 Apr 2023 05:35:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0BC27900004; Wed, 12 Apr 2023 05:35:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id F0F8A900002 for ; Wed, 12 Apr 2023 05:35:42 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 503DD1A3B94 for ; Wed, 12 Apr 2023 09:23:32 +0000 (UTC) X-FDA: 80672201064.24.9C3655C Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf14.hostedemail.com (Postfix) with ESMTP id 3C57B100021 for ; Wed, 12 Apr 2023 09:23:29 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=srRAZkGN; spf=pass (imf14.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=1681291410; 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=f9fMYDJZDgUQAkG8XezrdJzHQ/H+XHFOp2dBJyvFZng=; b=HH0astCRwFpM52owsARHQe7gHa5kGX0vEtmfHoGjUXCndSjd5Ui8JEgXGqMFL7+G+iz1Ay lW6gQlUg5URpFiL1CRG1lZgzSOa72fjsgqhijSvEHqjpfKZ9wIsebovl7kSPuzdvcO7v5+ hAkTBotzZsFqaoCVZ6EOnodwtrSl6ks= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=srRAZkGN; spf=pass (imf14.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=1681291410; a=rsa-sha256; cv=none; b=sWUSu3je0iQxq633JCQh9qqEoSPjXyq91oZZg8fIbBQBa8ycRi0zjviKtGWd4qt59+3lhn 7YZLeJTvnOWVC+VMqnSMMxqT+G/vR/pnwFgApV9qEWOHrBTYlJhnKlPhkougyHNieoJKZS 5Cphtbx1K0RPVvoN94aZNJP+YocbUi8= 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 B05591F890; Wed, 12 Apr 2023 09:23:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1681291408; 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=f9fMYDJZDgUQAkG8XezrdJzHQ/H+XHFOp2dBJyvFZng=; b=srRAZkGNHFWybWCUH/9iHfY36CH4iNoSYiYJRuBfDoudIVOmtt5MgU7Ec8Tkvwp+50aiTe NA6iHiEjlqIxVAEWMuo1ZAq+rJUEcPHYS8ATBjmlilIpaL8BOX3+lOLxMHVuqO088QIpNs 3LJJzy8nYFgNyTnUWMNnml6O9l/duf8= 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 8FC3D13498; Wed, 12 Apr 2023 09:23:28 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id hZ9xIJB4NmSFeAAAMHmgww (envelope-from ); Wed, 12 Apr 2023 09:23:28 +0000 Date: Wed, 12 Apr 2023 11:23:27 +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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230412085726epcms1p7d2bec2526e47bd10a3b6ea6a113c9cc3@epcms1p7> X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 3C57B100021 X-Stat-Signature: 739nncr4cgwjyao1us997s5u53sndjeb X-Rspam-User: X-HE-Tag: 1681291409-994913 X-HE-Meta: U2FsdGVkX189PSPjY+sY10vzQcVTlVaC+MAve2bsxCZr6RIDs1x+RJ8DEc3cMXAg207vPRdaWTfboddLpxX7x6r0VI4I7VmZWIGBrOUe3peRvzDqtshfsz021sXzIQh+Qz9E3nHPFyJiXO8XL+XtruEDBp3O0OnKmC4uWWGAiM2VjxDTQt+K7nYuVYnHli3NmMwvq588KyyptXwIc5wfWQxJOv90WFTV8eiwmNr1QPHO8eW2V+9YvMQC41v199V9ZvI59MnpEVe5Da7FJZ+NSauB/RG9Vggv579rkd/VJimqnl0d/Oeq2YMhgWxaj8SKiMjEdyf8xTelvupaYu2AlWIaMP9m5UqatF8Vr3AxaouDJYQpg+ZAUTVWx6Kefqm7DMvX91jfR8x3dkO+7P2I55PVW3Pj6tnWJ8FQ5TB3uHh+0h9KHNNcX0frEl/BESAN5K9sLEQiTpehvGbKoROjHKVl9gjgD5ttMdL8FmW91JJXd0SLqlvd5xAai7ZJW506WKu1fkUFAuHlQeGgQtjhqXVjtm2PA8THoKKM4Tt1iW5XKEQAWzS6BDFr3MYbSF44bBdiIycnEUKEYoVzsCWGNlqPAjDV61og4KnfXWDbofAFpkYhxUsWL/J9LgKkIehQ29fY1Kqus3Ou4Z1O8jeauhDxm1EsUjcKtTcS15RNzjZJuX2bnwYEmagumCL+B3vGmCTLlOnRjb6zfnspOxBJ+TYzeqZTVkPUNOxJGKsYjygX1iCmNYSolsvub5zBBq+rv3WuUZFoNNI3Xc+pIHMxBjFP15MwTQzbTEYwaGzmpeiuLjbtJ24+kKp5CpeII+c0aQ8s9nbcErkt/ueylsVpoA/Mt2C7pruGZwT4hvuoQXcN/0N+KIKx+lYKxVOX95uQgMSr2Acl/SON5rvcHfNgrK8fEl1+9eWiSmk3XsHrfFqHozEEI+67zUs4CEFRYvQE49xg7af1LYFhOELfGjd JAEbNGj0 xZ4glFQrzZi0zF0KDrxsFvh5wbnaJvnkMU66WKlh7w7buUGRvVMzZL4F42tAVI7uAVqEC1LnU7HyzZUXAEeu1TSjRDl32j1oVznPv7rjCxJ7C7AyFO1Kre+o/kYLXOOT40AzI3LzARrwDpGX++UF79yWFKUBs169e92SfM2wL6219jV39m3xv2KPiihVLCfXEyoc+6AjQiVCqLQb8jBRJ0qKMKYVlC5ccEan9VmPyBiuRWzsyoTcE042rq3naYt5jBLDkKcFCz27aj3Z6FrGXMMBn28F62CGa//pmMjJ8yZpxr3n2LC6ZmsaNg0GEWFZW+qyxaB3pZN2iNIQ= 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 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