netdev - Re: Genetlink per cmd policies

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:   Thu, 1 Oct 2020 08:50:47 -0700
From:   Jakub Kicinski <kuba@...nel.org>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Johannes Berg <johannes@...solutions.net>,
        Jiri Pirko <jiri@...nulli.us>,
        Michal Kubecek <mkubecek@...e.cz>, dsahern@...nel.org,
        pablo@...filter.org, netdev@...r.kernel.org
Subject: Re: Genetlink per cmd policies

On Thu, 1 Oct 2020 03:53:23 +0200 Andrew Lunn wrote:
> On Wed, Sep 30, 2020 at 05:23:17PM -0700, Jakub Kicinski wrote:
> > On Thu, 1 Oct 2020 01:38:17 +0200 Andrew Lunn wrote:  
> > > > > > +static void genl_op_from_full(const struct genl_family *family,
> > > > > > +			      unsigned int i, struct genl_ops *op)
> > > > > > +{
> > > > > > +	memcpy(op, &family->ops[i], sizeof(*op));      
> > > > > 
> > > > > What's wrong with struct assignment? :)
> > > > > 
> > > > > 	*op = family->ops[i];    
> > > > 
> > > > Code size :)
> > > > 
> > > >    text	   data	    bss	    dec	    hex
> > > >   22657	   3590	     64	  26311	   66c7	memcpy
> > > >   23103	   3590	     64	  26757	   6885	struct    
> > > 
> > > You might want to show that to the compiler people. Did you look at
> > > the assembly?  
> > 
> > Somewhere along the line I lost the ability to decipher compiler code :(  
> 
> Yah, Z80 and 6809 i could sometimes just read the byte codes. That has
> long gone. I tend to read ARM assembly now a days being mostly in the
> embedded world.
> 
> So the memcpy version just calls memcpy by the looks of it. I thought
> it might of inlined it, but it has not. Maybe because of the -Os.
> 
> The struct assignment is interesting because it appears to be calling
> three functions to do the work. I wonder if it is avoiding copying the
> padding in the structure?
> 
> But still, that does not explain an extra 400 bytes in the text
> segment.

FWIW the 400 was without the -Os with -Os it's more like 50. So I'll
just go for it and do the struct assignment.