On 7/27/20 8:33 PM, Nicholas Piggin wrote:
> /*
> - * Called at the time of execve() to get a new ASID
> - * Note the subtlety here: get_new_mmu_context() behaves differently here
> - * vs. in switch_mm(). Here it always returns a new ASID, because mm has
> - * an unallocated "initial" value, while in latter, it moves to a new ASID,
> - * only if it was unallocated
> + * activate_mm defaults to switch_mm and is called at the time of execve() to
With activate_mm() definition actually gone, perhaps add "activate_mm() comes from
generic code..." to provide next reader about the "spurious looking comment"
> + * get a new ASID Note the subtlety here: get_new_mmu_context() behaves
> + * differently here vs. in switch_mm(). Here it always returns a new ASID,
> + * because mm has an unallocated "initial" value, while in latter, it moves to
> + * a new ASID, only if it was unallocated
> */
> -#define activate_mm(prev, next) switch_mm(prev, next, NULL)
>
> /* it seemed that deactivate_mm( ) is a reasonable place to do book-keeping
> * for retiring-mm. However destroy_context( ) still needs to do that because
> @@ -168,8 +169,7 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
> * there is a good chance that task gets sched-out/in, making it's ASID valid
> * again (this teased me for a whole day).
> */
> -#define deactivate_mm(tsk, mm) do { } while (0)
same for deactivate_mm()
