mingo@chiara.csoma.elte.hu wrote:
>
> On Thu, 9 Sep 1999, Linus Torvalds wrote:
>
> > > Some month ago I pointed out that the checksum 686 can buffer overflow if
> > > the start of the buf&1 is != 0.
> >
> > And some months ago somebody pointed out that it wasn't true. I don't know
> > who is right.
[from memory:] The 686 ip checksum routine assumes it is always being
called with a 2-byte aligned buffer in order to optimize away a few
branches. Should it be called with an odd buffer address it may access
(read) an address that's >(buf+len) (it reads the last portion of the
data as a longword). Which could be a problem if that data would be
on another page. But this can _only_ happen if the starting address
of the checksummed buffer is odd, which does not happen. [i looked at
this a while ago and (a) was never able to catch such a case with
an instrumented checksum routine, (b) didn't find any place that
this could in theory happen. Apparently nobody else either.]
Now, if there is a problem with the checksum routine it's that this
assumption isn't documented properly, that's all.
> also some months ago somebody (who happened to be the implementor of that
> unrolled 686 loop) pointed out that the 128-byte unrolling is suboptimal
> as well.
from my tests further unrolling was a _small_ win when everything was
cached, didn't make much difference with cold caches, and isn't probably
worth it.
Note that the 686 routines _can_ be significanly improved. I think the
snapshot at
http://www.geocities.com/SiliconValley/Heights/6494/sw/iackk.tgz
contains my latest version of these routines (+ a few others, incl.
Andrea's, for comparison). IIRC I was able to reduce the cost of
the copy from ~30% to ~5%, and make csum_partial ~15% faster for
small buffers (ie headers). I got somewhat sidetracked and never
commented the code; which i wanted to do before publishing the
patch... Will try to merge with my other checksum changes and
post a patch in a few days.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/