netdev
[Top] [All Lists]

Re: what pointers does pskb_may_pull() nuke?

To: Michael Richardson <mcr@xxxxxxxxxxxxxxxxxxxxxx>
Subject: Re: what pointers does pskb_may_pull() nuke?
From: Julian Anastasov <ja@xxxxxx>
Date: Wed, 28 Nov 2001 00:32:45 +0000 (GMT)
Cc: <netdev@xxxxxxxxxxx>, <design@xxxxxxxxxxxxxxxxxx>
In-reply-to: <200111271944.fARJiGv01467@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx
        Hello,

On Tue, 27 Nov 2001, Michael Richardson wrote:

>     Julian>         if (skb_is_nonlinear(skb)) {
>     Julian>                 if (skb_linearize(skb, GFP_ATOMIC) != 0)
>     Julian>                         return NF_DROP;
>     Julian>                 ip_send_check(skb->nh.iph); // Not needed for 
> local delivery
>     Julian>         }
>
>   Can I just call skb_linearize()?

        It is safe but without checking with skb_is_nonlinear
skb_linearize will copy the data always (even for non-fragmented
packets). So, you can use such code:

if (skb_is_nonlinear(skb) && skb_linearize(skb, GFP_ATOMIC) != 0)
        return NF_DROP;

        Then you have read access to data but write access (IMO,
you don't need it) is still not guaranteed if the packet was not
fragmented.

        Why do you need to skip the check? It is a short inline
function that will save you so many CPU cycles with most of the
packets, i.e. for the common case where the packet is not
fragmented.

>     Julian>   Hm, are you sure it is not enabled? I don't know how you are
>     Julian> using skb->data in the protocol handlers as pointer to iphdr 
> after 2.4.4
>
>   Is IPH_is_SKB_PULLED set by some other part of the system?

        I see it in your own code, not in kernel: lib/freeswan.h (1.91)

#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,4)
#define IP_SELECT_IDENT_NEW
#define IPH_is_SKB_PULLED
...

        but you better know it. IMO, this code should be really
enabled because in the other case skb->data will be used wrongly
in ipsec_rcv().

Regards

--
Julian Anastasov <ja@xxxxxx>


<Prev in Thread] Current Thread [Next in Thread>