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] [day] [month] [year] [list]
Message-ID: <26b2c5f7-87af-9507-98e4-d92bed8c3354@rasmusvillemoes.dk>
Date:   Thu, 2 May 2019 15:07:03 +0200
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Jeff Mahoney <jeffm@...e.com>, Arnd Bergmann <arnd@...db.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Darren Hart (VMware)" <dvhart@...radead.org>,
        Mattias Jacobsson <2pi@....nu>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] mod_devicetable.h: reduce sizeof(struct of_device_id) by
 80 bytes

On 02/05/2019 14.29, Jeff Mahoney wrote:
> On 5/2/19 5:41 AM, Rasmus Villemoes wrote:

>> But we cannot really know whether there is some userspace tool that
>> parses the .ko ELF objects the same way that file2alias does, doing
>> pattern matching on the symbol names etc. I cannot see why anybody would
>> _do_ that (the in-tree infrastructure already generates the
>> MODULE_ALIAS() from which modules.alias gets generated), but the only
>> way of knowing, I think, is to try to apply the patch and see if anybody
>> complains.
> 
> The size is part of the ABI, though.  module-init-tools has a copy of
> the same struct and uses that size to walk an array of of_device_id when
> a module as more than one.  If you shrink it, that will certainly break.

Urgh, yes, didn't know about module-init-tools. But it seems to be
abandoned? So does anybody actually use that with a modern kernel (there
seems to be many new structs in mod_devicetable.h that the last release
of module-init-tools doesn't know about)?

Oh well. If it's not deemed worth the risk to do a release with this
patch applied, I can always just add this to the list of trivial things
to do when asked to trim a custom kernel.

Rasmus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ