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 AB7C1C04E69 for ; Thu, 10 Aug 2023 00:57:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0E7CA6B0071; Wed, 9 Aug 2023 20:57:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 097FC8E0001; Wed, 9 Aug 2023 20:57:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EA1BA6B0075; Wed, 9 Aug 2023 20:57:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id DD0B36B0071 for ; Wed, 9 Aug 2023 20:57:35 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 9EDBA1208BA for ; Thu, 10 Aug 2023 00:57:35 +0000 (UTC) X-FDA: 81106382070.05.383310A Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by imf04.hostedemail.com (Postfix) with ESMTP id C5EBD40014 for ; Thu, 10 Aug 2023 00:57:33 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=DcyoSSCw; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of jstultz@google.com designates 209.85.208.49 as permitted sender) smtp.mailfrom=jstultz@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1691629053; 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=pENb1t85EdhZr2S/NRQldNOIuogVZkW2tw0vSMoDYS4=; b=6hekD5+W4c5PHdOdducztq6f6PPHtcoikhnAECWFJcH1ueKH4kTvo17cX5Aa1LjSm3Zx33 Xlic46NRaNx7PtvpDOpnLpynluHogdLopZbBl5zhSnW3BAwWrwWicAAA2J2FTbIAVnHIAd XA3oc3Llyl6wp8NuafiRtEizYB4I6Hw= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=DcyoSSCw; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf04.hostedemail.com: domain of jstultz@google.com designates 209.85.208.49 as permitted sender) smtp.mailfrom=jstultz@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1691629053; a=rsa-sha256; cv=none; b=MGvJg+2LZM/+GeJbuxGPOq1tkac2H0YDoWJc2WIBflrbsyqVmjq8IW5ubt9oZmjeos+lER xmxG22wEUhAHunljq0MoTklNxYRKx84fh6rl0Iw+VU2kdGg/11RloGvzLnwGI3P+kI7c/b HB8b56UepJ3TA0mKDBxxeUcVXj+z7eM= Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-5232ce75e26so2865a12.1 for ; Wed, 09 Aug 2023 17:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691629052; x=1692233852; 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=pENb1t85EdhZr2S/NRQldNOIuogVZkW2tw0vSMoDYS4=; b=DcyoSSCwJwp9vWokfe6dcIcLr97RyCLwBKjCbSskay0ACsx3/Izc9hLNsxwGuAVej/ wB2ynNNpnWSk9rjEmycLvjbxhdjuGCr4gLKPNdtYax8aYtgx0roYCOdnsQxs2XvY8Kyz zm4+OHdnDZS1cSMHKnWNLEjHVbE+tLFR1H4cuVpsMI7fqGM3Rm7czFUMk2/pAODSkQ8h qpa6v2aLXK8WqWZ0zBc0vDg3ZDBlNkD+nEgNFbauOexdn14Eul3ITgPmwpU+k0aY3DlC U695WvJ65wCg4BdHjT1N2bzpnjEz1BPQGdzsN8A21gHFmb8YSwAg7Z0RT6ewZLnRVqRo JX5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691629052; x=1692233852; 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=pENb1t85EdhZr2S/NRQldNOIuogVZkW2tw0vSMoDYS4=; b=eZvkR2Yo2X+cGDQ4CJ9MB1qt7uLkXyhGQ1oQJN/K9pJIyusoywwt5JYmrt9dagdbb2 HaKx9P8ImVB53WFIOgDc6wJ2kMRSvOnGUdzEWF2+5tmY/N8mDWFLaF2rkMZA/aJ/EWaO COWZDRG90Pl/TVt8jLrShCtGO7rrciai+uF/tZaNL8Eoksot77absteipv0EZnrzd1Ws iIk6ujMsM09xDBIrOJDCbuh7HbGeUIOM8cUpOMoEpBu6WRzAMpm8b6Xv2ZITrkoQazMf ZKcgMn8yxcSjvRk8hpoDU/qT0KWzmMOtDQQ5J5IxrFNQ+nKituspqVWHfsxrhp0iGli0 Tb7A== X-Gm-Message-State: AOJu0YzIZWCg6k1elp5Z/9RTucNAnRUFxtM0qaGiCgb7LGAqjVzRhbzi XDQOhAgfnn7ig7vW9bnNDlHtGjLT2NaCDOjDAq8a X-Google-Smtp-Source: AGHT+IGC3Ojhu3H3wyaJnO0AFrfMJr5XHWFXJ1jg2Nd0krAXKutumnTRxviNOopna7nevL3OGuuOsnupTL3vhP1snHY= X-Received: by 2002:a50:99db:0:b0:522:28a1:2095 with SMTP id n27-20020a5099db000000b0052228a12095mr191965edb.3.1691629052118; Wed, 09 Aug 2023 17:57:32 -0700 (PDT) MIME-Version: 1.0 References: <1690598115-26287-1-git-send-email-quic_pintu@quicinc.com> <20230731112155.GA3662@lst.de> <20230801171838.GA14599@lst.de> <20230802094725.GA28241@lst.de> In-Reply-To: From: John Stultz Date: Wed, 9 Aug 2023 17:57:19 -0700 Message-ID: Subject: Re: [PATCH v2] dma-contiguous: define proper name for global cma region To: Pintu Agarwal Cc: Christoph Hellwig , Pintu Kumar , linux-kernel@vger.kernel.org, akpm@linux-foundation.org, linux-mm@kvack.org, m.szyprowski@samsung.com, robin.murphy@arm.com, iommu@lists.linux.dev, Sumit Semwal , Benjamin Gaignard , Liam Mark , Laura Abbott , Brian Starkey , =?UTF-8?Q?Christian_K=C3=B6nig?= , linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org, linaro-mm-sig@lists.linaro.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: C5EBD40014 X-Stat-Signature: x44p3d1u5z8d7opa14m3et8azwc3rj1d X-Rspam-User: X-HE-Tag: 1691629053-65005 X-HE-Meta: U2FsdGVkX1+cwkKC6VuCv8CAKBk/g99Z3jjKEralx+gXFHCQU3jjgKRG02v9Sa7Yb6Mm+SWTxJymp3b5OIcoZlLv40acXD0cMPj5DN6BHV7hI3AMsBJIIDLM0PyKFavIEtYz5kHUDDnrZ4F45vf/K/8RWwwkXMoA2zujpTE/uY0kZcjvpmv8A0k3WA3OPHYQuyRnpJ4UwfmK2hVoDc0SbCp2zsmuALSSl0JKiyimmNavxF5r0HdFSMgZyfDbSmRgGKysVrbi3wV1cYuk19jSVItBZPuJBCwn0bXd+DQWWcRXjoktptY9UegauHwWzTJFNpO/vrnuDBWJeBU3ig1HHRH04pPljyFxnnxQiqbHd2Z8LKTqNbT6pSRSYnPhCtZ4/JMDtifasRh0f8GiR2uHmPiDxPfRiqg5qLNrW9qyBZ6Mrd3R/9Fl3D+iuH29puCDCOtFRjwYkELKTDXcOMvQbXwPLrKng949klAsMQ54RN0KLOCzNXwdC3y2X4YPTnAFk+IiZfhwsyv0sVgilnZW5Yces2vdq10GbDoySv+ao7dUOtPmAxCkKL6KaPmuExV0C3jwTRutQTxx7qDsjdO+T91+s/NNYu2YpH1OUScsj3gTqLlzw3mSNLOBuemcG/c66lCi1xoa78eb0QIe8RPBFcXnKM+PzdcxWfUdqRfwMtdjWy766EGMFVFH6oot6Y2NvVO16gtOMT/FNRJrhehlZbNSiuGqE9EAd/nREt76FI2pfo1lO1nG6IJI2k2VyIKDbpjjAIyKWt/AkZmdBJSP+/TbMD01tA3TH5RWrOMtab+zO9AggFjGNSkz6j+rowapKIccL7W6u3s7qYTtyOxCn8Ny2Uj16M6tvQrKJsqUQKxRL5sXZlp4YxwQQxbIpTlQtwk0Y3MSWkCjpjjg+WbuWlKSer2z5r2G0rnWUzPILIk10riUuhZDJPc/ShJD0SBgP8/QNfPEE6kKkOZR5SF hwjiIWEf 3BInHlMmvl45C+xi86CSYU+xvU0fo+4g2UJCV01DZJwxO3dcBnSP1Jz5eOEA8lx6L92InATWTqW0HvSXdhR7n655r3JwS650t88GcB20Ov0shllJYlPNiMwUI99W1hDpfpwT9s0OynETqMzSXcumkomJbBuTo57PpwZrO7FmXA95W7YJQSGojhxoRkoSDrXDLROhwBSFHsXYEZO0gXUAMmQNcpMGEwyBa1+4SLWrX3S9YSYKvZD9R3VEvNXBHCGYZ0zWxnQzpa1OhjCqa2TcAtblWeogEosPSpvhrgtppRb6Dd975vRuPPu+CQ3EYuwgeCnDN 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 Wed, Aug 9, 2023 at 8:04=E2=80=AFAM Pintu Agarwal = wrote: > > Hi, > > On Thu, 3 Aug 2023 at 23:04, Pintu Agarwal wrote: > > > > Hi, > > > > On Wed, 2 Aug 2023 at 15:17, Christoph Hellwig wrote: > > > > > > On Tue, Aug 01, 2023 at 10:39:04PM -0700, John Stultz wrote: > > > > So, forgive me, I've not had a chance to look into this, but my > > > > recollection was "reserved" is the name we see on x86, but other na= mes > > > > are possibly provided via the dts node? > > > > > No, I think "reserved" is the name hard-coded (for all arch) in Kernel > > for global-cma. > > So, I don't think this is x86 specific. I am checking on arm32 itself. > > When we can dma_alloc_coherent we see these in the logs (if dts region > > is not present). > > cma: cma_alloc(cma (ptrval), name: reserved, count 64, align 6) > > Now, with this change we will see this: > > cma: cma_alloc(cma (ptrval), name: global-cma-region, count 64, align 6= ) > > > > > Indeed, dma_contiguous_default_area can also be set through > > > rmem_cma_setup, which then takes the name from DT. > > > > > I think this is a different case. If DT entry is present we get this: > > Reserved memory: created CMA memory pool at 0x98000000, name: name: > > linux,cma, size 128 MiB > > cma: cma_alloc(cma (ptrval), name: linux,cma, count 64, align 6) > > > > Here we are talking about the default hard-coded name in Kernel code > > if DT is not defined. > > So, in one of the boards, this DT entry was not present and it shows > > as "reserved". > > > > > > I believe on the hikey board its "linux,cma" is the name, so forcin= g > > > > it to reserved would break that. > > > > > > Yes, everywhere in the DT it's defined as "linux,cma". > > You mean this also should be changed to "linux,cma-global-region" > > everywhere with this change ? > > > > > > Maybe instead add a compat config option to force the cma name (so = x86 > > > > can set it to "default" if needed)? > > > > > Yes, having it in config is also a good option instead of hard-coding i= n Kernel. > > > > > > I think we'll just need to leave it as-is. I with dma-heaps had neve= r > > > exposed the name to userspace, but we'll have to l=D1=96ve with it no= w. > > > > Can you point me to the userspace utility we are talking about here ? > > I think we should not worry much about userspace name exposure. > > I guess it should fetch whatever is declared in Kernel or DTS, right ? > > Just to follow-up on this. > For now, can we change the Kernel hard-coded value from "reserved" to > "global-cma-region" ? > Later, for the DTS defined name let it be "linux,cma" or change that > also to "linux,global-cma-region" ? > > Will this make sense ? Apologies, sorry for not responding to your earlier message, it slipped by. So, the concern is there may be allocators (like gralloc in Android) that allocate from the CMA region via the dma-buf heaps interface. So by changing the name (either hardcoded or DTS names), you'll change the user-visible heap name, potentially breaking those userland allocators. Now, the dmabuf heaps are designed to be like other dynamic devices (like disks or partitions), which may be different from device to device. However, changing the name would still be an inconvenience for folks who have hard-coded that name in their userland allocator which was designed for a single device. This would be similar to the old issue of an existing fstab breaking from the ide (hda) to sata (sda) driver transition. Or similar to what folks went through a while back with network device names changing from eth0 -> ens0 or whatever. That said, most android devices historically haven't upreved to new kernel versions wihtout major userspace changes, so the impact might be minimal, but that is likely to change in the future so we should be careful here. What I'd propose instead is to either leave it alone as Christoph suggested, or have a build option/boot argument so folks can preserve the legacy name if they need. thanks -john