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)); >>>> Oh, yeah. >>> >>> 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. Ok, I’ll rework this. -dros >> >> 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. Anyway, a server that returns > attributes that we haven't requested must clearly be borken. It's > definitely violating the spec. > > -- > Trond Myklebust > Linux NFS client maintainer > > NetApp > Trond.Myklebust@xxxxxxxxxx > www.netapp.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
