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 24B1CC7618D for ; Thu, 6 Apr 2023 02:17:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9C7026B0071; Wed, 5 Apr 2023 22:17:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 976226B0074; Wed, 5 Apr 2023 22:17:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7F0846B0075; Wed, 5 Apr 2023 22:17:22 -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 6972A6B0071 for ; Wed, 5 Apr 2023 22:17:22 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 3C2FF1C6C1B for ; Thu, 6 Apr 2023 02:17:22 +0000 (UTC) X-FDA: 80649354324.01.B4AFAB8 Received: from mailout1.samsung.com (mailout1.samsung.com [203.254.224.24]) by imf13.hostedemail.com (Postfix) with ESMTP id 858D020002 for ; Thu, 6 Apr 2023 02:17:17 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b="ERw/QcAC"; spf=pass (imf13.hostedemail.com: domain of jaewon31.kim@samsung.com designates 203.254.224.24 as permitted sender) smtp.mailfrom=jaewon31.kim@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680747438; h=from:from:sender:sender:reply-to: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=Gsn8ZXMRUAgEYhGAlwHvevdvZrEdTSi0OLncrBxsoqc=; b=zEbBKlfts+L73gQaEq3uGkvU6soEpuNLIJGya18aN2DwTP7+9b9o+kCYq3IZV3lUhBvdxJ xqLEhf26KKBoqMX2KELv0lpN1LRo90na7yjXhHOf2cbSz2d+X1MgzVtSv1zaOpwaRy4pMK LDIuV+d4HeX3QpX2MvvFEX10K4dEo3k= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b="ERw/QcAC"; spf=pass (imf13.hostedemail.com: domain of jaewon31.kim@samsung.com designates 203.254.224.24 as permitted sender) smtp.mailfrom=jaewon31.kim@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680747438; a=rsa-sha256; cv=none; b=2EmVe5WHMgN30+cYR8Xz6/bhYN1tDjyeznHuZAX411VOK5Ctv/jZVd+GScIJSYsjPNiuBM k05v5sEO1XT9tI4kSfY6umnmIUGDIyLNZmQf6QjbAxRiATtLppUjlKgynmnfBdDQJWRS3j cb7NwEYIdQD0OLbREPKC2wne8RwmOJ4= Received: from epcas1p4.samsung.com (unknown [182.195.41.48]) by mailout1.samsung.com (KnoxPortal) with ESMTP id 20230406021713epoutp01240797505311e0eb09a458ed4e905ae0~TNuLfrNh00981709817epoutp01N for ; Thu, 6 Apr 2023 02:17:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.samsung.com 20230406021713epoutp01240797505311e0eb09a458ed4e905ae0~TNuLfrNh00981709817epoutp01N DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1680747434; bh=Gsn8ZXMRUAgEYhGAlwHvevdvZrEdTSi0OLncrBxsoqc=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=ERw/QcACtytT5nW9YauCxJqsQEzfYFBKu5suQOrdOUe5CHMGbUT0QzcxrqlNIBCOU s80Gj9U65JaFRP6kgz2gv9jESTq2TBl/9usw8FmuJ97vy44W2AY7PerJup0zW6PW/y 0d06YVAwA3a+IZuLbl//cdTLn/6QwTiFuEhgibbI= Received: from epsnrtp4.localdomain (unknown [182.195.42.165]) by epcas1p3.samsung.com (KnoxPortal) with ESMTP id 20230406021713epcas1p3b52018f8c71cc0e70c4b9507959d95f7~TNuKw_K6h2553625536epcas1p3O; Thu, 6 Apr 2023 02:17:13 +0000 (GMT) Received: from epsmges1p1.samsung.com (unknown [182.195.38.242]) by epsnrtp4.localdomain (Postfix) with ESMTP id 4PsQB05wJSz4x9QG; Thu, 6 Apr 2023 02:17:12 +0000 (GMT) X-AuditID: b6c32a35-00ffd7000000d8eb-e3-642e2ba8cb6d Received: from epcas1p2.samsung.com ( [182.195.41.46]) by epsmges1p1.samsung.com (Symantec Messaging Gateway) with SMTP id 94.66.55531.8AB2E246; Thu, 6 Apr 2023 11:17:12 +0900 (KST) Mime-Version: 1.0 Subject: RE: [PATCH v2] dma-buf/heaps: system_heap: Avoid DoS by limiting single allocations to half of all memory Reply-To: jaewon31.kim@samsung.com From: Jaewon Kim To: Andrew Morton 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" X-Priority: 3 X-Content-Kind-Code: NORMAL In-Reply-To: <20230405185650.239f9721f066aa480e83d543@linux-foundation.org> X-Drm-Type: N,general X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Message-ID: <20230406021712epcms1p216f274040d25d18380668ffbfa809c48@epcms1p2> Date: Thu, 06 Apr 2023 11:17:12 +0900 X-CMS-MailID: 20230406021712epcms1p216f274040d25d18380668ffbfa809c48 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Sendblock-Type: SVC_REQ_APPROVE X-CPGSPASS: Y X-CPGSPASS: Y CMS-TYPE: 101P X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMJsWRmVeSWpSXmKPExsWy7bCmnu4Kbb0Ug3dfdCzmrF/DZvHykKbF wod3mS1Wb/K16N48k9Gi9/0rJos/JzayWVzeNYfN4t6a/6wWr78tY7Y4dfczu8W79V/YHHg8 Dr95z+yx99sCFo+ds+6yeyzYVOqxaVUnm8emT5PYPe5c28PmcWLGbxaPvi2rGD0+b5IL4IrK tslITUxJLVJIzUvOT8nMS7dV8g6Od443NTMw1DW0tDBXUshLzE21VXLxCdB1y8wBulpJoSwx pxQoFJBYXKykb2dTlF9akqqQkV9cYquUWpCSU2BWoFecmFtcmpeul5daYmVoYGBkClSYkJ1x 7eYV1oIm2YqVfVoNjA3iXYycHBICJhI7TrxnBbGFBHYwSuw9Vt/FyMHBKyAo8XeHMIgpLFAi MXm3AkSFksTZH1fYQWxhAV2Jpu7VLCA2m4C2xPsFk8CmiADFVz3fxdzFyMXBLHCQWeLktclM EKt4JWa0P2WBsKUlti/fyghicwp4S8z5cYYRIi4qcXP1W3YY+/2x+VBxEYnWe2eZIWxBiQc/ dzPCzPlz/DkbhF0ssazzAdSuGokV51ZBxc0lGt6uBLN5BXwlmv/9BJvDIqAq0XzrPVS9i8Tp n9vAHmAWkJfY/nYOM8jvzAKaEut36UOUKErs/D2XEeaVho2/2dHZzAJ8Eu++9rDCxHfMewI1 Xk2i5dlXqLiMxN9/z1gnMCrNQgT0LCSLZyEsXsDIvIpRLLWgODc9tdiwwBAes8n5uZsYwalX y3QH48S3H/QOMTJxMB5ilOBgVhLhVe3SShHiTUmsrEotyo8vKs1JLT7EaAr08kRmKdHkfGDy zyuJNzSxNDAxMzKxMLY0NlMS5/3yVDtFSCA9sSQ1OzW1ILUIpo+Jg1OqgameoSKZRy7GaIOF quGjCwGm/406Cj0fLVny/rrKpKADkfO+av+Vdzx8tbJkYzy3wYZNHO7brbb/3PBe2/r9fJ/k u37x7cyVEifqMnKCt4VtmF+dl9Kwe8eGmey/35heXi7Ec6Bg/93k0kuMSa13C/umbO/haPWa xlB0qeGNwyUNl4Mqh7vKfrs9uy2yPOo0o9unGSfDJP2q3ZY+ULEIeuQ4N0SB9cSRCdayIfU3 8nfJHKxz3qKy8Yt7pIhw1vacS9nnOeUOtU6Ylz2hX/Dcr6dXXV9GnVlyxO7/tw063fs9q4tr epav7Hk61/XZNtUPnifctxxgn2rntmef6VvjV+dKN7q4vT+5gcFl48S9Ya5KLMUZiYZazEXF iQATvuQNRgQAAA== DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20230406000841epcas1p3630010a770682be0f1d540a448f3e00e References: <20230405185650.239f9721f066aa480e83d543@linux-foundation.org> <20230405172524.e25b62e1c548a95564b1d324@linux-foundation.org> <20230406000854.25764-1-jaewon31.kim@samsung.com> <20230406014419epcms1p3f285b6e3fdbb1457db1bcbaab9e863be@epcms1p3> X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: rg4k1d9hdziku5q6cj4o1wfqdnz9gg9u X-Rspamd-Queue-Id: 858D020002 X-HE-Tag: 1680747437-518013 X-HE-Meta: U2FsdGVkX1/BnPlVODFpekAfZgvEMG2IACHfddJ643oQaVj5dPl8uEuXybakkIrR60WAs14ITyoU0NLlKva+zQowJ6q7AcpIy7H4WAzmEfvgSm0FHDjn6uPJ7r7Z5E8ynLLiRlgTsR92EBTCkHJz9bQVmet5q15A4Nqjt9rmykwU0fvBEVBNkNXcBjPNeoAoMWNyLgFXFEqJ/h49Sn/aWi+UHJCAZWr2QpOkTPS+jdlIaiK+3Xs2SsDsAWxqxlSHGQgMfU3l9uV17C4AiMw0fMCSQuG3ck3FwC7I7DbwHdR0A79C6F7jEGfO7Dz/dJlzMwRzJy+qA7N5vloh8JuvraiwzlQIXSQx1KBKQ3yHgWitYyzZXaMNllCJjX0Bx1DRSRtOh0ovcivgn2p/oinakySog1lhIxm51VeX1n0V70vGcc81gOUVCZm96S1gUAR+hNbZFRL7RLhvoBYgV9bZqO/iuU6rpsNL4gGU5fbQICEd6rAbU2952BDYu8WU3R+6jun1g7ZsAzIBNOrI4uJhSykarudq8po3z4/7P6dj/Gmuw3HjyfwC+cdi2RApvU7GmXsinh+QRQfCwmIhwU9qG3EuFtKCR64pg9Gy9WhMOBzq4bo+41KEiS3CK3Q6P3dfMD4Gmt0XqTfciq+1zAZVbOipMjUz91O2/OZClaObpDwNsyC0oUVHNe4U4fBVj19PwToSUJtZV1klMAep+zYvX7NHolNEzXUgBnSX1zWMsWV8NxIelmJILsrG1DHs0X47C7e9CYXqWPxVbTaTkG0QM0eZyRDAkbRXrRyUZX7A56qFUZHzUdUWOED7iIGfBQ5uNZOENM2a0aoJL4kULuuHXSi0h+SleUd+/M0kQt1SMgk6YmGBoYxyx8j7W5yZmobbtdAearwUf9K/1mSWzPcy8JJylu6C4R6AA0ZHN9bQwl1cLN8ZgYW36XlOnbNN+nqFZrVhL4Jv3vUMQkeQNKT LFNAAO6g dZqHdKPAst0DrAU2knUS7/aofAIxB2P5eCtRINtkEH4mdEJjOHXzArMfXzOGm83636Rarl7zF19UMElWv67Nx1ipNTQUHCuAYNp2aCxwz+yyv54lE/+ZwGhPU5Fhh1ZIQdM3+mzqe7A7EV5buS/mIQ8NeOmqLTNYE5Mlui/lFhfj12jcmJDZowQy0+m0mAcgRUqNddrc3FIQoe9m/BayoE01G/5Dc2sO/jP6o5Yr7Tyf8MBRF7KZK/RyKl3NZmAEG7xkZ5jsM8m6anOi4pGs4jmJebcVe1HDnKvmkLjrfopggaXl4ahBLovaNtZr1iw6sAOyN2Hj+dz+tWVS4HT9TynAZjXdCxBjgklfa5IDcuvBlsajDE+jEu2FzHCLPjc39BR23OuC/MZjdv/ukTMHxPv2/Fg== 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? Yes we're considering a buggy caller. I thought even totalram_pages() / 2 in the old ion system is also unreasonable. To avoid the /2, I changed it to totalram_pages() though. Because userspace can request that size repeately, I think WARN_ON() may be called to too often, so that it would fill the kernel log buffer. Even we think WARN_ON_ONCE rather than WARN_ON, the buggy point is not kernel layer. Unlike page fault mechanism, this dma-buf system heap gets the size from userspace, and it is allowing unlimited size. I think we can't fix the buggy user space with the kernel warning log. So I think warning is not enough, and we need a safeguard in kernel layer.