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  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:	Sun, 22 Dec 2013 00:58:19 +1100
From:	David Gibson <>
To:	Joonsoo Kim <>
Cc:	Andrew Morton <>,
	Rik van Riel <>, Mel Gorman <>,
	Michal Hocko <>,
	"Aneesh Kumar K.V" <>,
	KAMEZAWA Hiroyuki <>,
	Hugh Dickins <>,
	Davidlohr Bueso <>,,, Joonsoo Kim <>,
	Wanpeng Li <>,
	Naoya Horiguchi <>,
	Hillf Danton <>
Subject: Re: [PATCH v3 03/14] mm, hugetlb: protect region tracking via newly
 introduced resv_map lock

On Wed, Dec 18, 2013 at 03:53:49PM +0900, Joonsoo Kim wrote:
> There is a race condition if we map a same file on different processes.
> Region tracking is protected by mmap_sem and hugetlb_instantiation_mutex.
> When we do mmap, we don't grab a hugetlb_instantiation_mutex, but,
> grab a mmap_sem. This doesn't prevent other process to modify region
> structure, so it can be modified by two processes concurrently.
> To solve this, I introduce a lock to resv_map and make region manipulation
> function grab a lock before they do actual work. This makes region
> tracking safe.

It's not clear to me if you're saying there is a list corruption race
bug in the existing code, or only that there will be if the
instantiation mutex goes away.

David Gibson			| I'll have my music baroque, and my code
david AT	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists