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-pci@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linuxppc-dev <linuxppc-dev@lists.ozlabs.org>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
linux-xtensa@linux-xtensa.org
Subject: Re: [PATCH v12.update2 02/15] PCI: Let pci_mmap_page_range() take resource address
Date: Fri, 17 Jun 2016 14:52:37 -0500 [thread overview]
Message-ID: <20160617195237.GA10416@localhost> (raw)
In-Reply-To: <CAE9FiQVMxuo16MArLXjT8oaSGMce1G=evaWqeOaW-WeT_ju6Mw@mail.gmail.com>
On Fri, Jun 17, 2016 at 12:25:49PM -0700, Yinghai Lu wrote:
> On Thu, Jun 16, 2016 at 7:15 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > On Thu, Jun 09, 2016 at 03:25:52PM -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'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?
> >
> >> Original pci_mmap_page_range() is taking PCI BAR value aka usr_address.
> >>
> >> Bjorn found out that it would be much simple to pass resource address
> >> directly and avoid extra those __pci_mmap_make_offset.
> >>
> >> In this patch:
> >> 1. in proc path: proc_bus_pci_mmap, try convert back to resource
> >> before calling pci_mmap_page_range
> >> 2. in sysfs path: pci_mmap_resource will just offset with resource start.
> >> 3. all pci_mmap_page_range will have vma->vm_pgoff with in resource
> >> range instead of BAR value.
> >> 4. remove __pci_mmap_make_offset, as the checking is done
> >> in pci_mmap_fits().
> >
> > This is a pretty big patch. It would help a lot to split it up.
>
> Looks like they are tight together after change api. vm_pgoff meaning changes.
>
> I could split item 4 to another patch, but compiler could complain or
> even refuse to
> go on if static functions are defined but not used.
Yeah, I was afraid they might be too tightly coupled to split up.
Still, every little bit helps.
> > I think the comment about "re-enabling the 2 lines below" is pointless
> > because doing that would break applications, which I don't think we'll
> > do.
> >
> > I propose the microblaze, powerpc, and sparc patches below, which
> > remove simplify pci_resource_to_user() and clean up this comment.
>
> Agreed. Actually I have the change for sparc/PCI in patch 3
> sparc/PCI: Use correct offset for bus address to resource
> according to previous review.
Sure enough, I see it there now. I think it's easier to review when
split out, so I'll keep it separate, since it's not actually dependent
on the rest of the changes in "sparc/PCI: Use correct offset for bus
address to resource".
> Will drop related change in sparc/PCI: Use correct offset for bus
> address to resource
>
> and respin the whole patchset today.
I added your acks and pushed the result to pci/resource. I'll also
post these formally on the list so they're easier to find.
Bjorn
next prev parent reply other threads:[~2016-06-17 19:52 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-09 22:25 [PATCH v12.update2 02/15] PCI: Let pci_mmap_page_range() take resource address Yinghai Lu
2016-06-17 2:15 ` Bjorn Helgaas
2016-06-17 19:25 ` Yinghai Lu
2016-06-17 19:52 ` Bjorn Helgaas [this message]
2016-06-18 2:27 ` 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=20160617195237.GA10416@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).