On Tue, Sep 16, 2014 at 09:19:58PM +0100, Martin Townsend wrote:
> Hi Alex,
>
> On 16/09/14 21:07, Alexander Aring wrote:
> >On Tue, Sep 16, 2014 at 08:53:06PM +0100, Martin Townsend wrote:
> >...
> >>>I make another c example, hopeful more correct than the last one:
> >>>
> >>>char *foo(char *skb
Hi Alex,
On 16/09/14 21:07, Alexander Aring wrote:
> On Tue, Sep 16, 2014 at 08:53:06PM +0100, Martin Townsend wrote:
> ...
>>> I make another c example, hopeful more correct than the last one:
>>>
>>> char *foo(char *skb)
>>> {
>>> char *new;
>>>
>>> if (some_error_before_consum
On Tue, Sep 16, 2014 at 08:53:06PM +0100, Martin Townsend wrote:
...
> >I make another c example, hopeful more correct than the last one:
> >
> >char *foo(char *skb)
> >{
> > char *new;
> >
> > if (some_error_before_consume)
> > return ERR_PTR(-EINVAL); /* here we ne
Hi Alex,
On 16/09/14 20:37, Alexander Aring wrote:
> On Tue, Sep 16, 2014 at 07:57:27PM +0100, Martin Townsend wrote:
>> Hi Alex,
>>
>> On 16/09/14 18:38, Alexander Aring wrote:
>>> Hi Martin,
>>>
>>> On Tue, Sep 16, 2014 at 03:44:43PM +0100, Martin Townsend wrote:
I would like to keep freein
Hi Alex,
Another idea that just occured to me is to use the control buffer (cb)
in the skb to store the (de)compress_status variable. This should be
possible as it is only valid for this layer. Then process_data (or
iphc_header_decompress as I like to think of it now) will only ever
return a
On Tue, Sep 16, 2014 at 07:57:27PM +0100, Martin Townsend wrote:
> Hi Alex,
>
> On 16/09/14 18:38, Alexander Aring wrote:
> >Hi Martin,
> >
> >On Tue, Sep 16, 2014 at 03:44:43PM +0100, Martin Townsend wrote:
> >>I would like to keep freeing skb's out of process_data as process_data will
> >>becom
Hi Alex,
On 16/09/14 18:38, Alexander Aring wrote:
> Hi Martin,
>
> On Tue, Sep 16, 2014 at 03:44:43PM +0100, Martin Townsend wrote:
>> 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
>> i
Hi Martin,
On Tue, Sep 16, 2014 at 03:44:43PM +0100, Martin Townsend wrote:
> 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
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.
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 ar
Hi Alex,
On ti, 2014-09-16 at 15:32 +0200, Alexander Aring wrote:
> Hi Jukka,
>
> On Tue, Sep 16, 2014 at 04:20:19PM +0300, Jukka Rissanen wrote:
> > Hi Alex,
> >
> > On ti, 2014-09-16 at 14:48 +0200, Alexander Aring wrote:
> > > Hi Martin,
> > >
> > > On Tue, Sep 16, 2014 at 01:40:24PM +0100,
Hi Jukka,
On Tue, Sep 16, 2014 at 04:20:19PM +0300, Jukka Rissanen wrote:
> Hi Alex,
>
> On ti, 2014-09-16 at 14:48 +0200, Alexander Aring wrote:
> > Hi Martin,
> >
> > On Tue, Sep 16, 2014 at 01:40:24PM +0100, Martin Townsend wrote:
> > ...
> > >
> > > Yes I see the problem now, maybe it's bet
Hi Alex,
On ti, 2014-09-16 at 14:48 +0200, Alexander Aring wrote:
> Hi Martin,
>
> On Tue, Sep 16, 2014 at 01:40:24PM +0100, Martin Townsend wrote:
> ...
> >
> > Yes I see the problem now, maybe it's better to revert back to skb_inout,
> > less chance of introducing bugs and then we have a well
Hi Martin,
On Tue, Sep 16, 2014 at 01:40:24PM +0100, Martin Townsend wrote:
...
>
> Yes I see the problem now, maybe it's better to revert back to skb_inout,
> less chance of introducing bugs and then we have a well defined return value.
>
No problem, for me it's okay, if this is okay for Jukk
On 16/09/14 13:34, Alexander Aring wrote:
> On Tue, Sep 16, 2014 at 01:26:19PM +0100, Martin Townsend wrote:
>> Hi Alex,
>>
>> On 16/09/14 13:18, Alexander Aring wrote:
>>> On Tue, Sep 16, 2014 at 02:02:47PM +0200, Alexander Aring wrote:
On Tue, Sep 16, 2014 at 01:53:57PM +0200, Alexander Ari
On Tue, Sep 16, 2014 at 01:26:19PM +0100, Martin Townsend wrote:
> Hi Alex,
>
> On 16/09/14 13:18, Alexander Aring wrote:
> > On Tue, Sep 16, 2014 at 02:02:47PM +0200, Alexander Aring wrote:
> >> On Tue, Sep 16, 2014 at 01:53:57PM +0200, Alexander Aring wrote:
> >>> On Tue, Sep 16, 2014 at 01:47:5
Hi Alex,
On 16/09/14 13:18, Alexander Aring wrote:
> On Tue, Sep 16, 2014 at 02:02:47PM +0200, Alexander Aring wrote:
>> On Tue, Sep 16, 2014 at 01:53:57PM +0200, Alexander Aring wrote:
>>> On Tue, Sep 16, 2014 at 01:47:59PM +0200, Alexander Aring wrote:
On Tue, Sep 16, 2014 at 12:39:11PM +01
On Tue, Sep 16, 2014 at 02:02:47PM +0200, Alexander Aring wrote:
> On Tue, Sep 16, 2014 at 01:53:57PM +0200, Alexander Aring wrote:
> > On Tue, Sep 16, 2014 at 01:47:59PM +0200, Alexander Aring wrote:
> > > On Tue, Sep 16, 2014 at 12:39:11PM +0100, Martin Townsend wrote:
> > > > Hi Alex,
> > > > On
On Tue, Sep 16, 2014 at 01:53:57PM +0200, Alexander Aring wrote:
> On Tue, Sep 16, 2014 at 01:47:59PM +0200, Alexander Aring wrote:
> > On Tue, Sep 16, 2014 at 12:39:11PM +0100, Martin Townsend wrote:
> > > Hi Alex,
> > > On 16/09/14 12:36, Alexander Aring wrote:
> > > > On Tue, Sep 16, 2014 at 12:
On Tue, Sep 16, 2014 at 01:47:59PM +0200, Alexander Aring wrote:
> On Tue, Sep 16, 2014 at 12:39:11PM +0100, Martin Townsend wrote:
> > Hi Alex,
> > On 16/09/14 12:36, Alexander Aring wrote:
> > > On Tue, Sep 16, 2014 at 12:01:59PM +0100, Martin Townsend wrote:
...
>
> and this also smells like si
On Tue, Sep 16, 2014 at 12:39:11PM +0100, Martin Townsend wrote:
> Hi Alex,
> On 16/09/14 12:36, Alexander Aring wrote:
> > On Tue, Sep 16, 2014 at 12:01:59PM +0100, Martin Townsend wrote:
> >> Currently there are a number of error paths in the lowpan_rcv function that
> >> free the skb before retu
Hi Alex,
On 16/09/14 12:36, Alexander Aring wrote:
> On Tue, Sep 16, 2014 at 12:01:59PM +0100, Martin Townsend wrote:
>> Currently there are a number of error paths in the lowpan_rcv function that
>> free the skb before returning, the patch simplifies the receive path by
>> ensuring that the skb is
On Tue, Sep 16, 2014 at 12:01:59PM +0100, Martin Townsend wrote:
> Currently there are a number of error paths in the lowpan_rcv function that
> free the skb before returning, the patch simplifies the receive path by
> ensuring that the skb is only freed from this function.
>
> Passing the skb fro
Just noticed a typo in the commit msg, refacored != refactored. I'll fix in v5
after further comments.
- Martin.
On 16/09/14 12:01, Martin Townsend wrote:
> Currently there are a number of error paths in the lowpan_rcv function that
> free the skb before returning, the patch simplifies the rece
Currently there are a number of error paths in the lowpan_rcv function that
free the skb before returning, the patch simplifies the receive path by
ensuring that the skb is only freed from this function.
Passing the skb from 6lowpan up to the higher layers is not a
function of IPHC. By moving it
This series aims to fix incorrect return values in lowpan_rcv
To achieve this it also refactors the receive path to
1) free skb only from lowpan_rcv and not functions that it calls
2) move skb delivery from IPHC
I have only compile tested the changes for bluetooth as I don't have any HW
availa
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_
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 th
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 th
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 s
On Tue, Sep 16, 2014 at 11:06:08AM +0200, Alexander Aring wrote:
...
> > Are you saying that skb->len needs setting here? or just that to do on the
> > fly decompression it's required?
> >
>
and I was wrong here, I mean we need the IPv6 header payload need to set
according "skb->len - sizeof(...
On Tue, Sep 16, 2014 at 09:28:10AM +0100, Martin Townsend wrote:
> Hi Alex,
>
> On 16/09/14 07:57, Alexander Aring wrote:
> > Hi Martin,
> >
> > On Mon, Sep 15, 2014 at 03:09:54PM +0100, Martin Townsend wrote:
> >> Currently there are a number of error paths in the lowpan_rcv function that
> >> fr
Hi Jukka,
On 16/09/14 08:04, Jukka Rissanen wrote:
> Hi Martin,
>
> On ma, 2014-09-15 at 15:09 +0100, Martin Townsend wrote:
>> Currently there are a number of error paths in the lowpan_rcv function that
>> free the skb before returning, the patch simplifies the receive path by
>> ensuring that th
Hi Alex,
On 16/09/14 07:57, Alexander Aring wrote:
> Hi Martin,
>
> On Mon, Sep 15, 2014 at 03:09:54PM +0100, Martin Townsend wrote:
>> Currently there are a number of error paths in the lowpan_rcv function that
>> free the skb before returning, the patch simplifies the receive path by
>> ensuring
On Tue, Sep 16, 2014 at 10:04:57AM +0300, Jukka Rissanen wrote:
> Hi Martin,
>
> On ma, 2014-09-15 at 15:09 +0100, Martin Townsend wrote:
> > Currently there are a number of error paths in the lowpan_rcv function that
> > free the skb before returning, the patch simplifies the receive path by
> >
Hi Martin,
On ma, 2014-09-15 at 15:09 +0100, Martin Townsend wrote:
> Currently there are a number of error paths in the lowpan_rcv function that
> free the skb before returning, the patch simplifies the receive path by
> ensuring that the skb is only freed from this function.
>
> Passing the skb
36 matches
Mail list logo
