Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756852Ab3CUHIL (ORCPT ); Thu, 21 Mar 2013 03:08:11 -0400 Received: from server.atrad.com.au ([150.101.241.2]:51749 "EHLO server.atrad.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751758Ab3CUHIJ (ORCPT ); Thu, 21 Mar 2013 03:08:09 -0400 Date: Thu, 21 Mar 2013 17:37:50 +1030 From: Jonathan Woithe To: Raymond Jennings Cc: Hillf Danton , David Rientjes , Linux-MM , LKML , Jonathan Woithe Subject: Re: OOM triggered with plenty of memory free Message-ID: <20130321070750.GV30145@marvin.atrad.com.au> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1767 Lines: 38 On Sat, Mar 16, 2013 at 02:33:23AM -0700, Raymond Jennings wrote: > Anyway, to the parent poster, could you tell us more, such as how much > ram you had left free? Following on from my previous post, here is a summary of what I know about this memory leak following additional testing. * It was introduced in 2.6.35.11 * It was not present in 2.6.35.12 * Previous git bisects on the main git tree indicate that the leak was not in 2.6.36 or any later mainline kernel version Commit cab9e9848b9a8283b0504a2d7c435a9f5ba026de to the stable tree ("scm: Capture the full credentials of the scm sender") seems to have introduced the leak. Commit 48e6b121605512d87f8da1ccd014313489c19630 to the stable tree ("Fix cred leak in AF_NETLINK") seems to have fixed the leak in the stable branch. The commit message concentrates on the closure of an information leak, but evidently there was a memory leak behind it as well. cab9..26de was upstreamed as 257b5358b32f17e0603b6ff57b13610b0e02348f, but 48e6..9630 does not appear to have made it into mainline in its entirety. However, the call to scm_destroy() in the "out:" block added by 48e6..9630 is in mainline; I presume that this is what closes the memory leak because the only other parts of the commit set the function return value (unless the different function returns cause the callers not to leak). I'm guessing that 48e6..9630 was not applied to mainline in its entirety due to the underlying problem being fixed in a slightly different way. Regards jonathan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/