[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a7m1ywni.fsf@oldenburg.str.redhat.com>
Date: Thu, 22 Nov 2018 16:11:45 +0100
From: Florian Weimer <fweimer@...hat.com>
To: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
Cc: Rich Felker <dalias@...c.org>, carlos <carlos@...hat.com>,
Joseph Myers <joseph@...esourcery.com>,
Szabolcs Nagy <szabolcs.nagy@....com>,
libc-alpha <libc-alpha@...rceware.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ben Maurer <bmaurer@...com>,
Peter Zijlstra <peterz@...radead.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
Boqun Feng <boqun.feng@...il.com>,
Will Deacon <will.deacon@....com>,
Dave Watson <davejwatson@...com>, Paul Turner <pjt@...gle.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-api <linux-api@...r.kernel.org>
Subject: Re: [RFC PATCH v4 1/5] glibc: Perform rseq(2) registration at nptl init and thread creation
* Mathieu Desnoyers:
> Thoughts ?
>
> /* Unregister rseq TLS from kernel. */
> if (has_rseq && __rseq_unregister_current_thread ())
> abort();
>
> advise_stack_range (pd->stackblock, pd->stackblock_size, (uintptr_t) pd,
> pd->guardsize);
>
> /* If the thread is detached free the TCB. */
> if (IS_DETACHED (pd))
> /* Free the TCB. */
> __free_tcb (pd);
Considering that we proceed to free the TCB, I really hope that all
signals are blocked at this point. (I have not checked this, though.)
Wouldn't this address your concern about access to the rseq area?
Thanks,
Florian
Powered by blists - more mailing lists