From owner-freebsd-threads@FreeBSD.ORG Sun Jul 7 16:48:08 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 D97912BE; Sun, 7 Jul 2013 16:48:08 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B0DBE1B86; Sun, 7 Jul 2013 16:48:08 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-226-51.lns20.per1.internode.on.net [121.45.226.51]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r67GlvQ8002275 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 7 Jul 2013 09:48:01 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51D99BB7.1020101@freebsd.org> Date: Mon, 08 Jul 2013 00:47:51 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Davide Italiano Subject: Re: Accessing struct pthread from kernel References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-amd64@freebsd.org, 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: Sun, 07 Jul 2013 16:48:08 -0000 On 7/6/13 7:22 AM, Davide Italiano wrote: > 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? there is a struct pthread for each tid (and visa versa) you could notify the kernel of it when you make a new thread. (new arg/call) for what it's worth the M:N threading system used to do something like this, with a user callback straucture supplied to the kernel.. > > Thanks, > From owner-freebsd-threads@FreeBSD.ORG Sun Jul 7 17:03:50 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AEE4BAA1; Sun, 7 Jul 2013 17:03:50 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) by mx1.freebsd.org (Postfix) with ESMTP id 5002E1C24; Sun, 7 Jul 2013 17:03:50 +0000 (UTC) Received: by mail-ve0-f181.google.com with SMTP id db10so2869779veb.40 for ; Sun, 07 Jul 2013 10:03:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lUiWnj24mPctHnyA2HS04n0pXIdnKdzYztlAwIb21mA=; b=XfiDy9DYC8yOpBOlDqf8YWZxFmuyYuNA9odyM8UIkgnExkyEf5+LAv4Fd+yLPUqnif sHRxYXzTS8rpnjBlpIQuSJQs3/nRCkPLA5VwIRuCNlwowJTsujHSrXEWhb5B94moLGdA MHegK6qFhhWvlKMAkqc3sJZ34fOD6EF1bsSkx2svn/JHczxcVc/gHLxyHGIJ+9GdVvvx pVvbHKIr/6mtB/qgbuUuAT/18t12QvOMFo5sKSZlQ2GnPQRy/IMUgNmSxmvL1nx3GZtj NWvxfc78PWgI4+DsW1j/XbivaFO9EuCt96dkkgHwmL+i/4u89hav/Mo8q5rLOuutZVcv ShRA== MIME-Version: 1.0 X-Received: by 10.58.197.5 with SMTP id iq5mr12233635vec.30.1373216629907; Sun, 07 Jul 2013 10:03:49 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.206.202 with HTTP; Sun, 7 Jul 2013 10:03:49 -0700 (PDT) In-Reply-To: <51D99BB7.1020101@freebsd.org> References: <51D99BB7.1020101@freebsd.org> Date: Sun, 7 Jul 2013 10:03:49 -0700 X-Google-Sender-Auth: q2jx5irjvUuVaWQxw88FWamPo84 Message-ID: Subject: Re: Accessing struct pthread from kernel From: Davide Italiano To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-amd64@freebsd.org, 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: Sun, 07 Jul 2013 17:03:50 -0000 On Sun, Jul 7, 2013 at 9:47 AM, Julian Elischer wrote: > On 7/6/13 7:22 AM, Davide Italiano wrote: >> >> 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? > > there is a struct pthread for each tid (and visa versa) > you could notify the kernel of it when you make a new thread. > (new arg/call) > Yes, I previously tried implementing something like what you propose, exploiting the fact that thr_create() pass the pointer to struct pthread to the kernel as argument. The problem I see here is that the main thread is not created by thr_create() but by fork(). So, another way to pass the struct to the kernel is needed. One might think about adding another system call for the purpose, but I guess this is overkill so if you have other suggestions I'll be happpy to hear. > for what it's worth the M:N threading system used to do something like this, > with a user callback straucture supplied to the kernel.. > > >> >> Thanks, >> > Thanks for your answer, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-threads@FreeBSD.ORG Sun Jul 7 21:35:02 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2A669A1; Sun, 7 Jul 2013 21:35:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0D50F1789; Sun, 7 Jul 2013 21:35:01 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r67LYwhL038096; Mon, 8 Jul 2013 00:34:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r67LYwhL038096 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r67LYwAV038095; Mon, 8 Jul 2013 00:34:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 8 Jul 2013 00:34:58 +0300 From: Konstantin Belousov To: Davide Italiano Subject: Re: Accessing struct pthread from kernel Message-ID: <20130707213458.GH91021@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KUl1BpUVukgrQ7uD" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-amd64@freebsd.org, 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: Sun, 07 Jul 2013 21:35:02 -0000 --KUl1BpUVukgrQ7uD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 06, 2013 at 01:22:05AM +0200, Davide Italiano wrote: > 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). >=20 > 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). You should not, see below. >=20 > 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. >=20 > Alternatively, is there an (easier way) to accomplish this task? Coupling the libthr thread structure and kernel makes the ABI cast in stone and avoids most possibilities of changing the libthr internals. The same is true for kernel accessing the userspace TLS area of the thread. If you want kernel<->usermode communication of the thread run state, and possibly also a way to advisory prevent a preemption of the spinning usermode thread, you should create a dedicated parameter block communicated from usermode to kernel on thread creation. For the main thread, the block could be allocated by kernel by image activator, placed on the stack and its address passed to the usermode by auxv. Note that you cannot access the usermode from the context switch code. Wiring the corresponding page is very wasteful (think about a process with 10,000 threads) and still does not provide any guarantees since usermode can unmap or remap the range. You might see my 'fast sigprocmask' patches where somewhat similar idea was implemented. I also recommend you to look at the Solaris schedctl(2). --KUl1BpUVukgrQ7uD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR2d8BAAoJEJDCuSvBvK1B2eMP/3wSALXdp5FSZb407N2oD6d/ 9vbhDnwRa5wMt5qzlktX7HSTUMsRjUSMyS7PfR7nLXp6/G5UKfQ/uBMR/R+J5bVs Z8nyIJ6tzE5+sYiAeWOzRI1tYk8K2uaC8lKeDB0NiVg0M1EaBRQMsJ894UJ9bhJq 71EC3YrS/WNl8KJKKZAoWP/ZR/aOtXbqZ7c69A7PC9yLvfp1oxtWbXoEBNNLx+UZ y3zf0TAyaWCpafl78Ftpb8ZGL3LaULR97JDYnachXVP0ATGVchDee10W3D/6FnBT cdI9mQ5hBYcAbC6pAz1gkotBDNeqGau6rneaCosSiehJmpVDTHTBLLey05SW3MWR 0ND9rwoQJvDcpWyPSVFx5ubcYQMXZ5wM1r0Us4znIELy4IXm5PArAnyN5nJVfKx+ SfPUNAAJz8eXybkFufnpdHavqaMyvetBjQ+20VdpI1hxtgIZXE8KHfYpAHl53Ozp pINKqlnZKLScjjWVOcQEHqwSPZYAYIuVBRcuCh23cYteBS5FDr4uGLIHQZ7usP0l Z1LhuVe6y+eMPSosI8AyCl9crcQHHIzTb7utHP9FzHVNXBkDj2XL+XgE1HL9+cEY l1rPg3hBnxyH4yzD8gQnMAJTeWQTUUb89CDT9FLi20YgyiWFpOh/Uh3yfmFc9xan JMA232G6Ic8crBLbFU2i =T71R -----END PGP SIGNATURE----- --KUl1BpUVukgrQ7uD-- From owner-freebsd-threads@FreeBSD.ORG Sun Jul 7 21:42:44 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8E0CCDED for ; Sun, 7 Jul 2013 21:42:44 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 7E28817D4 for ; Sun, 7 Jul 2013 21:42:44 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id E82061A3C42 for ; Sun, 7 Jul 2013 14:42:43 -0700 (PDT) Message-ID: <51D9E0D3.3040802@freebsd.org> Date: Sun, 07 Jul 2013 14:42:43 -0700 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: freebsd-threads@freebsd.org Subject: Re: Accessing struct pthread from kernel References: <20130707213458.GH91021@kib.kiev.ua> In-Reply-To: <20130707213458.GH91021@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Sun, 07 Jul 2013 21:42:44 -0000 On 7/7/13 2:34 PM, Konstantin Belousov wrote: > On Sat, Jul 06, 2013 at 01:22:05AM +0200, Davide Italiano wrote: >> 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). > You should not, see below. > >> 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? > Coupling the libthr thread structure and kernel makes the ABI cast in > stone and avoids most possibilities of changing the libthr internals. > The same is true for kernel accessing the userspace TLS area of the thread. > > If you want kernel<->usermode communication of the thread run state, > and possibly also a way to advisory prevent a preemption of the > spinning usermode thread, you should create a dedicated parameter block > communicated from usermode to kernel on thread creation. For the main > thread, the block could be allocated by kernel by image activator, > placed on the stack and its address passed to the usermode by auxv. > > Note that you cannot access the usermode from the context switch > code. Wiring the corresponding page is very wasteful (think about a > process with 10,000 threads) and still does not provide any guarantees > since usermode can unmap or remap the range. You might see my 'fast > sigprocmask' patches where somewhat similar idea was implemented. > > I also recommend you to look at the Solaris schedctl(2). About wiring the page, why not allow the kernel/userland to pack multiple threads into a single page? I'm not sure how many bytes of context are required, but that would be much more efficient. We used such tricks (packing multiple context blocks into a single page) in some scheduler magic we had on another project to allow the scheduler to access a page in userland. -Alfred From owner-freebsd-threads@FreeBSD.ORG Sun Jul 7 22:22:19 2013 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BC0E1C9E; Sun, 7 Jul 2013 22:22:19 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-vc0-x22f.google.com (mail-vc0-x22f.google.com [IPv6:2607:f8b0:400c:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 6E72A193E; Sun, 7 Jul 2013 22:22:19 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id hr11so2855664vcb.34 for ; Sun, 07 Jul 2013 15:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=uF/VfJIQYq8JjiRJSp/3idocAHN/KlcvFyYXTVpvl+M=; b=AF+B3DihQTWl3Xu2J53FU4pRJVjgFGtiDlFG8im7hBGmYW+/KUmrc5JXEI1RfVI63N 6mINPZdvNhaSkH967QesF5QceWZq2kOvZiAX0u2ib0o4p/JsMbXGTyAdeFdNIOkgiopB RZl4hNJuO1NOMg4Ld+FmDDAg6gbPzW5LGPFq9ywkaEPBj/A13mrJcrRWIMs0MWysDMCi YIhh/ZC2sJEMvY+GtTFHG0qFsRpOHXhzejG7JeIFh6rn+RkDwh0L5Zv+83OxYULZEMMV BD8GbW6V81h+DK2kGz04uMwiG9UYQ/+CbuZ1pDVwmhzGXTHdRjrhTWkQB6/n6Wc1JPgS OM2w== MIME-Version: 1.0 X-Received: by 10.52.66.104 with SMTP id e8mr10579798vdt.5.1373235738941; Sun, 07 Jul 2013 15:22:18 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.220.206.202 with HTTP; Sun, 7 Jul 2013 15:22:18 -0700 (PDT) In-Reply-To: <20130707213458.GH91021@kib.kiev.ua> References: <20130707213458.GH91021@kib.kiev.ua> Date: Sun, 7 Jul 2013 15:22:18 -0700 X-Google-Sender-Auth: XcJDmZA5zjq3nxivJoiI_WPA8Rw Message-ID: Subject: Re: Accessing struct pthread from kernel From: Davide Italiano To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-amd64@freebsd.org, 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: Sun, 07 Jul 2013 22:22:19 -0000 On Sun, Jul 7, 2013 at 2:34 PM, Konstantin Belousov wrote: > On Sat, Jul 06, 2013 at 01:22:05AM +0200, Davide Italiano wrote: >> 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). > You should not, see below. > >> >> 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? > > Coupling the libthr thread structure and kernel makes the ABI cast in > stone and avoids most possibilities of changing the libthr internals. > The same is true for kernel accessing the userspace TLS area of the thread. > > If you want kernel<->usermode communication of the thread run state, > and possibly also a way to advisory prevent a preemption of the > spinning usermode thread, you should create a dedicated parameter block > communicated from usermode to kernel on thread creation. For the main > thread, the block could be allocated by kernel by image activator, > placed on the stack and its address passed to the usermode by auxv. > > Note that you cannot access the usermode from the context switch > code. Wiring the corresponding page is very wasteful (think about a > process with 10,000 threads) and still does not provide any guarantees > since usermode can unmap or remap the range. You might see my 'fast > sigprocmask' patches where somewhat similar idea was implemented. > I think the tecnique you used for sigprocmask is neat and could be reused for sharing thread state between kernel and userland, with some modifications, thanks. That said, the problem I faced out before was slightly different. In order to implement adaptive spinning 'efficiently'[1], threads waiting for a lock held by some other thread should be able to access easily the state owner. If I understand the kernel locking code properly, to accomplish this, once a thread acquire a lock it writes the address of its struct thread in the owner field of the lock, so that other threads can easily access to his state. Now, it looks like applying such a tecnique for userspace is just impossible for the reasons you mentioned in your previous mail. The two alternatives that came up to the top of my mind are: 1) maintain an hashtable that keep track of the mapping tid->curthread, so that other thread perform a lookup on the hash table to get curthread access. 2) having an array indexed by tid where the state is stuck so that other threads can check what is the state of the lock owner. I do see problem in both of my ideas: 1) is clearly time inefficient, having to perform an hash table lookup might make useless the speedup obtained from the adaptive spinning implementation. 2) is clearly space inefficient, because in most of the situation the array would be 'sparse'. What do you prefer? If none, is there an alternative I'm missing? Thanks, > I also recommend you to look at the Solaris schedctl(2). I'll take a look at it in the next hours. [1] for some definition of 'efficient' -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-threads@FreeBSD.ORG Mon Jul 8 11:41: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 6CC59523 for ; Mon, 8 Jul 2013 11:41:06 +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 5FBA41471 for ; Mon, 8 Jul 2013 11:41:06 +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 r68BeXfE053981 for ; Mon, 8 Jul 2013 11:41:06 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r68B6hOD046233 for freebsd-threads@FreeBSD.org; Mon, 8 Jul 2013 11:06:43 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 8 Jul 2013 11:06:43 GMT Message-Id: <201307081106.r68B6hOD046233@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, 08 Jul 2013 11:41:06 -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 Mon Jul 8 21:26:09 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 DB49F70E; Mon, 8 Jul 2013 21:26:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 871441A11; Mon, 8 Jul 2013 21:26:09 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id E461AB94B; Mon, 8 Jul 2013 17:26:08 -0400 (EDT) From: John Baldwin To: freebsd-amd64@freebsd.org Subject: Re: Accessing struct pthread from kernel Date: Mon, 8 Jul 2013 14:56:54 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <20130707213458.GH91021@kib.kiev.ua> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201307081456.54944.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 08 Jul 2013 17:26:09 -0400 (EDT) Cc: Davide Italiano , 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, 08 Jul 2013 21:26:09 -0000 On Sunday, July 07, 2013 6:22:18 pm Davide Italiano wrote: > On Sun, Jul 7, 2013 at 2:34 PM, Konstantin Belousov wrote: > > On Sat, Jul 06, 2013 at 01:22:05AM +0200, Davide Italiano wrote: > >> 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). > > You should not, see below. > > > >> > >> 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? > > > > Coupling the libthr thread structure and kernel makes the ABI cast in > > stone and avoids most possibilities of changing the libthr internals. > > The same is true for kernel accessing the userspace TLS area of the thread. > > > > If you want kernel<->usermode communication of the thread run state, > > and possibly also a way to advisory prevent a preemption of the > > spinning usermode thread, you should create a dedicated parameter block > > communicated from usermode to kernel on thread creation. For the main > > thread, the block could be allocated by kernel by image activator, > > placed on the stack and its address passed to the usermode by auxv. > > > > Note that you cannot access the usermode from the context switch > > code. Wiring the corresponding page is very wasteful (think about a > > process with 10,000 threads) and still does not provide any guarantees > > since usermode can unmap or remap the range. You might see my 'fast > > sigprocmask' patches where somewhat similar idea was implemented. > > > > I think the tecnique you used for sigprocmask is neat and could be > reused for sharing thread state between kernel and userland, with some > modifications, thanks. > > That said, the problem I faced out before was slightly different. > In order to implement adaptive spinning 'efficiently'[1], threads > waiting for a lock held by some other thread should be able to access > easily the state owner. If I understand the kernel locking code > properly, to accomplish this, once a thread acquire a lock it writes > the address of its struct thread in the owner field of the lock, so > that other threads can easily access to his state. > > Now, it looks like applying such a tecnique for userspace is just > impossible for the reasons you mentioned in your previous mail. > The two alternatives that came up to the top of my mind are: > 1) maintain an hashtable that keep track of the mapping > tid->curthread, so that other thread perform a lookup on the hash > table to get curthread access. If you have a good hash, this should be close to O(1) in the common case, so the lookup shouldn't be bad. However, you have to handle the race of a thread being added or removed to the table while you are spinning, and that seems more problematic / expensive. You only have to do a best effort though, so you could perhaps never remove items from the table (just mark them as dead somehow, though even that isn't completely safe). > 2) having an array indexed by tid where the state is stuck so that > other threads can check what is the state of the lock owner. This might not be a bad idea, though I'd possibly make it a hash table. It handles the remaining race from above since an exiting thread can just tag its tid with a "dead" state and you don't have to worry about threads trying to deref a free'd pointer. -- John Baldwin From owner-freebsd-threads@FreeBSD.ORG Fri Jul 12 15:00:00 2013 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D12EB71C for ; Fri, 12 Jul 2013 15:00:00 +0000 (UTC) (envelope-from gnats@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 9DA1E1AF1 for ; Fri, 12 Jul 2013 15:00:00 +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 r6CF0020024108 for ; Fri, 12 Jul 2013 15:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6CF00Zr024107; Fri, 12 Jul 2013 15:00:00 GMT (envelope-from gnats) Resent-Date: Fri, 12 Jul 2013 15:00:00 GMT Resent-Message-Id: <201307121500.r6CF00Zr024107@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-threads@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Petr Salinger Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 92396474 for ; Fri, 12 Jul 2013 14:52:02 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from oldred.freebsd.org (oldred.freebsd.org [8.8.178.121]) by mx1.freebsd.org (Postfix) with ESMTP id 843591A9F for ; Fri, 12 Jul 2013 14:52:02 +0000 (UTC) Received: from oldred.freebsd.org ([127.0.1.6]) by oldred.freebsd.org (8.14.5/8.14.7) with ESMTP id r6CEq1fJ043660 for ; Fri, 12 Jul 2013 14:52:01 GMT (envelope-from nobody@oldred.freebsd.org) Received: (from nobody@localhost) by oldred.freebsd.org (8.14.5/8.14.5/Submit) id r6CEq1YX043656; Fri, 12 Jul 2013 14:52:01 GMT (envelope-from nobody) Message-Id: <201307121452.r6CEq1YX043656@oldred.freebsd.org> Date: Fri, 12 Jul 2013 14:52:01 GMT From: Petr Salinger To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Subject: threads/180496: clock_gettime() does not return CPU-time for zombie processes 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, 12 Jul 2013 15:00:00 -0000 >Number: 180496 >Category: threads >Synopsis: clock_gettime() does not return CPU-time for zombie processes >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-threads >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Fri Jul 12 15:00:00 UTC 2013 >Closed-Date: >Last-Modified: >Originator: Petr Salinger >Release: HEAD >Organization: >Environment: GNU/kFreeBSD 10.0-0-amd64 >Description: This is follow up to http://www.freebsd.org/cgi/query-pr.cgi?pr=168417 Our testsuite expects, that clock id created by clock_getcpuclockid() is valid also in time frame after process exit before its reap by parent. http://sourceware.org/git/?p=glibc.git;a=blob;f=rt/tst-cpuclock1.c;hb=HEAD live PID 46968 clock ffffffffc000b778 resolution 0.000001000 live PID 46968 before sleep => 0.000000000 live PID 46968 after sleep => 0.506846000 clock_nanosleep not supported for other process clock: Operation not supported clock_gettime on dead PID 46968 clock ffffffffc000b778 => Invalid argument It is rather reasonable expectation. Please allow getting of used time also for zombie processes. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: From owner-freebsd-threads@FreeBSD.ORG Fri Jul 12 18:50:01 2013 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 880248EB for ; Fri, 12 Jul 2013 18:50:01 +0000 (UTC) (envelope-from gnats@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 79C5F189D for ; Fri, 12 Jul 2013 18:50:01 +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 r6CIo12R072154 for ; Fri, 12 Jul 2013 18:50:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6CIo1Hw072153; Fri, 12 Jul 2013 18:50:01 GMT (envelope-from gnats) Date: Fri, 12 Jul 2013 18:50:01 GMT Message-Id: <201307121850.r6CIo1Hw072153@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org Cc: From: Konstantin Belousov Subject: Re: threads/180496: clock_gettime() does not return CPU-time for zombie processes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Konstantin Belousov List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 18:50:01 -0000 The following reply was made to PR threads/180496; it has been noted by GNATS. From: Konstantin Belousov To: Petr Salinger Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: threads/180496: clock_gettime() does not return CPU-time for zombie processes Date: Fri, 12 Jul 2013 21:47:43 +0300 Please try this. The clock_gettime() call on zombie clock worked for me. Note that the check for clock_getres() on the reapped process clock failed since we do not check for pid validity, all processes has the same clock. I do not see much sense in adding the useless check. diff --git a/sys/kern/kern_time.c b/sys/kern/kern_time.c index b68c949..9e0cc06 100644 --- a/sys/kern/kern_time.c +++ b/sys/kern/kern_time.c @@ -297,14 +297,9 @@ get_cputime(struct thread *td, clockid_t clock_id, struct timespec *ats) PROC_UNLOCK(td2->td_proc); } else { pid = clock_id & CPUCLOCK_ID_MASK; - p2 = pfind(pid); - if (p2 == NULL) - return (EINVAL); - error = p_cansee(td, p2); - if (error) { - PROC_UNLOCK(p2); + error = pget(pid, PGET_CANSEE, &p2); + if (error != 0) return (EINVAL); - } get_process_cputime(p2, ats); PROC_UNLOCK(p2); } From owner-freebsd-threads@FreeBSD.ORG Fri Jul 12 21:10:02 2013 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 508E1A28 for ; Fri, 12 Jul 2013 21:10:02 +0000 (UTC) (envelope-from gnats@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 4204C1F14 for ; Fri, 12 Jul 2013 21:10:02 +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 r6CLA10t099124 for ; Fri, 12 Jul 2013 21:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6CLA1a7099123; Fri, 12 Jul 2013 21:10:01 GMT (envelope-from gnats) Date: Fri, 12 Jul 2013 21:10:01 GMT Message-Id: <201307122110.r6CLA1a7099123@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org Cc: From: Petr Salinger Subject: Re: threads/180496: clock_gettime() does not return CPU-time for zombie processes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Petr Salinger List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 21:10:02 -0000 The following reply was made to PR threads/180496; it has been noted by GNATS. From: Petr Salinger To: Konstantin Belousov Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: threads/180496: clock_gettime() does not return CPU-time for zombie processes Date: Fri, 12 Jul 2013 22:59:51 +0200 (CEST) > Please try this. The clock_gettime() call on zombie clock worked > for me. Perfect. Many thanks. > Note that the check for clock_getres() on the reapped process clock > failed since we do not check for pid validity, all processes has > the same clock. I do not see much sense in adding the useless check. I agree that such check is technically useless. I cannot imagine usage of such restriction. The only reason of this check is wording of POSIX standard in http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.html "The clock_getres(), clock_gettime(), and clock_settime() functions shall fail if: [EINVAL] The clock_id argument does not specify a known clock." But this behaviour can be easily added in userspace wrapper. Similarly as " The clock_settime() function shall fail if: [EINVAL] The value of the clock_id argument is CLOCK_MONOTONIC." The kernel returns EPERM for ordinary user. Would be possible to MFC SYS_clock_getcpuclockid2 and related kernel changes into STABLE-9 ? Thanks again Petr From owner-freebsd-threads@FreeBSD.ORG Sat Jul 13 19:40:01 2013 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D0921AA6 for ; Sat, 13 Jul 2013 19:40:01 +0000 (UTC) (envelope-from gnats@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 C2ACF1DF4 for ; Sat, 13 Jul 2013 19:40:01 +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 r6DJe1gd026468 for ; Sat, 13 Jul 2013 19:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6DJe1iJ026467; Sat, 13 Jul 2013 19:40:01 GMT (envelope-from gnats) Date: Sat, 13 Jul 2013 19:40:01 GMT Message-Id: <201307131940.r6DJe1iJ026467@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: threads/180496: commit references a PR X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: dfilter service List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 19:40:01 -0000 The following reply was made to PR threads/180496; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: threads/180496: commit references a PR Date: Sat, 13 Jul 2013 19:33:03 +0000 (UTC) Author: kib Date: Sat Jul 13 19:32:50 2013 New Revision: 253325 URL: http://svnweb.freebsd.org/changeset/base/253325 Log: Allow to call clock_gettime() on the clock id for zombie process. Reported by: Petr Salinger PR: threads/180496 Sponsored by: The FreeBSD Foundation Modified: head/sys/kern/kern_time.c Modified: head/sys/kern/kern_time.c ============================================================================== --- head/sys/kern/kern_time.c Sat Jul 13 18:09:42 2013 (r253324) +++ head/sys/kern/kern_time.c Sat Jul 13 19:32:50 2013 (r253325) @@ -297,14 +297,9 @@ get_cputime(struct thread *td, clockid_t PROC_UNLOCK(td2->td_proc); } else { pid = clock_id & CPUCLOCK_ID_MASK; - p2 = pfind(pid); - if (p2 == NULL) - return (EINVAL); - error = p_cansee(td, p2); - if (error) { - PROC_UNLOCK(p2); + error = pget(pid, PGET_CANSEE, &p2); + if (error != 0) return (EINVAL); - } get_process_cputime(p2, ats); PROC_UNLOCK(p2); } _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-threads@FreeBSD.ORG Sat Jul 13 20:00:01 2013 Return-Path: Delivered-To: freebsd-threads@smarthost.ysv.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 CC5CD243 for ; Sat, 13 Jul 2013 20:00:01 +0000 (UTC) (envelope-from gnats@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 A4A671E57 for ; Sat, 13 Jul 2013 20:00:01 +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 r6DK01lM029858 for ; Sat, 13 Jul 2013 20:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r6DK01sg029857; Sat, 13 Jul 2013 20:00:01 GMT (envelope-from gnats) Date: Sat, 13 Jul 2013 20:00:01 GMT Message-Id: <201307132000.r6DK01sg029857@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org Cc: From: Konstantin Belousov Subject: Re: threads/180496: clock_gettime() does not return CPU-time for zombie processes X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Konstantin Belousov List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 20:00:01 -0000 The following reply was made to PR threads/180496; it has been noted by GNATS. From: Konstantin Belousov To: Petr Salinger Cc: freebsd-gnats-submit@FreeBSD.org Subject: Re: threads/180496: clock_gettime() does not return CPU-time for zombie processes Date: Sat, 13 Jul 2013 22:50:03 +0300 --E/fwm3itKUspkPYj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 12, 2013 at 10:59:51PM +0200, Petr Salinger wrote: > > Please try this. The clock_gettime() call on zombie clock worked > > for me. >=20 > Perfect. Many thanks. >=20 >=20 > > Note that the check for clock_getres() on the reapped process clock > > failed since we do not check for pid validity, all processes has > > the same clock. I do not see much sense in adding the useless check. >=20 > I agree that such check is technically useless. > I cannot imagine usage of such restriction. >=20 > The only reason of this check is wording of POSIX standard in > http://pubs.opengroup.org/onlinepubs/9699919799/functions/clock_getres.ht= ml >=20 > "The clock_getres(), clock_gettime(), and clock_settime() functions shall= =20 > fail if: > [EINVAL] > The clock_id argument does not specify a known clock." I could argue that the clock_id for the reapped pid is/was known. Anyway, due to our implementation of the clock ids, the id is not a handle, but rather a pid-like value. The reused pid would suddenly revive the clock. >=20 > But this behaviour can be easily added in userspace wrapper. > Similarly as > " The clock_settime() function shall fail if: > [EINVAL] > The value of the clock_id argument is CLOCK_MONOTONIC." >=20 > The kernel returns EPERM for ordinary user. >=20 >=20 > Would be possible to MFC SYS_clock_getcpuclockid2 > and related kernel changes into STABLE-9 ? stable/9 is frozen for 9.2. I do not think that re would approve merging of the non-critical new feature now. --E/fwm3itKUspkPYj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR4a9qAAoJEJDCuSvBvK1BU+oP/iR4xBn66pOaVZ3hZU1W/FIJ jBp3X9yjI5XKxVoq/pke5A2nVxaojcIL4V7v8QE+Pb90POpQAJM6cVwZjPPQdRG4 YGVQo8hXS9l2IuTbrsNy876ioQ9U3T1G530aJ7/h/tgZ1yJjn6eXDeBuAWaFyLfo nhoBgAV7PQOmaYvH3+qxuRXwZn/RyjorxrQww4eED+IkMuoL6/JFZTNpWuNwqsU2 fcc6HVNM5XyheHUbaBn42R5alBkk7U3FwfS5hoqlRb1K+Ps8axTRveRjfcnS12+H PmXuliW4kgg4S0WX6TB57Jt7gN6SsjjB7ghCfd9dPt4U0XAUFFCbIza6uWuKhOSw f3CTcdTuT0psHIbfl0zucwBY5HJxQgPy0JjtMBuwtdcNizdV2igzl/KzvRzzmSXB udHb9gr7x/29RYSZyPD5Rt55ZT0x8Ll237T1Ea5FRk2Jb33A/VIWs12DLXnoWLF9 xnzUY8VHIAlX0w5vOM3cVbFv0CaJi92oitygxb7Ss60Nv1FSzdQZEeK+gxiKL/EJ DX5NU2MYLlpW4ZYpsbgJE/Tu0qR9cl4Us8v43Ip+uWi/pBHBEJPvkdTJTCYlq63R oAkvi90GyNXbDxHArq2CKgzRG6MqKCIoN+XZOlporXbRXSD2OqRgY7zQ9KKveUH/ lDLHDxHJLEIwE8NMF22v =WSnN -----END PGP SIGNATURE----- --E/fwm3itKUspkPYj--