lkml.org 
[lkml]   [2022]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC v2 01/39] Kconfig: introduce HAS_IOPORT option and select it as necessary
    From
    Date
    On Wed, 2022-05-04 at 23:31 +0200, Arnd Bergmann wrote:
    > On Wed, May 4, 2022 at 11:08 PM Bjorn Helgaas <helgaas@kernel.org> wrote:
    > > On Fri, Apr 29, 2022 at 03:49:59PM +0200, Niklas Schnelle wrote:
    > > > We introduce a new HAS_IOPORT Kconfig option to indicate support for
    > > > I/O Port access. In a future patch HAS_IOPORT=n will disable compilation
    > > > of the I/O accessor functions inb()/outb() and friends on architectures
    > > > which can not meaningfully support legacy I/O spaces such as s390 or
    > > > where such support is optional.
    > >
    > > So you plan to drop inb()/outb() on architectures where I/O port space
    > > is optional? So even platforms that have I/O port space may not be
    > > able to use it?
    > >
    > > This feels like a lot of work where the main benefit is to keep
    > > Kconfig from offering drivers that aren't of interest on s390.
    > >
    > > Granted, there may be issues where inb()/outb() does the wrong thing
    > > such as dereferencing null pointers when I/O port space isn't
    > > implemented. I think that's a defect in inb()/outb() and could be
    > > fixed there.
    >
    > The current implementation in asm-generic/io.h implements inb()/outb()
    > using readb()/writeb() with a fixed architecture specific offset.
    >
    > There are three possible things that can happen here:
    >
    > a) there is a host bridge driver that maps its I/O ports to this window,
    > and everything works
    > b) the address range is reserved and accessible but no host bridge
    > driver has mapped its registers there, so an access causes a
    > page fault
    > c) the architecture does not define an offset, and accessing low I/O
    > ports ends up as a NULL pointer dereference
    >
    > The main goal is to avoid c), which is what happens on s390, but
    > can also happen elsewhere. Catching b) would be nice as well,
    > but is much harder to do from generic code as you'd need an
    > architecture specific inline asm statement to insert a ex_table
    > fixup, or a runtime conditional on each access.
    >
    > Arnd

    Yes and to add to this, we did try a local solution in inb()/outb()
    before. This added a warning when they are used and we know at compile
    time that we're dealing with case c). This approach was nacked by Linus
    though as we were turning a compile time known broken case into a
    runtime one:

    https://lore.kernel.org/lkml/CAHk-=wg80je=K7madF4e7WrRNp37e3qh6y10Svhdc7O8SZ_-8g@mail.gmail.com/

    I do agree with this assesment and think this is the right™ approach
    but it is more churn as can be seen by the size of this series. I think
    longer term it could be valuable though especially if more platforms
    phase out I/O port support like POWER9 for which this also allows
    filtering what drivers will never work.

    \
     
     \ /
      Last update: 2022-05-05 10:14    [W:7.464 / U:0.152 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site