All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Townsend <martin.townsend@xsilon.com>
To: Alexander Aring <alex.aring@gmail.com>,
	Martin Townsend <mtownsend1973@gmail.com>
Cc: 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 11:04:13 +0100	[thread overview]
Message-ID: <54180B1D.7090602@xsilon.com> (raw)
In-Reply-To: <20140916065703.GA1244@omega>

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);
		}
	rcu_read_unlock();

	consume_skb(skb);

	return stat;
}


 what are your thoughts?

-Martin.


On 16/09/14 07:57, Alexander Aring wrote:
>
> --- snap
>
> Ignore the below one, I will only note about this... that we don't
> forget that.
>
> This code should be a generic function for increasing headroom for
> decompressing headers (IPv6, next hdr's). Still issues with
> consume_skb/kfree_skb here.
>
>
> +	if (stat < 0) {
> +		kfree_skb(skb);
> +		stat = NET_RX_DROP;
> +	} else {
> +		consume_skb(skb);
> +	}
> This basically works now, but it confuse developers.
>
> Look how stat is initzialed.
> There is mixed errno and NET_RX_FOO handling here. Which is part of the
> complete error handling mess. And correct freeing of skb's required a
> correct error handling.
>
> The function looks now like this:
>
>         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) {
>                                 stat = -ENOMEM;
> Simple assign stat = NET_RX_DROP.
>                                 break;
>                         }
>
>                         skb_cp->dev = entry->ldev;
>                         stat = netif_rx(skb_cp);
>                 }
>         rcu_read_unlock();          
>         
>         if (stat < 0) {
> remove brackets and check on NET_RX_DROP. or vice versa.
>                 kfree_skb(skb);
>                 stat = NET_RX_DROP;
>         } else {                
>                 consume_skb(skb);
>         }
>         return stat;
>
> Now if the list is empty we check if (stat < 0) with a NET_RX_FOO stuff,
> we should avoid that. I mean the current situation is because somebody
> mixed this stuff and that's why we have this now.
>
> Another developers look of some code (that's what I did) and see, aaah
> returning NET_RX_FOO so we can check on it, but at this situation he
> need to think a little bit more what it is the correct handline because
> there is still some errno conversion.
>
>>  	return stat;
>>  }
>>  

  parent reply	other threads:[~2014-09-16 10:04 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 [this message]
2014-09-16 10:17       ` Alexander Aring
2014-09-16 10:28         ` Martin Townsend
2014-09-16 10:39           ` Alexander Aring
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=54180B1D.7090602@xsilon.com \
    --to=martin.townsend@xsilon.com \
    --cc=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=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 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.