From: Martin Townsend <martin.townsend@xsilon.com>
To: Alexander Aring <alex.aring@gmail.com>,
Jukka Rissanen <jukka.rissanen@linux.intel.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 v4 bluetooth] 6lowpan: fix incorrect return values in lowpan_rcv
Date: Tue, 16 Sep 2014 15:44:43 +0100 [thread overview]
Message-ID: <54184CDB.9050200@xsilon.com> (raw)
In-Reply-To: <20140916140459.GB6104@omega>
I would like to keep freeing skb's out of process_data as process_data will become something like iphc_decompress_hdr and it would be good if that's all it did. Otherwise I feel we are going to put a constraint on all future header decompression routines in that they must free the skb on error. I think it would be better to defer this so on error you might want to try something else with the skb, maybe not but at least the option is there.
So how about
struct sk_buff * ret_skb;
switch (skb->data[0] & 0xe0) {
case LOWPAN_DISPATCH_IPHC: /* ipv6 datagram */
ret_skb = process_data(skb, &hdr);
if (IS_ERR(ret_skb))
goto drop_skb;
else
skb = ret_skb;
break;
I know we currently have 3 calls to process_data so it will look fairly ugly in this patch but in my next patch to fix lowpan_rcv to handle uncompressed IPv6 packets that are fragmented there will only be one call to process_data so it won't look so bad. You could even wrap it in a macro but I'm not a fan of this as they can obfuscate the code a bit.
Thoughts?
- Martin.
On 16/09/14 15:05, Alexander Aring wrote:
> Hi Jukka and Martin,
>
> On Tue, Sep 16, 2014 at 04:52:50PM +0300, Jukka Rissanen wrote:
> ...
>> Great, your example clarified the issue nicely :)
>>
>> I would vote for option 2) but if it makes the code too ugly then 1) is
>> ok too.
>>
> I begin to have the feeling like there is a reason because there are
> different indicators for consume_skb, kfree_skb. Error or not error,
> because it's hard to implement it in some way to make a correct handling
> without using a pointer of pointer. A pointer of pointer always means also
> a unnecessary dereferencing (netdev people doesn't like unnecessary
> dereferencing stuff, takes too much time).
>
> That's why I vote also for option 2)... but we can also clarify this on
> the netdev mailinglist and ask other networking kernel hackers.
>
> - Alex
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wpan" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2014-09-16 14:44 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-16 11:01 [PATCH v4 bluetooth] Fix lowpan_rcv Martin Townsend
2014-09-16 11:01 ` [PATCH v4 bluetooth] 6lowpan: fix incorrect return values in lowpan_rcv Martin Townsend
2014-09-16 11:09 ` Martin Townsend
2014-09-16 11:36 ` Alexander Aring
2014-09-16 11:39 ` Martin Townsend
2014-09-16 11:48 ` Alexander Aring
2014-09-16 11:53 ` Alexander Aring
2014-09-16 12:02 ` Alexander Aring
2014-09-16 12:18 ` Alexander Aring
2014-09-16 12:26 ` Martin Townsend
2014-09-16 12:34 ` Alexander Aring
2014-09-16 12:40 ` Martin Townsend
2014-09-16 12:48 ` Alexander Aring
2014-09-16 13:20 ` Jukka Rissanen
2014-09-16 13:32 ` Alexander Aring
2014-09-16 13:52 ` Jukka Rissanen
2014-09-16 14:05 ` Alexander Aring
2014-09-16 14:44 ` Martin Townsend [this message]
2014-09-16 17:38 ` Alexander Aring
2014-09-16 18:57 ` Martin Townsend
2014-09-16 19:37 ` Alexander Aring
2014-09-16 19:53 ` Martin Townsend
2014-09-16 20:07 ` Alexander Aring
2014-09-16 20:19 ` Martin Townsend
2014-09-16 20:30 ` Alexander Aring
2014-09-25 5:55 ` Alexander Aring
2014-09-25 7:25 ` Martin Townsend
2014-09-25 7:31 ` Alexander Aring
2014-09-25 7:39 ` Alexander Aring
2014-09-16 19:38 ` Martin Townsend
-- strict thread matches above, loose matches on Subject: below --
2014-10-01 12:10 [PATCH v4 bluetooth] Fix lowpan_rcv Martin Townsend
2014-10-01 12:10 ` [PATCH v4 bluetooth] 6lowpan: fix incorrect return values in lowpan_rcv Martin Townsend
2014-10-01 12:42 ` Alexander Aring
2014-10-02 12:43 ` Alexander Aring
2014-10-05 17:50 ` Alexander Aring
2014-10-05 17:58 ` Alexander Aring
2014-10-05 18:03 ` Alexander Aring
2014-10-05 21:00 ` Martin Townsend
2014-10-06 7:12 ` Alexander Aring
2014-10-06 8:27 ` Martin Townsend
2014-10-06 8:50 ` Marcel Holtmann
2014-10-06 8:35 ` 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=54184CDB.9050200@xsilon.com \
--to=martin.townsend@xsilon.com \
--cc=alex.aring@gmail.com \
--cc=jukka.rissanen@linux.intel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).