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 4D53EC76196 for ; Fri, 7 Apr 2023 05:12:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 53CFF6B0072; Fri, 7 Apr 2023 01:12:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4EC696B0074; Fri, 7 Apr 2023 01:12:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B5696B0075; Fri, 7 Apr 2023 01:12:48 -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 29DCA6B0072 for ; Fri, 7 Apr 2023 01:12:48 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id E16C91C6EEA for ; Fri, 7 Apr 2023 05:12:47 +0000 (UTC) X-FDA: 80653425174.08.58E31AD Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) by imf15.hostedemail.com (Postfix) with ESMTP id 2C1D5A0013 for ; Fri, 7 Apr 2023 05:12:45 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UQB10SrC; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of tjmercier@google.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=tjmercier@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680844366; 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=uusv0M8pzUZuhFBllleTZFmrVuInj4LMbYNtb9FUd9E=; b=Xti9Ily+jKan8z+JZeoqLCo/rhmxs9fNwC9mvHm69VXDRnAZ13MRZPfXnYwNrIBtMgb4DF qp84rPI+RdEUpLMoLSn9lyYRRv+FcS/fnKggRIJwXjDKlO6pBK76F5jXeHcZNScxyMSDmN 7TVc/rsAU77zujb6IHs26O9bE3JEI5s= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=UQB10SrC; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of tjmercier@google.com designates 209.85.128.173 as permitted sender) smtp.mailfrom=tjmercier@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680844366; a=rsa-sha256; cv=none; b=mF1fVeD9e1Q+XgQmdIJ25Y69QwI4/Xscyp6iswN120oEW1nydYeZb7gCULf2h7keBsz1FU BA9t9sPt+IGOw/LigGO/+iWHbFvKoeBPcHMOLbTiOmt58rEYTFjH8RH7jRdF2mVtUNMi6E mmoswxe/ID4cte+rL+rnqfsRMZoTXk8= Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-5491fa028adso281969437b3.10 for ; Thu, 06 Apr 2023 22:12:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680844365; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=uusv0M8pzUZuhFBllleTZFmrVuInj4LMbYNtb9FUd9E=; b=UQB10SrC+9suQYS2CMuCOlNeV5lFEP+921z5yMw5670GZ8bRLJ7frNH7DTnvqh4+ub xPKzHZfAf8zLpgxryWFIsCA25rKAmjm4dkPSoiYd+ZszwYxy0A/ZGuBGv2Y9+0KivR9c cu750HODQxFS2fPFSgBf1QZ/ustdULyrqkXJWVINdX9cE88cNJv60MPaVDvKo7IvGcrz iKCeI62SGzPgvgHcy3Qp0R0ebOTbrKMyMmg/zi6A0PmZnmEg+PPuJaF3YmNl/WizHNv7 Vtb7VS4a4XRMF4M2MFthsnbVfCtdhuqp4xhUcXhHq3iyvUkT1jCdEUCXVp5G21vJabni 2oFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680844365; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=uusv0M8pzUZuhFBllleTZFmrVuInj4LMbYNtb9FUd9E=; b=hIEgq4VOIU5ifhEfNxvHX0iMf2tsnvsWDXUynV6oFsmVjCpA+fXPHmyO5SqO9ByCCh ga2UVA1Fav1ac5TZ1oq6wEUkcMRzaUvlkww3VUdUdAYBXxleOvzWfd+2c7AFGSCLjZbf jxcZ0gF8L2SaF5Qom8a/gXARKxzoWpCihDZEA9UngQbS5F8yqR31ngPckakseO0gHn7A i0SZxsV2qehtuaocQ8zqe3vO9/cb+gVOrs5ewt5hywUMUAG80ej1uUWnXblPFsndAZGW Atsvb5sESGaRU5j0j9/PTyg5SfGN0i5NMLtjNbFA5NDodVnR8cYLT91sIi3lo8XQdssa kCUg== X-Gm-Message-State: AAQBX9fra95HUXHY44ms76T0vH75pkUpCfdSN5fB0vIYWlbQDWR4PRnu VeXHMm+geUwLATy4wlYWGIss0zKLNEtRo/yFwqG0tQ== X-Google-Smtp-Source: AKy350ZsYQ7Ar/uGdukXwX+Y6yRNooRBsCYO53br3TJvKjAeBH2LzjDJnwLpWC/CIWLPU1lu8+thSaJn9sRW/dVWcUU= X-Received: by 2002:a81:ac15:0:b0:546:63a:6e23 with SMTP id k21-20020a81ac15000000b00546063a6e23mr470087ywh.0.1680844365042; Thu, 06 Apr 2023 22:12:45 -0700 (PDT) MIME-Version: 1.0 References: <20230405185650.239f9721f066aa480e83d543@linux-foundation.org> <20230405172524.e25b62e1c548a95564b1d324@linux-foundation.org> <20230406000854.25764-1-jaewon31.kim@samsung.com> <20230406014419epcms1p3f285b6e3fdbb1457db1bcbaab9e863be@epcms1p3> <20230406021712epcms1p216f274040d25d18380668ffbfa809c48@epcms1p2> <20230405200923.9b0dca2165ef3335a0f6b112@linux-foundation.org> <20230406163822.faae6a90b3aa4942df6e7442@linux-foundation.org> <20230407022419epcms1p424f1f8a7100aeccac62651ce25cd6140@epcms1p4> In-Reply-To: <20230407022419epcms1p424f1f8a7100aeccac62651ce25cd6140@epcms1p4> From: "T.J. Mercier" Date: Thu, 6 Apr 2023 22:12:34 -0700 Message-ID: Subject: Re: [PATCH v2] dma-buf/heaps: system_heap: Avoid DoS by limiting single allocations to half of all memory To: jaewon31.kim@samsung.com Cc: Andrew Morton , John Stultz , "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" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 2C1D5A0013 X-Rspamd-Server: rspam09 X-Rspam-User: X-Stat-Signature: g9nt6tayiddcqz4izu17faaw1i71x3cy X-HE-Tag: 1680844365-730540 X-HE-Meta: U2FsdGVkX19RmLJ3rglGEDaO98C4Yya1fFeKGvI2+uDZ7Gx/0ZBytdugX2HJbng+m5VaxmO8g9Nr9CRrqRxvIxaJaXgQT1rN7NSm/hY8TFc3SfTBqG0soS3I5noL7OYAE9Zv6a03v6VDp64GyXO1GbiWAr8fphlJB5m23byE70mtGT8WlkyvDBYMK9SC1jFg28zL6Q516rEq9uG4XUT340o29TbrgI/MMo+foC85r43sgXVONVlpEDTmbczEUtW4EZ5HtsPj2UKWd1aXvHlLNsmTSDW8owJZ3qyF4QIIxPp3WnbbVF09TdAFxKlTl3QaaOYML4x3MpNOaLFY73t3UEc/izBS8JcDiTmPcfLQwvyQ3VFgfshNlTIK/csgrHcovU4M1xbEjFYugdcV49JeGAWYbINvPQ41of/9MC4k88zuaL0v9o8fWDjM8AMHjeAG64VQKmVwx1F4+3a17ypz1CM3xPM3SHXEWbIH4yi3+apcMUhwzLiPWg+UHbeIc/AhCp29l8BrIHsCzd1yFCemW3pasjOr9QT1mCjPBK1y1pfRZwqNOdMIhg5BZADgdWawYBcKZxrYtZG1y70ZqwAgbhUHyYYNQ9smIGpIzB0Nti0ED9w9eVf/DjGr5m3zpyA627lTYEbASpEeTWvaVooePMWavKpKhtFRS0EF7h+SCqxytGsIHT3rDJN6ibgBX+WDWmLIIMjo4d7xegmvsmaw1w6hC8uHPwke//ynmhAoQOZ96agicazqptLL1DzOeKnUcVBbruZi2Bb+/7Cwioz0T9u77OJ8kFv0kxtAQNSA5SwOlJDXnfax08TE1yPPWNXtUL4FQ6RIQwU8RSkgbGn/rYUUslh1YSd2CDQTQk967rDtlz41jSZY5DXXJ2MneQuPCvG+Hye66LuaGf0nbErokpT+KzvAcweZlSXW9fXQcIzxLXQdnkDexr/FjaLmKigalYkTJzBhvDQ6j88J2hP Nv5upDHW +RrGxs973L6vTbO+tWL09Srty30Xdi7/o2bZ/ZDQglceY4ljlNLUg3dq+xtbBrW1rXFROu/zcwLq6K7Mx4dM+w8sikcUqAKEZ8/sojVta82qkqoaIxLpwlL4U6aRq2Q849WOdes35CXY7MrorNySDQfp+nQ7SmPxuMhl7Z0XP+T5d5yieeV9ls8kNayFcC8FoeG0fAwRuV0tf1enAOujYTGAPfx6zKP4pWhJyv5CssFsPcSuO+lpEcF+U46IwJ1pDHXPzwWW1B8DwfdqtNjVLZlKzMrmHR12ph0VRQ0wheebOKHeNZ1K5xM73iL85+tcG7lXuCeI22uwHhkIknOW0dfttv7t3ro8aZfVFNv2AkTbk0yoNe8HodO0fDhXClU4dG7bSJujLVXjOoXGNb/O8ZtQ6bSEojN4ZtlOgyWEJYvb5196efKnx2OPwNzRtX9cakadM8RF6kyYBUQf9aIaUdzSkI+CHkKxAduVHo3/uy+3SY9TNtYdutYvDJ14VuxuSsD0S X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Apr 6, 2023 at 7:24=E2=80=AFPM Jaewon Kim wrote: > > >On Thu, Apr 6, 2023 at 4:38?PM Andrew Morton = wrote: > >> > >> On Thu, 6 Apr 2023 16:27:28 -0700 "T.J. Mercier" wrote: > >> > >> > > When you say "decide what's the largest reasonable size", I think = it > >> > > is difficult as with the variety of RAM sizes and buffer sizes I d= on't > >> > > think there's a fixed limit. Systems with more ram will use larger > >> > > buffers for image/video capture buffers. And yes, you're right th= at > >> > > ram/2-1 in a single allocation is just as broken, but I'm not sure= how > >> > > to establish a better guard rail. > >> > > > >> > > thanks > >> > > -john > >> > > >> > I like ENOMEM with the len / PAGE_SIZE > totalram_pages() check and > >> > WARN_ON. We know for sure that's an invalid request, and it's pretty > >> > cheap to check as opposed to trying a bunch of reclaim before failin= g. > >> > >> Well, if some buggy caller has gone and requested eleventy bigabytes o= f > >:) > >> memory, doing a lot of reclaiming before failing isn't really a proble= m > >> - we don't want to optimize for this case! > >> > >The issue I see is that it could delay other non-buggy callers, or > >cause reclaim that wouldn't have happened if we just outright rejected > >a known-bad allocation request from the beginning. > > > >> > For buffers smaller than that I agree with John in that I'm not sure > >> > there's a definitive threshold. > >> > >> Well... why do we want to do _anything_ here? Why cater for buggy > >> callers? I think it's because "dma-buf behaves really badly with very > >> large allocation requests". Again, can we fix that instead? > >> > >There are a variety of different allocation strategies used by > >different exporters so I don't think there's one dma-buf thing we > >could fix for slow, large allocations in general. For the system_heap > >in this patch it's really just alloc_pages. I'm saying I don't think > >the kernel should ever ask alloc_pages for more memory than exists on > >the system, which seems like a pretty reasonable sanity check to me. > >Given that, I don't think we should do anything for buffers smaller > >than totalram_pages() (except maybe to prevent OOM panics via > >__GFP_RETRY_MAYFAIL when we attempt to exhaust system memory on any > >request - valid or otherwise). > > I think T. J. also agree with me on what I shared. > if (len / PAGE_SIZE > totalram_pages()) return ERR_PTR(-ENOMEM); > #define LOW_ORDER_GFP (GFP_HIGHUSER | __GFP_ZERO | __GFP_COMP | __GFP_R= ETRY_MAYFAIL) > Oh yeah, sorry if that wasn't clear. I was referring to your updated check for just totalram_pages() above, not totalram_pages() / 2. > Regarding the dma-buf behavior, I also would like to say that the dma-buf > system heap seems to be designed to allocate that large memory. In mobile > devices, we need that large memory for camera buffers or grahpics > rendendering buffers. So that large memory should be allowed but the inva= lid > huge size over ram should be avoided. > > I agree on that mm should reclaim even for the large size. But that recla= im > process may affect system performance or user convenience. In that perspe= ctive > I thought ram / 2 was reasonable, but yes not a golden value. I hope to u= se > just ram size as sanity check. > > Additionally if all agree, we may be able to apply __GFP_RETRY_MAYFAIL to= o. > > BR