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
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-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 19:52:37 +0000 [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: 10+ 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-09 22:25 ` Yinghai Lu
2016-06-17 2:15 ` Bjorn Helgaas
2016-06-17 2:15 ` Bjorn Helgaas
2016-06-17 19:25 ` Yinghai Lu
2016-06-17 19:25 ` Yinghai Lu
2016-06-17 19:52 ` Bjorn Helgaas [this message]
2016-06-17 19:52 ` Bjorn Helgaas
2016-06-18 2:27 ` Yinghai Lu
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 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.