netdev - Re: [PATCH net-next] tc: fix tc actions in case of shared skb

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: <55A41CE9.8050907@plumgrid.com>
Date:	Mon, 13 Jul 2015 13:17:45 -0700
From:	Alexei Starovoitov <ast@...mgrid.com>
To:	David Miller <davem@...emloft.net>
CC:	jhs@...atatu.com, daniel@...earbox.net, jiri@...nulli.us,
	netdev@...r.kernel.org
Subject: Re: [PATCH net-next] tc: fix tc actions in case of shared skb

On 7/13/15 1:04 PM, David Miller wrote:
> From: Alexei Starovoitov <ast@...mgrid.com>
> Date: Mon, 13 Jul 2015 12:47:42 -0700
>
>> In all normal cases skb->users == 1, but pktgen is using trick:
>> atomic_add(burst, &skb->users);
>> so when testing something like:
>
> You can want pktgen rx (which is the only buggy case as far as I can
> see, TX is fine) to run fast, but you must do so by abiding by the
> appropriate SKB sharing rules.
>
> You can't do an optimization in pktgen for RX processing that works
> "some of the time".  We have shared SKB rules for a reason.
>
> And I don't want to have to explain to someone in the future why that
> drop check is there, and have to tell them "because pktgen is broken
> and we decided to add a hack here rather than make pktgen send
> properly formed SKBs into the RX path"
>
> Ok?

in general all makes sense, but it is both RX and TX.
Without burst hack we cannot achieve line rate TX.
         atomic_add(burst, &pkt_dev->skb->users);
xmit_more:
         ret = netdev_start_xmit(pkt_dev->skb, odev, txq, --burst > 0);

in pktgen we check that driver can work with users > 1 via:
pkt_dev->odev->priv_flags & IFF_TX_SKB_SHARING

so real hw driver are mostly ready for users > 1, it's only
few tc actions struggle a bit.
We cannot check tc actions from pktgen, since they can be added
dynamically.
So I see three options:
1 get rid of burst hack for both RX and TX in pktgen (kills performance)
2 add unlikely(skb_shread) check to few tc actions
3 do nothing

I think 2 isn't that bad after all if properly documented with
"because pktgen is doing this hack for performance" ?

I'm fine with 3 too, since the whole pktgen business is for root
and for kernel hackers who suppose to know what they're doing.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html