From patchwork Thu Oct 13 21:48:14 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vivek Goyal X-Patchwork-Id: 9375919 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id EFADE60839 for ; Thu, 13 Oct 2016 22:34:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D09E02A1FD for ; Thu, 13 Oct 2016 22:34:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C250F2A1FF; Thu, 13 Oct 2016 22:34:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 5B8732A1FD for ; Thu, 13 Oct 2016 22:34:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756490AbcJMWef (ORCPT ); Thu, 13 Oct 2016 18:34:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53676 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756013AbcJMWef (ORCPT ); Thu, 13 Oct 2016 18:34:35 -0400 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E1ADF4E4CB; Thu, 13 Oct 2016 21:48:15 +0000 (UTC) Received: from horse.redhat.com (dhcp-25-162.bos.redhat.com [10.18.25.162]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9DLmFkk015003; Thu, 13 Oct 2016 17:48:15 -0400 Received: by horse.redhat.com (Postfix, from userid 10451) id EEFDA2043EC; Thu, 13 Oct 2016 17:48:14 -0400 (EDT) Date: Thu, 13 Oct 2016 17:48:14 -0400 From: Vivek Goyal To: CAI Qian Cc: Andreas Gruenbacher , Al Viro , Miklos Szeredi , linux-fsdevel Subject: Re: [bisected] Re: docker overlay support broken post v4.8 Message-ID: <20161013214814.GC7916@redhat.com> References: <530387982.494829.1476280492275.JavaMail.zimbra@redhat.com> <2011297919.807400.1476391103491.JavaMail.zimbra@redhat.com> <20161013211611.GA7916@redhat.com> <20161013213937.GB7916@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20161013213937.GB7916@redhat.com> User-Agent: Mutt/1.7.0 (2016-08-17) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 13 Oct 2016 21:48:15 +0000 (UTC) Sender: linux-fsdevel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fsdevel@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Thu, Oct 13, 2016 at 05:39:37PM -0400, Vivek Goyal wrote: [..] > > > > This message splits in the console. > > > > [61250.857832] SELinux: (dev overlay, type overlay) has no xattr support > > > Reverted the patchset of "Xattr inode operation removal" against the latest mainline > > > fixed the problem, i.e., commits below in order. > > > > > > fd50ecaddf8372a1d96e0daeaac0f93cf04e4d42 > > > 6c6ef9f26e598fb977f60935e109cd5b266c941a > > > bf3ee71363c0b44acb62f375aea470262ac4210a > > > 5d6c31910bc0713e37628dc0ce677dcb13c8ccf4 > > > f5c244383725a6de06bc62fa7c54c0ea0d942eec > > > 5f6e59ae8277cef221fdbf9b12f0c4f80db59944 > > > d0a5b995a308347fdb1bb0412df32acd0312523b > > > > Looking at selinux code, it seems to be coming from following code. > > Looks like in case of overlay inode, we are not setting > > IOP_XATTR? > > > > Vivek > > > > sb_finish_set_opts() > > > > if (sbsec->behavior == SECURITY_FS_USE_XATTR) { > > /* Make sure that the xattr handler exists and that no > > error other than -ENODATA is returned by getxattr on > > the root directory. -ENODATA is ok, as this may be > > the first boot of the SELinux kernel before we have > > assigned xattr values to the filesystem. */ > > if (!(root_inode->i_opflags & IOP_XATTR)) { > > printk(KERN_WARNING "SELinux: (dev %s, type %s) has no " > > "xattr support\n", sb->s_id, sb->s_type->name); > > rc = -EOPNOTSUPP; > > goto out; > > IOP_XATTR is set, if sb->s_xattr is not NULL. > > inode_init_always() { > if (sb->s_xattr) > inode->i_opflags |= IOP_XATTR; > } > > In case of overlay, when preparing super block and root dentry, > sb->s_xattr has not been set yet and we call, > > ovl_new_inode() > new_inode() > alloc_inode() > inode_init_always() > > Looks like we need to initalize overlay super block little more and > set s_xattr before calling ovl_new_inode(). Following hack fix seems to fix the issue for me. --- fs/overlayfs/super.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: rhvgoyal-linux/fs/overlayfs/super.c =================================================================== --- rhvgoyal-linux.orig/fs/overlayfs/super.c 2016-10-12 15:59:16.197781805 -0400 +++ rhvgoyal-linux/fs/overlayfs/super.c 2016-10-13 17:42:28.207365951 -0400 @@ -1292,6 +1292,9 @@ static int ovl_fill_super(struct super_b if (!oe) goto out_put_cred; + + sb->s_xattr = ovl_xattr_handlers; + root_dentry = d_make_root(ovl_new_inode(sb, S_IFDIR)); if (!root_dentry) goto out_free_oe; @@ -1317,7 +1320,6 @@ static int ovl_fill_super(struct super_b sb->s_magic = OVERLAYFS_SUPER_MAGIC; sb->s_op = &ovl_super_operations; - sb->s_xattr = ovl_xattr_handlers; sb->s_root = root_dentry; sb->s_fs_info = ufs; sb->s_flags |= MS_POSIXACL | MS_NOREMOTELOCK;