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()
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Reply via email to