Re: mpol_to_str revisited.

On Mon, Oct 15, 2012 at 11:58 PM, David Rientjes [off-list ref] wrote:

On Mon, 15 Oct 2012, KOSAKI Motohiro wrote:

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.

quoted

we should
close a race (or kill remain ref count leak) if we still have.

As I mentioned earlier in the thread, the read() is done here on a task
while only a reference to the task_struct is taken and we do not hold
task_lock() which is required for task->mempolicy.  Once that is fixed,
mpol_to_str() should never be called for !task->mempolicy so it will never
need to return -EINVAL in such a condition.

I agree that's obviously a bug and we should fix it.

--
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>