All of lore.kernel.org
 help / color / mirror / Atom feed
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.





             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 ` PROBLEM: csum_partial() / i386 does not handle unaligned address with empty region properly 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.