Andrew Donnellan [andrew.donnellan@xxxxxxxxxxx] wrote: > [+ Sukadev, Christophe] > > On 18/04/18 11:08, Alastair D'Silva wrote: > > From: Alastair D'Silva <alastair@xxxxxxxxxxx> > > > > The current implementation of TID allocation, using a global IDR, may > > result in an errant process starving the system of available TIDs. > > Instead, use task_pid_nr(), as mentioned by the original author. The > > scenario described which prevented it's use is not applicable, as > > set_thread_tidr can only be called after the task struct has been > > populated. > > > > Signed-off-by: Alastair D'Silva <alastair@xxxxxxxxxxx> > > So it's too late in the evening for me to completely get my head around > what's going on here enough to give my Reviewed-by:, but my current thinking > is: > > - In the first version of the patch to add TIDR support > (https://patchwork.ozlabs.org/patch/799494/), it was originally proposed to > call assign_thread_id() (as it was then called) from copy_thread() > > - The comment block documents the reason why we can't use task_pid_nr() but > assumes that we're trying to assign a TIDR from within copy_thread() > > - The final patch that was accepted > (https://patchwork.ozlabs.org/patch/835552/, > ec233ede4c8654894610ea54f4dae7adc954ac62) instead sets the TIDR to 0 from > copy_thread(), so the original reasoning regarding not using task_pid_nr() > within copy_thread() is no longer applicable. > > Sukadev: does this sound right? Yes. Like with PIDR, was trying to assign TIDR initially to all threads. But since only a subset of threads need/use TIDR, we can assign the value later (when set_thread_tidr() is called). So we should be able to use task_pid_nr() then. Sukadev -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
