On Fri, Jun 19, 2015 at 11:30:50AM +0100, vigne...@codeaurora.org wrote:
> >> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> >> index 5405aff5a590..7913386ca506 100644
> >> --- a/mm/kmemleak.c
> >> +++ b/mm/kmemleak.c
> >> @@ -194,6 +194,8 @@ static struct kmem_cache *scan_area_cache;
> >>
> >> /* s
>>
>> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
>> index 5405aff5a590..7913386ca506 100644
>> --- a/mm/kmemleak.c
>> +++ b/mm/kmemleak.c
>> @@ -194,6 +194,8 @@ static struct kmem_cache *scan_area_cache;
>>
>> /* set if tracing memory operations is enabled */
>> static int kmemleak_enabled;
>> +
> On Thu, May 21, 2015 at 06:45:17AM +0100, vigne...@codeaurora.org wrote:
>> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
>> index 5ec8b71..4455bb8 100644
>> --- a/mm/kmemleak.c
>> +++ b/mm/kmemleak.c
>> @@ -959,7 +959,7 @@ void __ref kmemleak_free(const void *ptr)
>> {
>> pr_debug("%s(0x%
Hi Vignesh,
Thanks for testing this.
On Thu, May 21, 2015 at 06:45:17AM +0100, vigne...@codeaurora.org wrote:
> diff --git a/mm/kmemleak.c b/mm/kmemleak.c
> index 5ec8b71..4455bb8 100644
> --- a/mm/kmemleak.c
> +++ b/mm/kmemleak.c
> @@ -959,7 +959,7 @@ void __ref kmemleak_free(const void *ptr)
>
> Analysis so far :
>
> I haven't been able to figure out exactly how the dots are connected and
> the relation to the change provided earlier but the following is what i
> could put together :
>
> When i checked the post mortem analysis i see the following in the
> crashing stack :
>
> -018|rb_era
Hi,
Sharing an update. We got back the test results. As such we did not
observe the bug, but we hit another side effect.
After kmemleak was disabled due to low memory
96.825883: <6> kmemleak: Cannot allocate a kmemleak_object structure
96.825902: <6> kmemleak: Cannot allocate a kmeml
>
> kmemleak_disable() may be called in an atomic context, so calling
> kthread_stop() here is not safe. We have a scan_should_stop() function
> which checks for the kmemleak_enabled variable but it doesn't seem to be
> enough.
>
> Basically the object_list has some vmalloc'ed objects. Scanning suc
On Wed, May 13, 2015 at 02:15:08PM +0100, vigne...@codeaurora.org wrote:
> We are seeing a panic in crc32_le after kmemleak_scan(). I have pasted the
> snippet of the crash log below. This is seen on 3.10 Kernel.
>
> This issue was earlier discussed over this thread as well -
> https://lkml.org/lk
We are seeing a panic in crc32_le after kmemleak_scan(). I have pasted the
snippet of the crash log below. This is seen on 3.10 Kernel.
This issue was earlier discussed over this thread as well -
https://lkml.org/lkml/2014/2/6/287.
<4>[ 70.732606] kmemleak: Cannot allocate a kmemleak_object st
9 matches
Mail list logo
