> 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. Even so, how would I detect if this issue was present? > --b. > >> >> I filed https://bugzilla.linux-nfs.org/show_bug.cgi?id=307 >> to document this second issue. >> >> I'm not sure what a next step would be. My suspicion is that >> either the server or the client is mishandling the RPC reply >> buffer, which causes the checksums to be different. Not sure >> why this would be so intermittent, though. -- 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
