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 ʇڙ,jfhz w j:+vwjmzZ+ݢ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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
