On 26/03/2015 19:55, Ingo Molnar wrote:
>
> * Laurent Dufour <lduf...@linux.vnet.ibm.com> wrote:
>
>> +{
>> + unsigned long vdso_end, vdso_start;
>> +
>> + if (!mm->context.vdso_base)
>> + return;
>> + vdso_start = mm->context.vdso_base;
>> +
>> +#ifdef CONFIG_PPC64
>> + /* Calling is_32bit_task() implies that we are dealing with the
>> + * current process memory. If there is a call path where mm is not
>> + * owned by the current task, then we'll have need to store the
>> + * vDSO size in the mm->context.
>> + */
>> + BUG_ON(current->mm != mm);
>> + if (is_32bit_task())
>> + vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
>> + else
>> + vdso_end = vdso_start + (vdso64_pages << PAGE_SHIFT);
>> +#else
>> + vdso_end = vdso_start + (vdso32_pages << PAGE_SHIFT);
>> +#endif
>> + vdso_end += (1<<PAGE_SHIFT); /* data page */
>> +
>> + /* Check if the vDSO is in the range of the remapped area */
>> + if ((vdso_start <= old_start && old_start < vdso_end) ||
>> + (vdso_start < old_end && old_end <= vdso_end) ||
>> + (old_start <= vdso_start && vdso_start < old_end)) {
>> + /* Update vdso_base if the vDSO is entirely moved. */
>> + if (old_start == vdso_start && old_end == vdso_end &&
>> + (old_end - old_start) == (new_end - new_start))
>> + mm->context.vdso_base = new_start;
>> + else
>> + mm->context.vdso_base = 0;
>> + }
>> +}
>
> Oh my, that really looks awfully complex, as you predicted, and right
> in every mremap() call.
I do agree, that's awfully complex ;)
> I'm fine with your original, imperfect, KISS approach. Sorry about
> this detour ...
>
> Reviewed-by: Ingo Molnar <mi...@kernel.org>
No problem, so let's stay on the v3 version of the patch.
Thanks for Reviewed-by statement which, I guess, applied to the v3 too.
Should I resend the v3 ?
Thanks,
Laurent.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
