From patchwork Thu Apr 28 04:55:45 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yinghai Lu X-Patchwork-Id: 615981 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3qwPfg1j5pz9t6g for ; Thu, 28 Apr 2016 14:55:52 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b=CBSXp3Fm; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750792AbcD1Ezr (ORCPT ); Thu, 28 Apr 2016 00:55:47 -0400 Received: from mail-vk0-f65.google.com ([209.85.213.65]:34875 "EHLO mail-vk0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750761AbcD1Ezq (ORCPT ); Thu, 28 Apr 2016 00:55:46 -0400 Received: by mail-vk0-f65.google.com with SMTP id c189so2605195vkb.2; Wed, 27 Apr 2016 21:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=9+rmx4AgcPyYm3IiLeTqzO7rDFKiVvAPtrlNdyLCDqs=; b=CBSXp3FmuvvCxOgYxNdKSGCD6wSrNawo0dWJlR6qIt8k4MZsS/GWoWYRD1ESyakLcI Ngs9odt4NPxophpnMNXEfJCMKV5x4QjScVLrDgOaOGdJo1gf+ReoGRK85G/RQfiSRGYV kGgv+LFiZSk5x8EVv1RVIB9TzchWohIt4zOMuwyMeFRPXnIBwt2EopKOTCVp8G2Kzdib WqQ5CKif/XKb3lTHngXVnHFid7BgXUXskPTr3Cbd5qqD+xkJHjfYD1+JDZOUsAmdIJ4N qsXEEnvweLyLahbvYTR8sezY+Hc2tmyCLpGU5ASJ2YyEV5xD/Ci0NgHZ8gRbSDEmnP3q +lIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=9+rmx4AgcPyYm3IiLeTqzO7rDFKiVvAPtrlNdyLCDqs=; b=e4SGFiTB/2LzKeJVDu47hEvevbqF7lpMAKLycjTZ78ZO6rBlYlu/yO4Jh8rjZnr6tr WlYKOw/rriGpRuZ0y9zeGl2w9XU9H0aWEedNhv5O4+a5e/YkDVCNsh7Mxf5JbK5Usn+C LVTCnLMqyf9+sqHuxTWNvOuuhZeiB4Ph1MQVV7ciz1RfOsaJFcVIMZO9V7rB9bq/Ni0Y 3upuE2O4NVF70/Dcz1eNgT0M8dW8tu/N7+u6pSvHJO37Y3n6eoBweTgReVSj83E58RPG vUvJMiW13sPkygy5hZD5Hhs+NLT4G17cGYyH/d2N4696FetSr0ktyq3Z+d/ncWNEQd1e CdAQ== X-Gm-Message-State: AOPr4FUWdwMZ5r8hN4g72EpF3ARZ+Vmc3DmufElMslK5liABlB2NaLr/4IGHuAfq4Vh+XXU/Hpe50mgwa7VRNQ== MIME-Version: 1.0 X-Received: by 10.159.37.181 with SMTP id 50mr6254689uaf.146.1461819345377; Wed, 27 Apr 2016 21:55:45 -0700 (PDT) Received: by 10.103.125.216 with HTTP; Wed, 27 Apr 2016 21:55:45 -0700 (PDT) In-Reply-To: <20160422204920.GA17215@localhost> References: <1460074573-7481-1-git-send-email-yinghai@kernel.org> <1460074573-7481-5-git-send-email-yinghai@kernel.org> <20160422204920.GA17215@localhost> Date: Wed, 27 Apr 2016 21:55:45 -0700 X-Google-Sender-Auth: LgnmSdj3rMtojP5fgU9Ud8zZlpw Message-ID: Subject: Re: [PATCH v11 04/60] sparc/PCI: Use correct offset for bus address to resource From: Yinghai Lu To: Bjorn Helgaas Cc: Bjorn Helgaas , David Miller , Benjamin Herrenschmidt , Linus Torvalds , Wei Yang , TJ , Yijing Wang , Khalid Aziz , "linux-pci@vger.kernel.org" , Linux Kernel Mailing List , Michael Ellerman Sender: linux-pci-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org On Fri, Apr 22, 2016 at 1:49 PM, Bjorn Helgaas wrote: > [+cc Ben, Michael] > I'm kind of confused here. There are two ways to mmap PCI BARs: > > /proc/bus/pci/00/02.0 (proc_bus_pci_mmap()): > all BARs in one file; MEM/IO determined by ioctl() > mmap offset is a CPU physical address in the PCI resource > > /sys/devices/pci0000:00/0000:00:02.0/resource0 (pci_mmap_resource()): > one file per BAR; MEM/IO determined by BAR type > mmap offset is between 0 and BAR size > > Both proc_bus_pci_mmap() and pci_mmap_resource() validate the > requested area with pci_mmap_fits() before calling pci_mmap_page_range(). > > In the proc_bus_pci_mmap() path, the offset in vma->vm_pgoff must be > within the pdev->resource[], so the user must be supplying a CPU > physical address (not an address obtained from pci_resource_to_user()). > That vma->vm_pgoff is passed unchanged to pci_mmap_page_range(). > > In the pci_mmap_resource() path, vma->vm_pgoff must be between 0 and > the BAR size. Then we add in the pci_resource_to_user() information > before passing it to pci_mmap_page_range(). The comment in > pci_mmap_resource() says pci_mmap_page_range() expects a "user > visible" address, but I don't really believe that based on how > proc_bus_pci_mmap() works. > > Do both proc_bus_pci_mmap() and pci_mmap_resource() work on sparc? > It looks like they call pci_mmap_page_range() with different > assumptions, so I don't see how they can both work. for sysfs path: in pci_mmap_resource pci_resource_to_user(pdev, i, res, &start, &end); vma->vm_pgoff += start >> PAGE_SHIFT; then call pci_mmap_page_range() the fit checking in pci_mmap_fits(), pci_start = (mmap_api == PCI_MMAP_PROCFS) ? pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0; if (start >= pci_start && start < pci_start + size && start + nr <= pci_start + size) so proc fs assume resource_start for vm_pgoff ? but current pci_mmap_page_range want to use bus address start aka BAR value. and we have /* pci_mmap_page_range() expects the same kind of entry as coming * from /proc/bus/pci/ which is a "user visible" value. If this is * different from the resource itself, arch will do necessary fixup. */ so we need to fix pci_mmap_fits(), please check if it is ok, will submit it as separated one. --- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index d319a9c..3768c6a 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -969,15 +969,20 @@ void pci_remove_legacy_files(struct pci_bus *b) int pci_mmap_fits(struct pci_dev *pdev, int resno, struct vm_area_struct *vma, enum pci_mmap_api mmap_api) { - unsigned long nr, start, size, pci_start; + unsigned long nr, start, size; + resource_size_t pci_start = 0, pci_end; if (pci_resource_len(pdev, resno) == 0) return 0; nr = vma_pages(vma); start = vma->vm_pgoff; size = ((pci_resource_len(pdev, resno) - 1) >> PAGE_SHIFT) + 1; - pci_start = (mmap_api == PCI_MMAP_PROCFS) ? - pci_resource_start(pdev, resno) >> PAGE_SHIFT : 0; + if (mmap_api == PCI_MMAP_PROCFS) { + struct resource *res = &pdev->resource[resno]; + + pci_resource_to_user(pdev, resno, res, &pci_start, &pci_end); + pci_start >>= PAGE_SHIFT; + } if (start >= pci_start && start < pci_start + size && start + nr <= pci_start + size) return 1;