On Tue, Oct 16, 2012 at 2:10 AM, David Rientjes [off-list ref] wrote:

On Tue, 16 Oct 2012, KOSAKI Motohiro wrote:

quoted

quoted

quoted

I don't think 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a is right fix.

It's certainly not a complete fix, but I think it's a much better result
of the race, i.e. we don't panic anymore, we simply fail the read()
instead.

Even though 80de7c3138ee9fd86a98696fd2cf7ad89b995d0a itself is simple. It bring
to caller complex. That's not good and have no worth.

Before: the kernel panics, all workloads cease.
After: the file shows garbage, all workloads continue.

This is better, in my opinion, but at best it's only a judgment call and
has no effect on anything.

Kernel panics help to find our serious mistake.

I agree it would be better to respect the return value of mpol_to_str()
since there are other possible error conditions other than a freed
mempolicy, but let's not consider reverting 80de7c3138.  It is obviously
not a full solution to the problem, though, and we need to serialize with
task_lock().

Sorry no. I will have to revert it. mempolicy have already a lot of
meaningless complex and bring us a lot of problems. I haven't
seen any reason adding more.

Dave, are you interested in coming up with a patch?

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>