On Tue, May 31, 2016 at 9:27 PM, Herbert Xu <herb...@gondor.apana.org.au> wrote: > On Tue, May 31, 2016 at 09:19:37PM -0700, Cong Wang wrote: >> >> Hmm, why could this happen? The upper device should be linked >> with the lower device, where a refcount is already held. >> Also, the work is cancelled in ->uninit(). > > Of course it can happen. We are talking about the source macvlan > device that we just looked up using the Ethernet address. That > device has nothing to do with the packet now so it may be deleted > at any time. > > We do flush the work but only when the all macvlan devices on a > port have been deleted. Perhaps you're confusing the source > device with vlan->lowerdev which is confusingly the actual > hardware device?
I thought all the on-flying packets are waited by synchronize_net() during the removal of any of these devices. But since you moved them to a workqueue, aka process context, so I think it won't work any more. Your patch makes sense to me now. :) Thanks!
