Re: [PATCH v3 2/5] kmemleak: add clear command support
From: Luis R. Rodriguez
Date: Tue Sep 08 2009 - 12:23:33 EST
On Tue, Sep 8, 2009 at 9:11 AM, Catalin Marinas<catalin.marinas@xxxxxxx> wrote:
>
On Fri, 2009年09月04日 at 17:44 -0700, Luis R. Rodriguez wrote:
>
> Â/*
>
> + * We use grey instead of black to ensure we can do future
>
> + * scans on the same objects. If we did not do future scans
>
> + * these black objects could potentially contain references to
>
> + * newly allocated objects in the future and we'd end up with
>
> + * false positives.
>
> + */
>
> +static void kmemleak_clear(void)
>
> +{
>
> + Â Â struct kmemleak_object *object;
>
> + Â Â unsigned long flags;
>
> +
>
> + Â Â stop_scan_thread();
>
> +
>
> + Â Â rcu_read_lock();
>
> + Â Â list_for_each_entry_rcu(object, &object_list, object_list) {
>
> + Â Â Â Â Â Â spin_lock_irqsave(&object->lock, flags);
>
> + Â Â Â Â Â Â if ((object->flags & OBJECT_REPORTED) &&
>
> + Â Â Â Â Â Â Â Â unreferenced_object(object))
>
> + Â Â Â Â Â Â Â Â Â Â object->min_count = -1;
>
> + Â Â Â Â Â Â spin_unlock_irqrestore(&object->lock, flags);
>
> + Â Â }
>
> + Â Â rcu_read_unlock();
>
> +
>
> + Â Â start_scan_thread();
>
> +}
>
>
Do we need to stop and start the scanning thread here? When starting it,
>
it will trigger a memory scan automatically. I don't think we want this
>
as a side-effect, so I dropped these lines from your patch.
OK thanks.
>
Also you set min_count to -1 here which means black object, so a
>
subsequent patch corrects it. I'll set min_count to 0 here in case
>
anyone bisects over it.
Dah, thanks for catching that, seems I only fixed the named set.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
http://www.tux.org/lkml/