lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 9 May 2021 14:09:56 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Ansuel Smith <ansuelsmth@...il.com>
Cc:     stable@...r.kernel.org, Palmer Dabbelt <palmerdabbelt@...gle.com>,
        Luis Chamberlain <mcgrof@...nel.org>,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH] arm: Enlarge IO_SPACE_LIMIT needed for some SoC

On Sun, May 09, 2021 at 12:51:20AM +0200, Ansuel Smith wrote:
> On Sat, May 08, 2021 at 07:50:44PM +0100, Russell King - ARM Linux admin wrote:
> > On Sat, May 08, 2021 at 07:55:35PM +0200, Ansuel Smith wrote:
> > > Ipq8064 SoC requires larger IO_SPACE_LIMIT or second and third pci port
> > > fails to register the IO addresses and connected device doesn't work.
> > > 
> > > Cc: <stable@...r.kernel.org> # 4.9+
> > > Signed-off-by: Ansuel Smith <ansuelsmth@...il.com>
> > 
> > I don't see any consideration of whether this increase results in any
> > clashes with any other related areas. Also, there is no update of the
> > memory layout documentation.
> > 
> > The memory layout documentation says:
> > 
> > =============== =============== ===============================================
> > Start           End             Use
> > =============== =============== ===============================================
> > fee00000        feffffff        Mapping of PCI I/O space. This is a static
> >                                 mapping within the vmalloc space.
> > 
> > which means there's a maximum of 0x001fffff available. You are
> > increasing it's size from 0x000fffff to 0x00ffffff. This means it
> > expands from 0xfee00000 through to 0xffdfffff.
> > 
> > This conflicts with these entries:
> > 
> > ffc80000        ffefffff        Fixmap mapping region.  Addresses provided
> >                                 by fix_to_virt() will be located here.
> > 
> > ffc00000        ffc7ffff        Guard region
> > 
> > ff800000        ffbfffff        Permanent, fixed read-only mapping of the
> >                                 firmware provided DT blob
> > 
> > So, I have no option but to NAK this change. Sorry.
> > 
> > You can find this documentation in the "Documentation" subdirectory.
> > 
> > -- 
> > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
> 
> Hi,
> Thanks a lot for the review and sorry for the mess. Just to make sure I
> don't push a very wrong patch another time. ipq8064 require 0x300000 of
> IO space if all 3 lines are used. From what I can read in the
> documentation, the PCI I/O mapping section does have space and can be
> expanded to ff0fffff without causing collision. So I have to update that
> part and the IO_LIMIT to 0x2fffff. Tell me if I'm completely wrong and
> again, thanks for the review.

Well, an obvious question would be: do you really need that much IO
space? PCs have got away with 64K of IO space without having a problem
for years, so 64K per bus should be fine. If you have 3 buses, that
should be 3 * 64K or 192K.

I would bet in the normal circumstance that the IO space on every PCI
bus is very sparsely used, so using 1MiB per bus seems over the top.

That said, using 1MB each for three buses takes the top of the IO space
to 0xff100000, which shouldn't be a problem, assuming memory.rst is up
to date.

In any case, I really don't think such a change has anything to do with
stable kernels, so please drop that for your next submission.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ