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: <20210123132626.GA22662@hoboy.vegasvil.org>
Date:   Sat, 23 Jan 2021 05:26:26 -0800
From:   Richard Cochran <richardcochran@...il.com>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     Russell King - ARM Linux admin <linux@...linux.org.uk>,
        netdev@...r.kernel.org, Andrew Lunn <andrew@...n.ch>,
        Florian Fainelli <f.fainelli@...il.com>,
        Marc Zyngier <maz@...nel.org>, linux-kernel@...r.kernel.org,
        Krzysztof Kozlowski <krzk@...nel.org>,
        Vivien Didelot <vivien.didelot@...il.com>,
        Dinh Nguyen <dinguyen@...nel.org>,
        Brandon Streiff <brandon.streiff@...com>,
        Olof Johansson <olof@...om.net>,
        Vladimir Oltean <olteanv@...il.com>,
        David Miller <davem@...emloft.net>,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH net 2/4] net: mvpp2: Remove unneeded Kconfig dependency.

On Fri, Jan 22, 2021 at 06:14:44PM -0800, Jakub Kicinski wrote:

> (I would put it in net-next tho, given the above this at most a space
> optimization.)

It isn't just about space but also time.  The reason why I targeted
net and not net-next was that NETWORK_PHY_TIMESTAMPING activates a
function call to skb_clone_tx_timestamp() for every transmitted frame.

	static inline void skb_tx_timestamp(struct sk_buff *skb)
	{
		skb_clone_tx_timestamp(skb);
		if (skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP)
			skb_tstamp_tx(skb, NULL);
	}

In the abscence of a PHY time stamping device, the check for its
presence inside of skb_clone_tx_timestamp() will of course fail, but
this still incurs the cost of the call on every transmitted skb.

Similarly netif_receive_skb() futilely calls skb_defer_rx_timestamp()
on every received skb.

I would argue that most users don't want this option activated by
accident.

(And yes, we could avoid the functions call by moving the check
outside of the global functions and inline to the call sites.  I'll be
sure to have that in the shiny new improved scheme under discussion.)

Thanks,
Richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ