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 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 .....................
