From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx150.postini.com [74.125.245.150]) by kanga.kvack.org (Postfix) with SMTP id 7FAD66B0070 for ; Thu, 20 Dec 2012 17:55:25 -0500 (EST) Received: by mail-da0-f42.google.com with SMTP id z17so1751499dal.15 for ; Thu, 20 Dec 2012 14:55:24 -0800 (PST) Date: Thu, 20 Dec 2012 14:55:22 -0800 (PST) From: David Rientjes Subject: Re: [patch] mm, mempolicy: Introduce spinlock to read shared policy tree In-Reply-To: Message-ID: References: <1353624594-1118-1-git-send-email-mingo@kernel.org> <1353624594-1118-19-git-send-email-mingo@kernel.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Ingo Molnar , Linux Kernel Mailing List , linux-mm , Peter Zijlstra , Paul Turner , Lee Schermerhorn , Christoph Lameter , Rik van Riel , Mel Gorman , Andrew Morton , Andrea Arcangeli , Thomas Gleixner , Johannes Weiner , Hugh Dickins , Sasha Levin , KOSAKI Motohiro On Thu, 20 Dec 2012, Linus Torvalds wrote: > Going through some old emails before -rc1 rlease.. > > What is the status of this patch? The patch that is reported to cause > the problem hasn't been merged, but that mpol_misplaced() thing did > happen in commit 771fb4d806a9. And it looks like it's called from > numa_migrate_prep() under the pte map lock. Or am I missing something? Andrew pinged both Ingo and I about it privately two weeks ago. It probably doesn't trigger right now because there's no pte_mknuma() on shared pages (yet) but will eventually be needed for correctness. So it's not required for -rc1 as it sits in the tree today but will be needed later (and hopefully not forgotten about until Sasha fuzzes again). > See commit 9532fec118d ("mm: numa: Migrate pages handled during a > pmd_numa hinting fault"). > > Am I missing something? Mel, please take another look. > > I despise these kinds of dual-locking models, and am wondering if we > can't have *just* the spinlock? > Adding KOSAKI to the cc. This is probably worth discussing now to see if we can't revert b22d127a39dd ("mempolicy: fix a race in shared_policy_replace()"), keep it only as a spinlock as you suggest, and do what KOSAKI suggested in http://marc.info/?l=linux-kernel&m=133940650731255 instead. I don't think it's worth trying to optimize this path at the cost of having both a spinlock and mutex. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org