On Tue, 6 Mar 2007, Herbert Xu wrote:
> It's just too error-prone to rely on it to not have MSG_TRUNC set.
Agreed.
> I'm going to clean this up for UDP and improve the UDP-lite checksum
> handling while I'm at it.
Great. It'll be good to get this years-old UDP bug fixed.
Thanks,
Jim
-
To unsub
On Tue, Mar 06, 2007 at 10:34:49AM +1100, Herbert Xu wrote:
> >
> > That's not true. Please see my post.
> >
> > Specifically, at linux-2.6.20.1/net/ipv4/udp.c:843, it seems that
> > udp_recvmsg() can randomly ignore whether the HW has computed a checksum
> > and compute it in SW redundantly.
On Mon, Mar 05, 2007 at 01:01:16PM -0800, Jim Chow wrote:
> On Tue, 6 Mar 2007, Herbert Xu wrote:
> > msg_flags [...] its initial value is not used.
>
> That's not true. Please see my post.
>
> Specifically, at linux-2.6.20.1/net/ipv4/udp.c:843, it seems that
> udp_recvmsg() can randomly ignore
On Tue, 6 Mar 2007, Herbert Xu wrote:
> msg_flags [...] its initial value is not used.
That's not true. Please see my post.
Specifically, at linux-2.6.20.1/net/ipv4/udp.c:843, it seems that
udp_recvmsg() can randomly ignore whether the HW has computed a checksum
and compute it in SW redundantl
Jim Chow <[EMAIL PROTECTED]> wrote:
> After inspection of some networking code, it seems there is a use of
> uninitialized data in udp_recvmsg(),
> linux-2.6.20.1/net/ipv4/udp.c:843, while testing msg->msg_flags (see
> the backtrace below). It looks like sys_recvfrom() is not
msg_flags is set on
After inspection of some networking code, it seems there is a use of
uninitialized data in udp_recvmsg(),
linux-2.6.20.1/net/ipv4/udp.c:843, while testing msg->msg_flags (see
the backtrace below). It looks like sys_recvfrom() is not
initializing msg.msg_flags and, along the path given below, msg_f