On Mon, Jul 20, 2015 at 04:37:15PM -0500, Steve Wise wrote: > > > > From: Steve Wise [mailto:swise@xxxxxxxxxxxxxxxxxxxxx] > > Sent: Monday, July 20, 2015 4:34 PM > > To: 'Jason Gunthorpe'; 'Tom Talpey' > > Cc: 'Chuck Lever'; 'linux-rdma@xxxxxxxxxxxxxxx'; 'linux-nfs@xxxxxxxxxxxxxxx' > > Subject: RE: [PATCH v3 05/15] xprtrdma: Remove last ib_reg_phys_mr() call site > > > > > > > > > > > Based on that, should we remove the cxgb3 driver as well? Or at least > > > > can you fix it up to at least fail get_dma_mr if there is too much > > > > ram? > > > > > > > > > > I would like to keep cxgb3 around. I can add code to fail if the memory is > 32b. Do you know how I get the amount of > available ram? > > > > > > > Something like this? > > > > @@ -736,6 +736,9 @@ static struct ib_mr *iwch_get_dma_mr(struct ib_pd *pd, int acc) > > /* > > * T3 only supports 32 bits of size. > > */ > > + if ((totalram_pages << PAGE_SHIFT) > 0xffffffff) > > + return -ENOTSUPP; > > oops: ERR_PTR(-ENOTSUPP); > > > + > > bl.size = 0xffffffff; > > bl.addr = 0; > > kva = 0; Yah, that seems much better.. With the patch set I am working on this will mean all ULPs will fail to create a kernel PD on cxgb3 if the above triggers. If our error handling works that should just make it unuable from kernel space which is what we need to see.. To remove the amasso driver, move it to Staging. I don't know the exact details, sorry. Hopefully Doug will be able to help you do that. Maybe add some kind of one time print 'cxgb3 is not usuable on machines with >4G of RAM' as well? Jason -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
