Return-Path: Date: Tue, 6 Jun 2017 16:56:46 -0400 From: "J. Bruce Fields" To: Chuck Lever Cc: Benjamin Coddington , Linux NFS Mailing List Subject: Re: GSS sequence number window Message-ID: <20170606205646.GJ13376@fieldses.org> References: <20170531192231.GA23526@fieldses.org> <28665890-C74A-4319-B42E-475393821EC7@oracle.com> <20170606194158.GG13376@fieldses.org> <4D542D55-DCBA-4838-9DB2-B76B4068783E@oracle.com> <20170606201504.GH13376@fieldses.org> <20170606202307.GI13376@fieldses.org> <2ED4D9A9-08B4-499C-BB76-EFCC5108D2FA@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: <2ED4D9A9-08B4-499C-BB76-EFCC5108D2FA@oracle.com> List-ID: On Tue, Jun 06, 2017 at 04:54:51PM -0400, Chuck Lever wrote: > > > On Jun 6, 2017, at 4:23 PM, J. Bruce Fields 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 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 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.