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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 E88F2C43457 for ; Fri, 16 Oct 2020 23:15:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8AFCE22203 for ; Fri, 16 Oct 2020 23:15:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Oi+V1WJt" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2410922AbgJPXPr (ORCPT ); Fri, 16 Oct 2020 19:15:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51192 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2393118AbgJPXPq (ORCPT ); Fri, 16 Oct 2020 19:15:46 -0400 Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A4517C061755 for ; Fri, 16 Oct 2020 16:15:46 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id h62so266911oth.9 for ; Fri, 16 Oct 2020 16:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z/utRDTKVHmHoEv/2/0Wo96JPENEebgv5nLtf2BjNsM=; b=Oi+V1WJt62DGA+OLvUtpmMrFw9shQt3hUS/kNEujvoDH0S+ng6vAYPzCIgge+f3w9u TKWiYzRhkNSA9GoKq34ilGiHvwx6EY6aftODB89USCCvqSBrOF9Ahb1YH6AVXBZCgQig 4DlUkffsXOsF1pIm13wAFD7dnXVaJqoYN2sqj94xan8ytJ2xtxnef5agl5SMLLqg4NgB QpAQQPmcmS3RUog/rS5HW2x/+33CWgbJZeTEULDKM2cMYyziRnQ50KtbeBtD/GX0MMx9 fEvYXSp+sAAsczFNL8AvoNylNDa3YEDww1jbOh3ovT1X6SZKJrjCeHi3LzO3cklJhFnp KO+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z/utRDTKVHmHoEv/2/0Wo96JPENEebgv5nLtf2BjNsM=; b=TKXyCk6VPmkFEGmZeRpf3+26Jm37pZr5TWyWwH3SsV6jje90IXXFd51k1GF8a1dF4y b86KhIweeha9YolsrIexfYg5osW15PdNq9tyjqvUZVM2Ul8PjWIlCk6xmRnepfOfhgrY q0QbeJJI60PFOj3q2dhcsj5TnZepGi4UFKKRPPyb76FeNphSW5HMFSTnAUS/BK1Ki9iA 7GpyNLwMG18FH+lFjV57qHEHUOVAe//QSE9urBvOJP1onUku5l3bnnCuhvf2QYT0hqdc aE94K2vyQaOVKBe6KJd06Z2kZ6/qNy4fJE1gLNVskPHQCCf12bqTOap8KZk4shlkFNKy ok4Q== X-Gm-Message-State: AOAM530A7PU+sc9Qg9toZA2DeSavCPynsUFtY8/QDyDNxEYgqO+c/czw fr7WssWyMUT4sNBqUKtvkMjqEN/pESxYvORs5euZ0A== X-Google-Smtp-Source: ABdhPJx+Js3ydQFBUP7ACgCzkoV+mCC9MxMLL2meKWUMIA/Fue2cHeE5SzEFTuMIFXv2hDabWqdWiVicuLD7Dfqz5J4= X-Received: by 2002:a05:6830:1082:: with SMTP id y2mr4127841oto.221.1602890146021; Fri, 16 Oct 2020 16:15:46 -0700 (PDT) MIME-Version: 1.0 References: <20201003040257.62768-1-john.stultz@linaro.org> <20201003040257.62768-8-john.stultz@linaro.org> <20201008115101.4qi6wh3hhkb6krg5@DESKTOP-E1NTVVP.localdomain> In-Reply-To: From: John Stultz Date: Fri, 16 Oct 2020 16:15:32 -0700 Message-ID: Subject: Re: [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap To: Brian Starkey Cc: lkml , Sumit Semwal , Liam Mark , Laura Abbott , Hridya Valsaraju , Suren Baghdasaryan , Sandeep Patil , Daniel Mentz , Chris Goldsworthy , =?UTF-8?Q?=C3=98rjan_Eide?= , Robin Murphy , Ezequiel Garcia , Simon Ser , James Jones , linux-media , dri-devel , nd Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 16, 2020 at 12:03 PM John Stultz wrote: > On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote: > > On Sat, Oct 03, 2020 at 04:02:57AM +0000, John Stultz wrote: > > > @@ -426,6 +487,16 @@ static int system_heap_create(void) > > > if (IS_ERR(sys_heap)) > > > return PTR_ERR(sys_heap); > > > > > > + exp_info.name = "system-uncached"; > > > + exp_info.ops = &system_uncached_heap_ops; > > > + exp_info.priv = NULL; > > > + > > > + sys_uncached_heap = dma_heap_add(&exp_info); > > > + if (IS_ERR(sys_uncached_heap)) > > > + return PTR_ERR(sys_heap); > > > + > > > > In principle, there's a race here between the heap getting registered > > to sysfs and the dma_mask getting updated. > > > > I don't think it would cause a problem in practice, but with the API > > as it is, there's no way to avoid it - so I wonder if the > > dma_heap_get_dev() accessor isn't the right API design. > > Hrm. I guess to address your concern we would need split > dma_heap_add() into something like: > dma_heap_create() > dma_heap_add() > > Which breaks the creation of the heap with the registering it to the > subsystem, so some attributes can be tweaked inbetween? Looking at this some more, this approach isn't going to work. We create the device and then we call dma_coerce_mask_and_coherent() on it, but as soon as the device is created it seems possible for userland to directly access it. Again, though, as you mentioned this isn't terribly likely in practice. The best thing I can think of for now is to have the uncached heap's allocate pointer initially point to a dummy function that returns EBUSY and then after we update the dma mask then we can set it to the real alloc. I'll go with that for now, but let me know if you have other suggestions. thanks -john 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=-3.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 6B4FAC433E7 for ; Fri, 16 Oct 2020 23:15:48 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E1DB820878 for ; Fri, 16 Oct 2020 23:15:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="Oi+V1WJt" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E1DB820878 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 52CF66F3DA; Fri, 16 Oct 2020 23:15:47 +0000 (UTC) Received: from mail-ot1-x342.google.com (mail-ot1-x342.google.com [IPv6:2607:f8b0:4864:20::342]) by gabe.freedesktop.org (Postfix) with ESMTPS id C64636F3DA for ; Fri, 16 Oct 2020 23:15:46 +0000 (UTC) Received: by mail-ot1-x342.google.com with SMTP id n15so4044382otl.8 for ; Fri, 16 Oct 2020 16:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=z/utRDTKVHmHoEv/2/0Wo96JPENEebgv5nLtf2BjNsM=; b=Oi+V1WJt62DGA+OLvUtpmMrFw9shQt3hUS/kNEujvoDH0S+ng6vAYPzCIgge+f3w9u TKWiYzRhkNSA9GoKq34ilGiHvwx6EY6aftODB89USCCvqSBrOF9Ahb1YH6AVXBZCgQig 4DlUkffsXOsF1pIm13wAFD7dnXVaJqoYN2sqj94xan8ytJ2xtxnef5agl5SMLLqg4NgB QpAQQPmcmS3RUog/rS5HW2x/+33CWgbJZeTEULDKM2cMYyziRnQ50KtbeBtD/GX0MMx9 fEvYXSp+sAAsczFNL8AvoNylNDa3YEDww1jbOh3ovT1X6SZKJrjCeHi3LzO3cklJhFnp KO+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=z/utRDTKVHmHoEv/2/0Wo96JPENEebgv5nLtf2BjNsM=; b=NiDI6skAcObpuWnXaOPZm2Jwk32Tl8BkcKo8jJOKQAoJDtTz4PmHnfA9bsm2JEUC0g f+gkm1g0Q2XjSvzbfoG8BAf4EolwukkqqErPqj+WJsRGfKk0maKwYb+Z82ePsLNu7IuG vwK2wjJXYtXVYOkWdy30jICcssP/fy75ulpFLRoEgAOXwaaqArm69VzwVvGhQlYKeaQI bClfNLMW5fnVzJ2LVaMT8EEBJ3kVdkwqVmobnoSiE+g0iDEt2Qjz29mmvI4mKbyuTEFl JxqV/0pvezhs9F3kRJaUbDMFqLXtQu6+8DI/U1zZIle11qCveqXypQ3laBlETN4kaIQq gA3A== X-Gm-Message-State: AOAM532ZbPjJ88BVDpdWKsgx10PWkDoxeuxTTyemNWK6FiMEzR6v9geG lKG6ZUi2nIAlNkCiWX+GUE+OfxuxsDxDO6FLTW/EZg== X-Google-Smtp-Source: ABdhPJx+Js3ydQFBUP7ACgCzkoV+mCC9MxMLL2meKWUMIA/Fue2cHeE5SzEFTuMIFXv2hDabWqdWiVicuLD7Dfqz5J4= X-Received: by 2002:a05:6830:1082:: with SMTP id y2mr4127841oto.221.1602890146021; Fri, 16 Oct 2020 16:15:46 -0700 (PDT) MIME-Version: 1.0 References: <20201003040257.62768-1-john.stultz@linaro.org> <20201003040257.62768-8-john.stultz@linaro.org> <20201008115101.4qi6wh3hhkb6krg5@DESKTOP-E1NTVVP.localdomain> In-Reply-To: From: John Stultz Date: Fri, 16 Oct 2020 16:15:32 -0700 Message-ID: Subject: Re: [PATCH v3 7/7] dma-buf: system_heap: Add a system-uncached heap re-using the system heap To: Brian Starkey X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: nd , Sandeep Patil , dri-devel , Ezequiel Garcia , Robin Murphy , James Jones , lkml , Liam Mark , Laura Abbott , Chris Goldsworthy , Hridya Valsaraju , =?UTF-8?Q?=C3=98rjan_Eide?= , linux-media , Suren Baghdasaryan , Daniel Mentz Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Fri, Oct 16, 2020 at 12:03 PM John Stultz wrote: > On Thu, Oct 8, 2020 at 4:51 AM Brian Starkey wrote: > > On Sat, Oct 03, 2020 at 04:02:57AM +0000, John Stultz wrote: > > > @@ -426,6 +487,16 @@ static int system_heap_create(void) > > > if (IS_ERR(sys_heap)) > > > return PTR_ERR(sys_heap); > > > > > > + exp_info.name = "system-uncached"; > > > + exp_info.ops = &system_uncached_heap_ops; > > > + exp_info.priv = NULL; > > > + > > > + sys_uncached_heap = dma_heap_add(&exp_info); > > > + if (IS_ERR(sys_uncached_heap)) > > > + return PTR_ERR(sys_heap); > > > + > > > > In principle, there's a race here between the heap getting registered > > to sysfs and the dma_mask getting updated. > > > > I don't think it would cause a problem in practice, but with the API > > as it is, there's no way to avoid it - so I wonder if the > > dma_heap_get_dev() accessor isn't the right API design. > > Hrm. I guess to address your concern we would need split > dma_heap_add() into something like: > dma_heap_create() > dma_heap_add() > > Which breaks the creation of the heap with the registering it to the > subsystem, so some attributes can be tweaked inbetween? Looking at this some more, this approach isn't going to work. We create the device and then we call dma_coerce_mask_and_coherent() on it, but as soon as the device is created it seems possible for userland to directly access it. Again, though, as you mentioned this isn't terribly likely in practice. The best thing I can think of for now is to have the uncached heap's allocate pointer initially point to a dummy function that returns EBUSY and then after we update the dma mask then we can set it to the real alloc. I'll go with that for now, but let me know if you have other suggestions. thanks -john _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel