On Apr 23, 2012, at 5:32 PM, Myklebust, Trond wrote: > On Mon, 2012-04-23 at 16:57 -0400, Chuck Lever wrote: >> On Apr 23, 2012, at 4:48 PM, Myklebust, Trond wrote: >> >>> On Mon, 2012-04-23 at 16:44 -0400, Chuck Lever wrote: >>>> Hi- >>>> >>>> I wish you had told me you were going to fix this too. I've been testing a fix for this for a couple weeks. Was going to post this afternoon. Shall I toss mine? >>> >>> I was hitting that BAD_SEQID storm during testing of the other open >>> fixes last week. >> >> Fair enough, but I announced I had a fix in my April 15 status report. Oh well. >> >> So, I decided that a timestamp would leak information about the client, so I'm using a simple counter instead. Would you consider that for your patch? > > How would a timestamp leak useful information? The server and anyone > monitoring the NFS traffic already knows at what time the open owner was > created to within a few milliseconds. It leaks the exact time as the client sees it. This is why time-based UUIDs are no longer considered safe. But also, is it possible that a state_owner could be destroyed and created so quickly on a system with inadequate timestamp resolution, such that the new owner ID would not actually be different than the previous one? -- Chuck Lever chuck[dot]lever[at]oracle[dot]com -- 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
