Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp1735461pxu; Fri, 16 Oct 2020 22:37:04 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwh4OpgePCrX7eE+2LsH9kuBXnIV0N5wXofAbu6OUhDiflWiIvoymAWbRJ0q+x/TeMGSV4g X-Received: by 2002:a50:f613:: with SMTP id c19mr7855481edn.81.1602913023761; Fri, 16 Oct 2020 22:37:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602913023; cv=none; d=google.com; s=arc-20160816; b=jcxSnsBlivyX1ALzqGHGlwxBp0zktQtTjglkHatmtLJWF/QAE2tdxwDblZ/SIt3ByF /B3ROq3uGjhtecxdUPtMBHKdF/gkfzzVxB7O0k87fj7Wkw9f9ZifWrcnscR+Opdu20tp ve9u7/5l+psqX/I9aSgydleQF3lZowYb/KJQnN/jf+HaikA9lYjcnP0xzxvYwtHkcfhm hcDjICE4RjH/FoCa04rh4vE1MxUk3qGfz+5TvBYzOyuP3GNfXlDo1m9P4gB5gSJh4dXK lprgwe2JDX8SadEUP82Zi/d2qUxTIed0fDZs6XjUQvKSxdX5hg+Kg5xaMgbywQ8vIVhA ABDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=z/utRDTKVHmHoEv/2/0Wo96JPENEebgv5nLtf2BjNsM=; b=vSEna0Ic/Mt3tDit80oXIh8VyOTvNcMV8pSYO3XXC6WDoECt6DGcwwZaJxO/x4slxa 1MouO17d94osmFgo3zAINV3bQ3euNuOZmfT5Kz4ygk2a+q/OD+++80/QG30QRzhiZAfB 9ECNkjJZCgBSd4Vy0sd85JIHkyBsIZwyP595vxEiatDJCtleS+EoolZFfGaFaHM55DiB VNnvyMO+92m3u/RJEpu8KATVBTbPXBporgclXnRaIcETM/a0zmb39TKsb1HaKBcIB1jl jt7qEzTfX5C7RiBvl9x+E4r0o8OttEzlsnquFsnO7ZfxrB7JKqR5J2cqcSlcIFKHcPAV Qy3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Oi+V1WJt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id bi9si4504247edb.4.2020.10.16.22.36.41; Fri, 16 Oct 2020 22:37:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=Oi+V1WJt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2410878AbgJPXPr (ORCPT + 99 others); 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-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