public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@cs.helsinki.fi>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Christian Casteyde <casteyde.christian@free.fr>,
	vegard.nossum@gmail.com
Subject: Re: [PATCH] kmemleak: Do not enable KMEMCHECK_PARTIAL_OK if	DEBUG_KMEMLEAK
Date: Wed, 27 Jan 2010 17:09:50 +0200	[thread overview]
Message-ID: <4B60573E.7080108@cs.helsinki.fi> (raw)
In-Reply-To: <1264590127.15957.14.camel@pc1117.cambridge.arm.com>

Catalin Marinas wrote:
> Hi Pekka,
> 
> On Wed, 2010-01-27 at 06:30 +0000, Pekka Enberg wrote:
>> Catalin Marinas kirjoitti:
>>> diff --git a/lib/Kconfig.kmemcheck b/lib/Kconfig.kmemcheck
>>> index 846e039..80660e9 100644
>>> --- a/lib/Kconfig.kmemcheck
>>> +++ b/lib/Kconfig.kmemcheck
>>> @@ -75,7 +75,7 @@ config KMEMCHECK_SHADOW_COPY_SHIFT
>>>  config KMEMCHECK_PARTIAL_OK
>>>       bool "kmemcheck: allow partially uninitialized memory"
>>>       depends on KMEMCHECK
>>> -     default y
>>> +     default y if !DEBUG_KMEMLEAK
>>>       help
>>>         This option works around certain GCC optimizations that produce
>>>         32-bit reads from 16-bit variables where the upper 16 bits are
>>>
>> Disabling KMEMCHECK_PARTIAL_OK can cause other false positives so maybe
>> we should add a new function to kmemcheck for kmemleak that only reads
>> full intervals?
> 
> There are two uses of kmemcheck_is_obj_initialized() in kmemleak: (1)
> before reading a value to check for valid pointer (sizeof long) and (2)
> before computing a CRC sum.
> 
> (1) is fine since it only does this for sizeof(long) before reading the
> same size. (2) has an issues since kmemleak checks the size of an
> allocated memory block while crc32 reads individual u32's.
> 
> Is there a way in kmemcheck to mark a false positive?

IIRC, no. The false positives come from the code generated by GCC so 
we'd need to sprinkle annotations here and there.

> The alternative, assuming that CRC_LE_BITS is 8 (that's what it seems to
> be defined to), the crc32 computation uses u32 values and something like
> below should work, though slower (not yet tested):
> 
> 
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 5b069e4..dfd39ba 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -948,6 +948,25 @@ EXPORT_SYMBOL(kmemleak_no_scan);
>  /*
>   * Update an object's checksum and return true if it was modified.
>   */
> +#ifdef CONFIG_KMEMCHECK_PARTIAL_OK
> +static bool update_checksum(struct kmemleak_object *object)
> +{
> +	u32 crc = 0;
> +	unsigned long ptr;
> +
> +	for (ptr = ALIGN(object->pointer, 4);
> +	     ptr < ((object->pointer + object->size) & ~3); ptr += 4) {
> +		if (!kmemcheck_is_obj_initialized(ptr, 4))
> +			continue;
> +		crc = crc32(crc, (void *)ptr, 4);
> +	}
> +
> +	if (object->checksum == crc)
> +		return false;
> +	object->checksum = crc;
> +	return true;

I think it would be better to add a function to _kmemcheck_ that checks 
the full object regardless of CONFIG_KMEMCHECK_PARTIAL_OK and use it here.

> +}
> +#else	/* !CONFIG_KMEMCHECK_PARTIAL_OK */
>  static bool update_checksum(struct kmemleak_object *object)
>  {
>  	u32 old_csum = object->checksum;
> @@ -958,6 +977,7 @@ static bool update_checksum(struct kmemleak_object *object)
>  	object->checksum = crc32(0, (void *)object->pointer, object->size);
>  	return object->checksum != old_csum;
>  }
> +#endif	/* CONFIG_KMEMCHECK_PARTIAL_OK */
>  
>  /*
>   * Memory scanning is a long process and it needs to be interruptable. This
> 
> 


  reply	other threads:[~2010-01-27 15:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-26 17:57 [PATCH] kmemleak: Do not enable KMEMCHECK_PARTIAL_OK if DEBUG_KMEMLEAK Catalin Marinas
2010-01-27  6:30 ` Pekka Enberg
2010-01-27 11:02   ` Catalin Marinas
2010-01-27 15:09     ` Pekka Enberg [this message]
2010-01-29 17:40       ` Catalin Marinas
2010-01-30  8:22         ` Pekka Enberg

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=4B60573E.7080108@cs.helsinki.fi \
    --to=penberg@cs.helsinki.fi \
    --cc=akpm@linux-foundation.org \
    --cc=casteyde.christian@free.fr \
    --cc=catalin.marinas@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vegard.nossum@gmail.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