From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 44355 invoked by alias); 25 Feb 2016 14:23:24 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 44304 invoked by uid 89); 25 Feb 2016 14:23:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00,SPF_NEUTRAL autolearn=no version=3.3.2 spammy=H*r:4.86 X-HELO: mail3-relais-sop.national.inria.fr Date: Thu, 25 Feb 2016 14:41:00 -0000 From: Samuel Thibault To: Thomas Schwinge Cc: Roland McGrath , bug-hurd@gnu.org, libc-alpha@sourceware.org Subject: Re: sysdeps/mach/hurd/profil.c (was: [PATCH] hurd: align -p and -pg behavior on Linux) Message-ID: <20160225142313.GV3460@var.bordeaux.inria.fr> Mail-Followup-To: Thomas Schwinge , Roland McGrath , bug-hurd@gnu.org, libc-alpha@sourceware.org References: <20150919120023.GA12911@var.home> <87bn75ybeb.fsf@kepler.schwinge.homeip.net> <8760xcyjfi.fsf@kepler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8760xcyjfi.fsf@kepler.schwinge.homeip.net> User-Agent: Mutt/1.5.21+34 (58baf7c9f32f) (2010-12-30) X-SW-Source: 2016-02/txt/msg00798.txt.bz2 Thomas Schwinge, on Thu 25 Feb 2016 15:05:21 +0100, wrote: > Should we move the initialization of profil_reply_port elsewhere, or be > prepared for profil_reply_port to be MACH_PORT_NULL in > sysdeps/mach/hurd/profil.c:fetch_samples (by returning early?), or not > call fetch_samples from sysdeps/mach/hurd/profil.c:__profil if > profil_reply_port is MACH_PORT_NULL, or make sure that we're always > properly initialized by making sure that the profile thread is always > scheduled to execute right after it's been created? __profil calls __thread_suspend (profile_thread); then uses fetch_samples. It seems unsafe to me to be using the profile thread's reply port for the last profil_task_get_sampled_pcs call: who knows where the thread got suspended? > These days, do we still need the threadvar-avoidance magic, the "special > RPC stubs", and the "special_profil_failure"? With TLS support, I'd say we don't, which gets the profil_reply_port issue away. > As there are accesses to variables shared between different threads, > should these be re-written to use GCC's atomic/sync load/store builtins > with appropriate semantics? The current way seems unsafe at least between update_waiter and fetch_samples, indeed. I'd say just go with a libc_lock. Samuel