Re: [PATCH 0/6] mempolicy memory corruption fixlet

From: KOSAKI Motohiro
Date: Wed May 30 2012 - 17:25:12 EST


(5/30/12 5:22 PM), Ben Hutchings wrote:
On Wed, May 30, 2012 at 04:00:55PM -0400, KOSAKI Motohiro wrote:
On Wed, May 30, 2012 at 3:52 PM, Andi Kleen<andi@xxxxxxxxxxxxxx> wrote:
On Wed, May 30, 2012 at 02:42:42PM -0500, Christoph Lameter wrote:
On Wed, 30 May 2012, Andi Kleen wrote:

On Wed, May 30, 2012 at 01:50:02PM -0500, Christoph Lameter wrote:
On Wed, 30 May 2012, Andi Kleen wrote:

I always regretted that cpusets were no done with custom node lists.
That would have been much cleaner and also likely faster than what we have.

Could shared memory policies ignore cpuset constraints?

Only if noone uses cpusets as a "security" mechanism, just for a "soft policy"
Even with soft policy you could well break someone's setup.

Well at least lets exempt shared memory from memory migration and memory
policy updates. That seems to be causing many of these issues.

Migration on the page level is needed for the memory error handling.

Updates: you mean not allowing to set the policy when there are already
multiple mappers? I could see that causing some unexpected behaviour. Presumably
a standard database will only set it at the beginning, but I don't know
if that would work for all users.

We don't need to kill migration core. We only need to kill that mbind(2) updates
vma->policy of shmem.
[...]

So should I (and Greg) drop 'mm: mempolicy: Let vma_merge and
vma_split handle vma->vm_policy linkages' from the pending stable
releases? Or is that OK as an interim fix until these changes go
into mainline?

Please drop. It screw up mbind(2).




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/