Thread (9 messages) 9 messages, 5 authors, 2012-02-28

Re: [PATCH] tmpfs: security xattr setting on inode creation

From: Ware, Ryan R <hidden>
Date: 2012-02-28 03:44:44

On Tue, Feb 28, 2012 at 7:46 AM, Andrew Morton [off-list ref]wrote:
On Fri, 24 Feb 2012 19:19:22 -0800 (PST)
Hugh Dickins [off-list ref] wrote:
quoted
+/*
+ * Callback for security_inode_init_security() for acquiring xattrs.
+ */
+static int shmem_initxattrs(struct inode *inode,
+                         const struct xattr *xattr_array,
+                         void *fs_info)
+{
+     struct shmem_inode_info *info = SHMEM_I(inode);
+     const struct xattr *xattr;
+     struct shmem_xattr *new_xattr;
+     size_t len;
+
+     for (xattr = xattr_array; xattr->name != NULL; xattr++) {
+             new_xattr = shmem_xattr_alloc(xattr->value,
xattr->value_len);
quoted
+             if (!new_xattr)
+                     return -ENOMEM;
+
+             len = strlen(xattr->name) + 1;
+             new_xattr->name = kmalloc(XATTR_SECURITY_PREFIX_LEN + len,
+                                       GFP_KERNEL);
+             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.

Ryan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help