From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752190AbcBEFYX (ORCPT ); Fri, 5 Feb 2016 00:24:23 -0500 Received: from mailout1.samsung.com ([203.254.224.24]:41181 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752101AbcBEFYU (ORCPT ); Fri, 5 Feb 2016 00:24:20 -0500 X-AuditID: cbfee68e-f793c6d00000136c-94-56b43202ce56 Date: Fri, 05 Feb 2016 05:23:35 +0000 (GMT) From: Vaneet Narang Subject: Re: [PATCH] af_packet: Raw socket destruction warning fix To: Daniel Borkmann , Maninder Singh Cc: "davem@davemloft.net" , "willemb@google.com" , "edumazet@google.com" , "eyal.birger@gmail.com" , "tklauser@distanz.ch" , "fruggeri@aristanetworks.com" , "dwmw2@infradead.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , PANKAJ MISHRA , Geon-ho Kim , Hak-Bong Lee Reply-to: v.narang@samsung.com MIME-version: 1.0 X-MTR: 20160205052154558@v.narang Msgkey: 20160205052154558@v.narang X-EPLocale: en_US.windows-1252 X-Priority: 3 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-EPApproval-Locale: X-EPHeader: ML X-MLAttribute: X-RootMTR: 20160205052154558@v.narang X-ParentMTR: X-ArchiveUser: X-CPGSPASS: N X-ConfirmMail: N,general Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 Message-id: <1841100414.696991454649811187.JavaMail.weblogic@epmlwas05b> X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGIsWRmVeSWpSXmKPExsWyRsSkSpfJaEuYwfJzOhaXd81hc2D0+LxJ LoAxissmJTUnsyy1SN8ugSvj8aLJrAU/RCu2d19lbmBcI9rFyMkhJKAs0XntGiuILSFgInF0 2mUoW0ziwr31bF2MXEA1SxklZm1qYu5i5AArWrkqAiI+h1Fi4snNYA0sAioSuxc/ZQex2QS0 Jd7862UBsYUFnCTedP8AqxERiJJ43nOUBaSZWeAii8Ssn+/ZIa6Qk/i74BcziM0rIChxcuYT FogrFCUOTz7IAhFXkpg7YTEzRFxOYsnUy0wQNq/EjPanLDDxaV/XQNVIS5yftYER5pvF3x9D xfkljt3eAdUrIDH1zEGoGjWJ9w9gvueTWLPwLQtM/a5Ty5lhdt3fMheqV0Jia8sTsHpmoDun dD9kh7ANJI4smsOK7hdeAQ+Jz1f2gj0vITCVQ+JQ82W2CYxKs5DUzUIyaxaSWchqFjCyrGIU TS1ILihOSi8y0itOzC0uzUvXS87P3cQITA6n/z3r28F484D1IUYBDkYlHt6M1ZvDhFgTy4or cw8xmgIjaiKzlGhyPjAF5ZXEGxqbGVmYmpgaG5lbmimJ8yZI/QwWEkhPLEnNTk0tSC2KLyrN SS0+xMjEwSnVwJiyv93lrk2pWtNPpxcN0ayVfZ8tRDXDrB8ePO/zMjHOa/vfxynPjnmFpUQd +qgbv/6z3eLLrAxHfsUXeNgbhb05OT/rwC5D5vXqQY8txesXN6vx2vm8/vPHaClbSIzb79ut x/uYakvL1r7bb7yqpXihMNcp3UUCLRFc15wYuEMzeXMvKdxaq8RSnJFoqMVcVJwIAJH/e5UJ AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOKsWRmVeSWpSXmKPExsVy+t/tPt3rhlvCDBYct7S4vGsOmwOjx+dN cgGMUWk2GamJKalFCql5yfkpmXnptkrewfHO8aZmBoa6hpYW5koKeYm5qbZKLj4Bum6ZOUBD lRTKEnNKgUIBicXFSvp2NkX5pSWpChn5xSW2StGG5kZ6RgZ6pkZ6hqaxVoYGBkamQDUJaRmP F01mLfghWrG9+ypzA+Ma0S5GTg4hAWWJzmvXWLsYOTgkBEwkVq6KAAlLCIhJXLi3nq2LkQuo ZA6jxMSTm1lBEiwCKhK7Fz9lB7HZBLQl3vzrZQGxhQWcJN50/wCrERGIknjec5QFpJlZ4CKL xKyf79khlslJ/F3wixnE5hUQlDg58wkLxDZFicOTD7JAxJUk5k5YzAwRl5NYMvUyE4TNKzGj /SkLTHza1zVQNdIS52dtYIS5evH3x1Bxfoljt3dA9QpITD1zEKpGTeL9g8usEDafxJqFb1lg 6nedWs4Ms+v+lrlQvRISW1uegNUzA905pfshO4RtIHFk0RxWdL/wCnhIfL6yl2UCo+wsJKlZ SNpnIWlHVrOAkWUVo2hqQXJBcVJ6hbFecWJucWleul5yfu4mRnAierZ4B+P/89aHGAU4GJV4 eA+u3RwmxJpYVlyZe4hRgoNZSYTXUH1LmBBvSmJlVWpRfnxRaU5q8SFGU2C0TWSWEk3OBybJ vJJ4Q2MTc1NjUwsDQ3NzMyVx3oC/68KEBNITS1KzU1MLUotg+pg4OKUaGJ275JlzTlzpuWxb 90dS4/XFk4+2TZuiw/9y/ov7ffd8r9p/mXnCxS1jf0gWb2WR9MaU80VGIjobHinNXyGRnhEg H/e5edX5c/9U+36aHfaYtl+h1PPPv7ehyV5Fbn9Mj3M/EV5fv1nFR6xZY+rW8qiz8tujItT5 //N7GiiyTRSZGtgQJsWyTImlOCPRUIu5qDgRAM0o7SRaAwAA DLP-Filter: Pass X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u155P05w012554 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 .....................