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=-4.0 required=3.0 tests=BAYES_00, 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 ADF6FC433DF for ; Thu, 30 Jul 2020 17:02:51 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (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 89B7020829 for ; Thu, 30 Jul 2020 17:02:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 89B7020829 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 41FAF884F0; Thu, 30 Jul 2020 17:02:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2pQrgKRKK3EH; Thu, 30 Jul 2020 17:02:47 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by hemlock.osuosl.org (Postfix) with ESMTP id DB0D7884D3; Thu, 30 Jul 2020 17:02:47 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by ash.osuosl.org (Postfix) with ESMTP id 9FC981BF294 for ; Thu, 30 Jul 2020 17:02:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 9BA1386DC4 for ; Thu, 30 Jul 2020 17:02:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPc5-spgbcto for ; Thu, 30 Jul 2020 17:02:46 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by fraxinus.osuosl.org (Postfix) with ESMTPS id A816F86DC2 for ; Thu, 30 Jul 2020 17:02:45 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 0DDD9B02E; Thu, 30 Jul 2020 17:02:56 +0000 (UTC) Message-ID: <1f3c4641a3058159a2923c1f5833a10b413747bf.camel@suse.de> Subject: Re: [PATCH v9 08/12] device core: Introduce DMA range map, supplanting dma_pfn_offset From: Nicolas Saenz Julienne To: Jim Quinlan , Rob Herring Date: Thu, 30 Jul 2020 19:02:37 +0200 In-Reply-To: References: <20200724203407.16972-1-james.quinlan@broadcom.com> <20200724203407.16972-9-james.quinlan@broadcom.com> <20200729061903.GA31671@lst.de> User-Agent: Evolution 3.36.3-0ubuntu1 MIME-Version: 1.0 X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Rich Felker , "open list:SUPERH" , David Airlie , PCI , Hanjun Guo , "open list:REMOTE PROCESSOR \(REMOTEPROC\) SUBSYSTEM" , Andy Shevchenko , Bjorn Andersson , Julien Grall , Heikki Krogerus , "H. Peter Anvin" , Will Deacon , Christoph Hellwig , Marek Szyprowski , "open list:STAGING SUBSYSTEM" , Jean-Philippe Brucker , Lorenzo Pieralisi , Yoshinori Sato , Frank Rowand , Joerg Roedel , "maintainer:X86 ARCHITECTURE \(32-BIT AND 64-BIT\)" , Russell King , "open list:ACPI FOR ARM64 \(ACPI/arm64\)" , Chen-Yu Tsai , Ingo Molnar , "maintainer:BROADCOM BCM7XXX ARM ARCHITECTURE" , Alan Stern , Len Brown , Ohad Ben-Cohen , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE" , Philipp Zabel , Arnd Bergmann , Suzuki K Poulose , Maxime Ripard , Florian Fainelli , Borislav Petkov , "open list:DRM DRIVERS FOR ALLWINNER A10" , Yong Deng , Santosh Shilimkar , Bjorn Helgaas , Thomas Gleixner , Mauro Carvalho Chehab , "moderated list:ARM PORT" , Saravana Kannan , Greg Kroah-Hartman , Oliver Neukum , "Rafael J. Wysocki" , open list , Paul Kocialkowski , "open list:IOMMU DRIVERS" , "open list:USB SUBSYSTEM" , Stefano Stabellini , Daniel Vetter , Sudeep Holla , "open list:ALLWINNER A10 CSI DRIVER" , Robin Murphy , "moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" On Thu, 2020-07-30 at 12:44 -0400, Jim Quinlan wrote: > On Wed, Jul 29, 2020 at 10:28 AM Rob Herring wrote: > > On Wed, Jul 29, 2020 at 12:19 AM Christoph Hellwig wrote: > > > On Tue, Jul 28, 2020 at 02:24:51PM -0400, Jim Quinlan wrote: > > > > I started using devm_kcalloc() but at least two reviewers convinced me > > > > to just use kcalloc(). In addition, when I was using devm_kcalloc() > > > > it was awkward because 'dev' is not available to this function. > > > > > > > > It comes down to whether unbind/binding the device N times is actually > > > > a reasonable usage. As for my experience I've seen two cases: (1) my > > > > overnight "bind/unbind the PCIe RC driver" script, and we have a > > > > customer who does an unbind/bind as a hail mary to bring back life to > > > > their dead EP device. If the latter case happens repeatedly, there > > > > are bigger problems. > > > > > > We can't just leak the allocations. Do you have a pointer to the > > > arguments against managed resources? I'm generally not a huge fan > > > of the managed resources, but for a case like this they actually seem > > > useful. If we don't use the managed resources we'll at leat need > > > to explicitly free the resources when freeing the device. > > > > The lifetime for devm_kcalloc may not be what we want here. devm > > allocs are freed on probe fail or remove, not on freeing the device > > (there is a just in case free there too though). > > What do you suggest doing as an alternative? I haven't given the idea much thought, but how about using a kref in the first element of your bus_dma_region array. It should be increased upon assigning it to a device and decreased it upon destroying it (triggering the free once it hits 0). It would take care of this memory leak, but also useful where you're sharing bus_dma_regions between devices. Regards, Nicolas _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel