Messages in this thread | | | From | Kees Cook <> | Date | Thu, 23 Jun 2016 11:00:08 -0700 | Subject | Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86, core) |
| |
On Thu, Jun 23, 2016 at 10:52 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, Jun 23, 2016 at 10:44 AM, Linus Torvalds > <torvalds@linux-foundation.org> 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
| |