Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 23 Jun 2016 16:31:26 +0200
From: Oleg Nesterov <>
To: Linus Torvalds <>
Cc: Andy Lutomirski <>, Andy Lutomirski <>,
        the arch/x86 maintainers <>,
        Linux Kernel Mailing List <>,
        "" <>,
        Borislav Petkov <>, Nadav Amit <>,
        Kees Cook <>, Brian Gerst <>,
        "" <>,
        Josh Poimboeuf <>, Jann Horn <>,
        Heiko Carstens <>
Subject: Re: [PATCH v3 00/13] Virtually mapped stacks with guard pages (x86,

On 06/22, Linus Torvalds wrote:
> Oleg, what do you think? Would it be reasonable to free the stack and
> thread_info synchronously at exit time, clear the pointer (to catch
> any odd use), and only RCU-delay the task_struct itself?

I didn't see the patches yet, quite possibly I misunderstood... But no,
I don't this we can do this (if we are not going to move ti->flags to
task_struct at least).

> (Obviously, we can't release it in do_exit() itself like we do some of
> the other state - it would need to be released after we've scheduled
> away to another process' stack, but we already have that TASK_DEAD
> handling in finish_task_switch for this exact reason).

Yes, but the problem is that a zombie thread can do its last schedule
before it is reaped.

Just for example, syscall_regfunc() does

		for_each_process_thread(p, t) {
			set_tsk_thread_flag(t, TIF_SYSCALL_TRACEPOINT);

and this can easily hit a TASK_DEAD thread with ->stack == NULL.

And we can't free/nullify it when the parent/debuger reaps a zombie,
say, mark_oom_victim() expects that get_task_struct() protects
thread_info as well.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.