[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <493F63E1.3030800@cn.fujitsu.com>
Date: Wed, 10 Dec 2008 14:38:25 +0800
From: Yang Hongyang <yanghy@...fujitsu.com>
To: David Miller <davem@...emloft.net>
CC: remi.denis-courmont@...ia.com, netdev@...r.kernel.org
Subject: Re: [RFC][PATCH 3/3]ipv6:fix the outgoing interface selection order
in udpv6_sendmsg()
Yang Hongyang wrote:
> David Miller wrote:
>> From: Yang Hongyang <yanghy@...fujitsu.com>
>> Date: Wed, 10 Dec 2008 08:42:20 +0800
>>
>>> If outgoing interface is set with SO_BINDTODEVICE and also sticky pktinfo
>>> the outgoing interface is exactly what SO_BINDTODEVICE set,because in my
>>> first patch,when set sticy pktinfo,outgoing interface set by SO_BINDTODEVICE
>>> is checked:
>>>
>>> + if(sk->sk_bound_dev_if && pkt.ipi6_ifindex != sk->sk_bound_dev_if)
>>> + goto e_inval;
>>>
>> You may be checking this, but these two values can become out of sync
>> if the application next makes a SO_BINDTODEVICE setsockopt() call to
>> change the index setting.
>>
>> Nothing makes sure the sticky ipv6 socket information is updated
>> if that happens. And the most obvious ways to handle that are
>> very ugly, doing some kind of call into ipv6 from the generic
>> socket SO_BINDTODEVICE setsockopt() handler.
>>
>>
>
> Hum..can we just ignore the sync of the sticky option and the SO_BINDTODEVICE,
> when send a message,first check sk_bound_dev_if,If it is specified,use it,otherwise
> use sticky option?This was what i ment. and in my patch ,the outgoing interface
> specified by sticky options will be overrided by the interface specified by
> SO_BINDTODEVICE.
If this is the solution, i'll post a updated patch.
> --
> 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
>
>
--
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