Hi,
I hope I knock on the right door...
Herve MASSON herve@mindstep.com
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.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jul 15 2001 - 21:00:14 EST