>>
>> 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;
>>
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;
+/* same as above
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
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 consider adding these
> 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)
>> {
>>
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%p)\n, __func__,
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
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 tables.
Hence,
> 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 :
>
>
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
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
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_erase(
>
> 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
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 such
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
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
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(_base->lock);
> + cpu_base->in_hrtirq = 1;
Since
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;
Since this is
18 matches
Mail list logo
