> On Oct 22, 2014, at 12:42 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > >> 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. > Or if the new minor versioning rules take effect... > 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 -- 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
