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 8DA8CC77B75 for ; Tue, 16 May 2023 11:43:07 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B3B5F900005; Tue, 16 May 2023 07:43:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AEB5E900002; Tue, 16 May 2023 07:43:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 98C0D900005; Tue, 16 May 2023 07:43:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8A6E4900002 for ; Tue, 16 May 2023 07:43:06 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4DFB8160208 for ; Tue, 16 May 2023 11:43:06 +0000 (UTC) X-FDA: 80795931972.11.B735E32 Received: from zg8tmtyylji0my4xnjqumte4.icoremail.net (zg8tmtyylji0my4xnjqumte4.icoremail.net [162.243.164.118]) by imf03.hostedemail.com (Postfix) with ESMTP id 94F6020012 for ; Tue, 16 May 2023 11:43:03 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=pku.edu.cn header.s=dkim header.b=PkcE7eCJ; spf=pass (imf03.hostedemail.com: domain of lrh2000@pku.edu.cn designates 162.243.164.118 as permitted sender) smtp.mailfrom=lrh2000@pku.edu.cn; dmarc=pass (policy=none) header.from=pku.edu.cn ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684237384; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=H9he+rg+FJu/lva+YkA+P4NB891uftZsubcF7D6o6y8=; b=2gKRsedGGgYfom06ussmX2oZ1phTk5mUj+abSlRkFzF0FsO3XmpOK1B1RZoRjStAcVhK87 zCE0FmCnP8Kf0RKCW1MWJNZOhNFSPbF4TbD5WGAwsDufU6PatYh6UvawF0dokUPNmG6mhs Ih7GR393YlFxrMX0iBuygPEfYgTg+1Y= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=pku.edu.cn header.s=dkim header.b=PkcE7eCJ; spf=pass (imf03.hostedemail.com: domain of lrh2000@pku.edu.cn designates 162.243.164.118 as permitted sender) smtp.mailfrom=lrh2000@pku.edu.cn; dmarc=pass (policy=none) header.from=pku.edu.cn ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684237384; a=rsa-sha256; cv=none; b=zKRxJAxgBoOZhmEpneBvLjLxw8Z4pRZo3mXz5RwXDgCV96Ln+x9HW9Er9eG+WGep5nUPog FWiLrDh6Fsruk4/qmskh4ybN0tm22XGCyno/5Pa8hw5f5mD8EpRz6Ux9FOWQGfOJq2Y9iC li7DeYNEP8UnO+ISef/2lXSZY6h30e4= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pku.edu.cn; s=dkim; h=Received:Date:From:To:Cc:Subject: Message-ID:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To; bh=H9he+rg+FJu/lva+YkA+P4NB891u ftZsubcF7D6o6y8=; b=PkcE7eCJcZ7WB4DdVMs1pe86EZ4dwiixFnqMY9R5THaR vzettkVHlC4UqhiNEwIN2aBFoD4KHmhtE26Q91BsWv1PvmUMVxUmZehwG0RnVWBJ +tYzM017P5RwWFsf/f+TEBI8JktBn8sr+atwffRwrgC+4hXnisUaveIn9EGrIp4= Received: from localhost (unknown [10.7.98.243]) by front01 (Coremail) with SMTP id 5oFpogD3_JQ8bGNk3+hsAw--.2746S2; Tue, 16 May 2023 19:42:56 +0800 (CST) Date: Tue, 16 May 2023 19:42:51 +0800 From: Ruihan Li To: David Laight Cc: "linux-mm@kvack.org" , "linux-usb@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Pasha Tatashin , David Hildenbrand , Matthew Wilcox , Andrew Morton , Christoph Hellwig , Alan Stern , Greg Kroah-Hartman , "stable@vger.kernel.org" , Ruihan Li Subject: Re: [PATCH v2 2/4] usb: usbfs: Use consistent mmap functions Message-ID: References: <20230515130958.32471-1-lrh2000@pku.edu.cn> <20230515130958.32471-3-lrh2000@pku.edu.cn> <2b6cb73d2cd14a46b7e4553566030b22@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2b6cb73d2cd14a46b7e4553566030b22@AcuMS.aculab.com> X-CM-TRANSID:5oFpogD3_JQ8bGNk3+hsAw--.2746S2 X-Coremail-Antispam: 1UD129KBjvJXoWxXF4UArW5Cw4UWrW5Jw43Jrb_yoW5Jw17pr W7G34Ikw4jq34rWrnruan3XFZ8Kwn5KFsxGr1YvwnxZ39xXrn7CrySkFy2kFy7tr1DGa1j qFWvvry8G3WDAaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBY1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AE w4v_Jr0_Jr4l8cAvFVAK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2 IY67AKxVWDJVCq3wA2z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVW8Jr0_Cr1UM28EF7xvwVC2 z280aVAFwI0_GcCE3s1l84ACjcxK6I8E87Iv6xkF7I0E14v26rxl6s0DM2vYz4IE04k24V AvwVAKI4IrM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xf McIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7 v_Jr0_Gr1lF7xvr2IY64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7M4IIrI8v6xkF7I0E 8cxan2IY04v7MxkIecxEwVCm-wCF04k20xvY0x0EwIxGrwCF04k20xvE74AGY7Cv6cx26w 4UJr1UMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_Jr0_Jr4lx2IqxVCj r7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUtVW8ZwCIc40Y0x0EwIxGrwCI42IY6x IIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVW8JVWxJwCI42IY6xAI w20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2z280aVCY1x 0267AKxVW8JVW8JrUvcSsGvfC2KfnxnUUI43ZEXa7VUbHa0DUUUUU== X-CM-SenderInfo: yssqiiarrvmko6sn3hxhgxhubq/1tbiAgEMBVPy7743xAAUsd X-Stat-Signature: iw44wsdpphmw1cqjctzttc6oq91s3i3h X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 94F6020012 X-Rspam-User: X-HE-Tag: 1684237383-601441 X-HE-Meta: U2FsdGVkX1/9ljzi5+Q9Dyl27wJhn2Jv9+lPHyHrKOTFQogKhKUUACWRdJV9/RUV6txVvItdJdpMGKczHcvPU8g75/VhynJt7TM6/Vur8Zs4eQVfMO6fn2bCpLU0xXuzc+uyOK7TodmjqRAv8+jx7eqX0kUHaMhR6Rju0yE9R3HC9NHJohIjeIVrHHebIUbtO1xerFO8VMWrMcg8f+ErAV0WgzyDpi6EJj0bR//Mwy0zi2w9iNrHlWrcpGBm9kK5E98iZr+vavRWqFRqkNCpu/XF0cfXJly8/phtGzoncFWTRYM1CsYaML0+PnuEDt4yQbp54OYQQUKFRSn5Vp4x+J8dCyakOwvFRkxX3UFhGNiprpcW16g+jZ4TM7bg2R9nMwPFBL6X1UvZjqYGRN9IShCPNV9X/WEWzOKge0/PLCsDsdEv8pj2/Uvrq8TTSuKFJUaRFDpM+N3+ODfF2JkwGXESCPdXNIDZ/gshDGtHvkBqkDcicl569/SdblrP2WA+Y0knpUGALwX2YFNStIRZa6KYJHMzdLZfRMNLmsk+8INQuUJFCzU35cl18AxKZy7HHZt/R9gm506JDW1SGjL97cSBGdIAQ4NPkZ2qooVd0J4uJgG2lgkZXyZfLAFCUc/+/QEQTAE8Utnm384jckFi6sJ6QWeKQQjM9qoaT5XRXnNYvdqEueOVdQwN1ZRcPbVVvXjDlkJJxc35bW79/b+MJB3Pyn/AdMPxDl7E4zWOmL+uZC78V++iNP2/4sPPZ7hzmpvmW7+iWeRC/OTMB2cUqjzVcY+ujjxG2fhInj6pb0o4v+VPrTbKm6t11e0JZoLEwx9LjKbLYqUiol16QddX9w2HfBY3HOqKHJzYrSB764CLzT3lffTNnX15EcQ6hgPUCIhKBAfQrSC4gW/fL2OgjGwt+UH5wcqPp+cKje64eVE0OHbGdknk/Tee/iZ80pgg7bxFGtPO/0F09mCpOoF cb9294SN AEwUtjWq4TxM0MZEpYoeexh+YwLefTDruuKc8A1Ktr6Z2Z/4hZzTpYm91y9hjouoIHmM2wsXmPt4ti6dmixeIpdy0GZBxmqwzvJo+OigeyCmE532XggcTWW1QcMZg7IXRk6zAMECdbZApGjt8LRnfLcry13tRTvs7YP/VBrJkEEUWISbDqlN1niML5RmYfDa84dt3iQm5HpgebzEt7mHxOATZ1q5Q3aDBBqHSHaftBEP0q3pcrYmETR5goraWNU2nx41lbrC5lMSbndrgq+gcg1qf9B/DAhxjkqPRZQ+Gnb5lZyw= 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 Mon, May 15, 2023 at 04:07:01PM +0000, David Laight wrote: > > From: Ruihan Li > > Sent: 15 May 2023 14:10 > > > > When hcd->localmem_pool is non-null, localmem_pool is used to allocate > > DMA memory. In this case, the dma address will be properly returned (in > > dma_handle), and dma_mmap_coherent should be used to map this memory > > into the user space. However, the current implementation uses > > pfn_remap_range, which is supposed to map normal pages. > > I've an (out of tree) driver that does the same. > Am I right in thinking that this does still work? Generally, it still works most of the time, but it can break sometimes. I am going to quote commit 2bef9aed6f0e ("usb: usbfs: correct kernel->user page attribute mismatch"), which introduces dma_mmap_coherent in usbdev_mmap, and says [1]: On some architectures (e.g. arm64) requests for IO coherent memory may use non-cachable attributes if the relevant device isn't cache coherent. If these pages are then remapped into userspace as cacheable, they may not be coherent with the non-cacheable mappings. [1] https://lore.kernel.org/all/20200504201348.1183246-1-jeremy.linton@arm.com/ I think it means that if your driver deals with devices that aren't cache-coherent on arm64, using pfn_remap_range directly may cause problems. Otherwise, you may need to check the arch-specific dma mmap operation and see if it performs additional things that pfn_remap_range does not (for the arm example, arm_iommu_mmap_attrs updates the vm_page_prot field to make the pages non-cacheable if the device is not cache-coherent [2]). [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm/mm/dma-mapping.c?id=f1fcbaa18b28dec10281551dfe6ed3a3ed80e3d6#n1129 > > I can't change the driver to use dma_map_coherent() because it > doesn't let me mmap from a page offset within a 16k allocation. > > In this case the memory area is an 8MB shared transfer area to an > FPGA PCIe target sparsely filled with 16kB allocation (max 512 allocs). > The discontinuous physical memory blocks appear as logically > contiguous to both the FPGA logic and when mapped to userspace. > (But not to driver code.) > > I don't really want to expose the 16k allocation size to userspace. > If we need more than 8MB then the allocation size would need > changing. > > David > > - > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK > Registration No: 1397386 (Wales) Thanks, Ruihan Li