Re: [PATCH rdma-next v7 0/8] RDMA resource tracking

[Laurence Oberman <loberman-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

On Tue, 2018-01-30 at 21:22 +0000, Bart Van Assche wrote:
> On Tue, 2018-01-30 at 13:48 -0700, Jason Gunthorpe wrote:
> > Ok, I think that is the only likely thing recently..
> > 
> > But your print above must be caused by this line, right:
> > 
> > static struct srp_fr_pool *srp_create_fr_pool(struct ib_device
> > *device,
> >                                               struct ib_pd *pd, int
> > pool_size,
> >                                               int
> > max_page_list_len)
> > {
> >         ret = -ENOMEM;
> >         pool = kzalloc(sizeof(struct srp_fr_pool) +
> >                        pool_size * sizeof(struct srp_fr_desc),
> > GFP_KERNEL);
> >         if (!pool)
> >                 goto err;
> > 
> > Since you didn't report the ib_alloc_mr() print it can't be the
> > other
> > ENOMEM case?
> > 
> > Hard to see how that interesects with resource tracking.. Are you
> > thinking memory corruption?
> 
> Hello Jason,
> 
> I don't see any reason to suspect memory corruption. kmemleak isn't
> reporting
> any memory leaks. Maybe memory fragmentation has increased?
> 
> Thanks,
> 
> Bart.NrybXǧv^)޺{.n+{ٚ{ay\x1d
ʇڙ,j\afhz\x1e
w\f
j:+vwjm\azZ+ݢj"!

Hi Bart, 

Can I take your tree and see if this fails for me too,
Your last tree was fine, so did not have this latest stuff.
Can I just pull to what I have

Thanks
Laurence
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html