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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
