Received: by 2002:a05:7412:3784:b0:e2:908c:2ebd with SMTP id jk4csp442541rdb; Sat, 30 Sep 2023 10:20:49 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFzy2NTZ647x0ZMhiR28wlP33iO6kVKFT9s4GUWuG6Fn8BpurIbRyK+kNaKE4lJyAZLdB+s X-Received: by 2002:a05:6a21:7784:b0:15d:facd:f214 with SMTP id bd4-20020a056a21778400b0015dfacdf214mr6559894pzc.32.1696094449591; Sat, 30 Sep 2023 10:20:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696094449; cv=none; d=google.com; s=arc-20160816; b=ETKYzbWSYZRnVbaQ4BE+ZEUpYeldWA9uBzfeO5czrGHoruECvqwnF97l2h8sEOChvp HPw3/MEJuMVOF7xJ9g7v0ry2msDYOIyAyS19r11YVI83E8rT7Q5bqRGY/r57VAGexFDi MESjXEDj+vUlom11dGpE9rtPBArEc/C+mrSSGLvmyJqlHZCbU2DDeeaWU3z2HpDRT+GI RvfZwN8DmD3ZxzD36J1IMMCPp09a6h0N7s+J6mZtqvlRF1B3XxvQ+P+QnX8EH+HiJgMA +7GcaonCImbo2GHycpukIwzMFgQ+wDmIw0kIJvSd8d9pMGebQcbGnREJ5P4D/q96qLu8 FhmA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=KaFNHvLGhSWw6k1YbrcP5aE6dRz+VfR2fjgF08Fj7OM=; fh=dt7ydZBcGBQSwZFUrZTWm6xxuG+wlpCJZdh9F5w8YVw=; b=su1FzwRHVzZ9zkTGxapzdlxc8GZZd0BdX1GBxaPSwOJgtIskn7b8cbZ8+h7Y4t35Ac GVb9tQX5A0pOWmE6KIEU1nkXk8HASHbi9AOrNfkVmFJCejhNj04HOlBz/V2mGwme75NC 3YRHK7I2vnudOCYUaNkJMpyVEjFzb2KWjGugeNlI2+Yk+Cr34ruSVENq79jSavmRSUCW +69IPjBtxHUaHSvgGD23Dm9usZ2pxlcSMJXGbTmvsDGxW77oi/PsIBxrJ9JQY6fS4N+2 0Jse5oZ2mIQe/mimLZTs5aWnxaUN/UOkDYwpn1oI2R0L/rMo57zf977tDNeIfQpU3dPg DDog== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UO+RYsCe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from pete.vger.email (pete.vger.email. [2620:137:e000::3:6]) by mx.google.com with ESMTPS id b16-20020a170902d51000b001c42b2b02casi15298843plg.174.2023.09.30.10.20.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 Sep 2023 10:20:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) client-ip=2620:137:e000::3:6; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=UO+RYsCe; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:6 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by pete.vger.email (Postfix) with ESMTP id 2309E807D411; Sat, 30 Sep 2023 00:10:26 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at pete.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234054AbjI3HKQ (ORCPT + 99 others); Sat, 30 Sep 2023 03:10:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229540AbjI3HKP (ORCPT ); Sat, 30 Sep 2023 03:10:15 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8BEE1C5 for ; Sat, 30 Sep 2023 00:10:13 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A7BB4C433C8; Sat, 30 Sep 2023 07:10:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1696057813; bh=uvGD1csA5JWxarCHp9AYsOjN6Mf9w1sy7vN59u16vz0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UO+RYsCedPI73JzxykVPefAXh/+ASlxwiOA9qJ27HKndAAIOP1hfuMNm7lXMXrSNO X0+VdhabYsih7Wq6zJOmoRsag9sO+DkhnAP5Oz9S2Ricf6PBQBWN32oRUCVGWAgzGi didA5lSJoGzH8SKrt/U2Xmgrd/2+VPxi9GkcPFvA= Date: Sat, 30 Sep 2023 09:10:10 +0200 From: Greg Kroah-Hartman To: Chris Leech Cc: Christoph Hellwig , Rasesh Mody , Ariel Elior , Sudarsana Kalluru , Manish Chopra , Nilesh Javali , Manish Rangankar , Jerry Snitselaar , John Meneghini , Lee Duncan , Mike Christie , Hannes Reinecke , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] uio: introduce UIO_DMA_COHERENT type Message-ID: <2023093037-onion-backroom-b4ef@gregkh> References: <20230929170023.1020032-1-cleech@redhat.com> <20230929170023.1020032-2-cleech@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230929170023.1020032-2-cleech@redhat.com> X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pete.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (pete.vger.email [0.0.0.0]); Sat, 30 Sep 2023 00:10:26 -0700 (PDT) On Fri, Sep 29, 2023 at 10:00:21AM -0700, Chris Leech wrote: > Add a UIO memtype specificially for sharing dma_alloc_coherent > memory with userspace, backed by dma_mmap_coherent. Are you sure that you can share this type of memory with userspace safely? And you are saying what you are doing here, but not why you want to do it and who will use it. What are the userspace implications for accessing this type of memory? > > Signed-off-by: Chris Leech > --- > drivers/uio/uio.c | 34 ++++++++++++++++++++++++++++++++++ > include/linux/uio_driver.h | 12 ++++++++++-- > 2 files changed, 44 insertions(+), 2 deletions(-) > > diff --git a/drivers/uio/uio.c b/drivers/uio/uio.c > index 62082d64ece0..f8f1f7ba6378 100644 > --- a/drivers/uio/uio.c > +++ b/drivers/uio/uio.c > @@ -24,6 +24,7 @@ > #include > #include > #include > +#include > > #define UIO_MAX_DEVICES (1U << MINORBITS) > > @@ -759,6 +760,36 @@ static int uio_mmap_physical(struct vm_area_struct *vma) > vma->vm_page_prot); > } > > +static int uio_mmap_dma_coherent(struct vm_area_struct *vma) > +{ > + struct uio_device *idev = vma->vm_private_data; > + int mi = uio_find_mem_index(vma); > + struct uio_mem *mem; > + int rc; > + > + if (mi < 0) > + return -EINVAL; > + mem = idev->info->mem + mi; > + > + if (mem->dma_addr & ~PAGE_MASK) > + return -ENODEV; > + if (vma->vm_end - vma->vm_start > mem->size) > + return -EINVAL; > + > + /* > + * UIO uses offset to index into the maps for a device. > + * We need to clear vm_pgoff for dma_mmap_coherent. > + */ > + vma->vm_pgoff = 0; > + rc = dma_mmap_coherent(mem->dma_device, > + vma, > + mem->virtual_addr, > + mem->dma_addr, > + vma->vm_end - vma->vm_start); > + vma->vm_pgoff = mi; > + return rc; > +} > + > static int uio_mmap(struct file *filep, struct vm_area_struct *vma) > { > struct uio_listener *listener = filep->private_data; > @@ -806,6 +837,9 @@ static int uio_mmap(struct file *filep, struct vm_area_struct *vma) > case UIO_MEM_VIRTUAL: > ret = uio_mmap_logical(vma); > break; > + case UIO_MEM_DMA_COHERENT: > + ret = uio_mmap_dma_coherent(vma); > + break; > default: > ret = -EINVAL; > } > diff --git a/include/linux/uio_driver.h b/include/linux/uio_driver.h > index 47c5962b876b..ede58e984658 100644 > --- a/include/linux/uio_driver.h > +++ b/include/linux/uio_driver.h > @@ -36,11 +36,18 @@ struct uio_map; > */ > struct uio_mem { > const char *name; > - phys_addr_t addr; > + union { > + phys_addr_t addr; > + dma_addr_t dma_addr; > + }; > unsigned long offs; > resource_size_t size; > int memtype; > - void __iomem *internal_addr; > + union { > + void __iomem *internal_addr; > + void *virtual_addr; > + }; > + struct device *dma_device; Why are you adding a new struct device here? And why the unions? How are you going to verify that they are being used correctly? What space savings are you attempting to do here and why? thanks, greg k-h