On Tue, 2017-05-09 at 15:54 -0700, Eric Dumazet wrote:
> On Tue, 2017-05-09 at 15:52 -0700, Eric Dumazet wrote:
> > On Tue, 2017-05-09 at 15:07 -0700, Cong Wang wrote:
> > > On Tue, May 9, 2017 at 1:56 PM, Cong Wang <xiyou.wangc...@gmail.com>
> > > wrote:
> > > > Wait... if we transfer dst->dev to loopback_dev because we don't
> > > > want to block unregister path, then we might have a similar problem
> > > > for rt->fi too, fib_info is still referenced by dst, so these nh_dev's
> > > > still
> > > > hold the dev references...
> > > >
> > >
> > > I finally come up with the attach patch... Do you mind to give it a try?
> >
> > I will, but this might be delayed by a few hours.
> >
> > In the mean time, it looks like you could try adding the following to
> > your .config ;)
> >
> > CONFIG_IP_ROUTE_MULTIPATH=y
> >
> >
>
> + /* This should be fine, we are on unregister
> + * path so synchronize_net() already waits for
> + * existing readers. We have to release the
> + * dev here because dst could still hold this
> + * fib_info via rt->fi, we can't wait for GC.
> + */
> + RCU_INIT_POINTER(nexthop_nh->nh_dev, NULL);
> + dev_put(dev);
> dead = fi->fib_nhs;
>
> dead = fi->fib_mhs looks wrong if you remove the break; statement ?
>
> - break;
Also setting nexthop_nh->nh_dev to NULL looks quite dangerous
We have plenty of sites doing :
if (fi->fib_dev)
x = fi->fib_dev->field
fib_route_seq_show() is one example.
