From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [1.203.163.78] (helo=mailgw01.mediatek.com) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1fVvcu-00010D-QN for linux-mtd@lists.infradead.org; Thu, 21 Jun 2018 09:11:38 +0000 Message-ID: <1529571876.14673.77.camel@mhfsdcap03> Subject: UBIFS assert when create new sub-dir under a transmute enabled dir with Smack enabled From: xiaolei li To: CC: , , , Date: Thu, 21 Jun 2018 17:04:36 +0800 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Hi Richard, I ever committed one patch[1] to fix ubifs assert in ubifs_xattr_set() if Smack is enabled. It almost always runs OK except "creating new sub-dir under a transmute enabled dir" which is found by Mr.Leqiao Peng. For this special case, there still has ubifs assert problem. With patch[1], this problem can be reproduced by these steps ( assume that the Smack has been enabled and the Smack userspace tool also installed ): 1). Add new smack rule in which the "aaa" for process object, "bbb" for file or directory object. "xwt" for the permission "execute, write and transmute" echo "aaa bbb xwt" | smackload 2). Apply the label "aaa" to current sh process. Verify the effect by "ps -Z" echo aaa > /proc/self/attr/current 3) Create a directory "test_dir" and assign the "bbb" label and enable the transmute feature upon the new directory. Verify this by "chsmack test_dir". mkdir test_dir chsmack -a "bbb" -t test_dir 4) Create a new directory "newDir" under the "test_dir". mkdir test_dir/newDir Then, ubifs assert happens, and the stack trace is: UBIFS assert failed in __ubifs_setxattr at 284 (pid 4041) CPU: 2 PID: 4041 Comm: mkdir Tainted: G S W 4.9.90 #1 Call trace: [] dump_backtrace+0x0/0x1d8 [] show_stack+0x24/0x30 [] dump_stack+0x94/0xb8 [] __ubifs_setxattr+0x358/0x5f8 [] ubifs_xattr_set+0x64/0x3d0 [] __vfs_setxattr+0x7c/0x98 [] smack_d_instantiate+0x304/0x350 [] security_d_instantiate+0x4c/0x78 [] d_instantiate+0x3c/0x70 [] ubifs_mkdir+0x1d8/0x1e0 [] vfs_mkdir2+0x128/0x1b0 [] SyS_mkdirat+0x80/0xf0 [] __sys_trace_return+0x0/0x4 Mr. Schaufler (original developer of SMACK) has analyzed the possible root cause: "I have confirmed this behavior. The issue is that the inode isn't locked during inode instantiation. It doesn't need to be, because until instatiation is complete the inode doesn't really exist and isn't accessible to any other task. The assertion in the ubifs code is not appropriate. I suggest that you contact the ubifs maintainers. Please CC me, and I will answer any questions they may have. Thank you for the report." Could you kindly have a look at this problem? Thanks very much! [1] https://patchwork.kernel.org/patch/9805535/ Thanks! Xiaolei Li