[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKD1Yr0MoyjBwUVG+Bjf5D-k0-JkvzOL3mDaNtjF4rUeWJ21Ew@mail.gmail.com>
Date: Fri, 25 Apr 2014 20:09:49 +0900
From: Lorenzo Colitti <lorenzo@...gle.com>
To: Lorenzo Colitti <lorenzo@...gle.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>,
David Miller <davem@...emloft.net>,
Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH net-next v4 1/3] net: ipv6: Unduplicate
{raw,udp}v6_sendmsg code
On Fri, Apr 25, 2014 at 12:43 AM, Hannes Frederic Sowa
<hannes@...essinduktion.org> wrote:
>> I wonder, is it better to just initialize dontfrag to np->dontfrag
>> instead of -1 in the caller? ip6_datagram_send_ctl seems to just
>> overwrite dontfrag with whatever comes from userspace, so nobody ever
>> checks that it's < 0.
>
> Yes, that is what I had in mind. So we must not reset dontfrag to -1 in
> datagram_common_send and leave the check just after do_append_data as is.
Thinking about it some more, it seems that that might be confusing as
well. Someone might trip up over it again - it's already happened
twice.
Instead, I've moved the initialization back into
ip6_datagram_send_common, so the variables are now obviously
uninitialized in the callers, and in udpv6_sendmsg I explicitly set
hlimit and tclass to -1, and dontfrag to np->dontfrag, before the goto
do_append data. That way, if the goto is taken, it's immediately
obvious that the variables are being set, and if it's not, it's clear
that they are uninitialized and being set in ip6_datagram_send_common.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists