| Message ID | 8ed506ba-ae7b-af27-2d2a-9a434c22353c@grimberg.me (mailing list archive) |
|---|---|
| State | Not Applicable |
| Headers | show |
On Sun, 2017-04-23 at 17:35 +0300, Sagi Grimberg wrote: > > > > I actually answered here: > > https://www.spinics.net/lists/linux-rdma/msg46412.html > > Did anything progress with the debug? > > > > > Sagi, > > As you mentioned the IO path is different in SRP and iSER so IMO we > > should start with SRP debugging. NVMf is similar to iSER (and not > > SRP) > > and that's why I think we can apply this patchset. > > My concern is that this might be broken due to the fact that we don't > know what triggers this. > > > > > If you want to wait till we debug SRP issue it's fine, but I can't > > repro > > it in my lab so it can take longer. > > I'd prefer not to take a non-mandatory feature that is not guaranteed > to work. Indeed. I've left this series on hold (actually, I've removed it from patchworks). When we get this straightened, then please resubmit.
On 5/1/2017 9:50 PM, Doug Ledford wrote: > On Sun, 2017-04-23 at 17:35 +0300, Sagi Grimberg wrote: >>> >>> I actually answered here: >>> https://www.spinics.net/lists/linux-rdma/msg46412.html >> >> Did anything progress with the debug? >> >>> >>> Sagi, >>> As you mentioned the IO path is different in SRP and iSER so IMO we >>> should start with SRP debugging. NVMf is similar to iSER (and not >>> SRP) >>> and that's why I think we can apply this patchset. >> >> My concern is that this might be broken due to the fact that we don't >> know what triggers this. >> >>> >>> If you want to wait till we debug SRP issue it's fine, but I can't >>> repro >>> it in my lab so it can take longer. >> >> I'd prefer not to take a non-mandatory feature that is not guaranteed >> to work. > > Indeed. I've left this series on hold (actually, I've removed it from > patchworks). When we get this straightened, then please resubmit. > Sure, no problem. Max. -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
----- Original Message ----- > From: "Max Gurtovoy" <maxg@mellanox.com> > To: "Doug Ledford" <dledford@redhat.com>, "Sagi Grimberg" <sagi@grimberg.me>, "Leon Romanovsky" <leon@kernel.org> > Cc: "Bart Van Assche" <Bart.VanAssche@sandisk.com>, hch@lst.de, "keith busch" <keith.busch@intel.com>, > linux-nvme@lists.infradead.org, linux-rdma@vger.kernel.org, vladimirk@mellanox.com > Sent: Tuesday, May 2, 2017 12:14:33 PM > Subject: Re: [PATCH v2 0/4] arbitrary sg lists support > > > > On 5/1/2017 9:50 PM, Doug Ledford wrote: > > On Sun, 2017-04-23 at 17:35 +0300, Sagi Grimberg wrote: > >>> > >>> I actually answered here: > >>> https://www.spinics.net/lists/linux-rdma/msg46412.html > >> > >> Did anything progress with the debug? > >> > >>> > >>> Sagi, > >>> As you mentioned the IO path is different in SRP and iSER so IMO we > >>> should start with SRP debugging. NVMf is similar to iSER (and not > >>> SRP) > >>> and that's why I think we can apply this patchset. > >> > >> My concern is that this might be broken due to the fact that we don't > >> know what triggers this. > >> > >>> > >>> If you want to wait till we debug SRP issue it's fine, but I can't > >>> repro > >>> it in my lab so it can take longer. > >> > >> I'd prefer not to take a non-mandatory feature that is not guaranteed > >> to work. > > > > Indeed. I've left this series on hold (actually, I've removed it from > > patchworks). When we get this straightened, then please resubmit. > > > > Sure, no problem. > > Max. > -- > To unsubscribe from this list: send the line "unsubscribe linux-rdma" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Max The setup is in place, send me whatever it is you need for debug here. Patches, instrumentation etc. I will be happy to gather the debug. Regards Laurence -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c index d9c6c0ea750b..040fbc387e4f 100644 --- a/drivers/infiniband/hw/mlx5/mr.c +++ b/drivers/infiniband/hw/mlx5/mr.c @@ -1403,6 +1403,8 @@ mlx5_alloc_priv_descs(struct ib_device *device, int add_size; int ret; + WARN_ON_ONCE(ndescs > device->attr.max_fast_reg_page_list_len); + add_size = max_t(int, MLX5_UMR_ALIGN - ARCH_KMALLOC_MINALIGN, 0); mr->descs_alloc = kzalloc(size + add_size, GFP_KERNEL);