>>
>> 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;
>> +
Gentle reminder for review comments.
> Forgot to add Maintainers. Adding them now.
>
>> On 05/13/2015 08:20 AM, Vignesh Radhakrishnan wrote:
>>> Functions inside kernel modules that use __ref
>>> will end up being placed in .ARM.exidx.ref.text
>>> section by gcc.
>>>
>>> Currently we don't conside
> 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%
Forgot to add Maintainers. Adding them now.
> On 05/13/2015 08:20 AM, Vignesh Radhakrishnan wrote:
>> Functions inside kernel modules that use __ref
>> will end up being placed in .ARM.exidx.ref.text
>> section by gcc.
>>
>> Currently we don't consider adding these functions
>> to arm unwind table
> 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
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
Hi Thomas,
In this patch, we are only setting the flag
cpu_base->in_hrtirq = 1; in hrtimer_interrupt() and not resetting it.
> @@ -1251,9 +1251,9 @@ void hrtimer_interrupt(struct clock_even
> dev->next_event.tv64 = KTIME_MAX;
>
> raw_spin_lock(&cpu_base->lock);
> + cpu_base->in_hrtirq = 1;
Sinc
9 matches
Mail list logo
