sk_buff destructor in 2.2.18

sk_buff destructor in 2.2.18

[christophe barbé]

Hi all,

I'm trying to figure out how to use the destructor function in the skbuff
object. 
I've read (the source code and) the alan cox's article from linuxjournal
but it refers to linux 2.0.
Perhaps someone can tell me what's wrong in the following :

Normally the rx code of a network driver do the following code :
allocate a skbuff
	skb=dev_alloc_skb(length);
	if (skb==NULL) ...
fill data
	skb_put(skb,length);
	memcpy((void *)skb->data, buf,length);
end so on ...

In my case, I own the incomming buffer so I would like to use it directly
without copying data.
I've written a new allocation function.
And use the destructor to free my buffer (replacing it on a free list).

First I imagine something is wrong because the destructor is called before
kfree_skbmem() so If I don't lie to skb->cloned (I set it to 1), an
unexpected skb->head occured.
I think the destructor method is provided to free privates data not the
main data. But I can't see an another way to do it.

Secondly, When my destructor function is called, the cloned flag is already
set (and datarefp indicates also that data is referenced elsewhere).
When is a skbuff cloned?
Is there a way to avoid this?
Where can I register a function to free (= replace it in my list) the data
buffer?

Thank you,
Christophe

-- 
Christophe Barbé
Software Engineer - christophe.barbe@lineo.fr
Lineo France - Lineo High Availability Group
42-46, rue Médéric - 92110 Clichy - France
phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01
http://www.lineo.com

Re: sk_buff destructor in 2.2.18

[Andi Kleen]

On Wed, May 23, 2001 at 04:16:54PM +0200, christophe barbé wrote:
> Hi all,
> 
> I'm trying to figure out how to use the destructor function in the skbuff
> object. 
> I've read (the source code and) the alan cox's article from linuxjournal
> but it refers to linux 2.0.
> Perhaps someone can tell me what's wrong in the following :

You can't use the destructor; it is already used by the main stack for socket
memory management.

-Andi

Re: sk_buff destructor in 2.2.18

[christophe barbé]

It seems to not be the case, because my destructor is called.
Could you point me the code where you think this method is already used?

Thank you for your answer,
Christophe


On Wed, 23 May 2001 16:27:39 Andi Kleen wrote:
> On Wed, May 23, 2001 at 04:16:54PM +0200, christophe barbé wrote:
> > Hi all,
> > 
> > I'm trying to figure out how to use the destructor function in the
> skbuff
> > object. 
> > I've read (the source code and) the alan cox's article from
> linuxjournal
> > but it refers to linux 2.0.
> > Perhaps someone can tell me what's wrong in the following :
> 
> You can't use the destructor; it is already used by the main stack for
> socket
> memory management.
> 
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-- 
Christophe Barbé
Software Engineer - christophe.barbe@lineo.fr
Lineo France - Lineo High Availability Group
42-46, rue Médéric - 92110 Clichy - France
phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01
http://www.lineo.com

Re: sk_buff destructor in 2.2.18

[Andi Kleen]

On Wed, May 23, 2001 at 04:37:58PM +0200, christophe barbé wrote:
> It seems to not be the case, because my destructor is called.

It is called, but you overwrote the kernel destructor and therefore
broke the socket memory accounting completely; causing all kinds of 
problems.

> Could you point me the code where you think this method is already used?

net/core/sock.c


-Andi

Re: sk_buff destructor in 2.2.18

[christophe barbé]

I don't know about socket but I allocate myself the skbuff and I set the
destructor (and previously the pointer value is NULL). So I don't overwrite
a destructor.

I believe net/core/sock.c is not involved in my problem but I can be wrong.
What is worrying me is that I don't know who clones my skbuff and why.

To said everything, I know who clones my skbuff because it causes a oops
when it tries to free my buffer If I use my destructor.

Christophe

On Wed, 23 May 2001 16:40:36 Andi Kleen wrote:
> On Wed, May 23, 2001 at 04:37:58PM +0200, christophe barbé wrote:
> > It seems to not be the case, because my destructor is called.
> 
> It is called, but you overwrote the kernel destructor and therefore
> broke the socket memory accounting completely; causing all kinds of 
> problems.
> 
> > Could you point me the code where you think this method is already
> used?
> 
> net/core/sock.c
> 
> 
> -Andi
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-- 
Christophe Barbé
Software Engineer - christophe.barbe@lineo.fr
Lineo France - Lineo High Availability Group
42-46, rue Médéric - 92110 Clichy - France
phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01
http://www.lineo.com

Re: sk_buff destructor in 2.2.18

[Andi Kleen]

On Wed, May 23, 2001 at 04:50:28PM +0200, christophe barbé wrote:
> I don't know about socket but I allocate myself the skbuff and I set the
> destructor (and previously the pointer value is NULL). So I don't overwrite
> a destructor.

That just means you didn't test all cases; e.g. not TCP or UDP send/receive.



> 
> I believe net/core/sock.c is not involved in my problem but I can be wrong.
> What is worrying me is that I don't know who clones my skbuff and why.

skbuffs are cloned all over the stack for various reasons.

 
> To said everything, I know who clones my skbuff because it causes a oops
> when it tries to free my buffer If I use my destructor.

Because you're mistakely using a private field.


-Andi

Re: sk_buff destructor in 2.2.18

[christophe barbé]

I believe you and It's sure that I have not tested all cases.
So do you see a way to use a private data buffer ?

Christophe

On Wed, 23 May 2001 16:55:57 Andi Kleen wrote:
> On Wed, May 23, 2001 at 04:50:28PM +0200, christophe barbé wrote:
> > I don't know about socket but I allocate myself the skbuff and I set
> the
> > destructor (and previously the pointer value is NULL). So I don't
> overwrite
> > a destructor.
> 
> That just means you didn't test all cases; e.g. not TCP or UDP
> send/receive.
> 
> 
> 
> > 
> > I believe net/core/sock.c is not involved in my problem but I can be
> wrong.
> > What is worrying me is that I don't know who clones my skbuff and why.
> 
> skbuffs are cloned all over the stack for various reasons.
> 
>  
> > To said everything, I know who clones my skbuff because it causes a
> oops
> > when it tries to free my buffer If I use my destructor.
> 
> Because you're mistakely using a private field.
> 
> 
> -Andi
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
-- 
Christophe Barbé
Software Engineer - christophe.barbe@lineo.fr
Lineo France - Lineo High Availability Group
42-46, rue Médéric - 92110 Clichy - France
phone (33).1.41.40.02.12 - fax (33).1.41.40.02.01
http://www.lineo.com

Re: sk_buff destructor in 2.2.18

[Andi Kleen]

On Wed, May 23, 2001 at 05:02:15PM +0200, christophe barbé wrote:
> I believe you and It's sure that I have not tested all cases.
> So do you see a way to use a private data buffer ?

The only way I know currently is to keep skb->users >= 1 and use a timer
that collects such buffers from a global list, but it is not very nice. The
stack doesn't like private buffers.

-Andi