From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752269Ab1GSVOx (ORCPT ); Tue, 19 Jul 2011 17:14:53 -0400 Received: from dsl-67-204-24-19.acanac.net ([67.204.24.19]:48131 "EHLO mail.ellipticsemi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752159Ab1GSVOv (ORCPT ); Tue, 19 Jul 2011 17:14:51 -0400 Date: Tue, 19 Jul 2011 17:14:38 -0400 From: Nick Bowler To: linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Catalin Marinas Subject: kmemleak fails to report detected leaks after allocation failure Message-ID: <20110719211438.GA21588@elliptictech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Organization: Elliptic Technologies Inc. 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 I just ran into a somewhat amusing issue with kmemleak. After running for a while (10 days), and detecting about 100 "suspected memory leaks", kmemleak ultimately reported: kmemleak: Cannot allocate a kmemleak_object structure kmemleak: Automatic memory scanning thread ended kmemleak: Kernel memory leak detector disabled OK, so something failed and kmemleak apparently can't recover from this. However, at this point, it appears that kmemleak has *also* lost the ability to report the earlier leaks that it actually detected. cat: /sys/kernel/debug/kmemleak: Device or resource busy It seems to me that kmemleak shouldn't lose the ability to report leaks that it already detected after it disables itself due to an issue that was potentially caused by the very leaks that it managed to detect (unlikely in this instance, but still...). This was on a 2.6.39.2 kernel on x86_64. I imagine that such a failure is unlikely to repeat itself, but I figured I'd throw it out there. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with ESMTP id C26646B00EE for ; Tue, 19 Jul 2011 17:14:52 -0400 (EDT) Date: Tue, 19 Jul 2011 17:14:38 -0400 From: Nick Bowler Subject: kmemleak fails to report detected leaks after allocation failure Message-ID: <20110719211438.GA21588@elliptictech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-linux-mm@kvack.org List-ID: To: linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Catalin Marinas I just ran into a somewhat amusing issue with kmemleak. After running for a while (10 days), and detecting about 100 "suspected memory leaks", kmemleak ultimately reported: kmemleak: Cannot allocate a kmemleak_object structure kmemleak: Automatic memory scanning thread ended kmemleak: Kernel memory leak detector disabled OK, so something failed and kmemleak apparently can't recover from this. However, at this point, it appears that kmemleak has *also* lost the ability to report the earlier leaks that it actually detected. cat: /sys/kernel/debug/kmemleak: Device or resource busy It seems to me that kmemleak shouldn't lose the ability to report leaks that it already detected after it disables itself due to an issue that was potentially caused by the very leaks that it managed to detect (unlikely in this instance, but still...). This was on a 2.6.39.2 kernel on x86_64. I imagine that such a failure is unlikely to repeat itself, but I figured I'd throw it out there. Cheers, -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org