From: Paul Moore <[EMAIL PROTECTED]>
Date: Thu, 3 Jan 2008 22:19:03 -0500
> > Perhaps move the skb->cloned = 1 to just after n->cloned = 1
> > or
> > skb->cloned = n->cloned = 1;
> > or maybe
> > skb->cloned = 1;
> > C(cloned);
>
> I thought about that, but I kinda like how the parent
On Thursday 03 January 2008 6:40:07 pm Joe Perches wrote:
> On Thu, 2008-01-03 at 18:13 -0500, Paul Moore wrote:
> > static struct sk_buff *__skb_clone(struct sk_buff *n, struct sk_buff
> > *skb)
> > {
> > #define C(x) n->x = skb->x
> >
> > n->next = n->prev = NULL;
> > n->sk = NULL;
> >
On Thu, 2008-01-03 at 18:13 -0500, Paul Moore wrote:
> static struct sk_buff *__skb_clone(struct sk_buff *n, struct sk_buff
> *skb)
> {
> #define C(x) n->x = skb->x
>
> n->next = n->prev = NULL;
> n->sk = NULL;
> __copy_skb_header(n, skb);
>
> C(len);
> C(data_len);
From: Paul Moore <[EMAIL PROTECTED]>
Date: Thu, 3 Jan 2008 18:13:57 -0500
> On Thursday 03 January 2008 6:05:18 pm David Miller wrote:
> > From: Paul Moore <[EMAIL PROTECTED]>
> > Date: Thu, 3 Jan 2008 16:20:06 -0500
> >
> > > On Thursday 03 January 2008 4:13:12 pm Jarek Poplawski wrote:
> > > > O
On Thursday 03 January 2008 6:05:18 pm David Miller wrote:
> From: Paul Moore <[EMAIL PROTECTED]>
> Date: Thu, 3 Jan 2008 16:20:06 -0500
>
> > On Thursday 03 January 2008 4:13:12 pm Jarek Poplawski wrote:
> > > On Thu, Jan 03, 2008 at 11:15:34AM -0500, Paul Moore wrote:
> > > ...
> > >
> > > > Whil
From: Paul Moore <[EMAIL PROTECTED]>
Date: Thu, 3 Jan 2008 16:20:06 -0500
> On Thursday 03 January 2008 4:13:12 pm Jarek Poplawski wrote:
> > On Thu, Jan 03, 2008 at 11:15:34AM -0500, Paul Moore wrote:
> > ...
> >
> > > While I'm at it, is there some reason for this #define in
> > > __skb_clone()?
On Thu, Jan 03, 2008 at 11:06:08PM +0100, Jarek Poplawski wrote:
...
> I'm not macros fan in general: just yesterday I've cursed a bit at some
> guy (I forgot the name...), who gave all these "meaningful" names to
> macros in linux/pkt_cls.h. But, maybe after some time I'll start to
> defend them a
On Thu, Jan 03, 2008 at 04:20:06PM -0500, Paul Moore wrote:
...
> For me personally, I would argue the readability bit. Whenever I see a
> function/macro call I have to go find the function/macro definition
> before I can understand what it is doing. Granted, the macro is
> defined "local" to
On Thursday 03 January 2008 4:13:12 pm Jarek Poplawski wrote:
> On Thu, Jan 03, 2008 at 11:15:34AM -0500, Paul Moore wrote:
> ...
>
> > While I'm at it, is there some reason for this #define in
> > __skb_clone()?
> >
> > #define C(x) n->x = skb->x
> >
> > ... it seems kinda silly to me and I tend
On Thu, Jan 03, 2008 at 11:15:34AM -0500, Paul Moore wrote:
...
> While I'm at it, is there some reason for this #define in __skb_clone()?
>
> #define C(x) n->x = skb->x
>
> ... it seems kinda silly to me and I tend to think the code would be
> better without it.
IMHO, if there are a lot of th
On Thursday 03 January 2008 6:23:22 am jamal wrote:
> On Thu, 2008-03-01 at 10:58 +0100, Jarek Poplawski wrote:
> > On 02-01-2008 17:01, Paul Moore wrote:
> > > This patch is needed by some of the labeled networking changes
> > > proposed for 2.6.25, does anyone have any objections?
> >
> > Probabl
On Thursday 03 January 2008 6:23:22 am jamal wrote:
> On Thu, 2008-03-01 at 10:58 +0100, Jarek Poplawski wrote:
> > On 02-01-2008 17:01, Paul Moore wrote:
> > > This patch is needed by some of the labeled networking changes proposed
> > > for 2.6.25, does anyone have any objections?
> >
> > Probabl
On Thu, 2008-03-01 at 10:58 +0100, Jarek Poplawski wrote:
> On 02-01-2008 17:01, Paul Moore wrote:
> > This patch is needed by some of the labeled networking changes proposed for
> > 2.6.25, does anyone have any objections?
>
> Probably Jamal could be the most interested (added to CC):
>
Gracia
On 02-01-2008 17:01, Paul Moore wrote:
> When sk_buffs are cloned the iif field of the new, cloned packet is neither
> zeroed out or copied from the existing sk_buff. The result is that the newly
> cloned sk_buff has garbage in the iif field which is a Bad Thing. This patch
> fixes this problem b
When sk_buffs are cloned the iif field of the new, cloned packet is neither
zeroed out or copied from the existing sk_buff. The result is that the newly
cloned sk_buff has garbage in the iif field which is a Bad Thing. This patch
fixes this problem by copying the iif field along with the other sk
15 matches
Mail list logo
