From owner-freebsd-threads@FreeBSD.ORG Mon Jul 1 11:06:56 2013 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6B9E8663 for ; Mon, 1 Jul 2013 11:06:56 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 5C03510EF for ; Mon, 1 Jul 2013 11:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r61B6u6x085956 for ; Mon, 1 Jul 2013 11:06:56 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r61B6tvx085954 for freebsd-threads@FreeBSD.org; Mon, 1 Jul 2013 11:06:55 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 1 Jul 2013 11:06:55 GMT Message-Id: <201307011106.r61B6tvx085954@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 11:06:56 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/179158 threads ruby19 segfaults during build on ppc64 o threa/168417 threads pthread_getcpuclockid() does not work to specification o threa/163512 threads libc defaults to single threaded o threa/160708 threads possible security problem with RLIMIT_VMEM o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/128922 threads threads hang with xorg running o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/30464 threads [patch] pthread mutex attributes -- pshared 18 problems total. From owner-freebsd-threads@FreeBSD.ORG Fri Jul 5 23:22:06 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76774B19; Fri, 5 Jul 2013 23:22:06 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-ve0-x229.google.com (mail-ve0-x229.google.com [IPv6:2607:f8b0:400c:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id 2C7D41A77; Fri, 5 Jul 2013 23:22:06 +0000 (UTC) Received: by mail-ve0-f169.google.com with SMTP id m1so2195195ves.28 for ; Fri, 05 Jul 2013 16:22:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=GmXtuqRMyn7yEljz3wj7mFZP8D0OulhB67g3s56I8B4=; b=aDulBCVvQSvXxD5iX2scODsZsp2I81QgvbK+GRhr4zEBl0njHyJ9XWCXLLCTFZkhCJ 2PCGvnmc6vgf4Te4YYFYgVWzyeV07LRK4fDaxAnDlax+T+LeTlXsz6tB+VgRhWPUa1iv 484rgh1bMojrFpNMoxp/ZxiQEOqsVY4qpZGTTTaoaZLqVt6Je8zgbtZjkB8rsSQzuI82 5zoLO2yhXPs0e0nN87DDGSlsnDkFi+Xu9nRpUVqc34EsHN9/XFFjff9PjEpTSHxsPK63 2NopBlmCzXpZt3YqDkNsa3XWGYiE8Evh+fzRX+jWKEzyEeKEUQBTl5AWjiXHxn1qiOIU h8tA== MIME-Version: 1.0 X-Received: by 10.52.158.164 with SMTP id wv4mr6777253vdb.106.1373066525632; Fri, 05 Jul 2013 16:22:05 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.206.202 with HTTP; Fri, 5 Jul 2013 16:22:05 -0700 (PDT) Date: Sat, 6 Jul 2013 01:22:05 +0200 X-Google-Sender-Auth: Yz7q4pxWhucVnt8ZZCujyEhP7rc Message-ID: Subject: Accessing struct pthread from kernel From: Davide Italiano To: freebsd-amd64@freebsd.org, freebsd-threads@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 23:22:06 -0000 Hi, as a preliminary step in the implementation of adaptive spinning for umtx, I'm switching the pthread/umtx code so that a thread that acquires a pthread_mutex writes the address of struct pthread in the owner field of the lock instead of the thread id (tid). This is because having struct pthread pointer allows easily to access informations of the thread, and makes easy to get the state of the thread exported from the kernel (once this will be implemented). For what concerns the libthr side, the internal function _get_curthread() goes into the TLS to obtain the struct field of curthread, so I'm done. OTOH, I'm quite unsure instead about how to get address of struct pthread for curthread from the kernel side (for example, in do_lock_umutex() sys/kern/kern_umtx.c). I guess I need to write some MD code because the TLS is different on the various architecture supported in FreeBSD, and as a first step I focused on amd64. It looks like from the SDM that %%fs register points to the base of the TLS, so I think that accessing using curthread->td_pcb->pcb_fsbase (and then adding the proper offset to acces the right field) is a viable solution to do this. Am I correct? In particular what worries me is if the read of 'struct pthread' for curthread from the TLS register is atomic with respect to preemptions. Alternatively, is there an (easier way) to accomplish this task? Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare