From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751085AbWGKRAp (ORCPT ); Tue, 11 Jul 2006 13:00:45 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751087AbWGKRAp (ORCPT ); Tue, 11 Jul 2006 13:00:45 -0400 Received: from py-out-1112.google.com ([64.233.166.181]:3626 "EHLO py-out-1112.google.com") by vger.kernel.org with ESMTP id S1751085AbWGKRAp (ORCPT ); Tue, 11 Jul 2006 13:00:45 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EYJkWD4Yu0C/mTdaJb03kkth7tg0u0v5p3mF+7uGvxX2HnZYZbJBTcG5VO6yQgKregcpf8oaVBDKWBcPQI+YGN+GR7yELUHv0Yhd+aX4U+8G0pSXmWqgBj2SIS6PlPYzGbMFNa7OzWzvxH47zTJynympNMeNqjO2necLpK5kOUw= Message-ID: <6bffcb0e0607111000q228673a9kcbc6c91f76331885@mail.gmail.com> Date: Tue, 11 Jul 2006 19:00:43 +0200 From: "Michal Piotrowski" To: "Catalin Marinas" Subject: Re: [PATCH 00/10] Kernel memory leak detector 0.8 Cc: linux-kernel@vger.kernel.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060710220901.5191.66488.stgit@localhost.localdomain> <6bffcb0e0607110617g36f7123dm2b5f0e88b10cbcaa@mail.gmail.com> <6bffcb0e0607110649s464840a9sf04c7537809436b1@mail.gmail.com> <6bffcb0e0607110802w4f423854rb340227331084596@mail.gmail.com> <6bffcb0e0607110902u4e24a4f2jc6acf2eb4c3bae93@mail.gmail.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 11/07/06, Catalin Marinas wrote: > On 11/07/06, Michal Piotrowski wrote: > > So if we got 3970 > > orphan pointer 0xf5a6fd60 (size 39): > > c0173822: <__kmalloc> > > c01df500: > [...] > > and 4673 > > orphan pointer 0xf4249488 (size 29): > > c0173822: <__kmalloc> > > c01df500: > [...] > > It's not a memleak? > > Not exactly. What I meant is that if you have a corresponding number > of reports from __alloc_skb, maybe they were false positives and the > block wasn't scanned leading to other false positive reports > > It looks like there are some reports in __alloc_skb. Please try the > attached patch. Here is the result http://www.stardust.webpages.pl/files/o_bugs/kml/ml4.txt > > Thanks. > > -- > Catalin > > > Regards, Michal -- Michal K. K. Piotrowski LTG - Linux Testers Group (http://www.stardust.webpages.pl/ltg/wiki/)