On Wed, 2016-02-10 at 12:43 +, Vaneet Narang wrote:
> Hi,
>
> >What driver are you using (is that in-tree)? Can you reproduce the same issue
> >with a latest -net kernel, for example (or, a 'reasonably' recent one like
> >4.3 or
> >4.4)? There has been quite a bit of changes in err queue hand
Hi,
>What driver are you using (is that in-tree)? Can you reproduce the same issue
>with a latest -net kernel, for example (or, a 'reasonably' recent one like 4.3
>or
>4.4)? There has been quite a bit of changes in err queue handling (which also
>accounts rmem) as well. How reliably can you trigg
On Mon, 2016-01-18 at 10:44 +0100, Daniel Borkmann wrote:
> On 01/18/2016 07:37 AM, Maninder Singh wrote:
> > Receieve queue is not purged when socket dectruction is called
> > results in kernel warning because of non zero sk_rmem_alloc.
> >
> > WARNING: at net/packet/af_packet.c:1142 packet_sock_d
Hi,
>>
>> Issue is coming for 3.10.58.
>
Sorry for late reply, we were trying to reproduce the issue but its not that
frequent.
>What driver are you using (is that in-tree)?
we are facing issue with wireless driver. Is it possible that wireless driver
can cause any issue because rmem accountin
On 01/21/2016 12:40 PM, Maninder Singh wrote:
The other sock_put() in packet_release() to drop the final ref and call into
sk_free(), which drops the 1 ref on the sk_wmem_alloc from init time. Since you
got into __sk_free() via sock_wfree() destructor, your socket must have invoked
packet_release
Hi Daniel,
>The other sock_put() in packet_release() to drop the final ref and call into
>sk_free(), which drops the 1 ref on the sk_wmem_alloc from init time. Since you
>got into __sk_free() via sock_wfree() destructor, your socket must have invoked
>packet_release() prior to this (perhaps kernel
