All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Jakub Kicinski <kuba@kernel.org>
Cc: davem@davemloft.net, netdev@vger.kernel.org, hawk@kernel.org,
	syzbot+4c63f36709a642f801c5@syzkaller.appspotmail.com
Subject: Re: [RFC net-next] net: guard drivers against shared skbs
Date: Mon, 15 Nov 2021 09:59:56 -0800	[thread overview]
Message-ID: <d719cc02-7963-bdf9-b6cd-494022b5d361@gmail.com> (raw)
In-Reply-To: <20211115093512.63404c26@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com>



On 11/15/21 9:35 AM, Jakub Kicinski wrote:
> On Mon, 15 Nov 2021 08:56:10 -0800 Eric Dumazet wrote:
>> On 11/15/21 8:32 AM, Jakub Kicinski wrote:
>>> Commit d8873315065f ("net: add IFF_SKB_TX_SHARED flag to priv_flags")
>>> introduced IFF_SKB_TX_SHARED to protect drivers which are not ready
>>> for getting shared skbs from pktgen sending such frames.
>>>
>>> Some drivers dutifully clear the flag but most don't, even though
>>> they modify the skb or call skb helpers which expect private skbs.
>>>
>>> syzbot has also discovered more sources of shared skbs than just
>>> pktgen (e.g. llc).
>>>
>>> I think defaulting to opt-in is doing more harm than good, those
>>> who care about fast pktgen should inspect their drivers and opt-in.
>>> It's far too risky to enable this flag in ether_setup().
> 
>>> diff --git a/net/core/dev.c b/net/core/dev.c
>>> index 15ac064b5562..476a826bb4f0 100644
>>> --- a/net/core/dev.c
>>> +++ b/net/core/dev.c
>>> @@ -3661,6 +3661,10 @@ static struct sk_buff *validate_xmit_skb(struct sk_buff *skb, struct net_device
>>>  	if (unlikely(!skb))
>>>  		goto out_null;
>>>  
>>> +	if (unlikely(skb_shared(skb)) &&
>>> +	    !(dev->priv_flags & IFF_TX_SKB_SHARING))
>>> +		goto out_kfree_skb;  
>>
>> So this will break llc, right ?
> 
> Likely. I haven't checked why LLC thinks it's a good idea to send
> shared skbs, probably convenience.
> 
>> I am sad we are adding so much tests in fast path.
> 
> What's our general stance on shared skbs in the Tx path? If we think
> that it's okay maybe it's time to turn the BUG_ON(shared_skb)s in pskb
> functions into return -EINVALs?

Yes, I think that a WARN_ON_ONCE() should be enough to keep syzbot reports
from alerting us, while not crashing regular hosts.

> 
> The IFF_TX_SKB_SHARING flag is pretty toothless as it stands.
> 

skb_padto() needs to be replaced by something better.
so that skb can be cloned if needed.


static inline int skb_padto(struct sk_buff *skb, unsigned int len)

->

static inline struct sk_buff *skb_padto(struct sk_buff *skb, unsigned int len)
{
}

  reply	other threads:[~2021-11-15 19:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-15 16:32 [RFC net-next] net: guard drivers against shared skbs Jakub Kicinski
2021-11-15 16:56 ` Eric Dumazet
2021-11-15 17:35   ` Jakub Kicinski
2021-11-15 17:59     ` Eric Dumazet [this message]
2021-11-15 18:11       ` Jakub Kicinski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d719cc02-7963-bdf9-b6cd-494022b5d361@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=hawk@kernel.org \
    --cc=kuba@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=syzbot+4c63f36709a642f801c5@syzkaller.appspotmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.