[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: Tue, 4 Dec 2001 12:18:24 +0200 (EET)
Cc: <netdev@xxxxxxxxxxx>, <design@xxxxxxxxxxxxxxxxxx>
In-reply-to: <200112040526.fB45Q4D12164@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: owner-netdev@xxxxxxxxxxx

On Tue, 4 Dec 2001, Michael Richardson wrote:

>   One thing is that we had mixed reports about the need to reassemble
> fragments. We realized that this is because netfilter will reassemble
> fragments for us.
>   (My User-Mode-Linux tests had netfilter off)

        Yes, this is true. But this reassembling will disappear soon
and will be moved down to each its user. I.e. you have to do it
yourself. Using the 2 lines is simpler but slower if you receive only
fragments. You can use these 2 lines of code before you design how
to read the data from each skb in frag_list (may be checksum + read?!?).

>   I thought that 2.2 had a specific option for turning this on. Maybe it
> was 2.0!

        Yes, in 2.2 ip_defrag performed the reassembling. Not in 2.4.
More specifically, the linearization of the data.

>   Anyway, it is not clear to us what netfilter option is the minimum required
> to cause fragments to be reassembled prior to transport layer. Is just having
> netfilter enabled enough to do that?  I'm asking so that we can properly
> diagnose the situation.

        It is not the Netfilter who calls ip_defrag, it was called
from the local delivery code (of course, the conntracking can do it
at prerouting). With the current kernels you are ok, as long as, the
patch from Rusty is not applied:

see the change in net/core/netfilter.c. There are 5 lines that
will disappear soon. So, be warned. This is the reason we to talk
for using these 2 lines. TCP is just ready for these changes (no
surprises here).

>   We will be adding:
>       /* In Linux 2.4.4, we may have to reassemble fragments. They are
>          not assembled automatically to save TCP from having to copy
>          twice.

        They are reassembled in sense of proper ordering but the
data is spread on many skbs in ->frag_list. I.e. ip_defrag avoids
data copy. If you need to checksum the data then you have to
additionally linearize it.

>       */
>       if (skb_is_nonlinear(skb)) {
>       if (skb_linearize(skb, GFP_ATOMIC) != 0) {
>         goto rcvleave;
>       }
>       }
>       ipp = (struct iphdr *)skb->nh.iph;
>       iphlen = ipp->ihl << 2;
> #endif
>   we will do this after we have checked for COW on the SKB.

        Instead of cow may be you have to look for another
function (but it will be 2.4 specific). skb_cow copies data,
although valid for 2.2, you must be sure that you need to copy
the skb data (if you need write access) in 2.4. The other variant
is to use function that expands the header if only that is the goal.


Julian Anastasov <ja@xxxxxx>

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