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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 14 Dec 2010 22:03:33 +0100
From:	Miklos Szeredi <miklos@...redi.hu>
To:	Andrea Arcangeli <aarcange@...hat.com>
CC:	dave@...ux.vnet.ibm.com, miklos@...redi.hu,
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, shenlinf@...ibm.com,
	volobuev@...ibm.com, mel@...ux.vnet.ibm.com, dingc@...ibm.com,
	lnxninja@...ibm.com
Subject: Re: Deadlocks with transparent huge pages and userspace fs daemons

On Tue, 14 Dec 2010, Andrea Arcangeli wrote:
> Hello Dave and everyone,
> 
> On Wed, Nov 03, 2010 at 01:43:25PM -0700, Dave Hansen wrote:
> > Hey Miklos,
> > 
> > When testing with a transparent huge page kernel:
> > 
> > 	http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/andrea/aa.git;a=summary
> > 
> > some IBM testers ran into some deadlocks.  It appears that the
> > khugepaged process is trying to migrate one of a filesystem daemon's
> > pages while khugepaged holds the daemon's mmap_sem for write.
> 
> The allocation under mmap_sem write mode in khugepaged bug should be
> fixed in current aa.git based on 37-rc5:
> 
> http://git.kernel.org/?p=linux/kernel/git/andrea/aa.git;a=shortlog
> http://git.kernel.org/?p=linux/kernel/git/andrea/aa.git;a=commit;h=83e4d55d0014b3eeb982005d73f55ffcf2813504
> 
> Let me know how it goes, it's not very well tested yet (which is why I
> didn't make a new submit yet).
> 
> I stick to my idea this is bug in userland and may trigger if your
> daemon does mmap/munmap and the vma allocation under mmap_sem waits
> for the I/O, but I don't want to show it with THP enabled, and this is
> more scalable so it's definitely good idea and no downside whatsoever.

This is all fine and dandy, but please let's not forget about the
other thing that Dave's test uncovered.  Namely that page migration
triggered by transparent hugepages takes the page lock on arbitrary
filesystems.  This is also deadlocky on fuse, but also not a good idea
for any filesystem where page reading time is not bounded (think NFS
with network down).

Thanks,
Miklos
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ