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 04555C7618D for ; Thu, 6 Apr 2023 01:56:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D8256B007B; Wed, 5 Apr 2023 21:56:56 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 761466B007D; Wed, 5 Apr 2023 21:56:56 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 601B26B007E; Wed, 5 Apr 2023 21:56:56 -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 4C8826B007B for ; Wed, 5 Apr 2023 21:56:56 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0FD04C03D7 for ; Thu, 6 Apr 2023 01:56:56 +0000 (UTC) X-FDA: 80649302832.10.BC39A5A Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 3297140002 for ; Thu, 6 Apr 2023 01:56:53 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=kuo7uiXV; spf=pass (imf27.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680746213; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=645s639VWaW0gE0UgAXUV1IewGhosCVfrsLD8Zy8VWQ=; b=Eda+bbGOI4pmYR7Mqaks3Q3gYRiGCY+mhO0+e517TTFtpUlvvMzqJN5cqHh0jH4C68KqVA VtlpKoHadb4+7zH5lMYelp+SFNBerIS/OLiMQm4pWzgCLyFaCl5WPKUd0l0cYbMB8z307z 35Wc47lofmzTwu77XM5rLkczF79fmzQ= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=kuo7uiXV; spf=pass (imf27.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680746213; a=rsa-sha256; cv=none; b=0HxspFhDoCjEdYPbHe3kz2aGMYV1KeNmvj1kUlA3hheX6LkNNELM3W8ibYAwv2xb8cpHRA 9El9CZM5WaRksMzD6EneAroFZFXBCa9Y+l0nqWpTRD+oxV/JL+6ct5SuEalnNDQkLgzm1o xQ4hDuqm7ui5Sy998CbxaMhTKj6qaOE= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 29D28628B5; Thu, 6 Apr 2023 01:56:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3B921C433EF; Thu, 6 Apr 2023 01:56:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1680746211; bh=NfVX/6hHzwCtO9HI9+XPZetTVkhGP+gQgPt3MPubcPk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kuo7uiXVaEjL4NGKpZ/ikc8NnyHxIM22q0eFCcPGmhranX/JO3hTSRGZf2Y8eEAQL VeKbZ2PDbfGbh0icOYaML7+71C3fqLRioDIOS7pritKeZtSAR8+wIwuQf3gvJITAvP mqDuEA+9mr/JJYl9mwWQGzkpkpbTYxsZ9929/Hw8= Date: Wed, 5 Apr 2023 18:56:50 -0700 From: Andrew Morton To: jaewon31.kim@samsung.com Cc: "jstultz@google.com" , "tjmercier@google.com" , "sumit.semwal@linaro.org" , "daniel.vetter@ffwll.ch" , "hannes@cmpxchg.org" , "mhocko@kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "jaewon31.kim@gmail.com" Subject: Re: [PATCH v2] dma-buf/heaps: system_heap: Avoid DoS by limiting single allocations to half of all memory Message-Id: <20230405185650.239f9721f066aa480e83d543@linux-foundation.org> In-Reply-To: <20230406014419epcms1p3f285b6e3fdbb1457db1bcbaab9e863be@epcms1p3> References: <20230405172524.e25b62e1c548a95564b1d324@linux-foundation.org> <20230406000854.25764-1-jaewon31.kim@samsung.com> <20230406014419epcms1p3f285b6e3fdbb1457db1bcbaab9e863be@epcms1p3> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 3297140002 X-Stat-Signature: wu6o6nbixsddpfy1g7x71rh7iknn8ubi X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1680746213-901475 X-HE-Meta: U2FsdGVkX18Y6T5VaYnK8CM0Regn/vV4x5H0NqnNN4XSsMZWIl1TQNNn0w3xMc6/ZXJ8V6xO4pqz1ms10iP0QfiJKSqPyqh8GQoxaIjy8mVnT8xeVXzErs1vJK+xxlQlVTKyqtR15tIE5Olmx4MzwMSaY4er9KZP0JHPUL3uKiBAHWspq9pPQGJt066ukq+coNPSMlCvYcKUtioYPd2npPdwJsTDbRTIwrWQt3YQLy72uL7vwh8GKZC6XKeUOxh8U/HhSdI8Vhd6tP2gMD7BU+lURaCjLz/YHobVvKJU6p7KT2gS8X3JRmdKUXWpYo4ZECG4BJ0rDaJX1xLwUOjmSBrG8Ny2Gg0mQfCKNzWfBt7jEMQJ/P4KaZRJDg9yvRZnRmgt3u8M7E/SKW25PUJiNUFbOsioub0RhaKjM6XPu7cSZtJWGc2d3Kjlgg2aOWpDGydV9zkKhBSM0zgukzqbZwLUFiiV7ub8UU36gpRupMu1DQZowUIgpoMa3c5yVaKOj9bxEUoIZoRW1hZzt2UEbqo01gFKRZ9Mtr8RgdgjefDujIu4a02t3n1vTgUvTouElC0wX9aff6gaoq0t8vHRWhobWpyk5B9d/CnYEMdIX+f4YeRiK42ZK4d93yhV6iDA560hrHAw2OYeQx6BAsWX8XlcowwgQh4LD5/6M3BubHKqa2SMn0BBTgbWIgKOJdnut951x1G//9B2GXXmGZhIYYRTkbmXfhZcIqkvIaSV0lnCLiAfVyl32ZiE/Ln3gy9iE0kLxv5FthXeCMUxxDTKpf6QvkSmHuYIEvPtRMrHL5IuGWGbCatth2uYeXIuhJBrCyRrlDPSCDJ+TzbGagnk61D0TY7DCvmxyey2rmIU0WI6RQTjI1X1e/NjXK0Pn7vxlGCF9kAuTDWvAh4JNwCNBU2aeRp8UCG1twxx9aQgp2xUjgIAEAnfAe46dkfR3R1q6DOcRLePHznJBwPut0o t4tnH7Yp NKm+hL7tZFgOGNlEqJgr7GDxbWInx23mnRqr/lKV/c9kyy0s5ir4p8nPV+HnL9UVAlzNjls3n5eOvwfKqqgv9vHmnJNhC1lPSCWtOr9wzR42sbc5Kipp6sCvaa9md2kNs6nmZFAtOiuDcdrV1Ie3X8oZCJjqRKYGCvzhkBvWuyr0opLd9sQJMeyYbL9XwK52Im441IejjKBCI5HHqm9tnHi8BalLbYz2IAwphlPoXKQLu4JILk/r1Sd9QqBtpdBdl8WUlSql0CHhdzhKVS72qXw7ytQuRwR/Ewr6xvNQgxjoKGsqa+ZAJdrw7pEhtfCxXYMBbf171Yo5yP66aHOqNspyAy+AeJ4+6GDhxIj4HUWrW0qFWNuPJ/nQLk66hDfkfIZCQjcWopJoUML7baIVG5KY5weO7zEn4qM5QLi4sup/lemty40r3Shpy20KprUJJOAqbDCUDeZeAub2tf1NR/eqtNFF8/d16mwN5z7q1jbSapJ6UE5rXZz5EHfy2o3OGdlUeA9zRhg+LZMpi1OFFiS1CPtjP5NcR2K6rkoB634Hdhz5LlHDiMqejYugpEhuIe8K1OG1rQtRVEoQ= 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 Thu, 06 Apr 2023 10:44:19 +0900 Jaewon Kim wrote: > >> ... > >> > >> --- a/drivers/dma-buf/heaps/system_heap.c > >> +++ b/drivers/dma-buf/heaps/system_heap.c > >> @@ -351,6 +351,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() / 2) > >> + return ERR_PTR(-ENOMEM); > >> + > > > >This seems so random. Why ram/2 rather than ram/3 or 17*ram/35? > > Hello > > Thank you for your comment. > > I just took the change from the old ion driver code, and actually I thought the > half of all memory is unrealistic. It could be unwanted size like negative, > or too big size which incurs slowness or OoM panic. > > > > >Better behavior would be to try to allocate what the caller asked > >for and if that doesn't work out, fail gracefully after freeing the > >partial allocations which have been performed thus far. If dma_buf > >is changed to do this then that change is useful in many scenarios other > >than this crazy corner case. > > I think you would like __GFP_RETRY_MAYFAIL. Actually T.J. Mercier recommended > earlier, here's what we discussed. > https://lore.kernel.org/linux-mm/20230331005140epcms1p1ac5241f02f645e9dbc29626309a53b24@epcms1p1/ > > I just worried about a case in which we need oom kill to get more memory but > let me change my mind. That case seems to be rare. I think now it's time when > we need to make a decision and not to allow oom kill for dma-buf system heap > allocations. > > But I still want to block that huge size over ram. For an unavailabe size, > I think, we don't have to do memory reclaim or killing processes, and we can > avoid freezing screen in user perspecitve. > > This is eventually what I want. Can we check totalram_pages and and apply > __GFP_RETRY_MAYFAIL? > > --- a/drivers/dma-buf/heaps/system_heap.c > +++ b/drivers/dma-buf/heaps/system_heap.c > @@ -41,7 +41,7 @@ struct dma_heap_attachment { > bool mapped; > }; > > -#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP) > +#define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP | __GFP_RETRY_MAYFAIL) > #define MID_ORDER_GFP (LOW_ORDER_GFP | __GFP_NOWARN) > #define HIGH_ORDER_GFP (((GFP_HIGHUSER | __GFP_ZERO | __GFP_NOWARN \ > | __GFP_NORETRY) & ~__GFP_RECLAIM) \ > @@ -351,6 +351,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); We're catering for a buggy caller here, aren't we? Are such large requests ever reasonable? How about we decide what's the largest reasonable size and do a WARN_ON(larger-than-that), so the buggy caller gets fixed?