Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751616AbbHTCyf (ORCPT ); Wed, 19 Aug 2015 22:54:35 -0400 Received: from cn.fujitsu.com ([59.151.112.132]:25898 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750874AbbHTCyd convert rfc822-to-8bit (ORCPT ); Wed, 19 Aug 2015 22:54:33 -0400 X-IronPort-AV: E=Sophos;i="5.15,520,1432569600"; d="scan'208";a="99829347" Message-ID: <55D54006.9030700@cn.fujitsu.com> Date: Thu, 20 Aug 2015 10:48:38 +0800 From: Dongsheng Yang User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Richard Weinberger , CC: , , Subodh Nijsure , Marc Kleine-Budde , Brad Mouring , Gratian Crisan , Artem Bityutskiy , Artem Bityutskiy Subject: Re: [PATCH 1/2] ubifs: Remove dead xattr code References: <1440016553-26481-1-git-send-email-richard@nod.at> In-Reply-To: <1440016553-26481-1-git-send-email-richard@nod.at> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8BIT X-Originating-IP: [10.167.226.66] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4560 Lines: 126 On 08/20/2015 04:35 AM, Richard Weinberger wrote: > This is a partial revert of commit d7f0b70d30ffb9bbe6b8a3e1035cf0b79965ef53 > ("UBIFS: Add security.* XATTR support for the UBIFS"). Hi Richard, What about a full reverting of this commit. In ubifs, we *can* support any namespace of xattr including user, trusted, security or other anyone prefixed by any words. But we have a check_namespace() in xattr.c to limit what we want to support. That said, if we want to "Add security.* XATTR support for the UBIFS", what we need to do is just extending the check_namespace() to allow security namespace pass. And yes, check_namespace() have been supporting security namespace. So, IMHO, we do not depend on the generic mechanism at all, and we can fully revert this commit. But strange to me, why we picked this commit for ubifs? Artem, is there something I am missing? Yang > > As UBIFS does not use generic inode xattr inode operations > the code behind sb->s_xattr is never called. > Remove that dead code for now. > > Cc: Subodh Nijsure > Cc: Marc Kleine-Budde > Cc: Brad Mouring > Cc: Gratian Crisan > Cc: Artem Bityutskiy > Reported-by: Andreas Grünbacher > Signed-off-by: Richard Weinberger > --- > After the merge window (and my vacation) I'll have the time to > re-introduce/work security xattr support. > > Thanks, > //richard > --- > fs/ubifs/super.c | 1 - > fs/ubifs/ubifs.h | 1 - > fs/ubifs/xattr.c | 40 ---------------------------------------- > 3 files changed, 42 deletions(-) > > diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c > index 9547a278..c71edca 100644 > --- a/fs/ubifs/super.c > +++ b/fs/ubifs/super.c > @@ -2037,7 +2037,6 @@ static int ubifs_fill_super(struct super_block *sb, void *data, int silent) > if (c->max_inode_sz > MAX_LFS_FILESIZE) > sb->s_maxbytes = c->max_inode_sz = MAX_LFS_FILESIZE; > sb->s_op = &ubifs_super_operations; > - sb->s_xattr = ubifs_xattr_handlers; > > mutex_lock(&c->umount_mutex); > err = mount_ubifs(c); > diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h > index de75902..33b6ee7 100644 > --- a/fs/ubifs/ubifs.h > +++ b/fs/ubifs/ubifs.h > @@ -1470,7 +1470,6 @@ extern spinlock_t ubifs_infos_lock; > extern atomic_long_t ubifs_clean_zn_cnt; > extern struct kmem_cache *ubifs_inode_slab; > extern const struct super_operations ubifs_super_operations; > -extern const struct xattr_handler *ubifs_xattr_handlers[]; > extern const struct address_space_operations ubifs_file_address_operations; > extern const struct file_operations ubifs_file_operations; > extern const struct inode_operations ubifs_file_inode_operations; > diff --git a/fs/ubifs/xattr.c b/fs/ubifs/xattr.c > index 96f3448..b512b14 100644 > --- a/fs/ubifs/xattr.c > +++ b/fs/ubifs/xattr.c > @@ -582,46 +582,6 @@ out_free: > return err; > } > > -static size_t security_listxattr(struct dentry *d, char *list, size_t list_size, > - const char *name, size_t name_len, int flags) > -{ > - const int prefix_len = XATTR_SECURITY_PREFIX_LEN; > - const size_t total_len = prefix_len + name_len + 1; > - > - if (list && total_len <= list_size) { > - memcpy(list, XATTR_SECURITY_PREFIX, prefix_len); > - memcpy(list + prefix_len, name, name_len); > - list[prefix_len + name_len] = '\0'; > - } > - > - return total_len; > -} > - > -static int security_getxattr(struct dentry *d, const char *name, void *buffer, > - size_t size, int flags) > -{ > - return ubifs_getxattr(d, name, buffer, size); > -} > - > -static int security_setxattr(struct dentry *d, const char *name, > - const void *value, size_t size, int flags, > - int handler_flags) > -{ > - return ubifs_setxattr(d, name, value, size, flags); > -} > - > -static const struct xattr_handler ubifs_xattr_security_handler = { > - .prefix = XATTR_SECURITY_PREFIX, > - .list = security_listxattr, > - .get = security_getxattr, > - .set = security_setxattr, > -}; > - > -const struct xattr_handler *ubifs_xattr_handlers[] = { > - &ubifs_xattr_security_handler, > - NULL, > -}; > - > static int init_xattrs(struct inode *inode, const struct xattr *xattr_array, > void *fs_info) > { > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/