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 d
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,
> > >
> > > >
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 reprodu
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_de
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.
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_ s
