[lkml]   [2001]   [Jul]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectPROBLEM: csum_partial() / i386 does not handle unaligned address with empty region properly

I hope I knock on the right door...

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

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;

printk("****** CSUM %x = %d\n",data,csum);
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
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:56    [W:0.033 / U:0.048 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site