In message <1063662564.1358.19.camel@localhost> you write:
> I got the large linearization patch from Rusty. At first look I noticed
> that it could be a large work for IPv6, BCF the extension headers.
> At netfilter6 we inspect these headers in ip6_target.c, ip6t_LOG.c and
> the extension header matches.
> So, my real questions. Could you check some files for me?
> - net/ipv6/ah6.c:ipv6_clear_mutable_options()
> this function uses the skb as a linear one w/o skb_copy_bits or
> skb_linearize. Am I right?
Well, yes, but this is at output, and current code always produces a
linear header (the data may be non-linear for zero-copy though). I
tried not to rely on this in netfilter hooks, in case it changes
> - net/ipv6/ah6.c
> where are these functions called? Before or after the netfilter
Best guesses follow based on a little grepping. Dave/Alexey will
correct me if this is wrong 8)
ah6_output called as a dst->output function, so after
ah6_input called from xfrm6_rcv, called from ip6_input_finish, so
> - net/ipv6/esp6.c
> mainly the same functions as ah6.c, but this file uses skb_copy_bits!
It's an input function, so can't assume linear beyond the header.
Header is pulled in ip6_input_finish, although I feel it should be
done in ip6_input itself so the netfilter hook gets a linear header,
but there's IPv6 header wierdness here (multuple handlers as it
iterates through the headers) which I think makes the current ordering
> - net/ipv6/exthdrs.c:ipv6_invert_rthdr()
> this function manipulates/modifies the routing addresses in an
> extension header. It uses the skb as a linear one w/o checks or
> linearization. Am I right? (This extension header can be far from the
> main IPv6 header and this header can contain lot of IPv6 addresses in a
Headers are linearized in ip6_input_finish IIUC.
> - net/ipv6/exthdrs.c:ipv6_skip_exthdr()
> it is a nice solution with linearization of the required areas only.
> It can be a good solution to use in the extension header based matches.
Yes, that is a good plan.
> The whole function could be used in the ip6_targt.c:ip6_packet_match()
> to get the real next level value. (Currently I have added a similar
> function into that function.)
> Do you see any chance to export this function into the namespace?
Hmm, they look similar, but different enough that merging them might
not be worthwhile: you already use ipv6_ext_hdr(). You'd have to try
it and see if it gets uglier or prettier.
> The 3rd problem is the ip6t_LOG.c, but I think that we stole the
> solution from ipt_LOG.c, as usual :)
Anyone who quotes me in their sig is an idiot. -- Rusty Russell.