hard_start_xmit struct sk_buff read-only?

hard_start_xmit struct sk_buff read-only?

[Matti Linnanvuori]

An old article about Linux's network drivers mentioned
that the struct sk_buff whose pointer is passed to a
driver's hard_start_xmit function is read-only to the
function. Is that still so? If it is, there is no
mention about it in the kernel tree as far as I know.


      Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail

Re: hard_start_xmit struct sk_buff read-only?

[Jeff Garzik]

Matti Linnanvuori wrote:
> An old article about Linux's network drivers mentioned
> that the struct sk_buff whose pointer is passed to a
> driver's hard_start_xmit function is read-only to the
> function. Is that still so? If it is, there is no
> mention about it in the kernel tree as far as I know.

This begs the question, what are you trying to do?  ;-)

In terms of object lifetimes, control passes to the net driver when 
->hard_start_xmit() is called, but that does not mean you can freely 
scribble over things -- the skb may have been cloned, its destructor 
callback still needs to be called (via dev_kfree_skb), etc.

	Jeff

Re: hard_start_xmit struct sk_buff read-only?

[Matti Linnanvuori]

--- Jeff Garzik <jeff@garzik.org> schrieb:

> This begs the question, what are you trying to do? 
> ;-)

I have seen network drivers whose hard_start_xmit
function calls skb_push or skb_put to extend the used
data area of the struct skb_buff passed to the
function. That avoids allocating a new buffer and
copying the whole data area to it. The drivers
apparently do that because the device expects a
specific header or suffix in the DMA buffer it
handles.

> In terms of object lifetimes, control passes to the
> net driver when 
> ->hard_start_xmit() is called, but that does not
> mean you can freely 
> scribble over things -- the skb may have been
> cloned, its destructor 
> callback still needs to be called (via
> dev_kfree_skb), etc.

So I assume modifying the data or header area of
struct sk_buff is incorrect because it can break
cloned buffers.


      Heute schon einen Blick in die Zukunft von E-Mails wagen? www.yahoo.de/mail