From: Xiaotian Feng <dfeng@redhat.com>
To: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Dan Carpenter <error27@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>,
Jack Steiner <steiner@sgi.com>,
Suresh Siddha <suresh.b.siddha@intel.com>,
linux-kernel@vger.kernel.org, x86@kernel.org,
Peter Zijlstra <peterz@infradead.org>
Subject: Re: [patch] x86, pat: freeing invalid memtype messages
Date: Mon, 21 Jun 2010 18:56:30 +0800 [thread overview]
Message-ID: <4C1F455E.6050502@redhat.com> (raw)
In-Reply-To: <20100618175726.GA2785@joi.lan>
On 06/19/2010 01:57 AM, Marcin Slusarz wrote:
> On Fri, Jun 18, 2010 at 02:47:45PM +0800, Xiaotian Feng wrote:
>> On 06/18/2010 12:17 AM, Marcin Slusarz wrote:
>>> On Thu, Jun 17, 2010 at 03:45:59PM +0200, Dan Carpenter wrote:
>>>> Commit 20413f27163 "x86, pat: Fix memory leak in free_memtype" added an
>>>> error message in free_memtype() if rbt_memtype_erase() returns NULL.
>>>> The problem is that if CONFIG_X86_PAT is enabled, we use a different
>>>> implimentation of rbt_memtype_erase() that always returns NULL.
>>>>
>>>> I've modified rbt_memtype_erase() to return an ERR_PTR() on errors and
>>>> made free_memtype() check for that instead.
>>>>
>>>> Addresses: https://bugzilla.kernel.org/show_bug.cgi?id=16205
>>>>
>>>> Signed-off-by: Dan Carpenter<error27@gmail.com>
>>>
>>> This patch is probably ok, but it does not address my bug.
>>> I have CONFIG_X86_PAT=y, so rbt_memtype_erase does not always return NULL.
>>
>> Could you please try boot with kernel parameter "debugpat", and
>> show me the output of reserve_memtype/free_memtype ?
>>
>>
>
>
> http://kadu.net/~joi/kernel/2010.06.09/2.6.35-rc3-debugpat.txt
That's quite weird, from the above log:
[ 1.787891] reserve_memtype added 0xbf799000-0xbf79a000, track uncached-minus, req uncached-minus, ret uncached-minus
[ 1.791029] free_memtype request 0xbf799000-0xbf79a000
[ 1.791822] reserve_memtype added 0xbf799000-0xbf79a000, track uncached-minus, req uncached-minus, ret uncached-minus
[ 1.794998] swapper:1 freeing invalid memtype bf799000-bf79a000
[ 1.795795] reserve_memtype added 0xbf799000-0xbf79a000, track uncached-minus, req uncached-minus, ret uncached-minus
[ 1.798979] free_memtype request 0xbf799000-0xbf79a000
[ 1.799775] Overlap at 0xbf799000-0xbf79a000
[ 22.271353] reserve_memtype added 0xd0a40000-0xd0a50000, track write-combining, req write-combining, ret write-combining
[ 22.275707] free_memtype request 0xd0a40000-0xd0a50000
[ 23.209570] reserve_memtype added 0xd0a40000-0xd0a50000, track write-combining, req write-combining, ret write-combining
[ 23.213888] X:2538 freeing invalid memtype d0a40000-d0a50000
[ 23.214065] reserve_memtype added 0xd0a40000-0xd0a50000, track write-combining, req write-combining, ret write-combining
[ 23.218415] free_memtype request 0xd0a40000-0xd0a50000
[ 26.028404] Overlap at 0xd0a40000-0xd0a50000
So it looks like after we free_memtype, reserve the same area again, then free_memtype again showed us the invalid memtype (was not found in rbtree).
But the third time reserve_memtype found overlap (it's in rbtree)...
I guess there might be something wrong between the augmented rbtree insert/remove ..
(Cc'ed Peter)
>
> Marcin
>
next prev parent reply other threads:[~2010-06-21 10:56 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-17 13:45 [patch] x86, pat: freeing invalid memtype messages Dan Carpenter
2010-06-17 16:17 ` Marcin Slusarz
2010-06-17 16:33 ` Dan Carpenter
2010-06-18 1:58 ` Xiaotian Feng
2010-06-18 6:47 ` Xiaotian Feng
2010-06-18 17:57 ` Marcin Slusarz
2010-06-21 10:56 ` Xiaotian Feng [this message]
2010-06-21 11:02 ` Peter Zijlstra
2010-06-21 11:07 ` Xiaotian Feng
2010-06-21 15:33 ` Marcin Slusarz
2010-06-21 15:41 ` Peter Zijlstra
2010-06-21 17:54 ` Suresh Siddha
2010-06-21 18:08 ` Venkatesh Pallipadi
2010-06-21 18:38 ` Venkatesh Pallipadi
2010-06-21 18:41 ` Marcin Slusarz
2010-06-21 18:56 ` Marcin Slusarz
2010-06-22 2:45 ` Xiaotian Feng
2010-06-22 3:47 ` Venkatesh Pallipadi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C1F455E.6050502@redhat.com \
--to=dfeng@redhat.com \
--cc=error27@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=marcin.slusarz@gmail.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=steiner@sgi.com \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=venkatesh.pallipadi@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.