On Tue, May 31, 2016 at 9:27 PM, Herbert Xu 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
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
On Tue, May 31, 2016 at 8:43 PM, Herbert Xu wrote:
> When we postpone a broadcast packet we save the source port in
> the skb if it is local. However, the source port can disappear
> before we get a chance to process the packet.
>
Hmm, why could this happen? The
When we postpone a broadcast packet we save the source port in
the skb if it is local. However, the source port can disappear
before we get a chance to process the packet.
This patch fixes this by holding a ref count on the netdev.
It also delays the skb->cb modification until after we allocate
When we postpone a broadcast packet we save the source port in
the skb if it is local. However, the source port can disappear
before we get a chance to process the packet.
This patch fixes this by holding a ref count on the netdev.
It also delays the skb->cb modification until after we allocate