From: ebiederm@xmission.com (Eric W. Biederman)
To: Matthew Wilcox <willy@debian.org>
Cc: Linus Torvalds <torvalds@osdl.org>,
"Durairaj, Sundarapandian" <sundarapandian.durairaj@intel.com>,
Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-pci@atrey.karlin.mff.cuni.cz,
Alan Cox <alan@lxorguk.ukuu.org.uk>, Greg KH <greg@kroah.com>,
Andi Kleen <ak@colin2.muc.de>, Andrew Morton <akpm@osdl.org>,
mj@ucw.cz, "Kondratiev, Vladimir" <vladimir.kondratiev@intel.com>,
"Seshadri, Harinarayanan" <harinarayanan.seshadri@intel.com>,
"Nakajima, Jun" <jun.nakajima@intel.com>
Subject: Re: [patch] PCI Express Enhanced Config Patch - 2.6.0-test11
Date: 01 Feb 2004 14:35:02 -0700 [thread overview]
Message-ID: <m1u12av5yx.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20040201201103.GW18725@parcelfarce.linux.theplanet.co.uk>
Matthew Wilcox <willy@debian.org> writes:
> On Sun, Feb 01, 2004 at 11:28:38AM -0700, Eric W. Biederman wrote:
> > I suspect the check for addresses being an address being too big
> > would be useful even on 64bit architectures. I just looked
> > and ia64 does not have that check and bad BARs could cause
> > interesting problems. It makes sense to catch illegal bar values
> > earlier, but this whole part of the code is a slow path so putting in
> > a sanity check should not hurt anything.
>
> Hard to say since ia64 boxes don't usually have BIOSes written by people
> on minimum wage. It certainly wouldn't hurt to check though.
An uninitialized BAR could have the same effect and it is easier to
trigger. ia64 boxes get so little volume you can miss things. I
killed an ia64 box once by changing the serial console baud rate.
I have no problem with firmware it is just that since it must be
written on a per board basis, and firmware is hard to update you
simply can't assume it is correct. Some little bug may have gotten
through the QA checks. Hardware has similar pressures except it
is even harder to correct.
So the concern is just healthy programmer paranoia. If it can
go wrong it will.
> > I think we want an ioremap_pfn instead of an ioremap64. On 64bit
> > platforms ioremap64 is just ioremap so it is redundant. On 32bit
> > platforms ioremap64 is really ioremap_pfn with just a different
> > wrapper around it. While ioremap_pfn makes sense on all
> > architectures.
>
> Yeah, but it doesn't make sense to driver writers. They have a hard
> enough time dealing with scatterlists. Heck, I don't even know what
> pfn stands for. So I'm all for having ioremap_pfn() as the base function,
> as long as we still have ioremap(), ioremap64() and map_resource() as
> wrappers around it.
pfn is short for page frame number. It is the abbreviation that is used
by the kernel vm layer for a page number. And it is a term that at
least to be used quite a lot in texts explaining virtual memory and
paging.
If you have a map_resource I don't know why you would need ioremap64.
But I have no problems with wrappers. The question mostly is which
function is architecture specific and which can be generic.
If I was not in the middle of moving out of my current apartment
hunting I think I would whip up a patch.
> > Could the patch be updated to do that please?
>
> Yup, not hard. Patch below.
Thanks for the updated patch.
> Actually, it's not relevant for ia64 because ia64 accesses PCI config
> space through SAL. I did a patch for ia64 and posted it to the list
> last week (SAL was revised to allow for the larger address space).
> It's part of the below patch.
Ok it is nice to see the support getting there.
The table entry should be just as relevant on ia64. It is odd
though that on ia64 the firmware interface is updated and on x86 a
firmware bypass interface is added.
Eric
next prev parent reply other threads:[~2004-02-01 21:42 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-29 11:32 Durairaj, Sundarapandian
2004-01-29 15:09 ` Matthew Wilcox
2004-01-29 15:59 ` Matthew Wilcox
2004-01-29 16:05 ` Linus Torvalds
2004-01-29 16:42 ` Matthew Wilcox
2004-01-29 16:52 ` Linus Torvalds
2004-01-31 21:57 ` Eric W. Biederman
2004-02-01 4:41 ` Grant Grundler
2004-02-01 5:10 ` Matthew Wilcox
2004-02-01 11:00 ` Eric W. Biederman
2004-02-01 15:18 ` Matthew Wilcox
2004-02-01 18:28 ` Eric W. Biederman
2004-02-01 20:11 ` Matthew Wilcox
2004-02-01 21:35 ` Eric W. Biederman [this message]
2004-02-01 11:10 ` Eric W. Biederman
2004-01-29 18:09 ` Greg KH
2004-01-30 16:33 ` Greg KH
-- strict thread matches above, loose matches on Subject: below --
2004-01-30 16:58 Nakajima, Jun
2004-01-28 9:38 Durairaj, Sundarapandian
2004-01-28 14:42 ` Vladimir Kondratiev
2004-01-28 14:54 ` Christoph Hellwig
2004-01-28 15:00 ` Martin Mares
2004-01-28 15:18 ` Matthew Wilcox
2004-01-22 10:21 Durairaj, Sundarapandian
2004-01-22 10:44 ` Andrew Morton
2004-01-22 11:09 ` Martin Mares
2004-01-22 13:12 ` Andi Kleen
2004-01-22 18:21 ` Alan Cox
2004-01-22 19:40 ` Randy.Dunlap
2004-01-23 19:19 ` Pavel Machek
2004-01-23 19:31 ` Martin Mares
2004-01-23 20:08 ` Stefan Smietanowski
2004-01-22 16:40 ` Grant Grundler
2004-01-22 17:00 ` Greg KH
2004-01-07 16:44 Nakajima, Jun
2004-01-07 12:59 Durairaj, Sundarapandian
2004-01-07 14:08 ` Meelis Roos
2004-01-07 17:34 ` Vladimir Kondratiev
[not found] <183UK-2Re-11@gated-at.bofh.it>
2003-12-29 19:12 ` Andi Kleen
2003-12-29 11:32 Durairaj, Sundarapandian
2003-12-29 11:53 ` Arjan van de Ven
2003-12-29 11:55 ` Christoph Hellwig
2003-12-29 12:51 ` Johan Sjoholm
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=m1u12av5yx.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=ak@colin2.muc.de \
--cc=akpm@osdl.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=greg@kroah.com \
--cc=harinarayanan.seshadri@intel.com \
--cc=jun.nakajima@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@atrey.karlin.mff.cuni.cz \
--cc=mj@ucw.cz \
--cc=sundarapandian.durairaj@intel.com \
--cc=torvalds@osdl.org \
--cc=vladimir.kondratiev@intel.com \
--cc=willy@debian.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
all inboxes | Powered by JetHome®