All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	David Miller <davem@davemloft.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Wei Yang <weiyang@linux.vnet.ibm.com>,
	Khalid Aziz <khalid.aziz@oracle.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
	linux-xtensa@linux-xtensa.org
Subject: Re: [PATCH v13 01/16] PCI: Let pci_mmap_page_range() take resource address
Date: Sat, 18 Jun 2016 07:17:52 -0500	[thread overview]
Message-ID: <20160618121752.GA22721@localhost> (raw)
In-Reply-To: <20160618022501.15648-2-yinghai@kernel.org>

On Fri, Jun 17, 2016 at 07:24:46PM -0700, Yinghai Lu wrote:
> In 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files"), try
> to check exposed value with resource start/end in proc mmap path.
> 
> |        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 (start >= pci_start && start < pci_start + size &&
> |                        start + nr <= pci_start + size)
> 
> That breaks sparc that exposed value is BAR value, and need to be offseted
> to resource address.

I asked this same question of the v12 patch, but I don't think you
answered it:

I'm not quite sure what you're saying here.  Are you saying that sparc
is currently broken, and this patch fixes it?  If so, what exactly is
broken?  Can you give a small example of an mmap that is currently
broken?

WARNING: multiple messages have this Message-ID (diff)
From: Bjorn Helgaas <helgaas@kernel.org>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	David Miller <davem@davemloft.net>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Wei Yang <weiyang@linux.vnet.ibm.com>,
	Khalid Aziz <khalid.aziz@oracle.com>,
	linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@lists.ozlabs.org, sparclinux@vger.kernel.org,
	linux-xtensa@linux-xtensa.org
Subject: Re: [PATCH v13 01/16] PCI: Let pci_mmap_page_range() take resource address
Date: Sat, 18 Jun 2016 12:17:52 +0000	[thread overview]
Message-ID: <20160618121752.GA22721@localhost> (raw)
In-Reply-To: <20160618022501.15648-2-yinghai@kernel.org>

On Fri, Jun 17, 2016 at 07:24:46PM -0700, Yinghai Lu wrote:
> In 8c05cd08a7 ("PCI: fix offset check for sysfs mmapped files"), try
> to check exposed value with resource start/end in proc mmap path.
> 
> |        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 (start >= pci_start && start < pci_start + size &&
> |                        start + nr <= pci_start + size)
> 
> That breaks sparc that exposed value is BAR value, and need to be offseted
> to resource address.

I asked this same question of the v12 patch, but I don't think you
answered it:

I'm not quite sure what you're saying here.  Are you saying that sparc
is currently broken, and this patch fixes it?  If so, what exactly is
broken?  Can you give a small example of an mmap that is currently
broken?

  reply	other threads:[~2016-06-18 12:17 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-18  2:24 [PATCH v13 00/16] PCI: Fixup for 64bit resource with sparc Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 01/16] PCI: Let pci_mmap_page_range() take resource address Yinghai Lu
2016-06-18  2:24   ` Yinghai Lu
2016-06-18 12:17   ` Bjorn Helgaas [this message]
2016-06-18 12:17     ` Bjorn Helgaas
2016-06-22  4:32     ` Yinghai Lu
2016-06-22  4:32       ` Yinghai Lu
2016-06-22 15:22       ` Bjorn Helgaas
2016-06-22 15:22         ` Bjorn Helgaas
2016-06-22 19:22         ` Yinghai Lu
2016-06-22 19:22           ` Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 02/16] PCI: Remove __pci_mmap_make_offset() Yinghai Lu
2016-06-18  2:24   ` Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 03/16] PCI: Check resource alignment for /sys pci_mmap_resource path Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 04/16] sparc/PCI: Use correct offset for bus address to resource Yinghai Lu
2016-06-18  2:24   ` Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 05/16] PCI: Add pci_find_bus_resource() Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 06/16] sparc/PCI: Reserve legacy mmio after PCI mmio Yinghai Lu
2016-06-18  2:24   ` Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 07/16] sparc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing Yinghai Lu
2016-06-18  2:24   ` Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 08/16] sparc/PCI: Keep resource idx order with bridge register number Yinghai Lu
2016-06-18  2:24   ` Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 09/16] powerpc/PCI: " Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 10/16] powerpc/PCI: Add IORESOURCE_MEM_64 for 64-bit resource in OF parsing Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 11/16] OF/PCI: Add IORESOURCE_MEM_64 for 64-bit resource Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 12/16] PCI: Check pref compatible bit for mem64 resource of PCIe device Yinghai Lu
2016-06-18  2:24   ` Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 13/16] PCI: Only treat non-pref mmio64 as pref if all bridges have MEM_64 Yinghai Lu
2016-06-18  2:24 ` [PATCH v13 14/16] PCI: Add has_mem64 for struct host_bridge Yinghai Lu
2016-06-18  2:25 ` [PATCH v13 15/16] PCI: Only treat non-pref mmio64 as pref if host bridge has mmio64 Yinghai Lu
2016-06-18  2:25 ` [PATCH v13 16/16] PCI: Restore pref MMIO allocation logic for host bridge without mmio64 Yinghai Lu
2016-08-08 19:49 ` [PATCH v13 00/16] PCI: Fixup for 64bit resource with sparc Bjorn Helgaas
2016-08-09 16:15   ` Yinghai Lu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160618121752.GA22721@localhost \
    --to=helgaas@kernel.org \
    --cc=benh@kernel.crashing.org \
    --cc=bhelgaas@google.com \
    --cc=davem@davemloft.net \
    --cc=khalid.aziz@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=sparclinux@vger.kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=weiyang@linux.vnet.ibm.com \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.