[OpenWrt-Devel] [PATCH 3/3] netifd: Read current link state when processing netlink event

[Hans Dedecker]

Hi Felix,

Thx for the feedback. Regarding the remaining race condition I assume you
refer
to the vlan device link status which can be set as enabled due to reading
directly
the carrier state in cb_rtnl_event while the parent interface is still link
status disabled?

I will rework my patch based on the keep_link_status changes and deliver a
new patch tomorrow.

Hans

On Wed, Oct 22, 2014 at 2:30 PM, Felix Fietkau <nbd at openwrt.org> wrote:

> On 2014-10-22 14:14, Hans Dedecker wrote:
> > Netifd commit b2dcb02570939d98b92c7c55db1c328693a5d52a introduces
> > a race condition resulting into infinite toggling interfaces
> > (eg static interfaces with linksensing enabled, vlan interfaces
> > with proto none (#18106)) when linksensing is enabled resulting into
> > a crash.
> > As netlink event messages will be queued on the netlink event socket
> > the included lower up interface flag will not always represent the
> > current link state when netifd processes the netlink messages;
> > by reading the current link state when a netlink event message is
> > parsed the correct info is passed to the device layer.
> > This will avoid continuous interface toggling (down/up) triggered
> > by link state changes based on outdated netlink interface info.
> > This solution replaces the patch which was introduced to solve
> > issue (#1806) for vlan devices as other protocol handlers suffered
> > from the same problem.
> >
> > Signed-off-by: Hans Dedecker <dedeckeh at gmail.com>
> While I agree with the change to read the carrier directly, this patch
> still has a remaining race condition.
> I added keep_link_status, because the VLAN device event callbacks set
> the VLAN device link status based on the link status of the parent device.
> Please either leave in keep_link_status or remove link status handling
> from the device event callbacks of VLAN devices.
>
> - Felix
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20141022/16f2a3f1/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel