From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757964AbaE2Qpj (ORCPT ); Thu, 29 May 2014 12:45:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:65302 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756902AbaE2Qpi (ORCPT ); Thu, 29 May 2014 12:45:38 -0400 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <20140529163629.GN17233@tucsk.piliscsaba.szeredi.hu> References: <20140529163629.GN17233@tucsk.piliscsaba.szeredi.hu> <27993.1401360881@warthog.procyon.org.uk> <1400838223-30844-1-git-send-email-miklos@szeredi.hu> <28313.1401362925@warthog.procyon.org.uk> <20140529120734.GM17233@tucsk.piliscsaba.szeredi.hu> <22475.1401380602@warthog.procyon.org.uk> To: Miklos Szeredi Cc: dhowells@redhat.com, Al Viro , Linus Torvalds , Linux-Fsdevel , Kernel Mailing List , Christoph Hellwig , Andrew Morton , Robo Bot , Felix Fietkau , Neil Brown , Jordi Pujol , ezk@fsl.cs.sunysb.edu, Sedat Dilek , "J. R. Okajima" , "mszeredi@suse.cz" Subject: Re: More kernel errors with overlay filesystem v22 Date: Thu, 29 May 2014 17:44:58 +0100 Message-ID: <28536.1401381898@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Miklos Szeredi wrote: > generic_file_splice_write() uses I_MUTEX_CHILD. Not sure why, though, parent > shouldn't be locked. Maybe it's some remaining thing from the days when pipes > used the i_mutex on the pipe inode. Probably should just remove that notation > and things will work. You should be so lucky! ;-) ============================================= [ INFO: possible recursive locking detected ] 3.15.0-rc6-fsdevel+ #367 Tainted: G W --------------------------------------------- open-file/3284 is trying to acquire lock: (&sb->s_type->i_mutex_key#9/2){+.+.+.}, at: [] generic_file_splice_write+0x88/0x154 but task is already holding lock: (&sb->s_type->i_mutex_key#9/2){+.+.+.}, at: [] lock_rename+0xd3/0xdc other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&sb->s_type->i_mutex_key#9/2); lock(&sb->s_type->i_mutex_key#9/2); *** DEADLOCK *** May be due to missing lock nesting notation 4 locks held by open-file/3284: #0: (sb_writers#8){.+.+.+}, at: [] mnt_want_write+0x1c/0x40 #1: (&type->s_vfs_rename_key){+.+.+.}, at: [] lock_rename+0x3b/0xdc #2: (&sb->s_type->i_mutex_key#9/1){+.+.+.}, at: [] lock_rename+0xbe/0xdc #3: (&sb->s_type->i_mutex_key#9/2){+.+.+.}, at: [] lock_rename+0xd3/0xdc stack backtrace: CPU: 0 PID: 3284 Comm: open-file Tainted: G W 3.15.0-rc6-fsdevel+ #367 Hardware name: /DG965RY, BIOS MQ96510J.86A.0816.2006.0716.2308 07/16/2006 0000000000000000 ffff88002219d7e0 ffffffff8148b779 ffffffff81ff9d80 ffff88002219d8a0 ffffffff81074b0e ffff88002219d820 ffff88002219d8a0 0000000000000000 0000000000000000 ffff880000000003 ffffffff00000000 Call Trace: [] dump_stack+0x4d/0x66 [] __lock_acquire+0x75a/0x1861 [] lock_acquire+0x9c/0x112 [] ? generic_file_splice_write+0x88/0x154 [] mutex_lock_nested+0x60/0x2ff [] ? generic_file_splice_write+0x88/0x154 [] ? debug_check_no_locks_freed+0x11b/0x136 [] generic_file_splice_write+0x88/0x154 [] direct_splice_actor+0x31/0x33 [] splice_direct_to_actor+0xc6/0x188 [] ? opipe_prep.part.8+0x9e/0x9e [] do_splice_direct+0x73/0x9b [] ovl_copy_up_one+0x509/0x586 [] ovl_copy_up+0x9e/0xd3 [] ovl_dentry_open+0xbf/0xce [] vfs_open+0x24/0x41 [] do_last+0x943/0xbc9 [] ? link_path_walk+0x64/0x744 [] path_openat+0x23d/0x61d [] do_filp_open+0x35/0x7a [] ? _raw_spin_unlock+0x22/0x2d [] ? __alloc_fd+0xe5/0xf4 [] do_sys_open+0x142/0x1d1 [] ? syscall_trace_enter+0x197/0x1eb [] SyS_open+0x19/0x1b [] tracesys+0xdd/0xe2