On Wed, 2011-03-23 at 01:39 +0300, Vitaliy Gusev wrote: > On Tue, 2011-03-22 at 17:46 -0400, Trond Myklebust wrote: > > > Why are you limiting this to fs_locations? > > Sorry, I haven't seen any other attribute that can cause memory > corruption. decode_attr_filehandle() will certainly cause an Oops if someone inserts one. There may be more occurrences in the future if/when we need to add support for more attributes. > > As I believe I said earlier, > > any attribute that we didn't explicitly request is an error and can > > cause corruption in the client. > > There are checks on each decode attr function. For instance, > decode_attr_filehandle: > > if (unlikely(bitmap[0] & (FATTR4_WORD0_FILEHANDLE - 1U))) > return -EIO; > > So any non handled attribute raise EIO error. If we're going to do this, then I suggest we add an 'expected bitmask' argument to 'decode_attr_bitmap()'. If the server sets any bit that is not part of this expected bitmask, then we can immediately return an EIO without having to decode any further. That will allow us to get rid of the 'if (unlikely(bitmap[] & ....)' tests altogether. -- 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
