All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Murray <andrew.murray@arm.com>
To: John Garry <john.garry@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Will Deacon <will.deacon@arm.com>,
	dann.frazier@canonical.com, bhelgaas@google.com,
	andy.shevchenko@gmail.com, Linuxarm <linuxarm@huawei.com>,
	linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, suzuki.poulose@arm.com,
	jean-philippe.brucker@arm.com
Subject: Re: [PATCH] asm-generic: io: Fix ioport_map() for !CONFIG_GENERIC_IOMAP && CONFIG_INDIRECT_PIO
Date: Mon, 17 Sep 2018 16:19:17 +0100	[thread overview]
Message-ID: <20180917151917.GB5390@e119886-lin.cambridge.arm.com> (raw)
In-Reply-To: <464e07ab-797e-971a-0839-5fd55e3e2ad3@huawei.com>

On Mon, Sep 17, 2018 at 03:42:32PM +0100, John Garry wrote:
> - dead e-mail addresses (Zhichang, Gabriele)
> 
> On 13/09/2018 13:48, Andrew Murray wrote:
> 
> Hi Andrew,
> 
> > The !CONFIG_GENERIC_IOMAP version of ioport_map uses MMIO_UPPER_LIMIT to
> > prevent users from making I/O accesses outside the expected I/O range -
> > however it erroneously treats MMIO_UPPER_LIMIT as a mask which is
> > contradictory to its other users.
> > 
> > The introduction of CONFIG_INDIRECT_PIO, which subtracts an arbitrary
> > amount from IO_SPACE_LIMIT to form MMIO_UPPER_LIMIT, results in ioport_map
> > mangling the given port rather than capping it.
> > 
> > We address this by aligning more closely with the CONFIG_GENERIC_IOMAP
> > implementation of ioport_map by using the comparison operator and
> > returning NULL where the port exceeds MMIO_UPPER_LIMIT. Though note that
> > we preserve the existing behavior of masking with IO_SPACE_LIMIT such that
> > we don't break existing buggy drivers that somehow rely on this masking.
> 
> I wouldn't say any drivers rely on this - for the only device driver which
> uses the "Indirect" IO space region above MMIO_UPPER_LIMIT (HiSilicon LPC),
> no child device driver for that host uses ioport_map() [those being ipmi si
> and 8250 generic+of drivers].

I was really referring to the existing !CONFIG_GENERIC_IOMAP && 
!CONFIG_INDIRECT_PIO use cases where there may be drivers (however unlikely)
that provide ioport_map an incorrect address which, due to the masking, gets
converted into a valid address. Returning NULL for these would result in new
run-time errors therefore it seemed safer to change this to support the new
"indirect IO" whilst not breaking existing bad drivers.

A more correct implementation would always return NULL if
port > IO_SPACE_LIMIT - it would fully align it with the CONFIG_GENERIC_IOMAP
implementation - in my view these two implementations should behave the same
with respect to error handling - at the moment they don't.


> 
> Regardless of that, it seems better to return NULL when the port is
> out-of-range, rather than masking it.
> 
> Cheers
> 
> > 
> > Fixes: 5745392e0c2b ("PCI: Apply the new generic I/O management on PCI IO hosts")
> > Reported-by: Will Deacon <will.deacon@arm.com>
> > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> 
> Reviewed-by: John Garry <john.garry@huawei.com>

Thanks for the review.

Andrew Murray

> 
> > ---
> >  include/asm-generic/io.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> > index 66d1d45..d356f80 100644
> > --- a/include/asm-generic/io.h
> > +++ b/include/asm-generic/io.h
> > @@ -1026,7 +1026,8 @@ static inline void __iomem *ioremap_wt(phys_addr_t offset, size_t size)
> >  #define ioport_map ioport_map
> >  static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
> >  {
> > -	return PCI_IOBASE + (port & MMIO_UPPER_LIMIT);
> > +	port &= IO_SPACE_LIMIT;
> > +	return (port > MMIO_UPPER_LIMIT) ? NULL : PCI_IOBASE + port;
> >  }
> >  #endif
> > 
> > 
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Andrew Murray <andrew.murray@arm.com>
To: John Garry <john.garry@huawei.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
	suzuki.poulose@arm.com, jean-philippe.brucker@arm.com,
	dann.frazier@canonical.com, Will Deacon <will.deacon@arm.com>,
	Linuxarm <linuxarm@huawei.com>,
	linux-kernel@vger.kernel.org, andy.shevchenko@gmail.com,
	linux-pci@vger.kernel.org, bhelgaas@google.com,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] asm-generic: io: Fix ioport_map() for !CONFIG_GENERIC_IOMAP && CONFIG_INDIRECT_PIO
Date: Mon, 17 Sep 2018 16:19:17 +0100	[thread overview]
Message-ID: <20180917151917.GB5390@e119886-lin.cambridge.arm.com> (raw)
In-Reply-To: <464e07ab-797e-971a-0839-5fd55e3e2ad3@huawei.com>

On Mon, Sep 17, 2018 at 03:42:32PM +0100, John Garry wrote:
> - dead e-mail addresses (Zhichang, Gabriele)
> 
> On 13/09/2018 13:48, Andrew Murray wrote:
> 
> Hi Andrew,
> 
> > The !CONFIG_GENERIC_IOMAP version of ioport_map uses MMIO_UPPER_LIMIT to
> > prevent users from making I/O accesses outside the expected I/O range -
> > however it erroneously treats MMIO_UPPER_LIMIT as a mask which is
> > contradictory to its other users.
> > 
> > The introduction of CONFIG_INDIRECT_PIO, which subtracts an arbitrary
> > amount from IO_SPACE_LIMIT to form MMIO_UPPER_LIMIT, results in ioport_map
> > mangling the given port rather than capping it.
> > 
> > We address this by aligning more closely with the CONFIG_GENERIC_IOMAP
> > implementation of ioport_map by using the comparison operator and
> > returning NULL where the port exceeds MMIO_UPPER_LIMIT. Though note that
> > we preserve the existing behavior of masking with IO_SPACE_LIMIT such that
> > we don't break existing buggy drivers that somehow rely on this masking.
> 
> I wouldn't say any drivers rely on this - for the only device driver which
> uses the "Indirect" IO space region above MMIO_UPPER_LIMIT (HiSilicon LPC),
> no child device driver for that host uses ioport_map() [those being ipmi si
> and 8250 generic+of drivers].

I was really referring to the existing !CONFIG_GENERIC_IOMAP && 
!CONFIG_INDIRECT_PIO use cases where there may be drivers (however unlikely)
that provide ioport_map an incorrect address which, due to the masking, gets
converted into a valid address. Returning NULL for these would result in new
run-time errors therefore it seemed safer to change this to support the new
"indirect IO" whilst not breaking existing bad drivers.

A more correct implementation would always return NULL if
port > IO_SPACE_LIMIT - it would fully align it with the CONFIG_GENERIC_IOMAP
implementation - in my view these two implementations should behave the same
with respect to error handling - at the moment they don't.


> 
> Regardless of that, it seems better to return NULL when the port is
> out-of-range, rather than masking it.
> 
> Cheers
> 
> > 
> > Fixes: 5745392e0c2b ("PCI: Apply the new generic I/O management on PCI IO hosts")
> > Reported-by: Will Deacon <will.deacon@arm.com>
> > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> 
> Reviewed-by: John Garry <john.garry@huawei.com>

Thanks for the review.

Andrew Murray

> 
> > ---
> >  include/asm-generic/io.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> > index 66d1d45..d356f80 100644
> > --- a/include/asm-generic/io.h
> > +++ b/include/asm-generic/io.h
> > @@ -1026,7 +1026,8 @@ static inline void __iomem *ioremap_wt(phys_addr_t offset, size_t size)
> >  #define ioport_map ioport_map
> >  static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
> >  {
> > -	return PCI_IOBASE + (port & MMIO_UPPER_LIMIT);
> > +	port &= IO_SPACE_LIMIT;
> > +	return (port > MMIO_UPPER_LIMIT) ? NULL : PCI_IOBASE + port;
> >  }
> >  #endif
> > 
> > 
> 
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: andrew.murray@arm.com (Andrew Murray)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] asm-generic: io: Fix ioport_map() for !CONFIG_GENERIC_IOMAP && CONFIG_INDIRECT_PIO
Date: Mon, 17 Sep 2018 16:19:17 +0100	[thread overview]
Message-ID: <20180917151917.GB5390@e119886-lin.cambridge.arm.com> (raw)
In-Reply-To: <464e07ab-797e-971a-0839-5fd55e3e2ad3@huawei.com>

On Mon, Sep 17, 2018 at 03:42:32PM +0100, John Garry wrote:
> - dead e-mail addresses (Zhichang, Gabriele)
> 
> On 13/09/2018 13:48, Andrew Murray wrote:
> 
> Hi Andrew,
> 
> > The !CONFIG_GENERIC_IOMAP version of ioport_map uses MMIO_UPPER_LIMIT to
> > prevent users from making I/O accesses outside the expected I/O range -
> > however it erroneously treats MMIO_UPPER_LIMIT as a mask which is
> > contradictory to its other users.
> > 
> > The introduction of CONFIG_INDIRECT_PIO, which subtracts an arbitrary
> > amount from IO_SPACE_LIMIT to form MMIO_UPPER_LIMIT, results in ioport_map
> > mangling the given port rather than capping it.
> > 
> > We address this by aligning more closely with the CONFIG_GENERIC_IOMAP
> > implementation of ioport_map by using the comparison operator and
> > returning NULL where the port exceeds MMIO_UPPER_LIMIT. Though note that
> > we preserve the existing behavior of masking with IO_SPACE_LIMIT such that
> > we don't break existing buggy drivers that somehow rely on this masking.
> 
> I wouldn't say any drivers rely on this - for the only device driver which
> uses the "Indirect" IO space region above MMIO_UPPER_LIMIT (HiSilicon LPC),
> no child device driver for that host uses ioport_map() [those being ipmi si
> and 8250 generic+of drivers].

I was really referring to the existing !CONFIG_GENERIC_IOMAP && 
!CONFIG_INDIRECT_PIO use cases where there may be drivers (however unlikely)
that provide ioport_map an incorrect address which, due to the masking, gets
converted into a valid address. Returning NULL for these would result in new
run-time errors therefore it seemed safer to change this to support the new
"indirect IO" whilst not breaking existing bad drivers.

A more correct implementation would always return NULL if
port > IO_SPACE_LIMIT - it would fully align it with the CONFIG_GENERIC_IOMAP
implementation - in my view these two implementations should behave the same
with respect to error handling - at the moment they don't.


> 
> Regardless of that, it seems better to return NULL when the port is
> out-of-range, rather than masking it.
> 
> Cheers
> 
> > 
> > Fixes: 5745392e0c2b ("PCI: Apply the new generic I/O management on PCI IO hosts")
> > Reported-by: Will Deacon <will.deacon@arm.com>
> > Signed-off-by: Andrew Murray <andrew.murray@arm.com>
> 
> Reviewed-by: John Garry <john.garry@huawei.com>

Thanks for the review.

Andrew Murray

> 
> > ---
> >  include/asm-generic/io.h | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/asm-generic/io.h b/include/asm-generic/io.h
> > index 66d1d45..d356f80 100644
> > --- a/include/asm-generic/io.h
> > +++ b/include/asm-generic/io.h
> > @@ -1026,7 +1026,8 @@ static inline void __iomem *ioremap_wt(phys_addr_t offset, size_t size)
> >  #define ioport_map ioport_map
> >  static inline void __iomem *ioport_map(unsigned long port, unsigned int nr)
> >  {
> > -	return PCI_IOBASE + (port & MMIO_UPPER_LIMIT);
> > +	port &= IO_SPACE_LIMIT;
> > +	return (port > MMIO_UPPER_LIMIT) ? NULL : PCI_IOBASE + port;
> >  }
> >  #endif
> > 
> > 
> 
> 

  reply	other threads:[~2018-09-17 15:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-13 12:48 [PATCH] asm-generic: io: Fix ioport_map() for !CONFIG_GENERIC_IOMAP && CONFIG_INDIRECT_PIO Andrew Murray
2018-09-13 12:48 ` Andrew Murray
2018-09-13 12:48 ` Andrew Murray
2018-09-13 13:02 ` Will Deacon
2018-09-13 13:02   ` Will Deacon
2018-09-13 13:02   ` Will Deacon
2018-09-13 14:00 ` Arnd Bergmann
2018-09-13 14:00   ` Arnd Bergmann
2018-09-13 14:00   ` Arnd Bergmann
2018-09-13 17:38   ` Will Deacon
2018-09-13 17:38     ` Will Deacon
2018-09-13 17:38     ` Will Deacon
2018-09-17 14:42 ` John Garry
2018-09-17 14:42   ` John Garry
2018-09-17 14:42   ` John Garry
2018-09-17 15:19   ` Andrew Murray [this message]
2018-09-17 15:19     ` Andrew Murray
2018-09-17 15:19     ` Andrew Murray

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=20180917151917.GB5390@e119886-lin.cambridge.arm.com \
    --to=andrew.murray@arm.com \
    --cc=andy.shevchenko@gmail.com \
    --cc=arnd@arndb.de \
    --cc=bhelgaas@google.com \
    --cc=dann.frazier@canonical.com \
    --cc=jean-philippe.brucker@arm.com \
    --cc=john.garry@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=suzuki.poulose@arm.com \
    --cc=will.deacon@arm.com \
    /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.