All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: David Miller <davem@davemloft.net>
Cc: kaber@trash.net, netdev@vger.kernel.org, markmc@redhat.com
Subject: Re: [PATCH V2 net-next-2.6] net: relax dst refcnt in input path
Date: Fri, 07 Aug 2009 07:05:38 +0200	[thread overview]
Message-ID: <4A7BB622.2070007@gmail.com> (raw)
In-Reply-To: <20090806.133518.263376332.davem@davemloft.net>

David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 22 Jul 2009 17:40:06 +0200
> 
>> [PATCH net-next-2.6] net: relax dst refcnt in input path
> 
> 
> Two things:
> 
> 1) Don't use a boolean name like "noref" it results in using
>    double-negatives in one's mind while trying to read and understand
>    the code.
> 
>    Call these arguments "need_ref" or something like that.
> 
>    Also, use "bool" type.

Sure

> 
> 2) I wonder about this:
> 
>> @@ -1700,9 +1700,15 @@ int dev_hard_start_xmit(struct sk_buff *skb, struct net_device *dev,
>>  		 * If device doesnt need skb->dst, release it right now while
>>  		 * its hot in this cpu cache
>>  		 */
>> -		if (dev->priv_flags & IFF_XMIT_DST_RELEASE)
>> -			skb_dst_drop(skb);
>> -
>> +		if (skb_dst(skb)) {
>> +			if (dev->priv_flags & IFF_XMIT_DST_RELEASE)
>> +				skb_dst_drop(skb);
>> +			else
>> +				/*
>> +				 * make sure dst was refcounted by caller
>> +				 */
>> +				WARN_ON(!(skb->_skb_dst & SKB_DST_REFTAKEN));
>> +		}
>>  		rc = ops->ndo_start_xmit(skb, dev);
>>  		if (rc == NETDEV_TX_OK)
> 
> So, won't this warning trigger if we are forwarding to a device that
> does not set IFF_XMIT_DST_RELEASE?

If this device has a queue, we do a skb_dst_force() in dev_queue_xmit()

> 
> If I understand things correctly, in IPv4 when we're not delivering to
> a socket, we don't take a reference.

yes, that would be the trick

> 
> We'll get here from the forwarding path with a DST, and the target TX
> device has IFF_XMIT_DST_RELEASE clear, the WARN_ON above will trigger.

I added this warning to make sure I called skb_dst_force(skb)
from dev_queue_xmit() if device has a queue (packet might be queued
and thus escape from rcu lock section)

I suppose I should also skb_dst_force() if device has no queue and
has IFF_XMIT_DST_RELEASE cleared. Or should audit all these devices
and insert the skb_dst_force() if the packet must be queued in a driver queue,
and its dst needed later. 

I'll respin patch anyway since commit bbd8a0d3a3b65d341437f8b99c828fa5cc29c739
(net: Avoid enqueuing skb for default qdiscs)
changed too many things, when I'll come back from vacations in two weeks.

Or if you prefer, I might submit it today (my vacations start tomorrow), but
please dont apply it while I cannot react to any bug report :)

Thanks a lot

  reply	other threads:[~2009-08-07  5:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-21 20:07 [PATCH net-next-2.6] net: relax dst refcnt in input path Eric Dumazet
2009-07-22 12:22 ` [PATCH V2 " Eric Dumazet
2009-07-22 12:40   ` Patrick McHardy
2009-07-22 15:40     ` Eric Dumazet
2009-08-06 20:35       ` David Miller
2009-08-07  5:05         ` Eric Dumazet [this message]
2009-08-07  5:09           ` David Miller

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=4A7BB622.2070007@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=davem@davemloft.net \
    --cc=kaber@trash.net \
    --cc=markmc@redhat.com \
    --cc=netdev@vger.kernel.org \
    /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.