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 X-Spam-Level: X-Spam-Status: No, score=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3A0EC4320A for ; Tue, 10 Aug 2021 08:40:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B21BA6056C for ; Tue, 10 Aug 2021 08:40:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234316AbhHJIkq (ORCPT ); Tue, 10 Aug 2021 04:40:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38160 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232964AbhHJIko (ORCPT ); Tue, 10 Aug 2021 04:40:44 -0400 Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 792DAC0613D3 for ; Tue, 10 Aug 2021 01:40:22 -0700 (PDT) Received: by mail-wr1-x42b.google.com with SMTP id h13so25148415wrp.1 for ; Tue, 10 Aug 2021 01:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=cKbU9FcikmLQJ8ei5FqM01XsNg7Lhvb/CqBLRSs+e6Y=; b=dyIuT2n2VcPiM/RBZyvglfDmYnDB6Khh/nbdE68r8gYpY/a2NOrDaGfZLTs1W/+53t vXS/cZ/tC1I9/7dqHtnrmgMvWpGq9dGx95D1TIug5tn0JH7x68v/1Ix3ehVQ3mzJinRI GUr9/F01AqBZbk8e0i4kbq2w26FwQ6BX+66Fo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=cKbU9FcikmLQJ8ei5FqM01XsNg7Lhvb/CqBLRSs+e6Y=; b=rupN6doTvmAXoWJj6sQyVZ1lOzbxVJs+8zLuwOxLf5soFvvW8/KXICrQDWyweaqWEG CMSih42tYYpWGF5euY00xM0l9fbfUN0S4E4TBs0eQR/7Gde10VI6n9JHt0WisWKwmmEk LsLYk2zDpHbs8xy/tD8tLZzGwVwQ1iPMeHdx8mJXWHQhWpNkTDe7bjfvZzNptbUrwF6e /DKAvHhCHo55R/395oD+++u4RwGmS2qfxL6p0IIgszTr6e7YsMw1YL1fpUIz26rxB8BN VzUYwBV0V3okVZzlJOfVWVhYZFRnm7OY6Hrmai9VdvVHos2UvXUp41hh2b0N2ZvuPX4r 3ctA== X-Gm-Message-State: AOAM532Yfnn3z22udJNtWVkevwUI0keAjCDTrcPoUc1JY5mY7hdLZju2 bKC5Thk9FmZgA2+XfmtXYKeh8huyI8aTVQ== X-Google-Smtp-Source: ABdhPJza6SgqUQMLMWRHmcm7FQ9wXAO72W40L4Idi8UXF8r5IQoBj3uhgCeKhzBt6M/C31Jpx7GRDw== X-Received: by 2002:adf:ee4e:: with SMTP id w14mr29754692wro.15.1628584821138; Tue, 10 Aug 2021 01:40:21 -0700 (PDT) Received: from phenom.ffwll.local ([2a02:168:57f4:0:efd0:b9e5:5ae6:c2fa]) by smtp.gmail.com with ESMTPSA id c15sm22801342wrw.93.2021.08.10.01.40.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 10 Aug 2021 01:40:20 -0700 (PDT) Date: Tue, 10 Aug 2021 10:40:18 +0200 From: Daniel Vetter To: Sumit Semwal Cc: Hridya Valsaraju , John Stultz , Benjamin Gaignard , Liam Mark , Laura Abbott , Brian Starkey , Christian =?iso-8859-1?Q?K=F6nig?= , linux-media , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , lkml , Android Kernel Team , Greg Kroah-Hartman Subject: Re: [PATCH] dma-buf: heaps: Set allocation limit for system heap Message-ID: Mail-Followup-To: Sumit Semwal , Hridya Valsaraju , John Stultz , Benjamin Gaignard , Liam Mark , Laura Abbott , Brian Starkey , Christian =?iso-8859-1?Q?K=F6nig?= , linux-media , dri-devel , "moderated list:DMA BUFFER SHARING FRAMEWORK" , lkml , Android Kernel Team , Greg Kroah-Hartman References: <20210722190747.1986614-1-hridya@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: Linux phenom 5.10.0-7-amd64 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Aug 10, 2021 at 01:54:41PM +0530, Sumit Semwal wrote: > Hi Hridya, > > Apologies for the delay in responding. > > On Wed, 4 Aug 2021 at 03:09, Hridya Valsaraju wrote: > > > On Mon, Aug 2, 2021 at 7:18 PM John Stultz wrote: > > > > > > On Thu, Jul 22, 2021 at 12:07 PM Hridya Valsaraju > > wrote: > > > > This patch limits the size of total memory that can be requested in a > > > > single allocation from the system heap. This would prevent a > > > > buggy/malicious client from depleting system memory by requesting for > > an > > > > extremely large allocation which might destabilize the system. > > > > > > > > The limit is set to half the size of the device's total RAM which is > > the > > > > same as what was set by the deprecated ION system heap. > > > > > > > > Signed-off-by: Hridya Valsaraju > > > > > > Seems sane to me, unless folks have better suggestions for allocation > > limits. > > > > > > Reviewed-by: John Stultz > > > > Thank you for taking a look John! > > > Looks good to me; I will apply it to drm-misc today. Please don't, this doesn't really solve anything: - it's easy to bypass, just allocate more buffers to get over the limit - resource limit plan is cgroups, not hand-rolled limits in every allocator - the ttm "max half of system memory" is for pinned memory, to work around locking inversion issues between dma_resv_lock and core mm shrinkers. It does not actually impose an overall allocation limit, you can allocate ttm bo until your entire memory (and swap) are full. Christian König has merged a patch set to lift this by reworking the shrinker interaction, but it had to be reverted again because of some fallout I can't remember offhand. dma_resv_lock vs shrinkers is very tricky. So if you want resource limits then you really want cgroups here. Cheers, Daniel > > > > > > Regards, > > Hridya > > > > > > > > thanks > > > -john > > > Best, > Sumit. > > -- > Thanks and regards, > > Sumit Semwal (he / him) > Tech Lead - LCG, Vertical Technologies > Linaro.org │ Open source software for ARM SoCs -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch