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. --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 > > -- 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
