From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 05:06:02 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 341BDDB3; Sun, 4 Jan 2015 05:06:02 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bbn0101.outbound.protection.outlook.com [157.56.111.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9CB1F3227; Sun, 4 Jan 2015 05:06:00 +0000 (UTC) Received: from BLUPR05CA0050.namprd05.prod.outlook.com (10.141.20.20) by BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) with Microsoft SMTP Server (TLS) id 15.1.49.12; Sun, 4 Jan 2015 05:05:58 +0000 Received: from BL2FFO11FD039.protection.gbl (2a01:111:f400:7c09::108) by BLUPR05CA0050.outlook.office365.com (2a01:111:e400:855::20) with Microsoft SMTP Server (TLS) id 15.1.49.12 via Frontend Transport; Sun, 4 Jan 2015 05:05:58 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD039.mail.protection.outlook.com (10.173.161.135) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Sun, 4 Jan 2015 05:05:58 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 3 Jan 2015 21:05:56 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t0455sW41644; Sat, 3 Jan 2015 21:05:54 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t0455dMr079659; Sun, 4 Jan 2015 00:05:39 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201501040505.t0455dMr079659@idle.juniper.net> To: Alfred Perlstein Subject: Re: Libxo bugs and fixes. In-Reply-To: <549F742D.3000802@mu.org> Date: Sun, 4 Jan 2015 00:05:39 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(189002)(120916001)(50466002)(50986999)(110136001)(46102003)(64706001)(47776003)(21056001)(20776003)(105596002)(54356999)(48376002)(84676001)(86362001)(87936001)(6806004)(106466001)(99396003)(92566001)(31966008)(77156002)(53416004)(62966003)(76506005)(69596002)(81156004)(97736003)(68736005)(107046002)(77096005)(2950100001)(4396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB433; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BLUPR05MB433; X-Forefront-PRVS: 0446F0FCE1 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2015 05:05:58.0665 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB433 Cc: Marcel Moolenaar , John-Mark Gurney , Alfred Perlstein , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 05:06:02 -0000 Alfred Perlstein writes: >Solaris and glibc have a private libc function to check if a stream is >line buffered called int __flbf (FILE *stream) which returns true/false >if the stream if line buffered or not. I dislike using a non-standard function like this. I'd prefer the caller flag this information on the handle. There's already a flag one can set on a handle that will trigger a call to flush data buffered in the handle to the write function. I'll add a function to set a custom flusher, which will be called at appropriate times. Apps like netstat will know if they need iterative output, and can decide to set the XOF_FLUSH flag with a flusher callback. If needed, that callback can use __flbf. >One other topic, I talked to some webdevs and they suggested that we >have a "jsonLD" which stands for "json line delimited" that would be >useful for periodic output. This would be halfway between a "pretty >format" and a compact stream format. meaning that each line would be a >record, example: I can certainly add this, but the interesting issue would be how to form/reform the hierarchy surrounding the iterative output. Simplest case would be that the caller is resonsible for this, and the libxo just provides a flag to enable this and a function to say "this is a object". Thanks, Phil From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 05:10:52 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 40543EF1; Sun, 4 Jan 2015 05:10:52 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0140.outbound.protection.outlook.com [157.56.111.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EBD43255; Sun, 4 Jan 2015 05:10:50 +0000 (UTC) Received: from CO2PR05CA020.namprd05.prod.outlook.com (10.141.241.148) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.1.49.12; Sun, 4 Jan 2015 05:10:48 +0000 Received: from BL2FFO11FD025.protection.gbl (2a01:111:f400:7c09::194) by CO2PR05CA020.outlook.office365.com (2a01:111:e400:1429::20) with Microsoft SMTP Server (TLS) id 15.1.49.12 via Frontend Transport; Sun, 4 Jan 2015 05:10:48 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD025.mail.protection.outlook.com (10.173.161.104) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Sun, 4 Jan 2015 05:10:48 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sat, 3 Jan 2015 21:10:46 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t045AiW44569; Sat, 3 Jan 2015 21:10:44 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t045AU6i079716; Sun, 4 Jan 2015 00:10:30 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201501040510.t045AU6i079716@idle.juniper.net> To: Alfred Perlstein Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML In-Reply-To: Date: Sun, 4 Jan 2015 00:10:30 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(199003)(164054003)(189002)(50986999)(2950100001)(62966003)(86362001)(64706001)(47776003)(48376002)(120916001)(50466002)(20776003)(54356999)(77156002)(92566001)(87936001)(6806004)(76506005)(77096005)(97736003)(99396003)(84676001)(4396001)(106466001)(21056001)(53416004)(107046002)(105596002)(81156004)(69596002)(110136001)(46102003)(68736005)(31966008); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB441; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR05MB441; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:CO1PR05MB441; X-Forefront-PRVS: 0446F0FCE1 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB441; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2015 05:10:48.0323 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB441 Cc: "adrian@FreeBSD.org" , Marcel Moolenaar , "Simon J. Gerraty" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov , Garrett Cooper X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 05:10:52 -0000 Alfred Perlstein writes: >Would like to expedite process here, I'm going to check in a few interim fixes so that p >eople can continue hackathon on libxo over the holiday break. When you're back please f >eel free to revert/modify my changes. I'm happy to import fixes in any form (and am currently addressing the D1378 and D1379), but the simplest way for me would be a fork on the github sources. Not sure how hard that makes things on your end, esp. re: importing of next libxo release. Also: sorry for the slow responses. I was on vacation for most of December, with multiple overlapping sets of relatives in town. Life is returning to normal now. Thanks, Phil From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 05:25:04 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 065C1124; Sun, 4 Jan 2015 05:25:04 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 302AD645CC; Sun, 4 Jan 2015 05:25:03 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 4CB13341F874; Sat, 3 Jan 2015 21:25:02 -0800 (PST) Message-ID: <54A8CEDA.4020902@freebsd.org> Date: Sat, 03 Jan 2015 21:25:46 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Phil Shafer Subject: Re: Libxo bugs and fixes. References: <201501040505.t0455dMr079659@idle.juniper.net> In-Reply-To: <201501040505.t0455dMr079659@idle.juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcel Moolenaar , John-Mark Gurney , Alfred Perlstein , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 05:25:04 -0000 On 1/3/15 9:05 PM, Phil Shafer wrote: > Alfred Perlstein writes: >> Solaris and glibc have a private libc function to check if a stream is >> line buffered called int __flbf (FILE *stream) which returns true/false >> if the stream if line buffered or not. > > I dislike using a non-standard function like this. I'd prefer the > caller flag this information on the handle. There's already a flag > one can set on a handle that will trigger a call to flush data > buffered in the handle to the write function. I'll add a function > to set a custom flusher, which will be called at appropriate times. > Apps like netstat will know if they need iterative output, and can > decide to set the XOF_FLUSH flag with a flusher callback. If needed, > that callback can use __flbf. It's not *that* non-standard since glibc and solaris support it. :) That's like saying that snprintf was a bad idea back before it was in the standards, but I digress. > >> One other topic, I talked to some webdevs and they suggested that we >> have a "jsonLD" which stands for "json line delimited" that would be >> useful for periodic output. This would be halfway between a "pretty >> format" and a compact stream format. meaning that each line would be a >> record, example: > > I can certainly add this, but the interesting issue would be how > to form/reform the hierarchy surrounding the iterative output. > Simplest case would be that the caller is resonsible for this, and > the libxo just provides a flag to enable this and a function to say > "this is a object". I think we just need a "cork/uncork" sort of api that will make it a single line? -Alfred From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 05:28:48 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE32F1DF; Sun, 4 Jan 2015 05:28:48 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id B82DC645EC; Sun, 4 Jan 2015 05:28:48 +0000 (UTC) Received: from AlfredMacbookAir.local (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 24961341F875; Sat, 3 Jan 2015 21:28:48 -0800 (PST) Message-ID: <54A8CFBB.5090609@freebsd.org> Date: Sat, 03 Jan 2015 21:29:31 -0800 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Phil Shafer Subject: Re: XML Output: libxo - provide single API to output TXT, XML, JSON and HTML References: <201501040510.t045AU6i079716@idle.juniper.net> In-Reply-To: <201501040510.t045AU6i079716@idle.juniper.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: "adrian@FreeBSD.org" , Marcel Moolenaar , "Simon J. Gerraty" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov , Garrett Cooper X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 05:28:48 -0000 On 1/3/15 9:10 PM, Phil Shafer wrote: > Alfred Perlstein writes: >> Would like to expedite process here, I'm going to check in a few interim fixes so that p >> eople can continue hackathon on libxo over the holiday break. When you're back please f >> eel free to revert/modify my changes. > > I'm happy to import fixes in any form (and am currently addressing > the D1378 and D1379), but the simplest way for me would be a fork > on the github sources. Not sure how hard that makes things on your > end, esp. re: importing of next libxo release. It's with, with git I can find a way. What I should have done, and will likely do is use either "git subtree" or "git submodule" in my 'libxo_master' branch to track a forked (github forked, not Open/NetBSD forked). This will allow us to track juniper's libxo. Shouldn't be a problem. > > Also: sorry for the slow responses. I was on vacation for most of > December, with multiple overlapping sets of relatives in town. Life > is returning to normal now. No worries, welcome to 2015! -Alfred From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 06:37:05 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A1841952 for ; Sun, 4 Jan 2015 06:37:05 +0000 (UTC) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 344F93FDB for ; Sun, 4 Jan 2015 06:37:05 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id k14so8080726wgh.30 for ; Sat, 03 Jan 2015 22:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=5EoC/tONEqiPrt9TT6lFIKsmSBhZMTL6jYAxSiiyL+U=; b=pr2o2xVGRnzFK0FOqew2M+ycrdG8faZ0agNntoAVYFLm1lFSmff4xMs5WBrMRpUmhM eaXYYOAkTTeZGGfHGDLhUwc7awwUeK56eOsG4u9ren0RjB6WaN1u+jL18LohQy18BIdG 4xq1JdRdUxYcHNEmxOxe7Z2s3XG0ZDnPDthAhwHmX/IZ/rvsUzrzuUl5h4eoxBU7faqK KQfmu9Bavd24YGTESGxGiLyxBBnYINleao5x1EmkFuLFK3qAUPG5K/gCUcYi6adJsNJ5 TLDHKrtd34L4dZCo9KcBUSLwboZkfx8yofEqVlTn2Oe8K9rJ/SAufODQM0qZE8lcOPoD zJZw== MIME-Version: 1.0 X-Received: by 10.194.24.103 with SMTP id t7mr167460272wjf.15.1420353423660; Sat, 03 Jan 2015 22:37:03 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Sat, 3 Jan 2015 22:37:03 -0800 (PST) In-Reply-To: <2F715AD9-CF34-4516-B75E-E14C77BFD2E3@mu.org> References: <2F715AD9-CF34-4516-B75E-E14C77BFD2E3@mu.org> Date: Sat, 3 Jan 2015 22:37:03 -0800 X-Google-Sender-Auth: RXlEUX_w2jGLXTqtxqD6pfxm5dg Message-ID: Subject: Re: odd behaviour with graphics, vt(4), VGA, and probing the text region leading to NMIs at boot From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 06:37:05 -0000 On 3 January 2015 at 09:31, Alfred Perlstein wrote: > Sounds like the virtualization code is sensitive to the mode. Meaning that whatever is virtualizing the graphics card doesn't do the proper thing when you're in a graphical mode. Can't the probes be turned off? So it's happening quite late in the boot process - when the ISA bus is being probed. So, maybe we can just avoid probing the dev/vga stuff like this. I'll have to talk to Ed/ray about how the syscons and vt devices hold together. I'm kinda shocked that we're re-probing things via an ISA probe so late in the boot process. > Basically when the "card" is in gfx mode, it doesn't do the right thing for those memory addresses. Sounds like the fix would be to not touch those regions unless you're actually in text mode. -adrian From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 11:46:06 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D24262C9; Sun, 4 Jan 2015 11:46:06 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71897381E; Sun, 4 Jan 2015 11:46:06 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t04Bk0Nb019720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 4 Jan 2015 13:46:00 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t04Bk0Nb019720 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t04Bk0UZ019718; Sun, 4 Jan 2015 13:46:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 4 Jan 2015 13:46:00 +0200 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: Fixing dlopen("libpthread.so") Message-ID: <20150104114600.GC42409@kib.kiev.ua> References: <20141226165337.GJ1754@kib.kiev.ua> <20150103212837.GC46373@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="yudcn1FV7Hsu/q59" Content-Disposition: inline In-Reply-To: <20150103212837.GC46373@stack.nl> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: threads@freebsd.org, arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 11:46:06 -0000 --yudcn1FV7Hsu/q59 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 03, 2015 at 10:28:37PM +0100, Jilles Tjoelker wrote: >=20 > I think this can work, conceptually. The changes were already committed, right before I got your mail. Still, thank you for the useful review. >=20 > Does this also mean that the order of libc and libthr on the link line > no longer matters? (so SVN r265003 could be reverted?) I think yes, it could. I have similar queries already. IMO it makes sense to wait some time for the changes to settle before even asking for testing of such reversals. >=20 > It looks like this change may introduce more indirection in common paths > which might harm performance. The effect is slight and on the other hand > more single-threaded applications can benefit from non-libthr > performance. >=20 > I noticed a problem in lib/libc/gen/raise.c: it calls the INTERPOS_pause > entry instead of the INTERPOS_raise entry. Alternatively, libc could > call thr_self() and thr_kill() so libthr need not do anything (much like > how lib/libc/gen/sem_new.c works). This was noted already and corrected raise.c committed. I have mixed feeling about the proposal to change raise(3) to use threading syscalls. On the one hand, it indeed works, on the other, there are subtle differences, not all important, WRT the change. E.g., puzzling ktrace output, changed si_code from SI_USER to SI_LWP (is this a bug on its own ?) . >=20 > The number of interposers could be reduced slightly by doing simple work > like wait(), waitpid() and wait3() before instead of after > interposition. This would be an additional change and the current patch > is more like the existing code. Could you, please, explain this ? What exactly should be done before what, and how would it help ? >=20 > In lib/libc/sys/__error.c, __error_selector should be declared static or > __hidden and an accessor function added for libthr, to avoid an > additional pointer chase in a common path. One more PLT and GOT > reference in some situations may be avoided by making a __hidden alias > for __error_unthreaded and making that __error_selector's initial value. __error_unthreaded can be made static, it seems. I added __set_error_selector() and made __error_selector static. >=20 > Although __libc_interposing is properly not exported (with > __libc_interposing_slot accessor), the full benefit is not obtained > because __libc_interposing is not declared __hidden in > lib/libc/include/libc_private.h, so the compiler will generate an > indirect access anyway (and ld will fix it up using a relative > relocation). Done. >=20 > In lib/libthr/thread/thr_private.h, __error_threaded() can be declared > __hidden. Done. >=20 > Sharing __sys_* code between libc and libthr is a net loss (the two > copies of the name, GOT entry, PLT entry and longer instruction > sequences are almost certainly larger than a syscall stub (32 bytes on > amd64)), so I think the best fix for most indirection from > __libc_interposing entries is to give libthr its own copy and mark both > copies hidden, instead of adding hidden aliases now. Do you mean linking syscall stubs (__sys_* trampolines) statically into the libthr, and referencing them directly from the C code ? Yes, this will be huge benefitial, both for libthr and ld-elf.so.1, for rtld it is even kind of required, see r276646 and other uses of __sys. I thought about it. But we need something like libsyscalls.a and libsyscalls_pic.a extracted from libc first. If I am misinterpreting your suggestion, please explain it in more details. diff --git a/lib/libc/include/libc_private.h b/lib/libc/include/libc_privat= e.h index adf342d..ea1a97b 100644 --- a/lib/libc/include/libc_private.h +++ b/lib/libc/include/libc_private.h @@ -173,13 +173,13 @@ typedef pthread_func_t pthread_func_entry_t[2]; =20 extern pthread_func_entry_t __thr_jtable[]; =20 -extern int *(*__error_selector)(void); +void __set_error_selector(int *(*arg)(void)); int _pthread_mutex_init_calloc_cb_stub(pthread_mutex_t *mutex, void *(calloc_cb)(__size_t, __size_t)); =20 typedef int (*interpos_func_t)(void); interpos_func_t *__libc_interposing_slot(int interposno); -extern interpos_func_t __libc_interposing[]; +extern interpos_func_t __libc_interposing[] __hidden; =20 enum { INTERPOS_accept, diff --git a/lib/libc/sys/Symbol.map b/lib/libc/sys/Symbol.map index 7d82361..f1f57ba 100644 --- a/lib/libc/sys/Symbol.map +++ b/lib/libc/sys/Symbol.map @@ -1045,8 +1045,7 @@ FBSDprivate_1.0 { __sys_write; _writev; __sys_writev; - __error_unthreaded; - __error_selector; + __set_error_selector; nlm_syscall; gssd_syscall; __libc_interposing_slot; diff --git a/lib/libc/sys/__error.c b/lib/libc/sys/__error.c index 329d124..28cc31d 100644 --- a/lib/libc/sys/__error.c +++ b/lib/libc/sys/__error.c @@ -32,13 +32,21 @@ __FBSDID("$FreeBSD$"); =20 extern int errno; =20 -int * +static int * __error_unthreaded(void) { - return(&errno); + + return (&errno); } =20 -int *(*__error_selector)(void) =3D __error_unthreaded; +static int *(*__error_selector)(void) =3D __error_unthreaded; + +void +__set_error_selector(int *(*arg)(void)) +{ + + __error_selector =3D arg; +} =20 int * __error(void) diff --git a/lib/libthr/thread/thr_private.h b/lib/libthr/thread/thr_privat= e.h index e8edbe1..0c16b2a 100644 --- a/lib/libthr/thread/thr_private.h +++ b/lib/libthr/thread/thr_private.h @@ -914,7 +914,7 @@ void _thr_tsd_unload(struct dl_phdr_info *phdr_info) __= hidden; void _thr_sigact_unload(struct dl_phdr_info *phdr_info) __hidden; void _thr_stack_fix_protection(struct pthread *thrd); =20 -int *__error_threaded(void); +int *__error_threaded(void) __hidden; void __thr_interpose_libc(void) __hidden; pid_t __thr_fork(void); int __thr_pause(void) __hidden; diff --git a/lib/libthr/thread/thr_syscalls.c b/lib/libthr/thread/thr_sysca= lls.c index 60427d8..a4fe7e8 100644 --- a/lib/libthr/thread/thr_syscalls.c +++ b/lib/libthr/thread/thr_syscalls.c @@ -692,7 +692,7 @@ void __thr_interpose_libc(void) { =20 - __error_selector =3D __error_threaded; + __set_error_selector(__error_threaded); #define SLOT(name) \ *(__libc_interposing_slot(INTERPOS_##name)) =3D \ (interpos_func_t)__thr_##name; --yudcn1FV7Hsu/q59 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUqSf4AAoJEJDCuSvBvK1BltwQAKbcDFHdJ2kXYZkyrdhTqKRd mBqYUz6xvSeNrfNGmGnK+PpVq5+Oky6vkuE5J0K6eS3mQphzwAflumQake6T13xe RSUz7bmef8y9mSq4fMuJMLI0k3ppFQMV7+tjdORoVOMXV9FB6FUpYNZr51mTEhrg WPtsDOo7vbGZjiDP3WFzsbWkQRftq7G7YpVdA3Ya8FNOSrTDzxdQ1yVMjex/4rP0 9i3GDs1GjgP5tOAjU2XC26/tBU+qvnAgLr0sMPbVkutSx0FZVsiHu4voGcg4zfKd RD0UOe1wF0+GW1NBlfh/aH095ay+V/qs8RFkspIBJ9P+U6mr1VmU+wF1uINyL151 W7VL7AaLxlfhIz2UUsKflN/NKAmSfV6DHo4gIC0eHxVbGOzwbXgb9Kzu2rbj1as2 hFqPZ41A4uMxCSUIXvybkvkOJs7g3eN/v7kHb/n/23eRomQ84yATvopioqhPGxna hdTzqOUlPfIYdudVX4mhUZCYYtoDkz9EmVheIEhXAXMucM/OJWuUhnimw8OX3Qae 9Du6NhNS/catg7RU+Vbc7Z6Rt/69Fd1HbWb4dc01jcFOV96BpGmUiOc0/C2qstIg +X4c9Y5QvbpUxwjPX4pcJOyHL7CoLDTUIlQ2Jzm4weanLlE6hUx/Xq92Dq9MdhZS meOJXHCDL3UMuwWZgHQ0 =JGXq -----END PGP SIGNATURE----- --yudcn1FV7Hsu/q59-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 12:14:29 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A747B302; Sun, 4 Jan 2015 12:14:29 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1D0B53E3D; Sun, 4 Jan 2015 12:14:28 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 4F5291FE022; Sun, 4 Jan 2015 13:14:26 +0100 (CET) Message-ID: <54A92ED1.2070906@selasky.org> Date: Sun, 04 Jan 2015 13:15:13 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Ivan Klymenko Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> In-Reply-To: <54A53F4F.2000003@selasky.org> Content-Type: multipart/mixed; boundary="------------070009030809080804000507" Cc: FreeBSD Current , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 12:14:29 -0000 This is a multi-part message in MIME format. --------------070009030809080804000507 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, Please find attached an updated timeout patch which also updates clients in the kernel area to use the callout API properly, like cv_timedwait(). Previously there was some custom sleepqueue code in the callout subsystem. All of that has now been removed and we allow callouts to be protected by spinlocks. This allows us to tear down the callback like done with regular mutexes, and a "td_slpmutex" has been added to "struct thread" to atomically teardown the "td_slpcallout". Further the "TDF_TIMOFAIL" and "SWT_SLEEPQTIMO" states can now be completely removed. Summary of changes: 1) Make consistent callout API which also supports spinlocks for the callback function. This has been done to allow atomic callout stop of "td_slpcallout" without the need of many kernel threading quirks. 2) It is not allowed to migrate CPU if the timeout is restarted while the timeout callback is executing. Callouts must be stopped before CPU migration is allowed. Optionally drained. 3) Shared lock support has been removed, because it prevents atomic stop of the callback function. 4) A new API to drain callouts asynchronously has been added, called "callout_drain_async()". Please test and report any errors! Patch applies to FreeBSD-11-current as of today. Thank you! --HPS --------------070009030809080804000507 Content-Type: text/x-patch; name="kern_timeout_wip_v2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kern_timeout_wip_v2.diff" Index: sys/ofed/include/linux/completion.h =================================================================== --- sys/ofed/include/linux/completion.h (revision 276531) +++ sys/ofed/include/linux/completion.h (working copy) @@ -105,7 +105,9 @@ if (c->done) break; sleepq_add(c, NULL, "completion", flags, 0); + sleepq_release(c); sleepq_set_timeout(c, end - ticks); + sleepq_lock(c); if (flags & SLEEPQ_INTERRUPTIBLE) { if (sleepq_timedwait_sig(c, 0) != 0) return (-ERESTARTSYS); Index: sys/kern/init_main.c =================================================================== --- sys/kern/init_main.c (revision 276531) +++ sys/kern/init_main.c (working copy) @@ -504,7 +504,8 @@ callout_init_mtx(&p->p_itcallout, &p->p_mtx, 0); callout_init_mtx(&p->p_limco, &p->p_mtx, 0); - callout_init(&td->td_slpcallout, CALLOUT_MPSAFE); + mtx_init(&td->td_slpmutex, "td_slpmutex", NULL, MTX_SPIN); + callout_init_mtx(&td->td_slpcallout, &td->td_slpmutex, 0); /* Create credentials. */ p->p_ucred = crget(); Index: sys/kern/kern_condvar.c =================================================================== --- sys/kern/kern_condvar.c (revision 276531) +++ sys/kern/kern_condvar.c (working copy) @@ -313,15 +313,13 @@ DROP_GIANT(); sleepq_add(cvp, lock, cvp->cv_description, SLEEPQ_CONDVAR, 0); + sleepq_release(cvp); sleepq_set_timeout_sbt(cvp, sbt, pr, flags); if (lock != &Giant.lock_object) { - if (class->lc_flags & LC_SLEEPABLE) - sleepq_release(cvp); WITNESS_SAVE(lock, lock_witness); lock_state = class->lc_unlock(lock); - if (class->lc_flags & LC_SLEEPABLE) - sleepq_lock(cvp); } + sleepq_lock(cvp); rval = sleepq_timedwait(cvp, 0); #ifdef KTRACE @@ -383,15 +381,13 @@ sleepq_add(cvp, lock, cvp->cv_description, SLEEPQ_CONDVAR | SLEEPQ_INTERRUPTIBLE, 0); + sleepq_release(cvp); sleepq_set_timeout_sbt(cvp, sbt, pr, flags); if (lock != &Giant.lock_object) { - if (class->lc_flags & LC_SLEEPABLE) - sleepq_release(cvp); WITNESS_SAVE(lock, lock_witness); lock_state = class->lc_unlock(lock); - if (class->lc_flags & LC_SLEEPABLE) - sleepq_lock(cvp); } + sleepq_lock(cvp); rval = sleepq_timedwait_sig(cvp, 0); #ifdef KTRACE Index: sys/kern/kern_lock.c =================================================================== --- sys/kern/kern_lock.c (revision 276531) +++ sys/kern/kern_lock.c (working copy) @@ -210,9 +210,11 @@ GIANT_SAVE(); sleepq_add(&lk->lock_object, NULL, wmesg, SLEEPQ_LK | (catch ? SLEEPQ_INTERRUPTIBLE : 0), queue); - if ((flags & LK_TIMELOCK) && timo) + if ((flags & LK_TIMELOCK) && timo) { + sleepq_release(&lk->lock_object); sleepq_set_timeout(&lk->lock_object, timo); - + sleepq_lock(&lk->lock_object); + } /* * Decisional switch for real sleeping. */ Index: sys/kern/kern_switch.c =================================================================== --- sys/kern/kern_switch.c (revision 276531) +++ sys/kern/kern_switch.c (working copy) @@ -93,8 +93,6 @@ &DPCPU_NAME(sched_switch_stats[SWT_TURNSTILE]), ""); SCHED_STAT_DEFINE_VAR(sleepq, &DPCPU_NAME(sched_switch_stats[SWT_SLEEPQ]), ""); -SCHED_STAT_DEFINE_VAR(sleepqtimo, - &DPCPU_NAME(sched_switch_stats[SWT_SLEEPQTIMO]), ""); SCHED_STAT_DEFINE_VAR(relinquish, &DPCPU_NAME(sched_switch_stats[SWT_RELINQUISH]), ""); SCHED_STAT_DEFINE_VAR(needresched, Index: sys/kern/kern_synch.c =================================================================== --- sys/kern/kern_synch.c (revision 276531) +++ sys/kern/kern_synch.c (working copy) @@ -236,13 +236,17 @@ * return from cursig(). */ sleepq_add(ident, lock, wmesg, sleepq_flags, 0); - if (sbt != 0) - sleepq_set_timeout_sbt(ident, sbt, pr, flags); if (lock != NULL && class->lc_flags & LC_SLEEPABLE) { sleepq_release(ident); WITNESS_SAVE(lock, lock_witness); lock_state = class->lc_unlock(lock); + if (sbt != 0) + sleepq_set_timeout_sbt(ident, sbt, pr, flags); sleepq_lock(ident); + } else if (sbt != 0) { + sleepq_release(ident); + sleepq_set_timeout_sbt(ident, sbt, pr, flags); + sleepq_lock(ident); } if (sbt != 0 && catch) rval = sleepq_timedwait_sig(ident, pri); @@ -306,8 +310,11 @@ * We put ourselves on the sleep queue and start our timeout. */ sleepq_add(ident, &mtx->lock_object, wmesg, SLEEPQ_SLEEP, 0); - if (sbt != 0) + if (sbt != 0) { + sleepq_release(ident); sleepq_set_timeout_sbt(ident, sbt, pr, flags); + sleepq_lock(ident); + } /* * Can't call ktrace with any spin locks held so it can lock the Index: sys/kern/kern_thread.c =================================================================== --- sys/kern/kern_thread.c (revision 276531) +++ sys/kern/kern_thread.c (working copy) @@ -149,6 +149,9 @@ audit_thread_alloc(td); #endif umtx_thread_alloc(td); + + mtx_init(&td->td_slpmutex, "td_slpmutex", NULL, MTX_SPIN); + callout_init_mtx(&td->td_slpcallout, &td->td_slpmutex, 0); return (0); } @@ -162,6 +165,10 @@ td = (struct thread *)mem; + /* make sure to drain any use of the "td->td_slpcallout" */ + callout_drain(&td->td_slpcallout); + mtx_destroy(&td->td_slpmutex); + #ifdef INVARIANTS /* Verify that this thread is in a safe state to free. */ switch (td->td_state) { @@ -544,7 +551,6 @@ LIST_INIT(&td->td_lprof[0]); LIST_INIT(&td->td_lprof[1]); sigqueue_init(&td->td_sigqueue, p); - callout_init(&td->td_slpcallout, CALLOUT_MPSAFE); TAILQ_INSERT_TAIL(&p->p_threads, td, td_plist); p->p_numthreads++; } Index: sys/kern/kern_timeout.c =================================================================== --- sys/kern/kern_timeout.c (revision 276531) +++ sys/kern/kern_timeout.c (working copy) @@ -54,6 +54,8 @@ #include #include #include +#include +#include #include #include #include @@ -124,37 +126,216 @@ */ u_int callwheelsize, callwheelmask; +typedef void callout_mutex_op_t(struct lock_object *); +typedef int callout_owned_op_t(struct lock_object *); + +struct callout_mutex_ops { + callout_mutex_op_t *lock; + callout_mutex_op_t *unlock; + callout_owned_op_t *owned; +}; + +enum { + CALLOUT_LC_UNUSED_0, + CALLOUT_LC_UNUSED_1, + CALLOUT_LC_UNUSED_2, + CALLOUT_LC_UNUSED_3, + CALLOUT_LC_SPIN, + CALLOUT_LC_MUTEX, + CALLOUT_LC_RW, + CALLOUT_LC_RM, +}; + +static void +callout_mutex_op_none(struct lock_object *lock) +{ +} + +static int +callout_owned_op_none(struct lock_object *lock) +{ + return (0); +} + +static void +callout_mutex_lock(struct lock_object *lock) +{ + mtx_lock((struct mtx *)lock); +} + +static void +callout_mutex_unlock(struct lock_object *lock) +{ + mtx_unlock((struct mtx *)lock); +} + +static void +callout_mutex_lock_spin(struct lock_object *lock) +{ + mtx_lock_spin((struct mtx *)lock); +} + +static void +callout_mutex_unlock_spin(struct lock_object *lock) +{ + mtx_unlock_spin((struct mtx *)lock); +} + +static int +callout_mutex_owned(struct lock_object *lock) +{ + return (mtx_owned((struct mtx *)lock)); +} + +static void +callout_rm_wlock(struct lock_object *lock) +{ + rm_wlock((struct rmlock *)lock); +} + +static void +callout_rm_wunlock(struct lock_object *lock) +{ + rm_wunlock((struct rmlock *)lock); +} + +static int +callout_rm_owned(struct lock_object *lock) +{ + return (rm_wowned((struct rmlock *)lock)); +} + +static void +callout_rw_wlock(struct lock_object *lock) +{ + rw_wlock((struct rwlock *)lock); +} + +static void +callout_rw_wunlock(struct lock_object *lock) +{ + rw_wunlock((struct rwlock *)lock); +} + +static int +callout_rw_owned(struct lock_object *lock) +{ + return (rw_wowned((struct rwlock *)lock)); +} + +static const struct callout_mutex_ops callout_mutex_ops[8] = { + [CALLOUT_LC_UNUSED_0] = { + .lock = callout_mutex_op_none, + .unlock = callout_mutex_op_none, + .owned = callout_owned_op_none, + }, + [CALLOUT_LC_UNUSED_1] = { + .lock = callout_mutex_op_none, + .unlock = callout_mutex_op_none, + .owned = callout_owned_op_none, + }, + [CALLOUT_LC_UNUSED_2] = { + .lock = callout_mutex_op_none, + .unlock = callout_mutex_op_none, + .owned = callout_owned_op_none, + }, + [CALLOUT_LC_UNUSED_3] = { + .lock = callout_mutex_op_none, + .unlock = callout_mutex_op_none, + .owned = callout_owned_op_none, + }, + [CALLOUT_LC_SPIN] = { + .lock = callout_mutex_lock_spin, + .unlock = callout_mutex_unlock_spin, + .owned = callout_mutex_owned, + }, + [CALLOUT_LC_MUTEX] = { + .lock = callout_mutex_lock, + .unlock = callout_mutex_unlock, + .owned = callout_mutex_owned, + }, + [CALLOUT_LC_RW] = { + .lock = callout_rw_wlock, + .unlock = callout_rw_wunlock, + .owned = callout_rw_owned, + }, + [CALLOUT_LC_RM] = { + .lock = callout_rm_wlock, + .unlock = callout_rm_wunlock, + .owned = callout_rm_owned, + }, +}; + +static void +callout_lock_client(int c_flags, struct lock_object *c_lock) +{ + callout_mutex_ops[CALLOUT_GET_LC(c_flags)].lock(c_lock); +} + +static void +callout_unlock_client(int c_flags, struct lock_object *c_lock) +{ + callout_mutex_ops[CALLOUT_GET_LC(c_flags)].unlock(c_lock); +} + +#ifdef SMP +static int +callout_lock_owned_client(int c_flags, struct lock_object *c_lock) +{ + return (callout_mutex_ops[CALLOUT_GET_LC(c_flags)].owned(c_lock)); +} +#endif + /* - * The callout cpu exec entities represent informations necessary for - * describing the state of callouts currently running on the CPU and the ones - * necessary for migrating callouts to the new callout cpu. In particular, - * the first entry of the array cc_exec_entity holds informations for callout - * running in SWI thread context, while the second one holds informations - * for callout running directly from hardware interrupt context. - * The cached informations are very important for deferring migration when - * the migrating callout is already running. + * The callout CPU exec structure represent information necessary for + * describing the state of callouts currently running on the CPU and + * for handling deferred callout restarts. + * + * In particular, the first entry of the array cc_exec_entity holds + * information for callouts running from the SWI thread context, while + * the second one holds information for callouts running directly from + * the hardware interrupt context. */ struct cc_exec { - struct callout *cc_next; + /* + * The "cc_curr" points to the currently executing callout and + * is protected by the "cc_lock" spinlock. If no callback is + * currently executing it is equal to "NULL". + */ struct callout *cc_curr; -#ifdef SMP - void (*ce_migration_func)(void *); - void *ce_migration_arg; - int ce_migration_cpu; - sbintime_t ce_migration_time; - sbintime_t ce_migration_prec; -#endif - bool cc_cancel; - bool cc_waiting; + /* + * The "cc_restart_args" structure holds the argument for a + * deferred callback restart and is protected by the "cc_lock" + * spinlock. The structure is only valid if "cc_restart" is + * "true". If "cc_restart" is "false" the information in the + * "cc_restart_args" structure shall be ignored. + */ + struct callout_args cc_restart_args; + bool cc_restart; + /* + * The "cc_cancel" variable allows the currently pending + * callback to be atomically cancelled. This field is write + * protected by the "cc_lock" spinlock. + */ + bool cc_cancel; + /* + * The "cc_drain_fn" points to a function which shall be + * called with the argument stored in "cc_drain_arg" when an + * asynchronous drain is performed. This field is write + * protected by the "cc_lock" spinlock. + */ + callout_func_t *cc_drain_fn; + void *cc_drain_arg; }; /* - * There is one struct callout_cpu per cpu, holding all relevant + * There is one "struct callout_cpu" per CPU, holding all relevant * state for the callout processing thread on the individual CPU. */ struct callout_cpu { struct mtx_padalign cc_lock; struct cc_exec cc_exec_entity[2]; + struct callout *cc_exec_next_dir; struct callout *cc_callout; struct callout_list *cc_callwheel; struct callout_tailq cc_expireq; @@ -166,27 +347,7 @@ char cc_ktr_event_name[20]; }; -#define cc_exec_curr cc_exec_entity[0].cc_curr -#define cc_exec_next cc_exec_entity[0].cc_next -#define cc_exec_cancel cc_exec_entity[0].cc_cancel -#define cc_exec_waiting cc_exec_entity[0].cc_waiting -#define cc_exec_curr_dir cc_exec_entity[1].cc_curr -#define cc_exec_next_dir cc_exec_entity[1].cc_next -#define cc_exec_cancel_dir cc_exec_entity[1].cc_cancel -#define cc_exec_waiting_dir cc_exec_entity[1].cc_waiting - #ifdef SMP -#define cc_migration_func cc_exec_entity[0].ce_migration_func -#define cc_migration_arg cc_exec_entity[0].ce_migration_arg -#define cc_migration_cpu cc_exec_entity[0].ce_migration_cpu -#define cc_migration_time cc_exec_entity[0].ce_migration_time -#define cc_migration_prec cc_exec_entity[0].ce_migration_prec -#define cc_migration_func_dir cc_exec_entity[1].ce_migration_func -#define cc_migration_arg_dir cc_exec_entity[1].ce_migration_arg -#define cc_migration_cpu_dir cc_exec_entity[1].ce_migration_cpu -#define cc_migration_time_dir cc_exec_entity[1].ce_migration_time -#define cc_migration_prec_dir cc_exec_entity[1].ce_migration_prec - struct callout_cpu cc_cpu[MAXCPU]; #define CPUBLOCK MAXCPU #define CC_CPU(cpu) (&cc_cpu[(cpu)]) @@ -211,62 +372,11 @@ static MALLOC_DEFINE(M_CALLOUT, "callout", "Callout datastructures"); -/** - * Locked by cc_lock: - * cc_curr - If a callout is in progress, it is cc_curr. - * If cc_curr is non-NULL, threads waiting in - * callout_drain() will be woken up as soon as the - * relevant callout completes. - * cc_cancel - Changing to 1 with both callout_lock and cc_lock held - * guarantees that the current callout will not run. - * The softclock() function sets this to 0 before it - * drops callout_lock to acquire c_lock, and it calls - * the handler only if curr_cancelled is still 0 after - * cc_lock is successfully acquired. - * cc_waiting - If a thread is waiting in callout_drain(), then - * callout_wait is nonzero. Set only when - * cc_curr is non-NULL. - */ - /* - * Resets the execution entity tied to a specific callout cpu. + * Kernel low level callwheel initialization called from cpu0 during + * kernel startup: */ static void -cc_cce_cleanup(struct callout_cpu *cc, int direct) -{ - - cc->cc_exec_entity[direct].cc_curr = NULL; - cc->cc_exec_entity[direct].cc_next = NULL; - cc->cc_exec_entity[direct].cc_cancel = false; - cc->cc_exec_entity[direct].cc_waiting = false; -#ifdef SMP - cc->cc_exec_entity[direct].ce_migration_cpu = CPUBLOCK; - cc->cc_exec_entity[direct].ce_migration_time = 0; - cc->cc_exec_entity[direct].ce_migration_prec = 0; - cc->cc_exec_entity[direct].ce_migration_func = NULL; - cc->cc_exec_entity[direct].ce_migration_arg = NULL; -#endif -} - -/* - * Checks if migration is requested by a specific callout cpu. - */ -static int -cc_cce_migrating(struct callout_cpu *cc, int direct) -{ - -#ifdef SMP - return (cc->cc_exec_entity[direct].ce_migration_cpu != CPUBLOCK); -#else - return (0); -#endif -} - -/* - * Kernel low level callwheel initialization - * called on cpu0 during kernel startup. - */ -static void callout_callwheel_init(void *dummy) { struct callout_cpu *cc; @@ -324,8 +434,6 @@ LIST_INIT(&cc->cc_callwheel[i]); TAILQ_INIT(&cc->cc_expireq); cc->cc_firstevent = SBT_MAX; - for (i = 0; i < 2; i++) - cc_cce_cleanup(cc, i); snprintf(cc->cc_ktr_event_name, sizeof(cc->cc_ktr_event_name), "callwheel cpu %d", cpu); if (cc->cc_callout == NULL) /* Only cpu0 handles timeout(9) */ @@ -333,42 +441,12 @@ for (i = 0; i < ncallout; i++) { c = &cc->cc_callout[i]; callout_init(c, 0); - c->c_flags = CALLOUT_LOCAL_ALLOC; + c->c_flags |= CALLOUT_LOCAL_ALLOC; SLIST_INSERT_HEAD(&cc->cc_callfree, c, c_links.sle); } } -#ifdef SMP /* - * Switches the cpu tied to a specific callout. - * The function expects a locked incoming callout cpu and returns with - * locked outcoming callout cpu. - */ -static struct callout_cpu * -callout_cpu_switch(struct callout *c, struct callout_cpu *cc, int new_cpu) -{ - struct callout_cpu *new_cc; - - MPASS(c != NULL && cc != NULL); - CC_LOCK_ASSERT(cc); - - /* - * Avoid interrupts and preemption firing after the callout cpu - * is blocked in order to avoid deadlocks as the new thread - * may be willing to acquire the callout cpu lock. - */ - c->c_cpu = CPUBLOCK; - spinlock_enter(); - CC_UNLOCK(cc); - new_cc = CC_CPU(new_cpu); - CC_LOCK(new_cc); - spinlock_exit(); - c->c_cpu = new_cpu; - return (new_cc); -} -#endif - -/* * Start standard softclock thread. */ static void @@ -444,9 +522,8 @@ #ifdef CALLOUT_PROFILING int depth_dir = 0, mpcalls_dir = 0, lockcalls_dir = 0; #endif - cc = CC_SELF(); - mtx_lock_spin_flags(&cc->cc_lock, MTX_QUIET); + CC_LOCK(cc); /* Compute the buckets of the last scan and present times. */ firstb = callout_hash(cc->cc_lastscan); @@ -549,7 +626,7 @@ avg_mpcalls_dir += (mpcalls_dir * 1000 - avg_mpcalls_dir) >> 8; avg_lockcalls_dir += (lockcalls_dir * 1000 - avg_lockcalls_dir) >> 8; #endif - mtx_unlock_spin_flags(&cc->cc_lock, MTX_QUIET); + CC_UNLOCK(cc); /* * swi_sched acquires the thread lock, so we don't want to call it * with cc_lock held; incorrect locking order. @@ -562,49 +639,55 @@ callout_lock(struct callout *c) { struct callout_cpu *cc; - int cpu; - - for (;;) { - cpu = c->c_cpu; -#ifdef SMP - if (cpu == CPUBLOCK) { - while (c->c_cpu == CPUBLOCK) - cpu_spinwait(); - continue; - } -#endif - cc = CC_CPU(cpu); - CC_LOCK(cc); - if (cpu == c->c_cpu) - break; - CC_UNLOCK(cc); - } + cc = CC_CPU(c->c_cpu); + CC_LOCK(cc); return (cc); } -static void -callout_cc_add(struct callout *c, struct callout_cpu *cc, - sbintime_t sbt, sbintime_t precision, void (*func)(void *), - void *arg, int cpu, int flags) +static struct callout_cpu * +callout_cc_add_locked(struct callout *c, struct callout_cpu *cc, + struct callout_args *coa, bool can_swap_cpu) { +#ifndef NO_EVENTTIMERS + sbintime_t sbt; +#endif int bucket; CC_LOCK_ASSERT(cc); - if (sbt < cc->cc_lastscan) - sbt = cc->cc_lastscan; - c->c_arg = arg; - c->c_flags |= (CALLOUT_ACTIVE | CALLOUT_PENDING); - if (flags & C_DIRECT_EXEC) - c->c_flags |= CALLOUT_DIRECT; - c->c_flags &= ~CALLOUT_PROCESSED; - c->c_func = func; - c->c_time = sbt; - c->c_precision = precision; + + /* update flags before swapping locks, if any */ + c->c_flags &= ~(CALLOUT_PROCESSED | CALLOUT_DIRECT | CALLOUT_DEFRESTART); + if (coa->flags & C_DIRECT_EXEC) + c->c_flags |= (CALLOUT_ACTIVE | CALLOUT_PENDING | CALLOUT_DIRECT); + else + c->c_flags |= (CALLOUT_ACTIVE | CALLOUT_PENDING); + +#ifdef SMP + /* + * Check if we are changing the CPU on which the callback + * should be executed and if we have a lock protecting us: + */ + if (can_swap_cpu != false && coa->cpu != c->c_cpu && + callout_lock_owned_client(c->c_flags, c->c_lock) != 0) { + CC_UNLOCK(cc); + c->c_cpu = coa->cpu; + cc = callout_lock(c); + } +#endif + if (coa->time < cc->cc_lastscan) + coa->time = cc->cc_lastscan; + c->c_arg = coa->arg; + c->c_func = coa->func; + c->c_time = coa->time; + c->c_precision = coa->precision; + bucket = callout_get_bucket(c->c_time); CTR3(KTR_CALLOUT, "precision set for %p: %d.%08x", c, (int)(c->c_precision >> 32), (u_int)(c->c_precision & 0xffffffff)); LIST_INSERT_HEAD(&cc->cc_callwheel[bucket], c, c_links.le); + + /* Ensure we are first to be scanned, if called via a callback */ if (cc->cc_bucket == bucket) cc->cc_exec_next_dir = c; #ifndef NO_EVENTTIMERS @@ -617,9 +700,10 @@ sbt = c->c_time + c->c_precision; if (sbt < cc->cc_firstevent) { cc->cc_firstevent = sbt; - cpu_new_callout(cpu, sbt, c->c_time); + cpu_new_callout(coa->cpu, sbt, c->c_time); } #endif + return (cc); } static void @@ -626,8 +710,6 @@ callout_cc_del(struct callout *c, struct callout_cpu *cc) { - if ((c->c_flags & CALLOUT_LOCAL_ALLOC) == 0) - return; c->c_func = NULL; SLIST_INSERT_HEAD(&cc->cc_callfree, c, c_links.sle); } @@ -639,20 +721,10 @@ #endif int direct) { - struct rm_priotracker tracker; - void (*c_func)(void *); + callout_func_t *c_func; void *c_arg; - struct lock_class *class; struct lock_object *c_lock; - uintptr_t lock_status; int c_flags; -#ifdef SMP - struct callout_cpu *new_cc; - void (*new_func)(void *); - void *new_arg; - int flags, new_cpu; - sbintime_t new_prec, new_time; -#endif #if defined(DIAGNOSTIC) || defined(CALLOUT_PROFILING) sbintime_t sbt1, sbt2; struct timespec ts2; @@ -663,37 +735,43 @@ KASSERT((c->c_flags & (CALLOUT_PENDING | CALLOUT_ACTIVE)) == (CALLOUT_PENDING | CALLOUT_ACTIVE), ("softclock_call_cc: pend|act %p %x", c, c->c_flags)); - class = (c->c_lock != NULL) ? LOCK_CLASS(c->c_lock) : NULL; - lock_status = 0; - if (c->c_flags & CALLOUT_SHAREDLOCK) { - if (class == &lock_class_rm) - lock_status = (uintptr_t)&tracker; - else - lock_status = 1; - } c_lock = c->c_lock; c_func = c->c_func; c_arg = c->c_arg; c_flags = c->c_flags; - if (c->c_flags & CALLOUT_LOCAL_ALLOC) - c->c_flags = CALLOUT_LOCAL_ALLOC; - else - c->c_flags &= ~CALLOUT_PENDING; + + /* remove pending bit */ + c->c_flags &= ~CALLOUT_PENDING; + + /* reset our local state */ cc->cc_exec_entity[direct].cc_curr = c; cc->cc_exec_entity[direct].cc_cancel = false; - CC_UNLOCK(cc); + cc->cc_exec_entity[direct].cc_restart = false; + cc->cc_exec_entity[direct].cc_drain_fn = NULL; + cc->cc_exec_entity[direct].cc_drain_arg = NULL; + if (c_lock != NULL) { - class->lc_lock(c_lock, lock_status); + CC_UNLOCK(cc); + + /* unlocked region for switching locks */ + + callout_lock_client(c_flags, c_lock); + /* - * The callout may have been cancelled - * while we switched locks. + * Check if the callout may have been cancelled while + * we were switching locks. Even though the callout is + * specifying a lock, it might not be certain this + * lock is locked when starting and stopping callouts. */ + CC_LOCK(cc); if (cc->cc_exec_entity[direct].cc_cancel) { - class->lc_unlock(c_lock); - goto skip; + callout_unlock_client(c_flags, c_lock); + goto skip_cc_locked; } - /* The callout cannot be stopped now. */ + /* The callout cannot be stopped now! */ cc->cc_exec_entity[direct].cc_cancel = true; + CC_UNLOCK(cc); + if (c_lock == &Giant.lock_object) { #ifdef CALLOUT_PROFILING (*gcalls)++; @@ -708,6 +786,8 @@ c, c_func, c_arg); } } else { + CC_UNLOCK(cc); + /* unlocked region */ #ifdef CALLOUT_PROFILING (*mpcalls)++; #endif @@ -740,85 +820,40 @@ #endif KTR_STATE0(KTR_SCHED, "callout", cc->cc_ktr_event_name, "idle"); CTR1(KTR_CALLOUT, "callout %p finished", c); + + /* + * At this point the callback structure might have been freed, + * so we need to check the previously copied value of + * "c->c_flags": + */ if ((c_flags & CALLOUT_RETURNUNLOCKED) == 0) - class->lc_unlock(c_lock); -skip: + callout_unlock_client(c_flags, c_lock); + CC_LOCK(cc); + +skip_cc_locked: KASSERT(cc->cc_exec_entity[direct].cc_curr == c, ("mishandled cc_curr")); cc->cc_exec_entity[direct].cc_curr = NULL; - if (cc->cc_exec_entity[direct].cc_waiting) { + + /* Check if there is anything which needs draining */ + if (cc->cc_exec_entity[direct].cc_drain_fn != NULL) { /* - * There is someone waiting for the - * callout to complete. - * If the callout was scheduled for - * migration just cancel it. + * Unlock the CPU callout last, so that any use of + * structures belonging to the callout are complete: */ - if (cc_cce_migrating(cc, direct)) { - cc_cce_cleanup(cc, direct); - - /* - * It should be assert here that the callout is not - * destroyed but that is not easy. - */ - c->c_flags &= ~CALLOUT_DFRMIGRATION; - } - cc->cc_exec_entity[direct].cc_waiting = false; CC_UNLOCK(cc); - wakeup(&cc->cc_exec_entity[direct].cc_waiting); + /* call drain function unlocked */ + cc->cc_exec_entity[direct].cc_drain_fn( + cc->cc_exec_entity[direct].cc_drain_arg); CC_LOCK(cc); - } else if (cc_cce_migrating(cc, direct)) { - KASSERT((c_flags & CALLOUT_LOCAL_ALLOC) == 0, - ("Migrating legacy callout %p", c)); -#ifdef SMP - /* - * If the callout was scheduled for - * migration just perform it now. - */ - new_cpu = cc->cc_exec_entity[direct].ce_migration_cpu; - new_time = cc->cc_exec_entity[direct].ce_migration_time; - new_prec = cc->cc_exec_entity[direct].ce_migration_prec; - new_func = cc->cc_exec_entity[direct].ce_migration_func; - new_arg = cc->cc_exec_entity[direct].ce_migration_arg; - cc_cce_cleanup(cc, direct); - - /* - * It should be assert here that the callout is not destroyed - * but that is not easy. - * - * As first thing, handle deferred callout stops. - */ - if ((c->c_flags & CALLOUT_DFRMIGRATION) == 0) { - CTR3(KTR_CALLOUT, - "deferred cancelled %p func %p arg %p", - c, new_func, new_arg); - callout_cc_del(c, cc); - return; - } - c->c_flags &= ~CALLOUT_DFRMIGRATION; - - new_cc = callout_cpu_switch(c, cc, new_cpu); - flags = (direct) ? C_DIRECT_EXEC : 0; - callout_cc_add(c, new_cc, new_time, new_prec, new_func, - new_arg, new_cpu, flags); - CC_UNLOCK(new_cc); - CC_LOCK(cc); -#else - panic("migration should not happen"); -#endif + } else if (c_flags & CALLOUT_LOCAL_ALLOC) { + /* return callout back to freelist */ + callout_cc_del(c, cc); + } else if (cc->cc_exec_entity[direct].cc_restart) { + /* [re-]schedule callout, if any */ + cc = callout_cc_add_locked(c, cc, + &cc->cc_exec_entity[direct].cc_restart_args, false); } - /* - * If the current callout is locally allocated (from - * timeout(9)) then put it on the freelist. - * - * Note: we need to check the cached copy of c_flags because - * if it was not local, then it's not safe to deref the - * callout pointer. - */ - KASSERT((c_flags & CALLOUT_LOCAL_ALLOC) == 0 || - c->c_flags == CALLOUT_LOCAL_ALLOC, - ("corrupted callout")); - if (c_flags & CALLOUT_LOCAL_ALLOC) - callout_cc_del(c, cc); } /* @@ -899,10 +934,11 @@ /* XXX Attempt to malloc first */ panic("timeout table full"); SLIST_REMOVE_HEAD(&cc->cc_callfree, c_links.sle); - callout_reset(new, to_ticks, ftn, arg); handle.callout = new; CC_UNLOCK(cc); + callout_reset(new, to_ticks, ftn, arg); + return (handle); } @@ -910,6 +946,7 @@ untimeout(timeout_t *ftn, void *arg, struct callout_handle handle) { struct callout_cpu *cc; + bool match; /* * Check for a handle that was initialized @@ -920,9 +957,11 @@ return; cc = callout_lock(handle.callout); - if (handle.callout->c_func == ftn && handle.callout->c_arg == arg) + match = (handle.callout->c_func == ftn && handle.callout->c_arg == arg); + CC_UNLOCK(cc); + + if (match) callout_stop(handle.callout); - CC_UNLOCK(cc); } void @@ -931,6 +970,119 @@ handle->callout = NULL; } +static int +callout_restart_async(struct callout *c, struct callout_args *coa, + callout_func_t *drain_fn, void *drain_arg) +{ + struct callout_cpu *cc; + int cancelled; + int direct; + + cc = callout_lock(c); + + /* Figure out if the callout is direct or not */ + direct = ((c->c_flags & CALLOUT_DIRECT) != 0); + + /* + * Check if the callback is currently scheduled for + * completion: + */ + if (cc->cc_exec_entity[direct].cc_curr == c) { + /* + * Try to prevent the callback from running by setting + * the "cc_cancel" variable to "true". Also check if + * the callout was previously subject to a deferred + * callout restart: + */ + if (cc->cc_exec_entity[direct].cc_cancel == false || + (c->c_flags & CALLOUT_DEFRESTART) != 0) { + cc->cc_exec_entity[direct].cc_cancel = true; + cancelled = 1; + } else { + cancelled = 0; + } + + /* + * Prevent callback restart if "callout_drain_xxx()" + * is being called or we are stopping the callout or + * the callback was preallocated by us: + */ + if (cc->cc_exec_entity[direct].cc_drain_fn != NULL || + coa == NULL || (c->c_flags & CALLOUT_LOCAL_ALLOC) != 0) { + CTR4(KTR_CALLOUT, "%s %p func %p arg %p", + cancelled ? "cancelled and draining" : "draining", + c, c->c_func, c->c_arg); + + /* clear old flags, if any */ + c->c_flags &= ~(CALLOUT_ACTIVE | CALLOUT_PENDING | + CALLOUT_DEFRESTART | CALLOUT_PROCESSED); + + /* clear restart flag, if any */ + cc->cc_exec_entity[direct].cc_restart = false; + + /* set drain function, if any */ + if (drain_fn != NULL) { + cc->cc_exec_entity[direct].cc_drain_fn = drain_fn; + cc->cc_exec_entity[direct].cc_drain_arg = drain_arg; + cancelled |= 2; /* XXX define the value */ + } + } else { + CTR4(KTR_CALLOUT, "%s %p func %p arg %p", + cancelled ? "cancelled and restarting" : "restarting", + c, c->c_func, c->c_arg); + + /* get us back into the game */ + c->c_flags |= (CALLOUT_ACTIVE | CALLOUT_PENDING | + CALLOUT_DEFRESTART); + c->c_flags &= ~CALLOUT_PROCESSED; + + /* enable deferred restart */ + cc->cc_exec_entity[direct].cc_restart = true; + + /* store arguments for the deferred restart, if any */ + cc->cc_exec_entity[direct].cc_restart_args = *coa; + } + } else { + /* stop callout */ + if (c->c_flags & CALLOUT_PENDING) { + /* + * The callback has not yet been executed, and + * we simply just need to unlink it: + */ + if ((c->c_flags & CALLOUT_PROCESSED) == 0) { + if (cc->cc_exec_next_dir == c) + cc->cc_exec_next_dir = LIST_NEXT(c, c_links.le); + LIST_REMOVE(c, c_links.le); + } else { + TAILQ_REMOVE(&cc->cc_expireq, c, c_links.tqe); + } + cancelled = 1; + } else { + cancelled = 0; + } + + /* [re-]schedule callout, if any */ + if (coa != NULL) { + cc = callout_cc_add_locked(c, cc, coa, true); + } else { + /* clear old flags, if any */ + c->c_flags &= ~(CALLOUT_ACTIVE | CALLOUT_PENDING | + CALLOUT_DEFRESTART | CALLOUT_PROCESSED); + + /* return callback to pre-allocated list, if any */ + if ((c->c_flags & CALLOUT_LOCAL_ALLOC) && cancelled != 0) { + callout_cc_del(c, cc); + } + } + + CTR4(KTR_CALLOUT, "%s %p func %p arg %p", + cancelled ? "rescheduled" : "scheduled", + c, c->c_func, c->c_arg); + } + CC_UNLOCK(cc); + return (cancelled); +} + /* * New interface; clients allocate their own callout structures. * @@ -949,25 +1101,32 @@ */ int callout_reset_sbt_on(struct callout *c, sbintime_t sbt, sbintime_t precision, - void (*ftn)(void *), void *arg, int cpu, int flags) + callout_func_t *ftn, void *arg, int cpu, int flags) { - sbintime_t to_sbt, pr; - struct callout_cpu *cc; - int cancelled, direct; + struct callout_args coa; - cancelled = 0; - if (flags & C_ABSOLUTE) { - to_sbt = sbt; + /* store arguments for callout add function */ + coa.func = ftn; + coa.arg = arg; + coa.precision = precision; + coa.flags = flags; + coa.cpu = cpu; + + /* compute the rest of the arguments needed */ + if (coa.flags & C_ABSOLUTE) { + coa.time = sbt; } else { - if ((flags & C_HARDCLOCK) && (sbt < tick_sbt)) + sbintime_t pr; + + if ((coa.flags & C_HARDCLOCK) && (sbt < tick_sbt)) sbt = tick_sbt; - if ((flags & C_HARDCLOCK) || + if ((coa.flags & C_HARDCLOCK) || #ifdef NO_EVENTTIMERS sbt >= sbt_timethreshold) { - to_sbt = getsbinuptime(); + coa.time = getsbinuptime(); /* Add safety belt for the case of hz > 1000. */ - to_sbt += tc_tick_sbt - tick_sbt; + coa.time += tc_tick_sbt - tick_sbt; #else sbt >= sbt_tickthreshold) { /* @@ -977,101 +1136,29 @@ * active ones. */ #ifdef __LP64__ - to_sbt = DPCPU_GET(hardclocktime); + coa.time = DPCPU_GET(hardclocktime); #else spinlock_enter(); - to_sbt = DPCPU_GET(hardclocktime); + coa.time = DPCPU_GET(hardclocktime); spinlock_exit(); #endif #endif - if ((flags & C_HARDCLOCK) == 0) - to_sbt += tick_sbt; + if ((coa.flags & C_HARDCLOCK) == 0) + coa.time += tick_sbt; } else - to_sbt = sbinuptime(); - if (SBT_MAX - to_sbt < sbt) - to_sbt = SBT_MAX; + coa.time = sbinuptime(); + if (SBT_MAX - coa.time < sbt) + coa.time = SBT_MAX; else - to_sbt += sbt; - pr = ((C_PRELGET(flags) < 0) ? sbt >> tc_precexp : - sbt >> C_PRELGET(flags)); - if (pr > precision) - precision = pr; + coa.time += sbt; + pr = ((C_PRELGET(coa.flags) < 0) ? sbt >> tc_precexp : + sbt >> C_PRELGET(coa.flags)); + if (pr > coa.precision) + coa.precision = pr; } - /* - * Don't allow migration of pre-allocated callouts lest they - * become unbalanced. - */ - if (c->c_flags & CALLOUT_LOCAL_ALLOC) - cpu = c->c_cpu; - direct = (c->c_flags & CALLOUT_DIRECT) != 0; - KASSERT(!direct || c->c_lock == NULL, - ("%s: direct callout %p has lock", __func__, c)); - cc = callout_lock(c); - if (cc->cc_exec_entity[direct].cc_curr == c) { - /* - * We're being asked to reschedule a callout which is - * currently in progress. If there is a lock then we - * can cancel the callout if it has not really started. - */ - if (c->c_lock != NULL && !cc->cc_exec_entity[direct].cc_cancel) - cancelled = cc->cc_exec_entity[direct].cc_cancel = true; - if (cc->cc_exec_entity[direct].cc_waiting) { - /* - * Someone has called callout_drain to kill this - * callout. Don't reschedule. - */ - CTR4(KTR_CALLOUT, "%s %p func %p arg %p", - cancelled ? "cancelled" : "failed to cancel", - c, c->c_func, c->c_arg); - CC_UNLOCK(cc); - return (cancelled); - } - } - if (c->c_flags & CALLOUT_PENDING) { - if ((c->c_flags & CALLOUT_PROCESSED) == 0) { - if (cc->cc_exec_next_dir == c) - cc->cc_exec_next_dir = LIST_NEXT(c, c_links.le); - LIST_REMOVE(c, c_links.le); - } else - TAILQ_REMOVE(&cc->cc_expireq, c, c_links.tqe); - cancelled = 1; - c->c_flags &= ~(CALLOUT_ACTIVE | CALLOUT_PENDING); - } -#ifdef SMP - /* - * If the callout must migrate try to perform it immediately. - * If the callout is currently running, just defer the migration - * to a more appropriate moment. - */ - if (c->c_cpu != cpu) { - if (cc->cc_exec_entity[direct].cc_curr == c) { - cc->cc_exec_entity[direct].ce_migration_cpu = cpu; - cc->cc_exec_entity[direct].ce_migration_time - = to_sbt; - cc->cc_exec_entity[direct].ce_migration_prec - = precision; - cc->cc_exec_entity[direct].ce_migration_func = ftn; - cc->cc_exec_entity[direct].ce_migration_arg = arg; - c->c_flags |= CALLOUT_DFRMIGRATION; - CTR6(KTR_CALLOUT, - "migration of %p func %p arg %p in %d.%08x to %u deferred", - c, c->c_func, c->c_arg, (int)(to_sbt >> 32), - (u_int)(to_sbt & 0xffffffff), cpu); - CC_UNLOCK(cc); - return (cancelled); - } - cc = callout_cpu_switch(c, cc, cpu); - } -#endif - - callout_cc_add(c, cc, to_sbt, precision, ftn, arg, cpu, flags); - CTR6(KTR_CALLOUT, "%sscheduled %p func %p arg %p in %d.%08x", - cancelled ? "re" : "", c, c->c_func, c->c_arg, (int)(to_sbt >> 32), - (u_int)(to_sbt & 0xffffffff)); - CC_UNLOCK(cc); - - return (cancelled); + /* get callback started, if any */ + return (callout_restart_async(c, &coa, NULL, NULL)); } /* @@ -1090,189 +1177,79 @@ } int -_callout_stop_safe(struct callout *c, int safe) +callout_stop(struct callout *c) { - struct callout_cpu *cc, *old_cc; - struct lock_class *class; - int direct, sq_locked, use_lock; + /* get callback stopped, if any */ + return (callout_restart_async(c, NULL, NULL, NULL)); +} - /* - * Some old subsystems don't hold Giant while running a callout_stop(), - * so just discard this check for the moment. - */ - if (!safe && c->c_lock != NULL) { - if (c->c_lock == &Giant.lock_object) - use_lock = mtx_owned(&Giant); - else { - use_lock = 1; - class = LOCK_CLASS(c->c_lock); - class->lc_assert(c->c_lock, LA_XLOCKED); - } - } else - use_lock = 0; - direct = (c->c_flags & CALLOUT_DIRECT) != 0; - sq_locked = 0; - old_cc = NULL; -again: - cc = callout_lock(c); +static void +callout_drain_function(void *arg) +{ + wakeup(arg); +} - /* - * If the callout was migrating while the callout cpu lock was - * dropped, just drop the sleepqueue lock and check the states - * again. - */ - if (sq_locked != 0 && cc != old_cc) { -#ifdef SMP - CC_UNLOCK(cc); - sleepq_release(&old_cc->cc_exec_entity[direct].cc_waiting); - sq_locked = 0; - old_cc = NULL; - goto again; -#else - panic("migration should not happen"); -#endif - } +int +callout_drain_async(struct callout *c, callout_func_t *fn, void *arg) +{ + /* get callback stopped, if any */ + return (callout_restart_async(c, NULL, fn, arg) & 2); +} - /* - * If the callout isn't pending, it's not on the queue, so - * don't attempt to remove it from the queue. We can try to - * stop it by other means however. - */ - if (!(c->c_flags & CALLOUT_PENDING)) { - c->c_flags &= ~CALLOUT_ACTIVE; +int +callout_drain(struct callout *c) +{ + int cancelled; + WITNESS_WARN(WARN_GIANTOK | WARN_SLEEPOK, NULL, + "Draining callout"); + + callout_lock_client(c->c_flags, c->c_lock); + + /* at this point the "c->c_cpu" field is not changing */ + + cancelled = callout_drain_async(c, &callout_drain_function, c); + + if (cancelled != 0) { + struct callout_cpu *cc; + int direct; + + CTR3(KTR_CALLOUT, "need to drain %p func %p arg %p", + c, c->c_func, c->c_arg); + + cc = callout_lock(c); + direct = ((c->c_flags & CALLOUT_DIRECT) != 0); + /* - * If it wasn't on the queue and it isn't the current - * callout, then we can't stop it, so just bail. + * We've gotten our callout CPU lock, it is safe to + * drop the initial lock: */ - if (cc->cc_exec_entity[direct].cc_curr != c) { - CTR3(KTR_CALLOUT, "failed to stop %p func %p arg %p", - c, c->c_func, c->c_arg); - CC_UNLOCK(cc); - if (sq_locked) - sleepq_release( - &cc->cc_exec_entity[direct].cc_waiting); - return (0); - } + callout_unlock_client(c->c_flags, c->c_lock); - if (safe) { - /* - * The current callout is running (or just - * about to run) and blocking is allowed, so - * just wait for the current invocation to - * finish. - */ - while (cc->cc_exec_entity[direct].cc_curr == c) { - /* - * Use direct calls to sleepqueue interface - * instead of cv/msleep in order to avoid - * a LOR between cc_lock and sleepqueue - * chain spinlocks. This piece of code - * emulates a msleep_spin() call actually. - * - * If we already have the sleepqueue chain - * locked, then we can safely block. If we - * don't already have it locked, however, - * we have to drop the cc_lock to lock - * it. This opens several races, so we - * restart at the beginning once we have - * both locks. If nothing has changed, then - * we will end up back here with sq_locked - * set. - */ - if (!sq_locked) { - CC_UNLOCK(cc); - sleepq_lock( - &cc->cc_exec_entity[direct].cc_waiting); - sq_locked = 1; - old_cc = cc; - goto again; - } + /* Wait for drain to complete */ - /* - * Migration could be cancelled here, but - * as long as it is still not sure when it - * will be packed up, just let softclock() - * take care of it. - */ - cc->cc_exec_entity[direct].cc_waiting = true; - DROP_GIANT(); - CC_UNLOCK(cc); - sleepq_add( - &cc->cc_exec_entity[direct].cc_waiting, - &cc->cc_lock.lock_object, "codrain", - SLEEPQ_SLEEP, 0); - sleepq_wait( - &cc->cc_exec_entity[direct].cc_waiting, - 0); - sq_locked = 0; - old_cc = NULL; + while (cc->cc_exec_entity[direct].cc_curr == c) + msleep_spin(c, (struct mtx *)&cc->cc_lock, "codrain", 0); - /* Reacquire locks previously released. */ - PICKUP_GIANT(); - CC_LOCK(cc); - } - } else if (use_lock && - !cc->cc_exec_entity[direct].cc_cancel) { - /* - * The current callout is waiting for its - * lock which we hold. Cancel the callout - * and return. After our caller drops the - * lock, the callout will be skipped in - * softclock(). - */ - cc->cc_exec_entity[direct].cc_cancel = true; - CTR3(KTR_CALLOUT, "cancelled %p func %p arg %p", - c, c->c_func, c->c_arg); - KASSERT(!cc_cce_migrating(cc, direct), - ("callout wrongly scheduled for migration")); - CC_UNLOCK(cc); - KASSERT(!sq_locked, ("sleepqueue chain locked")); - return (1); - } else if ((c->c_flags & CALLOUT_DFRMIGRATION) != 0) { - c->c_flags &= ~CALLOUT_DFRMIGRATION; - CTR3(KTR_CALLOUT, "postponing stop %p func %p arg %p", - c, c->c_func, c->c_arg); - CC_UNLOCK(cc); - return (1); - } - CTR3(KTR_CALLOUT, "failed to stop %p func %p arg %p", - c, c->c_func, c->c_arg); CC_UNLOCK(cc); - KASSERT(!sq_locked, ("sleepqueue chain still locked")); - return (0); + } else { + callout_unlock_client(c->c_flags, c->c_lock); } - if (sq_locked) - sleepq_release(&cc->cc_exec_entity[direct].cc_waiting); - c->c_flags &= ~(CALLOUT_ACTIVE | CALLOUT_PENDING); - CTR3(KTR_CALLOUT, "cancelled %p func %p arg %p", c, c->c_func, c->c_arg); - if ((c->c_flags & CALLOUT_PROCESSED) == 0) { - if (cc->cc_exec_next_dir == c) - cc->cc_exec_next_dir = LIST_NEXT(c, c_links.le); - LIST_REMOVE(c, c_links.le); - } else - TAILQ_REMOVE(&cc->cc_expireq, c, c_links.tqe); - callout_cc_del(c, cc); - CC_UNLOCK(cc); - return (1); + return (cancelled & 1); } void callout_init(struct callout *c, int mpsafe) { - bzero(c, sizeof *c); if (mpsafe) { - c->c_lock = NULL; - c->c_flags = CALLOUT_RETURNUNLOCKED; + _callout_init_lock(c, NULL, CALLOUT_RETURNUNLOCKED); } else { - c->c_lock = &Giant.lock_object; - c->c_flags = 0; + _callout_init_lock(c, &Giant.lock_object, 0); } - c->c_cpu = timeout_cpu; } void @@ -1279,15 +1256,26 @@ _callout_init_lock(struct callout *c, struct lock_object *lock, int flags) { bzero(c, sizeof *c); + KASSERT((flags & ~CALLOUT_RETURNUNLOCKED) == 0, + ("callout_init_lock: bad flags 0x%08x", flags)); + flags &= CALLOUT_RETURNUNLOCKED; + if (lock != NULL) { + struct lock_class *class = LOCK_CLASS(lock); + if (class == &lock_class_mtx_sleep) + flags |= CALLOUT_SET_LC(CALLOUT_LC_MUTEX); + else if (class == &lock_class_mtx_spin) + flags |= CALLOUT_SET_LC(CALLOUT_LC_SPIN); + else if (class == &lock_class_rm) + flags |= CALLOUT_SET_LC(CALLOUT_LC_RM); + else if (class == &lock_class_rw) + flags |= CALLOUT_SET_LC(CALLOUT_LC_RW); + else + panic("callout_init_lock: Unsupported lock class '%s'\n", class->lc_name); + } else { + flags |= CALLOUT_SET_LC(CALLOUT_LC_UNUSED_0); + } c->c_lock = lock; - KASSERT((flags & ~(CALLOUT_RETURNUNLOCKED | CALLOUT_SHAREDLOCK)) == 0, - ("callout_init_lock: bad flags %d", flags)); - KASSERT(lock != NULL || (flags & CALLOUT_RETURNUNLOCKED) == 0, - ("callout_init_lock: CALLOUT_RETURNUNLOCKED with no lock")); - KASSERT(lock == NULL || !(LOCK_CLASS(lock)->lc_flags & - (LC_SPINLOCK | LC_SLEEPABLE)), ("%s: invalid lock class", - __func__)); - c->c_flags = flags & (CALLOUT_RETURNUNLOCKED | CALLOUT_SHAREDLOCK); + c->c_flags = flags; c->c_cpu = timeout_cpu; } Index: sys/kern/subr_sleepqueue.c =================================================================== --- sys/kern/subr_sleepqueue.c (revision 276531) +++ sys/kern/subr_sleepqueue.c (working copy) @@ -152,7 +152,8 @@ */ static int sleepq_catch_signals(void *wchan, int pri); static int sleepq_check_signals(void); -static int sleepq_check_timeout(void); +static int sleepq_check_timeout(struct thread *); +static void sleepq_stop_timeout(struct thread *); #ifdef INVARIANTS static void sleepq_dtor(void *mem, int size, void *arg); #endif @@ -373,17 +374,14 @@ sleepq_set_timeout_sbt(void *wchan, sbintime_t sbt, sbintime_t pr, int flags) { - struct sleepqueue_chain *sc; struct thread *td; td = curthread; - sc = SC_LOOKUP(wchan); - mtx_assert(&sc->sc_lock, MA_OWNED); - MPASS(TD_ON_SLEEPQ(td)); - MPASS(td->td_sleepqueue == NULL); - MPASS(wchan != NULL); + + mtx_lock_spin(&td->td_slpmutex); callout_reset_sbt_on(&td->td_slpcallout, sbt, pr, sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); + mtx_unlock_spin(&td->td_slpmutex); } /* @@ -559,11 +557,8 @@ * Check to see if we timed out. */ static int -sleepq_check_timeout(void) +sleepq_check_timeout(struct thread *td) { - struct thread *td; - - td = curthread; THREAD_LOCK_ASSERT(td, MA_OWNED); /* @@ -573,28 +568,21 @@ td->td_flags &= ~TDF_TIMEOUT; return (EWOULDBLOCK); } - - /* - * If TDF_TIMOFAIL is set, the timeout ran after we had - * already been woken up. - */ - if (td->td_flags & TDF_TIMOFAIL) - td->td_flags &= ~TDF_TIMOFAIL; - - /* - * If callout_stop() fails, then the timeout is running on - * another CPU, so synchronize with it to avoid having it - * accidentally wake up a subsequent sleep. - */ - else if (callout_stop(&td->td_slpcallout) == 0) { - td->td_flags |= TDF_TIMEOUT; - TD_SET_SLEEPING(td); - mi_switch(SW_INVOL | SWT_SLEEPQTIMO, NULL); - } return (0); } /* + * Atomically stop the timeout by using a mutex. + */ +static void +sleepq_stop_timeout(struct thread *td) +{ + mtx_lock_spin(&td->td_slpmutex); + callout_stop(&td->td_slpcallout); + mtx_unlock_spin(&td->td_slpmutex); +} + +/* * Check to see if we were awoken by a signal. */ static int @@ -664,9 +652,11 @@ MPASS(!(td->td_flags & TDF_SINTR)); thread_lock(td); sleepq_switch(wchan, pri); - rval = sleepq_check_timeout(); + rval = sleepq_check_timeout(td); thread_unlock(td); + sleepq_stop_timeout(td); + return (rval); } @@ -677,12 +667,18 @@ int sleepq_timedwait_sig(void *wchan, int pri) { + struct thread *td; int rcatch, rvalt, rvals; + td = curthread; + rcatch = sleepq_catch_signals(wchan, pri); - rvalt = sleepq_check_timeout(); + rvalt = sleepq_check_timeout(td); rvals = sleepq_check_signals(); - thread_unlock(curthread); + thread_unlock(td); + + sleepq_stop_timeout(td); + if (rcatch) return (rcatch); if (rvals) @@ -889,64 +885,49 @@ static void sleepq_timeout(void *arg) { - struct sleepqueue_chain *sc; - struct sleepqueue *sq; - struct thread *td; - void *wchan; - int wakeup_swapper; + struct thread *td = arg; + int wakeup_swapper = 0; - td = arg; - wakeup_swapper = 0; CTR3(KTR_PROC, "sleepq_timeout: thread %p (pid %ld, %s)", (void *)td, (long)td->td_proc->p_pid, (void *)td->td_name); - /* - * First, see if the thread is asleep and get the wait channel if - * it is. - */ + /* Handle the three cases which can happen */ + thread_lock(td); - if (TD_IS_SLEEPING(td) && TD_ON_SLEEPQ(td)) { - wchan = td->td_wchan; - sc = SC_LOOKUP(wchan); - THREAD_LOCKPTR_ASSERT(td, &sc->sc_lock); - sq = sleepq_lookup(wchan); - MPASS(sq != NULL); - td->td_flags |= TDF_TIMEOUT; - wakeup_swapper = sleepq_resume_thread(sq, td, 0); - thread_unlock(td); - if (wakeup_swapper) - kick_proc0(); - return; - } + if (TD_ON_SLEEPQ(td)) { + if (TD_IS_SLEEPING(td)) { + struct sleepqueue_chain *sc; + struct sleepqueue *sq; + void *wchan; - /* - * If the thread is on the SLEEPQ but isn't sleeping yet, it - * can either be on another CPU in between sleepq_add() and - * one of the sleepq_*wait*() routines or it can be in - * sleepq_catch_signals(). - */ - if (TD_ON_SLEEPQ(td)) { - td->td_flags |= TDF_TIMEOUT; - thread_unlock(td); - return; + /* + * Case I - thread is asleep and needs to be + * awoken: + */ + wchan = td->td_wchan; + sc = SC_LOOKUP(wchan); + THREAD_LOCKPTR_ASSERT(td, &sc->sc_lock); + sq = sleepq_lookup(wchan); + MPASS(sq != NULL); + td->td_flags |= TDF_TIMEOUT; + wakeup_swapper = sleepq_resume_thread(sq, td, 0); + } else { + /* + * Case II - cancel going to sleep by setting + * the timeout flag because the target thread + * is not asleep yet. It can be on another CPU + * in between sleepq_add() and one of the + * sleepq_*wait*() routines or it can be in + * sleepq_catch_signals(). + */ + td->td_flags |= TDF_TIMEOUT; + } + } else { + /* + * Case III - thread is already woken up by a wakeup + * call and should not timeout. Nothing to do! + */ } - - /* - * Now check for the edge cases. First, if TDF_TIMEOUT is set, - * then the other thread has already yielded to us, so clear - * the flag and resume it. If TDF_TIMEOUT is not set, then the - * we know that the other thread is not on a sleep queue, but it - * hasn't resumed execution yet. In that case, set TDF_TIMOFAIL - * to let it know that the timeout has already run and doesn't - * need to be canceled. - */ - if (td->td_flags & TDF_TIMEOUT) { - MPASS(TD_IS_SLEEPING(td)); - td->td_flags &= ~TDF_TIMEOUT; - TD_CLR_SLEEPING(td); - wakeup_swapper = setrunnable(td); - } else - td->td_flags |= TDF_TIMOFAIL; thread_unlock(td); if (wakeup_swapper) kick_proc0(); Index: sys/sys/_callout.h =================================================================== --- sys/sys/_callout.h (revision 276531) +++ sys/sys/_callout.h (working copy) @@ -46,6 +46,17 @@ SLIST_HEAD(callout_slist, callout); TAILQ_HEAD(callout_tailq, callout); +typedef void callout_func_t(void *); + +struct callout_args { + sbintime_t time; /* absolute time for the event */ + sbintime_t precision; /* delta allowed wrt opt */ + void *arg; /* function argument */ + callout_func_t *func; /* function to call */ + int flags; /* flags passed to callout_reset() */ + int cpu; /* CPU we're scheduled on */ +}; + struct callout { union { LIST_ENTRY(callout) le; @@ -52,13 +63,13 @@ SLIST_ENTRY(callout) sle; TAILQ_ENTRY(callout) tqe; } c_links; - sbintime_t c_time; /* ticks to the event */ + sbintime_t c_time; /* absolute time for the event */ sbintime_t c_precision; /* delta allowed wrt opt */ void *c_arg; /* function argument */ - void (*c_func)(void *); /* function to call */ - struct lock_object *c_lock; /* lock to handle */ + callout_func_t *c_func; /* function to call */ + struct lock_object *c_lock; /* callback lock */ int c_flags; /* state of this entry */ - volatile int c_cpu; /* CPU we're scheduled on */ + int c_cpu; /* CPU we're scheduled on */ }; #endif Index: sys/sys/callout.h =================================================================== --- sys/sys/callout.h (revision 276531) +++ sys/sys/callout.h (working copy) @@ -45,10 +45,12 @@ #define CALLOUT_PENDING 0x0004 /* callout is waiting for timeout */ #define CALLOUT_MPSAFE 0x0008 /* callout handler is mp safe */ #define CALLOUT_RETURNUNLOCKED 0x0010 /* handler returns with mtx unlocked */ -#define CALLOUT_SHAREDLOCK 0x0020 /* callout lock held in shared mode */ -#define CALLOUT_DFRMIGRATION 0x0040 /* callout in deferred migration mode */ +#define CALLOUT_UNUSED_5 0x0020 /* --available-- */ +#define CALLOUT_DEFRESTART 0x0040 /* callout restart is deferred */ #define CALLOUT_PROCESSED 0x0080 /* callout in wheel or processing list? */ #define CALLOUT_DIRECT 0x0100 /* allow exec from hw int context */ +#define CALLOUT_SET_LC(x) (((x) & 7) << 16) /* set lock class */ +#define CALLOUT_GET_LC(x) (((x) >> 16) & 7) /* get lock class */ #define C_DIRECT_EXEC 0x0001 /* direct execution of callout */ #define C_PRELBITS 7 @@ -65,7 +67,8 @@ #ifdef _KERNEL #define callout_active(c) ((c)->c_flags & CALLOUT_ACTIVE) #define callout_deactivate(c) ((c)->c_flags &= ~CALLOUT_ACTIVE) -#define callout_drain(c) _callout_stop_safe(c, 1) +int callout_drain(struct callout *); +int callout_drain_async(struct callout *, callout_func_t *, void *); void callout_init(struct callout *, int); void _callout_init_lock(struct callout *, struct lock_object *, int); #define callout_init_mtx(c, mtx, flags) \ @@ -79,7 +82,7 @@ NULL, (flags)) #define callout_pending(c) ((c)->c_flags & CALLOUT_PENDING) int callout_reset_sbt_on(struct callout *, sbintime_t, sbintime_t, - void (*)(void *), void *, int, int); + callout_func_t *, void *, int, int); #define callout_reset_sbt(c, sbt, pr, fn, arg, flags) \ callout_reset_sbt_on((c), (sbt), (pr), (fn), (arg), (c)->c_cpu, (flags)) #define callout_reset_sbt_curcpu(c, sbt, pr, fn, arg, flags) \ @@ -103,8 +106,7 @@ int callout_schedule_on(struct callout *, int, int); #define callout_schedule_curcpu(c, on_tick) \ callout_schedule_on((c), (on_tick), PCPU_GET(cpuid)) -#define callout_stop(c) _callout_stop_safe(c, 0) -int _callout_stop_safe(struct callout *, int); +int callout_stop(struct callout *); void callout_process(sbintime_t now); #endif Index: sys/sys/proc.h =================================================================== --- sys/sys/proc.h (revision 276531) +++ sys/sys/proc.h (working copy) @@ -308,6 +308,7 @@ } td_uretoff; /* (k) Syscall aux returns. */ #define td_retval td_uretoff.tdu_retval struct callout td_slpcallout; /* (h) Callout for sleep. */ + struct mtx td_slpmutex; /* (h) Mutex for sleep callout */ struct trapframe *td_frame; /* (k) */ struct vm_object *td_kstack_obj;/* (a) Kstack object. */ vm_offset_t td_kstack; /* (a) Kernel VA of kstack. */ @@ -364,7 +365,7 @@ #define TDF_ALLPROCSUSP 0x00000200 /* suspended by SINGLE_ALLPROC */ #define TDF_BOUNDARY 0x00000400 /* Thread suspended at user boundary */ #define TDF_ASTPENDING 0x00000800 /* Thread has some asynchronous events. */ -#define TDF_TIMOFAIL 0x00001000 /* Timeout from sleep after we were awake. */ +#define TDF_UNUSED12 0x00001000 /* --available-- */ #define TDF_SBDRY 0x00002000 /* Stop only on usermode boundary. */ #define TDF_UPIBLOCKED 0x00004000 /* Thread blocked on user PI mutex. */ #define TDF_NEEDSUSPCHK 0x00008000 /* Thread may need to suspend. */ @@ -704,7 +705,7 @@ #define SWT_OWEPREEMPT 2 /* Switching due to opepreempt. */ #define SWT_TURNSTILE 3 /* Turnstile contention. */ #define SWT_SLEEPQ 4 /* Sleepq wait. */ -#define SWT_SLEEPQTIMO 5 /* Sleepq timeout wait. */ +#define SWT_UNUSED5 5 /* --available-- */ #define SWT_RELINQUISH 6 /* yield call. */ #define SWT_NEEDRESCHED 7 /* NEEDRESCHED was set. */ #define SWT_IDLE 8 /* Switching from the idle thread. */ --------------070009030809080804000507-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 17:56:41 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2A1AD7 for ; Sun, 4 Jan 2015 17:56:41 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D3353021 for ; Sun, 4 Jan 2015 17:56:41 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id y20so18448182ier.4 for ; Sun, 04 Jan 2015 09:56:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=glgRM+BUmY77EE57mc61HZZTcuG/L3xe5ErwSna3MHI=; b=S42mGHN629+Tdr17XHrFaBqQITpvRaEI7xWDmhYMvynjkHct8ohDoAojR/4cNajPx/ bR/7NEXMNKP2c0M7AS3+ZrI4Cr+UBstgtDwlHY9O7OmVlEu0/O+gaBtWJXYu8SgB0Vzb D6aPQGhLOdkighdpI/jdBQeTJnzHCo9QPjxnSsFRAr3Cd6ArIyIVl8/vRF5PdYGiC6co ioX7x+Ob1HX8e4WFrjQWdL1dwnioasDjBybYTQQiRL2v06catW2a6ZMG0Fo9HJTnspHp 3hqsnr1zfFT7NE1Kov7U4ANYesziiuqK0J08ZZwLttOSSLgImkd/Iii6ygpDAhVIBVkU M8Sg== X-Gm-Message-State: ALoCoQnWLC8p8rwr4z3kZCe8kY5VqYcQpnV4IH0Cxs4msRXiexBui1zL6/s0o3GezAGaf4iEN713 X-Received: by 10.107.170.166 with SMTP id g38mr30604447ioj.2.1420394194836; Sun, 04 Jan 2015 09:56:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.217 with HTTP; Sun, 4 Jan 2015 09:56:14 -0800 (PST) X-Originating-IP: [72.177.7.16] From: Bryan Venteicher Date: Sun, 4 Jan 2015 11:56:14 -0600 Message-ID: Subject: [CFT] Paravirtualized KVM clock To: FreeBSD-current Content-Type: multipart/mixed; boundary=001a11425fb46ce52b050bd74b4a X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 17:56:41 -0000 --001a11425fb46ce52b050bd74b4a Content-Type: text/plain; charset=UTF-8 For the last few weeks, I've been working on adding support for KVM clock in the projects/paravirt branch. Currently, a KVM VM guest will end up selecting either the HPET or ACPI as the timecounter source. Unfortunately, this is very costly since every timecounter fetch causes a VM exit. KVM clock allows the guest to use the TSC instead; it is very similar to the existing Xen timer. The performance difference between HPET/ACPI and KVMCLOCK can be dramatic: a simple disk benchmark goes from 10K IOPs to 100K IOPs. The patch is attached is attached or available at [1]. I'd appreciate any testing. Also as a part of this, I've tried to generalized a bit of our existing hypervisor guest code, with the eventual goal of being able to support more invasive PV operations. The patch series is viewable in Phabricator. https://reviews.freebsd.org/D1429 - paravirt: Generalize parts of the XEN timer code into pvclock https://reviews.freebsd.org/D1430 - paravirt: Add interface to calculate the TSC frequency from pvclock https://reviews.freebsd.org/D1431 - paravirt: Add simple hypervisor registration and detection interface https://reviews.freebsd.org/D1432 - paravirt: Add detection of bhyve using new hypervisor interface https://reviews.freebsd.org/D1433 - paravirt: Add detection of VMware using new hypervisor interface https://reviews.freebsd.org/D1434 - paravirt: Add detection of KVM using new hypervisor interface https://reviews.freebsd.org/D1435 - paravirt: Add KVM clock timecounter support My current plan is to MFC this series to 10-STABLE, and commit a self-contained KVM clock to the other stable branches. [1] - https://people.freebsd.org/~bryanv/patches/kvm_clock-1.patch --001a11425fb46ce52b050bd74b4a Content-Type: text/x-patch; charset=US-ASCII; name="kvm_clock-1.patch" Content-Disposition: attachment; filename="kvm_clock-1.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i4ipow0z0 ZGlmZiAtLWdpdCBhL3N5cy9hbWQ2NC9pbmNsdWRlL3B2Y2xvY2suaCBiL3N5cy9hbWQ2NC9pbmNs dWRlL3B2Y2xvY2suaApuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5mMDFmYWM2 Ci0tLSAvZGV2L251bGwKKysrIGIvc3lzL2FtZDY0L2luY2x1ZGUvcHZjbG9jay5oCkBAIC0wLDAg KzEsNiBAQAorLyotCisgKiBUaGlzIGZpbGUgaXMgaW4gdGhlIHB1YmxpYyBkb21haW4uCisgKi8K Ky8qICRGcmVlQlNEJCAqLworCisjaW5jbHVkZSA8eDg2L3B2Y2xvY2suaD4KZGlmZiAtLWdpdCBh L3N5cy9jb25mL2ZpbGVzLmFtZDY0IGIvc3lzL2NvbmYvZmlsZXMuYW1kNjQKaW5kZXggYmJiZTgy Ny4uN2Q4NTc0MiAxMDA2NDQKLS0tIGEvc3lzL2NvbmYvZmlsZXMuYW1kNjQKKysrIGIvc3lzL2Nv bmYvZmlsZXMuYW1kNjQKQEAgLTU1NSwxMyArNTU1LDE3IEBAIHg4Ni9pc2Evbm1pLmMJCQlzdGFu ZGFyZAogeDg2L2lzYS9vcm0uYwkJCW9wdGlvbmFsCWlzYQogeDg2L3BjaS9wY2lfYnVzLmMJCW9w dGlvbmFsCXBjaQogeDg2L3BjaS9xcGkuYwkJCW9wdGlvbmFsCXBjaQoreDg2L3g4Ni9iaHl2ZS5j CQkJc3RhbmRhcmQKIHg4Ni94ODYvYnVzZG1hX2JvdW5jZS5jCQlzdGFuZGFyZAogeDg2L3g4Ni9i dXNkbWFfbWFjaGRlcC5jCXN0YW5kYXJkCiB4ODYveDg2L2R1bXBfbWFjaGRlcC5jCQlzdGFuZGFy ZAogeDg2L3g4Ni9mZHRfbWFjaGRlcC5jCQlvcHRpb25hbAlmZHQKK3g4Ni94ODYvaHlwZXJ2aXNv ci5jCQlzdGFuZGFyZAogeDg2L3g4Ni9pZGVudGNwdS5jCQlzdGFuZGFyZAogeDg2L3g4Ni9pbnRy X21hY2hkZXAuYwkJc3RhbmRhcmQKIHg4Ni94ODYvaW9fYXBpYy5jCQlzdGFuZGFyZAoreDg2L3g4 Ni9rdm0uYwkJCXN0YW5kYXJkCit4ODYveDg2L2t2bV9jbG9jay5jCQlzdGFuZGFyZAogeDg2L3g4 Ni9sZWdhY3kuYwkJc3RhbmRhcmQKIHg4Ni94ODYvbG9jYWxfYXBpYy5jCQlzdGFuZGFyZAogeDg2 L3g4Ni9tY2EuYwkJCXN0YW5kYXJkCkBAIC01NjksOCArNTczLDEwIEBAIHg4Ni94ODYvbXB0YWJs ZS5jCQlvcHRpb25hbAltcHRhYmxlCiB4ODYveDg2L21wdGFibGVfcGNpLmMJCW9wdGlvbmFsCW1w dGFibGUgcGNpCiB4ODYveDg2L21zaS5jCQkJb3B0aW9uYWwJcGNpCiB4ODYveDg2L25leHVzLmMJ CQlzdGFuZGFyZAoreDg2L3g4Ni9wdmNsb2NrLmMJCXN0YW5kYXJkCiB4ODYveDg2L3RzYy5jCQkJ c3RhbmRhcmQKIHg4Ni94ODYvZGVsYXkuYwkJCXN0YW5kYXJkCit4ODYveDg2L3Ztd2FyZS5jCQlz dGFuZGFyZAogeDg2L3hlbi9odm0uYwkJCW9wdGlvbmFsCXhlbmh2bQogeDg2L3hlbi94ZW5faW50 ci5jCQlvcHRpb25hbAl4ZW4gfCB4ZW5odm0KIHg4Ni94ZW4vcHYuYwkJCW9wdGlvbmFsCXhlbmh2 bQpkaWZmIC0tZ2l0IGEvc3lzL2NvbmYvZmlsZXMuaTM4NiBiL3N5cy9jb25mL2ZpbGVzLmkzODYK aW5kZXggOTY4NzliOC4uY2E4M2M0YyAxMDA2NDQKLS0tIGEvc3lzL2NvbmYvZmlsZXMuaTM4Ngor KysgYi9zeXMvY29uZi9maWxlcy5pMzg2CkBAIC01NzMsMTMgKzU3MywxNyBAQCB4ODYvaXNhL25t aS5jCQkJc3RhbmRhcmQKIHg4Ni9pc2Evb3JtLmMJCQlvcHRpb25hbCBpc2EKIHg4Ni9wY2kvcGNp X2J1cy5jCQlvcHRpb25hbCBwY2kKIHg4Ni9wY2kvcXBpLmMJCQlvcHRpb25hbCBwY2kKK3g4Ni94 ODYvYmh5dmUuYwkJCXN0YW5kYXJkCiB4ODYveDg2L2J1c2RtYV9ib3VuY2UuYwkJc3RhbmRhcmQK IHg4Ni94ODYvYnVzZG1hX21hY2hkZXAuYwlzdGFuZGFyZAogeDg2L3g4Ni9kdW1wX21hY2hkZXAu YwkJc3RhbmRhcmQKIHg4Ni94ODYvZmR0X21hY2hkZXAuYwkJb3B0aW9uYWwgZmR0Cit4ODYveDg2 L2h5cGVydmlzb3IuYwkJc3RhbmRhcmQKIHg4Ni94ODYvaWRlbnRjcHUuYwkJc3RhbmRhcmQKIHg4 Ni94ODYvaW50cl9tYWNoZGVwLmMJCXN0YW5kYXJkCiB4ODYveDg2L2lvX2FwaWMuYwkJb3B0aW9u YWwgYXBpYworeDg2L3g4Ni9rdm0uYwkJCXN0YW5kYXJkCit4ODYveDg2L2t2bV9jbG9jay5jCQlz dGFuZGFyZAogeDg2L3g4Ni9sZWdhY3kuYwkJb3B0aW9uYWwgbmF0aXZlCiB4ODYveDg2L2xvY2Fs X2FwaWMuYwkJb3B0aW9uYWwgYXBpYwogeDg2L3g4Ni9tY2EuYwkJCXN0YW5kYXJkCkBAIC01ODgs NyArNTkyLDkgQEAgeDg2L3g4Ni9tcHRhYmxlX3BjaS5jCQlvcHRpb25hbCBhcGljIG5hdGl2ZSBw Y2kKIHg4Ni94ODYvbXNpLmMJCQlvcHRpb25hbCBhcGljIHBjaQogeDg2L3g4Ni9uZXh1cy5jCQkJ c3RhbmRhcmQKIHg4Ni94ODYvdHNjLmMJCQlzdGFuZGFyZAoreDg2L3g4Ni9wdmNsb2NrLmMJCXN0 YW5kYXJkCiB4ODYveDg2L2RlbGF5LmMJCQlzdGFuZGFyZAoreDg2L3g4Ni92bXdhcmUuYwkJc3Rh bmRhcmQKIHg4Ni94ZW4vaHZtLmMJCQlvcHRpb25hbCB4ZW5odm0KIHg4Ni94ZW4veGVuX2ludHIu YwkJb3B0aW9uYWwgeGVuIHwgeGVuaHZtCiB4ODYveGVuL3hlbl9hcGljLmMJCW9wdGlvbmFsIHhl bmh2bQpkaWZmIC0tZ2l0IGEvc3lzL2Rldi94ZW4vdGltZXIvdGltZXIuYyBiL3N5cy9kZXYveGVu L3RpbWVyL3RpbWVyLmMKaW5kZXggNTc0MzA3Ni4uNTNhZmYwYSAxMDA2NDQKLS0tIGEvc3lzL2Rl di94ZW4vdGltZXIvdGltZXIuYworKysgYi9zeXMvZGV2L3hlbi90aW1lci90aW1lci5jCkBAIC01 OSw2ICs1OSw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxtYWNoaW5lL2Ns b2NrLmg+CiAjaW5jbHVkZSA8bWFjaGluZS9faW50dHlwZXMuaD4KICNpbmNsdWRlIDxtYWNoaW5l L3NtcC5oPgorI2luY2x1ZGUgPG1hY2hpbmUvcHZjbG9jay5oPgogCiAjaW5jbHVkZSA8ZGV2L3hl bi90aW1lci90aW1lci5oPgogCkBAIC05NSw5ICs5Niw2IEBAIHN0cnVjdCB4ZW50aW1lcl9zb2Z0 YyB7CiAJc3RydWN0IGV2ZW50dGltZXIgZXQ7CiB9OwogCi0vKiBMYXN0IHRpbWU7IHRoaXMgZ3Vh cmFudGVlcyBhIG1vbm90b25pY2FsbHkgaW5jcmVhc2luZyBjbG9jay4gKi8KLXZvbGF0aWxlIHVp bnQ2NF90IHhlbl90aW1lcl9sYXN0X3RpbWUgPSAwOwotCiBzdGF0aWMgdm9pZAogeGVudGltZXJf aWRlbnRpZnkoZHJpdmVyX3QgKmRyaXZlciwgZGV2aWNlX3QgcGFyZW50KQogewpAQCAtMTQ4LDEy OCArMTQ2LDIwIEBAIHhlbnRpbWVyX3Byb2JlKGRldmljZV90IGRldikKIAlyZXR1cm4gKEJVU19Q Uk9CRV9OT1dJTERDQVJEKTsKIH0KIAotLyoKLSAqIFNjYWxlIGEgNjQtYml0IGRlbHRhIGJ5IHNj YWxpbmcgYW5kIG11bHRpcGx5aW5nIGJ5IGEgMzItYml0IGZyYWN0aW9uLAotICogeWllbGRpbmcg YSA2NC1iaXQgcmVzdWx0LgotICovCi1zdGF0aWMgaW5saW5lIHVpbnQ2NF90Ci1zY2FsZV9kZWx0 YSh1aW50NjRfdCBkZWx0YSwgdWludDMyX3QgbXVsX2ZyYWMsIGludCBzaGlmdCkKLXsKLQl1aW50 NjRfdCBwcm9kdWN0OwotCi0JaWYgKHNoaWZ0IDwgMCkKLQkJZGVsdGEgPj49IC1zaGlmdDsKLQll bHNlCi0JCWRlbHRhIDw8PSBzaGlmdDsKLQotI2lmIGRlZmluZWQoX19pMzg2X18pCi0JewotCQl1 aW50MzJfdCB0bXAxLCB0bXAyOwotCi0JCS8qKgotCQkgKiBGb3IgaTM4NiwgdGhlIGZvcm11bGEg bG9va3MgbGlrZToKLQkJICoKLQkJICogICBsb3dlciA9IChtdWxfZnJhYyAqIChkZWx0YSAmIFVJ TlRfTUFYKSkgPj4gMzIKLQkJICogICB1cHBlciA9IG11bF9mcmFjICogKGRlbHRhID4+IDMyKQot CQkgKiAgIHByb2R1Y3QgPSBsb3dlciArIHVwcGVyCi0JCSAqLwotCQlfX2FzbV9fICgKLQkJCSJt dWwgICU1ICAgICAgIDsgIgotCQkJIm1vdiAgJTQsJSVlYXggOyAiCi0JCQkibW92ICAlJWVkeCwl NCA7ICIKLQkJCSJtdWwgICU1ICAgICAgIDsgIgotCQkJInhvciAgJTUsJTUgICAgOyAiCi0JCQki YWRkICAlNCwlJWVheCA7ICIKLQkJCSJhZGMgICU1LCUlZWR4IDsgIgotCQkJOiAiPUEiIChwcm9k dWN0KSwgIj1yIiAodG1wMSksICI9ciIgKHRtcDIpCi0JCQk6ICJhIiAoKHVpbnQzMl90KWRlbHRh KSwgIjEiICgodWludDMyX3QpKGRlbHRhID4+IDMyKSksCi0JCQkgICIyIiAobXVsX2ZyYWMpICk7 Ci0JfQotI2VsaWYgZGVmaW5lZChfX2FtZDY0X18pCi0JewotCQl1bnNpZ25lZCBsb25nIHRtcDsK LQotCQlfX2FzbV9fICgKLQkJCSJtdWxxICVbbXVsX2ZyYWNdIDsgc2hyZCAkMzIsICVbaGldLCAl W2xvXSIKLQkJCTogW2xvXSI9YSIgKHByb2R1Y3QpLCBbaGldIj1kIiAodG1wKQotCQkJOiAiMCIg KGRlbHRhKSwgW211bF9mcmFjXSJybSIoKHVpbnQ2NF90KW11bF9mcmFjKSk7Ci0JfQotI2Vsc2UK LSNlcnJvciAieGVudGltZXI6IHVuc3VwcG9ydGVkIGFyY2hpdGVjdHVyZSIKLSNlbmRpZgotCi0J cmV0dXJuIChwcm9kdWN0KTsKLX0KLQotc3RhdGljIHVpbnQ2NF90Ci1nZXRfbnNlY19vZmZzZXQo c3RydWN0IHZjcHVfdGltZV9pbmZvICp0aW5mbykKLXsKLQotCXJldHVybiAoc2NhbGVfZGVsdGEo cmR0c2MoKSAtIHRpbmZvLT50c2NfdGltZXN0YW1wLAotCSAgICB0aW5mby0+dHNjX3RvX3N5c3Rl bV9tdWwsIHRpbmZvLT50c2Nfc2hpZnQpKTsKLX0KLQotLyoKLSAqIFJlYWQgdGhlIGN1cnJlbnQg aHlwZXJ2aXNvciBzeXN0ZW0gdXB0aW1lIHZhbHVlIGZyb20gWGVuLgotICogU2VlIDx4ZW4vaW50 ZXJmYWNlL3hlbi5oPiBmb3IgYSBkZXNjcmlwdGlvbiBvZiBob3cgdGhpcyB3b3Jrcy4KLSAqLwot c3RhdGljIHVpbnQzMl90Ci14ZW5fZmV0Y2hfdmNwdV90aW5mbyhzdHJ1Y3QgdmNwdV90aW1lX2lu Zm8gKmRzdCwgc3RydWN0IHZjcHVfdGltZV9pbmZvICpzcmMpCi17Ci0KLQlkbyB7Ci0JCWRzdC0+ dmVyc2lvbiA9IHNyYy0+dmVyc2lvbjsKLQkJcm1iKCk7Ci0JCWRzdC0+dHNjX3RpbWVzdGFtcCA9 IHNyYy0+dHNjX3RpbWVzdGFtcDsKLQkJZHN0LT5zeXN0ZW1fdGltZSA9IHNyYy0+c3lzdGVtX3Rp bWU7Ci0JCWRzdC0+dHNjX3RvX3N5c3RlbV9tdWwgPSBzcmMtPnRzY190b19zeXN0ZW1fbXVsOwot CQlkc3QtPnRzY19zaGlmdCA9IHNyYy0+dHNjX3NoaWZ0OwotCQlybWIoKTsKLQl9IHdoaWxlICgo c3JjLT52ZXJzaW9uICYgMSkgfCAoZHN0LT52ZXJzaW9uIF4gc3JjLT52ZXJzaW9uKSk7Ci0KLQly ZXR1cm4gKGRzdC0+dmVyc2lvbik7Ci19Ci0KIC8qKgogICogXGJyaWVmIEdldCB0aGUgY3VycmVu dCB0aW1lLCBpbiBuYW5vc2Vjb25kcywgc2luY2UgdGhlIGh5cGVydmlzb3IgYm9vdGVkLgogICoK ICAqIFxwYXJhbSB2Y3B1CQl2Y3B1X2luZm8gc3RydWN0dXJlIHRvIGZldGNoIHRoZSB0aW1lIGZy b20uCiAgKgotICogXG5vdGUgVGhpcyBmdW5jdGlvbiByZXR1cm5zIHRoZSBjdXJyZW50IENQVSdz IGlkZWEgb2YgdGhpcyB2YWx1ZSwgdW5sZXNzCi0gKiAgICAgICBpdCBoYXBwZW5zIHRvIGJlIGxl c3MgdGhhbiBhbm90aGVyIENQVSdzIHByZXZpb3VzbHkgZGV0ZXJtaW5lZCB2YWx1ZS4KICAqLwog c3RhdGljIHVpbnQ2NF90CiB4ZW5fZmV0Y2hfdmNwdV90aW1lKHN0cnVjdCB2Y3B1X2luZm8gKnZj cHUpCiB7Ci0Jc3RydWN0IHZjcHVfdGltZV9pbmZvIGRzdDsKLQlzdHJ1Y3QgdmNwdV90aW1lX2lu Zm8gKnNyYzsKLQl1aW50MzJfdCBwcmVfdmVyc2lvbjsKLQl1aW50NjRfdCBub3c7Ci0Jdm9sYXRp bGUgdWludDY0X3QgbGFzdDsKLQotCXNyYyA9ICZ2Y3B1LT50aW1lOwotCi0JZG8gewotCQlwcmVf dmVyc2lvbiA9IHhlbl9mZXRjaF92Y3B1X3RpbmZvKCZkc3QsIHNyYyk7Ci0JCWJhcnJpZXIoKTsK LQkJbm93ID0gZHN0LnN5c3RlbV90aW1lICsgZ2V0X25zZWNfb2Zmc2V0KCZkc3QpOwotCQliYXJy aWVyKCk7Ci0JfSB3aGlsZSAocHJlX3ZlcnNpb24gIT0gc3JjLT52ZXJzaW9uKTsKKwlzdHJ1Y3Qg cHZjbG9ja192Y3B1X3RpbWVfaW5mbyAqdGltZTsKIAotCS8qCi0JICogRW5mb3JjZSBhIG1vbm90 b25pY2FsbHkgaW5jcmVhc2luZyBjbG9jayB0aW1lIGFjcm9zcyBhbGwKLQkgKiBWQ1BVcy4gIElm IG91ciB0aW1lIGlzIHRvbyBvbGQsIHVzZSB0aGUgbGFzdCB0aW1lIGFuZCByZXR1cm4uCi0JICog T3RoZXJ3aXNlLCB0cnkgdG8gdXBkYXRlIHRoZSBsYXN0IHRpbWUuCi0JICovCi0JZG8gewotCQls YXN0ID0geGVuX3RpbWVyX2xhc3RfdGltZTsKLQkJaWYgKGxhc3QgPiBub3cpIHsKLQkJCW5vdyA9 IGxhc3Q7Ci0JCQlicmVhazsKLQkJfQotCX0gd2hpbGUgKCFhdG9taWNfY21wc2V0XzY0KCZ4ZW5f dGltZXJfbGFzdF90aW1lLCBsYXN0LCBub3cpKTsKKwl0aW1lID0gKHN0cnVjdCBwdmNsb2NrX3Zj cHVfdGltZV9pbmZvICopICZ2Y3B1LT50aW1lOwogCi0JcmV0dXJuIChub3cpOworCXJldHVybiAo cHZjbG9ja19nZXRfdGltZWNvdW50KHRpbWUpKTsKIH0KIAogc3RhdGljIHVpbnQzMl90CkBAIC0z MDIsMTUgKzE5MiwxMSBAQCBzdGF0aWMgdm9pZAogeGVuX2ZldGNoX3dhbGxjbG9jayhzdHJ1Y3Qg dGltZXNwZWMgKnRzKQogewogCXNoYXJlZF9pbmZvX3QgKnNyYyA9IEhZUEVSVklTT1Jfc2hhcmVk X2luZm87Ci0JdWludDMyX3QgdmVyc2lvbiA9IDA7CisJc3RydWN0IHB2Y2xvY2tfd2FsbF9jbG9j ayAqd2M7CiAKLQlkbyB7Ci0JCXZlcnNpb24gPSBzcmMtPndjX3ZlcnNpb247Ci0JCXJtYigpOwot CQl0cy0+dHZfc2VjID0gc3JjLT53Y19zZWM7Ci0JCXRzLT50dl9uc2VjID0gc3JjLT53Y19uc2Vj OwotCQlybWIoKTsKLQl9IHdoaWxlICgoc3JjLT53Y192ZXJzaW9uICYgMSkgfCAodmVyc2lvbiBe IHNyYy0+d2NfdmVyc2lvbikpOworCXdjID0gKHN0cnVjdCBwdmNsb2NrX3dhbGxfY2xvY2sgKikg JnNyYy0+d2NfdmVyc2lvbjsKKworCXB2Y2xvY2tfZ2V0X3dhbGxjbG9jayh3YywgdHMpOwogfQog CiBzdGF0aWMgdm9pZApAQCAtNTc0LDcgKzQ2MCw3IEBAIHhlbnRpbWVyX3Jlc3VtZShkZXZpY2Vf dCBkZXYpCiAJfQogCiAJLyogUmVzZXQgdGhlIGxhc3QgdXB0aW1lIHZhbHVlICovCi0JeGVuX3Rp bWVyX2xhc3RfdGltZSA9IDA7CisJcHZjbG9ja19yZXN1bWUoKTsKIAogCS8qIFJlc2V0IHRoZSBS VEMgY2xvY2sgKi8KIAlpbml0dG9kcih0aW1lX3NlY29uZCk7CmRpZmYgLS1naXQgYS9zeXMvaTM4 Ni9pbmNsdWRlL3B2Y2xvY2suaCBiL3N5cy9pMzg2L2luY2x1ZGUvcHZjbG9jay5oCm5ldyBmaWxl IG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLmYwMWZhYzYKLS0tIC9kZXYvbnVsbAorKysgYi9z eXMvaTM4Ni9pbmNsdWRlL3B2Y2xvY2suaApAQCAtMCwwICsxLDYgQEAKKy8qLQorICogVGhpcyBm aWxlIGlzIGluIHRoZSBwdWJsaWMgZG9tYWluLgorICovCisvKiAkRnJlZUJTRCQgKi8KKworI2lu Y2x1ZGUgPHg4Ni9wdmNsb2NrLmg+CmRpZmYgLS1naXQgYS9zeXMva2Vybi9zdWJyX3BhcmFtLmMg Yi9zeXMva2Vybi9zdWJyX3BhcmFtLmMKaW5kZXggOTVmMzI1MC4uNTMzMjA1NSAxMDA2NDQKLS0t IGEvc3lzL2tlcm4vc3Vicl9wYXJhbS5jCisrKyBiL3N5cy9rZXJuL3N1YnJfcGFyYW0uYwpAQCAt MTU5LDYgKzE1OSw4IEBAIHN0YXRpYyBjb25zdCBjaGFyICpjb25zdCB2bV9ndWVzdF9zeXNjdGxf bmFtZXNbXSA9IHsKIAkieGVuIiwKIAkiaHYiLAogCSJ2bXdhcmUiLAorCSJiaHl2ZSIsCisJImt2 bSIsCiAJTlVMTAogfTsKIENUQVNTRVJUKG5pdGVtcyh2bV9ndWVzdF9zeXNjdGxfbmFtZXMpIC0g MSA9PSBWTV9MQVNUKTsKZGlmZiAtLWdpdCBhL3N5cy9zeXMvc3lzdG0uaCBiL3N5cy9zeXMvc3lz dG0uaAppbmRleCBkMzgzM2QwLi41MGE0OWQyIDEwMDY0NAotLS0gYS9zeXMvc3lzL3N5c3RtLmgK KysrIGIvc3lzL3N5cy9zeXN0bS5oCkBAIC03Myw3ICs3Myw3IEBAIGV4dGVybiBpbnQgdm1fZ3Vl c3Q7CQkvKiBSdW5uaW5nIGFzIHZpcnR1YWwgbWFjaGluZSBndWVzdD8gKi8KICAqIEtlZXAgaW4g c3luYyB3aXRoIHZtX2d1ZXN0X3N5c2N0bF9uYW1lc1tdLgogICovCiBlbnVtIFZNX0dVRVNUIHsg Vk1fR1VFU1RfTk8gPSAwLCBWTV9HVUVTVF9WTSwgVk1fR1VFU1RfWEVOLCBWTV9HVUVTVF9IViwK LQkJVk1fR1VFU1RfVk1XQVJFLCBWTV9MQVNUIH07CisJCVZNX0dVRVNUX1ZNV0FSRSwgVk1fR1VF U1RfQkhZVkUsIFZNX0dVRVNUX0tWTSwgVk1fTEFTVCB9OwogCiAjaWYgZGVmaW5lZChXSVRORVNT KSB8fCBkZWZpbmVkKElOVkFSSUFOVFMpCiB2b2lkCWthc3NlcnRfcGFuaWMoY29uc3QgY2hhciAq Zm10LCAuLi4pICBfX3ByaW50Zmxpa2UoMSwgMik7CmRpZmYgLS1naXQgYS9zeXMveDg2L2luY2x1 ZGUvaHlwZXJ2aXNvci5oIGIvc3lzL3g4Ni9pbmNsdWRlL2h5cGVydmlzb3IuaApuZXcgZmlsZSBt b2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5kNWQzMGViCi0tLSAvZGV2L251bGwKKysrIGIvc3lz L3g4Ni9pbmNsdWRlL2h5cGVydmlzb3IuaApAQCAtMCwwICsxLDU2IEBACisvKi0KKyAqIENvcHly aWdodCAoYykgMjAxNCBCcnlhbiBWZW50ZWljaGVyIDxicnlhbnZARnJlZUJTRC5vcmc+CisgKiBB bGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291 cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBh cmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBh cmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWlu IHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlv bnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBp biBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBu b3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWlt ZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJv dmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJP VklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKKyAqIEFO WSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlU RUQgVE8sIFRIRQorICogSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQg RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKKyAqIEFSRSBESVNDTEFJTUVELiAgSU4g Tk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisgKiBG T1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwg T1IgQ09OU0VRVUVOVElBTAorICogREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQg VE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMKKyAqIE9SIFNFUlZJQ0VTOyBMT1NT IE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorICog SE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElO IENPTlRSQUNULCBTVFJJQ1QKKyAqIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJ R0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKKyAqIE9VVCBPRiBUSEUgVVNF IE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YK KyAqIFNVQ0ggREFNQUdFLgorICoKKyAqICRGcmVlQlNEJAorICovCisKKyNpZm5kZWYgX1g4Nl9I WVBFUlZJU09SX0hfCisjZGVmaW5lIF9YODZfSFlQRVJWSVNPUl9IXworCisjaW5jbHVkZSA8c3lz L3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL2tlcm5lbC5oPgorCit0eXBlZGVmIHZvaWQgaHlwZXJ2 aXNvcl9pbml0X2Z1bmNfdCh2b2lkKTsKKworLyoKKyAqIFRoZSBndWVzdCBoeXBlcnZpc29yIHN1 cHBvcnQgbWF5IHByb3ZpZGUgcGFyYXZpcnR1YWxpemVkIG9yIGhhdmUgc3BlY2lhbAorICogcmVx dWlyZW1lbnRzIGZvciB2YXJpb3VzIG9wZXJhdGlvbnMuIFRoZSBjYWxsYmFjayBmdW5jdGlvbnMg YXJlIHByb3ZpZGVkCisgKiB3aGVuIGEgaHlwZXJ2aXNvciBpcyBkZXRlY3RlZCBhbmQgcmVnaXN0 ZXJlZC4KKyAqLworc3RydWN0IGh5cGVydmlzb3Jfb3BzIHsKK307CisKK3ZvaWQJaHlwZXJ2aXNv cl9zeXNpbml0KHZvaWQgKmZ1bmMpOwordm9pZAloeXBlcnZpc29yX3JlZ2lzdGVyKGNvbnN0IGNo YXIgKnZlbmRvciwgZW51bSBWTV9HVUVTVCBndWVzdCwKKwkgICAgc3RydWN0IGh5cGVydmlzb3Jf b3BzICpvcHMpOworaW50CWh5cGVydmlzb3JfY3B1aWRfYmFzZShjb25zdCBjaGFyICpzaWduYXR1 cmUsIGludCBsZWF2ZXMsCisJICAgIHVpbnQzMl90ICpiYXNlLCB1aW50MzJfdCAqaGlnaCk7Cit2 b2lkCWh5cGVydmlzb3JfcHJpbnRfaW5mbyh2b2lkKTsKKworI2RlZmluZSBIWVBFUlZJU09SX1NZ U0lOSVQobmFtZSwgZnVuYykJCQkJXAorCVNZU0lOSVQobmFtZSAjIyBfaHlwZXJ2aXNvcl9zeXNp bml0LCBTSV9TVUJfSFlQRVJWSVNPUiwJXAorCSAgICBTSV9PUkRFUl9GSVJTVCwgaHlwZXJ2aXNv cl9zeXNpbml0LCBmdW5jKQorCisjZW5kaWYgLyogIV9YODZfSFlQRVJWSVNPUl9IXyAqLwpkaWZm IC0tZ2l0IGEvc3lzL3g4Ni9pbmNsdWRlL2t2bS5oIGIvc3lzL3g4Ni9pbmNsdWRlL2t2bS5oCm5l dyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLmI1MzkwMzgKLS0tIC9kZXYvbnVsbAor KysgYi9zeXMveDg2L2luY2x1ZGUva3ZtLmgKQEAgLTAsMCArMSw0OSBAQAorLyotCisgKiBDb3B5 cmlnaHQgKGMpIDIwMTQgQnJ5YW4gVmVudGVpY2hlciA8YnJ5YW52QEZyZWVCU0Qub3JnPgorICog QWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNv dXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwg YXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICog YXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFp biB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRp b25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMg aW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAg bm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFp bWVyIGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHBy b3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBS T1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBB TlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1J VEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5E IEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElO IE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICog Rk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlks IE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVE IFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9T UyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAq IEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJ TiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdM SUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVT RSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9G CisgKiBTVUNIIERBTUFHRS4KKyAqCisgKiAkRnJlZUJTRCQKKyAqLworCisjaWZuZGVmIF9YODZf S1ZNX0hfCisjZGVmaW5lIF9YODZfS1ZNX0hfCisKKyNkZWZpbmUgS1ZNX0NQVUlEX0ZFQVRVUkVT X0xFQUYJCTB4NDAwMDAwMDEKKworI2RlZmluZSBLVk1fRkVBVFVSRV9DTE9DS1NPVVJDRQkJMHgw MDAwMDAwMQorI2RlZmluZSBLVk1fRkVBVFVSRV9DTE9DS1NPVVJDRTIJMHgwMDAwMDAwOAorCisv KiBEZXByZWNhdGVkOiBmb3IgdGhlIENMT0NLU09VUkNFIGZlYXR1cmUuICovCisjZGVmaW5lIEtW TV9NU1JfV0FMTF9DTE9DSwkJMHgxMQorI2RlZmluZSBLVk1fTVNSX1NZU1RFTV9USU1FCQkweDEy CisKKyNkZWZpbmUgS1ZNX01TUl9XQUxMX0NMT0NLX05FVwkJMHg0YjU2NGQwMAorI2RlZmluZSBL Vk1fTVNSX1NZU1RFTV9USU1FX05FVwkJMHg0YjU2NGQwMQorCitpbnQJCWt2bV9wYXJhdmlydF9z dXBwb3J0ZWQodm9pZCk7Cit1aW50MzJfdAlrdm1fZ2V0X2ZlYXR1cmVzKHZvaWQpOworCit1aW50 NjRfdAlrdm1fY2xvY2tfdHNjX2ZyZXEodm9pZCk7CisKKyNlbmRpZiAvKiAhX1g4Nl9LVk1fSF8g Ki8KZGlmZiAtLWdpdCBhL3N5cy94ODYvaW5jbHVkZS9wdmNsb2NrLmggYi9zeXMveDg2L2luY2x1 ZGUvcHZjbG9jay5oCm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLjI1YWJhOTkK LS0tIC9kZXYvbnVsbAorKysgYi9zeXMveDg2L2luY2x1ZGUvcHZjbG9jay5oCkBAIC0wLDAgKzEs NTggQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDE0LCBCcnlhbiBWZW50ZWljaGVyIDxicnlh bnZARnJlZUJTRC5vcmc+CisgKiBBbGwgcmlnaHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJp YnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFuZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91 dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVybWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxv d2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNv dXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwg dGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAq IDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5hcnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJv dmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0 aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4gdGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9v ciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQgd2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAq IFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQgQlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JT IGBgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5D TFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1QTElFRCBXQVJSQU5USUVTIE9G IE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKKyAq IEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklC VVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUws IFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorICogREFNQUdFUyAoSU5DTFVE SU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMK KyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5F U1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZFUiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0Yg TElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyAqIExJQUJJTElUWSwgT1Ig VE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBX QVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBP RiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICoKKyAqICRGcmVlQlNEJAor ICovCisKKyNpZm5kZWYgWDg2X1BWQ0xPQ0sKKyNkZWZpbmUgWDg2X1BWQ0xPQ0sKKworc3RydWN0 IHB2Y2xvY2tfdmNwdV90aW1lX2luZm8geworCXVpbnQzMl90CXZlcnNpb247CisJdWludDMyX3QJ cGFkMDsKKwl1aW50NjRfdAl0c2NfdGltZXN0YW1wOworCXVpbnQ2NF90CXN5c3RlbV90aW1lOwor CXVpbnQzMl90CXRzY190b19zeXN0ZW1fbXVsOworCWludDhfdAkJdHNjX3NoaWZ0OworCXVpbnQ4 X3QJCWZsYWdzOworCXVpbnQ4X3QJCXBhZFsyXTsKK30gX19wYWNrZWQ7CisKKyNkZWZpbmUgUFZD TE9DS19GTEFHX1RTQ19TVEFCTEUJCTB4MDEKKyNkZWZpbmUgUFZDTE9DS19GTEFHX0dVRVNUX1BB U1VFRAkweDAyCisKK3N0cnVjdCBwdmNsb2NrX3dhbGxfY2xvY2sgeworCXVpbnQzMl90CXZlcnNp b247CisJdWludDMyX3QJc2VjOworCXVpbnQzMl90CW5zZWM7Cit9IF9fcGFja2VkOworCit2b2lk CQlwdmNsb2NrX3Jlc3VtZSh2b2lkKTsKK3VpbnQ2NF90CXB2Y2xvY2tfdHNjX2ZyZXEoc3RydWN0 IHB2Y2xvY2tfdmNwdV90aW1lX2luZm8gKnRpKTsKK3VpbnQ2NF90CXB2Y2xvY2tfZ2V0X3RpbWVj b3VudChzdHJ1Y3QgcHZjbG9ja192Y3B1X3RpbWVfaW5mbyAqdGkpOwordm9pZAkJcHZjbG9ja19n ZXRfd2FsbGNsb2NrKHN0cnVjdCBwdmNsb2NrX3dhbGxfY2xvY2sgKndjLAorCQkgICAgc3RydWN0 IHRpbWVzcGVjICp0cyk7CisKKyNlbmRpZgpkaWZmIC0tZ2l0IGEvc3lzL3g4Ni9pbmNsdWRlL3Zt d2FyZS5oIGIvc3lzL3g4Ni9pbmNsdWRlL3Ztd2FyZS5oCmluZGV4IGM3MmY0OGQuLjg5NjE2YzUg MTAwNjQ0Ci0tLSBhL3N5cy94ODYvaW5jbHVkZS92bXdhcmUuaAorKysgYi9zeXMveDg2L2luY2x1 ZGUvdm13YXJlLmgKQEAgLTQ0LDQgKzQ0LDYgQEAgdm13YXJlX2h2Y2FsbCh1X2ludCBjbWQsIHVf aW50ICpwKQogCTogIm1lbW9yeSIpOwogfQogCit1aW50NjRfdAl2bXdhcmVfdHNjX2ZyZXEodm9p ZCk7CisKICNlbmRpZiAvKiAhX1g4Nl9WTVdBUkVfSF8gKi8KZGlmZiAtLWdpdCBhL3N5cy94ODYv eDg2L2JoeXZlLmMgYi9zeXMveDg2L3g4Ni9iaHl2ZS5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0Cmlu ZGV4IDAwMDAwMDAuLmQyMWU4MDgKLS0tIC9kZXYvbnVsbAorKysgYi9zeXMveDg2L3g4Ni9iaHl2 ZS5jCkBAIC0wLDAgKzEsNTggQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDE0IEJyeWFuIFZl bnRlaWNoZXIgPGJyeWFudkBGcmVlQlNELm9yZz4KKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQuCisg KgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jtcywg d2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlkZWQg dGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRpc3Ry aWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdodAor ICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBk aXNjbGFpbWVyLgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3QgcmVw cm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNv bmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRvY3Vt ZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0cmli dXRpb24uCisgKgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9SIEFO RCBDT05UUklCVVRPUlMgYGBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElFRCBX QVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBMSUVE IFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJQ1VM QVIgUFVSUE9TRQorICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUgQVVU SE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJUkVD VCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisgKiBE QU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0YgU1VC U1RJVFVURSBHT09EUworICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQUk9G SVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQgT04g QU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAorICog TElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0UpIEFS SVNJTkcgSU4gQU5ZIFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwgRVZF TiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisgKi8K KworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRGcmVlQlNEJCIpOworCisjaW5j bHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisKKyNpbmNsdWRlIDx4 ODYvaHlwZXJ2aXNvci5oPgorCitzdGF0aWMgdWludDMyX3QgYmh5dmVfY3B1aWRfYmFzZSA9IC0x Oworc3RhdGljIHVpbnQzMl90IGJoeXZlX2NwdWlkX2hpZ2ggPSAtMTsKKworc3RhdGljIGludAor Ymh5dmVfY3B1aWRfaWRlbnRpZnkodm9pZCkKK3sKKworCWlmIChiaHl2ZV9jcHVpZF9iYXNlID09 IC0xKSB7CisJCWh5cGVydmlzb3JfY3B1aWRfYmFzZSgiYmh5dmUgYmh5dmUiLCAwLCAmYmh5dmVf Y3B1aWRfYmFzZSwKKwkJICAgICZiaHl2ZV9jcHVpZF9oaWdoKTsKKwl9CisKKwlyZXR1cm4gKGJo eXZlX2NwdWlkX2Jhc2UgPiAwKTsKK30KKworc3RhdGljIHZvaWQKK2JoeXZlX2luaXQodm9pZCkK K3sKKworCWlmIChiaHl2ZV9jcHVpZF9pZGVudGlmeSgpICE9IDApCisJCWh5cGVydmlzb3JfcmVn aXN0ZXIoImJoeXZlIiwgVk1fR1VFU1RfQkhZVkUsIE5VTEwpOworfQorCitIWVBFUlZJU09SX1NZ U0lOSVQoYmh5dmUsIGJoeXZlX2luaXQpOwpkaWZmIC0tZ2l0IGEvc3lzL3g4Ni94ODYvaHlwZXJ2 aXNvci5jIGIvc3lzL3g4Ni94ODYvaHlwZXJ2aXNvci5jCm5ldyBmaWxlIG1vZGUgMTAwNjQ0Cmlu ZGV4IDAwMDAwMDAuLjMwYzcwZGYKLS0tIC9kZXYvbnVsbAorKysgYi9zeXMveDg2L3g4Ni9oeXBl cnZpc29yLmMKQEAgLTAsMCArMSw5OSBAQAorLyotCisgKiBDb3B5cmlnaHQgKGMpIDIwMTQgQnJ5 YW4gVmVudGVpY2hlciA8YnJ5YW52QEZyZWVCU0Qub3JnPgorICogQWxsIHJpZ2h0cyByZXNlcnZl ZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZv cm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92 aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJl ZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJp Z2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93 aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVz dCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qg b2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAg ZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRp c3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRI T1IgQU5EIENPTlRSSUJVVE9SUyBBUyBJUycnIEFORAorICogQU5ZIEVYUFJFU1MgT1IgSU1QTElF RCBXQVJSQU5USUVTLCBJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgVEhFCisgKiBJTVBM SUVEIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIEFORCBGSVRORVNTIEZPUiBBIFBBUlRJ Q1VMQVIgUFVSUE9TRQorICogQVJFIERJU0NMQUlNRUQuICBJTiBOTyBFVkVOVCBTSEFMTCBUSEUg QVVUSE9SIE9SIENPTlRSSUJVVE9SUyBCRSBMSUFCTEUKKyAqIEZPUiBBTlkgRElSRUNULCBJTkRJ UkVDVCwgSU5DSURFTlRBTCwgU1BFQ0lBTCwgRVhFTVBMQVJZLCBPUiBDT05TRVFVRU5USUFMCisg KiBEQU1BR0VTIChJTkNMVURJTkcsIEJVVCBOT1QgTElNSVRFRCBUTywgUFJPQ1VSRU1FTlQgT0Yg U1VCU1RJVFVURSBHT09EUworICogT1IgU0VSVklDRVM7IExPU1MgT0YgVVNFLCBEQVRBLCBPUiBQ Uk9GSVRTOyBPUiBCVVNJTkVTUyBJTlRFUlJVUFRJT04pCisgKiBIT1dFVkVSIENBVVNFRCBBTkQg T04gQU5ZIFRIRU9SWSBPRiBMSUFCSUxJVFksIFdIRVRIRVIgSU4gQ09OVFJBQ1QsIFNUUklDVAor ICogTElBQklMSVRZLCBPUiBUT1JUIChJTkNMVURJTkcgTkVHTElHRU5DRSBPUiBPVEhFUldJU0Up IEFSSVNJTkcgSU4gQU5ZIFdBWQorICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwg RVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRgorICogU1VDSCBEQU1BR0UuCisg Ki8KKworI2luY2x1ZGUgPHN5cy9jZGVmcy5oPgorX19GQlNESUQoIiRGcmVlQlNEJCIpOworCisj aW5jbHVkZSA8c3lzL3BhcmFtLmg+CisjaW5jbHVkZSA8c3lzL3N5c2N0bC5oPgorI2luY2x1ZGUg PHN5cy9zeXN0bS5oPgorCisjaW5jbHVkZSA8bWFjaGluZS9jcHVmdW5jLmg+CisjaW5jbHVkZSA8 bWFjaGluZS9jcHUuaD4KKyNpbmNsdWRlIDxtYWNoaW5lL21kX3Zhci5oPgorI2luY2x1ZGUgPG1h Y2hpbmUvc3BlY2lhbHJlZy5oPgorCisjaW5jbHVkZSA8eDg2L2h5cGVydmlzb3IuaD4KKworY2hh ciBodl92ZW5kb3JbMTZdOworU1lTQ1RMX1NUUklORyhfaHcsIE9JRF9BVVRPLCBodl92ZW5kb3Is IENUTEZMQUdfUkQsIGh2X3ZlbmRvciwgMCwKKyAgICAiSHlwZXJ2aXNvciB2ZW5kb3IiKTsKKwor dm9pZAoraHlwZXJ2aXNvcl9zeXNpbml0KHZvaWQgKmZ1bmMpCit7CisJaHlwZXJ2aXNvcl9pbml0 X2Z1bmNfdCAqaW5pdDsKKworCWluaXQgPSBmdW5jOworCisJLyoKKwkgKiBDYWxsIHRoZSBpbml0 IGZ1bmN0aW9uIGlmIHdlIGhhdmUgbm90IGFscmVhZHkgaWRlbnRpZmllZCB0aGUKKwkgKiBoeXBl cnZpc29yIHlldC4gV2UgYXNzdW1lIHRoZSBkZXRlY3RhYmxlIGh5cGVydmlzb3JzIHdpbGwKKwkg KiBhbm5vdW5jZSBpdHMgcHJlc2VuY2UgdmlhIHRoZSBDUFVJRCBiaXQuCisJICovCisJaWYgKHZt X2d1ZXN0ID09IFZNX0dVRVNUX1ZNICYmIGNwdV9mZWF0dXJlMiAmIENQVUlEMl9IVikKKwkJKCpp bml0KSgpOworfQorCit2b2lkCitoeXBlcnZpc29yX3JlZ2lzdGVyKGNvbnN0IGNoYXIgKnZlbmRv ciwgZW51bSBWTV9HVUVTVCBndWVzdCwKKyAgICBzdHJ1Y3QgaHlwZXJ2aXNvcl9vcHMgKm9wcykK K3sKKworCXN0cmxjcHkoaHZfdmVuZG9yLCB2ZW5kb3IsIHNpemVvZihodl92ZW5kb3IpKTsKKwl2 bV9ndWVzdCA9IGd1ZXN0OworfQorCisvKgorICogW1JGQ10gQ1BVSUQgdXNhZ2UgZm9yIGludGVy YWN0aW9uIGJldHdlZW4gSHlwZXJ2aXNvcnMgYW5kIExpbnV4LgorICogaHR0cDovL2xrbWwub3Jn L2xrbWwvMjAwOC8xMC8xLzI0NgorICovCitpbnQKK2h5cGVydmlzb3JfY3B1aWRfYmFzZShjb25z dCBjaGFyICpzaWduYXR1cmUsIGludCBsZWF2ZXMsIHVpbnQzMl90ICpiYXNlLAorICAgIHVpbnQz Ml90ICpoaWdoKQoreworCXVpbnQzMl90IGxlYWYsIHJlZ3NbNF07CisKKwlmb3IgKGxlYWYgPSAw eDQwMDAwMDAwOyBsZWFmIDwgMHg0MDAxMDAwMDsgbGVhZiArPSAweDEwMCkgeworCQlkb19jcHVp ZChsZWFmLCByZWdzKTsKKwkJaWYgKCFtZW1jbXAoc2lnbmF0dXJlLCAmcmVnc1sxXSwgMTIpICYm CisJCSAgICAobGVhdmVzID09IDAgfHwgKHJlZ3NbMF0gLSBsZWFmID49IGxlYXZlcykpKSB7CisJ CQkqYmFzZSA9IGxlYWY7CisJCQkqaGlnaCA9IHJlZ3NbMF07CisJCQlyZXR1cm4gKDApOworCQl9 CisJfQorCisJcmV0dXJuICgxKTsKK30KKwordm9pZAoraHlwZXJ2aXNvcl9wcmludF9pbmZvKHZv aWQpCit7CisKKwlpZiAoKmh2X3ZlbmRvcikKKwkJcHJpbnRmKCJIeXBlcnZpc29yOiBPcmlnaW4g PSBcIiVzXCJcbiIsIGh2X3ZlbmRvcik7Cit9CmRpZmYgLS1naXQgYS9zeXMveDg2L3g4Ni9pZGVu dGNwdS5jIGIvc3lzL3g4Ni94ODYvaWRlbnRjcHUuYwppbmRleCBiYWU0MzBhLi5jMjgzOTBjIDEw MDY0NAotLS0gYS9zeXMveDg2L3g4Ni9pZGVudGNwdS5jCisrKyBiL3N5cy94ODYveDg2L2lkZW50 Y3B1LmMKQEAgLTY0LDYgKzY0LDcgQEAgX19GQlNESUQoIiRGcmVlQlNEJCIpOwogCiAjaW5jbHVk ZSA8YW1kNjQvdm1tL2ludGVsL3ZteF9jb250cm9scy5oPgogI2luY2x1ZGUgPHg4Ni9pc2EvaWN1 Lmg+CisjaW5jbHVkZSA8eDg2L2h5cGVydmlzb3IuaD4KICNpbmNsdWRlIDx4ODYvdm13YXJlLmg+ CiAKICNpZmRlZiBfX2kzODZfXwpAQCAtNzgsNyArNzksNiBAQCBzdGF0aWMgdV9pbnQgZmluZF9j cHVfdmVuZG9yX2lkKHZvaWQpOwogc3RhdGljIHZvaWQgcHJpbnRfQU1EX2luZm8odm9pZCk7CiBz dGF0aWMgdm9pZCBwcmludF9JTlRFTF9pbmZvKHZvaWQpOwogc3RhdGljIHZvaWQgcHJpbnRfSU5U RUxfVExCKHVfaW50IGRhdGEpOwotc3RhdGljIHZvaWQgcHJpbnRfaHlwZXJ2aXNvcl9pbmZvKHZv aWQpOwogc3RhdGljIHZvaWQgcHJpbnRfc3ZtX2luZm8odm9pZCk7CiBzdGF0aWMgdm9pZCBwcmlu dF92aWFfcGFkbG9ja19pbmZvKHZvaWQpOwogc3RhdGljIHZvaWQgcHJpbnRfdm14X2luZm8odm9p ZCk7CkBAIC0xMjMsMTEgKzEyMyw2IEBAIHN0YXRpYyBpbnQgaHdfY2xvY2tyYXRlOwogU1lTQ1RM X0lOVChfaHcsIE9JRF9BVVRPLCBjbG9ja3JhdGUsIENUTEZMQUdfUkQsCiAgICAgJmh3X2Nsb2Nr cmF0ZSwgMCwgIkNQVSBpbnN0cnVjdGlvbiBjbG9jayByYXRlIik7CiAKLXVfaW50IGh2X2hpZ2g7 Ci1jaGFyIGh2X3ZlbmRvclsxNl07Ci1TWVNDVExfU1RSSU5HKF9odywgT0lEX0FVVE8sIGh2X3Zl bmRvciwgQ1RMRkxBR19SRCwgaHZfdmVuZG9yLCAwLAotICAgICJIeXBlcnZpc29yIHZlbmRvciIp OwotCiBzdGF0aWMgZXZlbnRoYW5kbGVyX3RhZyB0c2NfcG9zdF90YWc7CiAKIHN0YXRpYyBjaGFy IGNwdV9icmFuZFs0OF07CkBAIC05ODUsNyArOTgwLDcgQEAgcHJpbnRjcHVpbmZvKHZvaWQpCiAj ZW5kaWYKIAl9CiAKLQlwcmludF9oeXBlcnZpc29yX2luZm8oKTsKKwloeXBlcnZpc29yX3ByaW50 X2luZm8oKTsKIH0KIAogdm9pZApAQCAtMTIxOCwyNSArMTIxMywxMiBAQCBpZGVudGlmeV9oeXBl cnZpc29yKHZvaWQpCiAJaW50IGk7CiAKIAkvKgotCSAqIFtSRkNdIENQVUlEIHVzYWdlIGZvciBp bnRlcmFjdGlvbiBiZXR3ZWVuIEh5cGVydmlzb3JzIGFuZCBMaW51eC4KLQkgKiBodHRwOi8vbGtt bC5vcmcvbGttbC8yMDA4LzEwLzEvMjQ2Ci0JICoKLQkgKiBLQjEwMDk0NTg6IE1lY2hhbmlzbXMg dG8gZGV0ZXJtaW5lIGlmIHNvZnR3YXJlIGlzIHJ1bm5pbmcgaW4KLQkgKiBhIFZNd2FyZSB2aXJ0 dWFsIG1hY2hpbmUKLQkgKiBodHRwOi8va2Iudm13YXJlLmNvbS9rYi8xMDA5NDU4CisJICogTW9k ZXJuIGh5cGVydmlzb3JzIHNldCB0aGUgSFYgcHJlc2VudCBmZWF0dXJlIGJpdCBhbmQgYXJlIHRo ZW4KKwkgKiBpZGVudGlmaWFibGUgdGhyb3VnaCBhIHNwZWNpYWwgQ1BVSUQgbGVhZi4gSHlwZXJ2 aXNvcnMgd2Uga25vdworCSAqIGFib3V0IGFyZSBsYXRlciBkZXRlY3RlZCB2aWEgdGhlIFNJX1NV Ql9IWVBFUlZJU09SIFNZU0lOSVQoKS4KIAkgKi8KIAlpZiAoY3B1X2ZlYXR1cmUyICYgQ1BVSUQy X0hWKSB7CiAJCXZtX2d1ZXN0ID0gVk1fR1VFU1RfVk07Ci0JCWRvX2NwdWlkKDB4NDAwMDAwMDAs IHJlZ3MpOwotCQlpZiAocmVnc1swXSA+PSAweDQwMDAwMDAwKSB7Ci0JCQlodl9oaWdoID0gcmVn c1swXTsKLQkJCSgodV9pbnQgKikmaHZfdmVuZG9yKVswXSA9IHJlZ3NbMV07Ci0JCQkoKHVfaW50 ICopJmh2X3ZlbmRvcilbMV0gPSByZWdzWzJdOwotCQkJKCh1X2ludCAqKSZodl92ZW5kb3IpWzJd ID0gcmVnc1szXTsKLQkJCWh2X3ZlbmRvclsxMl0gPSAnXDAnOwotCQkJaWYgKHN0cmNtcChodl92 ZW5kb3IsICJWTXdhcmVWTXdhcmUiKSA9PSAwKQotCQkJCXZtX2d1ZXN0ID0gVk1fR1VFU1RfVk1X QVJFOwotCQl9CiAJCXJldHVybjsKIAl9CiAKQEAgLTIxNTAsMTEgKzIxMzIsMyBAQCBwcmludF92 bXhfaW5mbyh2b2lkKQogCQkpOwogCX0KIH0KLQotc3RhdGljIHZvaWQKLXByaW50X2h5cGVydmlz b3JfaW5mbyh2b2lkKQotewotCi0JaWYgKCpodl92ZW5kb3IpCi0JCXByaW50ZigiSHlwZXJ2aXNv cjogT3JpZ2luID0gXCIlc1wiXG4iLCBodl92ZW5kb3IpOwotfQpkaWZmIC0tZ2l0IGEvc3lzL3g4 Ni94ODYva3ZtLmMgYi9zeXMveDg2L3g4Ni9rdm0uYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRl eCAwMDAwMDAwLi5iNDdlYjc2Ci0tLSAvZGV2L251bGwKKysrIGIvc3lzL3g4Ni94ODYva3ZtLmMK QEAgLTAsMCArMSw4MyBAQAorLyotCisgKiBDb3B5cmlnaHQgKGMpIDIwMTQgQnJ5YW4gVmVudGVp Y2hlciA8YnJ5YW52QEZyZWVCU0Qub3JnPgorICogQWxsIHJpZ2h0cyByZXNlcnZlZC4KKyAqCisg KiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJjZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRo IG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJlIHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0 IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJlIG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0 aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAg ICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2Ns YWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4gYmluYXJ5IGZvcm0gbXVzdCByZXByb2R1 Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0 aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVyIGluIHRoZQorICogICAgZG9jdW1lbnRh dGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3ZpZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlv bi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJREVEIEJZIFRIRSBBVVRIT1IgQU5EIENP TlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkgRVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJB TlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBUSEUKKyAqIElNUExJRUQgV0FS UkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJVE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQ VVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5PIEVWRU5UIFNIQUxMIFRIRSBBVVRIT1Ig T1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICogRk9SIEFOWSBESVJFQ1QsIElORElSRUNULCBJ TkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9SIENPTlNFUVVFTlRJQUwKKyAqIERBTUFH RVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRPLCBQUk9DVVJFTUVOVCBPRiBTVUJTVElU VVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBPRiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7 IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhPV0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkg VEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBDT05UUkFDVCwgU1RSSUNUCisgKiBMSUFC SUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdFTkNFIE9SIE9USEVSV0lTRSkgQVJJU0lO RyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNPRlRXQVJFLCBFVkVOIElG IEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisgKiBTVUNIIERBTUFHRS4KKyAqLworCisj aW5jbHVkZSA8c3lzL2NkZWZzLmg+CitfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CisKKyNpbmNsdWRl IDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMvc3lzdG0uaD4KKworI2luY2x1ZGUgPG1hY2hp bmUvY3B1ZnVuYy5oPgorCisjaW5jbHVkZSA8eDg2L2h5cGVydmlzb3IuaD4KKyNpbmNsdWRlIDx4 ODYva3ZtLmg+CisKK3N0YXRpYyBpbnQJCWt2bV9jcHVpZF9pZGVudGlmeSh2b2lkKTsKKworc3Rh dGljIHVpbnQzMl90IGt2bV9jcHVpZF9iYXNlID0gLTE7CitzdGF0aWMgdWludDMyX3Qga3ZtX2Nw dWlkX2hpZ2ggPSAtMTsKKworc3RhdGljIGludAora3ZtX2NwdWlkX2lkZW50aWZ5KHZvaWQpCit7 CisKKwlpZiAoa3ZtX2NwdWlkX2Jhc2UgPT0gLTEpIHsKKwkJaHlwZXJ2aXNvcl9jcHVpZF9iYXNl KCJLVk1LVk1LVk1cMFwwIiwgMCwgJmt2bV9jcHVpZF9iYXNlLAorCQkgICAgJmt2bV9jcHVpZF9o aWdoKTsKKwl9CisKKwlyZXR1cm4gKGt2bV9jcHVpZF9iYXNlID4gMCk7Cit9CisKK2ludAora3Zt X3BhcmF2aXJ0X3N1cHBvcnRlZCh2b2lkKQoreworCisJcmV0dXJuIChrdm1fY3B1aWRfYmFzZSA+ IDApOworfQorCit1aW50MzJfdAora3ZtX2dldF9mZWF0dXJlcyh2b2lkKQoreworCXVfaW50IHJl Z3NbNF07CisKKwlpZiAoa3ZtX3BhcmF2aXJ0X3N1cHBvcnRlZCgpKQorCQlkb19jcHVpZChrdm1f Y3B1aWRfYmFzZSB8IEtWTV9DUFVJRF9GRUFUVVJFU19MRUFGLCByZWdzKTsKKwllbHNlCisJCXJl Z3NbMF0gPSAwOworCisJcmV0dXJuIChyZWdzWzBdKTsKK30KKworc3RhdGljIHZvaWQKK2t2bV9p bml0KHZvaWQpCit7CisKKwlpZiAoa3ZtX2NwdWlkX2lkZW50aWZ5KCkgIT0gMCkKKwkJaHlwZXJ2 aXNvcl9yZWdpc3RlcigiS1ZNIiwgVk1fR1VFU1RfS1ZNLCBOVUxMKTsKK30KKworSFlQRVJWSVNP Ul9TWVNJTklUKGt2bSwga3ZtX2luaXQpOwpkaWZmIC0tZ2l0IGEvc3lzL3g4Ni94ODYva3ZtX2Ns b2NrLmMgYi9zeXMveDg2L3g4Ni9rdm1fY2xvY2suYwpuZXcgZmlsZSBtb2RlIDEwMDY0NAppbmRl eCAwMDAwMDAwLi43ZGE2MzYzCi0tLSAvZGV2L251bGwKKysrIGIvc3lzL3g4Ni94ODYva3ZtX2Ns b2NrLmMKQEAgLTAsMCArMSwxMzIgQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDE0IEJyeWFu IFZlbnRlaWNoZXIgPGJyeWFudkBGcmVlQlNELm9yZz4KKyAqIEFsbCByaWdodHMgcmVzZXJ2ZWQu CisgKgorICogUmVkaXN0cmlidXRpb24gYW5kIHVzZSBpbiBzb3VyY2UgYW5kIGJpbmFyeSBmb3Jt cywgd2l0aCBvciB3aXRob3V0CisgKiBtb2RpZmljYXRpb24sIGFyZSBwZXJtaXR0ZWQgcHJvdmlk ZWQgdGhhdCB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMKKyAqIGFyZSBtZXQ6CisgKiAxLiBSZWRp c3RyaWJ1dGlvbnMgb2Ygc291cmNlIGNvZGUgbXVzdCByZXRhaW4gdGhlIGFib3ZlIGNvcHlyaWdo dAorICogICAgbm90aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2lu ZyBkaXNjbGFpbWVyLgorICogMi4gUmVkaXN0cmlidXRpb25zIGluIGJpbmFyeSBmb3JtIG11c3Qg cmVwcm9kdWNlIHRoZSBhYm92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9m IGNvbmRpdGlvbnMgYW5kIHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lciBpbiB0aGUKKyAqICAgIGRv Y3VtZW50YXRpb24gYW5kL29yIG90aGVyIG1hdGVyaWFscyBwcm92aWRlZCB3aXRoIHRoZSBkaXN0 cmlidXRpb24uCisgKgorICogVEhJUyBTT0ZUV0FSRSBJUyBQUk9WSURFRCBCWSBUSEUgQVVUSE9S IEFORCBDT05UUklCVVRPUlMgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBSRVNTIE9SIElNUExJRUQg V0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFRIRQorICogSU1QTElF RCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVTUyBGT1IgQSBQQVJUSUNV TEFSIFBVUlBPU0UKKyAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZFTlQgU0hBTEwgVEhFIEFV VEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5ZIERJUkVDVCwgSU5ESVJF Q1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09OU0VRVUVOVElBTAorICog REFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBST0NVUkVNRU5UIE9GIFNV QlNUSVRVVEUgR09PRFMKKyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVTRSwgREFUQSwgT1IgUFJP RklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZFUiBDQVVTRUQgQU5EIE9O IEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRSQUNULCBTVFJJQ1QKKyAq IExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0UgT1IgT1RIRVJXSVNFKSBB UklTSU5HIElOIEFOWSBXQVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRISVMgU09GVFdBUkUsIEVW RU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNVQ0ggREFNQUdFLgorICov CisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJlZUJTRCQiKTsKKworI2lu Y2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9rZXJuZWwuaD4KKyNpbmNsdWRlIDxz eXMvbGltaXRzLmg+CisjaW5jbHVkZSA8c3lzL3N5c3RtLmg+CisjaW5jbHVkZSA8c3lzL3BjcHUu aD4KKyNpbmNsdWRlIDxzeXMvc21wLmg+CisjaW5jbHVkZSA8c3lzL3RpbWV0Yy5oPgorCisjaW5j bHVkZSA8dm0vdm0uaD4KKyNpbmNsdWRlIDx2bS9wbWFwLmg+CisKKyNpbmNsdWRlIDxtYWNoaW5l L3B2Y2xvY2suaD4KKyNpbmNsdWRlIDx4ODYva3ZtLmg+CisKK3N0YXRpYyB1X2ludAlrdm1fY2xv Y2tfZ2V0X3RpbWVjb3VudGVyKHN0cnVjdCB0aW1lY291bnRlciAqKTsKK3N0YXRpYyB2b2lkCWt2 bV9jbG9ja19wY3B1X3N5c3RlbV90aW1lKHZvaWQgKik7CisKK0RQQ1BVX0RFRklORShzdHJ1Y3Qg cHZjbG9ja192Y3B1X3RpbWVfaW5mbywga3ZtX2Nsb2NrX3ZjcHVfdGltZV9pbmZvKTsKKworc3Rh dGljIHN0cnVjdCB0aW1lY291bnRlciBrdm1fY2xvY2tfdGltZWNvdW50ZXIgPSB7CisJa3ZtX2Ns b2NrX2dldF90aW1lY291bnRlciwKKwlOVUxMLAorCX4wdSwKKwkxMDAwMDAwMDAwVUxMLAorCSJL Vk1DTE9DSyIsCisJMTAwMCwKK307CisKK3N0YXRpYyBpbnQJCWt2bV9jbG9ja19yZWdpc3RlcmVk Oworc3RhdGljIHVpbnQzMl90CQlrdm1fY2xvY2tfd2FsbF9jbG9ja19tc3I7CitzdGF0aWMgdWlu dDMyX3QJCWt2bV9jbG9ja19zeXN0ZW1fdGltZV9tc3I7CisKK3VpbnQ2NF90Citrdm1fY2xvY2tf dHNjX2ZyZXEodm9pZCkKK3sKKwlzdHJ1Y3QgcHZjbG9ja192Y3B1X3RpbWVfaW5mbyAqdGk7CisJ dWludDY0X3QgZnJlcTsKKworCWNyaXRpY2FsX2VudGVyKCk7CisJdGkgPSBEUENQVV9QVFIoa3Zt X2Nsb2NrX3ZjcHVfdGltZV9pbmZvKTsKKwlmcmVxID0gcHZjbG9ja190c2NfZnJlcSh0aSk7CisJ Y3JpdGljYWxfZXhpdCgpOworCisJcmV0dXJuIChmcmVxKTsKK30KKworc3RhdGljIHVfaW50Citr dm1fY2xvY2tfZ2V0X3RpbWVjb3VudGVyKHN0cnVjdCB0aW1lY291bnRlciAqdGMpCit7CisJc3Ry dWN0IHB2Y2xvY2tfdmNwdV90aW1lX2luZm8gKnRpOworCXVpbnQ2NF90IHRpbWU7CisKKwljcml0 aWNhbF9lbnRlcigpOworCXRpID0gRFBDUFVfUFRSKGt2bV9jbG9ja192Y3B1X3RpbWVfaW5mbyk7 CisJdGltZSA9IHB2Y2xvY2tfZ2V0X3RpbWVjb3VudCh0aSk7CisJY3JpdGljYWxfZXhpdCgpOwor CisJcmV0dXJuICh0aW1lICYgVUlOVF9NQVgpOworfQorCitzdGF0aWMgdm9pZAora3ZtX2Nsb2Nr X3BjcHVfc3lzdGVtX3RpbWUodm9pZCAqYXJnKQoreworCXVpbnQ2NF90IGRhdGE7CisJaW50IGVu YWJsZTsKKworCWVuYWJsZSA9ICooaW50ICopIGFyZzsKKworCWlmIChlbmFibGUgIT0gMCkKKwkJ ZGF0YSA9IHZ0b3BoeXMoRFBDUFVfUFRSKGt2bV9jbG9ja192Y3B1X3RpbWVfaW5mbykpIHwgMTsK KwllbHNlCisJCWRhdGEgPSAwOworCisJd3Jtc3Ioa3ZtX2Nsb2NrX3N5c3RlbV90aW1lX21zciwg ZGF0YSk7Cit9CisKK3N0YXRpYyB2b2lkCitrdm1fY2xvY2tfaW5pdCh2b2lkKQoreworCXVpbnQz Ml90IGZlYXR1cmVzOworCisJaWYgKHZtX2d1ZXN0ICE9IFZNX0dVRVNUX0tWTSB8fCAha3ZtX3Bh cmF2aXJ0X3N1cHBvcnRlZCgpKQorCQlyZXR1cm47CisKKwlmZWF0dXJlcyA9IGt2bV9nZXRfZmVh dHVyZXMoKTsKKworCWlmIChmZWF0dXJlcyAmIEtWTV9GRUFUVVJFX0NMT0NLU09VUkNFMikgewor CQlrdm1fY2xvY2tfd2FsbF9jbG9ja19tc3IgPSBLVk1fTVNSX1dBTExfQ0xPQ0tfTkVXOworCQlr dm1fY2xvY2tfc3lzdGVtX3RpbWVfbXNyID0gS1ZNX01TUl9TWVNURU1fVElNRV9ORVc7CisJfSBl bHNlIGlmIChmZWF0dXJlcyAmIEtWTV9GRUFUVVJFX0NMT0NLU09VUkNFKSB7CisJCWt2bV9jbG9j a193YWxsX2Nsb2NrX21zciA9IEtWTV9NU1JfV0FMTF9DTE9DSzsKKwkJa3ZtX2Nsb2NrX3N5c3Rl bV90aW1lX21zciA9IEtWTV9NU1JfU1lTVEVNX1RJTUU7CisJfSBlbHNlCisJCXJldHVybjsKKwor CWt2bV9jbG9ja19yZWdpc3RlcmVkID0gMTsKKwlzbXBfcmVuZGV6dm91cyhzbXBfbm9fcmVuZGV2 b3VzX2JhcnJpZXIsIGt2bV9jbG9ja19wY3B1X3N5c3RlbV90aW1lLAorCSAgICBzbXBfbm9fcmVu ZGV2b3VzX2JhcnJpZXIsICZrdm1fY2xvY2tfcmVnaXN0ZXJlZCk7CisKKwl0Y19pbml0KCZrdm1f Y2xvY2tfdGltZWNvdW50ZXIpOworfQorCitTWVNJTklUKGt2bV9jbG9jaywgU0lfU1VCX1NNUCwg U0lfT1JERVJfQU5ZLCBrdm1fY2xvY2tfaW5pdCwgTlVMTCk7CmRpZmYgLS1naXQgYS9zeXMveDg2 L3g4Ni9wdmNsb2NrLmMgYi9zeXMveDg2L3g4Ni9wdmNsb2NrLmMKbmV3IGZpbGUgbW9kZSAxMDA2 NDQKaW5kZXggMDAwMDAwMC4uZDBlZWYxODUKLS0tIC9kZXYvbnVsbAorKysgYi9zeXMveDg2L3g4 Ni9wdmNsb2NrLmMKQEAgLTAsMCArMSwxOTcgQEAKKy8qLQorICogQ29weXJpZ2h0IChjKSAyMDA5 IEFkcmlhbiBDaGFkZAorICogQ29weXJpZ2h0IChjKSAyMDEyIFNwZWN0cmEgTG9naWMgQ29ycG9y YXRpb24KKyAqIENvcHlyaWdodCAoYykgMjAxNCBCcnlhbiBWZW50ZWljaGVyCisgKiBBbGwgcmln aHRzIHJlc2VydmVkLgorICoKKyAqIFJlZGlzdHJpYnV0aW9uIGFuZCB1c2UgaW4gc291cmNlIGFu ZCBiaW5hcnkgZm9ybXMsIHdpdGggb3Igd2l0aG91dAorICogbW9kaWZpY2F0aW9uLCBhcmUgcGVy bWl0dGVkIHByb3ZpZGVkIHRoYXQgdGhlIGZvbGxvd2luZyBjb25kaXRpb25zCisgKiBhcmUgbWV0 OgorICogMS4gUmVkaXN0cmlidXRpb25zIG9mIHNvdXJjZSBjb2RlIG11c3QgcmV0YWluIHRoZSBh Ym92ZSBjb3B5cmlnaHQKKyAqICAgIG5vdGljZSwgdGhpcyBsaXN0IG9mIGNvbmRpdGlvbnMgYW5k IHRoZSBmb2xsb3dpbmcgZGlzY2xhaW1lci4KKyAqIDIuIFJlZGlzdHJpYnV0aW9ucyBpbiBiaW5h cnkgZm9ybSBtdXN0IHJlcHJvZHVjZSB0aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2Us IHRoaXMgbGlzdCBvZiBjb25kaXRpb25zIGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIgaW4g dGhlCisgKiAgICBkb2N1bWVudGF0aW9uIGFuZC9vciBvdGhlciBtYXRlcmlhbHMgcHJvdmlkZWQg d2l0aCB0aGUgZGlzdHJpYnV0aW9uLgorICoKKyAqIFRISVMgU09GVFdBUkUgSVMgUFJPVklERUQg QlkgVEhFIEFVVEhPUiBBTkQgQ09OVFJJQlVUT1JTIGBgQVMgSVMnJyBBTkQKKyAqIEFOWSBFWFBS RVNTIE9SIElNUExJRUQgV0FSUkFOVElFUywgSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8s IFRIRQorICogSU1QTElFRCBXQVJSQU5USUVTIE9GIE1FUkNIQU5UQUJJTElUWSBBTkQgRklUTkVT UyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UKKyAqIEFSRSBESVNDTEFJTUVELiAgSU4gTk8gRVZF TlQgU0hBTEwgVEhFIEFVVEhPUiBPUiBDT05UUklCVVRPUlMgQkUgTElBQkxFCisgKiBGT1IgQU5Z IERJUkVDVCwgSU5ESVJFQ1QsIElOQ0lERU5UQUwsIFNQRUNJQUwsIEVYRU1QTEFSWSwgT1IgQ09O U0VRVUVOVElBTAorICogREFNQUdFUyAoSU5DTFVESU5HLCBCVVQgTk9UIExJTUlURUQgVE8sIFBS T0NVUkVNRU5UIE9GIFNVQlNUSVRVVEUgR09PRFMKKyAqIE9SIFNFUlZJQ0VTOyBMT1NTIE9GIFVT RSwgREFUQSwgT1IgUFJPRklUUzsgT1IgQlVTSU5FU1MgSU5URVJSVVBUSU9OKQorICogSE9XRVZF UiBDQVVTRUQgQU5EIE9OIEFOWSBUSEVPUlkgT0YgTElBQklMSVRZLCBXSEVUSEVSIElOIENPTlRS QUNULCBTVFJJQ1QKKyAqIExJQUJJTElUWSwgT1IgVE9SVCAoSU5DTFVESU5HIE5FR0xJR0VOQ0Ug T1IgT1RIRVJXSVNFKSBBUklTSU5HIElOIEFOWSBXQVkKKyAqIE9VVCBPRiBUSEUgVVNFIE9GIFRI SVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YKKyAqIFNV Q0ggREFNQUdFLgorICovCisKKyNpbmNsdWRlIDxzeXMvY2RlZnMuaD4KK19fRkJTRElEKCIkRnJl ZUJTRCQiKTsKKworI2luY2x1ZGUgPHN5cy9wYXJhbS5oPgorI2luY2x1ZGUgPHN5cy9zeXN0bS5o PgorI2luY2x1ZGUgPHN5cy9wcm9jLmg+CisKKyNpbmNsdWRlIDxtYWNoaW5lL2NwdWZ1bmMuaD4K KyNpbmNsdWRlIDxtYWNoaW5lL2NwdS5oPgorI2luY2x1ZGUgPG1hY2hpbmUvYXRvbWljLmg+Cisj aW5jbHVkZSA8bWFjaGluZS9wdmNsb2NrLmg+CisKKy8qCisgKiBMYXN0IHRpbWU7IHRoaXMgZ3Vh cmFudGVlcyBhIG1vbm90b25pY2FsbHkgaW5jcmVhc2luZyBjbG9jayBmb3Igd2hlbgorICogYSBz dGFibGUgVFNDIGlzIG5vdCBwcm92aWRlZC4KKyAqLworc3RhdGljIHZvbGF0aWxlIHVpbnQ2NF90 IHB2Y2xvY2tfbGFzdF9jeWNsZXM7CisKK3ZvaWQKK3B2Y2xvY2tfcmVzdW1lKHZvaWQpCit7CisK KwlhdG9taWNfc3RvcmVfcmVsXzY0KCZwdmNsb2NrX2xhc3RfY3ljbGVzLCAwKTsKK30KKwordWlu dDY0X3QKK3B2Y2xvY2tfdHNjX2ZyZXEoc3RydWN0IHB2Y2xvY2tfdmNwdV90aW1lX2luZm8gKnRp KQoreworCXVpbnQ2NF90IGZyZXE7CisKKwlmcmVxID0gKDEwMDAwMDAwMDBVTEwgPDwgMzIpIC8g dGktPnRzY190b19zeXN0ZW1fbXVsOworCisJaWYgKHRpLT50c2Nfc2hpZnQgPCAwKQorCQlmcmVx IDw8PSAtdGktPnRzY19zaGlmdDsKKwllbHNlCisJCWZyZXEgPj49IHRpLT50c2Nfc2hpZnQ7CisK KwlyZXR1cm4gKGZyZXEpOworfQorCisvKgorICogU2NhbGUgYSA2NC1iaXQgZGVsdGEgYnkgc2Nh bGluZyBhbmQgbXVsdGlwbHlpbmcgYnkgYSAzMi1iaXQgZnJhY3Rpb24sCisgKiB5aWVsZGluZyBh IDY0LWJpdCByZXN1bHQuCisgKi8KK3N0YXRpYyBpbmxpbmUgdWludDY0X3QKK3B2Y2xvY2tfc2Nh bGVfZGVsdGEodWludDY0X3QgZGVsdGEsIHVpbnQzMl90IG11bF9mcmFjLCBpbnQgc2hpZnQpCit7 CisJdWludDY0X3QgcHJvZHVjdDsKKworCWlmIChzaGlmdCA8IDApCisJCWRlbHRhID4+PSAtc2hp ZnQ7CisJZWxzZQorCQlkZWx0YSA8PD0gc2hpZnQ7CisKKyNpZiBkZWZpbmVkKF9faTM4Nl9fKQor CXsKKwkJdWludDMyX3QgdG1wMSwgdG1wMjsKKworCQkvKioKKwkJICogRm9yIGkzODYsIHRoZSBm b3JtdWxhIGxvb2tzIGxpa2U6CisJCSAqCisJCSAqICAgbG93ZXIgPSAobXVsX2ZyYWMgKiAoZGVs dGEgJiBVSU5UX01BWCkpID4+IDMyCisJCSAqICAgdXBwZXIgPSBtdWxfZnJhYyAqIChkZWx0YSA+ PiAzMikKKwkJICogICBwcm9kdWN0ID0gbG93ZXIgKyB1cHBlcgorCQkgKi8KKwkJX19hc21fXyAo CisJCQkibXVsICAlNSAgICAgICA7ICIKKwkJCSJtb3YgICU0LCUlZWF4IDsgIgorCQkJIm1vdiAg JSVlZHgsJTQgOyAiCisJCQkibXVsICAlNSAgICAgICA7ICIKKwkJCSJ4b3IgICU1LCU1ICAgIDsg IgorCQkJImFkZCAgJTQsJSVlYXggOyAiCisJCQkiYWRjICAlNSwlJWVkeCA7ICIKKwkJCTogIj1B IiAocHJvZHVjdCksICI9ciIgKHRtcDEpLCAiPXIiICh0bXAyKQorCQkJOiAiYSIgKCh1aW50MzJf dClkZWx0YSksICIxIiAoKHVpbnQzMl90KShkZWx0YSA+PiAzMikpLAorCQkJICAiMiIgKG11bF9m cmFjKSApOworCX0KKyNlbGlmIGRlZmluZWQoX19hbWQ2NF9fKQorCXsKKwkJdW5zaWduZWQgbG9u ZyB0bXA7CisKKwkJX19hc21fXyAoCisJCQkibXVscSAlW211bF9mcmFjXSA7IHNocmQgJDMyLCAl W2hpXSwgJVtsb10iCisJCQk6IFtsb10iPWEiIChwcm9kdWN0KSwgW2hpXSI9ZCIgKHRtcCkKKwkJ CTogIjAiIChkZWx0YSksIFttdWxfZnJhY10icm0iKCh1aW50NjRfdCltdWxfZnJhYykpOworCX0K KyNlbHNlCisjZXJyb3IgInB2Y2xvY2s6IHVuc3VwcG9ydGVkIHg4NiBhcmNoaXRlY3R1cmU/Igor I2VuZGlmCisKKwlyZXR1cm4gKHByb2R1Y3QpOworfQorCitzdGF0aWMgdWludDY0X3QKK3B2Y2xv Y2tfZ2V0X25zZWNfb2Zmc2V0KHN0cnVjdCBwdmNsb2NrX3ZjcHVfdGltZV9pbmZvICp0aSkKK3sK Kwl1aW50NjRfdCBkZWx0YTsKKworCWRlbHRhID0gcmR0c2MoKSAtIHRpLT50c2NfdGltZXN0YW1w OworCisJcmV0dXJuIChwdmNsb2NrX3NjYWxlX2RlbHRhKGRlbHRhLCB0aS0+dHNjX3RvX3N5c3Rl bV9tdWwsCisJICAgIHRpLT50c2Nfc2hpZnQpKTsKK30KKworc3RhdGljIHZvaWQKK3B2Y2xvY2tf cmVhZF90aW1lX2luZm8oc3RydWN0IHB2Y2xvY2tfdmNwdV90aW1lX2luZm8gKnRpLAorICAgIHVp bnQ2NF90ICpjeWNsZXMsIHVpbnQ4X3QgKmZsYWdzKQoreworCXVpbnQzMl90IHZlcnNpb247CisK KwlkbyB7CisJCXZlcnNpb24gPSB0aS0+dmVyc2lvbjsKKwkJcm1iKCk7CisJCSpjeWNsZXMgPSB0 aS0+c3lzdGVtX3RpbWUgKyBwdmNsb2NrX2dldF9uc2VjX29mZnNldCh0aSk7CisJCSpmbGFncyA9 IHRpLT5mbGFnczsKKwkJcm1iKCk7CisJfSB3aGlsZSAoKHRpLT52ZXJzaW9uICYgMSkgIT0gMCB8 fCB0aS0+dmVyc2lvbiAhPSB2ZXJzaW9uKTsKK30KKworc3RhdGljIHZvaWQKK3B2Y2xvY2tfcmVh ZF93YWxsX2Nsb2NrKHN0cnVjdCBwdmNsb2NrX3dhbGxfY2xvY2sgKndjLCB1aW50MzJfdCAqc2Vj LAorICAgIHVpbnQzMl90ICpuc2VjKQoreworCXVpbnQzMl90IHZlcnNpb247CisKKwlkbyB7CisJ CXZlcnNpb24gPSB3Yy0+dmVyc2lvbjsKKwkJcm1iKCk7CisJCSpzZWMgPSB3Yy0+c2VjOworCQkq bnNlYyA9IHdjLT5uc2VjOworCQlybWIoKTsKKwl9IHdoaWxlICgod2MtPnZlcnNpb24gJiAxKSAh PSAwIHx8IHdjLT52ZXJzaW9uICE9IHZlcnNpb24pOworfQorCit1aW50NjRfdAorcHZjbG9ja19n ZXRfdGltZWNvdW50KHN0cnVjdCBwdmNsb2NrX3ZjcHVfdGltZV9pbmZvICp0aSkKK3sKKwl1aW50 NjRfdCBub3c7CisJdWludDhfdCBmbGFnczsKKwl2b2xhdGlsZSB1aW50NjRfdCBsYXN0OworCisJ cHZjbG9ja19yZWFkX3RpbWVfaW5mbyh0aSwgJm5vdywgJmZsYWdzKTsKKworCWlmIChmbGFncyAm IFBWQ0xPQ0tfRkxBR19UU0NfU1RBQkxFKQorCQlyZXR1cm4gKG5vdyk7CisKKwkvKgorCSAqIEVu Zm9yY2UgYSBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmcgY2xvY2sgdGltZSBhY3Jvc3MgYWxsIFZD UFVzLgorCSAqIElmIG91ciB0aW1lIGlzIHRvbyBvbGQsIHVzZSB0aGUgbGFzdCB0aW1lIGFuZCBy ZXR1cm4uIE90aGVyd2lzZSwKKwkgKiB0cnkgdG8gdXBkYXRlIHRoZSBsYXN0IHRpbWUuCisJICov CisJZG8geworCQlsYXN0ID0gYXRvbWljX2xvYWRfYWNxXzY0KCZwdmNsb2NrX2xhc3RfY3ljbGVz KTsKKwkJaWYgKGxhc3QgPiBub3cpCisJCQlyZXR1cm4gKGxhc3QpOworCX0gd2hpbGUgKCFhdG9t aWNfY21wc2V0XzY0KCZwdmNsb2NrX2xhc3RfY3ljbGVzLCBsYXN0LCBub3cpKTsKKworCXJldHVy biAobm93KTsKK30KKwordm9pZAorcHZjbG9ja19nZXRfd2FsbGNsb2NrKHN0cnVjdCBwdmNsb2Nr X3dhbGxfY2xvY2sgKndjLCBzdHJ1Y3QgdGltZXNwZWMgKnRzKQoreworCXVpbnQzMl90IHNlYywg bnNlYzsKKworCXB2Y2xvY2tfcmVhZF93YWxsX2Nsb2NrKHdjLCAmc2VjLCAmbnNlYyk7CisJdHMt PnR2X3NlYyA9IHNlYzsKKwl0cy0+dHZfbnNlYyA9IG5zZWM7Cit9CmRpZmYgLS1naXQgYS9zeXMv eDg2L3g4Ni90c2MuYyBiL3N5cy94ODYveDg2L3RzYy5jCmluZGV4IDRjYTU3NGUuLmE4MzRjYjUg MTAwNjQ0Ci0tLSBhL3N5cy94ODYveDg2L3RzYy5jCisrKyBiL3N5cy94ODYveDg2L3RzYy5jCkBA IC0xMDQsMjIgKzEwNCw2IEBAIHN0YXRpYyBzdHJ1Y3QgdGltZWNvdW50ZXIgdHNjX3RpbWVjb3Vu dGVyID0gewogfTsKIAogc3RhdGljIHZvaWQKLXRzY19mcmVxX3Ztd2FyZSh2b2lkKQotewotCXVf aW50IHJlZ3NbNF07Ci0KLQlpZiAoaHZfaGlnaCA+PSAweDQwMDAwMDEwKSB7Ci0JCWRvX2NwdWlk KDB4NDAwMDAwMTAsIHJlZ3MpOwotCQl0c2NfZnJlcSA9IHJlZ3NbMF0gKiAxMDAwOwotCX0gZWxz ZSB7Ci0JCXZtd2FyZV9odmNhbGwoVk1XX0hWQ01EX0dFVEhaLCByZWdzKTsKLQkJaWYgKHJlZ3Nb MV0gIT0gVUlOVF9NQVgpCi0JCQl0c2NfZnJlcSA9IHJlZ3NbMF0gfCAoKHVpbnQ2NF90KXJlZ3Nb MV0gPDwgMzIpOwotCX0KLQl0c2NfaXNfaW52YXJpYW50ID0gMTsKLX0KLQotc3RhdGljIHZvaWQK IHRzY19mcmVxX2ludGVsKHZvaWQpCiB7CiAJY2hhciBicmFuZFs0OF07CkBAIC0yMDEsNyArMTg1 LDggQEAgcHJvYmVfdHNjX2ZyZXEodm9pZCkKIAl9CiAKIAlpZiAodm1fZ3Vlc3QgPT0gVk1fR1VF U1RfVk1XQVJFKSB7Ci0JCXRzY19mcmVxX3Ztd2FyZSgpOworCQl0c2NfZnJlcSA9IHZtd2FyZV90 c2NfZnJlcSgpOworCQl0c2NfaXNfaW52YXJpYW50ID0gMTsKIAkJcmV0dXJuOwogCX0KIApkaWZm IC0tZ2l0IGEvc3lzL3g4Ni94ODYvdm13YXJlLmMgYi9zeXMveDg2L3g4Ni92bXdhcmUuYwpuZXcg ZmlsZSBtb2RlIDEwMDY0NAppbmRleCAwMDAwMDAwLi5lMTZhY2JiCi0tLSAvZGV2L251bGwKKysr IGIvc3lzL3g4Ni94ODYvdm13YXJlLmMKQEAgLTAsMCArMSw4NCBAQAorLyotCisgKiBDb3B5cmln aHQgKGMpIDIwMTQgQnJ5YW4gVmVudGVpY2hlciA8YnJ5YW52QEZyZWVCU0Qub3JnPgorICogQWxs IHJpZ2h0cyByZXNlcnZlZC4KKyAqCisgKiBSZWRpc3RyaWJ1dGlvbiBhbmQgdXNlIGluIHNvdXJj ZSBhbmQgYmluYXJ5IGZvcm1zLCB3aXRoIG9yIHdpdGhvdXQKKyAqIG1vZGlmaWNhdGlvbiwgYXJl IHBlcm1pdHRlZCBwcm92aWRlZCB0aGF0IHRoZSBmb2xsb3dpbmcgY29uZGl0aW9ucworICogYXJl IG1ldDoKKyAqIDEuIFJlZGlzdHJpYnV0aW9ucyBvZiBzb3VyY2UgY29kZSBtdXN0IHJldGFpbiB0 aGUgYWJvdmUgY29weXJpZ2h0CisgKiAgICBub3RpY2UsIHRoaXMgbGlzdCBvZiBjb25kaXRpb25z IGFuZCB0aGUgZm9sbG93aW5nIGRpc2NsYWltZXIuCisgKiAyLiBSZWRpc3RyaWJ1dGlvbnMgaW4g YmluYXJ5IGZvcm0gbXVzdCByZXByb2R1Y2UgdGhlIGFib3ZlIGNvcHlyaWdodAorICogICAgbm90 aWNlLCB0aGlzIGxpc3Qgb2YgY29uZGl0aW9ucyBhbmQgdGhlIGZvbGxvd2luZyBkaXNjbGFpbWVy IGluIHRoZQorICogICAgZG9jdW1lbnRhdGlvbiBhbmQvb3Igb3RoZXIgbWF0ZXJpYWxzIHByb3Zp ZGVkIHdpdGggdGhlIGRpc3RyaWJ1dGlvbi4KKyAqCisgKiBUSElTIFNPRlRXQVJFIElTIFBST1ZJ REVEIEJZIFRIRSBBVVRIT1IgQU5EIENPTlRSSUJVVE9SUyBgYEFTIElTJycgQU5ECisgKiBBTlkg RVhQUkVTUyBPUiBJTVBMSUVEIFdBUlJBTlRJRVMsIElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVE IFRPLCBUSEUKKyAqIElNUExJRUQgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgQU5EIEZJ VE5FU1MgRk9SIEEgUEFSVElDVUxBUiBQVVJQT1NFCisgKiBBUkUgRElTQ0xBSU1FRC4gIElOIE5P IEVWRU5UIFNIQUxMIFRIRSBBVVRIT1IgT1IgQ09OVFJJQlVUT1JTIEJFIExJQUJMRQorICogRk9S IEFOWSBESVJFQ1QsIElORElSRUNULCBJTkNJREVOVEFMLCBTUEVDSUFMLCBFWEVNUExBUlksIE9S IENPTlNFUVVFTlRJQUwKKyAqIERBTUFHRVMgKElOQ0xVRElORywgQlVUIE5PVCBMSU1JVEVEIFRP LCBQUk9DVVJFTUVOVCBPRiBTVUJTVElUVVRFIEdPT0RTCisgKiBPUiBTRVJWSUNFUzsgTE9TUyBP RiBVU0UsIERBVEEsIE9SIFBST0ZJVFM7IE9SIEJVU0lORVNTIElOVEVSUlVQVElPTikKKyAqIEhP V0VWRVIgQ0FVU0VEIEFORCBPTiBBTlkgVEhFT1JZIE9GIExJQUJJTElUWSwgV0hFVEhFUiBJTiBD T05UUkFDVCwgU1RSSUNUCisgKiBMSUFCSUxJVFksIE9SIFRPUlQgKElOQ0xVRElORyBORUdMSUdF TkNFIE9SIE9USEVSV0lTRSkgQVJJU0lORyBJTiBBTlkgV0FZCisgKiBPVVQgT0YgVEhFIFVTRSBP RiBUSElTIFNPRlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GCisg KiBTVUNIIERBTUFHRS4KKyAqLworCisjaW5jbHVkZSA8c3lzL2NkZWZzLmg+CitfX0ZCU0RJRCgi JEZyZWVCU0QkIik7CisKKyNpbmNsdWRlIDxzeXMvcGFyYW0uaD4KKyNpbmNsdWRlIDxzeXMvc3lz dG0uaD4KKyNpbmNsdWRlIDxzeXMvbGltaXRzLmg+CisKKyNpbmNsdWRlIDx4ODYvaHlwZXJ2aXNv ci5oPgorI2luY2x1ZGUgPHg4Ni92bXdhcmUuaD4KKworc3RhdGljIHVpbnQzMl90IHZtd2FyZV9j cHVpZF9iYXNlID0gLTE7CitzdGF0aWMgdWludDMyX3Qgdm13YXJlX2NwdWlkX2hpZ2ggPSAtMTsK Kworc3RhdGljIGludAordm13YXJlX2NwdWlkX2lkZW50aWZ5KHZvaWQpCit7CisKKwkvKgorCSAq IEtCMTAwOTQ1ODogTWVjaGFuaXNtcyB0byBkZXRlcm1pbmUgaWYgc29mdHdhcmUgaXMgcnVubmlu ZyBpbiBhCisJICogVk13YXJlIHZpcnR1YWwgbWFjaGluZTogaHR0cDovL2tiLnZtd2FyZS5jb20v a2IvMTAwOTQ1OAorCSAqLworCWlmICh2bXdhcmVfY3B1aWRfYmFzZSA9PSAtMSkgeworCQloeXBl cnZpc29yX2NwdWlkX2Jhc2UoIlZNd2FyZVZNd2FyZSIsIDAsICZ2bXdhcmVfY3B1aWRfYmFzZSwK KwkJICAgICZ2bXdhcmVfY3B1aWRfaGlnaCk7CisJfQorCisJcmV0dXJuICh2bXdhcmVfY3B1aWRf YmFzZSA+IDApOworfQorCit1aW50NjRfdAordm13YXJlX3RzY19mcmVxKHZvaWQpCit7CisJdWlu dDY0X3QgZnJlcTsKKwl1X2ludCByZWdzWzRdOworCisJaWYgKHZtd2FyZV9jcHVpZF9oaWdoID49 IDB4NDAwMDAwMTApIHsKKwkJZG9fY3B1aWQoMHg0MDAwMDAxMCwgcmVncyk7CisJCWZyZXEgPSBy ZWdzWzBdICogMTAwMDsKKwl9IGVsc2UgeworCQl2bXdhcmVfaHZjYWxsKFZNV19IVkNNRF9HRVRI WiwgcmVncyk7CisJCWlmIChyZWdzWzFdICE9IFVJTlRfTUFYKQorCQkJZnJlcSA9IHJlZ3NbMF0g fCAoKHVpbnQ2NF90KXJlZ3NbMV0gPDwgMzIpOworCQllbHNlCisJCQlmcmVxID0gMDsKKwl9CisK KwlyZXR1cm4gKGZyZXEpOworfQorCitzdGF0aWMgdm9pZAordm13YXJlX2luaXQodm9pZCkKK3sK KworCWlmICh2bXdhcmVfY3B1aWRfaWRlbnRpZnkoKSAhPSAwKQorCQloeXBlcnZpc29yX3JlZ2lz dGVyKCJWTXdhcmUiLCBWTV9HVUVTVF9WTVdBUkUsIE5VTEwpOworfQorCitIWVBFUlZJU09SX1NZ U0lOSVQodm13YXJlLCB2bXdhcmVfaW5pdCk7Cg== --001a11425fb46ce52b050bd74b4a-- From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 18:20:31 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67CD4705; Sun, 4 Jan 2015 18:20:31 +0000 (UTC) Received: from mx1.stack.nl (relay04.stack.nl [IPv6:2001:610:1108:5010::107]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id EC4D5355; Sun, 4 Jan 2015 18:20:30 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 37D12B805D; Sun, 4 Jan 2015 19:20:27 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 2272528494; Sun, 4 Jan 2015 19:20:27 +0100 (CET) Date: Sun, 4 Jan 2015 19:20:27 +0100 From: Jilles Tjoelker To: Konstantin Belousov Subject: Re: Fixing dlopen("libpthread.so") Message-ID: <20150104182026.GA61250@stack.nl> References: <20141226165337.GJ1754@kib.kiev.ua> <20150103212837.GC46373@stack.nl> <20150104114600.GC42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150104114600.GC42409@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: threads@freebsd.org, arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 18:20:31 -0000 On Sun, Jan 04, 2015 at 01:46:00PM +0200, Konstantin Belousov wrote: > On Sat, Jan 03, 2015 at 10:28:37PM +0100, Jilles Tjoelker wrote: > > I think this can work, conceptually. > The changes were already committed, right before I got your mail. > Still, thank you for the useful review. > > Does this also mean that the order of libc and libthr on the link line > > no longer matters? (so SVN r265003 could be reverted?) > I think yes, it could. I have similar queries already. > IMO it makes sense to wait some time for the changes to settle before > even asking for testing of such reversals. OK. > > It looks like this change may introduce more indirection in common paths > > which might harm performance. The effect is slight and on the other hand > > more single-threaded applications can benefit from non-libthr > > performance. > > I noticed a problem in lib/libc/gen/raise.c: it calls the INTERPOS_pause > > entry instead of the INTERPOS_raise entry. Alternatively, libc could > > call thr_self() and thr_kill() so libthr need not do anything (much like > > how lib/libc/gen/sem_new.c works). > This was noted already and corrected raise.c committed. > I have mixed feeling about the proposal to change raise(3) to use > threading syscalls. On the one hand, it indeed works, on the other, > there are subtle differences, not all important, WRT the change. E.g., > puzzling ktrace output, changed si_code from SI_USER to SI_LWP (is this > a bug on its own ?) . SI_LWP already occurs with libthr's raise(), and with pthread_kill(pthread_self(), sig); which POSIX says is equivalent. > > The number of interposers could be reduced slightly by doing simple work > > like wait(), waitpid() and wait3() before instead of after > > interposition. This would be an additional change and the current patch > > is more like the existing code. > Could you, please, explain this ? What exactly should be done before what, > and how would it help ? In libc, define the below wait3(). All code in libc that allows libthr to interpose wait3() and in libthr that interposes wait3() can then go away. pid_t wait3(int *istat, int options, struct rusage *rup) { return (((pid_t (*)(pid_t, int *, int, struct rusage *)) __libc_interposing[INTERPOS_wait4])(WAIT_ANY, istat, options, rup)); } This change is also possible for wait() and waitpid(), but not for e.g. sigwait() which has different [EINTR] behaviour than sigtimedwait(). > > In lib/libc/sys/__error.c, __error_selector should be declared static or > > __hidden and an accessor function added for libthr, to avoid an > > additional pointer chase in a common path. One more PLT and GOT > > reference in some situations may be avoided by making a __hidden alias > > for __error_unthreaded and making that __error_selector's initial value. > __error_unthreaded can be made static, it seems. > I added __set_error_selector() and made __error_selector static. > > Although __libc_interposing is properly not exported (with > > __libc_interposing_slot accessor), the full benefit is not obtained > > because __libc_interposing is not declared __hidden in > > lib/libc/include/libc_private.h, so the compiler will generate an > > indirect access anyway (and ld will fix it up using a relative > > relocation). > Done. > > In lib/libthr/thread/thr_private.h, __error_threaded() can be declared > > __hidden. > Done. The changes look good to me. > > Sharing __sys_* code between libc and libthr is a net loss (the two > > copies of the name, GOT entry, PLT entry and longer instruction > > sequences are almost certainly larger than a syscall stub (32 bytes on > > amd64)), so I think the best fix for most indirection from > > __libc_interposing entries is to give libthr its own copy and mark both > > copies hidden, instead of adding hidden aliases now. > Do you mean linking syscall stubs (__sys_* trampolines) statically into > the libthr, and referencing them directly from the C code ? Yes, this > will be huge benefitial, both for libthr and ld-elf.so.1, for rtld it is > even kind of required, see r276646 and other uses of __sys. I thought > about it. But we need something like libsyscalls.a and libsyscalls_pic.a > extracted from libc first. > If I am misinterpreting your suggestion, please explain it in more > details. Your interpretation is correct. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 18:58:56 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C6E6FD; Sun, 4 Jan 2015 18:58:56 +0000 (UTC) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D718BC5; Sun, 4 Jan 2015 18:58:56 +0000 (UTC) Received: by mail-we0-f171.google.com with SMTP id u56so6828619wes.2; Sun, 04 Jan 2015 10:58:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lj6uNzZ5qyAiIDb22ODPg/1yflQdnaoZogrV9T//nDs=; b=p8rn4vJ0Yt9kiRQdfWpELDgollVxo2UdLbIU0MmpiRcAyzf65gIDPd/Sj9istgVqoP Bd3tHFrTk9W38/eaw4sTmCZTu0dR03UwgMUMiGtNe4w5j9qr4TM6I/Dg/pRa16D3Z6Ou +LwWCKhuWIZFb+D9DDzCYpPh6TtmxSlId9A/Xe7PS2KfVVAaT94SP9IzSP/uDr4I1voZ u6wsHu1p06dv7rlgtyEK7lzgkNNQiRW3b3Y1czrHongybP0ReDeerLPb9bZYcfK19NUF 8IW+geFCBdYngxbEoFuLL5PwIyXCKS7EpTbBKyL4D4cfIb3e1zlbKf/O7MNmS+XblT8E 2sLw== MIME-Version: 1.0 X-Received: by 10.194.5.37 with SMTP id p5mr50584701wjp.20.1420397934515; Sun, 04 Jan 2015 10:58:54 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Sun, 4 Jan 2015 10:58:54 -0800 (PST) In-Reply-To: <54A92ED1.2070906@selasky.org> References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> Date: Sun, 4 Jan 2015 10:58:54 -0800 X-Google-Sender-Auth: zPrMzqvbPxhpXxB-ysT2PDMSxIY Message-ID: Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress From: Adrian Chadd To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Ivan Klymenko , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 18:58:56 -0000 Hi! Can you throw this into reviews.freebsd.org please? This is something that should be very closely reviewed and tested. (I'm going to go over this quite closely as it related to a lot of the random crap I do ..) -adrian On 4 January 2015 at 04:15, Hans Petter Selasky wrote: > Hi, > > Please find attached an updated timeout patch which also updates clients in > the kernel area to use the callout API properly, like cv_timedwait(). > Previously there was some custom sleepqueue code in the callout subsystem. > All of that has now been removed and we allow callouts to be protected by > spinlocks. This allows us to tear down the callback like done with regular > mutexes, and a "td_slpmutex" has been added to "struct thread" to atomically > teardown the "td_slpcallout". Further the "TDF_TIMOFAIL" and > "SWT_SLEEPQTIMO" states can now be completely removed. > > Summary of changes: > > 1) Make consistent callout API which also supports spinlocks for the > callback function. This has been done to allow atomic callout stop of > "td_slpcallout" without the need of many kernel threading quirks. > > 2) It is not allowed to migrate CPU if the timeout is restarted while the > timeout callback is executing. Callouts must be stopped before CPU migration > is allowed. Optionally drained. > > 3) Shared lock support has been removed, because it prevents atomic stop of > the callback function. > > 4) A new API to drain callouts asynchronously has been added, called > "callout_drain_async()". > > Please test and report any errors! > > Patch applies to FreeBSD-11-current as of today. > > Thank you! > > --HPS > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 19:00:52 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 396373E8; Sun, 4 Jan 2015 19:00:52 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0038BFF; Sun, 4 Jan 2015 19:00:51 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so26400090wgg.5; Sun, 04 Jan 2015 11:00:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=r9Jjxl4IBQeMusxhS2QvouJHSLOShUwuWSjeAieLjpU=; b=Q91lWExQMe09Vzn7uL1vG9IIv9noofo4QyylXYARcuzsC9COj6kqZhBcJKghg1Uti8 vkXmS9A+nleU4fw0ZBenH6FyhGtzCUpfOXNH2oo+uO0qDlqu5e190JvqgE3rYvwsvPht dzeOx5nxm+xJVwwvmB52WPp10U+0mMpj1dltPCfnVtFFoirjg9hbVyXp070IXJZnvZG3 Qsh6i9r1XUsXHcl8iScYKeOfVAM5aAX+cWnv+Uo7aiEvSJuKbplx86Vvi17qSyezUZ2R y2XkIYKwsMLYAkgXERuhLTJE2XID5eBuZslFpXioqXH5VR7SUKyM9OKbhmLJjt32heiF E/YQ== MIME-Version: 1.0 X-Received: by 10.180.14.136 with SMTP id p8mr18159102wic.20.1420398050052; Sun, 04 Jan 2015 11:00:50 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Sun, 4 Jan 2015 11:00:49 -0800 (PST) In-Reply-To: References: Date: Sun, 4 Jan 2015 11:00:49 -0800 X-Google-Sender-Auth: SmBt7x2ob9AwSZZGjIXV4ldzyeA Message-ID: Subject: Re: [CFT] Paravirtualized KVM clock From: Adrian Chadd To: Bryan Venteicher Content-Type: text/plain; charset=UTF-8 Cc: FreeBSD-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 19:00:52 -0000 ... so, out of pure curiousity - what's making the benchmark go faster? Is it userland side of things calling clock methods, or something in the kernel, or both? -adrian On 4 January 2015 at 09:56, Bryan Venteicher wrote: > For the last few weeks, I've been working on adding support for KVM clock > in the projects/paravirt branch. Currently, a KVM VM guest will end up > selecting either the HPET or ACPI as the timecounter source. Unfortunately, > this is very costly since every timecounter fetch causes a VM exit. KVM > clock allows the guest to use the TSC instead; it is very similar to the > existing Xen timer. > > The performance difference between HPET/ACPI and KVMCLOCK can be dramatic: > a simple disk benchmark goes from 10K IOPs to 100K IOPs. > > The patch is attached is attached or available at [1]. I'd appreciate any > testing. > > Also as a part of this, I've tried to generalized a bit of our existing > hypervisor guest code, with the eventual goal of being able to support more > invasive PV operations. The patch series is viewable in Phabricator. > > https://reviews.freebsd.org/D1429 - paravirt: Generalize parts of the XEN > timer code into pvclock > https://reviews.freebsd.org/D1430 - paravirt: Add interface to calculate > the TSC frequency from pvclock > https://reviews.freebsd.org/D1431 - paravirt: Add simple hypervisor > registration and detection interface > https://reviews.freebsd.org/D1432 - paravirt: Add detection of bhyve using > new hypervisor interface > https://reviews.freebsd.org/D1433 - paravirt: Add detection of VMware using > new hypervisor interface > https://reviews.freebsd.org/D1434 - paravirt: Add detection of KVM using > new hypervisor interface > https://reviews.freebsd.org/D1435 - paravirt: Add KVM clock timecounter > support > > My current plan is to MFC this series to 10-STABLE, and commit a > self-contained KVM clock to the other stable branches. > > [1] - https://people.freebsd.org/~bryanv/patches/kvm_clock-1.patch > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 20:47:45 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A276DE15; Sun, 4 Jan 2015 20:47:45 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6031C64C8E; Sun, 4 Jan 2015 20:47:45 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 21E3D1FE022; Sun, 4 Jan 2015 21:47:43 +0100 (CET) Message-ID: <54A9A71E.70609@selasky.org> Date: Sun, 04 Jan 2015 21:48:30 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Ivan Klymenko , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 20:47:45 -0000 On 01/04/15 19:58, Adrian Chadd wrote: > Hi! > > Can you throw this into reviews.freebsd.org please? This is something > that should be very closely reviewed and tested. > > (I'm going to go over this quite closely as it related to a lot of the > random crap I do ..) > Hi Adrian, Here you go: https://reviews.freebsd.org/D1438 Thank you for your time to review this! --HPS From owner-freebsd-arch@FreeBSD.ORG Sun Jan 4 22:27:04 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98D2D8B8; Sun, 4 Jan 2015 22:27:04 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0114.outbound.protection.outlook.com [207.46.100.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BA252CE5; Sun, 4 Jan 2015 22:27:03 +0000 (UTC) Received: from BY2PR05CA058.namprd05.prod.outlook.com (10.141.250.48) by CO1PR05MB442.namprd05.prod.outlook.com (10.141.73.146) with Microsoft SMTP Server (TLS) id 15.1.49.12; Sun, 4 Jan 2015 22:27:01 +0000 Received: from BY2FFO11FD060.protection.gbl (2a01:111:f400:7c0c::105) by BY2PR05CA058.outlook.office365.com (2a01:111:e400:2c5f::48) with Microsoft SMTP Server (TLS) id 15.1.49.12 via Frontend Transport; Sun, 4 Jan 2015 22:27:00 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD060.mail.protection.outlook.com (10.1.15.184) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Sun, 4 Jan 2015 22:27:00 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 4 Jan 2015 14:27:00 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t04MQwW33110; Sun, 4 Jan 2015 14:26:58 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t04MQgfr085769; Sun, 4 Jan 2015 17:26:43 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201501042226.t04MQgfr085769@idle.juniper.net> To: Alfred Perlstein Subject: Re: Libxo bugs and fixes. In-Reply-To: <54A8CEDA.4020902@freebsd.org> Date: Sun, 4 Jan 2015 17:26:42 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(189002)(24454002)(377454003)(164054003)(479174004)(199003)(6806004)(50466002)(69596002)(46102003)(120916001)(99396003)(87936001)(2950100001)(48376002)(62966003)(77156002)(21056001)(54356999)(84676001)(77096005)(50986999)(76506005)(53416004)(97736003)(68736005)(110136001)(64706001)(20776003)(31966008)(47776003)(4396001)(107046002)(105596002)(81156004)(106466001)(86362001)(92566001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB442; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR05MB442; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:CO1PR05MB442; X-Forefront-PRVS: 0446F0FCE1 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB442; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jan 2015 22:27:00.5825 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB442 Cc: Marcel Moolenaar , John-Mark Gurney , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 22:27:04 -0000 Alfred Perlstein writes: >On 1/3/15 9:05 PM, Phil Shafer wrote: >> I dislike using a non-standard function like this. I'd prefer the >> caller flag this information on the handle. There's already a flag >> one can set on a handle that will trigger a call to flush data >> buffered in the handle to the write function. I'll add a function >> to set a custom flusher, which will be called at appropriate times. >> Apps like netstat will know if they need iterative output, and can >> decide to set the XOF_FLUSH flag with a flusher callback. If needed, >> that callback can use __flbf. We considering this: given that the caller knows when it wants to fflush(stdout) and libxo doesn't, it seems we'd be better served having the app do something like: for (;;) { xo_open_instance("foo"); ... xo_close_instance("foo"); xo_flush(); /* Flush data buffersd in libxo */ if (__flbf(stdout)) fflush(stdout); /* Flush data buffered in stdio */ } xo_flush flushes the data that libxo is buffering in the handle, which is used to avoid making malformed XML and JSON content. Then fflush can push that data out if needed. The XOF_FLUSH flushes data after every call from the xo handle to the underlaying opaque stream; putting a flush at that point would likely be overkill. >I think we just need a "cork/uncork" sort of api that will make it a >single line? I can make a flag to push container and list names as they are opened, so a function can close, add an inter-record string (a NL for NLDJSON), and reopen the tags. Since I have the keys, I could add those also. Thanks, Phil From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 00:04:34 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FB9DA7C; Mon, 5 Jan 2015 00:04:34 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6B1DA2A08; Mon, 5 Jan 2015 00:04:34 +0000 (UTC) Received: from [10.0.1.110] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 31A6F341F88A; Sun, 4 Jan 2015 16:04:28 -0800 (PST) Subject: Re: Libxo bugs and fixes. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alfred Perlstein In-Reply-To: <201501042226.t04MQgfr085769@idle.juniper.net> Date: Sun, 4 Jan 2015 16:08:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <31BE601E-1D52-42FE-92FC-4610D0250A20@freebsd.org> References: <201501042226.t04MQgfr085769@idle.juniper.net> To: Phil Shafer X-Mailer: Apple Mail (2.1283) Cc: Marcel Moolenaar , John-Mark Gurney , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 00:04:34 -0000 On Jan 4, 2015, at 2:26 PM, Phil Shafer wrote: > Alfred Perlstein writes: >> On 1/3/15 9:05 PM, Phil Shafer wrote: >>> I dislike using a non-standard function like this. I'd prefer the >>> caller flag this information on the handle. There's already a flag >>> one can set on a handle that will trigger a call to flush data >>> buffered in the handle to the write function. I'll add a function >>> to set a custom flusher, which will be called at appropriate times. >>> Apps like netstat will know if they need iterative output, and can >>> decide to set the XOF_FLUSH flag with a flusher callback. If = needed, >>> that callback can use __flbf. >=20 > We considering this: given that the caller knows when it wants to > fflush(stdout) and libxo doesn't, it seems we'd be better served > having the app do something like: >=20 > for (;;) { > xo_open_instance("foo"); > ... > xo_close_instance("foo"); > xo_flush(); /* Flush data buffersd in libxo */ > if (__flbf(stdout)) > fflush(stdout); /* Flush data buffered in stdio */ > } That api=85 could it not be better? Also, won't it be fully buffered = when it's to a pipe to another program? I think I messed that up. We = probably want actually if !__flbf() I think which for non-buffered will = cause a nop-fflush but for fully buffered will do an actual flush. I think we REALLY want to have the fflush be a callback offered by = libxo, otherwise the layering violations are pretty difficult to deal = with. Consider if libxo is outputting to a non-stdio buffer, then what = is the paradigm? Is it not better to give libxo a "flush" callback and = have that exposed via the xop interface? >=20 > xo_flush flushes the data that libxo is buffering in the handle, > which is used to avoid making malformed XML and JSON content. > Then fflush can push that data out if needed. >=20 > The XOF_FLUSH flushes data after every call from the xo handle to > the underlaying opaque stream; putting a flush at that point would > likely be overkill. >=20 >> I think we just need a "cork/uncork" sort of api that will make it a=20= >> single line? >=20 > I can make a flag to push container and list names as they are opened, > so a function can close, add an inter-record string (a NL for = NLDJSON), > and reopen the tags. Since I have the keys, I could add those also. That sounds awesome.= From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 00:33:31 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11DB13ED; Mon, 5 Jan 2015 00:33:31 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0138.outbound.protection.outlook.com [207.46.100.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 76A902F98; Mon, 5 Jan 2015 00:33:29 +0000 (UTC) Received: from CO2PR05CA018.namprd05.prod.outlook.com (10.141.241.146) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 00:33:28 +0000 Received: from BY2FFO11FD004.protection.gbl (2a01:111:f400:7c0c::182) by CO2PR05CA018.outlook.office365.com (2a01:111:e400:1429::18) with Microsoft SMTP Server (TLS) id 15.1.49.12 via Frontend Transport; Mon, 5 Jan 2015 00:33:27 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD004.mail.protection.outlook.com (10.1.14.158) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Mon, 5 Jan 2015 00:33:26 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 4 Jan 2015 16:33:26 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t050XOW90219; Sun, 4 Jan 2015 16:33:24 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t050X9L5086220; Sun, 4 Jan 2015 19:33:09 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201501050033.t050X9L5086220@idle.juniper.net> To: Alfred Perlstein Subject: Re: Libxo bugs and fixes. In-Reply-To: <31BE601E-1D52-42FE-92FC-4610D0250A20@freebsd.org> Date: Sun, 4 Jan 2015 19:33:09 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(164054003)(2950100001)(81156004)(64706001)(20776003)(47776003)(110136001)(68736005)(77096005)(99396003)(86362001)(31966008)(62966003)(120916001)(92566001)(106466001)(53416004)(4396001)(107046002)(6806004)(69596002)(54356999)(105596002)(50986999)(87936001)(84676001)(46102003)(97736003)(76506005)(77156002)(21056001)(50466002)(48376002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BN1PR05MB440; X-Forefront-PRVS: 0447DB1C71 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2015 00:33:26.8382 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Cc: Marcel Moolenaar , John-Mark Gurney , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 00:33:31 -0000 Alfred Perlstein writes: >I think we REALLY want to have the fflush be a callback offered by libxo, otherwise the >layering violations are pretty difficult to deal with. Consider if libxo is outputting >to a non-stdio buffer, then what is the paradigm? Is it not better to give libxo a "flu >sh" callback and have that exposed via the xop interface? The problem is divining when to flush. If you are whiffling thru a list, does the app want to flush after each list member, or when the complete list is done. Or maybe you are just looking at the case when pretty output is made to the terminal? Thanks, Phil From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 00:52:27 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B54307B6; Mon, 5 Jan 2015 00:52:27 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id A03E4325E; Mon, 5 Jan 2015 00:52:27 +0000 (UTC) Received: from [10.0.1.106] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id 51003341F88A; Sun, 4 Jan 2015 16:52:27 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Libxo bugs and fixes. From: Alfred Perlstein X-Mailer: iPhone Mail (12B440) In-Reply-To: <201501050033.t050X9L5086220@idle.juniper.net> Date: Sun, 4 Jan 2015 16:52:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201501050033.t050X9L5086220@idle.juniper.net> To: Phil Shafer Cc: Marcel Moolenaar , John-Mark Gurney , Alfred Perlstein , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 00:52:27 -0000 > On Jan 4, 2015, at 4:33 PM, Phil Shafer wrote: >=20 > Alfred Perlstein writes: >> I think we REALLY want to have the fflush be a callback offered by libxo,= otherwise the=20 >> layering violations are pretty difficult to deal with. Consider if libxo= is outputting=20 >> to a non-stdio buffer, then what is the paradigm? Is it not better to gi= ve libxo a "flu >> sh" callback and have that exposed via the xop interface? >=20 > The problem is divining when to flush. If you are whiffling thru a list, > does the app want to flush after each list member, or when the complete > list is done. >=20 > Or maybe you are just looking at the case when pretty output > is made to the terminal? I am more thinking of the case where you pass a libxo handle down to a subsy= stem that shouldn't have to know if it is a studio object or not.=20 Consider the code sample you gave me, but instead of using the handleless ve= rsion xo_flush() you are writing a routine that takes a handle so instead yo= u would be calling xo_flush_h().=20 In the case of xo_flush_h() how does a subroutine know how to flush the back= ing object of the handle? -ap=20 From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 02:01:20 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8AC4D903; Mon, 5 Jan 2015 02:01:20 +0000 (UTC) Received: from mail-vc0-x22e.google.com (mail-vc0-x22e.google.com [IPv6:2607:f8b0:400c:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 339A964C84; Mon, 5 Jan 2015 02:01:20 +0000 (UTC) Received: by mail-vc0-f174.google.com with SMTP id id10so8066973vcb.19; Sun, 04 Jan 2015 18:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t7rMM6MMyKZFrTvYCUE4IflJQSpSfmYn1gqwyUyMM0Q=; b=NZ9E4zhnSxuttyW0aweyKKsFLYBL/8uso8gWUqhvSJsV80nwCHAmFio/hlS4IPM0Fc xeGZBY5qU+VoA8Nj60gTLyonAL4B7n8GRVvkrP05yhVpTUkpGkkk2ZYR2FMKq/DGa/Lz L11fSk/4BXFjugEyv6u0LygRotfAZCsmi9YApIZKrNcsPxiuPmRLStRQE1b9Z2bKWxGk Ji48urfh+s8iQtb1gHtQMFd+GN6nfmLMR/j3yHg4N6x1ohzQf3P5KarMpxooaoJrGzqm 9FkJVn20qJYcrYqEVk+ZhyNHXcM1ucGLrrix+NYBq8EXEwNhF08HOtFBTEp04p+11cEi r+Cw== MIME-Version: 1.0 X-Received: by 10.52.66.200 with SMTP id h8mr46352692vdt.97.1420423279034; Sun, 04 Jan 2015 18:01:19 -0800 (PST) Received: by 10.52.117.108 with HTTP; Sun, 4 Jan 2015 18:01:18 -0800 (PST) In-Reply-To: References: Date: Sun, 4 Jan 2015 19:01:18 -0700 Message-ID: Subject: Re: [CFT] Paravirtualized KVM clock From: Jim Harris To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: FreeBSD-current , Bryan Venteicher , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 02:01:20 -0000 On Sun, Jan 4, 2015 at 12:00 PM, Adrian Chadd wrote: > ... so, out of pure curiousity - what's making the benchmark go > faster? Is it userland side of things calling clock methods, or > something in the kernel, or both? > > Most likely GEOM statistic gathering in the kernel but Bryan would have to confirm. I intermittently saw this same kind of massive slowdown in nvme(4) performance a couple of years back due to a bug in the TSC self-check code which has since been fixed. The bug would result in falling back to HPET and all of the clock calls from the GEOM code for each I/O would kill performance. > > -adrian > > > On 4 January 2015 at 09:56, Bryan Venteicher > wrote: > > For the last few weeks, I've been working on adding support for KVM clock > > in the projects/paravirt branch. Currently, a KVM VM guest will end up > > selecting either the HPET or ACPI as the timecounter source. > Unfortunately, > > this is very costly since every timecounter fetch causes a VM exit. KVM > > clock allows the guest to use the TSC instead; it is very similar to the > > existing Xen timer. > > > > The performance difference between HPET/ACPI and KVMCLOCK can be > dramatic: > > a simple disk benchmark goes from 10K IOPs to 100K IOPs. > > > > The patch is attached is attached or available at [1]. I'd appreciate any > > testing. > > > > Also as a part of this, I've tried to generalized a bit of our existing > > hypervisor guest code, with the eventual goal of being able to support > more > > invasive PV operations. The patch series is viewable in Phabricator. > > > > https://reviews.freebsd.org/D1429 - paravirt: Generalize parts of the > XEN > > timer code into pvclock > > https://reviews.freebsd.org/D1430 - paravirt: Add interface to calculate > > the TSC frequency from pvclock > > https://reviews.freebsd.org/D1431 - paravirt: Add simple hypervisor > > registration and detection interface > > https://reviews.freebsd.org/D1432 - paravirt: Add detection of bhyve > using > > new hypervisor interface > > https://reviews.freebsd.org/D1433 - paravirt: Add detection of VMware > using > > new hypervisor interface > > https://reviews.freebsd.org/D1434 - paravirt: Add detection of KVM using > > new hypervisor interface > > https://reviews.freebsd.org/D1435 - paravirt: Add KVM clock timecounter > > support > > > > My current plan is to MFC this series to 10-STABLE, and commit a > > self-contained KVM clock to the other stable branches. > > > > [1] - https://people.freebsd.org/~bryanv/patches/kvm_clock-1.patch > > > > _______________________________________________ > > freebsd-arch@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 02:07:27 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42899C41; Mon, 5 Jan 2015 02:07:27 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0122.outbound.protection.outlook.com [65.55.169.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8A1B64DFD; Mon, 5 Jan 2015 02:07:25 +0000 (UTC) Received: from CO2PR05CA033.namprd05.prod.outlook.com (10.141.241.161) by BLUPR05MB436.namprd05.prod.outlook.com (10.141.27.152) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 5 Jan 2015 02:07:23 +0000 Received: from BY2FFO11FD049.protection.gbl (2a01:111:f400:7c0c::122) by CO2PR05CA033.outlook.office365.com (2a01:111:e400:1429::33) with Microsoft SMTP Server (TLS) id 15.1.49.12 via Frontend Transport; Mon, 5 Jan 2015 02:07:22 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD049.mail.protection.outlook.com (10.1.15.186) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Mon, 5 Jan 2015 02:07:23 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 4 Jan 2015 18:07:22 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t0527KW33267; Sun, 4 Jan 2015 18:07:20 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t05274U2086589; Sun, 4 Jan 2015 21:07:05 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201501050207.t05274U2086589@idle.juniper.net> To: Alfred Perlstein Subject: Re: Libxo bugs and fixes. In-Reply-To: Date: Sun, 4 Jan 2015 21:07:04 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(164054003)(84676001)(50986999)(54356999)(53416004)(69596002)(76506005)(6806004)(92566001)(21056001)(97736003)(105596002)(86362001)(107046002)(46102003)(31966008)(106466001)(81156004)(87936001)(4396001)(47776003)(20776003)(64706001)(2950100001)(62966003)(110136001)(48376002)(68736005)(77156002)(50466002)(99396003)(77096005)(120916001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB436; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BLUPR05MB436; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB436; X-Forefront-PRVS: 0447DB1C71 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB436; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Jan 2015 02:07:23.1260 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB436 Cc: Marcel Moolenaar , John-Mark Gurney , Alfred Perlstein , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 02:07:27 -0000 Alfred Perlstein writes: >In the case of xo_flush_h() how does a subroutine know how to flush the backing object o >f the handle? Okay, I buy the argument that calling xo_flush should trigger a flush all the way down the stack. The app should be able to call xo_flush when it matters to the app, and the result should be a complete flush of output. Will get it working. Thanks, Phil From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 02:37:17 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DBC6100; Mon, 5 Jan 2015 02:37:17 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4DB21225; Mon, 5 Jan 2015 02:37:16 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t052b8Xr026926 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Jan 2015 04:37:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t052b8Xr026926 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t052b8A7026925; Mon, 5 Jan 2015 04:37:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Jan 2015 04:37:08 +0200 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: Fixing dlopen("libpthread.so") Message-ID: <20150105023708.GD42409@kib.kiev.ua> References: <20141226165337.GJ1754@kib.kiev.ua> <20150103212837.GC46373@stack.nl> <20150104114600.GC42409@kib.kiev.ua> <20150104182026.GA61250@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150104182026.GA61250@stack.nl> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: threads@freebsd.org, arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 02:37:17 -0000 On Sun, Jan 04, 2015 at 07:20:27PM +0100, Jilles Tjoelker wrote: > In libc, define the below wait3(). All code in libc that allows libthr to > interpose wait3() and in libthr that interposes wait3() can then go > away. > > pid_t > wait3(int *istat, int options, struct rusage *rup) > { > > return (((pid_t (*)(pid_t, int *, int, struct rusage *)) > __libc_interposing[INTERPOS_wait4])(WAIT_ANY, istat, options, rup)); > } > > This change is also possible for wait() and waitpid(), but not for e.g. > sigwait() which has different [EINTR] behaviour than sigtimedwait(). > Ok, I did the pass over all such thin wrappers. The list is accept <- calls accept4 now creat \ open <- openat pause <- there were actual bugs, pause called _sigprocmask and _sigsuspend raise <- I converted it to threaded kill sleep <- this one is tricky, but seems to work usleep wait wait3 waitpid Patch is below. > The changes look good to me. Next natural question is about the __error calls through PLT in the .cerror asm. Before the work was committed, libthr interposed __error, which was required for correct operation. Now, we need __error exported, but do we need support its interposing ? This is an implementation detail for errno, I do not see any loss from not allowing to override errno location. diff --git a/lib/libc/compat-43/Symbol.map b/lib/libc/compat-43/Symbol.map index 2827705..bd49f99 100644 --- a/lib/libc/compat-43/Symbol.map +++ b/lib/libc/compat-43/Symbol.map @@ -28,5 +28,4 @@ FBSD_1.2 { FBSDprivate_1.0 { __creat; _creat; - __libc_creat; }; diff --git a/lib/libc/compat-43/creat.c b/lib/libc/compat-43/creat.c index 5ee4531..4545482 100644 --- a/lib/libc/compat-43/creat.c +++ b/lib/libc/compat-43/creat.c @@ -38,21 +38,16 @@ __FBSDID("$FreeBSD$"); #include "un-namespace.h" #include "libc_private.h" -__weak_reference(__libc_creat, __creat); -__weak_reference(__libc_creat, _creat); +__weak_reference(__creat, creat); +__weak_reference(__creat, _creat); #pragma weak creat int -creat(const char *path, mode_t mode) +__creat(const char *path, mode_t mode) { - return (((int (*)(const char *, mode_t)) - __libc_interposing[INTERPOS_creat])(path, mode)); + return (((int (*)(int, const char *, int, ...)) + __libc_interposing[INTERPOS_openat])(AT_FDCWD, path, O_WRONLY | + O_CREAT | O_TRUNC, mode)); } -int -__libc_creat(const char *path, mode_t mode) -{ - - return(__sys_open(path, O_WRONLY | O_CREAT | O_TRUNC, mode)); -} diff --git a/lib/libc/gen/Symbol.map b/lib/libc/gen/Symbol.map index e01a897..ee4d619 100644 --- a/lib/libc/gen/Symbol.map +++ b/lib/libc/gen/Symbol.map @@ -533,14 +533,7 @@ FBSDprivate_1.0 { _libc_sem_post_compat; _libc_sem_getvalue_compat; - __libc_pause; - __libc_raise; - __libc_sleep; __libc_tcdrain; - __libc_usleep; - __libc_wait; - __libc_wait3; - __libc_waitpid; __elf_aux_vector; __pthread_map_stacks_exec; diff --git a/lib/libc/gen/pause.c b/lib/libc/gen/pause.c index 97fbb01..ef48c1c 100644 --- a/lib/libc/gen/pause.c +++ b/lib/libc/gen/pause.c @@ -33,10 +33,8 @@ static char sccsid[] = "@(#)pause.c 8.1 (Berkeley) 6/4/93"; #include __FBSDID("$FreeBSD$"); -#include "namespace.h" #include #include -#include "un-namespace.h" #include "libc_private.h" @@ -44,23 +42,14 @@ __FBSDID("$FreeBSD$"); * Backwards compatible pause. */ int -__libc_pause(void) +__pause(void) { sigset_t oset; - if (_sigprocmask(SIG_BLOCK, NULL, &oset) == -1) + if (sigprocmask(SIG_BLOCK, NULL, &oset) == -1) return (-1); - return (_sigsuspend(&oset)); + return (sigsuspend(&oset)); } -#pragma weak pause -int -pause(void) -{ - - return (((int (*)(void)) - __libc_interposing[INTERPOS_pause])()); -} - -__weak_reference(__libc_pause, __pause); -__weak_reference(__libc_pause, _pause); +__weak_reference(__pause, pause); +__weak_reference(__pause, _pause); diff --git a/lib/libc/gen/raise.c b/lib/libc/gen/raise.c index d605639..994fea5 100644 --- a/lib/libc/gen/raise.c +++ b/lib/libc/gen/raise.c @@ -38,21 +38,15 @@ __FBSDID("$FreeBSD$"); #include "libc_private.h" -__weak_reference(__libc_raise, __raise); -__weak_reference(__libc_raise, _raise); +__weak_reference(__raise, raise); +__weak_reference(__raise, _raise); -#pragma weak raise int -raise(int s) +__raise(int s) { + long id; - return (((int (*)(int)) - __libc_interposing[INTERPOS_raise])(s)); -} - -int -__libc_raise(int s) -{ - - return (kill(getpid(), s)); + if (__sys_thr_self(&id) == -1) + return (-1); + return (__sys_thr_kill(id, s)); } diff --git a/lib/libc/gen/sleep.c b/lib/libc/gen/sleep.c index f558e36..6bb4ecd 100644 --- a/lib/libc/gen/sleep.c +++ b/lib/libc/gen/sleep.c @@ -42,17 +42,8 @@ __FBSDID("$FreeBSD$"); #include "libc_private.h" -#pragma weak sleep unsigned int -sleep(unsigned int seconds) -{ - - return (((unsigned int (*)(unsigned int)) - __libc_interposing[INTERPOS_sleep])(seconds)); -} - -unsigned int -__libc_sleep(unsigned int seconds) +__sleep(unsigned int seconds) { struct timespec time_to_sleep; struct timespec time_remaining; @@ -62,17 +53,19 @@ __libc_sleep(unsigned int seconds) * the maximum value for a time_t is >= INT_MAX. */ if (seconds > INT_MAX) - return (seconds - INT_MAX + __libc_sleep(INT_MAX)); + return (seconds - INT_MAX + __sleep(INT_MAX)); time_to_sleep.tv_sec = seconds; time_to_sleep.tv_nsec = 0; - if (_nanosleep(&time_to_sleep, &time_remaining) != -1) + if (((int (*)(const struct timespec *, struct timespec *)) + __libc_interposing[INTERPOS_nanosleep])( + &time_to_sleep, &time_remaining) != -1) return (0); if (errno != EINTR) return (seconds); /* best guess */ return (time_remaining.tv_sec + - (time_remaining.tv_nsec != 0)); /* round up */ + (time_remaining.tv_nsec != 0)); /* round up */ } -__weak_reference(__libc_sleep, __sleep); -__weak_reference(__libc_sleep, _sleep); +__weak_reference(__sleep, sleep); +__weak_reference(__sleep, _sleep); diff --git a/lib/libc/gen/usleep.c b/lib/libc/gen/usleep.c index 1d58b98..7c35f6c 100644 --- a/lib/libc/gen/usleep.c +++ b/lib/libc/gen/usleep.c @@ -40,24 +40,16 @@ __FBSDID("$FreeBSD$"); #include "libc_private.h" -#pragma weak usleep int -usleep(useconds_t useconds) -{ - - return (((int (*)(useconds_t)) - __libc_interposing[INTERPOS_usleep])(useconds)); -} - -int -__libc_usleep(useconds_t useconds) +__usleep(useconds_t useconds) { struct timespec time_to_sleep; time_to_sleep.tv_nsec = (useconds % 1000000) * 1000; time_to_sleep.tv_sec = useconds / 1000000; - return (_nanosleep(&time_to_sleep, NULL)); + return (((int (*)(const struct timespec *, struct timespec *)) + __libc_interposing[INTERPOS_nanosleep])(&time_to_sleep, NULL)); } -__weak_reference(__libc_usleep, __usleep); -__weak_reference(__libc_usleep, _usleep); +__weak_reference(__usleep, usleep); +__weak_reference(__usleep, _usleep); diff --git a/lib/libc/gen/wait.c b/lib/libc/gen/wait.c index dc1351d..46a3fdd 100644 --- a/lib/libc/gen/wait.c +++ b/lib/libc/gen/wait.c @@ -42,21 +42,13 @@ __FBSDID("$FreeBSD$"); #include "libc_private.h" -#pragma weak wait pid_t -wait(int *istat) +__wait(int *istat) { - return (((pid_t (*)(int *)) - __libc_interposing[INTERPOS_wait])(istat)); + return (((pid_t (*)(pid_t, int *, int, struct rusage *)) + __libc_interposing[INTERPOS_wait4])(WAIT_ANY, istat, 0, NULL)); } -pid_t -__libc_wait(int *istat) -{ - - return (__sys_wait4(WAIT_ANY, istat, 0, NULL)); -} - -__weak_reference(__libc_wait, __wait); -__weak_reference(__libc_wait, _wait); +__weak_reference(__wait, wait); +__weak_reference(__wait, _wait); diff --git a/lib/libc/gen/wait3.c b/lib/libc/gen/wait3.c index 2e116be..965effe 100644 --- a/lib/libc/gen/wait3.c +++ b/lib/libc/gen/wait3.c @@ -42,20 +42,12 @@ __FBSDID("$FreeBSD$"); #include "libc_private.h" -#pragma weak wait3 pid_t -wait3(int *istat, int options, struct rusage *rup) +__wait3(int *istat, int options, struct rusage *rup) { - return (((pid_t (*)(int *, int, struct rusage *)) - __libc_interposing[INTERPOS_wait3])(istat, options, rup)); + return (((pid_t (*)(pid_t, int *, int, struct rusage *)) + __libc_interposing[INTERPOS_wait4])(WAIT_ANY, istat, options, rup)); } -__weak_reference(__libc_wait3, __wait3); - -pid_t -__libc_wait3(int *istat, int options, struct rusage *rup) -{ - - return (__sys_wait4(WAIT_ANY, istat, options, rup)); -} +__weak_reference(__wait3, wait3); diff --git a/lib/libc/gen/waitpid.c b/lib/libc/gen/waitpid.c index 27e920f..5177591 100644 --- a/lib/libc/gen/waitpid.c +++ b/lib/libc/gen/waitpid.c @@ -42,21 +42,13 @@ __FBSDID("$FreeBSD$"); #include "libc_private.h" -#pragma weak waitpid pid_t -waitpid(pid_t pid, int *istat, int options) +__waitpid(pid_t pid, int *istat, int options) { - return (((pid_t (*)(pid_t, int *, int)) - __libc_interposing[INTERPOS_waitpid])(pid, istat, options)); + return (((pid_t (*)(pid_t, int *, int, struct rusage *)) + __libc_interposing[INTERPOS_wait4])(pid, istat, options, NULL)); } -pid_t -__libc_waitpid(pid_t pid, int *istat, int options) -{ - - return (__sys_wait4(pid, istat, options, NULL)); -} - -__weak_reference(__libc_waitpid, __waitpid); -__weak_reference(__libc_waitpid, _waitpid); +__weak_reference(__waitpid, waitpid); +__weak_reference(__waitpid, _waitpid); diff --git a/lib/libc/include/libc_private.h b/lib/libc/include/libc_private.h index ea1a97b..b698553 100644 --- a/lib/libc/include/libc_private.h +++ b/lib/libc/include/libc_private.h @@ -182,22 +182,18 @@ interpos_func_t *__libc_interposing_slot(int interposno); extern interpos_func_t __libc_interposing[] __hidden; enum { - INTERPOS_accept, INTERPOS_accept4, INTERPOS_aio_suspend, INTERPOS_close, INTERPOS_connect, - INTERPOS_creat, INTERPOS_fcntl, INTERPOS_fsync, INTERPOS_fork, INTERPOS_msync, INTERPOS_nanosleep, - INTERPOS_open, INTERPOS_openat, INTERPOS_poll, INTERPOS_pselect, - INTERPOS_raise, INTERPOS_recvfrom, INTERPOS_recvmsg, INTERPOS_select, @@ -212,16 +208,10 @@ enum { INTERPOS_sigwaitinfo, INTERPOS_swapcontext, INTERPOS_system, - INTERPOS_sleep, INTERPOS_tcdrain, - INTERPOS_usleep, - INTERPOS_pause, INTERPOS_read, INTERPOS_readv, - INTERPOS_wait, - INTERPOS_wait3, INTERPOS_wait4, - INTERPOS_waitpid, INTERPOS_write, INTERPOS_writev, INTERPOS__pthread_mutex_init_calloc_cb, @@ -353,23 +343,17 @@ int __sys_sigwait(const __sigset_t *, int *); int __sys_sigwaitinfo(const __sigset_t *, struct __siginfo *); int __sys_swapcontext(struct __ucontext *, const struct __ucontext *); +int __sys_thr_kill(long, int); +int __sys_thr_self(long *); int __sys_truncate(const char *, __off_t); __pid_t __sys_wait4(__pid_t, int *, int, struct rusage *); __ssize_t __sys_write(int, const void *, __size_t); __ssize_t __sys_writev(int, const struct iovec *, int); -int __libc_creat(const char *path, __mode_t mode); -int __libc_pause(void); -int __libc_raise(int); int __libc_sigwait(const __sigset_t * __restrict, int * restrict sig); int __libc_system(const char *); -unsigned int __libc_sleep(unsigned int); int __libc_tcdrain(int); -int __libc_usleep(__useconds_t); -__pid_t __libc_wait(int *); -__pid_t __libc_wait3(int *, int, struct rusage *); -__pid_t __libc_waitpid(__pid_t, int *, int); int __fcntl_compat(int fd, int cmd, ...); /* execve() with PATH processing to implement posix_spawnp() */ diff --git a/lib/libc/sys/accept.c b/lib/libc/sys/accept.c index 38e32f2..8fb945f 100644 --- a/lib/libc/sys/accept.c +++ b/lib/libc/sys/accept.c @@ -38,13 +38,13 @@ __FBSDID("$FreeBSD$"); #include #include "libc_private.h" -__weak_reference(__sys_accept, __accept); +__weak_reference(__accept, accept); #pragma weak accept int -accept(int s, struct sockaddr *addr, socklen_t *addrlen) +__accept(int s, struct sockaddr *addr, socklen_t *addrlen) { - return (((int (*)(int, struct sockaddr *, socklen_t *)) - __libc_interposing[INTERPOS_accept])(s, addr, addrlen)); + return (((int (*)(int, struct sockaddr *, socklen_t *, int)) + __libc_interposing[INTERPOS_accept4])(s, addr, addrlen, 0)); } diff --git a/lib/libc/sys/interposing_table.c b/lib/libc/sys/interposing_table.c index 9987bf0..10d56fd 100644 --- a/lib/libc/sys/interposing_table.c +++ b/lib/libc/sys/interposing_table.c @@ -39,22 +39,18 @@ __FBSDID("$FreeBSD$"); #define SLOT(a, b) \ [INTERPOS_##a] = (interpos_func_t)b interpos_func_t __libc_interposing[INTERPOS_MAX] = { - SLOT(accept, __sys_accept), SLOT(accept4, __sys_accept4), SLOT(aio_suspend, __sys_aio_suspend), SLOT(close, __sys_close), SLOT(connect, __sys_connect), - SLOT(creat, __libc_creat), SLOT(fcntl, __fcntl_compat), SLOT(fsync, __sys_fsync), SLOT(fork, __sys_fork), SLOT(msync, __sys_msync), SLOT(nanosleep, __sys_nanosleep), - SLOT(open, __sys_open), SLOT(openat, __sys_openat), SLOT(poll, __sys_poll), SLOT(pselect, __sys_pselect), - SLOT(raise, __libc_raise), SLOT(read, __sys_read), SLOT(readv, __sys_readv), SLOT(recvfrom, __sys_recvfrom), @@ -71,14 +67,8 @@ interpos_func_t __libc_interposing[INTERPOS_MAX] = { SLOT(sigwaitinfo, __sys_sigwaitinfo), SLOT(swapcontext, __sys_swapcontext), SLOT(system, __libc_system), - SLOT(sleep, __libc_sleep), SLOT(tcdrain, __libc_tcdrain), - SLOT(usleep, __libc_usleep), - SLOT(pause, __libc_pause), - SLOT(wait, __libc_wait), - SLOT(wait3, __libc_wait3), SLOT(wait4, __sys_wait4), - SLOT(waitpid, __libc_waitpid), SLOT(write, __sys_write), SLOT(writev, __sys_writev), SLOT(_pthread_mutex_init_calloc_cb, _pthread_mutex_init_calloc_cb_stub), diff --git a/lib/libc/sys/open.c b/lib/libc/sys/open.c index 57c0324..e0273c6 100644 --- a/lib/libc/sys/open.c +++ b/lib/libc/sys/open.c @@ -54,6 +54,6 @@ open(const char *path, int flags, ...) } else { mode = 0; } - return (((int (*)(const char *, int, ...)) - __libc_interposing[INTERPOS_open])(path, flags, mode)); + return (((int (*)(int, const char *, int, ...)) + __libc_interposing[INTERPOS_openat])(AT_FDCWD, path, flags, mode)); } diff --git a/lib/libthr/thread/thr_private.h b/lib/libthr/thread/thr_private.h index 0c16b2a..d62de98 100644 --- a/lib/libthr/thread/thr_private.h +++ b/lib/libthr/thread/thr_private.h @@ -917,8 +917,6 @@ void _thr_stack_fix_protection(struct pthread *thrd); int *__error_threaded(void) __hidden; void __thr_interpose_libc(void) __hidden; pid_t __thr_fork(void); -int __thr_pause(void) __hidden; -int __thr_raise(int sig); int __thr_setcontext(const ucontext_t *ucp); int __thr_sigaction(int sig, const struct sigaction *act, struct sigaction *oact) __hidden; diff --git a/lib/libthr/thread/thr_sig.c b/lib/libthr/thread/thr_sig.c index 1ec64f0..7cd0f75 100644 --- a/lib/libthr/thread/thr_sig.c +++ b/lib/libthr/thread/thr_sig.c @@ -515,23 +515,6 @@ _thr_signal_deinit(void) } int -__thr_pause(void) -{ - sigset_t oset; - - if (_sigprocmask(SIG_BLOCK, NULL, &oset) == -1) - return (-1); - return (__thr_sigsuspend(&oset)); -} - -int -__thr_raise(int sig) -{ - - return (_thr_send_sig(_get_curthread(), sig)); -} - -int __thr_sigaction(int sig, const struct sigaction *act, struct sigaction *oact) { struct sigaction newact, oldact, oldact2; diff --git a/lib/libthr/thread/thr_syscalls.c b/lib/libthr/thread/thr_syscalls.c index a4fe7e8..d45ecd2 100644 --- a/lib/libthr/thread/thr_syscalls.c +++ b/lib/libthr/thread/thr_syscalls.c @@ -104,24 +104,6 @@ extern int __fcntl_compat(int, int, ...); * If thread is canceled, no socket is created. */ static int -__thr_accept(int s, struct sockaddr *addr, socklen_t *addrlen) -{ - struct pthread *curthread; - int ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __sys_accept(s, addr, addrlen); - _thr_cancel_leave(curthread, ret == -1); - - return (ret); -} - -/* - * Cancellation behavior: - * If thread is canceled, no socket is created. - */ -static int __thr_accept4(int s, struct sockaddr *addr, socklen_t *addrlen, int flags) { struct pthread *curthread; @@ -189,25 +171,6 @@ __thr_connect(int fd, const struct sockaddr *name, socklen_t namelen) return (ret); } - -/* - * Cancellation behavior: - * If thread is canceled, file is not created. - */ -static int -__thr_creat(const char *path, mode_t mode) -{ - struct pthread *curthread; - int ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __libc_creat(path, mode); - _thr_cancel_leave(curthread, ret == -1); - - return (ret); -} - /* * Cancellation behavior: * According to specification, only F_SETLKW is a cancellation point. @@ -300,35 +263,6 @@ __thr_nanosleep(const struct timespec *time_to_sleep, * If the thread is canceled, file is not opened. */ static int -__thr_open(const char *path, int flags,...) -{ - struct pthread *curthread; - int mode, ret; - va_list ap; - - /* Check if the file is being created: */ - if ((flags & O_CREAT) != 0) { - /* Get the creation mode: */ - va_start(ap, flags); - mode = va_arg(ap, int); - va_end(ap); - } else { - mode = 0; - } - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __sys_open(path, flags, mode); - _thr_cancel_leave(curthread, ret == -1); - - return (ret); -} - -/* - * Cancellation behavior: - * If the thread is canceled, file is not opened. - */ -static int __thr_openat(int fd, const char *path, int flags, ...) { struct pthread *curthread; @@ -523,19 +457,6 @@ __thr_sendto(int s, const void *m, size_t l, int f, const struct sockaddr *t, return (ret); } -static unsigned int -__thr_sleep(unsigned int seconds) -{ - struct pthread *curthread; - unsigned int ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __libc_sleep(seconds); - _thr_cancel_leave(curthread, 1); - return (ret); -} - static int __thr_system(const char *string) { @@ -567,55 +488,6 @@ __thr_tcdrain(int fd) return (ret); } -static int -__thr_usleep(useconds_t useconds) -{ - struct pthread *curthread; - int ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __libc_usleep(useconds); - _thr_cancel_leave(curthread, 1); - return (ret); -} - -/* - * Cancellation behavior: - * Thread may be canceled at start, but if the system call returns - * a child pid, the thread is not canceled. - */ -static pid_t -__thr_wait(int *istat) -{ - struct pthread *curthread; - pid_t ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __libc_wait(istat); - _thr_cancel_leave(curthread, ret <= 0); - return (ret); -} - -/* - * Cancellation behavior: - * Thread may be canceled at start, but if the system call returns - * a child pid, the thread is not canceled. - */ -static pid_t -__thr_wait3(int *status, int options, struct rusage *rusage) -{ - struct pthread *curthread; - pid_t ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __libc_wait3(status, options, rusage); - _thr_cancel_leave(curthread, ret <= 0); - return (ret); -} - /* * Cancellation behavior: * Thread may be canceled at start, but if the system call returns @@ -636,24 +508,6 @@ __thr_wait4(pid_t pid, int *status, int options, struct rusage *rusage) /* * Cancellation behavior: - * Thread may be canceled at start, but if the system call returns - * a child pid, the thread is not canceled. - */ -static pid_t -__thr_waitpid(pid_t wpid, int *status, int options) -{ - struct pthread *curthread; - pid_t ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __libc_waitpid(wpid, status, options); - _thr_cancel_leave(curthread, ret <= 0); - return (ret); -} - -/* - * Cancellation behavior: * Thread may be canceled at start, but if the thread wrote some data, * it is not canceled. */ @@ -696,22 +550,18 @@ __thr_interpose_libc(void) #define SLOT(name) \ *(__libc_interposing_slot(INTERPOS_##name)) = \ (interpos_func_t)__thr_##name; - SLOT(accept); SLOT(accept4); SLOT(aio_suspend); SLOT(close); SLOT(connect); - SLOT(creat); SLOT(fcntl); SLOT(fsync); SLOT(fork); SLOT(msync); SLOT(nanosleep); - SLOT(open); SLOT(openat); SLOT(poll); SLOT(pselect); - SLOT(raise); SLOT(read); SLOT(readv); SLOT(recvfrom); @@ -728,14 +578,8 @@ __thr_interpose_libc(void) SLOT(sigwaitinfo); SLOT(swapcontext); SLOT(system); - SLOT(sleep); SLOT(tcdrain); - SLOT(usleep); - SLOT(pause); - SLOT(wait); - SLOT(wait3); SLOT(wait4); - SLOT(waitpid); SLOT(write); SLOT(writev); #undef SLOT From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 04:11:31 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26E801F9; Mon, 5 Jan 2015 04:11:31 +0000 (UTC) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BF9313262; Mon, 5 Jan 2015 04:11:30 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id b13so26810071wgh.32; Sun, 04 Jan 2015 20:11:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fCT9OhmgS+B+mF08Iu8u9td2ebp8TVnCbjtUIlTZCWU=; b=nvdkzng2tIPNVa2eGFBW8L5RJyB0TQHBy8D3NFCRa0AtM3hI7zbmuv3CBwdjlabDN2 PGqtjMvYt+k36kM0o02yRXpN1kAfbdXNeDNVOiqbmsnqBMb9ZtrZxOy/m98LG/UmANIr 6Nv289ktXxlskgsFYCZeeMHFWz2yL7btvSyPxfMMb5PBDTIvJpIf1hYv27bC9lQyoaci Aa4QPeq4Akb6VWSsNBUBl7p0IDbiDdPHYKqgt7ypZLB6rFR76IJq2aQKE3zurUSY4YCO pq4xPB3155Tv2Yn/OsTvosA5ak85HBSPhTOiwwJpqslqaSX3n0ngjy/+4uq4rEKkZEan MKbw== MIME-Version: 1.0 X-Received: by 10.180.91.193 with SMTP id cg1mr21696277wib.26.1420431089269; Sun, 04 Jan 2015 20:11:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Sun, 4 Jan 2015 20:11:29 -0800 (PST) In-Reply-To: <201501050207.t05274U2086589@idle.juniper.net> References: <201501050207.t05274U2086589@idle.juniper.net> Date: Sun, 4 Jan 2015 20:11:29 -0800 X-Google-Sender-Auth: osDoL_fw2aWRAgYlxNl7QMKONxc Message-ID: Subject: Re: Libxo bugs and fixes. From: Adrian Chadd To: Phil Shafer Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Mon, 05 Jan 2015 04:28:28 +0000 Cc: Alfred Perlstein , John-Mark Gurney , Alfred Perlstein , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , Marcel Moolenaar , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 04:11:31 -0000 ... hm, lost in all of that - so does the proposed API change actually delineate records somehow? (Ie, not having the "close/open tags" bit as a hard-coded new record, but a "this is a self contained record, ok, we're going to output another one.") It will be useful for things that aren't time-series graphs. -adrian From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 04:49:45 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 860F3B3F for ; Mon, 5 Jan 2015 04:49:45 +0000 (UTC) Received: from mail-ie0-f173.google.com (mail-ie0-f173.google.com [209.85.223.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7B819DA for ; Mon, 5 Jan 2015 04:49:45 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id y20so19010089ier.32 for ; Sun, 04 Jan 2015 20:49:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=19nMuSJjgms/sP+RScuQsC3HdrI3WazmNhVjDevVAgI=; b=az15LwxJQdfxxiLsGfKX0mobBN1oW6J7s9PcEQbd+BLarE2yj4ymxpDXCovXYOWjs9 k+J2CcrduttVqTH2wemO4+Tfqu761Fx3XFjGDV9Qwnw3b4hqMVncEFBBovU2PRXLUFrh paRGRQLiy27Hy9eLe8L3J7HLCcLflpzpypki9lLvC7cvzKKlxsmcQ6X6bgfk2guYCTnr brmUPq8lmQjxOmt6CigA152EykU4706x84p6+Bp3JfMnFeT3rQcDDZ5KhpTmYJ4WHLQ9 /56NsFDj7Hu0rcD6r4rU9C15J0WfA3SS7XEHeYRlQHe3Usvaj7Hl9TnBeq8aRf32PFZt 3TGw== X-Gm-Message-State: ALoCoQkokw6svyFNlV4j1hCiDPluwVstHTzhmNhjyJJ1XRjYqtq1aGWNRaVPnFISAXV/BuUhJPWA X-Received: by 10.50.7.34 with SMTP id g2mr9297153iga.36.1420433383960; Sun, 04 Jan 2015 20:49:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.138.217 with HTTP; Sun, 4 Jan 2015 20:49:23 -0800 (PST) X-Originating-IP: [72.177.7.16] In-Reply-To: References: From: Bryan Venteicher Date: Sun, 4 Jan 2015 22:49:23 -0600 Message-ID: Subject: Re: [CFT] Paravirtualized KVM clock To: Jim Harris Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , FreeBSD-current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 04:49:45 -0000 On Sun, Jan 4, 2015 at 8:01 PM, Jim Harris wrote: > > > On Sun, Jan 4, 2015 at 12:00 PM, Adrian Chadd wrote: > >> ... so, out of pure curiousity - what's making the benchmark go >> faster? Is it userland side of things calling clock methods, or >> something in the kernel, or both? >> >> > Most likely GEOM statistic gathering in the kernel but Bryan would have t= o > confirm. > > Yes =E2=80=8B - t=E2=80=8B hat's the main =E2=80=8B source=E2=80=8B . A similar issue exists in the network stack =E2=80=8BBPF.=E2=80=8B I haven't looked or thought too much if it make sense / is possible to use kvmclock in userland too (I think kib@ added fast gettimeofday & friends support a few years back). I intermittently saw this same kind of massive slowdown in nvme(4) > performance a couple of years back due to a bug in the TSC self-check cod= e > which has since been fixed. The bug would result in falling back to HPET > and all of the clock calls from the GEOM code for each I/O would kill > performance. > > >> >> -adrian >> >> >> On 4 January 2015 at 09:56, Bryan Venteicher >> wrote: >> > For the last few weeks, I've been working on adding support for KVM >> clock >> > in the projects/paravirt branch. Currently, a KVM VM guest will end up >> > selecting either the HPET or ACPI as the timecounter source. >> Unfortunately, >> > this is very costly since every timecounter fetch causes a VM exit. KV= M >> > clock allows the guest to use the TSC instead; it is very similar to t= he >> > existing Xen timer. >> > >> > The performance difference between HPET/ACPI and KVMCLOCK can be >> dramatic: >> > a simple disk benchmark goes from 10K IOPs to 100K IOPs. >> > >> > The patch is attached is attached or available at [1]. I'd appreciate >> any >> > testing. >> > >> > Also as a part of this, I've tried to generalized a bit of our existin= g >> > hypervisor guest code, with the eventual goal of being able to support >> more >> > invasive PV operations. The patch series is viewable in Phabricator. >> > >> > https://reviews.freebsd.org/D1429 - paravirt: Generalize parts of the >> XEN >> > timer code into pvclock >> > https://reviews.freebsd.org/D1430 - paravirt: Add interface to >> calculate >> > the TSC frequency from pvclock >> > https://reviews.freebsd.org/D1431 - paravirt: Add simple hypervisor >> > registration and detection interface >> > https://reviews.freebsd.org/D1432 - paravirt: Add detection of bhyve >> using >> > new hypervisor interface >> > https://reviews.freebsd.org/D1433 - paravirt: Add detection of VMware >> using >> > new hypervisor interface >> > https://reviews.freebsd.org/D1434 - paravirt: Add detection of KVM >> using >> > new hypervisor interface >> > https://reviews.freebsd.org/D1435 - paravirt: Add KVM clock timecounte= r >> > support >> > >> > My current plan is to MFC this series to 10-STABLE, and commit a >> > self-contained KVM clock to the other stable branches. >> > >> > [1] - https://people.freebsd.org/~bryanv/patches/kvm_clock-1.patch >> > >> > _______________________________________________ >> > freebsd-arch@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-arch >> > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org= " >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.or= g >> " >> > > From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 20:07:37 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8500A610 for ; Mon, 5 Jan 2015 20:07:37 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5D1F43387 for ; Mon, 5 Jan 2015 20:07:37 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 92538B913 for ; Mon, 5 Jan 2015 15:07:35 -0500 (EST) From: John Baldwin To: arch@freebsd.org Subject: devctl(8): A device control utility Date: Mon, 05 Jan 2015 15:01 -0500 Message-ID: <3200196.9ZgXApgRdA@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 05 Jan 2015 15:07:35 -0500 (EST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 20:07:37 -0000 For a long time I've wanted a way to administratively manipulate the state of new-bus devices from userland. I think the first use case I wanted was a way to power off the sound controller (and anything else I wasn't using) on my first laptop (a Dell Inspiron 5000e I got back in 2000). Similarly, it would be nice to have a way to handle "ejectable" devices (ACPI has a provision for this, and said laptop had _EJx methods to allow one to swap a CD drive out for a battery in a bay while the laptop was in S3). There are some other use cases that would also be nice such as detaching a driver from a PCI device to decide at runtime that it should be passed through to a bhyve guest (and possibly undoing that to allow a host driver to take it back over). Forcing a rescan of a PCI device can be useful if you are using an FPGA and would like to alter BAR layout/sizes without having to reboot the OS. A way to force resets at runtime might also be useful (e.g. a FLR for a PCI device). A few weeks ago I finally sat down and started on an implementation. It can be found here: https://github.com/bsdjhb/freebsd/compare/devctl Sample commands look like: % devctl disable virtio_pci2 # detaches the driver, but leaves the device's name intact similar to # specifying hint.virtio_pci.2.disabled=1 at boot % devctl enable virtio_pci2 # enables a disabled device, including attaching it % devctl detach uart1 # does a full detach, which means the device is now unnamed % devctl attach \_SB_.PCI0.LPC.UAR1 # attaches an unattached device. A provision is made for recognizing # device addresses via an EVENTHANDLER hook that a bus driver can # install. Currently ACPI handles and pci selectors (ala pciconf) # are recognized via hooks in the ACPI and PCI bus drivers. % devctl set driver foo0 bar # forces the 'foo0' device to use the 'bar' device class and thus # only attach to a driver named 'bar' (assuming that 'bar' will # probe it, this doesn't override device_probe). With some changes # to ppt.c, this would allow one to do 'devctl set driver foo0 ppt' # to detach a host driver and mark a device for PCI passthrough at # runtime. I have not yet implemented a "clear driver" to reset # back to an empty device class. The current version also includes 'suspend' and 'resume' commands which use bus_suspend_child() (recently added by Justin Hibbits) to suspend (and possibly power down) individual devices. Implementation notes: For the kernel <-> userland interface, I chose to use ioctls. The ioctls use a 'struct devreq' structure that is modeled on 'struct ifreq' used for network interface ioctls in that there are a set of common fields and a union of request-specific fields. I would have liked to reuse /dev/devctl for this, but it is a single purpose device intended for use by devd. If I had my druthers, I would probably like to rename /dev/devctl to /dev/devevents or /dev/devnotify or some such and create a new /dev/devctl for these control ioctls. Instead what I've done for now is create a /dev/devctl2 for the new ioctls. There is a thin library (libdevctl) that wraps the /dev/devctl2 ioctls and provides methods like devctl_detach(), etc. The thin library even has a manpage already. The devctl(8) utility is then a thin wrapper around libdevctl (and does not yet have a manpage). Do folks have any feedback? -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 20:13:02 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 45A1E793; Mon, 5 Jan 2015 20:13:02 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 08DF634AE; Mon, 5 Jan 2015 20:13:02 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 27C2A1FE022; Mon, 5 Jan 2015 21:12:59 +0100 (CET) Message-ID: <54AAF07B.7030601@selasky.org> Date: Mon, 05 Jan 2015 21:13:47 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Baldwin , arch@freebsd.org Subject: Re: devctl(8): A device control utility References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> In-Reply-To: <3200196.9ZgXApgRdA@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 20:13:02 -0000 On 01/05/15 21:01, John Baldwin wrote: > The devctl(8) utility is then a thin wrapper around libdevctl (and does not > yet have a manpage). > > Do folks have any feedback? Hi, In the USB area attach and detach must be synchronized to the USB stack and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y reset" should be used to avoid races attaching and detaching drivers! --HPS From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 20:16:53 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4C782918; Mon, 5 Jan 2015 20:16:53 +0000 (UTC) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D37A13510; Mon, 5 Jan 2015 20:16:52 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id k14so28429381wgh.15; Mon, 05 Jan 2015 12:16:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2AgjdBiGmYdC23a9BLVenqjn/8EWaFg+dor1xmHYGH8=; b=RgImgAPukLl+CfZTuCl6JrFjDUBTdZ+PzDrtMHMRXIr5reffLFw0BbjidX6qVHReze LqNgLJUTnmEqhpePevBg1qWP6M4kyu5fL+sCPElMbq619mjfQl8PTBE3or5d4zLVMwZy wxQCbhhznaubtJnpJoRzSn4inhhubOSL5Mo90Y4qBtLi3gyfTxNo48/N2c7bbwGIft/e 7MHgw07sgJYc2LzqB8WuWaxXGI53GkLEjojXbM0nZPTKFM0+0fpqfd/oxnVti87x3BBs z77aooLgW04oV7j/yCJ/W0vTMKsca3l4qr0fALXDZR7UwB7K9D4kLSmAqCNBRaVdCN4e w7Lw== MIME-Version: 1.0 X-Received: by 10.180.80.163 with SMTP id s3mr28653862wix.59.1420489011016; Mon, 05 Jan 2015 12:16:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Mon, 5 Jan 2015 12:16:50 -0800 (PST) In-Reply-To: <3200196.9ZgXApgRdA@ralph.baldwin.cx> References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> Date: Mon, 5 Jan 2015 12:16:50 -0800 X-Google-Sender-Auth: yfW4oa-KO-eExwct5v-dT2ltehQ Message-ID: Subject: Re: devctl(8): A device control utility From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 20:16:53 -0000 Hi, This looks good to me. I'm sure there will be fallout (like hps@ comment about sync'ing with other attach/detach things in USB) but I think this is fine as-is and will be useful for finding bugs in various attach/detach paths. -adrian On 5 January 2015 at 12:01, John Baldwin wrote: > For a long time I've wanted a way to administratively manipulate the state of > new-bus devices from userland. I think the first use case I wanted was a way > to power off the sound controller (and anything else I wasn't using) on my > first laptop (a Dell Inspiron 5000e I got back in 2000). Similarly, it would > be nice to have a way to handle "ejectable" devices (ACPI has a provision for > this, and said laptop had _EJx methods to allow one to swap a CD drive out for > a battery in a bay while the laptop was in S3). There are some other use > cases that would also be nice such as detaching a driver from a PCI device to > decide at runtime that it should be passed through to a bhyve guest (and > possibly undoing that to allow a host driver to take it back over). Forcing a > rescan of a PCI device can be useful if you are using an FPGA and would like > to alter BAR layout/sizes without having to reboot the OS. A way to force > resets at runtime might also be useful (e.g. a FLR for a PCI device). A few > weeks ago I finally sat down and started on an implementation. It can be > found here: > > https://github.com/bsdjhb/freebsd/compare/devctl > > Sample commands look like: > > % devctl disable virtio_pci2 > > # detaches the driver, but leaves the device's name intact similar to > # specifying hint.virtio_pci.2.disabled=1 at boot > > % devctl enable virtio_pci2 > > # enables a disabled device, including attaching it > > % devctl detach uart1 > > # does a full detach, which means the device is now unnamed > > % devctl attach \_SB_.PCI0.LPC.UAR1 > > # attaches an unattached device. A provision is made for recognizing > # device addresses via an EVENTHANDLER hook that a bus driver can > # install. Currently ACPI handles and pci selectors (ala pciconf) > # are recognized via hooks in the ACPI and PCI bus drivers. > > % devctl set driver foo0 bar > > # forces the 'foo0' device to use the 'bar' device class and thus > # only attach to a driver named 'bar' (assuming that 'bar' will > # probe it, this doesn't override device_probe). With some changes > # to ppt.c, this would allow one to do 'devctl set driver foo0 ppt' > # to detach a host driver and mark a device for PCI passthrough at > # runtime. I have not yet implemented a "clear driver" to reset > # back to an empty device class. > > The current version also includes 'suspend' and 'resume' commands which > use bus_suspend_child() (recently added by Justin Hibbits) to suspend > (and possibly power down) individual devices. > > Implementation notes: > > For the kernel <-> userland interface, I chose to use ioctls. The ioctls > use a 'struct devreq' structure that is modeled on 'struct ifreq' used > for network interface ioctls in that there are a set of common fields and > a union of request-specific fields. > > I would have liked to reuse /dev/devctl for this, but it is a single > purpose device intended for use by devd. If I had my druthers, I would > probably like to rename /dev/devctl to /dev/devevents or /dev/devnotify > or some such and create a new /dev/devctl for these control ioctls. Instead > what I've done for now is create a /dev/devctl2 for the new ioctls. > > There is a thin library (libdevctl) that wraps the /dev/devctl2 ioctls and > provides methods like devctl_detach(), etc. The thin library even has a > manpage already. > > The devctl(8) utility is then a thin wrapper around libdevctl (and does not > yet have a manpage). > > Do folks have any feedback? > > -- > John Baldwin > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 20:37:34 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C0865E4 for ; Mon, 5 Jan 2015 20:37:34 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 763BC28C3 for ; Mon, 5 Jan 2015 20:37:34 +0000 (UTC) Received: from new-host-2.home (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 6F878B913; Mon, 5 Jan 2015 15:37:32 -0500 (EST) Message-ID: <54AAF60A.9070609@FreeBSD.org> Date: Mon, 05 Jan 2015 15:37:30 -0500 From: John Baldwin User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Hans Petter Selasky , arch@freebsd.org Subject: Re: devctl(8): A device control utility References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF07B.7030601@selasky.org> In-Reply-To: <54AAF07B.7030601@selasky.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 05 Jan 2015 15:37:32 -0500 (EST) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 20:37:34 -0000 On 1/5/15 3:13 PM, Hans Petter Selasky wrote: > On 01/05/15 21:01, John Baldwin wrote: >> The devctl(8) utility is then a thin wrapper around libdevctl (and >> does not >> yet have a manpage). >> >> Do folks have any feedback? > > Hi, > > In the USB area attach and detach must be synchronized to the USB stack > and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y reset" should > be used to avoid races attaching and detaching drivers! I think this points to one or more missing bus methods so that the bus can hook into device_probe_and_attach() to reset a device as needed. (e.g. if you had bus_probe_started / bus_probe_finished and possibly similar methods for attach. PCI could use a bus_attach_finished() callback so that it could clean up any dangling resources and possibly power down on a failed attach the way it does in bus_child_detached as well). Also, 'devctl detach' is a bit racy anyway as a subsequent kldload of any driver on the bus will rescan the bus and try to attach any unattached device. 'devctl disable' does not have this race, but it currently matches 'hint.foo.0.disabled' and doesn't let you try an alternate driver. I consider attach/detach a bit more low-level while enable/disable are probably more end-user friendly. For the case of letting a device rebid after loading a new driver, a new 'reprobe' ioctl/command might be best rather than requiring an explicit 'detach/attach'. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 20:57:33 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67B2C199; Mon, 5 Jan 2015 20:57:33 +0000 (UTC) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2AAAA2D87; Mon, 5 Jan 2015 20:57:33 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 3D19A1FE022; Mon, 5 Jan 2015 21:57:31 +0100 (CET) Message-ID: <54AAFAEB.2090505@selasky.org> Date: Mon, 05 Jan 2015 21:58:19 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: John Baldwin , arch@freebsd.org Subject: Re: devctl(8): A device control utility References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF07B.7030601@selasky.org> <54AAF60A.9070609@FreeBSD.org> In-Reply-To: <54AAF60A.9070609@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 20:57:33 -0000 On 01/05/15 21:37, John Baldwin wrote: > On 1/5/15 3:13 PM, Hans Petter Selasky wrote: >> On 01/05/15 21:01, John Baldwin wrote: >>> The devctl(8) utility is then a thin wrapper around libdevctl (and >>> does not >>> yet have a manpage). >>> >>> Do folks have any feedback? >> >> Hi, >> >> In the USB area attach and detach must be synchronized to the USB stack >> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y reset" should >> be used to avoid races attaching and detaching drivers! > > I think this points to one or more missing bus methods so that the bus > can hook into device_probe_and_attach() to reset a device as needed. > (e.g. if you had bus_probe_started / bus_probe_finished and possibly > similar methods for attach. PCI could use a bus_attach_finished() > callback so that it could clean up any dangling resources and possibly > power down on a failed attach the way it does in bus_child_detached as > well). Hi, USB has its own threads to allocate/free devices. Another problem is how to atomically get a reference count across multiple layers like PCI and USB. It doesn't allow probe/attach when called from outside these threads. What happens if one instance of "devctl detach" detaches the USB PCI controller and another detaches a USB device, child of the USB PCI controller? > > Also, 'devctl detach' is a bit racy anyway as a subsequent kldload of > any driver on the bus will rescan the bus and try to attach any > unattached device. 'devctl disable' does not have this race, but it > currently matches 'hint.foo.0.disabled' and doesn't let you try an > alternate driver. I consider attach/detach a bit more low-level while > enable/disable are probably more end-user friendly. For the case of > letting a device rebid after loading a new driver, a new 'reprobe' > ioctl/command might be best rather than requiring an explicit > 'detach/attach'. Is it a problem if devctl access is protected by a single SX lock and only can access PCI devices? --HPS From owner-freebsd-arch@FreeBSD.ORG Mon Jan 5 21:34:09 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68C7CBED for ; Mon, 5 Jan 2015 21:34:09 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40577643DE for ; Mon, 5 Jan 2015 21:34:09 +0000 (UTC) Received: from ralph.baldwin.cx (pool-173-70-85-31.nwrknj.fios.verizon.net [173.70.85.31]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 38297B926; Mon, 5 Jan 2015 16:34:07 -0500 (EST) From: John Baldwin To: Hans Petter Selasky Subject: Re: devctl(8): A device control utility Date: Mon, 05 Jan 2015 16:18:21 -0500 Message-ID: <6155572.yV5dxPJznD@ralph.baldwin.cx> User-Agent: KMail/4.14.2 (FreeBSD/10.1-STABLE; KDE/4.14.2; amd64; ; ) In-Reply-To: <54AAFAEB.2090505@selasky.org> References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF60A.9070609@FreeBSD.org> <54AAFAEB.2090505@selasky.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 05 Jan 2015 16:34:07 -0500 (EST) Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2015 21:34:09 -0000 On Monday, January 05, 2015 09:58:19 PM Hans Petter Selasky wrote: > On 01/05/15 21:37, John Baldwin wrote: > > On 1/5/15 3:13 PM, Hans Petter Selasky wrote: > >> On 01/05/15 21:01, John Baldwin wrote: > >>> The devctl(8) utility is then a thin wrapper around libdevctl (and > >>> does not > >>> yet have a manpage). > >>> > >>> Do folks have any feedback? > >> > >> Hi, > >> > >> In the USB area attach and detach must be synchronized to the USB stack > >> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y reset" should > >> be used to avoid races attaching and detaching drivers! > > > > I think this points to one or more missing bus methods so that the bus > > can hook into device_probe_and_attach() to reset a device as needed. > > (e.g. if you had bus_probe_started / bus_probe_finished and possibly > > similar methods for attach. PCI could use a bus_attach_finished() > > callback so that it could clean up any dangling resources and possibly > > power down on a failed attach the way it does in bus_child_detached as > > well). > > Hi, > > USB has its own threads to allocate/free devices. Another problem is how > to atomically get a reference count across multiple layers like PCI and > USB. It doesn't allow probe/attach when called from outside these threads. That just means you need to use some locks. :) Cardbus also uses an event thread to handle auto-attach of devices when it detected a card change event, but that doesn't prevent it from servicing an ioctl request. > What happens if one instance of "devctl detach" detaches the USB PCI > controller and another detaches a USB device, child of the USB PCI > controller? Right now new-bus is single-threaded, so one of those should wait on the other. If it doesn't, that should be fixed in new-bus / the drivers. It should not require extra hoops for the administrator. > > Also, 'devctl detach' is a bit racy anyway as a subsequent kldload of > > any driver on the bus will rescan the bus and try to attach any > > unattached device. 'devctl disable' does not have this race, but it > > currently matches 'hint.foo.0.disabled' and doesn't let you try an > > alternate driver. I consider attach/detach a bit more low-level while > > enable/disable are probably more end-user friendly. For the case of > > letting a device rebid after loading a new driver, a new 'reprobe' > > ioctl/command might be best rather than requiring an explicit > > 'detach/attach'. > > Is it a problem if devctl access is protected by a single SX lock and > only can access PCI devices? It is devctl, not pcictl. It is not intended only for PCI devices (and in particular I tested it with ACPI-enumerated devices in a bhyve guest, not just PCI). New-bus' locking in general is not robust and this might expose the need for refining that further (a global sx lock to replace the existing Giant locking wouldn't be a bad start), but that is orthogonal to the tool I think. -- John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 02:28:25 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 14140BD7; Tue, 6 Jan 2015 02:28:25 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0131.outbound.protection.outlook.com [207.46.100.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7CDFB66AB8; Tue, 6 Jan 2015 02:28:23 +0000 (UTC) Received: from BLUPR05CA0053.namprd05.prod.outlook.com (10.141.20.23) by DM2PR05MB446.namprd05.prod.outlook.com (10.141.104.142) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 02:28:17 +0000 Received: from BN1BFFO11FD053.protection.gbl (2a01:111:f400:7c10::1:131) by BLUPR05CA0053.outlook.office365.com (2a01:111:e400:855::23) with Microsoft SMTP Server (TLS) id 15.1.49.12 via Frontend Transport; Tue, 6 Jan 2015 02:28:16 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BN1BFFO11FD053.mail.protection.outlook.com (10.58.145.8) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Tue, 6 Jan 2015 02:28:16 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Mon, 5 Jan 2015 18:28:15 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t062SCW08697; Mon, 5 Jan 2015 18:28:12 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t062RtXw095998; Mon, 5 Jan 2015 21:27:56 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201501060227.t062RtXw095998@idle.juniper.net> To: Adrian Chadd Subject: Re: Libxo bugs and fixes. In-Reply-To: Date: Mon, 5 Jan 2015 21:27:55 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(199003)(51704005)(189002)(164054003)(64706001)(50986999)(54356999)(21056001)(97736003)(92566001)(4396001)(48376002)(86362001)(87936001)(84676001)(46102003)(99396003)(31966008)(50466002)(20776003)(47776003)(62966003)(77156002)(106466001)(81156004)(105596002)(77096005)(107046002)(68736005)(6806004)(120916001)(53416004)(110136001)(2950100001)(76506005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB446; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DM2PR05MB446; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:DM2PR05MB446; X-Forefront-PRVS: 0448A97BF2 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:DM2PR05MB446; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2015 02:28:16.1052 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB446 X-Mailman-Approved-At: Tue, 06 Jan 2015 05:18:38 +0000 Cc: Alfred Perlstein , John-Mark Gurney , Alfred Perlstein , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , Marcel Moolenaar , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 02:28:25 -0000 Adrian Chadd writes: >... hm, lost in all of that - so does the proposed API change actually >delineate records somehow? > >(Ie, not having the "close/open tags" bit as a hard-coded new record, >but a "this is a self contained record, ok, we're going to output >another one.") > >It will be useful for things that aren't time-series graphs. Well, it's not that far along yet, but no, there's nothing cooked into it to make the delinations. This would be either a callback, or a set of "well known" protocols, such as NLD-json. The same plumbing should be usable for other domains. Thanks, Phil From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 06:21:47 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E061C1E; Tue, 6 Jan 2015 06:21:47 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 27F4F293C; Tue, 6 Jan 2015 06:21:46 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-233-252.lns20.per1.internode.on.net [121.45.233.252]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t066Lfai003080 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 5 Jan 2015 22:21:44 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54AB7EEF.9030505@freebsd.org> Date: Tue, 06 Jan 2015 14:21:35 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Hans Petter Selasky , John Baldwin , arch@freebsd.org Subject: Re: devctl(8): A device control utility References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> <54AAF07B.7030601@selasky.org> <54AAF60A.9070609@FreeBSD.org> <54AAFAEB.2090505@selasky.org> In-Reply-To: <54AAFAEB.2090505@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 06:21:47 -0000 On 1/6/15 4:58 AM, Hans Petter Selasky wrote: > On 01/05/15 21:37, John Baldwin wrote: >> On 1/5/15 3:13 PM, Hans Petter Selasky wrote: >>> On 01/05/15 21:01, John Baldwin wrote: >>>> The devctl(8) utility is then a thin wrapper around libdevctl (and >>>> does not >>>> yet have a manpage). >>>> >>>> Do folks have any feedback? >>> >>> Hi, >>> >>> In the USB area attach and detach must be synchronized to the USB >>> stack >>> and "usbconfig -d X.Y set_config Z" or "usbconfig -d X.Y reset" >>> should >>> be used to avoid races attaching and detaching drivers! >> >> I think this points to one or more missing bus methods so that the bus >> can hook into device_probe_and_attach() to reset a device as needed. >> (e.g. if you had bus_probe_started / bus_probe_finished and possibly >> similar methods for attach. PCI could use a bus_attach_finished() >> callback so that it could clean up any dangling resources and possibly >> power down on a failed attach the way it does in bus_child_detached as >> well). > > Hi, > > USB has its own threads to allocate/free devices. Another problem is > how to atomically get a reference count across multiple layers like > PCI and USB. It doesn't allow probe/attach when called from outside > these threads. > > What happens if one instance of "devctl detach" detaches the USB PCI > controller and another detaches a USB device, child of the USB PCI > controller? > >> >> Also, 'devctl detach' is a bit racy anyway as a subsequent kldload of >> any driver on the bus will rescan the bus and try to attach any >> unattached device. 'devctl disable' does not have this race, but it >> currently matches 'hint.foo.0.disabled' and doesn't let you try an >> alternate driver. I consider attach/detach a bit more low-level while >> enable/disable are probably more end-user friendly. For the case of >> letting a device rebid after loading a new driver, a new 'reprobe' >> ioctl/command might be best rather than requiring an explicit >> 'detach/attach'. > > Is it a problem if devctl access is protected by a single SX lock > and only can access PCI devices? I already use pciconf to twiddle registers etc for PCI devices. (well, I did at a previous employer).. are we duplicating any functionality here? > > --HPS > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 17:27:24 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6855E7A2; Tue, 6 Jan 2015 17:27:24 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 14F0166922; Tue, 6 Jan 2015 17:27:23 +0000 (UTC) Received: from [172.29.96.153] ([66.129.239.10]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id t06HRBOb065386 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2015 09:27:13 -0800 (PST) (envelope-from marcel@xcllnt.net) Subject: Re: Libxo bugs and fixes. Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A55A2850-5F24-4F06-A669-8373D1853E6A"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 From: Marcel Moolenaar In-Reply-To: <549F742D.3000802@mu.org> Date: Tue, 6 Jan 2015 09:27:04 -0800 Message-Id: <7F04AD6C-6D07-40C1-9753-D37A82B1CC85@xcllnt.net> References: <201408141640.s7EGe422096656@idle.juniper.net> <53ED57F2.5020808@mu.org> <20140815053604.9E40B580A2@chaos.jnpr.net> <53EDB0EF.6090902@mu.org> <20140815173830.93832580A2@chaos.jnpr.net> <53EEA74B.9070107@mu.org> <20140816045254.5F47E580A2@chaos.jnpr.net> <549BA675.9070107@freebsd.org> <29784.1419492726@chaos> <26E73A9E-6EA4-4698-885D-BD91906D32D2@mu.org> <18276.1419528679@chaos> <549C50FB.6050908@mu.org> <23687.1419546234@chaos> <549F742D.3000802@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1993) X-Mailman-Approved-At: Tue, 06 Jan 2015 17:39:30 +0000 Cc: Marcel Moolenaar , Phil Shafer , John-Mark Gurney , Alfred Perlstein , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 17:27:24 -0000 --Apple-Mail=_A55A2850-5F24-4F06-A669-8373D1853E6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Dec 27, 2014, at 7:08 PM, Alfred Perlstein wrote: >=20 >>=20 > OK, so I've updated https://reviews.freebsd.org/D1379 to include code = to handle this. >=20 > Solaris and glibc have a private libc function to check if a stream is = line buffered called int __flbf (FILE *stream) which returns true/false = if the stream if line buffered or not. I'm still unclear on the need or importance of adding __flbf(). What's wrong with just calling fflush()? What is to be gained by only calling fflush() when the stream is line-buffered? Why not call fflush() when the stream is not line buffered? Put differently: we have 618 instance of fflush() in the source tree and there has been no demand for something like __flbf() before that I know of. Why now? And why specifically for libxo? If __flbf() is really important, then I'd rather see someone go over the source tree to add calls to it for most of those 618 instances of fflush() at the time of its introduction. Not have it introduced as a side-effect of something else when it's not at all obvious that the side-effect was warranted. Can you elaborate? Thanks, -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_A55A2850-5F24-4F06-A669-8373D1853E6A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlSsGukACgkQpgWlLWHuifajUACggBOiDKVbKQ37xbP52l2kznnO OOwAn2UkRwSPfDbUI9sMA2plRvvJg9u3 =s1Ff -----END PGP SIGNATURE----- --Apple-Mail=_A55A2850-5F24-4F06-A669-8373D1853E6A-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 20:03:40 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF89B9ED; Tue, 6 Jan 2015 20:03:40 +0000 (UTC) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id F3FFC2CEA; Tue, 6 Jan 2015 18:30:47 +0000 (UTC) Received: from [10.0.1.110] (c-76-21-10-192.hsd1.ca.comcast.net [76.21.10.192]) by elvis.mu.org (Postfix) with ESMTPSA id DBDFD341F894; Tue, 6 Jan 2015 10:30:46 -0800 (PST) Subject: Re: Libxo bugs and fixes. Mime-Version: 1.0 (Apple Message framework v1283) From: Alfred Perlstein In-Reply-To: <7F04AD6C-6D07-40C1-9753-D37A82B1CC85@xcllnt.net> Date: Tue, 6 Jan 2015 10:34:33 -0800 Message-Id: References: <201408141640.s7EGe422096656@idle.juniper.net> <53ED57F2.5020808@mu.org> <20140815053604.9E40B580A2@chaos.jnpr.net> <53EDB0EF.6090902@mu.org> <20140815173830.93832580A2@chaos.jnpr.net> <53EEA74B.9070107@mu.org> <20140816045254.5F47E580A2@chaos.jnpr.net> <549BA675.9070107@freebsd.org> <29784.1419492726@chaos> <26E73A9E-6EA4-4698-885D-BD91906D32D2@mu.org> <18276.1419528679@chaos> <549C50FB.6050908@mu.org> <23687.1419546234@chaos> <549F742D.3000802@mu.org> <7F04AD6C-6D07-40C1-9753-D37A82B1CC85@xcllnt.net> To: Marcel Moolenaar X-Mailer: Apple Mail (2.1283) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Marcel Moolenaar , Phil Shafer , John-Mark Gurney , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:03:41 -0000 On Jan 6, 2015, at 9:27 AM, Marcel Moolenaar wrote: >=20 >> On Dec 27, 2014, at 7:08 PM, Alfred Perlstein wrote: >>=20 >>>=20 >> OK, so I've updated https://reviews.freebsd.org/D1379 to include code = to handle this. >>=20 >> Solaris and glibc have a private libc function to check if a stream = is line buffered called int __flbf (FILE *stream) which returns = true/false if the stream if line buffered or not. >=20 > I'm still unclear on the need or importance of adding __flbf(). > What's wrong with just calling fflush()? > What is to be gained by only calling fflush() when the stream is > line-buffered? Why not call fflush() when the stream is not line > buffered? >=20 > Put differently: we have 618 instance of fflush() in the source > tree and there has been no demand for something like __flbf() > before that I know of. Why now? And why specifically for libxo? >=20 > If __flbf() is really important, then I'd rather see someone go > over the source tree to add calls to it for most of those 618 > instances of fflush() at the time of its introduction. Not have > it introduced as a side-effect of something else when it's not > at all obvious that the side-effect was warranted. >=20 > Can you elaborate? Nope. the code is up, figure it out yourself. https://github.com/splbio/freebsd/tree/ap_libxo_master/contrib/libxo -Alfred From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 20:05:22 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8450510F; Tue, 6 Jan 2015 20:05:22 +0000 (UTC) Received: from mail.xcllnt.net (mail.xcllnt.net [50.0.150.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D1CDC645CD; Tue, 6 Jan 2015 18:54:48 +0000 (UTC) Received: from [172.29.96.153] ([66.129.239.10]) (authenticated bits=0) by mail.xcllnt.net (8.14.9/8.14.9) with ESMTP id t06IshXw065984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Jan 2015 10:54:44 -0800 (PST) (envelope-from marcel@xcllnt.net) Subject: Re: Libxo bugs and fixes. Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_4036A430-9132-4CE7-8FA6-B8068C331AA0"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b4 From: Marcel Moolenaar In-Reply-To: Date: Tue, 6 Jan 2015 10:54:36 -0800 Message-Id: <7267FD66-8D14-4D0B-AD63-4893A05F33A5@xcllnt.net> References: <201408141640.s7EGe422096656@idle.juniper.net> <53ED57F2.5020808@mu.org> <20140815053604.9E40B580A2@chaos.jnpr.net> <53EDB0EF.6090902@mu.org> <20140815173830.93832580A2@chaos.jnpr.net> <53EEA74B.9070107@mu.org> <20140816045254.5F47E580A2@chaos.jnpr.net> <549BA675.9070107@freebsd.org> <29784.1419492726@chaos> <26E73A9E-6EA4-4698-885D-BD91906D32D2@mu.org> <18276.1419528679@chaos> <549C50FB.6050908@mu.org> <23687.1419546234@chaos> <549F742D.3000802@mu.org> <7F04AD6C-6D07-40C1-9753-D37A82B1CC85@xcllnt.net> To: Alfred Perlstein X-Mailer: Apple Mail (2.1993) Cc: Marcel Moolenaar , Phil Shafer , John-Mark Gurney , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:05:22 -0000 --Apple-Mail=_4036A430-9132-4CE7-8FA6-B8068C331AA0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 > On Jan 6, 2015, at 10:34 AM, Alfred Perlstein wrote: >> Can you elaborate? > > Nope. the code is up, figure it out yourself. Ok. Useless then. It doesn't even handle fully buffered streams so is broken to boot. It's introduction would be a bug and it's use a mistake. Thanks, -- Marcel Moolenaar marcel@xcllnt.net --Apple-Mail=_4036A430-9132-4CE7-8FA6-B8068C331AA0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlSsL20ACgkQpgWlLWHuifZHqwCfTdF920HoiDpSBZgvhSHR3tkN +WoAn2z9NWgCklW7KNNOoe3EUrgGRzLS =z1+P -----END PGP SIGNATURE----- --Apple-Mail=_4036A430-9132-4CE7-8FA6-B8068C331AA0-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 20:50:49 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A569C92E; Tue, 6 Jan 2015 20:50:49 +0000 (UTC) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailhost.stack.nl", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 668EA7F3; Tue, 6 Jan 2015 20:50:49 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id AA1403592EF; Tue, 6 Jan 2015 21:50:46 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 97EAC28494; Tue, 6 Jan 2015 21:50:46 +0100 (CET) Date: Tue, 6 Jan 2015 21:50:46 +0100 From: Jilles Tjoelker To: Konstantin Belousov Subject: Re: Fixing dlopen("libpthread.so") Message-ID: <20150106205046.GA24971@stack.nl> References: <20141226165337.GJ1754@kib.kiev.ua> <20150103212837.GC46373@stack.nl> <20150104114600.GC42409@kib.kiev.ua> <20150104182026.GA61250@stack.nl> <20150105023708.GD42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150105023708.GD42409@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: threads@freebsd.org, arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:50:49 -0000 On Mon, Jan 05, 2015 at 04:37:08AM +0200, Konstantin Belousov wrote: > On Sun, Jan 04, 2015 at 07:20:27PM +0100, Jilles Tjoelker wrote: > > In libc, define the below wait3(). All code in libc that allows libthr to > > interpose wait3() and in libthr that interposes wait3() can then go > > away. > > pid_t > > wait3(int *istat, int options, struct rusage *rup) > > { > > > > return (((pid_t (*)(pid_t, int *, int, struct rusage *)) > > __libc_interposing[INTERPOS_wait4])(WAIT_ANY, istat, options, rup)); > > } > > This change is also possible for wait() and waitpid(), but not for e.g. > > sigwait() which has different [EINTR] behaviour than sigtimedwait(). > Ok, I did the pass over all such thin wrappers. The list is > accept <- calls accept4 now This is wrong since accept() copies various properties from the listening to the new socket, which accept4() never does. (Note that Linux accept() is equivalent to accept4() with 0 flags, so the linuxolator can use such a shortcut.) > creat \ > open <- openat > pause <- there were actual bugs, pause called _sigprocmask and _sigsuspend > raise <- I converted it to threaded kill > sleep <- this one is tricky, but seems to work > usleep > wait > wait3 > waitpid These look OK. > > The changes look good to me. > Next natural question is about the __error calls through PLT in the > .cerror asm. Before the work was committed, libthr interposed __error, > which was required for correct operation. Now, we need __error exported, > but do we need support its interposing ? This is an implementation > detail for errno, I do not see any loss from not allowing to override > errno location. Indeed, there is no need to allow interposing __error (as with many libc-internal calls to its exported symbols). Additionally, the current namespace.h mechanism could be used to redirect __error calls from C code. Glibc uses macro trickery with the asm labels compiler feature, making libc code see things like int *__error(void) asm("__hidden__error"); and defining the hidden alias somewhere. This also works for compiler-generated calls like to memcpy(). I'm not sure whether it is a good idea to add this extra trickery and depend on the compiler feature. Glibc also has build-time checks that only specifically listed symbols are referenced via the PLT. -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 20:04:13 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA05B64E; Tue, 6 Jan 2015 20:04:12 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0115.outbound.protection.outlook.com [157.56.111.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E135E64AB4; Tue, 6 Jan 2015 19:06:53 +0000 (UTC) Received: from BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) by BLUPR05MB038.namprd05.prod.outlook.com (10.255.210.147) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 19:06:45 +0000 Received: from BL2PR05CA0042.namprd05.prod.outlook.com (10.255.226.42) by BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 19:06:45 +0000 Received: from BY2FFO11FD006.protection.gbl (2a01:111:f400:7c0c::134) by BL2PR05CA0042.outlook.office365.com (2a01:111:e400:c04::42) with Microsoft SMTP Server (TLS) id 15.1.49.12 via Frontend Transport; Tue, 6 Jan 2015 19:06:44 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BY2FFO11FD006.mail.protection.outlook.com (10.1.14.127) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Tue, 6 Jan 2015 19:06:44 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 6 Jan 2015 11:06:44 -0800 Received: from chaos.jnpr.net (chaos.jnpr.net [172.21.16.28]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t06J6hW75507; Tue, 6 Jan 2015 11:06:43 -0800 (PST) (envelope-from sjg@juniper.net) Received: from chaos (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id 041B7580A3; Tue, 6 Jan 2015 11:06:43 -0800 (PST) To: Phil Shafer Subject: Re: Libxo bugs and fixes. In-Reply-To: <201501061815.t06IFoMi003101@idle.juniper.net> References: <201501061815.t06IFoMi003101@idle.juniper.net> Comments: In-reply-to: Phil Shafer message dated "Tue, 06 Jan 2015 13:15:50 -0500." From: "Simon J. Gerraty" X-Mailer: MH-E 8.0.3; nmh 1.3; GNU Emacs 22.3.1 Date: Tue, 6 Jan 2015 11:06:43 -0800 Message-ID: <2472.1420571203@chaos> MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=sjg@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(89996001)(117636001)(99396003)(86362001)(120916001)(77156002)(50226001)(92566001)(62966003)(31966008)(97736003)(4396001)(21056001)(84676001)(19580405001)(6806004)(48376002)(19580395003)(69596002)(50466002)(87936001)(2950100001)(1941001)(110136001)(50986999)(76176999)(64706001)(47776003)(20776003)(76506005)(33716001)(107046002)(105596002)(81156004)(106466001)(68736005)(57986006)(77096005)(46102003)(42262002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB435; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-DmarcAction: None X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:BLUPR05MB435; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:BLUPR05MB435; X-Forefront-PRVS: 0448A97BF2 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB435; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2015 19:06:44.5515 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB435 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB038; X-OriginatorOrg: juniper.net X-Mailman-Approved-At: Tue, 06 Jan 2015 21:01:39 +0000 Cc: Alfred Perlstein , John-Mark Gurney , Alfred Perlstein , Marcel Moolenaar , "arch@freebsd.org" , Poul-Henning Kamp , Marcel Moolenaar , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:04:13 -0000 Phil Shafer wrote: > My take is that the missing piece was the ability of xo_flush to > flush the underlaying (opaque) stream. The way it's currently coded .. > uses fflush for stdout, but doesn't call __flbf. The app needs to > decide when a flush is needed and calls xo_flush. .. > Setting the XOF_FLUSH flag should (but doesn't yet) trigger this > for each xo_* call. Currently XOF_FLUSH just flushes to the > writer, but doesn't call the flush function. I'll add this. Calling flush for every xo_* call would seem like a bad idea no? The app/caller is the only one to know when a suitable flush point has been reached (if necessary). It should suffice if xo_flush() does what the name implies. If someone is using something other than stdio for a handle, they just need to tell libxo a function to call in response to xo_flush ? Does it need to be more complicated than that? From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 20:05:13 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1EF18D26; Tue, 6 Jan 2015 20:05:13 +0000 (UTC) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bbn0102.outbound.protection.outlook.com [157.56.111.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C52BC2791; Tue, 6 Jan 2015 18:16:21 +0000 (UTC) Received: from CO2PR05CA024.namprd05.prod.outlook.com (10.141.241.152) by DM2PR05MB445.namprd05.prod.outlook.com (10.141.104.154) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 6 Jan 2015 18:16:14 +0000 Received: from BL2FFO11FD049.protection.gbl (2a01:111:f400:7c09::180) by CO2PR05CA024.outlook.office365.com (2a01:111:e400:1429::24) with Microsoft SMTP Server (TLS) id 15.1.49.12 via Frontend Transport; Tue, 6 Jan 2015 18:16:13 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD049.mail.protection.outlook.com (10.173.161.211) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Tue, 6 Jan 2015 18:16:13 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 6 Jan 2015 10:16:11 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t06IG9W48659; Tue, 6 Jan 2015 10:16:09 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t06IFoMi003101; Tue, 6 Jan 2015 13:15:51 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201501061815.t06IFoMi003101@idle.juniper.net> To: Marcel Moolenaar Subject: Re: Libxo bugs and fixes. In-Reply-To: <7F04AD6C-6D07-40C1-9753-D37A82B1CC85@xcllnt.net> Date: Tue, 6 Jan 2015 13:15:50 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(164054003)(189002)(199003)(92566001)(110136001)(68736005)(46102003)(105596002)(31966008)(107046002)(76506005)(97736003)(4396001)(53416004)(84676001)(69596002)(106466001)(77096005)(6806004)(99396003)(120916001)(50986999)(54356999)(2950100001)(87936001)(86362001)(50466002)(62966003)(21056001)(77156002)(48376002)(81156004)(64706001)(20776003)(47776003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR05MB445; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:DM2PR05MB445; X-Forefront-PRVS: 0448A97BF2 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jan 2015 18:16:13.0665 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR05MB445 X-Mailman-Approved-At: Tue, 06 Jan 2015 21:07:30 +0000 Cc: Alfred Perlstein , John-Mark Gurney , Alfred Perlstein , "Simon J. Gerraty" , "arch@freebsd.org" , Poul-Henning Kamp , Marcel Moolenaar , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 20:05:13 -0000 Marcel Moolenaar writes: >What's wrong with just calling fflush()? My take is that the missing piece was the ability of xo_flush to flush the underlaying (opaque) stream. The way it's currently coded (the "develop" branch) adds the flush function to xo_set_writer and uses fflush for stdout, but doesn't call __flbf. The app needs to decide when a flush is needed and calls xo_flush. Setting the XOF_FLUSH flag should (but doesn't yet) trigger this for each xo_* call. Currently XOF_FLUSH just flushes to the writer, but doesn't call the flush function. I'll add this. Thanks, Phil From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 21:25:54 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D76751C; Tue, 6 Jan 2015 21:25:54 +0000 (UTC) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A82C64D3B; Tue, 6 Jan 2015 21:25:54 +0000 (UTC) Received: by mail-yh0-f45.google.com with SMTP id f10so44675yha.18; Tue, 06 Jan 2015 13:25:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=QweXJqEqC6t2TCjajJIwiUytgJj5Z6Ti3ExZQVjFW80=; b=PGqpBzTPnYSRjKeB2Udj6p0qh30vnGQbNe3ypOxbqnflRwzXrtKbKR/hLQzhmvAv0y Qeu1ej8KEACW+kKMzh/5UsKGLR/gzk3AIfQZKtAfEXwe+fOkXgdJ4XCVh1FaXJlHyF+C hb7Qqbai+cXLaSkOjBUL4vcBAfYixqyH81Hu5TSWmV+emOYs/NNQHV68nAuHqm430zdH DnUPegyjvFDyoIwS5T1nOsz0AfPCHY6wd2uYzuwNJg8KsqMg2hC6YHvAFD5Fk0D7JAW6 4jXkIUInvNT3DqtAh6GaxE5LGDEbNjTH7hiQvsUp+Vgzos38VEtxW8YLx5AzE7r2vhIu 5Wbw== MIME-Version: 1.0 X-Received: by 10.236.1.97 with SMTP id 61mr36608840yhc.78.1420579553504; Tue, 06 Jan 2015 13:25:53 -0800 (PST) Received: by 10.170.186.214 with HTTP; Tue, 6 Jan 2015 13:25:53 -0800 (PST) Date: Tue, 6 Jan 2015 23:25:53 +0200 Message-ID: Subject: Populating /var from files or command From: Guy Yur To: freebsd-arch@freebsd.org, freebsd-rc@freebsd.org Content-Type: multipart/mixed; boundary=001a11333f64a99707050c02739c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 21:25:54 -0000 --001a11333f64a99707050c02739c Content-Type: text/plain; charset=UTF-8 Hi, What do you think about adding support to var rc script to populate /var from files or command? Attached patch adds three variables: 1. populate_var_mtree_enable Enable/disable populating /var from mtree. Defaults to YES to keep current behavior. 2. populate_var_files Files to be copied to /var (similar to mdconfig_md_files) 3. populate_var_cmd Command to run to populate /var (similar to mdconfig_md_cmd) There is one behavior change. If you set populate_var="YES" with mtree and /usr fails to mount, the script will now exit with error. If there is a use case for a non-empty /var, a separate /usr and still wanting to set populate_var="YES" I can modify the checks. Some examples: Keeping a var.tgz on a read-only root file system and extracting it. /var is tmpfs specified in /etc/fstab or varmfs. populate_var="YES" populate_var_cmd="/usr/bin/tar xfzC /etc/var.tgz /var" (add "mount /usr && " before tar if /usr is a separate file system) Keeping a var source dir on root and copying the files from it. Mtree can be skipped if the source dir contains all the subdirs. populate_var="YES" populate_var_mtree_enable="NO" populate_var_files="/etc/var/*" or populate_var_files="/_var/*" - Guy --001a11333f64a99707050c02739c Content-Type: application/octet-stream; name="populate_var_files.patch" Content-Disposition: attachment; filename="populate_var_files.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i4lrybyf0 SW5kZXg6IGV0Yy9kZWZhdWx0cy9yYy5jb25mCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGV0Yy9kZWZhdWx0cy9y Yy5jb25mCShyZXZpc2lvbiAyNzY3NTgpCisrKyBldGMvZGVmYXVsdHMvcmMuY29uZgkod29ya2lu ZyBjb3B5KQpAQCAtNTIsNiArNTIsOSBAQCB2YXJtZnM9IkFVVE8iCQkjIFNldCB0byBZRVMgdG8g YWx3YXlzIGNyZWF0ZSBhbiBtZgogdmFyc2l6ZT0iMzJtIgkJIyBTaXplIG9mIG1mcyAvdmFyIGlm IGNyZWF0ZWQKIHZhcm1mc19mbGFncz0iLVMiCSMgRXh0cmEgbW91bnQgb3B0aW9ucyBmb3IgdGhl IG1mcyAvdmFyCiBwb3B1bGF0ZV92YXI9IkFVVE8iCSMgU2V0IHRvIFlFUyB0byBhbHdheXMgKHJl KXBvcHVsYXRlIC92YXIsIE5PIHRvIG5ldmVyCitwb3B1bGF0ZV92YXJfbXRyZWVfZW5hYmxlPSJZ RVMiCSMgVXNlIG10cmVlKDgpIHRvIChyZSlwb3B1bGF0ZSAvdmFyCisjcG9wdWxhdGVfdmFyX2Zp bGVzPSIiCSMgRmlsZXMgdG8gYmUgY29waWVkIHRvIC92YXIKKyNwb3B1bGF0ZV92YXJfY21kPSIi CSMgQ29tbWFuZCB0byBleGVjdXRlIGZvciAocmUpcG9wdWxhdGluZyAvdmFyCiBjbGVhbnZhcl9l bmFibGU9IllFUyIgCSMgQ2xlYW4gdGhlIC92YXIgZGlyZWN0b3J5CiBsb2NhbF9zdGFydHVwPSIv dXNyL2xvY2FsL2V0Yy9yYy5kIiAjIHN0YXJ0dXAgc2NyaXB0IGRpcnMuCiBzY3JpcHRfbmFtZV9z ZXA9IiAiCSMgQ2hhbmdlIGlmIHlvdXIgc3RhcnR1cCBzY3JpcHRzJyBuYW1lcyBjb250YWluIHNw YWNlcwpJbmRleDogZXRjL3JjLmQvdmFyCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGV0Yy9yYy5kL3ZhcgkocmV2 aXNpb24gMjc2NzU4KQorKysgZXRjL3JjLmQvdmFyCSh3b3JraW5nIGNvcHkpCkBAIC00MSwxNCAr NDEsMzMgQEAgbG9hZF9yY19jb25maWcgJG5hbWUKIAogcG9wdWxhdGVfdmFyKCkKIHsKLQkvdXNy L3NiaW4vbXRyZWUgLWRlVSAtZiAvZXRjL210cmVlL0JTRC52YXIuZGlzdCAtcCAvdmFyID4gL2Rl di9udWxsCi0JY2FzZSAke3NlbmRtYWlsX2VuYWJsZX0gaW4KLQlbTm5dW09vXVtObl1bRWVdKQor CWNhc2UgJHtwb3B1bGF0ZV92YXJfbXRyZWVfZW5hYmxlfSBpbgorCVtObl1bT29dKQogCQk7Owog CSopCi0JCS91c3Ivc2Jpbi9tdHJlZSAtZGVVIC1mIC9ldGMvbXRyZWUvQlNELnNlbmRtYWlsLmRp c3QgLXAgLyA+IC9kZXYvbnVsbAorCQlpZiBbICEgLXggL3Vzci9zYmluL210cmVlIF07IHRoZW4K KwkJCSMgV2UgbmVlZCBtdHJlZSB0byBwb3B1bGF0ZSAvdmFyIHNvIHRyeSBtb3VudGluZyAvdXNy LgorCQkJIyBJZiB0aGlzIGRvZXMgbm90IHdvcmssIHdlIGNhbiBub3QgYm9vdCBzbyBpdCBpcyBP SyB0bworCQkJIyB0cnkgdG8gbW91bnQgb3V0IG9mIG9yZGVyLgorCQkJbW91bnQgL3VzcgorCQkJ WyAhIC14IC91c3Ivc2Jpbi9tdHJlZSBdICYmIGV4aXQgMQorCQlmaQorCQkvdXNyL3NiaW4vbXRy ZWUgLWRlVSAtZiAvZXRjL210cmVlL0JTRC52YXIuZGlzdCAtcCAvdmFyID4gL2Rldi9udWxsCisJ CWNhc2UgJHtzZW5kbWFpbF9lbmFibGV9IGluCisJCVtObl1bT29dW05uXVtFZV0pCisJCQk7Owor CQkqKQorCQkJL3Vzci9zYmluL210cmVlIC1kZVUgLWYgL2V0Yy9tdHJlZS9CU0Quc2VuZG1haWwu ZGlzdCAtcCAvID4gL2Rldi9udWxsCisJCQk7OworCQllc2FjCiAJCTs7CiAJZXNhYworCWlmIFsg LW4gIiR7cG9wdWxhdGVfdmFyX2ZpbGVzfSIgXTsgdGhlbgorCQljcCAtUnAgJHtwb3B1bGF0ZV92 YXJfZmlsZXN9IC92YXIKKwlmaQorCWlmIFsgLW4gIiR7cG9wdWxhdGVfdmFyX2NtZH0iIF07IHRo ZW4KKwkJZXZhbCAke3BvcHVsYXRlX3Zhcl9jbWR9CisJZmkKIH0KIAogIyBJZiB3ZSBkbyBub3Qg aGF2ZSBhIHdyaXRhYmxlIC92YXIsIGNyZWF0ZSBhIG1lbW9yeSBmaWxlc3lzdGVtIGZvciAvdmFy CkBAIC03MSw5ICs5MCw3IEBAIGNhc2UgIiR7dmFybWZzfSIgaW4KIGVzYWMKIAogCi0jIElmIHdl IGhhdmUgYW4gZW1wdHkgbG9va2luZyAvdmFyLCBwb3B1bGF0ZSBpdCwgYnV0IG9ubHkgaWYgd2Ug aGF2ZQotIyAvdXNyIGF2YWlsYWJsZS4gIEhvcGVmdWxseSwgd2UnbGwgZXZlbnR1YWxseSBmaW5k IGEgd29ya2Fyb3VuZCwgYnV0Ci0jIGluIHJlYWxpc3RpYyBkaXNrbGVzcyBzZXR1cHMsIHdlJ3Jl IHByb2JhYmx5IG9rLgorIyBJZiBleHBsaWNpdGx5IHJlcXVlc3RlZCBvciB3ZSBoYXZlIGFuIGVt cHR5IGxvb2tpbmcgL3ZhciwgcG9wdWxhdGUgaXQuCiBjYXNlICIke3BvcHVsYXRlX3Zhcn0iIGlu CiBbWXldW0VlXVtTc10pCiAJcG9wdWxhdGVfdmFyCkBAIC04NCwxOCArMTAxLDggQEAgY2FzZSAi JHtwb3B1bGF0ZV92YXJ9IiBpbgogKikKIAlpZiBbIC1kIC92YXIvcnVuIC1hIC1kIC92YXIvZGIg LWEgLWQgL3Zhci9lbXB0eSBdIDsgdGhlbgogCQl0cnVlCi0JZWxpZiBbIC14IC91c3Ivc2Jpbi9t dHJlZSBdIDsgdGhlbgorCWVsc2UKIAkJcG9wdWxhdGVfdmFyCi0JZWxzZQotCQkjIFdlIG5lZWQg bXRyZWUgdG8gcG9wdWxhdGUgL3ZhciBzbyB0cnkgbW91bnRpbmcgL3Vzci4KLQkJIyBJZiB0aGlz IGRvZXMgbm90IHdvcmssIHdlIGNhbiBub3QgYm9vdCBzbyBpdCBpcyBPSyB0bwotCQkjIHRyeSB0 byBtb3VudCBvdXQgb2Ygb3JkZXIuCi0JCW1vdW50IC91c3IKLQkJaWYgWyAhIC14IC91c3Ivc2Jp bi9tdHJlZSBdIDsgdGhlbgotCQkJZXhpdCAxCi0JCWVsc2UKLQkJCXBvcHVsYXRlX3ZhcgotCQlm aQogCWZpCiAJOzsKIGVzYWMKSW5kZXg6IHNoYXJlL21hbi9tYW41L3JjLmNvbmYuNQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09Ci0tLSBzaGFyZS9tYW4vbWFuNS9yYy5jb25mLjUJKHJldmlzaW9uIDI3Njc1OCkKKysrIHNo YXJlL21hbi9tYW41L3JjLmNvbmYuNQkod29ya2luZyBjb3B5KQpAQCAtMzg2LDYgKzM4NiwyNyBA QCBOb3RlIHRoYXQgdGhpcyBwcm9jZXNzIHJlcXVpcmVzIGFjY2VzcyB0byBjZXJ0YWluCiBiZWZv cmUKIC5QYSAvdXNyCiBpcyBtb3VudGVkIG9uIG5vcm1hbCBzeXN0ZW1zLgorLkl0IFZhIHBvcHVs YXRlX3Zhcl9tdHJlZV9lbmFibGUKKy5QcSBWdCBib29sCitVc2UKKy5YciBtdHJlZSA4Cit0byBw b3B1bGF0ZQorLlBhIC92YXIKK2FmdGVyIGl0IGhhcyBiZWVuIG1vdW50ZWQuCitEZWZhdWx0IGlz CisuRHEgTGkgWUVTIC4KKy5JdCBWYSBwb3B1bGF0ZV92YXJfZmlsZXMKKy5QcSBWdCBzdHIKK0Zp bGVzIHRvIGJlIGNvcGllZCB0bworLlBhIC92YXIKK2FmdGVyIGl0IGhhcyBiZWVuIG1vdW50ZWQu CisuSXQgVmEgcG9wdWxhdGVfdmFyX2NtZAorLlBxIFZ0IHN0cgorQ29tbWFuZCB0byBleGVjdXRl IGFmdGVyCisuUGEgL3ZhcgoraGFzIGJlZW4gbW91bnRlZC4KK05vdGUgdGhhdCB0aGUgY29tbWFu ZCBpcyBwYXNzZWQgdG8KKy5JYyBldmFsLgogLkl0IFZhIGNsZWFudmFyX2VuYWJsZQogLlBxIFZ0 IGJvb2wKIENsZWFuIHRoZQo= --001a11333f64a99707050c02739c-- From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 22:51:09 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F8EBBAD; Tue, 6 Jan 2015 22:51:09 +0000 (UTC) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4376EA7C; Tue, 6 Jan 2015 22:51:09 +0000 (UTC) Received: by mail-pa0-f44.google.com with SMTP id et14so662831pad.3; Tue, 06 Jan 2015 14:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=4SQvoNOexqCzMGszZZ+YXu9qjH4PB0YrUb99epCa/NQ=; b=MLYqA08tpZfW3b/KQ1uxabWL2zqtt2DEQdMWp75P6Zf9B3kmtHGQAlgEssx5lDyJ+M MQUKerOP/saWugo11gcAxnlN0R+DGqqR6lAJSsIglywOAdLt3r4UAkOBGrTcOMdXOAUK 1P9VmbzblFz9bTbtgcS+S6ZUVCOVCyppZvti2sLroHwIuPr1gnHXtscFEKhALq2gK9ND 6ScI2GWc6s8rsrAhGirwKKsWx+sFLw4ymHig5E1cxwMZZTjtv5v8Hfb2fHkWP6P0yH/b A1R7XM5dTnOD362FM7gLK7XJ/WnvmbJh4SX7EFzv4c8g6jxusBXLioyc6cuM8iYr2343 NVyQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=erj.cc; s=ericroxx; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=4SQvoNOexqCzMGszZZ+YXu9qjH4PB0YrUb99epCa/NQ=; b=rFrBsV4aBVqY+t+pm55ToPCafZNeEWaqJMIVVUkaWr6Tz9j73i7JU5U+iJe9S7iYJ9 Un5Q3Ej0C81zxbfe/imDovu3KeplGxfwxnKcuTSZ8nUIJY8NA22lZVdbRjvom1c4IiZd QB76YPCvqctkzGA+qnmEuh53t90UHZP9hSH2E= X-Received: by 10.66.141.197 with SMTP id rq5mr112415979pab.118.1420584668801; Tue, 06 Jan 2015 14:51:08 -0800 (PST) MIME-Version: 1.0 Sender: ricera10@gmail.com Received: by 10.70.89.209 with HTTP; Tue, 6 Jan 2015 14:50:28 -0800 (PST) In-Reply-To: <201412130106.sBD16tgl072730@mail.karels.net> References: <2116096.l1vR0RuKRU@ralph.baldwin.cx> <201412130106.sBD16tgl072730@mail.karels.net> From: Eric Joyner Date: Tue, 6 Jan 2015 14:50:28 -0800 X-Google-Sender-Auth: ipy0MCiE36PaVM6w-CtdKxEn9js Message-ID: Subject: Re: Adding new media types to if_media.h To: mike@karels.net Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Adrian Chadd , Rui Paulo , "freebsd-net@freebsd.org" , Eric Joyner , John Baldwin , Jack Vogel , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 22:51:09 -0000 Then going with what Mike says about leaving backwards compatibility, I suppose we should do something like what Adrian suggested, and add a separate struct. We can indicate that the separate struct exists by setting the media type value in the if_media word to 0xc0, since that's the last unused value. Then existing programs won't have to support any new features if they don't want to. Adrian -- where can I look for more information on what net80211 does for media types? Do you mean what it does with MCS values, or something more; I've looked at it a bit, but I don't know very much about how Wi-Fi works. - Eric On Fri, Dec 12, 2014 at 5:06 PM, Mike Karels wrote: > > On Friday, December 12, 2014 12:26:24 PM Jack Vogel wrote: > > > I think I'd go along with Mike, keeping it simpler seems like a good > idea. > > > > > > Jack > > > If the userland ABI impact isn't too broad I think this is fine. Mike, > do you > > know off hand how many user-facing things would be affected? > > I didn't know off hand, but I have a glimpse index at $WORK (it's for > McAfee > Firewall Enterprise, aka Sidewinder, based on 8.2). I found 45 references > to > if_media.h at user level, including "ports" that we use, and excluding our > own software. The list includes libpcap, snmpd, dhclient, quagga, xorp, > atm, devd, and rtsold. fwiw, I found about 260 inclusions of if_media.h > in the kernel. > > This suggests that we should preserve a backward-compatible user API, even > if it has limits. Unfortunately, the media word I mentioned is a plain > int, > not a typedef. I would propose a similar API that is not limited, but easy > to convert (e.g. using a new typedef). I'd be willing to sketch out > something > like that. > > > > On Fri, Dec 12, 2014 at 6:39 AM, Mike Karels wrote: > > > > > Any other thoughts, or should I start looking at seeing what I can > take > > > > > copy from net80211? > > > > > > > > > > Also adding -net, since this is pretty relevant. > > > > > > > > I had the same reaction as Adrian initially, as an int with numerous > > > > fields > > > > seems really messy. However, I don't think we have the challenges of > > > > 802.11, > > > > and the only real problem is that the subtype field has run out of > bits. > > > > And both ifconfig and the drivers are cast in the form of a scalar > "media > > > > word", with parameters to ifmedia_add like IFM_ETHER | IFM_1000_T | > > > > IFM_FDX > > > > (assuming that all the bits are in a scalar). > > > > > > > > Instead, I would propose that we simply change the media word from > 32 bits > > > > to 64, and move the subtype from its current location to a new field > (e.g. > > > > 16 bits) in the new space. I believe this can be KPI compatible, > and it > > > > is relatively easy to provide a backward-compatible ABI. There > should be > > > > a reserved subtype for "other" that can be encoded in the existing > field > > > > for use when the subtype can't fit in the old field. This seems much > > > > easier, > > > > can be KPI compatible, and will make it much easier to backport > drivers. > > > > A backport could simply define the new subtypes as "other", and the > KPI > > > > would still be compatible. > > > > > > > > Thoughts? > > > > > > > > Mike > > > -- > > John Baldwin > > Mike > From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 23:10:51 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5B9F4479; Tue, 6 Jan 2015 23:10:51 +0000 (UTC) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E1C3EDE3; Tue, 6 Jan 2015 23:10:50 +0000 (UTC) Received: by mail-wi0-f173.google.com with SMTP id r20so6361876wiv.12; Tue, 06 Jan 2015 15:10:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lnrLaNsFaFkFMjelQPyk8KgJabfGUzCgSP1eLfyynQA=; b=gIiFWNj8dhfoG5SQdojgEn9V0RR0wVnZlg/AF42yCruGfy/hU3Q9ulfb9pfEndkJ43 h0NqmBrFVDXFe2d23unjDJu4uQDmtVdlIVO69J0YllD/tCFg/hXlkefoZsaxhpkSsZ3B hnH4+bY/yyq1Aq2RAo5j/Np5cOpyCO1TfG7w9nZTstPf1pYI4TU3zwnecW7qM5HcormY 23sU/xfz2QW3c/FYJzuHrT54Dj3hgvVtPKN9sKosMbmpPWWxvJx3o6g4lzbLm2lblU7W E/Uz5fE/fQLwRWRyj0u7f86sK4GBxr2jOlZEo+OjyHH1Xbm34Dqt1OA9i4KkEcI+PbFd 6hrw== MIME-Version: 1.0 X-Received: by 10.180.73.108 with SMTP id k12mr1275504wiv.24.1420585849407; Tue, 06 Jan 2015 15:10:49 -0800 (PST) Received: by 10.217.118.194 with HTTP; Tue, 6 Jan 2015 15:10:49 -0800 (PST) In-Reply-To: <54A9A71E.70609@selasky.org> References: <54A1B38C.1000709@selasky.org> <20150101005613.4f788b0c@nonamehost.local> <54A49CA5.2060801@selasky.org> <54A4A002.8010802@selasky.org> <54A53F4F.2000003@selasky.org> <54A92ED1.2070906@selasky.org> <54A9A71E.70609@selasky.org> Date: Tue, 6 Jan 2015 16:10:49 -0700 Message-ID: Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress From: Jason Wolfe To: Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 Cc: Adrian Chadd , FreeBSD Current , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 23:10:51 -0000 On Sun, Jan 4, 2015 at 1:48 PM, Hans Petter Selasky wrote: > On 01/04/15 19:58, Adrian Chadd wrote: >> >> Hi! >> >> Can you throw this into reviews.freebsd.org please? This is something >> that should be very closely reviewed and tested. >> >> (I'm going to go over this quite closely as it related to a lot of the >> random crap I do ..) >> > > Hi Adrian, > > Here you go: > > https://reviews.freebsd.org/D1438 > > Thank you for your time to review this! > > > --HPS Hans, We've been running into 'spin lock held too long' panics in the kernel idle threads on 10-STABLE over the past 6 months, so I was interested to see your work here in the callout code. I went ahead and brought this patch back to a recent 10.1-STABLE base without much issue, kern_timeout.c was actually the only piece with some easily resolvable rejections. I've had a box running stable under load with this patch for a few days, and 10 more have just been added to the rotation. Anyway just figured you might be interested in the some feedback while the changes are reviewed. Thanks! Jason From owner-freebsd-arch@FreeBSD.ORG Tue Jan 6 23:12:53 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E8716569 for ; Tue, 6 Jan 2015 23:12:53 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8D3AE20 for ; Tue, 6 Jan 2015 23:12:53 +0000 (UTC) Received: from [10.12.76.127] (llnw-corp-src.phx2.llnw.com [69.164.56.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 0C434192A3B for ; Tue, 6 Jan 2015 23:12:51 +0000 (UTC) Message-ID: <54AC6BEC.2020500@ignoranthack.me> Date: Tue, 06 Jan 2015 15:12:44 -0800 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-arch@freebsd.org Subject: How to use an external tool chain, mips/mips64 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2015 23:12:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 In an effort to help out migration of our tool chains, I've started to play with clang/llvm trunk to see what the mips/mips64 support looks like. I don't know the correct-foo to do a buildworld, but this is what I've tried: Build a valid toolchain: http://clang.llvm.org/get_started.html This allows me to use /home/sbruno/build/Debug+Asserts/bin/ as my toolchain dir Symlink clang -> cc and clang++ ->cpp Try a buildworld for TARGET=3Dmips TARGET_ARCH=3Dmips make TARGET=3Dmips TARGET_ARCH=3Dmips CROSS_TOOLCHAIN_PREFIX=3D/home/sbruno/build/Debug+Asserts/bin/ buildworld= This fails, as I haven't setup the assembler correctly or something.=20 I'm not sure. https://people.freebsd.org/~sbruno/full_mips_log.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUrGvpXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kZq0H/j/ZmVVpvUXxaqBKa4+17ERH j6A8L9dyuBU6sFlZ7KbPYq4iOQyAfPYnu1l75FPEu1m7G+GqxDLtPnXiGOsoGFKR CkNz3/oBtlHm2edWRA7kHraiTR5COW3i+DfrCumDkYV5EcRClFR6I4vl19bxs3pW VFpnFcUsnvac29J6Qlz4JBxco9eLqoeeqBjHHazuxL6AZGxew5YgjIcQY/onFhNS jQJ6PXLe/+BXSdf+lRG43wkLroNOPqO63RMwdYYIHJHGYpPvxmSIVwZPwn29UDW0 jc8Th4gwucy4LBgRQ1HFHmHQNr15vAkWz5SxGoxTUfdu4trzrHtvZl25rPEKKbI=3D =3D9IsJ -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Wed Jan 7 00:02:39 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E252329F for ; Wed, 7 Jan 2015 00:02:39 +0000 (UTC) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B255E64683 for ; Wed, 7 Jan 2015 00:02:39 +0000 (UTC) Received: by mail-pd0-f180.google.com with SMTP id fl12so891947pdb.11 for ; Tue, 06 Jan 2015 16:02:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=6yIUIDv9fomiccrvBn2M0ErWZD0VLKiXx0xe5+dFAXE=; b=KUctvg+as/S3nhNQqrgQ4Yc7OaoofF349Bmijo83zYOFqyDiQ7gQtciRnEojs9d8ZD +WvNl627BwUYsJNIgA+ue/UEfYspC3HKWqcWenn+I6rW85H90b5dBfiEkHyjK3civPah 9EXFAExTl8Vetcj8Iqn4seApIoZ3n5P8g+tW29To5CnHqZX/X+7gKS4BabrTJ9pBhZ7J vAf39mR84MUlIsDmdzq2D8L1mqeoOFyFlzdR6N3LAqXwkZIzepGeyaY8MFkBljb4Zszz 0jE6Rdviq59pKK/xCwoQuO/YWLJ18y1OeeF4QohEmpsdvJ61h06SmKRBMWuVJHQeIwT8 eYJQ== X-Gm-Message-State: ALoCoQmICzJwPCcbRU3CRmyII94QLDq1vw8AVFYP2dPYO2zvQp2I6xzEm6R5fal8JyW8x31apFD4 X-Received: by 10.70.96.162 with SMTP id dt2mr160575205pdb.57.1420588952913; Tue, 06 Jan 2015 16:02:32 -0800 (PST) Received: from [10.64.26.233] ([69.53.236.236]) by mx.google.com with ESMTPSA id ju5sm11340pab.42.2015.01.06.16.02.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Jan 2015 16:02:32 -0800 (PST) Sender: Warner Losh Subject: Re: How to use an external tool chain, mips/mips64 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_564E6E1F-6E37-4491-9EC2-662496EF4BA8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b3 From: Warner Losh In-Reply-To: <54AC6BEC.2020500@ignoranthack.me> Date: Tue, 6 Jan 2015 17:02:29 -0700 Message-Id: References: <54AC6BEC.2020500@ignoranthack.me> To: sbruno@freebsd.org X-Mailer: Apple Mail (2.1993) Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 00:02:40 -0000 --Apple-Mail=_564E6E1F-6E37-4491-9EC2-662496EF4BA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 6, 2015, at 4:12 PM, Sean Bruno wrote: >=20 > As a hack, try the following. Try adding -no-integrated-as in bsd.cpu.mk = where we are currently adding -G0 (and keep -G0, it=E2=80=99s also important). Warner --Apple-Mail=_564E6E1F-6E37-4491-9EC2-662496EF4BA8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUrHeWAAoJEGwc0Sh9sBEAE4UP/iAcjALhDusebzJvrHZocwVu 32YiZF/OVd5CVMbCFFbizN00RJEI6RNZjKWHmTXmczvPOewcDfjJgcSOOFuv55sx PlCj8SchttEO0L1ZvA0A5xa1KcAqQSaqE1efH/fAvGTQ7H10uoxeaJtJTvyXZ/P8 4mG9nHMIdx1sLlk7AY/cg2PVxurq9b0ahMhjOs5RaW8tT7jjg+qT3O1tv1CXJxRW 0Qn1RwIh9g/yQ4jROzlpWMJdKnw3QA4qGFXnDcb2dpv96sTqyBcwpzX7+LI2pClH EiyFCGlTtWn3OT16Ghj3s7IXVwYdmpT3eUcOgXMPbZYBp60NiD8AQ//iCTf/PHtR fDnr57GWw3TyOnFr1pi87VPaxJUzQ4trUP9pMGWABu5Y/gZlAp2dPxAfTMsEMcGI U1NHu0+vVBzMLAzeWGGGDqUnGmP+wEgOahfRtjv3Rqwyw9zmB/MhbP5r1vyLybf+ o/UXfTcYc8xg7X7hzjRQM/BlptgzGPeQwMc6CH6CKGIGSWPtD6d9x2+wRRnswDN1 cLGlTLLgWcqfPxlfmaZG28Ornxt7rvg3cM3LATF2o5xnCmjfZqhzGBD7ivodY3rb Cjb0d581yXpOKKV98ecvLM4rqFl79y7vZ1zReL4k3MUuRDhU6tSUYqea7V2wbkj1 cgzk8DHe0NzDAVYeRsYG =YntV -----END PGP SIGNATURE----- --Apple-Mail=_564E6E1F-6E37-4491-9EC2-662496EF4BA8-- From owner-freebsd-arch@FreeBSD.ORG Wed Jan 7 00:09:27 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E482D448; Wed, 7 Jan 2015 00:09:26 +0000 (UTC) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7574B646FF; Wed, 7 Jan 2015 00:09:26 +0000 (UTC) Received: by mail-wg0-f46.google.com with SMTP id x13so248605wgg.19; Tue, 06 Jan 2015 16:09:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=NS44vkc7bgIl/ds//nP+CVEerhOgsy/9PEhblCmvucY=; b=wrNWe6NaiRqhtuKuGZ53IdrZ5fL7V9bjrlh5FN/qW8fWVVv4fqcxAj8sIl+53b6QR+ WASwPUfkLCVFtB4PYa+EIH+sz5b5nAF8pxzFR/mAc7t5KL9J9qSW84I1XgPBXJj3e6lT fD1aZOHwCbh1Pq27lIxC+ZM2ZOyElev2dC+5DAJ0w/W/KYidNPLAi9SWFj9iwiBFhv7w 15anMI450a8Tq3PajKtXDVN0TaVOzcZRbSFsllhn136TUdRtGrRRaUh57DFwV7yxmW3r pY00YkTRQiTxpJzDvS2sHeDNJsNzIMwmg/zUgHKZhhEjG/K++Ok3dq+xIFP3FmlvV9Yo W7cA== MIME-Version: 1.0 X-Received: by 10.194.5.37 with SMTP id p5mr371489wjp.20.1420589364856; Tue, 06 Jan 2015 16:09:24 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.41.136 with HTTP; Tue, 6 Jan 2015 16:09:24 -0800 (PST) In-Reply-To: References: <2116096.l1vR0RuKRU@ralph.baldwin.cx> <201412130106.sBD16tgl072730@mail.karels.net> Date: Tue, 6 Jan 2015 16:09:24 -0800 X-Google-Sender-Auth: zTxRoPSVw4orkcXeKarMLcJHczg Message-ID: Subject: Re: Adding new media types to if_media.h From: Adrian Chadd To: Eric Joyner Content-Type: text/plain; charset=UTF-8 Cc: mike@karels.net, Rui Paulo , "freebsd-net@freebsd.org" , John Baldwin , Jack Vogel , "freebsd-arch@freebsd.org" X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 00:09:27 -0000 On 6 January 2015 at 14:50, Eric Joyner wrote: > Then going with what Mike says about leaving backwards compatibility, I > suppose we should do something like what Adrian suggested, and add a > separate struct. We can indicate that the separate struct exists by setting > the media type value in the if_media word to 0xc0, since that's the last > unused value. Then existing programs won't have to support any new features > if they don't want to. > > Adrian -- where can I look for more information on what net80211 does for > media types? Do you mean what it does with MCS values, or something more; > I've looked at it a bit, but I don't know very much about how Wi-Fi works. Well, my idea is that there's parts of ifmedia that's related to the interface state that we care about, and some of it is just presentation related stuff that's opaque to the stack and only relevant for userland and for the driver/phy bits. The tricky bit is breaking the ifmedia API. It's not included as a pointer inside things - it's embedded as an actual struct. It's embedded inside net80211, but other than that and if_lagg I think it's mostly done inside drivers. So maybe we want to turn its use into allocate/free rather than embedded inside the struct; maybe we don't. Second is how we split up the bits that are mediatype-dependent versus the bits that are related to the network stack. My idea is just to break out each ifmedia field into an int each: * if_media Options word: * Bits Use * ---- ------- * 0-4 Media variant * 5-7 Media type * 8-15 Type specific options * 16-18 Mode (for multi-mode devices) * 19 RFU * 20-27 Shared (global) options * 28-31 Instance .. because I think it'll be easier in the long run to just have uint32_t fields for each of these. The general network stack shouldn't care about type, options and mode. It'll be a lot of churn, but I think it's cleaner than trying to continue doing dirty bitmap things. So: * do we break ifmedia use up into a pointer / allocated thing, rather than an embedded struct, with all the driver churn that'll entail; * do we just add a new field for type/options and have a magic type that's "other", or do we just go for breaking each option out into a field in a struct and have accessor methods to get access to things. What do people think? -adrian From owner-freebsd-arch@FreeBSD.ORG Wed Jan 7 01:23:29 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CB134648 for ; Wed, 7 Jan 2015 01:23:29 +0000 (UTC) Received: from mail.ignoranthack.me (ignoranthack.me [199.102.79.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9C9F12B8 for ; Wed, 7 Jan 2015 01:23:29 +0000 (UTC) Received: from [10.12.76.127] (llnw-corp-src.phx2.llnw.com [69.164.56.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: sbruno@ignoranthack.me) by mail.ignoranthack.me (Postfix) with ESMTPSA id 312EA192A3B; Wed, 7 Jan 2015 01:23:21 +0000 (UTC) Message-ID: <54AC8A87.3090301@ignoranthack.me> Date: Tue, 06 Jan 2015 18:23:19 -0700 From: Sean Bruno Reply-To: sbruno@freebsd.org User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: How to use an external tool chain, mips/mips64 References: <54AC6BEC.2020500@ignoranthack.me> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 01:23:29 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/06/15 17:02, Warner Losh wrote: > >> On Jan 6, 2015, at 4:12 PM, Sean Bruno >> wrote: >> >> > > As a hack, try the following. Try adding -no-integrated-as in > bsd.cpu.mk where we are currently adding -G0 (and keep -G0, it’s > also important). > > Warner > I already chatted with Warner in irc, so logging here that this didn't help the situation. sean -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAEBCgBmBQJUrIqFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRCQUFENDYzMkU3MTIxREU4RDIwOTk3REQx MjAxRUZDQTFFNzI3RTY0AAoJEBIB78oecn5kslcIALRGUDGxFC6LtTh50Idv4Yir 5qheZdONe2WoK5QHjABLqEnZDDR8eTwNFeeQst2CaUdnH9fOpSQ52JskUj8suRCM 0IIm0+u1KQ4WYOxOLVtL2dzGr+tXpueXaBB0scNStfdJnb0/2XPCeIqfz63ZdlGE e9eH/RyEGgQwgSl2HuGGHy4l8qP8H52bfKcoeyOiakxU3Db5fN0s7iZDF8zJhTVH Bk+TByU/zRpFqY/mnO1dujzztqXf6ghrzngwITXQKrjizhs3ZzucrOqELG8eJFrz TjhRP3z+aVDumOr8f7zNObYWe3WvFquTJXv40OgieAe1Z4CrKg1Do+HPSeZVSS0= =4tLg -----END PGP SIGNATURE----- From owner-freebsd-arch@FreeBSD.ORG Wed Jan 7 00:12:39 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2F20785; Wed, 7 Jan 2015 00:12:38 +0000 (UTC) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0143.outbound.protection.outlook.com [207.46.100.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 95E276482F; Wed, 7 Jan 2015 00:12:38 +0000 (UTC) Received: from CO2PR05CA015.namprd05.prod.outlook.com (10.141.241.143) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.49.12; Wed, 7 Jan 2015 00:12:26 +0000 Received: from BL2FFO11FD026.protection.gbl (2a01:111:f400:7c09::119) by CO2PR05CA015.outlook.office365.com (2a01:111:e400:1429::15) with Microsoft SMTP Server (TLS) id 15.1.49.12 via Frontend Transport; Wed, 7 Jan 2015 00:12:25 +0000 Received: from P-EMF02-SAC.jnpr.net (66.129.239.16) by BL2FFO11FD026.mail.protection.outlook.com (10.173.161.105) with Microsoft SMTP Server (TLS) id 15.1.49.13 via Frontend Transport; Wed, 7 Jan 2015 00:12:25 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF02-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Tue, 6 Jan 2015 16:12:24 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id t070CLW34831; Tue, 6 Jan 2015 16:12:21 -0800 (PST) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id t070C0mO005107; Tue, 6 Jan 2015 19:12:01 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201501070012.t070C0mO005107@idle.juniper.net> To: "Simon J. Gerraty" Subject: Re: Libxo bugs and fixes. In-Reply-To: <2472.1420571203@chaos> Date: Tue, 6 Jan 2015 19:12:00 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.16 as permitted sender) Authentication-Results: spf=softfail (sender IP is 66.129.239.16) smtp.mailfrom=phil@juniper.net; X-Forefront-Antispam-Report: CIP:66.129.239.16; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(164054003)(51704005)(47776003)(20776003)(50986999)(64706001)(68736005)(76506005)(1941001)(105596002)(6806004)(84676001)(54356999)(4396001)(53416004)(110136001)(69596002)(2950100001)(77096005)(87936001)(99396003)(48376002)(107046002)(81156004)(106466001)(21056001)(92566001)(31966008)(86362001)(46102003)(50466002)(97736003)(77156002)(120916001)(62966003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:P-EMF02-SAC.jnpr.net; FPR:; SPF:SoftFail; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-DmarcAction: None X-Microsoft-Antispam: UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:(3005003);SRVR:CO1PR05MB443; X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004); SRVR:CO1PR05MB443; X-Forefront-PRVS: 044968D9E1 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB443; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2015 00:12:25.1778 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.16] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 X-Mailman-Approved-At: Wed, 07 Jan 2015 02:32:31 +0000 Cc: Alfred Perlstein , John-Mark Gurney , Alfred Perlstein , Marcel Moolenaar , "arch@freebsd.org" , Poul-Henning Kamp , Marcel Moolenaar , freebsd-arch , Konstantin Belousov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 00:12:39 -0000 "Simon J. Gerraty" writes: >Calling flush for every xo_* call would seem like a bad idea no? Yup, so callers would need to set the XOF_FLUSH flag by hand if they want this odd behavior. >The app/caller is the only one to know when a suitable flush point has >been reached (if necessary). > >It should suffice if xo_flush() does what the name implies. Cool. Then I'm done ;^) >If someone is using something other than stdio for a handle, they just >need to tell libxo a function to call in response to xo_flush ? Exactly. Or just flush it themselves in their write function, if they needed an immediate flushing model. >Does it need to be more complicated than that? Nope. Thanks, Phil From owner-freebsd-arch@FreeBSD.ORG Wed Jan 7 03:29:55 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C0DE824; Wed, 7 Jan 2015 03:29:55 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BB36E1839; Wed, 7 Jan 2015 03:29:54 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t073Tgua058112 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2015 05:29:42 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t073Tgua058112 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t073TfKw058111; Wed, 7 Jan 2015 05:29:41 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 7 Jan 2015 05:29:41 +0200 From: Konstantin Belousov To: Jilles Tjoelker Subject: Re: Fixing dlopen("libpthread.so") Message-ID: <20150107032941.GJ42409@kib.kiev.ua> References: <20141226165337.GJ1754@kib.kiev.ua> <20150103212837.GC46373@stack.nl> <20150104114600.GC42409@kib.kiev.ua> <20150104182026.GA61250@stack.nl> <20150105023708.GD42409@kib.kiev.ua> <20150106205046.GA24971@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150106205046.GA24971@stack.nl> User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: threads@freebsd.org, arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 03:29:55 -0000 On Tue, Jan 06, 2015 at 09:50:46PM +0100, Jilles Tjoelker wrote: > On Mon, Jan 05, 2015 at 04:37:08AM +0200, Konstantin Belousov wrote: > > accept <- calls accept4 now > > This is wrong since accept() copies various properties from the > listening to the new socket, which accept4() never does. (Note that > Linux accept() is equivalent to accept4() with 0 flags, so the > linuxolator can use such a shortcut.) Reverted this part. So it is not possible to emulate accept(2) with accept4(2) ? Does it make sense to add flag(s) to accept4(2) to copy nonblock and async from the listen socket ? > > > creat \ > > open <- openat > > pause <- there were actual bugs, pause called _sigprocmask and _sigsuspend > > raise <- I converted it to threaded kill > > sleep <- this one is tricky, but seems to work > > usleep > > wait > > wait3 > > waitpid > > These look OK. Updated patch is at the end. > > > > The changes look good to me. > > Next natural question is about the __error calls through PLT in the > > .cerror asm. Before the work was committed, libthr interposed __error, > > which was required for correct operation. Now, we need __error exported, > > but do we need support its interposing ? This is an implementation > > detail for errno, I do not see any loss from not allowing to override > > errno location. > > Indeed, there is no need to allow interposing __error (as with many > libc-internal calls to its exported symbols). Additionally, the current > namespace.h mechanism could be used to redirect __error calls from C > code. > > Glibc uses macro trickery with the asm labels compiler feature, making > libc code see things like > int *__error(void) asm("__hidden__error"); > and defining the hidden alias somewhere. This also works for > compiler-generated calls like to memcpy(). I'm not sure whether it is a > good idea to add this extra trickery and depend on the compiler feature. I might look at this after the current change is committed. > Glibc also has build-time checks that only specifically listed symbols > are referenced via the PLT. As well as e.g. libunwind. This would be a nice addition to currently empty set of ABI stability tests. diff --git a/lib/libc/compat-43/Symbol.map b/lib/libc/compat-43/Symbol.map index 2827705..bd49f99 100644 --- a/lib/libc/compat-43/Symbol.map +++ b/lib/libc/compat-43/Symbol.map @@ -28,5 +28,4 @@ FBSD_1.2 { FBSDprivate_1.0 { __creat; _creat; - __libc_creat; }; diff --git a/lib/libc/compat-43/creat.c b/lib/libc/compat-43/creat.c index 5ee4531..4545482 100644 --- a/lib/libc/compat-43/creat.c +++ b/lib/libc/compat-43/creat.c @@ -38,21 +38,16 @@ __FBSDID("$FreeBSD$"); #include "un-namespace.h" #include "libc_private.h" -__weak_reference(__libc_creat, __creat); -__weak_reference(__libc_creat, _creat); +__weak_reference(__creat, creat); +__weak_reference(__creat, _creat); #pragma weak creat int -creat(const char *path, mode_t mode) +__creat(const char *path, mode_t mode) { - return (((int (*)(const char *, mode_t)) - __libc_interposing[INTERPOS_creat])(path, mode)); + return (((int (*)(int, const char *, int, ...)) + __libc_interposing[INTERPOS_openat])(AT_FDCWD, path, O_WRONLY | + O_CREAT | O_TRUNC, mode)); } -int -__libc_creat(const char *path, mode_t mode) -{ - - return(__sys_open(path, O_WRONLY | O_CREAT | O_TRUNC, mode)); -} diff --git a/lib/libc/gen/Symbol.map b/lib/libc/gen/Symbol.map index e01a897..ee4d619 100644 --- a/lib/libc/gen/Symbol.map +++ b/lib/libc/gen/Symbol.map @@ -533,14 +533,7 @@ FBSDprivate_1.0 { _libc_sem_post_compat; _libc_sem_getvalue_compat; - __libc_pause; - __libc_raise; - __libc_sleep; __libc_tcdrain; - __libc_usleep; - __libc_wait; - __libc_wait3; - __libc_waitpid; __elf_aux_vector; __pthread_map_stacks_exec; diff --git a/lib/libc/gen/pause.c b/lib/libc/gen/pause.c index 97fbb01..ef48c1c 100644 --- a/lib/libc/gen/pause.c +++ b/lib/libc/gen/pause.c @@ -33,10 +33,8 @@ static char sccsid[] = "@(#)pause.c 8.1 (Berkeley) 6/4/93"; #include __FBSDID("$FreeBSD$"); -#include "namespace.h" #include #include -#include "un-namespace.h" #include "libc_private.h" @@ -44,23 +42,14 @@ __FBSDID("$FreeBSD$"); * Backwards compatible pause. */ int -__libc_pause(void) +__pause(void) { sigset_t oset; - if (_sigprocmask(SIG_BLOCK, NULL, &oset) == -1) + if (sigprocmask(SIG_BLOCK, NULL, &oset) == -1) return (-1); - return (_sigsuspend(&oset)); + return (sigsuspend(&oset)); } -#pragma weak pause -int -pause(void) -{ - - return (((int (*)(void)) - __libc_interposing[INTERPOS_pause])()); -} - -__weak_reference(__libc_pause, __pause); -__weak_reference(__libc_pause, _pause); +__weak_reference(__pause, pause); +__weak_reference(__pause, _pause); diff --git a/lib/libc/gen/raise.c b/lib/libc/gen/raise.c index d605639..994fea5 100644 --- a/lib/libc/gen/raise.c +++ b/lib/libc/gen/raise.c @@ -38,21 +38,15 @@ __FBSDID("$FreeBSD$"); #include "libc_private.h" -__weak_reference(__libc_raise, __raise); -__weak_reference(__libc_raise, _raise); +__weak_reference(__raise, raise); +__weak_reference(__raise, _raise); -#pragma weak raise int -raise(int s) +__raise(int s) { + long id; - return (((int (*)(int)) - __libc_interposing[INTERPOS_raise])(s)); -} - -int -__libc_raise(int s) -{ - - return (kill(getpid(), s)); + if (__sys_thr_self(&id) == -1) + return (-1); + return (__sys_thr_kill(id, s)); } diff --git a/lib/libc/gen/sleep.c b/lib/libc/gen/sleep.c index f558e36..6bb4ecd 100644 --- a/lib/libc/gen/sleep.c +++ b/lib/libc/gen/sleep.c @@ -42,17 +42,8 @@ __FBSDID("$FreeBSD$"); #include "libc_private.h" -#pragma weak sleep unsigned int -sleep(unsigned int seconds) -{ - - return (((unsigned int (*)(unsigned int)) - __libc_interposing[INTERPOS_sleep])(seconds)); -} - -unsigned int -__libc_sleep(unsigned int seconds) +__sleep(unsigned int seconds) { struct timespec time_to_sleep; struct timespec time_remaining; @@ -62,17 +53,19 @@ __libc_sleep(unsigned int seconds) * the maximum value for a time_t is >= INT_MAX. */ if (seconds > INT_MAX) - return (seconds - INT_MAX + __libc_sleep(INT_MAX)); + return (seconds - INT_MAX + __sleep(INT_MAX)); time_to_sleep.tv_sec = seconds; time_to_sleep.tv_nsec = 0; - if (_nanosleep(&time_to_sleep, &time_remaining) != -1) + if (((int (*)(const struct timespec *, struct timespec *)) + __libc_interposing[INTERPOS_nanosleep])( + &time_to_sleep, &time_remaining) != -1) return (0); if (errno != EINTR) return (seconds); /* best guess */ return (time_remaining.tv_sec + - (time_remaining.tv_nsec != 0)); /* round up */ + (time_remaining.tv_nsec != 0)); /* round up */ } -__weak_reference(__libc_sleep, __sleep); -__weak_reference(__libc_sleep, _sleep); +__weak_reference(__sleep, sleep); +__weak_reference(__sleep, _sleep); diff --git a/lib/libc/gen/usleep.c b/lib/libc/gen/usleep.c index 1d58b98..7c35f6c 100644 --- a/lib/libc/gen/usleep.c +++ b/lib/libc/gen/usleep.c @@ -40,24 +40,16 @@ __FBSDID("$FreeBSD$"); #include "libc_private.h" -#pragma weak usleep int -usleep(useconds_t useconds) -{ - - return (((int (*)(useconds_t)) - __libc_interposing[INTERPOS_usleep])(useconds)); -} - -int -__libc_usleep(useconds_t useconds) +__usleep(useconds_t useconds) { struct timespec time_to_sleep; time_to_sleep.tv_nsec = (useconds % 1000000) * 1000; time_to_sleep.tv_sec = useconds / 1000000; - return (_nanosleep(&time_to_sleep, NULL)); + return (((int (*)(const struct timespec *, struct timespec *)) + __libc_interposing[INTERPOS_nanosleep])(&time_to_sleep, NULL)); } -__weak_reference(__libc_usleep, __usleep); -__weak_reference(__libc_usleep, _usleep); +__weak_reference(__usleep, usleep); +__weak_reference(__usleep, _usleep); diff --git a/lib/libc/gen/wait.c b/lib/libc/gen/wait.c index dc1351d..46a3fdd 100644 --- a/lib/libc/gen/wait.c +++ b/lib/libc/gen/wait.c @@ -42,21 +42,13 @@ __FBSDID("$FreeBSD$"); #include "libc_private.h" -#pragma weak wait pid_t -wait(int *istat) +__wait(int *istat) { - return (((pid_t (*)(int *)) - __libc_interposing[INTERPOS_wait])(istat)); + return (((pid_t (*)(pid_t, int *, int, struct rusage *)) + __libc_interposing[INTERPOS_wait4])(WAIT_ANY, istat, 0, NULL)); } -pid_t -__libc_wait(int *istat) -{ - - return (__sys_wait4(WAIT_ANY, istat, 0, NULL)); -} - -__weak_reference(__libc_wait, __wait); -__weak_reference(__libc_wait, _wait); +__weak_reference(__wait, wait); +__weak_reference(__wait, _wait); diff --git a/lib/libc/gen/wait3.c b/lib/libc/gen/wait3.c index 2e116be..965effe 100644 --- a/lib/libc/gen/wait3.c +++ b/lib/libc/gen/wait3.c @@ -42,20 +42,12 @@ __FBSDID("$FreeBSD$"); #include "libc_private.h" -#pragma weak wait3 pid_t -wait3(int *istat, int options, struct rusage *rup) +__wait3(int *istat, int options, struct rusage *rup) { - return (((pid_t (*)(int *, int, struct rusage *)) - __libc_interposing[INTERPOS_wait3])(istat, options, rup)); + return (((pid_t (*)(pid_t, int *, int, struct rusage *)) + __libc_interposing[INTERPOS_wait4])(WAIT_ANY, istat, options, rup)); } -__weak_reference(__libc_wait3, __wait3); - -pid_t -__libc_wait3(int *istat, int options, struct rusage *rup) -{ - - return (__sys_wait4(WAIT_ANY, istat, options, rup)); -} +__weak_reference(__wait3, wait3); diff --git a/lib/libc/gen/waitpid.c b/lib/libc/gen/waitpid.c index 27e920f..5177591 100644 --- a/lib/libc/gen/waitpid.c +++ b/lib/libc/gen/waitpid.c @@ -42,21 +42,13 @@ __FBSDID("$FreeBSD$"); #include "libc_private.h" -#pragma weak waitpid pid_t -waitpid(pid_t pid, int *istat, int options) +__waitpid(pid_t pid, int *istat, int options) { - return (((pid_t (*)(pid_t, int *, int)) - __libc_interposing[INTERPOS_waitpid])(pid, istat, options)); + return (((pid_t (*)(pid_t, int *, int, struct rusage *)) + __libc_interposing[INTERPOS_wait4])(pid, istat, options, NULL)); } -pid_t -__libc_waitpid(pid_t pid, int *istat, int options) -{ - - return (__sys_wait4(pid, istat, options, NULL)); -} - -__weak_reference(__libc_waitpid, __waitpid); -__weak_reference(__libc_waitpid, _waitpid); +__weak_reference(__waitpid, waitpid); +__weak_reference(__waitpid, _waitpid); diff --git a/lib/libc/include/libc_private.h b/lib/libc/include/libc_private.h index ea1a97b..347b463 100644 --- a/lib/libc/include/libc_private.h +++ b/lib/libc/include/libc_private.h @@ -187,17 +187,14 @@ enum { INTERPOS_aio_suspend, INTERPOS_close, INTERPOS_connect, - INTERPOS_creat, INTERPOS_fcntl, INTERPOS_fsync, INTERPOS_fork, INTERPOS_msync, INTERPOS_nanosleep, - INTERPOS_open, INTERPOS_openat, INTERPOS_poll, INTERPOS_pselect, - INTERPOS_raise, INTERPOS_recvfrom, INTERPOS_recvmsg, INTERPOS_select, @@ -212,16 +209,10 @@ enum { INTERPOS_sigwaitinfo, INTERPOS_swapcontext, INTERPOS_system, - INTERPOS_sleep, INTERPOS_tcdrain, - INTERPOS_usleep, - INTERPOS_pause, INTERPOS_read, INTERPOS_readv, - INTERPOS_wait, - INTERPOS_wait3, INTERPOS_wait4, - INTERPOS_waitpid, INTERPOS_write, INTERPOS_writev, INTERPOS__pthread_mutex_init_calloc_cb, @@ -353,23 +344,17 @@ int __sys_sigwait(const __sigset_t *, int *); int __sys_sigwaitinfo(const __sigset_t *, struct __siginfo *); int __sys_swapcontext(struct __ucontext *, const struct __ucontext *); +int __sys_thr_kill(long, int); +int __sys_thr_self(long *); int __sys_truncate(const char *, __off_t); __pid_t __sys_wait4(__pid_t, int *, int, struct rusage *); __ssize_t __sys_write(int, const void *, __size_t); __ssize_t __sys_writev(int, const struct iovec *, int); -int __libc_creat(const char *path, __mode_t mode); -int __libc_pause(void); -int __libc_raise(int); int __libc_sigwait(const __sigset_t * __restrict, int * restrict sig); int __libc_system(const char *); -unsigned int __libc_sleep(unsigned int); int __libc_tcdrain(int); -int __libc_usleep(__useconds_t); -__pid_t __libc_wait(int *); -__pid_t __libc_wait3(int *, int, struct rusage *); -__pid_t __libc_waitpid(__pid_t, int *, int); int __fcntl_compat(int fd, int cmd, ...); /* execve() with PATH processing to implement posix_spawnp() */ diff --git a/lib/libc/sys/accept.c b/lib/libc/sys/accept.c index 38e32f2..1797783 100644 --- a/lib/libc/sys/accept.c +++ b/lib/libc/sys/accept.c @@ -38,11 +38,11 @@ __FBSDID("$FreeBSD$"); #include #include "libc_private.h" -__weak_reference(__sys_accept, __accept); +__weak_reference(__accept, accept); #pragma weak accept int -accept(int s, struct sockaddr *addr, socklen_t *addrlen) +__accept(int s, struct sockaddr *addr, socklen_t *addrlen) { return (((int (*)(int, struct sockaddr *, socklen_t *)) diff --git a/lib/libc/sys/interposing_table.c b/lib/libc/sys/interposing_table.c index 9987bf0..d303779 100644 --- a/lib/libc/sys/interposing_table.c +++ b/lib/libc/sys/interposing_table.c @@ -44,17 +44,14 @@ interpos_func_t __libc_interposing[INTERPOS_MAX] = { SLOT(aio_suspend, __sys_aio_suspend), SLOT(close, __sys_close), SLOT(connect, __sys_connect), - SLOT(creat, __libc_creat), SLOT(fcntl, __fcntl_compat), SLOT(fsync, __sys_fsync), SLOT(fork, __sys_fork), SLOT(msync, __sys_msync), SLOT(nanosleep, __sys_nanosleep), - SLOT(open, __sys_open), SLOT(openat, __sys_openat), SLOT(poll, __sys_poll), SLOT(pselect, __sys_pselect), - SLOT(raise, __libc_raise), SLOT(read, __sys_read), SLOT(readv, __sys_readv), SLOT(recvfrom, __sys_recvfrom), @@ -71,14 +68,8 @@ interpos_func_t __libc_interposing[INTERPOS_MAX] = { SLOT(sigwaitinfo, __sys_sigwaitinfo), SLOT(swapcontext, __sys_swapcontext), SLOT(system, __libc_system), - SLOT(sleep, __libc_sleep), SLOT(tcdrain, __libc_tcdrain), - SLOT(usleep, __libc_usleep), - SLOT(pause, __libc_pause), - SLOT(wait, __libc_wait), - SLOT(wait3, __libc_wait3), SLOT(wait4, __sys_wait4), - SLOT(waitpid, __libc_waitpid), SLOT(write, __sys_write), SLOT(writev, __sys_writev), SLOT(_pthread_mutex_init_calloc_cb, _pthread_mutex_init_calloc_cb_stub), diff --git a/lib/libc/sys/open.c b/lib/libc/sys/open.c index 57c0324..e0273c6 100644 --- a/lib/libc/sys/open.c +++ b/lib/libc/sys/open.c @@ -54,6 +54,6 @@ open(const char *path, int flags, ...) } else { mode = 0; } - return (((int (*)(const char *, int, ...)) - __libc_interposing[INTERPOS_open])(path, flags, mode)); + return (((int (*)(int, const char *, int, ...)) + __libc_interposing[INTERPOS_openat])(AT_FDCWD, path, flags, mode)); } diff --git a/lib/libthr/thread/thr_private.h b/lib/libthr/thread/thr_private.h index 0c16b2a..d62de98 100644 --- a/lib/libthr/thread/thr_private.h +++ b/lib/libthr/thread/thr_private.h @@ -917,8 +917,6 @@ void _thr_stack_fix_protection(struct pthread *thrd); int *__error_threaded(void) __hidden; void __thr_interpose_libc(void) __hidden; pid_t __thr_fork(void); -int __thr_pause(void) __hidden; -int __thr_raise(int sig); int __thr_setcontext(const ucontext_t *ucp); int __thr_sigaction(int sig, const struct sigaction *act, struct sigaction *oact) __hidden; diff --git a/lib/libthr/thread/thr_sig.c b/lib/libthr/thread/thr_sig.c index 1ec64f0..7cd0f75 100644 --- a/lib/libthr/thread/thr_sig.c +++ b/lib/libthr/thread/thr_sig.c @@ -515,23 +515,6 @@ _thr_signal_deinit(void) } int -__thr_pause(void) -{ - sigset_t oset; - - if (_sigprocmask(SIG_BLOCK, NULL, &oset) == -1) - return (-1); - return (__thr_sigsuspend(&oset)); -} - -int -__thr_raise(int sig) -{ - - return (_thr_send_sig(_get_curthread(), sig)); -} - -int __thr_sigaction(int sig, const struct sigaction *act, struct sigaction *oact) { struct sigaction newact, oldact, oldact2; diff --git a/lib/libthr/thread/thr_syscalls.c b/lib/libthr/thread/thr_syscalls.c index a4fe7e8..06b63c8 100644 --- a/lib/libthr/thread/thr_syscalls.c +++ b/lib/libthr/thread/thr_syscalls.c @@ -99,10 +99,6 @@ __FBSDID("$FreeBSD$"); extern int __fcntl_compat(int, int, ...); #endif -/* - * Cancellation behavior: - * If thread is canceled, no socket is created. - */ static int __thr_accept(int s, struct sockaddr *addr, socklen_t *addrlen) { @@ -189,25 +185,6 @@ __thr_connect(int fd, const struct sockaddr *name, socklen_t namelen) return (ret); } - -/* - * Cancellation behavior: - * If thread is canceled, file is not created. - */ -static int -__thr_creat(const char *path, mode_t mode) -{ - struct pthread *curthread; - int ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __libc_creat(path, mode); - _thr_cancel_leave(curthread, ret == -1); - - return (ret); -} - /* * Cancellation behavior: * According to specification, only F_SETLKW is a cancellation point. @@ -300,35 +277,6 @@ __thr_nanosleep(const struct timespec *time_to_sleep, * If the thread is canceled, file is not opened. */ static int -__thr_open(const char *path, int flags,...) -{ - struct pthread *curthread; - int mode, ret; - va_list ap; - - /* Check if the file is being created: */ - if ((flags & O_CREAT) != 0) { - /* Get the creation mode: */ - va_start(ap, flags); - mode = va_arg(ap, int); - va_end(ap); - } else { - mode = 0; - } - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __sys_open(path, flags, mode); - _thr_cancel_leave(curthread, ret == -1); - - return (ret); -} - -/* - * Cancellation behavior: - * If the thread is canceled, file is not opened. - */ -static int __thr_openat(int fd, const char *path, int flags, ...) { struct pthread *curthread; @@ -523,19 +471,6 @@ __thr_sendto(int s, const void *m, size_t l, int f, const struct sockaddr *t, return (ret); } -static unsigned int -__thr_sleep(unsigned int seconds) -{ - struct pthread *curthread; - unsigned int ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __libc_sleep(seconds); - _thr_cancel_leave(curthread, 1); - return (ret); -} - static int __thr_system(const char *string) { @@ -567,55 +502,6 @@ __thr_tcdrain(int fd) return (ret); } -static int -__thr_usleep(useconds_t useconds) -{ - struct pthread *curthread; - int ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __libc_usleep(useconds); - _thr_cancel_leave(curthread, 1); - return (ret); -} - -/* - * Cancellation behavior: - * Thread may be canceled at start, but if the system call returns - * a child pid, the thread is not canceled. - */ -static pid_t -__thr_wait(int *istat) -{ - struct pthread *curthread; - pid_t ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __libc_wait(istat); - _thr_cancel_leave(curthread, ret <= 0); - return (ret); -} - -/* - * Cancellation behavior: - * Thread may be canceled at start, but if the system call returns - * a child pid, the thread is not canceled. - */ -static pid_t -__thr_wait3(int *status, int options, struct rusage *rusage) -{ - struct pthread *curthread; - pid_t ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __libc_wait3(status, options, rusage); - _thr_cancel_leave(curthread, ret <= 0); - return (ret); -} - /* * Cancellation behavior: * Thread may be canceled at start, but if the system call returns @@ -636,24 +522,6 @@ __thr_wait4(pid_t pid, int *status, int options, struct rusage *rusage) /* * Cancellation behavior: - * Thread may be canceled at start, but if the system call returns - * a child pid, the thread is not canceled. - */ -static pid_t -__thr_waitpid(pid_t wpid, int *status, int options) -{ - struct pthread *curthread; - pid_t ret; - - curthread = _get_curthread(); - _thr_cancel_enter(curthread); - ret = __libc_waitpid(wpid, status, options); - _thr_cancel_leave(curthread, ret <= 0); - return (ret); -} - -/* - * Cancellation behavior: * Thread may be canceled at start, but if the thread wrote some data, * it is not canceled. */ @@ -701,17 +569,14 @@ __thr_interpose_libc(void) SLOT(aio_suspend); SLOT(close); SLOT(connect); - SLOT(creat); SLOT(fcntl); SLOT(fsync); SLOT(fork); SLOT(msync); SLOT(nanosleep); - SLOT(open); SLOT(openat); SLOT(poll); SLOT(pselect); - SLOT(raise); SLOT(read); SLOT(readv); SLOT(recvfrom); @@ -728,14 +593,8 @@ __thr_interpose_libc(void) SLOT(sigwaitinfo); SLOT(swapcontext); SLOT(system); - SLOT(sleep); SLOT(tcdrain); - SLOT(usleep); - SLOT(pause); - SLOT(wait); - SLOT(wait3); SLOT(wait4); - SLOT(waitpid); SLOT(write); SLOT(writev); #undef SLOT From owner-freebsd-arch@FreeBSD.ORG Wed Jan 7 04:01:38 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 22076F91; Wed, 7 Jan 2015 04:01:38 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6DE01CE8; Wed, 7 Jan 2015 04:01:37 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.9/8.14.9/NETPLEX) with ESMTP id t0741UUR064895; Tue, 6 Jan 2015 23:01:30 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 06 Jan 2015 23:01:30 -0500 (EST) Date: Tue, 6 Jan 2015 23:01:30 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Konstantin Belousov Subject: Re: Fixing dlopen("libpthread.so") In-Reply-To: <20150107032941.GJ42409@kib.kiev.ua> Message-ID: References: <20141226165337.GJ1754@kib.kiev.ua> <20150103212837.GC46373@stack.nl> <20150104114600.GC42409@kib.kiev.ua> <20150104182026.GA61250@stack.nl> <20150105023708.GD42409@kib.kiev.ua> <20150106205046.GA24971@stack.nl> <20150107032941.GJ42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: threads@freebsd.org, Jilles Tjoelker , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 04:01:38 -0000 On Wed, 7 Jan 2015, Konstantin Belousov wrote: > On Tue, Jan 06, 2015 at 09:50:46PM +0100, Jilles Tjoelker wrote: >> On Mon, Jan 05, 2015 at 04:37:08AM +0200, Konstantin Belousov wrote: >>> Next natural question is about the __error calls through PLT in the >>> .cerror asm. Before the work was committed, libthr interposed __error, >>> which was required for correct operation. Now, we need __error exported, >>> but do we need support its interposing ? This is an implementation >>> detail for errno, I do not see any loss from not allowing to override >>> errno location. >> >> Indeed, there is no need to allow interposing __error (as with many >> libc-internal calls to its exported symbols). Additionally, the current >> namespace.h mechanism could be used to redirect __error calls from C >> code. >> >> Glibc uses macro trickery with the asm labels compiler feature, making >> libc code see things like >> int *__error(void) asm("__hidden__error"); >> and defining the hidden alias somewhere. This also works for >> compiler-generated calls like to memcpy(). I'm not sure whether it is a >> good idea to add this extra trickery and depend on the compiler feature. > I might look at this after the current change is committed. I don't quite follow all the above about __error(), but non-C programs need to interface to an __error() that works regardless of threading or not. -- DE From owner-freebsd-arch@FreeBSD.ORG Wed Jan 7 04:21:03 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AD22E28C; Wed, 7 Jan 2015 04:21:03 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E8D964054; Wed, 7 Jan 2015 04:21:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t074KsMq070206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Jan 2015 06:20:54 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t074KsMq070206 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t074KrMN070204; Wed, 7 Jan 2015 06:20:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 7 Jan 2015 06:20:53 +0200 From: Konstantin Belousov To: Daniel Eischen Subject: Re: Fixing dlopen("libpthread.so") Message-ID: <20150107042053.GK42409@kib.kiev.ua> References: <20141226165337.GJ1754@kib.kiev.ua> <20150103212837.GC46373@stack.nl> <20150104114600.GC42409@kib.kiev.ua> <20150104182026.GA61250@stack.nl> <20150105023708.GD42409@kib.kiev.ua> <20150106205046.GA24971@stack.nl> <20150107032941.GJ42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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 autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: threads@freebsd.org, Jilles Tjoelker , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 04:21:03 -0000 On Tue, Jan 06, 2015 at 11:01:30PM -0500, Daniel Eischen wrote: > On Wed, 7 Jan 2015, Konstantin Belousov wrote: > > > On Tue, Jan 06, 2015 at 09:50:46PM +0100, Jilles Tjoelker wrote: > >> On Mon, Jan 05, 2015 at 04:37:08AM +0200, Konstantin Belousov wrote: > >>> Next natural question is about the __error calls through PLT in the > >>> .cerror asm. Before the work was committed, libthr interposed __error, > >>> which was required for correct operation. Now, we need __error exported, > >>> but do we need support its interposing ? This is an implementation > >>> detail for errno, I do not see any loss from not allowing to override > >>> errno location. > >> > >> Indeed, there is no need to allow interposing __error (as with many > >> libc-internal calls to its exported symbols). Additionally, the current > >> namespace.h mechanism could be used to redirect __error calls from C > >> code. > >> > >> Glibc uses macro trickery with the asm labels compiler feature, making > >> libc code see things like > >> int *__error(void) asm("__hidden__error"); > >> and defining the hidden alias somewhere. This also works for > >> compiler-generated calls like to memcpy(). I'm not sure whether it is a > >> good idea to add this extra trickery and depend on the compiler feature. > > I might look at this after the current change is committed. > > I don't quite follow all the above about __error(), but non-C > programs need to interface to an __error() that works regardless > of threading or not. C programs also need to be able to call __error(), to have working errno. Discussion above talks about the need for the programs to be able to interpose __error(), which I and Jilles agree is excessive. My proposal is to remove PLT indirection in the calls to __error() from _inside_ libc, which makes errno functioning in libc both more reliable and slightly faster. From owner-freebsd-arch@FreeBSD.ORG Wed Jan 7 05:14:58 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B761682; Wed, 7 Jan 2015 05:14:58 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BA4E64709; Wed, 7 Jan 2015 05:14:57 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.9/8.14.9/NETPLEX) with ESMTP id t075EtkD034465; Wed, 7 Jan 2015 00:14:56 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 07 Jan 2015 00:14:56 -0500 (EST) Date: Wed, 7 Jan 2015 00:14:55 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Konstantin Belousov Subject: Re: Fixing dlopen("libpthread.so") In-Reply-To: <20150107042053.GK42409@kib.kiev.ua> Message-ID: References: <20141226165337.GJ1754@kib.kiev.ua> <20150103212837.GC46373@stack.nl> <20150104114600.GC42409@kib.kiev.ua> <20150104182026.GA61250@stack.nl> <20150105023708.GD42409@kib.kiev.ua> <20150106205046.GA24971@stack.nl> <20150107032941.GJ42409@kib.kiev.ua> <20150107042053.GK42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: threads@freebsd.org, Jilles Tjoelker , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 05:14:58 -0000 On Wed, 7 Jan 2015, Konstantin Belousov wrote: > On Tue, Jan 06, 2015 at 11:01:30PM -0500, Daniel Eischen wrote: >> On Wed, 7 Jan 2015, Konstantin Belousov wrote: >> >>> On Tue, Jan 06, 2015 at 09:50:46PM +0100, Jilles Tjoelker wrote: >>>> On Mon, Jan 05, 2015 at 04:37:08AM +0200, Konstantin Belousov wrote: >>>>> Next natural question is about the __error calls through PLT in the >>>>> .cerror asm. Before the work was committed, libthr interposed __error, >>>>> which was required for correct operation. Now, we need __error exported, >>>>> but do we need support its interposing ? This is an implementation >>>>> detail for errno, I do not see any loss from not allowing to override >>>>> errno location. >>>> >>>> Indeed, there is no need to allow interposing __error (as with many >>>> libc-internal calls to its exported symbols). Additionally, the current >>>> namespace.h mechanism could be used to redirect __error calls from C >>>> code. >>>> >>>> Glibc uses macro trickery with the asm labels compiler feature, making >>>> libc code see things like >>>> int *__error(void) asm("__hidden__error"); >>>> and defining the hidden alias somewhere. This also works for >>>> compiler-generated calls like to memcpy(). I'm not sure whether it is a >>>> good idea to add this extra trickery and depend on the compiler feature. >>> I might look at this after the current change is committed. >> >> I don't quite follow all the above about __error(), but non-C >> programs need to interface to an __error() that works regardless >> of threading or not. > > C programs also need to be able to call __error(), to have working > errno. Discussion above talks about the need for the programs to be > able to interpose __error(), which I and Jilles agree is excessive. My > proposal is to remove PLT indirection in the calls to __error() from > _inside_ libc, which makes errno functioning in libc both more reliable > and slightly faster. Fair enough - thanks for the explanation! -- DE From owner-freebsd-arch@FreeBSD.ORG Wed Jan 7 18:17:53 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 78C10F68; Wed, 7 Jan 2015 18:17:53 +0000 (UTC) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2FF02642C5; Wed, 7 Jan 2015 18:17:53 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Y8vB0-0001vg-O4; Wed, 07 Jan 2015 22:17:50 +0400 Date: Wed, 7 Jan 2015 22:17:50 +0400 From: Slawa Olhovchenkov To: John Baldwin Subject: Re: devctl(8): A device control utility Message-ID: <20150107181750.GB5588@zxy.spb.ru> References: <3200196.9ZgXApgRdA@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3200196.9ZgXApgRdA@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false Cc: arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 18:17:53 -0000 On Mon, Jan 05, 2015 at 03:01:00PM -0500, John Baldwin wrote: > For a long time I've wanted a way to administratively manipulate the state of > new-bus devices from userland. I think the first use case I wanted was a way > to power off the sound controller (and anything else I wasn't using) on my > first laptop (a Dell Inspiron 5000e I got back in 2000). Similarly, it would > be nice to have a way to handle "ejectable" devices (ACPI has a provision for > this, and said laptop had _EJx methods to allow one to swap a CD drive out for > a battery in a bay while the laptop was in S3). There are some other use > cases that would also be nice such as detaching a driver from a PCI device to > decide at runtime that it should be passed through to a bhyve guest (and > possibly undoing that to allow a host driver to take it back over). Forcing a > rescan of a PCI device can be useful if you are using an FPGA and would like > to alter BAR layout/sizes without having to reboot the OS. A way to force > resets at runtime might also be useful (e.g. a FLR for a PCI device). A few > weeks ago I finally sat down and started on an implementation. It can be > found here: > > https://github.com/bsdjhb/freebsd/compare/devctl > > Sample commands look like: > > % devctl disable virtio_pci2 > > # detaches the driver, but leaves the device's name intact similar to > # specifying hint.virtio_pci.2.disabled=1 at boot > > % devctl enable virtio_pci2 > > # enables a disabled device, including attaching it > > % devctl detach uart1 > > # does a full detach, which means the device is now unnamed Can be now this device used for VirtualBox USB passthrough? From owner-freebsd-arch@FreeBSD.ORG Thu Jan 8 13:45:47 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 93C35D49; Thu, 8 Jan 2015 13:45:47 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 158DB14B; Thu, 8 Jan 2015 13:45:47 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id gd6so9255448lab.3; Thu, 08 Jan 2015 05:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=MmN1aXbbn8QiiIMVF2NYKX/o8ifUskfGAZtbIoh6R74=; b=YBQ6QZ2chk8dyEw2HgPArTLTKJ1NIdyJUZ37C38NZ97c4MvnxpyeDHWVeU51SGQ8fb V6hHYOFyOChOsFIg7thJERrD5UHM0OnN1cg0f7aA3Ep7mhpnazocPzGSw1chDgEC5xdQ GvD9BlgfSGA1xedL/8dubSX4eMtrVgvXQMjIeDGlTvGtbL6c4bVXeZT/ItXAv20P5Nd4 gm8oq59JyechaLP9CHhUBk074z/JGvZ51RXzjKROXblvMHtHUg4pbpCQ3B5pyTF10zf/ S0UXSVQHTGhgzO8V+iqn/gpxgoGV7EshiofHBQbXbFEQ1/X/0kRS8v9y2i7wmfyuS4ak snHQ== MIME-Version: 1.0 X-Received: by 10.152.6.67 with SMTP id y3mr13747152lay.90.1420724745206; Thu, 08 Jan 2015 05:45:45 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.141.5 with HTTP; Thu, 8 Jan 2015 05:45:45 -0800 (PST) In-Reply-To: <528C023D-6207-4054-917B-05D4C4E605EC@FreeBSD.org> References: <528C023D-6207-4054-917B-05D4C4E605EC@FreeBSD.org> Date: Thu, 8 Jan 2015 05:45:45 -0800 X-Google-Sender-Auth: H1cd0VunzTQ6ZUcc_Dv2gwWVKfo Message-ID: Subject: Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0 From: Craig Rodrigues To: Dimitry Andric Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-toolchain@freebsd.org, freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 13:45:47 -0000 Hi, I just tried to build CURRENT with WITH_LLDB=yes in /etc/make.conf. I got this error: /usr/obj/opt2/branches/head/usr.bin/clang/lldb/../../../lib/clang/libllvmaarch64disassemble r/libllvmaarch64disassembler.a(AArch64Disassembler.o): In function `createAArch64ExternalSy mbolizer(llvm::StringRef, int (*)(void*, unsigned long, unsigned long, unsigned long, int, void*), char const* (*)(void*, unsigned long, unsigned long*, unsigned long, char const**), void*, llvm::MCContext*, llvm::MCRelocationInfo*)': /opt2/branches/head/lib/clang/libllvmaarch64disassembler/../../../contrib/llvm/lib/Target/A Arch64/Disassembler/AArch64Disassembler.cpp:(.text+0xeaf): undefined reference to `vtable f or llvm::AArch64ExternalSymbolizer' Any ideas? Thanks. -- Craig From owner-freebsd-arch@FreeBSD.ORG Thu Jan 8 14:05:20 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2804E31A; Thu, 8 Jan 2015 14:05:20 +0000 (UTC) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E320D3A1; Thu, 8 Jan 2015 14:05:19 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id z20so2850398igj.4; Thu, 08 Jan 2015 06:05:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=4tkJ7YsfUq2Mgb0Ma8koN6CvRmnur+wGSX3KSJWvTn8=; b=zO4sMuPPhS4HkxX/GGu7FLlX2yONUmdsTTkSFPSiLvGAARvnUZjALntEug4FDN7Lgw 03h8uTenNvr19dpOrZbrB9vaooaTHkJ55KDJKsRwuu5qckTyqwXRUcOZ7ak22POFIbpr ibGS2KA0uLaAifhNAViVxVYJdrl32o+8cBvgKV2khyWM+euSkMquWSjvGKAK4G425N1k CX0m0/gyURHSENbKgEPgMbh/EVJecEduxwPaUJmkBNkinNnIEiR43Ok9wMoJemtQNbh1 d5VdPm3nT29RevRuW9wRw4dhH/tF5Xhuxbb+PDrZGG26smd9Cw0OcsN/kjce6+d80noW Ttvg== X-Received: by 10.50.143.101 with SMTP id sd5mr10029342igb.40.1420725919363; Thu, 08 Jan 2015 06:05:19 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.0.85 with HTTP; Thu, 8 Jan 2015 06:04:59 -0800 (PST) In-Reply-To: References: <528C023D-6207-4054-917B-05D4C4E605EC@FreeBSD.org> From: Ed Maste Date: Thu, 8 Jan 2015 09:04:59 -0500 X-Google-Sender-Auth: rlSbR-6I_NBNLYRT6OZ7G-Vy1g8 Message-ID: Subject: Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0 To: Craig Rodrigues Content-Type: text/plain; charset=UTF-8 Cc: freebsd-toolchain@freebsd.org, Dimitry Andric , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:05:20 -0000 On 8 January 2015 at 08:45, Craig Rodrigues wrote: > I just tried to build CURRENT with WITH_LLDB=yes > in /etc/make.conf. I got this error: > > ... Thanks for the report Craig, I'm looking at it. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 8 14:15:08 2015 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 490E0AD9; Thu, 8 Jan 2015 14:15:08 +0000 (UTC) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BBE1F6AE; Thu, 8 Jan 2015 14:15:07 +0000 (UTC) Received: by mail-lb0-f179.google.com with SMTP id z11so3049468lbi.10; Thu, 08 Jan 2015 06:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rJ0YpwnbzOI/gfmF7G0FT/Q2kKqY58jMBRb492AXCgU=; b=OIyZpnLC3gaPVkeZnIBpWPDAtpMCj+QEcsP24XJN8xsLEGbEA3afCImc33Z+menoFx L/rmWT7xv/JpTCwwoDtmCwOFxNHNfd+qUgGlWgAF4nXafBd9O0dgPz14QuyDF4m7pKVi O5a70vrwLJILD4DjXsymczDI/wzwdKNYzZD52lPUPQZoBbdRmlMX0tnA72/qnwJXyGWk pK9TpADw3P9w8xLzfdyW/14YKEex/IEi66Erqp0FJx3mMQxyvvRHxaYsqD1Sur+dBSCz nzlpmSdtCF3+Y+9+2HT1JwG1tO0jaS8SJrCj/ik2WvJpedvDHuaiWeWS5om8czl32VFp 521A== MIME-Version: 1.0 X-Received: by 10.152.23.98 with SMTP id l2mr13873794laf.46.1420726505777; Thu, 08 Jan 2015 06:15:05 -0800 (PST) Sender: crodr001@gmail.com Received: by 10.112.141.5 with HTTP; Thu, 8 Jan 2015 06:15:05 -0800 (PST) In-Reply-To: References: <528C023D-6207-4054-917B-05D4C4E605EC@FreeBSD.org> Date: Thu, 8 Jan 2015 06:15:05 -0800 X-Google-Sender-Auth: 5xcTUkewFTr4PnkAS6m3pwbFKBQ Message-ID: Subject: Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0 From: Craig Rodrigues To: Ed Maste Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-toolchain@freebsd.org, Dimitry Andric , freebsd-arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2015 14:15:08 -0000 On Thu, Jan 8, 2015 at 6:04 AM, Ed Maste wrote: > On 8 January 2015 at 08:45, Craig Rodrigues wrote: > > I just tried to build CURRENT with WITH_LLDB=yes > > in /etc/make.conf. I got this error: > > > > ... > > Thanks for the report Craig, I'm looking at it. > This fixes it for me: Index: libllvmaarch64disassembler/Makefile =================================================================== --- libllvmaarch64disassembler/Makefile (revision 276808) +++ libllvmaarch64disassembler/Makefile (working copy) @@ -8,7 +8,7 @@ INCDIR= lib/Target/AArch64 SRCS= AArch64Disassembler.cpp -.if ${MK_CLANG_EXTRAS} != "no" +.if ${MK_CLANG_EXTRAS} != "no" || ${MK_LLDB} != "no" SRCS+= AArch64ExternalSymbolizer.cpp .endif -- Craig From owner-freebsd-arch@FreeBSD.ORG Fri Jan 9 20:09:47 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34DC3CA4 for ; Fri, 9 Jan 2015 20:09:47 +0000 (UTC) Received: from ccm36.constantcontact.com (ccm36.constantcontact.com [208.75.123.196]) by mx1.freebsd.org (Postfix) with ESMTP id A387180A for ; Fri, 9 Jan 2015 20:09:46 +0000 (UTC) Received: from p2-jbsvcs5291.ad.prodcc.net (p2-pen7.ad.prodcc.net [10.252.0.107]) by p2-mail189.ccm36.constantcontact.com (Postfix) with ESMTP id 58056A8D6E7 for ; Fri, 9 Jan 2015 15:09:46 -0500 (EST) DKIM-Signature: v=1; q=dns/txt; a=rsa-sha256; c=relaxed/relaxed; s=1000073432; d=auth.ccsend.com; h=to:X-Feedback-ID:subject:mime-version:message-id:from:date:list-unsubscribe:reply-to; bh=RP/ffVyTRvfGBTD022HCl64Om5BFi8Ryr+Xz7JEYGLM=; b=YAUfUqIKISTxK7WIfvV6TJADrH82xiwggECpkse6isQUCli6iF48zIzI7HJDZ3XF4F5VfoHBa/33mzpqI6JPyUvZxdf6B311ZCM3oNDL/Qejh/mlt2GRrYvy+UxJ8Ud6U1ytTbKor9AQJnvXVdNAxt6qJHZq1ByuL9+B99uRZfk= Message-ID: <1119722242581.1115603422701.1254712288.0.421509JL.1002@scheduler.constantcontact.com> Date: Fri, 9 Jan 2015 15:09:46 -0500 (EST) From: Salvage Drive Reply-To: info@salvagedrive.com To: arch@freebsd.org Subject: Great Deals from Salvage Drive MIME-Version: 1.0 X-Campaign-Activity-ID: 6ecd8bf7-cfa0-4c44-a9c7-a9870e85ffb0 X-Channel-ID: 8b131940-9839-11e4-9cca-d4ae528eade9 X-Mailer: Roving Constant Contact 2012 (http://www.constantcontact.com) X-Return-Path-Hint: Abs2L98+gTESpx6mHDoX/sA==_1115603422701_ixMZQJg5EeScytSuUo6t6Q==@in.constantcontact.com X-Roving-Campaignid: 1119722242581 X-Roving-Id: 1115603422701.1254712288 X-Feedback-ID: 8b131940-9839-11e4-9cca-d4ae528eade9:6ecd8bf7-cfa0-4c44-a9c7-a9870e85ffb0:1115603422701:CTCT X-CTCT-ID: 8a6a7d30-9839-11e4-9c25-d4ae528eade9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2015 20:09:47 -0000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ Special Deals from Salvage Drive ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ NOW OFFERING OVER 90,000 VEHICLES CLEAN TITLE CARS SALVAGE TITLE CARS BUY NOW CARS AUCTION CARS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2006 Lexus RX330 RUN & DRIVE Salvage Title Only 76,817 miles BUY NOW $7,300 [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrALLE0WaKy-dnmpM= tX7EVoSa_7IIravXNcsUtG8Hvw7ine9Ob8sdkuW_YNl3krXrCoji2L46cHRmYPbB5qie3HIUOsV= CWdcxpvZGZLV1HtObEuX_g78xLW9zHI_PYJZwlekZX9uf6sv614ZztnjiIXm9XwQP5LWjjhAu0R= 9i-w2xKv2TDtT7FjLj6ddu_qIs_F4h2SnlwPhJ4RUV6HijY3&c=3DggBbO-DQbjU3EOhYsAiGCw= 3uDs65z51r81rx4cZ-wzHRcq931O59TA=3D=3D&ch=3DOj72h50tmNfVXrSSu5JVKxWWjf_ZsgT= u8ugLNuhfHNL6xnXahHJzug=3D=3D] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2002 Lexus RX300 RUN & DRIVE Clear Title 175,570 miles BUY NOW $6,270 [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrALLE0WaKy-dnmpM= tX7EVoSa_7IIravXNcsUtG8Hvw7ine9Ob8sdkuU7RtHA3vJ-3rAFTlPFyQ5BSATM85XyHGY9c_u= otpUMjHaThGmAym3MlSuWsE0V62FMy3L-wrt-4ikXEX5DQdtGNDqUDqsWrrllTHWCw8w01OVFRK= CX9QzkbZCqWVxGF02DkQoFlsBb9ER09FqewQt1j8vYjrVvTN&c=3DggBbO-DQbjU3EOhYsAiGCw= 3uDs65z51r81rx4cZ-wzHRcq931O59TA=3D=3D&ch=3DOj72h50tmNfVXrSSu5JVKxWWjf_ZsgT= u8ugLNuhfHNL6xnXahHJzug=3D=3D] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2008 Lexus RX350 RUN & DRIVE Clear Title 11,197 miles BUY NOW $10,200 [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrALLE0WaKy-dnmp= MtX7EVoSa_7IIravXNcsUtG8Hvw7ine9Ob8sdku0I1oc7UDsXMJ75blwYjHrx5u2ObiP7NK1LED= xaaOWcl93LZUxIDe2WhJxkqayusWK3uTBSREnMS1L4OC-QlaUG7XnUTMGDqa4CePc8bJWpKuCio= j6VeWeJZjFRJXAuYblDY8XJRRto2_jUAWi0ik8PpSELfPnpIr&c=3DggBbO-DQbjU3EOhYsAiGC= w3uDs65z51r81rx4cZ-wzHRcq931O59TA=3D=3D&ch=3DOj72h50tmNfVXrSSu5JVKxWWjf_Zsg= Tu8ugLNuhfHNL6xnXahHJzug=3D=3D] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2002 Lexus ES300 RUN & DRIVE Salvage Title 199,532 miles Auction on 1/16/15 [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrALLE0WaKy-d= nmpMtX7EVoSa_7IIravXNcsUtG8Hvw7ine9Ob8sdkuyLj0cU5ybVoGk80WwQLdFHntljcZDn5NK= rHOZ3aiOqZWaOONi6RZ6m6iKFi35OWIiLDk2o9AymxCb1D28F-VEnE8sO-HxRqOpG3SNjWVfELK= 1Q-OnvRoe_PrOtNMgQNQiYLMgbQr9DueIdtKnW4jAEv6A6HCAxa1&c=3DggBbO-DQbjU3EOhYsA= iGCw3uDs65z51r81rx4cZ-wzHRcq931O59TA=3D=3D&ch=3DOj72h50tmNfVXrSSu5JVKxWWjf_= ZsgTu8ugLNuhfHNL6xnXahHJzug=3D=3D] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2005 Toyota Camry FWD RUN & DRIVE Salvage Title 141,125 miles Auction on 1/14/15 [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrALLE0WaKy-d= nmpMtX7EVoSa_7IIravXNcsUtG8Hvw7ine9Ob8sdkuIOwfsdfPNciwIDbYGiBSge4MIbXtc5eKB= jQ3vzTOiHgcvnIsHHIFxlF3770vSYe31I0mhb_rL0YecDbWnjUR8gA9fkhEa7fhWdzVlrn2HdsS= 5AdqMcdFkYjRilDTP2wQHj-Oa1UWhUPwHivV5u1bb_UTNBoi0DP3&c=3DggBbO-DQbjU3EOhYsA= iGCw3uDs65z51r81rx4cZ-wzHRcq931O59TA=3D=3D&ch=3DOj72h50tmNfVXrSSu5JVKxWWjf_= ZsgTu8ugLNuhfHNL6xnXahHJzug=3D=3D] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2010 Toyota Corolla RUN & DRIVE Clear Title Only 60,439 miles BUY NOW $10,355 [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrALLE0WaKy-dnmp= MtX7EVoSa_7IIravXNcsUtG8Hvw7ine9Ob8sdku2wyKztMeUB4C9_c9FmgUIBVvo_BYy9g2WAs4= oCRUFbIsdU7Jkl-y6pM6ELAWBA5Ee7dzmg1Mrl6SPdTzT6CjdrU6lerh7UwMgi7iZsmGu2aA2ZH= -E5I_b4eiQNK6m3t0cvsRS_imyW0gcjIiINoiwguZKju7g-2k&c=3DggBbO-DQbjU3EOhYsAiGC= w3uDs65z51r81rx4cZ-wzHRcq931O59TA=3D=3D&ch=3DOj72h50tmNfVXrSSu5JVKxWWjf_Zsg= Tu8ugLNuhfHNL6xnXahHJzug=3D=3D] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2008 Honda Accord EX-L RUN & DRIVE Clear Title 120,163 miles BUY NOW [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrALLE0WaKy-dnmpMtX7EVoS= a_7IIravXNcsUtG8Hvw7ine9Ob8sdkuvJoejyEeedKbqVrikuB5SeuUINjdhBidhmTelvZnx62c= BZOl7bO7GuYwgKZF1VH5Mc8OsngFgEt2WV03ORaOHs7SbNgRVuuAxMwuzTcB0ykI959LdWY6-ny= c43V1ZwkwZj8Fa6F_ofGFu55bixW3k7ODI2P5yLzD&c=3DggBbO-DQbjU3EOhYsAiGCw3uDs65z= 51r81rx4cZ-wzHRcq931O59TA=3D=3D&ch=3DOj72h50tmNfVXrSSu5JVKxWWjf_ZsgTu8ugLNu= hfHNL6xnXahHJzug=3D=3D] $8,532 [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrALLE0WaKy-dnmpMtX7EVoSa= _7IIravXNcsUtG8Hvw7ine9Ob8sdkuvJoejyEeedKbqVrikuB5SeuUINjdhBidhmTelvZnx62cB= ZOl7bO7GuYwgKZF1VH5Mc8OsngFgEt2WV03ORaOHs7SbNgRVuuAxMwuzTcB0ykI959LdWY6-nyc= 43V1ZwkwZj8Fa6F_ofGFu55bixW3k7ODI2P5yLzD&c=3DggBbO-DQbjU3EOhYsAiGCw3uDs65z5= 1r81rx4cZ-wzHRcq931O59TA=3D=3D&ch=3DOj72h50tmNfVXrSSu5JVKxWWjf_ZsgTu8ugLNuh= fHNL6xnXahHJzug=3D=3D] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2007 Honda Pilot EX RUN & DRIVE Clear Title 133,377 miles BUY NOW $8,856 [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrALLE0WaKy-dnmpM= tX7EVoSa_7IIravXNcsUtG8Hvw7ine9Ob8sdkuEiu-yLZfdg19s8sRAUWi2ylHGgfwIvA-WBN9C= oZdy70baZqEwI90dv15j4AsvS2kL099BvyX0ZzMgbFnoePrashiB8pfumUHl0zvfD1gqoRjwkQd= vwRK9hCVRy3vY0rRY-rV1tLKUuhL_vvvB5cg6hXZCOutEVan&c=3DggBbO-DQbjU3EOhYsAiGCw= 3uDs65z51r81rx4cZ-wzHRcq931O59TA=3D=3D&ch=3DOj72h50tmNfVXrSSu5JVKxWWjf_ZsgT= u8ugLNuhfHNL6xnXahHJzug=3D=3D] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ 2006 Toyota Tacoma RUN & DRIVE Salvage Title Only 47,181 miles Auction on 1/20/15 [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrALLE0WaKy-d= nmpMtX7EVoSa_7IIravXNcsUtG8Hvw7ine9Ob8sdkus1N-S4VGAO3K59HKPk5kSLfVQydfQrJdN= SkOv7I5k05R8m50skRCYr5YQPFksWq8HjCAHuuNIEeOtEd85cbWrbfuO5mQzZQ01UdQQnkDlnRm= oXxyz7Ho4zVS-Ebv_dD0gSZPC8_rfONtcxSSz4rPfndNZCfR87Dx&c=3DggBbO-DQbjU3EOhYsA= iGCw3uDs65z51r81rx4cZ-wzHRcq931O59TA=3D=3D&ch=3DOj72h50tmNfVXrSSu5JVKxWWjf_= ZsgTu8ugLNuhfHNL6xnXahHJzug=3D=3D] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ Save Save Save Get $100 OFF Salvage Drive Fee on your next purchase by mentioning the Promo Code: Salvage Drive 411 Limit 1 per customer, Salvage Drive registered members only. Applies only t= o in=20 stock items. Not valid on prior purchases. Not valid with any other offers,= promotions, coupons or discounts. Coupon must be mentioned at time of purchase. Salvage Drive, Inc. is not responsible for any Coupons not redeemed by any = expiration date hereon. Failure to use a Coupon by expiration date hereon shall result= in the forfeiture of such Coupon. Offer Expires: August January 23rd 2015 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ LET US SEARCH FOR YOU! TELL US WHAT YOU ARE LOOKING FOR AND OUR EXPERTS WILL SEARCH FOR YOU BASED = ON YOUR SPECIFIC BUDGET AND REQUIREMENTS. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ SalvageDrive.com [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrALLE0WaKy-dnm= pMtX7EVoSa_7IIravXNcsUtG8Hvw7lKv23q8tVNk4bFhGiFiiFQSXZIfqdiS_I6CMPFS1PwaWfF= 4yr_3k0UzbAPmVQ-CquUljhD2bUy28GhvLqQo749O5L6lsoKXD5DXq-ZAnEfZW-8RbAY4gqqxC3= gT3E_3Dw=3D=3D&c=3DggBbO-DQbjU3EOhYsAiGCw3uDs65z51r81rx4cZ-wzHRcq931O59TA= =3D=3D&ch=3DOj72h50tmNfVXrSSu5JVKxWWjf_ZsgTu8ugLNuhfHNL6xnXahHJzug=3D=3D] SalvageDrive.com [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrALLE0WaKy-dnm= pMtX7EVoSa_7IIravXNcsUtG8Hvw7j1FCKY_paxOthySrqCTKOBFUTwkGwNQiK1_YqdqMGPAoNd= -MSnpsa-nzJVBjU4SQG7z21vjbS7_S9grQp9JuKOIpvn1atJ_vkEK4j8q5O1pCGSx9OUYQC2bwj= OWRgwsCcluBCWK37ZuGalKO4f62enuHWrDYoGqAmSPzbiP8KhC&c=3DggBbO-DQbjU3EOhYsAiG= Cw3uDs65z51r81rx4cZ-wzHRcq931O59TA=3D=3D&ch=3DOj72h50tmNfVXrSSu5JVKxWWjf_Zs= gTu8ugLNuhfHNL6xnXahHJzug=3D=3D] 1-844-227-7411 Toll Free 1-347-492-1727 Tel. Skype: salvagedrive info@SalvageDrive.com [mailto:info@SalvageDrive.com] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ Sincerely, Salvage Drive Team ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ ___________________________________________________________________________= __________ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ Don't forget to add info@salvagedrive.com to your Address Book to keep it f= rom skipping your inbox or getting caught in spam filters. We want your experience with the Salvage Drive to be as smooth and reassuri= ng as possible. Accordingly, we diligently safeguard your privacy. If you wish t= o review our Privacy Policy at any time, please click on the link below, or copy and= paste it into your web browser's location window Salvage Drive Privacy Policy [http://r20.rs6.net/tn.jsp?f=3D001ncl2q7f_dsrA= LLE0WaKy-dnmpMtX7EVoSa_7IIravXNcsUtG8Hvw7j1FCKY_paxOJc55_Ds6h-PpHT3TBHJiLn2= XoaQujJtoRZWjr9QgdtawD1DJywf3A7W2Ih6WbVKW_-gC1jDkBeuSX3BCFt3A-aOGlrnDHMJM5o= GXZu8McOLZavGYZ02Mw-EKwMa6sSEyQgHtiFRsDEmaZWdpkrznp-u_fgBbjsFs&c=3DggBbO-DQ= bjU3EOhYsAiGCw3uDs65z51r81rx4cZ-wzHRcq931O59TA=3D=3D&ch=3DOj72h50tmNfVXrSSu= 5JVKxWWjf_ZsgTu8ugLNuhfHNL6xnXahHJzug=3D=3D] =C2=A9 2014 SalvageDrive, Inc. | All rights reserved ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~ This email was sent to arch@freebsd.org by info@salvagedrive.com. Update Profile/Email Address http://visitor.constantcontact.com/do?p=3Doo&m=3D001byRd3MOrEzrBc_e8AIN5jg%= 3D%3D&ch=3D8b131940-9839-11e4-9cca-d4ae528eade9&ca=3D6ecd8bf7-cfa0-4c44-a9c= 7-a9870e85ffb0 Instant removal with SafeUnsubscribe(TM) http://visitor.constantcontact.com/do?p=3Dun&m=3D001byRd3MOrEzrBc_e8AIN5jg%= 3D%3D&ch=3D8b131940-9839-11e4-9cca-d4ae528eade9&ca=3D6ecd8bf7-cfa0-4c44-a9c= 7-a9870e85ffb0 Privacy Policy: http://ui.constantcontact.com/roving/CCPrivacyPolicy.jsp Online Marketing by Constant Contact(R) www.constantcontact.com Salvage Drive, Inc. | 217 Broadway | Suite 505 | New York | NY | 10007 From owner-freebsd-arch@FreeBSD.ORG Sat Jan 10 10:21:50 2015 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E4B5FA for ; Sat, 10 Jan 2015 10:21:50 +0000 (UTC) Received: from mx1.webcast129.com (mx1.webcast129.com [50.30.42.208]) by mx1.freebsd.org (Postfix) with SMTP id B3A36176 for ; Sat, 10 Jan 2015 10:21:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; s=s1024;d=webcast129.com; h=message-id:from:to:subject:date:mime-version:content-type; bh=EAmWPM3J0y9ZUoI/y2qGUBuMLRI=; b=Wyn8IyX2zh84PiX9O8bZyGgZxGXbUoA8cqDiXBUTuJUyik2GGF1I+EwNd9K1pc5z+RCDeyS2QKgNsij0zasw1lBv4cFbJYo5FkJMBMJu5FyccujO5JWdS6H6OdxqnIM2G5euAu+GSXd7gewBwauLOYOle+qlwoZzSHlRUXW2u1M= DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=s1024;d=webcast129.com; h=message-id:from:to:subject:date:mime-version:content-type; b=J11rgNTc3GQqENMBT0KzYcvIClqaRPm2UOAHMPUqqNE6AQofjvaVHRNB9yy96R/S+nlZ2qi0l8Pym5LOlBw8IdsEQQuSCYXz0IaPbmaTCd452O0KISVIWfvq+2tGumYJrzFEXh6e5ldwd7CminasoQ0yBZbJCkE3/7LNXuLWbZg= Received: from mx1.webcast129.com ([50.30.42.208]) by mx1.webcast129.com ([50.30.42.208]) with SMTPSVC 75095272; Sat, 10 Jan 2015 15:51:39 +0500 Message-ID: Reply-To: From: "Himsan Polymer" To: Subject: =?utf-8?B?U0lMSUNPTkUgVFVCSU5HLCBCUkFJREVEIEhPU0VTLCBHQVNLRVRTLA==?= =?utf-8?B?U0hFRVRTIEFORCBGQkQgR0FTS0VUUyAoRkRBIDIxIENGUiAxNzcuMg==?= =?utf-8?B?NjAwKSBBUFBST1ZFRCk=?= Date: Sat, 10 Jan 2015 15:51:39 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Jan 2015 10:21:50 -0000 Respected Sir, Sub. : Silicone & Viton Rubber Products for Food, = Pharma & Medical, Textile and Allied Industrial Applications We wish = to introduce ourselves as leading supplier of Silicon & Viton Rubber = Products for Food, Pharma & Medical Application with distinguished = characteristic as follows. We are one of the leading manufacturers of = Silicon Rubber Products in INDIA. We are supplying our products to Pharma = Machinery manufacturers & suppliers, Pharmaceutical & Biotech = Industries, Thermal Power Stations, Chemical Plants and Heavy Engineering = Sectors in all over world. Himsan Polymer (An ISO 9001:2008 Certified = Company)(1) A Destination to Endless diversities CATEGORIES:- TUBINGS, = BRAIDED HOSES, O RINGS, FBD INFLATABLE GASKETS, EXTRUDED DOOR GASKETS, = RUBBER SHEETS, AUTO CLAVE DOOR GASKETS, RUBBER EXPANSION BELLOW, = COMPRESSION BELLOW, DIAPHRAGMS, SQUARE, RECTANGULAR & ROUND CORDS, = ENVELOPE GASKETS, GLAND PACKING ROPES, SHIFTER GASKETS, RMG GASKETS MOC:- = SILICONE,VITON, EPDM, NEOPRENE, NITRILE(NBR), BUTYL, POLY BUTADINE, = HYPALON, SBR, NATURAL, PTFE, PVC, NYLON (2) In-house Testing facility = We have got in house well =E2=80=93 equipped testing facility, and our = each supply accomplishes our own Testing certificates. Our products are as = per FDA standard. Non Toxic and safety designed for Food =E2=80=93 Pharma = =E2=80=93 Medical Application. Thanking you and looking forward to your = fruitful business association with us. Humbly waiting your kind feedback. = Thanks & Regards, Sreesanth Saruvil Himsan Polymer (An ISO 9001:2008 = Certified Company) CORPORATE OFFICE:- R-1,SAI KRUPA NIWAS, OPP. KAMLAKAR = BHANDARI HOUSE, CHARKOP VILLAGE, KANDIVALI WEST-400067 FACTORY:- B/1, = VISHAL INDL. ESTATE, PANCHAL, NEAR HP GAS GODOWN, BHAYANDER (E)-401105 = EMAIL:- sales@himsanpolymer.com MOB:- +91-7738363930 / +91-7715871508 / = 09/ 10 www.himsanpolymer.com FACEBOOK:- = facebook.com/himsanpolymer TWITTER:- www.twitter.com/HimsanPolymer = LINKEDIN:- in.linkedin.com/in/himsanpolymer WHATSAPP:- = +91-7738363930 / +91-7715871510Himsan Polymer (An ISO 9001:2008 Certified = Company) Silicone Transparent Tubings (Platinum Cured & Peroxide = Cured) 1) Made from medical grade Silicone Rubber which complies With = USP class VI requirement & FDA 21 CFR 177.2600 2) Suitable for = Peristaltic Pump applications. 3) Temperature resistance = from-80=C2=B0C to+250=C2=B0C [-110=C2=B0F to +480=C2=B0F] 4) = Sterilisable by steam, dry heat, ethylene oxide (ETO) and gamma radiation. = 5) Available in sizes ranging from 0.3 mm ID to 98 mm ID 6) Food = - Pharma - Medical Grade and Complies with USP class VI requirement & = FDA 21 CFR 177.2600 Himsan Polymer (An ISO 9001:2008 Certified Company) = Silicone Braided Hoses (Platinum Cured & Peroxide Cured) 1) Made = from medical grade Silicone Rubber which complies With USP class VI = requirement & FDA 21 CFR 177.2600 2) Suitable for Peristaltic = Pump applications. 3) Temperature resistance from-80=C2=B0C = to+250=C2=B0C [-110=C2=B0F to +480=C2=B0F] 4) Sterilisable by steam, = dry heat, ethylene oxide (ETO) and gamma radiation. 5) Available in = sizes ranging from 1/4=E2=80=9D ID to 2=E2=80=9D ID 6) Food - Pharma = - Medical Grade and Complies with USP class VI requirement & FDA 21 = CFR 177.2600 Himsan Polymer (An ISO 9001:2008 Certified Company) = Silicone SS Braided Hoses (Platinum Cured & Peroxide Cured) 1) = Made from medical grade Silicone Rubber which complies With USP class VI = requirement & FDA 21 CFR 177.2600 2) Suitable for Peristaltic = Pump applications. 3) Temperature resistance from-80=C2=B0C = to+250=C2=B0C [-110=C2=B0F to +480=C2=B0F] 4) Sterilisable by steam, = dry heat, ethylene oxide (ETO) and gamma radiation. 5) Available in = sizes ranging from 1/2=E2=80=9D ID to 1.5=E2=80=9D ID 6) Food - = Pharma - Medical Grade and Complies with USP class VI requirement & = FDA 21 CFR 177.2600 Himsan Polymer (An ISO 9001:2008 Certified = Company)Inflatable Gaskets For FBD / FBE / FBC & Sterilizers Our = FBD Inflatable Gasket functions like a cycle tube. When inflated, it seals = the bowl and ensures proper sealing. It is being made up of Food-Pharma = Grade white Neoprene Rubber. This Gasket is inflated by 10 mm to 12 mm = when 2 to 4kg pressure is applied. There basically three gaskets in fluid = bed dryer:- 1) PC-Top Bowl Sealing Gasket. (40mm x 22mm) 2) PC-Bottom = Sealing Gasket. (40mm x 22mm) 3) Fitter Press Bag Sealing Gasket. (50mm x = 20mm) Himsan Polymer (An ISO 9001:2008 Certified Company) Tri-Clover = (T/C) Gaskets 1) Made from medical grade Silicone Rubber which = complies With USP class VI requirement & FDA 21 CFR 177.2600 2) = Available in sizes ranging from 1/2=E2=80=9D ID to 1.5=E2=80=9D ID 3) = Sizes Available are 1/4", 3/8", 1/2", 1", 1.5", = 2", 2.5",3=E2=80=9D,4=E2=80=9D,6=E2=80=9D & Any Other Custom = sizes. Himsan Polymer (An ISO 9001:2008 Certified Company)Silicone = Autoclave & Sterilizer Door Gasket (Non-Inflatable) We offer its = wide range of Sillicone Autoclave Gasket in more than 1000 different = shapes and designs. We also offer soft Sillicone Sponge Gasket (Hardness = range from Shore A15 to 30) to Solid silicone Gasket (Hardness range from = Shore A 35 to 85). These Gaskets are being made from Food-Pharma Grade = Sillicone Rubber. It easily withstands a temperature range of -80=C2=B0C = to + 300=C2=B0C. These gaskets are available in square cross sections = like 20mm x 20mm, 25mm x 25mm x 25mm with central hole of 10mm Dia etc. = These gaskets are available in Red, White, Orange or any other colour as = per customer's requirement. Himsan Polymer (An ISO 9001:2008 Certified = Company) Silicone, Neoprene,Viton & PTFE Rubber Sheets Size = available from 1 feet x 1 feet up to maximum 1200 MM x 10 MTR Thickness = ranges from 1mm, 2mm to 20mm Transparent Silicone Sheet is also made = available which is of Highest Quality Standard (FDA 21CFR 177.2600) = Himsan Polymer (An ISO 9001:2008 Certified Company) Rubber O Rings We = offer it's wide range of 'O' Ring from ID 2.0mm to 600mm from it's 500 = single piece moulds. We have also successfully developed Viton 'O' Rings = of ID upto 3000mm. These 'O' Rings are manufactured on a Hydraulic Press = with tightly controlled temperature and time and ensures accurate = dimension, excellent finish, invisible flash line, properly post cured and = absolutely defect free. Himsan Polymer (An ISO 9001:2008 Certified = Company)Silicone Sponge & Solid Gaskets 1) Available in Round Square = and Rectangular Cross Section. 2) Colours are available in White, Red, = Grey, Green & Orange. 3) Complies to FDA 21 CFR 177.2600. Himsan = Polymer (An ISO 9001:2008 Certified Company) Viton, Nitrile, EPDM & = PTFE Tubes 1) Designed for various applications 2) Complies to FDA 21 = CER 177.2600. 3) Sizes are available as per customer=E2=80=99s = requirement. Thanks & Regards, Sreesanth Saruvil Himsan Polymer = (An ISO 9001:2008 Certified Company) CORPORATE OFFICE:- R-1,SAI KRUPA = NIWAS, OPP. KAMLAKAR BHANDARI HOUSE, CHARKOP VILLAGE, KANDIVALI = WEST-400067 FACTORY:- B/1, VISHAL INDL. ESTATE, PANCHAL, NEAR HP GAS = GODOWN, BHAYANDER (E)-401105 EMAIL:- sales@himsanpolymer.com MOB:- = +91-7738363930 / +91-7715871508 / 09/ 10 www.himsanpolymer.com = FACEBOOK:- facebook.com/himsanpolymer TWITTER:- = www.twitter.com/HimsanPolymer LINKEDIN:- = in.linkedin.com/in/himsanpolymer WHATSAPP:- +91-7738363930 / = +91-7715871510 Himsan Polymer (An ISO 9001:2008 Certified Company) =09 =09 =09 =09 This email was sent from himsanpolymer@yahoo.com to = freebsd-arch@FreeBSD.org =09 =09 Forward Mail Click here =09 =09 To unsubscribe from this list please Click here webcast129.com=20 =09 =09 To report an abuse complaint or for problem resolution please Click = here