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 1CCBAC77B6E for ; Wed, 12 Apr 2023 11:38:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8CD076B0074; Wed, 12 Apr 2023 07:38:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 87D726B0075; Wed, 12 Apr 2023 07:38:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 71DA4900002; Wed, 12 Apr 2023 07:38:09 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6235A6B0074 for ; Wed, 12 Apr 2023 07:38:09 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2A09A80114 for ; Wed, 12 Apr 2023 11:38:09 +0000 (UTC) X-FDA: 80672540298.03.F4AFEBB Received: from mailout4.samsung.com (mailout4.samsung.com [203.254.224.34]) by imf24.hostedemail.com (Postfix) with ESMTP id D362A180011 for ; Wed, 12 Apr 2023 11:38:04 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=ETn2rUFy; spf=pass (imf24.hostedemail.com: domain of jaewon31.kim@samsung.com designates 203.254.224.34 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=1681299486; 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=PCRyiCdo9buNSVxIlVwF0a59tYap8pCla0PxLClsOhY=; b=lxidV5BPuHPyMlFZcx78JiRX+f14bh5Bv3791QmofRGEF9Hjj/AP/w/6rLdi2DuXbOLnoB IfRs/w1NivN9zp0md8O+AVu84JDZ3thWVojsgvWmCfz22hVjrbhbHLznkJlgeqH9F5FSw/ x8/mheYzidKuKqA46OaAfxiooE8gODc= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=ETn2rUFy; spf=pass (imf24.hostedemail.com: domain of jaewon31.kim@samsung.com designates 203.254.224.34 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=1681299486; a=rsa-sha256; cv=none; b=Jg5xlQde7luGzJW2VYeyoE4A+p3MwreE6LwMtW5xS3QjfbWJ4llnqlI7ZSmUaMD7UUGJr3 hiPvEPy9+w78YNcyaAa4zwovsNKo4oN/DJmrAYzxwzj7Lmt1zEWLpLFYTjUFVniCLusP6n 4Pgryppj/lWLK7oubWJxklFpTGNLWOo= Received: from epcas1p1.samsung.com (unknown [182.195.41.45]) by mailout4.samsung.com (KnoxPortal) with ESMTP id 20230412113801epoutp040e3db918c9573050b2c8e8d62316d0fb~VLPhhB71_3008530085epoutp04a for ; Wed, 12 Apr 2023 11:38:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout4.samsung.com 20230412113801epoutp040e3db918c9573050b2c8e8d62316d0fb~VLPhhB71_3008530085epoutp04a DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1681299481; bh=PCRyiCdo9buNSVxIlVwF0a59tYap8pCla0PxLClsOhY=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=ETn2rUFy1Ub3gcUDd91EwRpYobL2nDvHifKXG5TbfZW0l7jGp0wXALXt0oZ//7ail UQXYH9himAhhweC/vO03XKCrHw4m7pkHMud290MnXJCbO7GO4Z6HxPSun4D+332Bqw AFCc5RKigJe5gsEj23rdmIgHR/ntZeGKz+wlWAm4= Received: from epsnrtp1.localdomain (unknown [182.195.42.162]) by epcas1p3.samsung.com (KnoxPortal) with ESMTP id 20230412113800epcas1p3fb76ac32ffb9cb6631f65160c6e36c1b~VLPgvL3RJ0352403524epcas1p3o; Wed, 12 Apr 2023 11:38:00 +0000 (GMT) Received: from epsmges1p3.samsung.com (unknown [182.195.38.248]) by epsnrtp1.localdomain (Postfix) with ESMTP id 4PxLLH6y74z4x9Pv; Wed, 12 Apr 2023 11:37:59 +0000 (GMT) X-AuditID: b6c32a37-c1fff7000000243f-24-64369817ca3d Received: from epcas1p1.samsung.com ( [182.195.41.45]) by epsmges1p3.samsung.com (Symantec Messaging Gateway) with SMTP id 25.16.09279.71896346; Wed, 12 Apr 2023 20:37:59 +0900 (KST) Mime-Version: 1.0 Subject: RE: [PATCH v3] dma-buf/heaps: system_heap: avoid too much allocation Reply-To: jaewon31.kim@samsung.com From: Jaewon Kim To: Michal Hocko 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" X-Priority: 3 X-Content-Kind-Code: NORMAL In-Reply-To: X-Drm-Type: N,general X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Message-ID: <20230412113759epcms1p8cb15b54e3a96c7616419cb030d16f804@epcms1p8> Date: Wed, 12 Apr 2023 20:37:59 +0900 X-CMS-MailID: 20230412113759epcms1p8cb15b54e3a96c7616419cb030d16f804 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Sendblock-Type: SVC_REQ_APPROVE CMS-TYPE: 101P X-CPGSPASS: Y X-CPGSPASS: Y X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKJsWRmVeSWpSXmKPExsWy7bCmrq74DLMUg+7N5hZz1q9hs3h5SNNi 4cO7zBarN/ladG+eyWjR+/4Vk8WfExvZLC7vmsNmcW/Nf1aL+30OFqfufma3eLf+C5sDj8fh N++ZPfZ+W8DisXPWXXaPBZtKPTZ9msTucefaHjaPEzN+s3j0bVnF6LF+y1UWj8+b5AK4orJt MlITU1KLFFLzkvNTMvPSbZW8g+Od403NDAx1DS0tzJUU8hJzU22VXHwCdN0yc4COVlIoS8wp BQoFJBYXK+nb2RTll5akKmTkF5fYKqUWpOQUmBXoFSfmFpfmpevlpZZYGRoYGJkCFSZkZ+zp 7Gcr6FGqOPVzG1MD40LpLkZODgkBE4lzs+aydTFycQgJ7GCUeDdxMZDDwcErICjxd4cwSI2w gL/EvhdzGEFsIQElibM/rrBDxHUlmrpXs4DYbALaEu8XTGIFsUWAaro27wSbySxwmVmi9eo+ NohlvBIz2p+yQNjSEtuXbwUbyimgJ7H24BlWiLioxM3Vb9lh7PfH5jNC2CISrffOMkPYghIP fu5mhJnz5/hzqPnFEss6HzBB2DUSK86tgoqbSzS8XQlm8wr4Stz5uRhsF4uAqsSGjS+g5rhI vGv/CjafWUBeYvvbOcygcGAW0JRYv0sfokRRYufvuYwQJXwS7772sMK81bDxNzs29o55T6DO UZNoefYVql5G4u+/Z6wTGJVmIUJ6FpLFsxAWL2BkXsUollpQnJueWmxYYAyP3OT83E2M4PSr Zb6DcdrbD3qHGJk4GA8xSnAwK4nw/nAxTRHiTUmsrEotyo8vKs1JLT7EaAr08kRmKdHkfGAG yCuJNzSxNDAxMzKxMLY0NlMS5/3yVDtFSCA9sSQ1OzW1ILUIpo+Jg1OqgWn1i2Wv1So2H6m+ FfR/5ieFA5M1DSZKqJjfXj9frPeS1jebK3y333o9nsAtqlpzWObetv9NrLsmPN/gzMpQMU1D 4xHz7+8XLL5Gf303q3GdvMx2vVNb0iLblzZut7nha+g8ccMGBUNt7n99XBceVNTy/ut8OH+T sP+npl1bbh3Z8SWjuvRnTOl3h7NvG2YuLVfP+9Je1Hz62cWzVb//HVyspZvCVP5y/SOVHfvm HjsrdoTxG2fO0+Mcj166PV76a9lBBV2GhVLzQlifM9hfn8K9o7Tr+72m2clBj5sv/T6v5hS9 V2f+wl+TjZk+zbmoubA/NqTO6cfTZxOnx9upcxcnf5hv+2fh+7y8czP3WP8P+qzEUpyRaKjF XFScCABalK9zSAQAAA== DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20230410073304epcas1p4cf3079b096994d69472b7801bd530bc7 References: <20230410073228.23043-1-jaewon31.kim@samsung.com> <20230412085726epcms1p7d2bec2526e47bd10a3b6ea6a113c9cc3@epcms1p7> <20230412094440epcms1p445319579ead0d0576bb616ebb07501b4@epcms1p4> X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: o8btma6oe4nupnqntwk7epi79x6sujaq X-Rspamd-Queue-Id: D362A180011 X-HE-Tag: 1681299484-58125 X-HE-Meta: U2FsdGVkX19RrP5cBeO/EQYFZ0o6mCEQz5bQtDNVMa+HcYVfhT1T2zdlHj6OMVxe+6+FxWHf/COnljrzxibtld6FOEmUgw+XtwdT2FJZfXv3/Edm5uYWTfQOKOKM6GhcXxA2tBh5Sp5wMiz9X1VpomZxuUsKKu1+xPh4StOpuq3eTaWuq0K871fqOXO3gIOuzGb8TYeh9Gx+T45Ld0o1kGwG04x86VP043bJvfoPC2Bt+7MlH4VDHxHCCzG3zNn7w8OAOg66//mcN9+/+ICxqW4nq7npAm7wtV6h4LvYAtSmZBlhBzbXO5n2azlnumHFtT4lbgvaCZRImfkIB5hRuRqBDSZqL+1rQTW1KEMXksfjnNjO7UaR2T/dDCFXG3vFGRh1W8BNnQhjGw6vPmwEO5wz2LN6I6cNwZxsklfBe9JDP7+6tDH47GJMlvV+rCrIgQ/J8+0kGrxoLXiUHELrGe+xcNWqTXKlGc0oniIFuUHnmnq2IrNQFe0Ou0KZOImR5fkDeuF1++8ZfJM9D4D2mh31NRjHvZ9XD6kl0rEzkanjizexS9nRe5w6vKVU8AEO9k2HBvvZ1i7Is/GJKezy/7Mba/5AuYIiBGZnC25QB4QFGQM+a6nYv19cLkCQzJi7U+5q0coJUjJiQIjix2fz7sY6KzPekevDhAErXmPm2SoiInonskzId8+ytW7KGC+86ztEFqB5gNgtHeIzGxC9NpQ2Wl4Pd0VCnbB7HW3CRNkc/UlsAPufHjz3l5rRaMwWldvY/XVoxMp+9CW//ze0Ri69GJjWX7VhbWHoIb1iH9SGbzJNtWcJ36fqyrjWrjr0B3Xa/lnFXHyBaSX1tkUPGvHmHPKQFCUThdUZvujW0s/rNemBzqUZGEbK5kTA+fa6Hto1aBamU+62dkfbz5YHSu+SmRgXz9CgJnxfenk2jA+3mX7BFiZg591nh+mr2XBzMvduV5Di0KSYetQHf2Q zQdSnO/F q6BXUsRwtcKrahUATU6xePpEI5pMh1e+D2pbYoE9GrB0zOf+OxgEGQ0puyd8JYe0mWwTWCyEx/vNLcyccfpDgMZ8qgPmTye19u8VoGmzSaHOqYbr1Q9GID1K7/Yf0sjNi+Y1hSJSyggcHgn+jD+1W84SCLeMaLP/LEhcWfDVhQpv+kY76y0cVcfippXpBHE5Ltliulhshi1l3Hekd51TcDvX0OnuFiH1bedyhVgALJd2Dqth1Zf534utoN+lxgpgtiTuwZZDQ0LVBS05ZIb6z/J9a7C6UX+iAQl5lrZxJfu7ASERdVZZ71lG1ZX/eoBSt3zZGeAOA+o6HFSGznqPiDjqbNnXdoGlyYu6eSwu3Ov6jSqhSNMK6ImEWXuFyAVu9VpA5OD8kQBruvbPSTCMoza9H/w== 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 Yes I think you're right. As a allocator, dma-buf system heap looks to be loose in memory allocation. Limiting dmabuf memory may be required. But I think there is no nice and reasonable way so far. And the dma-buf system heap is being widely used in Android mobile system. AFAIK the camera consumes huge memory through this dma-buf system heap. I actually even looked a huge size request over 2GB in one dma-buf request. Jaewon Kim