> On Nov 30, 2018, at 5:30 PM, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > > 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? The WARN_ON in call_decode that fires when rq_rcv_buf does not exactly match rq_private_buf. -- Chuck Lever
