Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754129AbbGXMjs (ORCPT ); Fri, 24 Jul 2015 08:39:48 -0400 Received: from emvm-gh1-uea08.nsa.gov ([63.239.67.9]:50848 "EHLO emvm-gh1-uea08.nsa.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753998AbbGXMjh (ORCPT ); Fri, 24 Jul 2015 08:39:37 -0400 X-TM-IMSS-Message-ID: <410c286c000896b8@nsa.gov> Message-ID: <55B231BE.6090304@tycho.nsa.gov> Date: Fri, 24 Jul 2015 08:38:22 -0400 From: Stephen Smalley Organization: National Security Agency User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Dave Chinner CC: prarit@redhat.com, mstevens@fedoraproject.org, manfred@colorfullife.com, esandeen@redhat.com, wagi@monom.org, hughd@google.com, linux-kernel@vger.kernel.org, eparis@redhat.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org, dave@stgolabs.net, nyc@holomorphy.com, akpm@linux-foundation.org, torvalds@linux-foundation.org, selinux@tycho.nsa.gov Subject: Re: [RFC][PATCH] ipc: Use private shmem or hugetlbfs inodes for shm segments. References: <1437668913-25446-1-git-send-email-sds@tycho.nsa.gov> <20150724001157.GF3902@dastard> In-Reply-To: <20150724001157.GF3902@dastard> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4405 Lines: 82 On 07/23/2015 08:11 PM, Dave Chinner wrote: > On Thu, Jul 23, 2015 at 12:28:33PM -0400, Stephen Smalley wrote: >> The shm implementation internally uses shmem or hugetlbfs inodes >> for shm segments. As these inodes are never directly exposed to >> userspace and only accessed through the shm operations which are >> already hooked by security modules, mark the inodes with the >> S_PRIVATE flag so that inode security initialization and permission >> checking is skipped. >> >> This was motivated by the following lockdep warning: >> =================================================== >> [ INFO: possible circular locking dependency detected ] >> 4.2.0-0.rc3.git0.1.fc24.x86_64+debug #1 Tainted: G W >> ------------------------------------------------------- >> httpd/1597 is trying to acquire lock: >> (&ids->rwsem){+++++.}, at: [] shm_close+0x34/0x130 >> (&mm->mmap_sem){++++++}, at: [] SyS_shmdt+0x4b/0x180 >> [] lock_acquire+0xc7/0x270 >> [] __might_fault+0x7a/0xa0 >> [] filldir+0x9e/0x130 >> [] xfs_dir2_block_getdents.isra.12+0x198/0x1c0 [xfs] >> [] xfs_readdir+0x1b4/0x330 [xfs] >> [] xfs_file_readdir+0x2b/0x30 [xfs] >> [] iterate_dir+0x97/0x130 >> [] SyS_getdents+0x91/0x120 >> [] entry_SYSCALL_64_fastpath+0x12/0x76 >> [] lock_acquire+0xc7/0x270 >> [] down_read_nested+0x57/0xa0 >> [] xfs_ilock+0x167/0x350 [xfs] >> [] xfs_ilock_attr_map_shared+0x38/0x50 [xfs] >> [] xfs_attr_get+0xbd/0x190 [xfs] >> [] xfs_xattr_get+0x3d/0x70 [xfs] >> [] generic_getxattr+0x4f/0x70 >> [] inode_doinit_with_dentry+0x162/0x670 >> [] sb_finish_set_opts+0xd9/0x230 >> [] selinux_set_mnt_opts+0x35c/0x660 >> [] superblock_doinit+0x77/0xf0 >> [] delayed_superblock_init+0x10/0x20 >> [] iterate_supers+0xb3/0x110 >> [] selinux_complete_init+0x2f/0x40 >> [] security_load_policy+0x103/0x600 >> [] sel_write_load+0xc1/0x750 >> [] __vfs_write+0x37/0x100 >> [] vfs_write+0xa9/0x1a0 >> [] SyS_write+0x58/0xd0 >> [] entry_SYSCALL_64_fastpath+0x12/0x76 >> [] lock_acquire+0xc7/0x270 >> [] mutex_lock_nested+0x7f/0x3e0 >> [] inode_doinit_with_dentry+0xb9/0x670 >> [] selinux_d_instantiate+0x1c/0x20 >> [] security_d_instantiate+0x36/0x60 >> [] d_instantiate+0x54/0x70 >> [] __shmem_file_setup+0xdc/0x240 >> [] shmem_file_setup+0x10/0x20 >> [] newseg+0x290/0x3a0 >> [] ipcget+0x208/0x2d0 >> [] SyS_shmget+0x54/0x70 >> [] entry_SYSCALL_64_fastpath+0x12/0x76 >> [] __lock_acquire+0x1a78/0x1d00 >> [] lock_acquire+0xc7/0x270 >> [] down_write+0x5a/0xc0 >> [] shm_close+0x34/0x130 >> [] remove_vma+0x45/0x80 >> [] do_munmap+0x2b0/0x460 >> [] SyS_shmdt+0xb5/0x180 >> [] entry_SYSCALL_64_fastpath+0x12/0x76 > > That's a completely screwed up stack trace. There are *4* syscall > entry points with 4 separate, unrelated syscall chains on that > stack trace, all starting at the same address. How is this a valid > stack trace and not a lockdep bug of some kind? Sorry, I mangled it when I tried to reformat it from Morten Steven's original report. Fixed in v2. -- 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/