From: John Garry <firstname.lastname@example.org>
To: David Laight <David.Laight@ACULAB.COM>,
Niklas Schnelle <email@example.com>,
Arnd Bergmann <firstname.lastname@example.org>
Cc: Linus Torvalds <email@example.com>,
"Linux Kernel Mailing List" <firstname.lastname@example.org>
Subject: Re: [GIT PULL 1/2] asm-generic: rework PCI I/O space access
Date: Tue, 21 Dec 2021 16:21:10 +0000 [thread overview]
Message-ID: <email@example.com> (raw)
On 19/12/2021 14:23, David Laight wrote:
>>>>> I have tested this on s390 with HAS_IOPORT=n and allyesconfig as well
>>>>> as running it with defconfig. I've also been using it on my Ryzen 3990X
>>>>> workstation with LEGACY_PCI=n for a few days. I do get about 60 MiB
>>>>> fewer modules compared with a similar config of v5.15.8. Hard to say
>>>>> which other systems might miss things of course.
>>>>> I have not yet worked on the discussed IOPORT_NATIVE flag. Mostly I'm
>>>>> wondering two things. For one it feels like that could be a separate
>>>>> change on top since HAS_IOPORT + LEGACY_PCI is already quite big.
>>>>> Secondly I'm wondering about good ways of identifying such drivers and
>>>>> how much this overlaps with the ISA config flag.
>> I was interesting in the IOPORT_NATIVE flag (or whatever we call it) as
>> it solves the problem of drivers which "unconditionally do inb()/outb()
>> without checking the validity of the address using firmware or other
>> methods first" being built for (and loaded on and crashing) unsuitable
>> systems. Such a problem is in 
>> So if we want to support that later, then it seems that someone would
>> need to go back and re-edit many same driver Kconfigs – like hwmon, for
>> example. I think it's better to avoid that and do it now.
> Could you do something where valid arguments to inb() have to come
> from some kernel mapping/validation function and are never in the
> range [0x0, 0x10000).
> Then drivers that are cheating the system will fail.
That sounds like the solution which I had here:
It worked for the scenario I was interested in, but Arnd had some
concerns, which you can check there.
> Or, maybe, only allow [0x0, 0x10000) on systems that have a suitable bus.
> With the mapping functions returning a different value (eg the KVA into
> the PCI master window) that can be separately verified.
> That would let drivers do (say) inb(0x120) on systems that have (something
> like) and ISA bus, but not on PCI-only systems which support PCI IO
> accesses through a physical address window.
I'm not sure how this would look in practice. What would the check for
the suitable bus be?
next prev parent reply other threads:[~2021-12-21 16:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-02 13:47 [GIT PULL 1/2] asm-generic: rework PCI I/O space access Arnd Bergmann
2021-07-02 13:49 ` [GIT PULL 2/2] asm-generic: Unify asm/unaligned.h around struct helper Arnd Bergmann
2021-07-02 20:13 ` pr-tracker-bot
2021-07-02 19:42 ` [GIT PULL 1/2] asm-generic: rework PCI I/O space access Linus Torvalds
2021-07-03 12:12 ` Arnd Bergmann
2021-07-05 10:06 ` Arnd Bergmann
2021-08-03 9:46 ` John Garry
2021-08-03 10:06 ` Arnd Bergmann
2021-08-03 11:23 ` John Garry
2021-08-03 12:15 ` Arnd Bergmann
2021-08-04 7:55 ` John Garry
2021-08-04 8:52 ` Arnd Bergmann
2021-08-10 9:19 ` John Garry
2021-08-10 11:33 ` Arnd Bergmann
2021-09-03 8:31 ` Niklas Schnelle
2021-12-17 13:19 ` Niklas Schnelle
2021-12-17 13:32 ` Arnd Bergmann
2021-12-17 13:52 ` Niklas Schnelle
2021-12-17 14:05 ` Arnd Bergmann
2021-12-17 14:27 ` John Garry
2021-12-17 14:32 ` Arnd Bergmann
2021-12-17 15:27 ` John Garry
2021-12-17 15:55 ` Arnd Bergmann
2021-12-17 16:30 ` John Garry
2021-12-20 9:27 ` Niklas Schnelle
2021-12-21 16:48 ` John Garry
2021-12-21 16:57 ` Niklas Schnelle
2021-12-19 14:23 ` David Laight
2021-12-21 16:21 ` John Garry [this message]
2021-07-05 12:40 ` Niklas Schnelle
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.