|
Hello,
On Wed, 17 Oct 2001, Wensong Zhang wrote:
> The size=40 is exactly the size of struct iphdr and tcphdr, so the size of
> payload is zero, so this is zero data packet, it seldom helps in real
> applications.
Mamma mia. And we do payload-only calls with size=0.
> One of odd thing is that csum_partial implementation on the i386
> architecture will provide the wrong result if the length is zero and the
> address is double word aligned.
>
> csum_partial(a, 0, 0) = 0
> csum_partial(a+1, 0, 0) = 0
> csum_partial(a+2, 0, 0) = 3
> csum_partial(a+3, 0, 0) = 4
>
> csum_partial implementations on other architectures is right. I used to
> provide a patch.
>
> --- linux/arch/i386/lib/checksum.S.orig Wed Sep 6 05:01:35 2000
> +++ linux/arch/i386/lib/checksum.S Fri Jul 13 09:54:37 2001
> @@ -149,6 +149,8 @@
> 30: subl $2, %ecx
> ja 20b
> je 32f
> + addl $2, %ecx
> + jz 80f
> movzbl (%esi),%ebx # csumming 1 byte, 2-aligned
> addl %ebx, %eax
> adcl $0, %eax
>
>
> But the kernel guru insist that the caller should check the length first
> before csum_partial, their assumption on csum_partial calling is the
> length must be >0. Maybe I need to make a shell of ip_vs_csum_partial to
> correct this problem.
After 0.9.4 when we use only one csum_partial call ip_vs_proto_doff
will guard us against such problems. But your solution can be needed
for the "stable" 0.8.X series. In any case, the 0.8.X csum handling
is not correct on CHECKSUM_HW, skb->csum is not loaded correctly (the
proto header) is not included. It will work while the kernel returns
CHECKSUM_NONE. The real problem is only for ip_vs_out(), ip_vs_nat_xmit
may be always will detect CHECKSUM_NONE.
> Regards,
>
> Wensong
Regards
--
Julian Anastasov <ja@xxxxxx>
|
