linux-kernel - Re: [PATCH net-next v2] net: phy: Maintain MDIO device and bus statistics

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]

Date:   Wed, 15 Jan 2020 16:01:35 -0800
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, cphealy@...il.com,
        rmk+kernel@...linux.org.uk, Heiner Kallweit <hkallweit1@...il.com>,
        "David S. Miller" <davem@...emloft.net>,
        open list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v2] net: phy: Maintain MDIO device and bus
 statistics

Hi Andrew,

On 1/15/20 3:53 PM, Andrew Lunn wrote:
>> +#define MDIO_BUS_STATS_ADDR_ATTR(field, addr, file)			\
>> +static ssize_t mdio_bus_##field##_##addr##_show(struct device *dev,	\
>> +						struct device_attribute *attr, \
>> +						char *buf)		\
>> +{									\
>> +	struct mii_bus *bus = to_mii_bus(dev);				\
>> +	return mdio_bus_stats_##field##_show(&bus->stats[addr], buf);	\
>> +}									\
> 
> Hi Florian
> 
> Lots of Macro magic here. But it is reasonably understandable.
> However, the compiler is maybe not doing the best of jobs:
> 
> 00000064 l     F .text	00000030 mdio_bus_reads_31_show
> 00000094 l     F .text	00000030 mdio_bus_reads_30_show
> 000000c4 l     F .text	00000030 mdio_bus_reads_29_show
> 000000f4 l     F .text	00000030 mdio_bus_reads_28_show
> 00000124 l     F .text	00000030 mdio_bus_reads_27_show
> 00000154 l     F .text	00000030 mdio_bus_reads_26_show
> 00000184 l     F .text	00000030 mdio_bus_reads_25_show
> 000001b4 l     F .text	00000034 mdio_bus_reads_24_show
> 000001e8 l     F .text	00000034 mdio_bus_reads_23_show
> 0000021c l     F .text	00000034 mdio_bus_reads_22_show
> 00000250 l     F .text	00000034 mdio_bus_reads_21_show
> 00000284 l     F .text	00000034 mdio_bus_reads_20_show
> 000002b8 l     F .text	00000034 mdio_bus_reads_19_show
> 000002ec l     F .text	00000034 mdio_bus_reads_18_show
> 00000320 l     F .text	00000034 mdio_bus_reads_17_show
> 00000354 l     F .text	00000034 mdio_bus_reads_16_show
> 00000388 l     F .text	00000034 mdio_bus_reads_15_show
> 000003bc l     F .text	00000034 mdio_bus_reads_14_show
> 000003f0 l     F .text	00000034 mdio_bus_reads_13_show
> 00000424 l     F .text	00000034 mdio_bus_reads_12_show
> 00000458 l     F .text	00000034 mdio_bus_reads_11_show
> 0000048c l     F .text	00000034 mdio_bus_reads_10_show
> 000004c0 l     F .text	00000034 mdio_bus_reads_9_show
> 000004f4 l     F .text	00000034 mdio_bus_reads_8_show
> 00000528 l     F .text	00000034 mdio_bus_reads_7_show
> 0000055c l     F .text	00000034 mdio_bus_reads_6_show
> 00000590 l     F .text	00000034 mdio_bus_reads_5_show
> 000005c4 l     F .text	00000034 mdio_bus_reads_4_show
> 000005f8 l     F .text	00000034 mdio_bus_reads_3_show
> 0000062c l     F .text	00000034 mdio_bus_reads_2_show
> 00000660 l     F .text	00000034 mdio_bus_reads_1_show
> 00000694 l     F .text	00000034 mdio_bus_reads_0_show
> 
> It appears to be inlining everything, so end up with lots of
> functions, and they are not tiny.
> 
> I'm wondering if we can get ride of this per address
> reads/write/transfer function. Could you stuff the addr into var of
> struct dev_ext_attribute?

That is a great suggestion, thanks! This should reduce the number of
those _show functions, expect v3 soon.
-- 
Florian