From patchwork Thu Nov 13 11:19:15 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Lorenzo Pieralisi X-Patchwork-Id: 40741 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-wg0-f72.google.com (mail-wg0-f72.google.com [74.125.82.72]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id 7119A240ED for ; Thu, 13 Nov 2014 11:19:58 +0000 (UTC) Received: by mail-wg0-f72.google.com with SMTP id y19sf557191wgg.3 for ; Thu, 13 Nov 2014 03:19:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:delivered-to:from:to:cc:subject :date:message-id:in-reply-to:references:sender:precedence:list-id :x-original-sender:x-original-authentication-results:mailing-list :list-post:list-help:list-archive:list-unsubscribe; bh=5aXsOomRX3ey4xVlm0j2h9RqsNZN5GAGoIQcqpYOlM8=; b=NeOqkrRqk5x0MIxYxmb35ga4a6f24rVnxzd0YBDXPvkG5rDG1yCK1yloZ9TqgC3NvF 3dci2ubvtN3s1W/qirocNbmUs5XUKYnkbPipa9DdB9iEjhVzn3ezITMnqcUd7PmCzfqI jq0Hvf3LsLdn6CZnKzabs2P7LHih+3uV10Ni70caTpCRFw+lqZ5PvnRInccL11SJdA48 4fcQfx2LSl/mR2RNBHMhF9O2Gd1ZWyPt6tNsi00lqZxHfg1pecP71cyLj5q0oc+sEfaZ hDIlU/mD8MFlufi8mxPKKv1WeP8WKx9Zpgm/NmQfabz92Jb/rcb3xv44+bysKVe+ek+J mTMw== X-Gm-Message-State: ALoCoQlbLMgnubMqG/s58Ijs4tN5C+2leDw+XQr/R3VzaC9sP/xLeGlp8wwwWu658qYKmU+sl2Yl X-Received: by 10.152.6.4 with SMTP id w4mr476520law.7.1415877597705; Thu, 13 Nov 2014 03:19:57 -0800 (PST) MIME-Version: 1.0 X-BeenThere: patchwork-forward@linaro.org Received: by 10.152.23.229 with SMTP id p5ls503169laf.4.gmail; Thu, 13 Nov 2014 03:19:57 -0800 (PST) X-Received: by 10.112.146.37 with SMTP id sz5mr1781845lbb.27.1415877597444; Thu, 13 Nov 2014 03:19:57 -0800 (PST) Received: from mail-la0-f42.google.com (mail-la0-f42.google.com. [209.85.215.42]) by mx.google.com with ESMTPS id oh2si37963457lbb.107.2014.11.13.03.19.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Nov 2014 03:19:57 -0800 (PST) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.42 as permitted sender) client-ip=209.85.215.42; Received: by mail-la0-f42.google.com with SMTP id gq15so13126984lab.29 for ; Thu, 13 Nov 2014 03:19:57 -0800 (PST) X-Received: by 10.112.62.166 with SMTP id z6mr1784675lbr.74.1415877597266; Thu, 13 Nov 2014 03:19:57 -0800 (PST) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.112.184.201 with SMTP id ew9csp572791lbc; Thu, 13 Nov 2014 03:19:56 -0800 (PST) X-Received: by 10.66.218.42 with SMTP id pd10mr1695911pac.151.1415877595381; Thu, 13 Nov 2014 03:19:55 -0800 (PST) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id kt6si723165pdb.141.2014.11.13.03.19.54 for ; Thu, 13 Nov 2014 03:19:55 -0800 (PST) Received-SPF: none (google.com: linux-kernel-owner@vger.kernel.org does not designate permitted sender hosts) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932794AbaKMLTw (ORCPT + 26 others); Thu, 13 Nov 2014 06:19:52 -0500 Received: from foss-mx-na.foss.arm.com ([217.140.108.86]:57415 "EHLO foss-mx-na.foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932416AbaKMLTW (ORCPT ); Thu, 13 Nov 2014 06:19:22 -0500 Received: from foss-smtp-na-1.foss.arm.com (unknown [10.80.61.8]) by foss-mx-na.foss.arm.com (Postfix) with ESMTP id EB18317A; Thu, 13 Nov 2014 05:19:17 -0600 (CST) Received: from collaborate-mta1.arm.com (highbank-bc01-b06.austin.arm.com [10.112.81.134]) by foss-smtp-na-1.foss.arm.com (Postfix) with ESMTP id CE4735FAD7; Thu, 13 Nov 2014 05:19:15 -0600 (CST) Received: from red-moon.cambridge.arm.com (red-moon.cambridge.arm.com [10.1.203.137]) by collaborate-mta1.arm.com (Postfix) with ESMTP id 463BC13F78C; Thu, 13 Nov 2014 05:19:14 -0600 (CST) From: Lorenzo Pieralisi To: linux-kernel@vger.kernel.org Cc: Lorenzo Pieralisi , Arnd Bergmann , Jesse Barnes , Bjorn Helgaas , Benjamin Herrenschmidt , Russell King , "David S. Miller" , Michal Simek , Martin Wilck , Linux PCI Subject: [RFC PATCH v3 1/2] drivers: pci: fix pci_mmap_fits() implementation for procfs mmap Date: Thu, 13 Nov 2014 11:19:15 +0000 Message-Id: <1415877558-8906-2-git-send-email-lorenzo.pieralisi@arm.com> X-Mailer: git-send-email 2.1.2 In-Reply-To: <1415877558-8906-1-git-send-email-lorenzo.pieralisi@arm.com> References: <1415877558-8906-1-git-send-email-lorenzo.pieralisi@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: lorenzo.pieralisi@arm.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.215.42 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , The introduction of pci_mmap_fits() in commit: b5ff7df3df9efab511244d5a299fce706c71af48 "Check mapped ranges on sysfs resource files" allowed to check for valid range mappings of PCI resources to user space when mapping PCI resources through the sysfs filesystem. The mapping of resources through the sysfs expects the offset passed by the user through the mmap syscall to be 0, and the pgoff is adjusted by the kernel to memory map the resource to the CPU physical address corresponding to the PCI resource in question. The usage of procfs mapping of PCI resources (/proc/bus/pci files) is more controversial in that userspace programs mapping PCI resources are expected to pass in the mmap offset field either a CPU physical address or a PCI bar value, depending on the architecture. By the time pci_mmap_fits() was used to check PCI resource ranges for procfs PCI resources mapping in commit: 9eff02e2042f96fb2aedd02e032eca1c5333d7 "PCI: check mmap range of /proc/bus/pci files too" the procfs interface for mmapping resources to user space broke, since pci_mmap_fits() expected the offset passed from user space in the mmap call to be 0, not the CPU physical address or PCI BAR value of the resource in question. Subsequent attempts at fixing the pci_mmap_fits() implementation failed to fix the issue (or fixed the issue in some architectures but not for all of them, ARM and SPARC procfs interface PCI resources mapping stayed broken throughout) in particular commits: 8c05cd08a7504b855c265263e84af61aabafa329 "PCI: fix offset check for sysfs mmapped files" and 3b519e4ea618b6943a82931630872907f9ac2c2b "PCI: fix size checks for mmap() on /proc/bus/pci files" fixed procfs PCI resources mapping checks in pci_mmap_fits for some architectures, but not for architectures like SPARC that expects the offset value passed from user space through the mmap syscall (when mapping through procfs) to represent the PCI BAR value of the resource to be mapped. The reason behind the breakage is the following. The addresses stored in PCI device resources for memory spaces correspond to CPU physical addresses, which do not necessarily map 1:1 to PCI bus addresses as programmed in PCI devices configuration spaces. This implies that the sanity checks carried out in pci_mmap_fits() to ensure that the user executes an mmap of a "real" pci resource are erroneous when executed through procfs. Some platforms (ie SPARC) expect the offset value to be passed in (procfs mapping) to be the PCI BAR configuration value as read from the PCI device configuration space, not the fixed-up CPU physical address that is present in PCI device resources. The required pgoff (offset in mmap syscall) value passed from userspace is supposed to represent the resource value exported through /proc/bus/pci/devices when the resource is mmapped though procfs (and 0 when the mapping is carried out through sysfs resource files), which corresponds to the PCI resource filtered through the pci_resource_to_user() API. This patch converts the PCI resource to the expected "user visible" value through pci_resource_to_user() before carrying out sanity checks in pci_mmap_fits() so that the check is carried out on the resource values as expected from the userspace mmap API. Cc: Arnd Bergmann Cc: Jesse Barnes Cc: Bjorn Helgaas Cc: Benjamin Herrenschmidt Cc: Russell King Cc: David S. Miller Cc: Michal Simek Cc: Martin Wilck Signed-off-by: Lorenzo Pieralisi --- drivers/pci/pci-sysfs.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c index 2c6643f..e4634e3 100644 --- a/drivers/pci/pci-sysfs.c +++ b/drivers/pci/pci-sysfs.c @@ -963,17 +963,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, pci_offset; + resource_size_t pci_start, pci_end; if (pci_resource_len(pdev, resno) == 0) return 0; nr = vma_pages(vma); start = vma->vm_pgoff; + pci_resource_to_user(pdev, resno, &pdev->resource[resno], + &pci_start, &pci_end); 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 (start >= pci_start && start < pci_start + size && - start + nr <= pci_start + size) + pci_offset = (mmap_api == PCI_MMAP_PROCFS) ? + pci_start >> PAGE_SHIFT : 0; + if (start >= pci_offset && start < pci_offset + size && + start + nr <= pci_offset + size) return 1; return 0; }