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]
Message-ID: <CY4PR1201MB012086E453B1C8435535D44AA1310@CY4PR1201MB0120.namprd12.prod.outlook.com>
Date:   Tue, 7 May 2019 14:15:32 +0000
From:   Alexey Brodkin <Alexey.Brodkin@...opsys.com>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
CC:     Sasha Levin <sashal@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        "David Laight" <David.Laight@...lab.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Vineet Gupta <Vineet.Gupta1@...opsys.com>,
        Will Deacon <will.deacon@....com>,
        Sasha Levin <alexander.levin@...rosoft.com>
Subject: RE: [PATCH AUTOSEL 4.14 72/95] devres: Align data[] to
 ARCH_KMALLOC_MINALIGN

Hi Greg,

[snip]

> > > This is not needed in any of the older kernels, despite what the stable@
> > > line said, as it ends up taking a lot of memory up for all other arches.
> > > That's why I only applied it to the one kernel version.  I'm betting
> > > that it will be eventually reverted when people notice it as well :)
> >
> > That very well might become the case but then we're back to the initial problem,
> > right? So maybe some other more future-proof solution should be implemented?
> 
> Possibly yes.
> 
> > See initially we discussed simple explicit 8-byte alignment which won't change
> > data layout for most of arches while fixing our issue on ARC but for some reason
> > people were not happy with that proposal and that's how we ended-up with what we
> > discuss here now.
> 
> I'm not disagreeing that this is a valid solution for you, I wasn't part
> of the original discussion, sorry.  Just that this probably isn't
> something that should be backported to older kernels at this point in
> time.

That's fine for now.

Then if it ever gets reverted in Linux tree hopefully I'll be CCed and
it will be enough time to come up with a better fix.

-Alexey

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ