On Nov 15, 2013, at 12:10 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > On Fri, 2013-11-15 at 12:07 -0500, Chuck Lever wrote: >> On Nov 15, 2013, at 12:05 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: >> >>> On Fri, 2013-11-15 at 12:00 -0500, Trond Myklebust wrote: >>>> On Fri, 2013-11-15 at 11:38 -0500, Weston Andros Adamson wrote: >>>>> decode_bitmap will only decode up to three bitmaps. If the xdr buffer >>>>> has more than three bitmaps, return -EIO here instead of bailing out in >>>>> a later xdr decode. >>>>> >>>> >>>> No. decode_bitmap will only _save_ 3 words in the bitmap[] argment, but >>>> it will decode arbitrary sized bitmaps: >>>> >>>> p = xdr_inline_decode(xdr, (bmlen << 2)); >>>> >>> >>> That said, we should probably check that the server isn't setting those >>> bitmap words to any non-zero values. That would be a reason to return >>> EIO. >> >> Why wouldn't the client simply warn and ignore the extraneous data? >> > > ...because unless the GETATTR is the very last operation, we'd end up > failing to decode things correctly. Surely that's only if the returned bitmap length doesn't match the number of bitmap words returned. The server can return a properly encoded result without overwriting the next operation in the compound, can't it? > Anyway, a server that returns > attributes that we haven't requested must clearly be borken. It's > definitely violating the spec. Definitely, but "be lenient in what you accept." The reason I bring this up is that we had exactly this problem with NFSv4.2, where the third bitmap word was added. Anyway, just an observation. -- 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
