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