From: Hirokazu Takahashi <taka@valinux.co.jp>
Date: Tue, 03 Sep 2002 16:42:43 +0900 (JST)
I guess it may also depend on bad implementations of csum_partial().
It's wrong that some architecture assume every data in a skbuff are
aligned on a 2byte boundary so that it would access a byte next to
the the last byte where no pages might be there.
It is real requirement, x86 works because unaligned
access is handled transparently by cpu.
But on every non-x86 csum_partial I have examined, worse than
2-byte aligned data start is totally not handled. It is not difficult
to figure out why this is the case, everyone has copied by example. :-)
So we must make a decision, either make every csum_partial
implementation eat 1 byte alignment or enforce 2-byte
alignment at call sites.
I think for 2.4.x it is unreasonable to force everyone to change their
csum_partial, especially since handling byte aligned buffer requires
holding onto state across the whole checksum from beginning to the
last fold. Many RISC implementation are using registers to the max
and may not easily be able to obtain a temporary.
I dealt with a bug in this area recently, pppoe can cause ppp_input to
send byte aligned data in packets to TCP input, this crashes just
about every non-x86 system so my "fix" was to copy byte aligned SKBs
in ppp_input.
-
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 : Sat Sep 07 2002 - 22:00:17 EST