On 06/01/2017 09:28, "Ben Pfaff" <b...@ovn.org> wrote:
>On Thu, Jan 05, 2017 at 08:37:26PM -0800, Daniele Di Proietto wrote:
>> bridge_delete_or_reconfigure() deletes every interface that's not dumped
>> by OFPROTO_PORT_FOR_EACH(). ofproto_dpif.c:port_dump_next(), used by
>> OFPROTO_PORT_FOR_EACH, checks if the ofport is in the datapath by
>> calling port_query_by_name(). If port_query_by_name() returns an error,
>> the dump is interrupted. If port_query_by_name() returns ENODEV, the
>> device doesn't exist and the dump can continue.
>>
>> port_query_by_name() for the userspace datapath returns ENOENT instead
>> of ENODEV. This is expected by dpif_port_query_by_name(), but it's not
>> handled correctly by port_dump_next().
>>
>> This commit fixes the problem by handling ENOENT like ENODEV.
>>
>> dpif-netdev handles reconfiguration errors for an interface by deleting
>> it from the datapath, so it's possible that a device is missing. When this
>> happens we must make sure that port_dump_next() continues to dump other
>> devices otherwise they will be deleted and the two layers will have an
>> inconsistent view.
>>
>> The problem was found while developing new code.
>>
>> Signed-off-by: Daniele Di Proietto <diproiet...@vmware.com>
>
>I'm not sure whether there's a difference in meaning between ENOENT and
>ENODEV when it comes from these functions. I wonder whether the dpif
>layer should translate one of them into the other, for callers'
>convenience.
Good idea, let me send a v2.
Thanks,
Daniele
>
>Acked-by: Ben Pfaff <b...@ovn.org>
_______________________________________________
dev mailing list
d...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
