Re: GSS sequence number window

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Jun 06, 2017 at 04:54:51PM -0400, Chuck Lever wrote:
> 
> > On Jun 6, 2017, at 4:23 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> > 
> > On Tue, Jun 06, 2017 at 04:16:53PM -0400, Chuck Lever wrote:
> >> 
> >>> On Jun 6, 2017, at 4:15 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >>> 
> >>> On Tue, Jun 06, 2017 at 03:45:59PM -0400, Chuck Lever wrote:
> >>>> 
> >>>>> On Jun 6, 2017, at 3:41 PM, J. Bruce Fields <bfields@fieldses.org> wrote:
> >>>>> 
> >>>>> On Tue, Jun 06, 2017 at 03:35:23PM -0400, Chuck Lever wrote:
> >>>>>> I filed https://bugzilla.linux-nfs.org/show_bug.cgi?id=306
> >>>>>> 
> >>>>>> To check memory allocation latency, I could always construct
> >>>>>> a framework around kmalloc and alloc_page.
> >>>>>> 
> >>>>>> 
> >>>>>> I've also found some bad behavior around proto=rdma,sec=krb5i.
> >>>>>> When I run a heavy I/O workload (fio, for example), every so
> >>>>>> often a read operation fails with EIO. I dug into it a little
> >>>>>> and MIC verification fails for these replies on the client.
> >>>>> 
> >>>>> Do we still have the problem that the read data can change between the
> >>>>> time we calculate the MIC and the time we transmit the data to the
> >>>>> client?
> >>>> 
> >>>> I don't see a problem with krb5p, which, if IIUC, would also
> >>>> fall victim to this situation, unless there is much stricter
> >>>> request serialization going on with krb5p.
> >>> 
> >>> We turn off zero-copy by clearing RQ_SPLICE_OK in the krb5p case.
> >> 
> >> Seems like this is the right answer for krb5i too. Shall I try that?
> > 
> > Sure!  Just grep around for RQ_SPLICE_OK, I think it should be easy to
> > figure out.
> 
> I added
> 
>         clear_bit(RQ_SPLICE_OK, &rqstp->rq_flags);
> 
> at the top of unwrap_integ_data() in net/sunrpc/auth_gss/svcauth_gss.c.
> 
> I haven't seen a failure yet, which is a good sign.

Well, unfortunately it means the only easy fix we have right now may
cause a performance regression.  Anyway, maybe that's what we should do.

--b.