I'm still looking at your patch.
Below is a piece of my original patch that I've separated out to make sure
it doesn't get lost in this discussion. It's the fix for the bug that
triggered all
of this and the real cause of the panic for the ordinary raw-socket cases,
where
nr_frags is supposed to be "0". Attached and in-line below.
A couple comments initially on your patch: multiple packet support I don't
think is needed here (in sendmsg). I agree it's good to put it in for
other
possible uses, but IPV6_CHECKSUM doesn't need it, as far as I can tell.
How about a loop instead of a recursive call? If the list is long enough
and the architecture eats stack a lot of stack space on function calls,
that could be a problem.
+-DLS
The fix part of the patch:
Signed-off-by: David L Stevens <dlstevens@xxxxxxxxxx>
--- linux-2.6.11.7/net/ipv6/raw.c 2005-04-07 11:57:32.000000000
-0700
+++ linux-2.6.11.7T1/net/ipv6/raw.c 2005-04-12 15:05:00.000000000
-0700
@@ -771,8 +790,11 @@ back_from_confirm:
if (err)
ip6_flush_pending_frames(sk);
- else if (!(msg->msg_flags & MSG_MORE))
+ else if (!(msg->msg_flags & MSG_MORE)) {
err = rawv6_push_pending_frames(sk, &fl, rp, len);
+ if (err)
+ ip6_flush_pending_frames(sk);
+ }
}
done:
ip6_dst_store(sk, dst,
rawv6-2.patch
Description: Binary data
|