On Thu, 2017-10-12 at 21:52 -0400, J. Bruce Fields wrote: > On Thu, Oct 12, 2017 at 03:00:51PM -0700, Tom Haynes wrote: > > On Thu, Oct 12, 2017 at 05:44:54PM -0400, J. Bruce Fields wrote: > > > Your mailer's not quoting right, it's a little hard for me to > > > find your > > > replies. Wading in: > > > > > > On Thu, Oct 12, 2017 at 09:39:04PM +0000, Thomas Haynes wrote: > > > > On Oct 12, 2017, at 12:49 PM, J. Bruce Fields <bfields@fieldses > > > > .org<mailto:bfields@xxxxxxxxxxxx>> wrote: > > > > > So I *think* the only correct options OK or FALSE_RETRY? > > > > > > > > It can’t be OK if the parameters to SEQUENCE differ. > > > > > > I'm getting that from: "When the replier detects a false retry, > > > it is > > > permitted (but not always obligated) to return > > > NFS4ERR_FALSE_RETRY in > > > response to the Sequence operation when it detects a false > > > retry." > > > > I think you are agreeing with me that OK is not appropriate here? > > No, I think OK is OK: > > > > If i understand the following language, we're required to return > > > FALSE_RETRY in the case the rpc credentials of the caller map to > > > different principals, but not otherwise. > > > > This one drove me crazy: > > > > If a requester sent a Sequence operation with a slot ID and > > sequence > > ID that are in the reply cache but the replier detected that the > > retried request is not the same as the original request, > > including a > > retry that has different operations or different arguments in > > the > > operations from the original > > > > SEQUENCE is not special - both the compounds in this example > > only have the SEQUENCE op and they differ only in that in the > > first sa_cachethis is False and in the second it is True. > > > > So we have to return FALSE_SEQ_RETRY here... > > It says "if the replier detected" a difference, not "if there is" a > difference. So the replier is not required to do such > detection. This > agrees with the "not always obligated" above. > > So I think it's allowed for the server to just return an old cached > response here (with the cached OK). And I can't see any practical > problem that would create--a client shouldn't be sending a different > request with the same (slot, sequence) anyway. The only potential > risk > is the malicious client trying to snoop somebody else's reply cache, > hence the requirement in the case principals differ. Clients may indeed send a different request with the same slot and sequence if they don't know that the server received the last request. This is tbe "user pressed ^C" scenario... Servers MAY ignore that fact, but they'd be really stupid to do so... > > --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 > -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx ��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
