| To: | Dave Chinner <david@xxxxxxxxxxxxx> |
|---|---|
| Subject: | Re: xfs: possible deadlock warning |
| From: | Gu Zheng <guz.fnst@xxxxxxxxxxxxxx> |
| Date: | Thu, 29 May 2014 11:34:21 +0800 |
| Cc: | <xfs@xxxxxxxxxxx>, linux-kernel <linux-kernel@xxxxxxxxxxxxxxx> |
| Delivered-to: | xfs@xxxxxxxxxxx |
| In-reply-to: | <20140528060050.GK8554@dastard> |
| References: | <538571D4.70904@xxxxxxxxxxxxxx> <20140528060050.GK8554@dastard> |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110930 Thunderbird/7.0.1 |
Hi Dave, On 05/28/2014 02:00 PM, Dave Chinner wrote: > On Wed, May 28, 2014 at 01:19:16PM +0800, Gu Zheng wrote: >> Hi all, >> When running the latest Linus' tree, the following possible deadlock warning >> occurs. > > false positive. There isn't a deadlock between inode locks on > different filesystems. i.e. there is no dependency between shmem > inodes and xfs inodes, nor on their security contexts. Nor can you > take a page fault on a directory inode, which is the XFS inode lock > class it's complaining about. If it's really a noisy, can we avoid this? Thanks, Gu > > Fundamentally, the problem here is shmem instantiating a new inode > with the mmap_sem held. That's just plain wrong... Agree, it's better to prepare the file before going into the protection region. > > > Cheers, > > Dave. |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: [PATCH] xfsprogs: xfs_copy: fix data corruption of target, Junxiao Bi |
|---|---|
| Next by Date: | Re: [RFC 2/2] x86_64: expand kernel stack to 16K, Minchan Kim |
| Previous by Thread: | Re: xfs: possible deadlock warning, Dave Chinner |
| Next by Thread: | Re: xfs: possible deadlock warning, Dave Chinner |
| Indexes: | [Date] [Thread] [Top] [All Lists] |