On Tue, May 16, 2017 at 04:55:28PM -0700, Andy Lutomirski wrote:
> On Tue, May 16, 2017 at 6:39 AM, Catalin Marinas
> wrote:
> > Thanks for cc'ing me. The vmalloc allocations have always been tricky
> > for kmemleak since there are 2-3 other memory locations with the same
> > value as the vmalloc'
On Tue, May 16, 2017 at 6:39 AM, Catalin Marinas
wrote:
> Thanks for cc'ing me. The vmalloc allocations have always been tricky
> for kmemleak since there are 2-3 other memory locations with the same
> value as the vmalloc'ed object: vm_struct.addr and vmap_area.va_start;
> occasionally we have vm
Thanks for cc'ing me. The vmalloc allocations have always been tricky
for kmemleak since there are 2-3 other memory locations with the same
value as the vmalloc'ed object: vm_struct.addr and vmap_area.va_start;
occasionally we have vmap_area.va_end pointing to the next
vmap_area.va_start.
To have
Let's CC Catalin
this smells like a kmemleak bug to me.
On Mon 15-05-17 23:53:18, Luis R. Rodriguez wrote:
> On Fri, Feb 17, 2017 at 11:32:34AM -0800, Andy Lutomirski wrote:
> > On Fri, Feb 17, 2017 at 9:23 AM, Luis R. Rodriguez
> > wrote:
> > > On Fri, Feb 17, 2017 at 9:07 AM, Andy Lutomirski
On Fri, Feb 17, 2017 at 11:32:34AM -0800, Andy Lutomirski wrote:
> On Fri, Feb 17, 2017 at 9:23 AM, Luis R. Rodriguez wrote:
> > On Fri, Feb 17, 2017 at 9:07 AM, Andy Lutomirski
> > wrote:
> >> But maybe
> >> there really is a race in which a kmemleak check right in the middle
> >> of duplicatin
On Fri, Feb 17, 2017 at 9:23 AM, Luis R. Rodriguez wrote:
> On Fri, Feb 17, 2017 at 9:07 AM, Andy Lutomirski wrote:
>> But maybe
>> there really is a race in which a kmemleak check right in the middle
>> of duplicating the task struct really can't see the stack pointer.
>
> Funny, but it was actu
On Fri, Feb 17, 2017 at 9:07 AM, Andy Lutomirski wrote:
> But maybe
> there really is a race in which a kmemleak check right in the middle
> of duplicating the task struct really can't see the stack pointer.
Funny, but it was actually using kmemleak how I can easily reproduce:
To reproduce the k
On Wed, Feb 8, 2017 at 5:37 PM, Luis R. Rodriguez wrote:
> On Tue, Feb 07, 2017 at 09:03:43AM +0100, Michal Hocko wrote:
>> On Tue 07-02-17 02:37:02, Luis R. Rodriguez wrote:
>> > > From a quick check I do not see any leak there either.
>> >
>> > Then in that case what about:
>>
>> This just disab
On Tue, Feb 07, 2017 at 09:03:43AM +0100, Michal Hocko wrote:
> On Tue 07-02-17 02:37:02, Luis R. Rodriguez wrote:
> > > From a quick check I do not see any leak there either.
> >
> > Then in that case what about:
>
> This just disables the kmemleak altogether which doesn't sound like a
> good id
On Tue 07-02-17 02:37:02, Luis R. Rodriguez wrote:
> On Mon, Feb 06, 2017 at 10:47:41AM +0100, Michal Hocko wrote:
> > On Fri 03-02-17 13:06:04, Luis R. Rodriguez wrote:
> > > On next-20170125 running some kselftest not yet upstream I eventually
> > > get a kmemleak splat:
> > >
> > > unreferenced
On Mon, Feb 06, 2017 at 10:47:41AM +0100, Michal Hocko wrote:
> On Fri 03-02-17 13:06:04, Luis R. Rodriguez wrote:
> > On next-20170125 running some kselftest not yet upstream I eventually
> > get a kmemleak splat:
> >
> > unreferenced object 0xa7b1034b4000 (size 16384):
> > comm "driver_dat
On Fri 03-02-17 13:06:04, Luis R. Rodriguez wrote:
> On next-20170125 running some kselftest not yet upstream I eventually
> get a kmemleak splat:
>
> unreferenced object 0xa7b1034b4000 (size 16384):
> comm "driver_data.sh", pid 6506, jiffies 4295068366 (age 1697.272s)
> hex dump (first 32
On next-20170125 running some kselftest not yet upstream I eventually
get a kmemleak splat:
unreferenced object 0xa7b1034b4000 (size 16384):
comm "driver_data.sh", pid 6506, jiffies 4295068366 (age 1697.272s)
hex dump (first 32 bytes):
9d 6e ac 57 00 00 00 00 74 2d 64 72 69 76 65 72 .
13 matches
Mail list logo
