On Wed, Oct 22, 2014 at 03:22:58PM -0400, J. Bruce Fields wrote: > On Tue, Oct 21, 2014 at 09:14:06AM -0400, J. Bruce Fields wrote: > > Also my tests are failing due to an unrelated crash in 18-rc1 which I > > want to track down before sending this in. > > There are two bugs: > > - the client is sending SEEK over minorversion 1. > - this sometimes causes the server to crash. > > I'm testing a fix for the latter. > > On the former: looks like if 4.2 support is built in, then llseek is set > to nfs4_file_llseek, which unconditionally calls nfs42_proc_llseek(). > > Does nfs4_file_llseek need an explicit minorversion check, or should it > be handled some other way? By the way, a purely theoretical issue for now, but: on unknown operations the server returns either NFS4ERR_OP_ILLEGAL or NFS4ERR_OP_NOTSUPP depending on whether we think it's in the range of defined nfs4.2 operations. That means that if a revision of the 4.2 draft adds a new operation beyond the current end (OP_WRITE_SAME = 70), a client would need to be prepared for old servers returning OP_ILLEGAL to that operation. Freezing the definitions of the ops and attributes we care about may not be quite enough to make implementing-as-we-go-along work? --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
