From: Andi Kleen <ak@suse.de>
Date: Tue, 3 Sep 2002 12:10:41 +0200
On Tue, Sep 03, 2002 at 03:00:25AM -0700, David S. Miller wrote:
> Ok I think we really need to fix this then in the arches
> where broken. Let's do an audit. :-)
Yes, it's needed because users can pass unaligned addresses in from
userspace to sendmsg
I know, that is old news. New case is csum_partial since
sys_sendfile can use byte aligned page offsets.
Traditionally this really didn't ever happen because
skb->data was always nicely aligned.
> It looks like sparc64 is the only platform where oddly aligned buffer
> can truly cause problems and I can fix that easily enough.
It could allow everybody to generate packets with bogus addresses on
the network.
No, the sparc64 case generates an OOPS for csum_partial only.
csum_partial_copy_*() is perfectly fine for byte aligned buffers.
I suspect on sparc64 it will just be all handled by the unalignment handler
in the kernel ? If yes it will be incredibly slow, but should work.
That's what happens now as long as the VIS instructions don't
get used. The one case where oddly aligned buffer address is
not checked to avoid using VIS is csum_partial.
The unaligned trap handler doesn't handle the 64-byte VIS loads into
the fpu regs from kernel mode, and this is by choice. I'd rather back
down to an integer algorithm than actually handle this odd case.
-
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