DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 10EFC20863
Content-Type: text/plain;
        charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: [PATCH v3 3/3] SUNRPC: Ensure we refresh the bvec after
 RPCSEC_GSS encoding
From:   Chuck Lever <chuck.lever@oracle.com>
In-Reply-To: <499a31eab46be4e0ad0ec13e7ae693cd133a0444.camel@hammerspace.com>
Date:   Fri, 30 Nov 2018 17:31:31 -0500
Cc:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F42A4A1-59EA-4467-8FC1-40E1872351B8@oracle.com>
References: <20181130215555.91107-1-trond.myklebust@hammerspace.com>
 <20181130215555.91107-2-trond.myklebust@hammerspace.com>
 <20181130215555.91107-3-trond.myklebust@hammerspace.com>
 <E9450F2D-D888-4EFC-B0BD-6506E4EC2887@oracle.com>
 <545d13619ffe92a69097f8f68fc36df85944cac2.camel@hammerspace.com>
 <7B7D615F-8A5B-4EBD-96DC-FDDA9DC35DD9@oracle.com>
 <499a31eab46be4e0ad0ec13e7ae693cd133a0444.camel@hammerspace.com>
To:     Trond Myklebust <trondmy@hammerspace.com>
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk


> On Nov 30, 2018, at 5:30 PM, Trond Myklebust <trondmy@hammerspace.com> =
wrote:
>=20
> On Fri, 2018-11-30 at 17:23 -0500, Chuck Lever wrote:
>>> On Nov 30, 2018, at 5:18 PM, Trond Myklebust <
>>> trondmy@hammerspace.com> wrote:
>>>=20
>>> On Fri, 2018-11-30 at 17:15 -0500, Chuck Lever wrote:
>>>>> On Nov 30, 2018, at 4:55 PM, Trond Myklebust <trondmy@gmail.com
>>>>>>=20
>>>>> wrote:
>>>>>=20
>>>>> 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.
>>>>=20
>>>> I would add a note here that this patch fixes a memory leak. And
>>>> you might want to add a Fixes: tag.
>>>>=20
>>>=20
>>> It only applies to new code that went into 4.20, so it won't need
>>> any
>>> stable backporting.
>>>=20
>>> That said, I'm realising (slowly - apparently I'm asleep today)
>>> that
>>> this is receive side code, so
>>>=20
>>> 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.
>>>=20
>>> IOW: a v4 is forthcoming.
>>=20
>> fwiw, i see the soft IRQ warnings with NFS/RDMA too.
>>=20
>> I would like to turn those into a pr_warn_rate_limited. I don't
>> see much point in the backtrace blather.
>>=20
>=20
> 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