Re: GSS sequence number window

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

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.

--b.
> 
> 
> >> Even so, how would I detect if this issue was present?
> > 
> > Good question.  If you knew the data and mic in the bad case, and had
> > some way to guess what the previous data might have been based on what
> > you knew about the test, then you could try mic's of likely older
> > versions of the data and see if you get a match....  That sounds hard.
> > 
> > --b.
> 
> --
> Chuck Lever
> 
>