On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Jun 23, 2016 at 10:44 AM, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> The thread_info->tsk pointer, that was one of the most critical issues >> and the main raison d'être of the thread_info, has been replaced on >> x86 by just using the per-cpu "current_task". Yes,.there are probably >> more than a few "ti->task" users left for legacy reasons, harking back >> to when the thread-info was cheaper to access, but it shouldn't be a >> big deal. > > Ugh. Looking around at this, it turns out that a great example of this > kind of legacy issue is the debug_mutex stuff. > > It uses "struct thread_info *" as the owner pointer, and there is _no_ > existing reason for it. In fact, in every single place it actually > wants the task_struct, and it does task_thread_info(task) just to > convert it to the thread-info, and then converts it back with > "ti->task". Heh, yeah, that looks like a nice clean-up. > So the attached patch seems to be the right thing to do regardless of > this whole discussion. Why does __mutex_lock_common() have "task" as a stack variable? It's only assigned at the start, and is always "current". (I only noticed from the patch changing "current_thread_info()" and "task_thread_info(task)" both to "task".) -Kees -- Kees Cook Chrome OS & Brillo Security -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
