From: Ben Greear <greearb@candelatech.com>
To: David Rientjes <rientjes@google.com>
Cc: linux-kernel@vger.kernel.org, Pekka Enberg <penberg@kernel.org>,
Christoph Lameter <cl@linux.com>
Subject: Re: [PATCH 2/2] slub: Add method to verify memory is not deleted.
Date: Mon, 27 Jun 2011 16:46:56 -0700 [thread overview]
Message-ID: <4E091670.9040405@candelatech.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1106271622510.24211@chino.kir.corp.google.com>
On 06/27/2011 04:28 PM, David Rientjes wrote:
> On Mon, 27 Jun 2011, greearb@candelatech.com wrote:
>
>> From: Ben Greear<greearb@candelatech.com>
>>
>> This is for tracking down suspect memory usage.
>>
>
> Several things wrong with this:
>
> - I have no idea where patch 1/2 is.
It was sent to lkml...should show up soon.
> - the subject line is ambiguous, when you say memory is "deleted," I
> thought at first you were talking about hot-removed, but it seems like
> you're talking about "freed."
Ok, I can fix that. I'm talking about memory that was freed.
>
> - what "suspect memory usage" are you adding functionality to catch and
> how are you doing it?
I saw a case where xprt was 0x6b6b6b6b. I'm trying to figure out
what freed it. I am not certain if this is a bug I introduced in
some nfs changes I am testing, or if it is in a standard kernel.
I am unable to reproduce it in standard kernel, but that is partly
because my test case depends on my nfs patches.
The code below contains my debugging hacks, definitely not
for kernel inclusion as is.
/*
* Rpcbind child task calls this callback via tk_exit.
*/
static void rpcb_getport_done(struct rpc_task *child, void *data)
{
struct rpcbind_args *map = data;
struct rpc_xprt *xprt = map->r_xprt;
int status = child->tk_status;
verify_mem_not_deleted(map);
verify_mem_not_deleted(xprt);
BUG_ON((unsigned int)(map) == (unsigned int)(0x6b6b6b6b));
if ((unsigned int)(xprt) == (unsigned int)(0x6b6b6b6b)) {
printk("xprt: %p is invalid, which means map: %p is likely deleted already.\n",
xprt, map);
printk("map: r_owner: %p r_prog: %u r_status: %u\n",
map->r_owner, map->r_prog, map->r_status);
printk("child: %p status: %i\n", child, status);
BUG_ON(1);
}
BUG_ON((unsigned int)(status) == (unsigned int)(0x6b6b6b6b));
> - you didn't cc the slab maintainers, Pekka Enberg and Christoph Lameter
> (I added them).
Thanks for that.
>> +/** Calling this on deleted objects will print some
>> + * SLUB debugging information.
>> + */
>
> Ambiguous as to what it will be printing and violation of the comment
> style used in the kernel (see Documentation/CodingStyle).
>
>> +#if defined(CONFIG_SLUB)&& defined(CONFIG_SLUB_DEBUG)
>> +extern bool verify_mem_not_deleted(const void *x);
>> +#else
>> +#define verify_mem_not_deleted(x)
>
> This will surely break if anybody isn't using slub or CONFIG_SLUB_DEBUG
> and it testing verify_mem_not_deleted(). You probably want
>
> static inline bool verify_mem_not_deleted(const void *x)
> {
> return false;
> }
Ok.
>
>> +#endif
>> +
>> /*
>> * Shortcuts
>> */
>> diff --git a/mm/slub.c b/mm/slub.c
>> index 14d0135..b3d7680 100644
>> --- a/mm/slub.c
>> +++ b/mm/slub.c
>> @@ -2953,6 +2953,40 @@ size_t ksize(const void *object)
>> }
>> EXPORT_SYMBOL(ksize);
>>
>> +#if defined(CONFIG_SLUB_DEBUG)
>
> #ifdef CONFIG_SLUB_DEBUG
>
>> +bool verify_mem_not_deleted(const void *x)
>> +{
>> + struct page *page;
>> + void *object = (void *)x;
>> + struct kmem_cache *s;
>> + unsigned long flags;
>> + bool rv = false;
>> +
>> + if (unlikely(ZERO_OR_NULL_PTR(x)))
>> + false;
>> +
>
> Did you even compile-test this?
Well yes, but obviously I'm having a bad day!
Aside from the lame mistakes in my patch..is the general approach
usable?
>> + local_irq_save(flags);
>> +
>> + page = virt_to_head_page(x);
>> + if (unlikely(!PageSlab(page))) {
>> + BUG_ON(!PageCompound(page));
>
> Why is there a BUG_ON() here if we didn't pass a pointer to a slab object?
Just copying the kfree code. Just return 'true' in this case?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
next prev parent reply other threads:[~2011-06-27 23:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-27 23:17 [PATCH 0/2] SLUB memory debugging improvements greearb
2011-06-27 23:17 ` [PATCH 1/2] slub: Enable backtrace for create/delete points greearb
2011-06-27 23:17 ` [PATCH 2/2] slub: Add method to verify memory is not deleted greearb
2011-06-27 23:28 ` David Rientjes
2011-06-27 23:46 ` Ben Greear [this message]
2011-06-28 0:18 ` Ben Greear
2011-06-28 0:19 ` David Rientjes
2011-06-28 0:24 ` Ben Greear
2011-06-28 3:45 ` Ben Greear
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=4E091670.9040405@candelatech.com \
--to=greearb@candelatech.com \
--cc=cl@linux.com \
--cc=linux-kernel@vger.kernel.org \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox