Re: [PATCH v4 0/2] mm/highmem: make kmap cache coloring aware

[David Daney]

On 08/25/2014 07:41 PM, Joshua Kinard wrote:
> On 08/25/2014 20:36, David Daney wrote:
> > On 08/25/2014 04:55 PM, Joshua Kinard wrote:
> > > On 08/25/2014 13:16, Ralf Baechle wrote:
> > > > On Sat, Aug 02, 2014 at 05:11:37AM +0400, Max Filippov wrote:
> > > >
> > > > > this series adds mapping color control to the generic kmap code, allowing
> > > > > architectures with aliasing VIPT cache to use high memory. There's also
> > > > > use example of this new interface by xtensa.
> > > >
> > > > I haven't actually ported this to MIPS but it certainly appears to be
> > > > the right framework to get highmem aliases handled on MIPS, too.
> > > >
> > > > Though I still consider increasing PAGE_SIZE to 16k the preferable
> > > > solution because it will entirly do away with cache aliases.
> > >
> > > Won't setting PAGE_SIZE to 16k break some existing userlands (o32)?  I use a
> > > 4k PAGE_SIZE because the last few times I've tried 16k or 64k, init won't
> > > load (SIGSEGVs or such, which panicks the kernel).
> >
> > It isn't supposed to break things.  Using "stock" toolchains should result
> > in executables that will run with any page size.
> >
> > In the past, some geniuses came up with some linker (ld) patches that, in
> > order to save a few KB of RAM, produced executables that ran only on 4K pages.
> >
> > There were some equally astute Debian emacs package maintainers that were
> > carrying emacs patches into Debian that would not work on non-4K page size
> > systems.
> >
> > That said, I think such thinking should be punished.  The punishment should
> > be to not have their software run when we select non-4K page sizes.  The
> > vast majority of prepackaged software runs just fine with a larger page size.
>
> Well, it does appear to mostly work now w/ 16k PAGE_SIZE.  The Octane booted
> into userland with just a couple of "illegal instruction" errors from 'rm'
> and 'mdadm'.  I wonder if that's tied to a hardcoded PAGE_SIZE somewhere.
> Have to dig around and find something that reproduces the problem on demand.

What does the output of "readelf -lW" look like for the failing 
programs?  If the "Offset" and "VirtAddr" constraints for the LOAD 
Program Headers are not possible to achieve with the selected PAGE_SIZE, 
you will see problems.  A "correct" toolchain will generate binaries 
that work with any PAGE_SIZE up to 64K.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/