linux-kernel - Re: [less-CONFIG_NET 1/7] net: reorder filter code

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:   Wed, 6 Jun 2018 20:19:09 +0200
From:   Norbert Manthey <nmanthey@...zon.de>
To:     Willem de Bruijn <willemdebruijn.kernel@...il.com>
CC:     Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        "David S. Miller" <davem@...emloft.net>,
        "Network Development" <netdev@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [less-CONFIG_NET 1/7] net: reorder filter code

On 06/06/2018 06:33 PM, Willem de Bruijn wrote:
> On Wed, Jun 6, 2018 at 9:53 AM, Norbert Manthey <nmanthey@...zon.de> wrote:
>> This commit reorders the definition of functions and struct in the
>> file filter.c, such that in the next step we can easily cut the file
>> into a commonly used part, as well as a part that is only required in
>> case CONFIG_NET is actually set.
>>
>> This is part of the effort to split CONFIG_SECCOMP_FILTER and
>> CONFIG_NET.
>>
>> Signed-off-by: Norbert Manthey <nmanthey@...zon.de>
> Reordering patches like this and the flow-dissector patch in this
> series make cherry-picking fixes back to stable branches and
> and following code history with git blame harder.
>
Dear Willem,

I agree that this change makes cherry picking harder. When keeping the
order of the code, the following commits have to introduce many pairs
"#ifdef CONFIG_NET - #endif" and "#if defined(CONFIG_NET) || 
defined(CONFIG_SECCOMP_FILTER) #endif"
This is how I developed the commits, but then refactored for improved
readability.

From my experience, cherry picking changes from this variant is equally
difficult. A third alternative, splitting the files into separate files,
would force me to make current static definitions visible.

I am happy to go another route, if people insist that this is the better
way forward.

Best,
Norbert

Amazon Development Center Germany GmbH
Berlin - Dresden - Aachen
main office: Krausenstr. 38, 10117 Berlin
Geschaeftsfuehrer: Dr. Ralf Herbrich, Christian Schlaeger
Ust-ID: DE289237879
Eingetragen am Amtsgericht Charlottenburg HRB 149173 B