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 C0765C761A6 for ; Fri, 7 Apr 2023 00:00:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F370E6B0072; Thu, 6 Apr 2023 20:00:48 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EE7C06B0074; Thu, 6 Apr 2023 20:00:48 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D88786B0075; Thu, 6 Apr 2023 20:00:48 -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 CB5936B0072 for ; Thu, 6 Apr 2023 20:00:48 -0400 (EDT) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id A452A4037F for ; Fri, 7 Apr 2023 00:00:48 +0000 (UTC) X-FDA: 80652638976.03.0F7D2C4 Received: from mail-yw1-f177.google.com (mail-yw1-f177.google.com [209.85.128.177]) by imf23.hostedemail.com (Postfix) with ESMTP id C39FA14000B for ; Fri, 7 Apr 2023 00:00:46 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GAEu0hx2; spf=pass (imf23.hostedemail.com: domain of tjmercier@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=tjmercier@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1680825646; 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=EUe0Zeu+77um4muZNyM98wqgNCUSH9t8M+sk1P4Rs2c=; b=6Brb7W65t0Za5D6jFE83YSBKYclMHe7z8E4a+8tsICdD4yzYaxVvubNrjKTvLyWc00Pcgo NdM6O9nD2Qki7quKCH3MXBlEO12EA5BBi0rZVZDn9Utu5nQrondYNje8YAvpOlvD7K+TIJ JAhcRzBU81r+UzpYOFZibhDlXSmvq+U= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=GAEu0hx2; spf=pass (imf23.hostedemail.com: domain of tjmercier@google.com designates 209.85.128.177 as permitted sender) smtp.mailfrom=tjmercier@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1680825646; a=rsa-sha256; cv=none; b=SPVARSPGVl7GvKoNAMMhMAYmIChNsvqHzEnkFmGk4w2SdVqGe9l/Bmu/kbFgHwzJfwVAex tqU6pIhG19lwdnQwgKhU5bZPzSbsyuEggTY+qQPbxOCvsg/4pbuYzNJDvQkkwIJbWFzx6P RIHgI/SD0U6CA3+33TIj1mj+qSsKXEI= Received: by mail-yw1-f177.google.com with SMTP id 00721157ae682-54c0c86a436so69160477b3.6 for ; Thu, 06 Apr 2023 17:00:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; t=1680825646; 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=EUe0Zeu+77um4muZNyM98wqgNCUSH9t8M+sk1P4Rs2c=; b=GAEu0hx2ollv+g0TFazo9MnuzGvE0WDNcW64TTrX0NKQ9CqQU1OY6BjBHOgZgeeLCL CGniCLuxUFAfE9r0tZhfZs5/oFl6eiA/uOSitNgdka5p7+CVUwEOwdZd8MWbi0qxj9SJ 8iwTgtLb3G1q2pQgNWyBjxWuOui/eKrOTJkOMuFUYtAQ8lPoM8hK/+fpd5zKfwNRPYsq JtVcrH8ZSI9sZ+a6X9dXiXZXZC66l6g0lJEmUOzY9CBGZV1NWKkPGee3AAo8MEKzhTWP DNsYUwHbhlG5x87B60Wco+S0q0utb+UVgVdGIwUTHjt34Hbohp7KBaXTH+/v3CtC2LLy 6MYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680825646; 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=EUe0Zeu+77um4muZNyM98wqgNCUSH9t8M+sk1P4Rs2c=; b=MhtHSnZhg9Kgnocho4sQ/0fDt3GZ/UxxoSgDfrnZK0WX+bnsYwicfCYmHcMbLqQVfh kx1ytmRAoPLZElUa/SA3WR3JMfDdZWIh4FqvRBM/v9q9NahbbE9xlsslTh6gWJpL7JOn s5f8F25uv1Ojffmc2e4M0BcVc/k/gIw/8+TdCeE3W5DGNegb5SMbqjO6UekMbXNrplDI 4S6d6PjOXNgYXHeXf7rO8R944ygtxebtISrtAugBKjx2zzHBhv9Y8C3/zTDHFPq95aDC R6mHsbobfNm6oish7Ncz5purcM7s3iG/H01bNm6ErJM6gtbR8fwEsOsL+FJjxzSgIkYp kGtw== X-Gm-Message-State: AAQBX9fNAtDtNJXcOlnKLAdkpzhQ9Hm+xyx3cotoaXDctqp9Z98bhTxB oA2P6eGDikhs7EReCUVyRinuRQNVTwSPSmA3F+cahg== X-Google-Smtp-Source: AKy350bf6UAG8mhENjiS0Lfk7jW8qr2aRjuZOYeJPenecPeBYqIeH1wo/a3sO+5YoLHoz5czfJvPs1BbexpqT4d5WxA= X-Received: by 2002:a81:ac64:0:b0:541:7237:6e6b with SMTP id z36-20020a81ac64000000b0054172376e6bmr84906ywj.0.1680825645755; Thu, 06 Apr 2023 17:00: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> In-Reply-To: <20230406163822.faae6a90b3aa4942df6e7442@linux-foundation.org> From: "T.J. Mercier" Date: Thu, 6 Apr 2023 17:00: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: Andrew Morton Cc: John Stultz , jaewon31.kim@samsung.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" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: zrjf8asqjfzznuqczxbgttjhpyhkus5s X-Rspam-User: X-Rspamd-Queue-Id: C39FA14000B X-Rspamd-Server: rspam06 X-HE-Tag: 1680825646-667415 X-HE-Meta: U2FsdGVkX1/pVhlzUk1KiR67mKPBJ92lJmDejCKykPe2BoNqiwMgzNmTFbLCGPwlJY4mo0hFH2mYDH2DPgr9+Frdu6knNE5M4e2R/PChZmfoABIIrY2frFARCNn/sbtuLyhANV2sZyzKUnQmeRDJNFPbpsd0kfhBuxLAW+C2HnB4EogzAhOohHg2SccCrbRZsf3f0Pkk1kBZS0CHwitjf+AgRm0cWlKX351SVudiWEygzaOSPKeTfVIxKoiQR0LToAioRayGaPfKxNVvzZQ+aKRsVvkSKDXE42h9mJRmKz/OZ90yE6e87CA7uJMyhqpxj6L37esFD6uJzi04hYtu1jVaBW5xEeVC1/80Bw/tM063JRqHPaywl6lNc0wV6DQaIUxBNh4KUi+gvTXXr1mOZu4x2Bp+F1GjO9Pipkt4V+L5u9p3Ce2howuitUJHpo1pHQr+wl2/7ho7bdYAfj/X7lB1uKrv5Jf9NiEGEe5KpinKccQ2MyOh09qFF9KdDd4iIaDa0FgfWLDyNaHgWeEQ2DDmaRnGMwSCEqsvppJssEswCQ9y6lnk65ObTWYUAaRiX/sCrMQ6To/oa5I+Ej94t3hJRXJ0TuqEBlAsfJfEcLmnK06/EvxwNfTGG/ue0oAkhwzH9wr7VzsaUlw1He8gYdfClIPYzNH+92NpNmErZaiLhgcw/CZKIv29OSE78A8YJWFXzCE6kGuqqCDYaADTNAnPJrfclPFq+ZWtRfVi8MKpSmJVehtEUn7/FELVYuF8RQjpyOa6wGuAfsrW29eFE+fFgsvJBlkQdlqyvw+eFBOCm+qpIzb/YlchQFJlXPr45IP2eqds4R1GEqZqeb22JoAlTnqAWz3YXVr+Sz4DFRS7TG60IO2ENxHaU/EbR98ZMFVVoD8f3/Ighqd+yrvz5ic26RhJJdlgorN6K0AsUJ3XXj5U4Cg/MNIFFUK3UTN5sSj9O0Ic46Xu9buAMW5 Yhh9xwQ1 Ng97364eonOi0Wr4qguPvqynk66Vk+GbKqkteKh/+XlyRjmoKRLkTpYdH+Noj+xRzj/KM1Sv5nb8biJgIl+n9y6s63R1nU6n8bttw/6NsrpfNmbYRRB3vd9czH3d+v/SPBnX3CRbsexd0bMgkPqZ2Qd/quOzfumYvYuDBiQEHyzKcnvkRmnaKaby/AnFor9clCM6Bh+nmsYovPGFB0uq/IJ+a+J0nFmsRKqSPMQRZEBjqLagGYsh2ZqvRDM2sJDtoDGjVPLDmYJ9yzYWHvmcZQzwziLK1CPeXQ6plJFELu+pVfwoqlu1G6Z14C5qcwmHPUp7DwPyXYTkVKGpO2unYqiBv7Ab+d5+/C4z4kXPm4kMOH9I+74LzR5da2+p43yQqdVFqcx3wSD8DoRtD99oWa7L7u8AGojHAuSl1CaL+3NAJs9Phfa7g9mT9w+z/N/M7W6RbfasxcPKLlte4dgJpMKbMUZt7CmWol8JEWVdB2LDHpgw= 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, Apr 6, 2023 at 4:38=E2=80=AFPM Andrew Morton wrote: > > On Thu, 6 Apr 2023 16:27:28 -0700 "T.J. Mercier" w= rote: > > > > 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 don'= 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 that > > > ram/2-1 in a single allocation is just as broken, but I'm not sure ho= w > > > 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 failing. > > Well, if some buggy caller has gone and requested eleventy bigabytes of :) > memory, doing a lot of reclaiming before failing isn't really a problem > - 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).