Messages in this thread | | | 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 |
| |
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.
| |