Re: WARNING in dma_map_page_attrs
On Mon, Oct 26, 2020 at 05:23:48AM +, Parav Pandit wrote: > Hi Christoph, > > > From: Jakub Kicinski > > Sent: Saturday, October 24, 2020 11:45 PM > > > > CC: rdma, looks like rdma from the stack trace > > > > On Fri, 23 Oct 2020 20:07:17 -0700 syzbot wrote: > > > syzbot has found a reproducer for the following issue on: > > > > > > HEAD commit:3cb12d27 Merge tag 'net-5.10-rc1' of > > > git://git.kernel.org/.. > > In [1] you mentioned that dma_mask should not be set for dma_virt_ops. > So patch [2] removed it. > > But check to validate the dma mask for all dma_ops was added in [3]. > > What is the right way? Did I misunderstood your comment about dma_mask in [1]? No, I did not say we don't need the mask. I said copying over the various dma-related fields from the parent is bogus. I think rxe (and ther other drivers/infiniband/sw drivers) need a simple dma_coerce_mask_and_coherent and nothing else.
Re: WARNING in dma_map_page_attrs
On Tue, Oct 27, 2020 at 12:52:30PM +, Parav Pandit wrote: > > > From: h...@lst.de > > Sent: Tuesday, October 27, 2020 1:41 PM > > > > On Mon, Oct 26, 2020 at 05:23:48AM +, Parav Pandit wrote: > > > Hi Christoph, > > > > > > > From: Jakub Kicinski > > > > Sent: Saturday, October 24, 2020 11:45 PM > > > > > > > > CC: rdma, looks like rdma from the stack trace > > > > > > > > On Fri, 23 Oct 2020 20:07:17 -0700 syzbot wrote: > > > > > syzbot has found a reproducer for the following issue on: > > > > > > > > > > HEAD commit:3cb12d27 Merge tag 'net-5.10-rc1' of > > git://git.kernel.org/.. > > > > > > In [1] you mentioned that dma_mask should not be set for dma_virt_ops. > > > So patch [2] removed it. > > > > > > But check to validate the dma mask for all dma_ops was added in [3]. > > > > > > What is the right way? Did I misunderstood your comment about > > dma_mask in [1]? > > > > No, I did not say we don't need the mask. I said copying over the various > > dma-related fields from the parent is bogus. > > > > I think rxe (and ther other drivers/infiniband/sw drivers) need a simple > > dma_coerce_mask_and_coherent and nothing else. > > I see. Does below fix make sense? > Is DMA_MASK_NONE correct? DMA_MASK_NONE is gone in 5.10. I think you want DMA_BIT_MASK(64). That isn't actually correct for 32-bit platforms, but good enough.
Re: [RFC PATCH v3 00/11] NVMeTCP Offload ULP and QEDN Device Driver
On Thu, Feb 18, 2021 at 06:38:07PM +, Shai Malin wrote: > So, as there are no more comments / questions, we understand the direction > is acceptable and will proceed to the full series. I do not think we should support offloads at all, and certainly not onces requiring extra drivers. Those drivers have caused unbelivable pain for iSCSI and we should not repeat that mistake.
Re: net/smc and the RDMA core
On Thu, May 11, 2017 at 06:50:04PM +0200, Ursula Braun wrote: > Please consider the following patch to make users aware of the > security implications through existing mechanisms. Any such patch would be in addition to the BROKEN marker until there is an actual alternative. > + rmb_desc->mr_rx[SMC_SINGLE_LINK] = > + lgr->lnk[SMC_SINGLE_LINK].roce_pd->__internal_mr; And it's named __internal_mr for reason. The right interface to use the unsafe rkey is to use pd->unsafe_global_rkey.
Re: net/smc and the RDMA core
On Thu, May 04, 2017 at 11:43:50AM +0300, Sagi Grimberg wrote: > I would also suggest that you stop exposing the DMA MR for remote > access (at least by default) and use a proper reg_mr operations with a > limited lifetime on a properly sized buffer. Yes, exposing the default DMA MR is a _major_ security risk. As soon as SMC is enabled this will mean a remote system has full read/write access to the local systems memory. There іs a reason why I removed the ib_get_dma_mr function and replaced it with the IB_PD_UNSAFE_GLOBAL_RKEY key that has _UNSAFE_ in the name and a very long comment explaining why, and I'm really disappointed that we got a driver merged that instead of asking on the relevant list on why a change unexpertong a function it needed happened and instead tried the hard way to keep a security vulnerarbility alive.
Re: net/smc and the RDMA core
On Fri, May 05, 2017 at 11:10:17AM -0600, Jason Gunthorpe wrote: > I recommend immediately sending a kconfig patch cc'd to stable making > SMC require CONFIG_BROKEN so that nobody inadvertantly turns it on. Yes, I'll send the patch.
