Linux IEEE 802.15.4 and 6LoWPAN development
 help / color / mirror / Atom feed
From: Alexander Aring <alex.aring@gmail.com>
To: Martin Townsend <martin.townsend@xsilon.com>
Cc: Martin Townsend <mtownsend1973@gmail.com>,
	linux-zigbee-devel@lists.sourceforge.net,
	linux-bluetooth@vger.kernel.org, linux-wpan@vger.kernel.org,
	marcel@holtmann.org
Subject: Re: [PATCH v3 bluetooth] 6lowpan: fix incorrect return values in lowpan_rcv
Date: Tue, 16 Sep 2014 12:39:25 +0200	[thread overview]
Message-ID: <20140916103923.GB4969@omega> (raw)
In-Reply-To: <541810B6.3010508@xsilon.com>

On Tue, Sep 16, 2014 at 11:28:06AM +0100, Martin Townsend wrote:
> 
> On 16/09/14 11:17, Alexander Aring wrote:
> > On Tue, Sep 16, 2014 at 11:04:13AM +0100, Martin Townsend wrote:
> >> Hi Alex,
> >>
> >> On the lowpan_give_skb_to_devices change.
> >>
> >> As we are iterating over a list of lowpan_devices and could potentially copy the skb more than once, what happens if the first device returns NET_RX_DROP and then the second time it return NET_RX_SUCCESS?  The stat variable is overwritten so stat only ever reflects the return value of netif_rx for the last device?
> >>
> >> Maybe it's better to completely remove the if else at the end and always consume the skb?  For the case whereskb_copy fails then we should kfree_skb,
> >> e.g.
> >>
> >> static int lowpan_give_skb_to_devices(struct sk_buff *skb,
> >> 				      struct net_device *dev)
> >> {
> >> 	struct lowpan_dev_record *entry;
> >> 	struct sk_buff *skb_cp;
> >> 	int stat = NET_RX_SUCCESS;
> >>
> >> 	rcu_read_lock();
> >> 	list_for_each_entry_rcu(entry, &lowpan_devices, list)
> >> 		if (lowpan_dev_info(entry->ldev)->real_dev == skb->dev) {
> >> 			skb_cp = skb_copy(skb, GFP_ATOMIC);
> >> 			if (!skb_cp) {
> >> 				kfree_skb(skb);
> >> 				rcu_read_unlock();
> >> 				return NET_RX_DROP;
> >> 			}
> >>
> >> 			skb_cp->dev = entry->ldev;
> >> 			stat = netif_rx(skb_cp);
> > here we should do a:
> >
> > if (stat == NET_RX_DROP)
> > 	kfree_skb(skb_cp);
> >
> > or? It doesn't deliver and then we "could" lost the pointer.
> Doesn't netif_rx always free the buffer?

yes, you are right. [0] Now other things makes more sense for me.
Thanks.

I mean there is another deliver function netif_receive_skb and on
comment always stand "Return values (usually ignored)", depends on
context what you need. But netif_rx in this context is right.

Here we should not ignore the return value, because we already are in
the packet layer (the packet layer func callback). The netif_receive_skb 
function we need for putting frames from the driver (some tasklet context)
into the packet layer.


[0] is some function which is called mainly after "netif_rx" function,
"netif_receive_skb" will call this function, too.

- Alex

[0] http://lxr.free-electrons.com/source/net/core/dev.c#L3280

  reply	other threads:[~2014-09-16 10:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-15 14:09 [PATCH v3 bluetooth] Fix lowpan_rcv Martin Townsend
2014-09-15 14:09 ` [PATCH v3 bluetooth] 6lowpan: fix incorrect return values in lowpan_rcv Martin Townsend
2014-09-16  6:57   ` Alexander Aring
2014-09-16  8:28     ` Martin Townsend
2014-09-16  9:06       ` Alexander Aring
2014-09-16  9:17         ` Alexander Aring
2014-09-16 10:04     ` Martin Townsend
2014-09-16 10:17       ` Alexander Aring
2014-09-16 10:28         ` Martin Townsend
2014-09-16 10:39           ` Alexander Aring [this message]
2014-09-16  7:04   ` Jukka Rissanen
2014-09-16  7:10     ` Alexander Aring
2014-09-16  8:32     ` Martin Townsend
  -- strict thread matches above, loose matches on Subject: below --
2014-09-15 14:08 [PATCH v2 bluetooth] Fix lowpan_rcv Martin Townsend
2014-09-15 14:08 ` [PATCH v3 bluetooth] 6lowpan: fix incorrect return values in lowpan_rcv Martin Townsend

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=20140916103923.GB4969@omega \
    --to=alex.aring@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=linux-wpan@vger.kernel.org \
    --cc=linux-zigbee-devel@lists.sourceforge.net \
    --cc=marcel@holtmann.org \
    --cc=martin.townsend@xsilon.com \
    --cc=mtownsend1973@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox