On Fri, 2018-11-30 at 17:23 -0500, Chuck Lever wrote: > > On Nov 30, 2018, at 5:18 PM, Trond Myklebust < > > trondmy@xxxxxxxxxxxxxxx> wrote: > > > > On Fri, 2018-11-30 at 17:15 -0500, Chuck Lever wrote: > > > > On Nov 30, 2018, at 4:55 PM, Trond Myklebust <trondmy@xxxxxxxxx > > > > > > > > > wrote: > > > > > > > > A call to gss_wrap_req_priv() will end up replacing the > > > > original > > > > array > > > > in rqstp->rq_snd_buf.pages with a new one containing the > > > > encrypted > > > > data. In order to avoid having the rqstp->rq_snd_buf.bvec point > > > > to > > > > the > > > > wrong page data, we need to refresh that too. > > > > > > I would add a note here that this patch fixes a memory leak. And > > > you might want to add a Fixes: tag. > > > > > > > It only applies to new code that went into 4.20, so it won't need > > any > > stable backporting. > > > > That said, I'm realising (slowly - apparently I'm asleep today) > > that > > this is receive side code, so > > > > a) The contents of rq_snd_buf are irrelevant. > > b) We want to beware of changing it while there is a copy in > > rq_private_buf. > > > > IOW: a v4 is forthcoming. > > fwiw, i see the soft IRQ warnings with NFS/RDMA too. > > I would like to turn those into a pr_warn_rate_limited. I don't > see much point in the backtrace blather. > Your initial email mentioned these soft IRQ warnings, but didn't provide an example. Which warnings are these exactly, and where are they coming from? -- -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
