| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <20080910151245.GC18644@wotan.suse.de>
Date: Wed, 10 Sep 2008 17:12:45 +0200
From: Nick Piggin <npiggin@...e.de>
To: Ingo Molnar <mingo@...e.hu>
Cc: Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [patch] x86: some lock annotations for user copy paths
On Wed, Sep 10, 2008 at 02:32:46PM +0200, Ingo Molnar wrote:
>
> here's another one found on another box:
>
> [ 574.380319] =======================================================
> [ 574.380381] [ INFO: possible circular locking dependency detected ]
> [ 574.380413] 2.6.27-rc6-tip #30918
> [ 574.380440] -------------------------------------------------------
> [ 574.380472] sshd/8255 is trying to acquire lock:
> [ 574.380500] (&sb->s_type->i_mutex_key#9){--..}, at: [<ffffffff802d5aab>] do_truncate+0x59/0x83
> [ 574.380628]
> [ 574.380629] but task is already holding lock:
> [ 574.380679] (&mm->mmap_sem){----}, at: [<ffffffff80249775>] sys32_mmap2+0x64/0xa7
> [ 574.380781]
> [ 574.380781] which lock already depends on the new lock.
> [ 574.380782]
> [ 574.380857]
> [ 574.380857] the existing dependency chain (in reverse order) is:
> [ 574.380910]
> [ 574.380911] -> #1 (&mm->mmap_sem){----}:
> [ 574.381025] [<ffffffff80281979>] __lock_acquire+0x9b4/0xb3b
> [ 574.381081] [<ffffffff80282499>] lock_acquire+0x8d/0xba
> [ 574.381219] [<ffffffff802a94ff>] iov_iter_fault_in_readable+0x84/0x169
> [ 574.381359] [<ffffffff802aae18>] generic_file_buffered_write+0x119/0x5ad
> [ 574.381584] [<ffffffff802ab6cb>] __generic_file_aio_write_nolock+0x260/0x294
> [ 574.381809] [<ffffffff802ab768>] generic_file_aio_write+0x69/0xc5
> [ 574.381948] [<ffffffff802d68e2>] do_sync_write+0xeb/0x132
> [ 574.382086] [<ffffffff802d6f28>] vfs_write+0xa7/0xe1
> [ 574.382222] [<ffffffff802d701c>] sys_write+0x47/0x6d
> [ 574.382359] [<ffffffff802481b7>] cstar_dispatch+0x7/0x4b
> [ 574.382496] [<ffffffffffffffff>] 0xffffffffffffffff
> [ 574.382635]
> [ 574.382636] -> #0 (&sb->s_type->i_mutex_key#9){--..}:
> [ 574.382942] [<ffffffff8028181b>] __lock_acquire+0x856/0xb3b
> [ 574.383080] [<ffffffff80282499>] lock_acquire+0x8d/0xba
> [ 574.383218] [<ffffffff80b77600>] __mutex_lock_common+0xe4/0x333
> [ 574.383358] [<ffffffff80b778e9>] mutex_lock_nested+0x30/0x35
> [ 574.383495] [<ffffffff802d5aab>] do_truncate+0x59/0x83
> [ 574.383633] [<ffffffff802cbbf7>] shmem_file_setup+0xcf/0x106
> [ 574.383772] [<ffffffff802cbc50>] shmem_zero_setup+0x22/0x5e
> [ 574.383910] [<ffffffff802bfc92>] mmap_region+0x250/0x438
> [ 574.384031] [<ffffffff802c047f>] do_mmap_pgoff+0x2fe/0x363
> [ 574.384031] [<ffffffff8024978e>] sys32_mmap2+0x7d/0xa7
> [ 574.384031] [<ffffffff802481b7>] cstar_dispatch+0x7/0x4b
> [ 574.384031] [<ffffffffffffffff>] 0xffffffffffffffff
> [ 574.384031]
> [ 574.384031] other info that might help us debug this:
> [ 574.384031]
> [ 574.384031] 1 lock held by sshd/8255:
> [ 574.384031] #0: (&mm->mmap_sem){----}, at: [<ffffffff80249775>] sys32_mmap2+0x64/0xa7
> [ 574.384031]
> [ 574.384031] stack backtrace:
> [ 574.384031] Pid: 8255, comm: sshd Not tainted 2.6.27-rc6-tip #30918
> [ 574.384031] Call Trace:
> [ 574.384031] [<ffffffff80280fba>] print_circular_bug_tail+0x71/0x7c
> [ 574.384031] [<ffffffff8028181b>] __lock_acquire+0x856/0xb3b
> [ 574.384031] [<ffffffff80282499>] lock_acquire+0x8d/0xba
> [ 574.384031] [<ffffffff802d5aab>] ? do_truncate+0x59/0x83
> [ 574.384031] [<ffffffff80b77600>] __mutex_lock_common+0xe4/0x333
> [ 574.384031] [<ffffffff802d5aab>] ? do_truncate+0x59/0x83
> [ 574.384031] [<ffffffff802d5aab>] ? do_truncate+0x59/0x83
> [ 574.384031] [<ffffffff804e475f>] ? _raw_spin_unlock+0x8e/0x93
> [ 574.384031] [<ffffffff80b778e9>] mutex_lock_nested+0x30/0x35
> [ 574.384031] [<ffffffff802d5aab>] do_truncate+0x59/0x83
> [ 574.384031] [<ffffffff802d7c1f>] ? init_file+0x99/0xbb
> [ 574.384031] [<ffffffff802d7deb>] ? alloc_file+0x3e/0x4e
> [ 574.384031] [<ffffffff802cbbf7>] shmem_file_setup+0xcf/0x106
> [ 574.384031] [<ffffffff802cbc50>] shmem_zero_setup+0x22/0x5e
> [ 574.384031] [<ffffffff802bfc92>] mmap_region+0x250/0x438
> [ 574.384031] [<ffffffff802282aa>] ? arch_get_unmapped_area_topdown+0x192/0x294
> [ 574.384031] [<ffffffff802c047f>] do_mmap_pgoff+0x2fe/0x363
> [ 574.384031] [<ffffffff8024978e>] sys32_mmap2+0x7d/0xa7
> [ 574.384031] [<ffffffff802481b7>] cstar_dispatch+0x7/0x4b
Oh, nice one.
It had me scratching my head until I realised you must be using tiny shmem.
Patch attached (which brings closely into line with shmem)
--
Index: linux-2.6/mm/tiny-shmem.c
===================================================================
--- linux-2.6.orig/mm/tiny-shmem.c
+++ linux-2.6/mm/tiny-shmem.c
@@ -65,31 +65,25 @@ struct file *shmem_file_setup(char *name
if (!dentry)
goto put_memory;
+ error = -ENFILE;
+ file = get_empty_filp();
+ if (!file)
+ goto put_dentry;
+
error = -ENOSPC;
inode = ramfs_get_inode(root->d_sb, S_IFREG | S_IRWXUGO, 0);
if (!inode)
- goto put_dentry;
-
- d_instantiate(dentry, inode);
- error = -ENFILE;
- file = alloc_file(shm_mnt, dentry, FMODE_WRITE | FMODE_READ,
- &ramfs_file_operations);
- if (!file)
- goto put_dentry;
-
- inode->i_nlink = 0; /* It is unlinked */
-
- /* notify everyone as to the change of file size */
- error = do_truncate(dentry, size, 0, file);
- if (error < 0)
goto close_file;
+ d_instantiate(dentry, inode);
+ inode->i_size = size;
+ inode->i_nlink = 0; /* It is unlinked */
+ init_file(file, shm_mnt, dentry, FMODE_WRITE | FMODE_READ,
+ &ramfs_file_operations);
return file;
close_file:
put_filp(file);
- return ERR_PTR(error);
-
put_dentry:
dput(dentry);
put_memory:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists