Messages in this thread | | | Date | Mon, 27 Feb 2012 20:10:53 -0800 (PST) | From | Hugh Dickins <> | Subject | Re: [PATCH] tmpfs: security xattr setting on inode creation |
| |
On Tue, 28 Feb 2012, Ware, Ryan R wrote: > On Tue, Feb 28, 2012 at 7:46 AM, Andrew Morton <akpm@linux-foundation.org>wrote: > > On Fri, 24 Feb 2012 19:19:22 -0800 (PST) > > Hugh Dickins <hughd@google.com> wrote: > >... > > > + if (!new_xattr->name) { > > > + kfree(new_xattr); > > > + return -ENOMEM; > > > + } > > > + > > > + memcpy(new_xattr->name, XATTR_SECURITY_PREFIX, > > > + XATTR_SECURITY_PREFIX_LEN); > > > + memcpy(new_xattr->name + XATTR_SECURITY_PREFIX_LEN, > > > + xattr->name, len); > > > + > > > + spin_lock(&info->lock); > > > + list_add(&new_xattr->list, &info->xattr_list); > > > + spin_unlock(&info->lock); > > > + } > > > + > > > + return 0; > > > +} > > > > So if there's a kmalloc failure partway through the array, we leave a > > partially xattrified inode in place. > > > > Are we sure this is OK? > > > > I'm guessing Jarkko can clean that up a bit. It wouldn't be a good idea to > leave inaccurate data structures laying around during failure cases.
Andrew raises a good concern, but Jarkko got it just right and no change is needed: any xattrs already allocated are properly linked on info->xattr_list, then when security_inode_init_security() fails (with an error other than EOPNOTSUPP) the failing inode is iput(), which ends up in shmem_evict_inode(), which kfree()s those xattrs (and their names) on info->xattr_list.
Hugh
| |