PROBLEM: csum_partial() / i386 does not handle unaligned address with empty region properly

Hi,

I hope I knock on the right door...

Herve MASSON [email protected]
MindStep Corp.

----

[1.] One line summary of the problem:
csum_partial()/i386 does not handle unaligned address with empty region properly

[2.] Full description of the problem/report:

First, I don't know if this is a BUG or if that behavior has been left intentionally.

When we call the csum_partial() function with an empty region (i.e. len=0), its code (arch/i386/lib/checksum.S) behaves differently when the given address is aligned (to 32 bits) or not. When it's aligned, the function returns 0, which is what I would expect. When it's not, it seems that it returns the first byte of the buffer, while I would expect it to return zero as well.
It's not clear to me if it's calling code's responsibility to check the len parameter, but I know software that assume csum_partial does the test in all case (IPVS is the one where I disovered the problem).

[3.] Keywords: Networking, i386, Arch, checksum

[4.] Kernel version (from /proc/version):

     Linux version 2.4.5 (root@linux) (gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-81))
     #92 SMP Sat Jul 7 19:28:46 EDT 2001

[6.] A small shell script or example program which triggers the

     problem (if possible)

     static char data[10]={9,4,9,4,9,4};
     int csum;

     csum=csum_partial(data,0,0);
     printk("****** CSUM %x = %d\n",data,csum);
     csum=csum_partial(data+2,0,0);
     printk(0, "****** CSUM %x = %d\n",data+2,csum);
     
     First message will report an aligned address and a nul checksum.
     Second message will report an unaligned address and a checksum value of 9.

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)

If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes.

Linux linux 2.4.5 #92 SMP Sat Jul 7 19:28:46 EDT 2001 i686 unknown

Gnu C 2.96
Gnu make 3.79.1
binutils 2.10.91.0.2
util-linux 2.10s
mount 2.10r
modutils 2.4.2
e2fsprogs 1.19
PPP 2.4.0
isdn4k-utils 3.1pre1
Linux C Library 2.2.2
Dynamic linker (ldd) 2.2.2
Procps 2.0.7
Net-tools 1.57
Console-tools 0.3.3
Sh-utils 2.0
Modules Loaded ip_vs_rr ip_vs_wrr ip_vs_queue ip_vs eepro100

[7.2.] Processor information (from /proc/cpuinfo):

    processor       : 0
    vendor_id       : AuthenticAMD
    cpu family      : 6
    model           : 3
    model name      : AMD Duron(tm) Processor
    stepping        : 1
    cpu MHz         : 756.753
    cache size      : 64 KB
    fdiv_bug        : no
    hlt_bug         : no
    f00f_bug        : no
    coma_bug        : no
    fpu             : yes
    fpu_exception   : yes
    cpuid level     : 1
    wp              : yes
    flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov

pat pse36 mmx fxsr syscall mmxext 3dnowext 3dnow
bogomips : 1510.60

[7.3.] Module information (from /proc/modules):

    ip_vs_rr                1616   8 (autoclean)
    ip_vs_wrr               1936   3 (autoclean)
    ip_vs_queue             6464   0 (unused)

ip_vs 70880 13 (autoclean) [ip_vs_rr ip_vs_wrr ip_vs_queue]
eepro100 16368 1 (autoclean)

[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)

(I believe this is not relevant in that case)

[7.5.] PCI information ('lspci -vvv' as root)

(I believe this is not relevant in that case)

[7.6.] SCSI information (from /proc/scsi/scsi)

(I believe this is not relevant in that case)

[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you think to be relevant):

[X.] Other notes, patches, fixes, workarounds:

Saddly, I don't have the knowledge to fix the problem myself since i386 is still cryptic to me.

AFAIK the standard kernel never passes zero length to csum_partial so there is no bug in it. If IPVS does that it probably needs to be fixed. I would report it to the IPVS maintainers.

-Andi

Yes, better to put the rare check into the weird callers instead of punishing everyone who does not allow this to occur by other means already.

Later,
David S. Miller
[email protected]