From: "Herve Masson" <herve@mindstep.com>
To: <linux-kernel@vger.kernel.org>
Cc: <ak@muc.de>
Subject: PROBLEM: csum_partial() / i386 does not handle unaligned address with empty region properly
Date: Wed, 11 Jul 2001 12:29:26 -0700 [thread overview]
Message-ID: <065f01c10a3f$cbe849a0$0400a8c0@swan> (raw)
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.
next reply other threads:[~2001-07-11 16:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-07-11 19:29 Herve Masson [this message]
2001-07-11 17:17 ` Andi Kleen
2001-07-11 23:18 ` David S. Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='065f01c10a3f$cbe849a0$0400a8c0@swan' \
--to=herve@mindstep.com \
--cc=ak@muc.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®