On Fri, 2013-11-15 at 12:07 -0500, Chuck Lever wrote: +AD4- On Nov 15, 2013, at 12:05 PM, +ACI-Myklebust, Trond+ACI- +ADw-Trond.Myklebust+AEA-netapp.com+AD4- wrote: +AD4- +AD4- +AD4- On Fri, 2013-11-15 at 12:00 -0500, Trond Myklebust wrote: +AD4- +AD4APg- On Fri, 2013-11-15 at 11:38 -0500, Weston Andros Adamson wrote: +AD4- +AD4APgA+- decode+AF8-bitmap will only decode up to three bitmaps. If the xdr buffer +AD4- +AD4APgA+- has more than three bitmaps, return -EIO here instead of bailing out in +AD4- +AD4APgA+- a later xdr decode. +AD4- +AD4APgA+- +AD4- +AD4APg- +AD4- +AD4APg- No. decode+AF8-bitmap will only +AF8-save+AF8- 3 words in the bitmap+AFsAXQ- argment, but +AD4- +AD4APg- it will decode arbitrary sized bitmaps: +AD4- +AD4APg- +AD4- +AD4APg- p +AD0- xdr+AF8-inline+AF8-decode(xdr, (bmlen +ADwAPA- 2))+ADs- +AD4- +AD4APg- +AD4- +AD4- +AD4- +AD4- That said, we should probably check that the server isn't setting those +AD4- +AD4- bitmap words to any non-zero values. That would be a reason to return +AD4- +AD4- EIO. +AD4- +AD4- Why wouldn't the client simply warn and ignore the extraneous data? +AD4- ...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+AEA-netapp.com 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
