On Tue, May 9, 2017 at 4:09 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > 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;
This statement is only used to ensure we pass the "dead == fi->fib_nhs" check right below the inner loop, it is fine to keep it without break since fi is not changed in the inner loop. > > 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. > All of them take RCU read lock, so, as I explained in the code comment, they all should be fine because of synchronize_net() on unregister path. Do you see anything otherwise?
