Received: by 2002:ac0:a874:0:0:0:0:0 with SMTP id c49csp258656ima; Fri, 15 Mar 2019 02:07:48 -0700 (PDT) X-Google-Smtp-Source: APXvYqyiDExtoMs/4EH4mgBwd52WpwzIgeRt3hCtzfTCAbg3ZCfFwj6NeMLnS1C/OnlbrvCm53K+ X-Received: by 2002:a65:6203:: with SMTP id d3mr2379284pgv.109.1552640868187; Fri, 15 Mar 2019 02:07:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552640868; cv=none; d=google.com; s=arc-20160816; b=r5nAdKTuss8plFTjQQ97b/F4PakkQKo48Cj/XXRACmen+BYccZkuVa/YN2B0RW79/b c6CFCO2mVFyx2orc8yggEWf1+Mi6IPxQv2wIyE2/V7ZYGWpeLYnmzbgFcSSjMMmtbgRH t6gU+5XRcC93alDFyVsrH6cnaJwl5ZzJCtSbG3sQO4k+FB1BRPsxDePYC5MzE+qdcpXE s2dvZ8rtLEYEk5tj/OO+WvXpXFHgfQrcNsXjZp9xLjKxFd0JGf2mnjxvFyYlpM5CuqLL XBlyMWZEKYvXiXOlCibMwwo4rfjaemmY5ZwR1fdalCg1lP10R8WxLTVqx1+6ZZFE8clj fMpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=j78cqxO0j5kBy+Sel1YCiPWdQ5D6/QSjaVylMNTrh48=; b=XZMMqeQFE41Fm9YG/cxThLiyiO0fFKkmK07NjR79MMIIhX4CNRwgcE7LYBkS2kvjnr TTGsBwE/KYXFwMuhY7sLEEFBflgxV8rjn4UbqtwJAf8E3UdDc+C+s+XJM1gpW7MB48xa C5BAGiMy+EqE1Za24OnGhcsMvkCgoaFuCCa9DVN+mz7tQm892j1dYqrINnyEKQ3mauq1 xg5RUOxVc7HeJonLVpwamKVpWffa2MQ43mlN4ZCJYRg4hOvefX3zcOcBTNysPVMC0fUt DEwMp++LYsf9ailEY36fqxSJJmT9gJWrFtolaAmINZnVPo2dlPRbcXgM3blTdgakhtAL cZcQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=sGDmDKwR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n34si1390347pld.163.2019.03.15.02.07.33; Fri, 15 Mar 2019 02:07:48 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=sGDmDKwR; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728660AbfCOJGu (ORCPT + 99 others); Fri, 15 Mar 2019 05:06:50 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:34598 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728640AbfCOJGr (ORCPT ); Fri, 15 Mar 2019 05:06:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=j78cqxO0j5kBy+Sel1YCiPWdQ5D6/QSjaVylMNTrh48=; b=sGDmDKwR4njjrRMCEpeaF6hBe KIiB3DdMToavB3IYYtrotZF1iT734TjiYMuj5/TYQqat6ZVLbJg0bRLTKTxuurcSSvQa5pePbArgV 3nHIGQyoADXzwnDRw83UUymxMQVg5/FkBKal4lDH8Ka2cCNMw/kItqAt3d5j9NyaslNKGLEi8qoE6 sdbjBGnCRJykv552LBoGqHWxCFvCGtg0eGIeGottgNxHsxtT6sQp3kajZuWPo5nxF3pFpeMWTynFY bwldQC66NWZ2U4WXEKWQYUqbqeRk1eqsVn1VMku/pS6vscHtaEd68SSUgyUPdSzHmv+w1h+1dwhMW fGBaglPrg==; Received: from hch by bombadil.infradead.org with local (Exim 4.90_1 #2 (Red Hat Linux)) id 1h4ine-0008AA-SJ; Fri, 15 Mar 2019 09:06:46 +0000 Date: Fri, 15 Mar 2019 02:06:46 -0700 From: Christoph Hellwig To: John Stultz Cc: lkml , Laura Abbott , Benjamin Gaignard , Greg KH , Sumit Semwal , Liam Mark , Brian Starkey , "Andrew F . Davis" , Chenbo Feng , Alistair Strachan , dri-devel@lists.freedesktop.org Subject: Re: [RFC][PATCH 2/5 v2] dma-buf: heaps: Add heap helpers Message-ID: <20190315090646.GC4470@infradead.org> References: <1551819273-640-1-git-send-email-john.stultz@linaro.org> <1551819273-640-3-git-send-email-john.stultz@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1551819273-640-3-git-send-email-john.stultz@linaro.org> User-Agent: Mutt/1.9.2 (2017-12-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > +static void *dma_heap_map_kernel(struct heap_helper_buffer *buffer) > +{ > + struct scatterlist *sg; > + int i, j; > + void *vaddr; > + pgprot_t pgprot; > + struct sg_table *table = buffer->sg_table; > + int npages = PAGE_ALIGN(buffer->heap_buffer.size) / PAGE_SIZE; > + struct page **pages = vmalloc(array_size(npages, > + sizeof(struct page *))); > + struct page **tmp = pages; > + > + if (!pages) > + return ERR_PTR(-ENOMEM); > + > + pgprot = PAGE_KERNEL; > + > + for_each_sg(table->sgl, sg, table->nents, i) { > + int npages_this_entry = PAGE_ALIGN(sg->length) / PAGE_SIZE; > + struct page *page = sg_page(sg); > + > + WARN_ON(i >= npages); > + for (j = 0; j < npages_this_entry; j++) > + *(tmp++) = page++; This should probably use nth_page. That being said I really wish we could have a more iterative version of vmap, where the caller does a get_vm_area_caller and then adds each chunk using another call, including the possibility of mapping larger than PAGE_SIZE contigous ones. Any chance you could look into that? > + ret = remap_pfn_range(vma, addr, page_to_pfn(page), len, > + vma->vm_page_prot); So the same chunk could be mapped to userspace and vmap, and later on also DMA mapped. Who is going to take care of cache aliasing as I see nothing of that in this series? > + if (buffer->kmap_cnt) { > + buffer->kmap_cnt++; > + return buffer->vaddr; > + } > + vaddr = dma_heap_map_kernel(buffer); > + if (WARN_ONCE(!vaddr, > + "heap->ops->map_kernel should return ERR_PTR on error")) > + return ERR_PTR(-EINVAL); > + if (IS_ERR(vaddr)) > + return vaddr; > + buffer->vaddr = vaddr; > + buffer->kmap_cnt++; The cnt manioulation is odd. The normal way to make this readable is to use a postfix op on the check, as that makes it clear to everyone, e.g.: if (buffer->kmap_cnt++) return buffer->vaddr; .. > + buffer->kmap_cnt--; > + if (!buffer->kmap_cnt) { > + vunmap(buffer->vaddr); > + buffer->vaddr = NULL; > + } Same here, just with an infix. > +static inline void INIT_HEAP_HELPER_BUFFER(struct heap_helper_buffer *buffer, > + void (*free)(struct heap_helper_buffer *)) > +{ > + buffer->private_flags = 0; > + buffer->priv_virt = NULL; > + mutex_init(&buffer->lock); > + buffer->kmap_cnt = 0; > + buffer->vaddr = NULL; > + buffer->sg_table = NULL; > + INIT_LIST_HEAD(&buffer->attachments); > + buffer->free = free; > +} There is absolutely no reason to inlines this as far as I can tell. Also it would seem much simpler to simply let the caller assign the free callback.