| 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
| ||
|
Date: Wed, 13 Aug 2008 10:58:52 +1000 From: Dave Chinner <david@...morbit.com> To: "Linda A. Walsh" <xfs@...nx.org> Cc: xfs-oss <xfs@....sgi.com>, LKML <linux-kernel@...r.kernel.org>, Eric Sandeen <sandeen@...deen.net> Subject: Re: XFS Lock debugging noise or real problem? On Tue, Aug 12, 2008 at 03:28:46PM -0700, Linda A. Walsh wrote: > Eric Sandeen wrote: >> ... > Is it also known, (and the same bug) when you get the lock warnings when > doing > "xfs_restore", as well (dio_get_page and xfs_ilock)... That's the mm code calling fput() with the mmap_sem held. That's a problem in the VM code, which XFS can do nothing about. The normal I/O paths always lock the inode first, then (if a page fault occurs during copyin/out or we need to lock down pages for direct I/O) grab the mmap_sem at that point. This one could deadlock if you are mixing read/write with mmap on the same file in different threads of a multithreaded app. Unlikely, but possible, though it would only hang that app (not the rest of the machine). > The bugs with 'sort', & imap were both with xfs_ilock and > shrink_icache_memory. Once again, a problem with the generic code inverting the normal lock order. This one cannot deadlock, though, because by definition any inode on the unused list is, well, unused and hence we can't be holding a reference to it... Cheers, Dave. -- Dave Chinner david@...morbit.com -- 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