[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091001092218.GH15345@elte.hu>
Date: Thu, 1 Oct 2009 11:22:18 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Anirban Sinha <ASinha@...gmasystems.com>,
Darren Hart <dvhltc@...ibm.com>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc: linux-kernel@...r.kernel.org
Subject: Re: futex question
(Cc:-ed more futex folks.)
* Anirban Sinha <ASinha@...gmasystems.com> wrote:
> Hi Folks:
>
> We are observing something interesting regarding how task->robust_list
> pointer is being handled across a sys_execve() call. If a task does a
> sys_set_robust_list() with a certain head pointer and then at some point
> does a execve() call to over-write it's address space, the 'robust-list'
> pointer is never cleared. So in essence what happens is that during task
> exit, within mm_release(), the
> if (unlikely(tsk->robust_list)) condition might still be true because
> the pointer has a non-null address. However, the actual address value
> may not belong to the new address space or point to something else
> within the new address space. Should we not just clear the pointer (and
> it's compat version) within do_execve()?
>
> Granted, within exit_robust_list(), the fetch_robust_entry() calls will
> fail and bail out of the function. So in essence, nothing bad should
> happen. However, that extra code should save us from entering
> exit_robust_list() in the first place.
>
> CCing Ingo since the robust futex support was started by him.
>
> Cheers,
>
> Ani
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists