Re: [PATCH] af_packet: Raw socket destruction warning fix

Hi,

quoted

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 accounting is done by kernel.

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.

It difficult to port on 4.3 as of now but can you suggest some patches which can
be helpful. One more thing, can https://lkml.org/lkml/2015/9/15/634. change 
in linux kernel cause this issue. Just an observation (could be incorrect), after 
including this change we are facing this issue.

How reliably can you trigger the issue? Does it trigger
with a completely different in-tree network driver as well with your tests?

This issue is not easily reproducible. This issue gets reproduced in long term
testing. Yes wireless network driver is not in tree.

Would be useful to track/debug sk_rmem_alloc increases/decreases to see from which path
new rmem is being charged in the time between packet_release() and packet_sock_destruct()
for that socket ...

As i mentioned, its not easily reproducible but we have added some debug patch in 
packet_sock_destruct to check the value of rmem_alloc. 
So as per logs, At the entry point rmem_alloc was 0 but after error queue purge 
it becomes some 576(seems a new packet added). Not sure which queue. 
Is it possible that kernel can still add packets in receive queue when socket is already closed, 
can you point the kernel code where this is avoided or is there any way this gets added to error
queue. 
As per my understanding rmem_alloc gets increased only if packets gets added to receive queue
or error queue. Is it any other queue which also changes rmem_alloc?

Thanks,
Vaneet Narang
.....................