From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 1 00:04:39 2015 Return-Path: Delivered-To: freebsd-hackers@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 B626EEFE for ; Mon, 1 Jun 2015 00:04:39 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from know-smtprelay-omc-5.server.virginmedia.net (know-smtprelay-omc-5.server.virginmedia.net [80.0.253.69]) by mx1.freebsd.org (Postfix) with ESMTP id 2E23D1DE0 for ; Mon, 1 Jun 2015 00:04:38 +0000 (UTC) (envelope-from j.deboynepollard-newsgroups@ntlworld.com) Received: from [192.168.1.100] ([86.20.122.200]) by know-smtprelay-5-imp with bizsmtp id ao3T1q00e4KXVwe01o3T9f; Mon, 01 Jun 2015 01:03:28 +0100 X-Originating-IP: [86.20.122.200] X-Spam: 0 X-Authority: v=2.1 cv=Sd8KDalu c=1 sm=1 tr=0 a=WByauD8lJrWvBFCNrxRoEQ==:117 a=WByauD8lJrWvBFCNrxRoEQ==:17 a=LdKPt8bmWjYA:10 a=N659UExz7-8A:10 a=NLZqzBF-AAAA:8 a=rsrMG00WocOAskGYwyUA:9 a=pILNOxqGKmIA:10 a=XdyKOaxJwVsA:10 a=A_Ij85UXA3UA:10 a=NJfp1ZnvUGcA:10 Message-ID: <556BA130.50708@NTLWorld.com> Date: Mon, 01 Jun 2015 01:02:56 +0100 From: Jonathan de Boyne Pollard User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: debian-user@lists.debian.org, "supervision@list.skarnet.org" , FreeBSD Hackers Subject: nosh version 1.16 References: <54430B41.3010301@NTLWorld.com> <54B86FD5.3090203@NTLWorld.com> <554E53EF.4080600@NTLWorld.com> <554E93AF.3070709@NTLWorld.com> In-Reply-To: <554E93AF.3070709@NTLWorld.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 00:04:39 -0000 nosh is now up to version 1.16 * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html As you'll see, the WWW pages have expanded a bit. In part this is because of the Big News, which is the arrival of FreeBSD packages, bringing FreeBSD up to par with Debian. The old box down the right-hand side of the page was starting to make the thing look lop-sided. (-: * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/freebsd-binary-packages.html * http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh/debian-binary-packages.html More big news on the package front is the reorganization into a main "bundles" package and a group of "-run" packages. Lesser news is the addition of packages for enabling/running various further groups of services. Comparatively small news are things like the change to the output of "system-control status" and "service-status", which now uses long form that displays more information. "svstat" retains its 1 line short form, however. There's also a "system-control cat" command, for dumping out service bundle configuration files. The new "emergency-login" fills the gap where FreeBSD lacks a "sulogin" (because it's hardwired into the old "init" and thus unusable separately), and also means that there's no need to rely upon the old System 5 utilities/Linux utilities for "sulogin" on Linux. There is also a new roadmap WWW page. The Nosh Guide has also gained several new pages dealing with logging and the import of external stuff. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 1 16:55:52 2015 Return-Path: Delivered-To: freebsd-hackers@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 E090EE80 for ; Mon, 1 Jun 2015 16:55:52 +0000 (UTC) (envelope-from Suresh.Gumpula@netapp.com) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mx142.netapp.com", Issuer "VeriSign Class 3 International Server CA - G3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B40F31981 for ; Mon, 1 Jun 2015 16:55:52 +0000 (UTC) (envelope-from Suresh.Gumpula@netapp.com) X-IronPort-AV: E=Sophos;i="5.13,534,1427785200"; d="scan'208";a="44639024" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx142-out.netapp.com with ESMTP; 01 Jun 2015 09:50:52 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 1 Jun 2015 09:50:51 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([fe80::10a9:77a2:f937:e9da]) by hioexcmbx03-prd.hq.netapp.com ([fe80::10a9:77a2:f937:e9da%21]) with mapi id 15.00.1076.000; Mon, 1 Jun 2015 09:50:50 -0700 From: "Gumpula, Suresh" To: "freebsd-hackers@freebsd.org" Subject: Re: Use after free check for all private zones too Thread-Topic: Use after free check for all private zones too Thread-Index: AQHQhopTQv6FyLvjkE2duWbwV+tNQZ2YO22A Date: Mon, 1 Jun 2015 16:50:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.56.79] Content-Type: multipart/mixed; boundary="_002_D19203B63975Cgsureshnetappcom_" MIME-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:55:53 -0000 --_002_D19203B63975Cgsureshnetappcom_ Content-Type: text/plain; charset="us-ascii" Content-ID: <17DE2A073DA2BD4CB2583EE0D741C3BC@hq.netapp.com> Content-Transfer-Encoding: quoted-printable Hi, I have attached the diff. Can somebody please review and commit this ? Thanks Suresh On 5/4/15, 12:49 PM, "Gumpula, Suresh" wrote: >Hi , > Currently use after free check is available for power of 2 malloc >zones ( mt_rash_ctor/ m_trash_dotr ) which writes uma_junk(0xdeadc0de) on >freed memory and >validates on reusing the object for others . > Similary we( NETAPP) have added a check for all other private zones >too with trash_ctor/ trash_dtor . We pass the trash_ctor/trash_dtor >to uma_zcreate(9) if it is called with NULL for constructor/destructor. >This change uncovered the couple of bugs inernally. One of this is in >tcp timer bug >https://svnweb.freebsd.org/base?view=3Drevision&revision=3D281599 > >Its a useful check and uncovers use after free bugs . Would like to push >this change . Any comments/suggestions please ? > >Thanks >Suresh > > > >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" --_002_D19203B63975Cgsureshnetappcom_ Content-Type: application/octet-stream; name="patch.patch" Content-Description: patch.patch Content-Disposition: attachment; filename="patch.patch"; size=1446; creation-date="Mon, 01 Jun 2015 16:50:49 GMT"; modification-date="Mon, 01 Jun 2015 16:50:49 GMT" Content-ID: <65EE2E0E69E38741ABDC01EE474295E6@hq.netapp.com> Content-Transfer-Encoding: base64 ZGlmZiAtdXJOIGhlYWQvc3lzL3ZtL3VtYV9jb3JlLmMgem9uZV9jcHVfY2FjaGUvc3lzL3ZtL3Vt YV9jb3JlLmMKLS0tIGhlYWQvc3lzL3ZtL3VtYV9jb3JlLmMJMjAxNC0xMS0xMyAyMDozNjo0NS4w MTE0MDYwMDAgLTA1MDAKKysrIHpvbmVfY3B1X2NhY2hlL3N5cy92bS91bWFfY29yZS5jCTIwMTUt MDUtMjEgMTA6MzM6NDEuMjM5NTY4MDAwIC0wNDAwCkBAIC0xOTM5LDYgKzE5MzksMTcgQEAKIAlh cmdzLmR0b3IgPSBkdG9yOwogCWFyZ3MudW1pbml0ID0gdW1pbml0OwogCWFyZ3MuZmluaSA9IGZp bmk7CisjaWZkZWYgIElOVkFSSUFOVFMKKyAgICAgICAgLypJZiBhIHpvbmUgaXMgYmVpbmcgY3Jl YXRlZCB3aXRoIGFuIGVtcHR5IGNvbnN0cnVjdG9yIGFuZCBkZXN0cnVjdG9yICwgcGFzcyBVTUEg Y29uc3RydWN0b3IvZGVzdHJ1Y3RvcgorICAgICAgICAgIHdoaWNoIGNoZWNrIGZvciB1c2UgYWZ0 ZXIgZnJlZSBvZiBtZW1vcnkKKyAgICAgICAgICAqLworICAgICAgICBpZiAoKCEoZmxhZ3MgJiBV TUFfWk9ORV9aSU5JVCkpICYmIGN0b3IgPT0gTlVMTCAmJiBkdG9yID09IE5VTEwgJiYgdW1pbml0 ID09IE5VTEwgJiYgZmluaSA9PSBOVUxMKSB7CisgICAgICAgICAgICAgICAgYXJncy5jdG9yID0g dHJhc2hfY3RvcjsKKyAgICAgICAgICAgICAgICBhcmdzLmR0b3IgPSB0cmFzaF9kdG9yOworICAg ICAgICAgICAgICAgIGFyZ3MudW1pbml0ID0gdHJhc2hfaW5pdDsKKyAgICAgICAgICAgICAgICBh cmdzLmZpbmkgPSB0cmFzaF9maW5pOworICAgICAgICB9CisjZW5kaWYKIAlhcmdzLmFsaWduID0g YWxpZ247CiAJYXJncy5mbGFncyA9IGZsYWdzOwogCWFyZ3Mua2VnID0gTlVMTDsKZGlmZiAtdXJO IGhlYWQvc3lzL3ZtL3VtYV9kYmcuYyB6b25lX2NwdV9jYWNoZS9zeXMvdm0vdW1hX2RiZy5jCi0t LSBoZWFkL3N5cy92bS91bWFfZGJnLmMJMjAxNC0xMS0xMyAyMDozNjo0NC44MTQ0MDAwMDAgLTA1 MDAKKysrIHpvbmVfY3B1X2NhY2hlL3N5cy92bS91bWFfZGJnLmMJMjAxNS0wNS0yMSAxMDozNjow NC44NTg0NjgwMDAgLTA0MDAKQEAgLTY5LDggKzY5LDExIEBACiAKIAlmb3IgKHAgPSBtZW07IGNu dCA+IDA7IGNudC0tLCBwKyspCiAJCWlmICgqcCAhPSB1bWFfanVuaykgewotCQkJcHJpbnRmKCJN ZW1vcnkgbW9kaWZpZWQgYWZ0ZXIgZnJlZSAlcCglZCkgdmFsPSV4IEAgJXBcbiIsCi0JCQkgICAg bWVtLCBzaXplLCAqcCwgcCk7CisjaWZkZWYgSU5WQVJJQU5UUworCQkJcGFuaWMoIk1lbW9yeSBt b2RpZmllZCBhZnRlciBmcmVlICVwKCVkKSB2YWw9JXggQCAlcFxuIiwgbWVtLCBzaXplLCAqcCwg cCk7CisjZWxzZQorCQkJcHJpbnRmKCJNZW1vcnkgbW9kaWZpZWQgYWZ0ZXIgZnJlZSAlcCglZCkg dmFsPSV4IEAgJXBcbiIsIG1lbSwgc2l6ZSwgKnAsIHApOworI2VuZGlmCiAJCQlyZXR1cm4gKDAp OwogCQl9CiAJcmV0dXJuICgwKTsK --_002_D19203B63975Cgsureshnetappcom_-- From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 3 11:46:20 2015 Return-Path: Delivered-To: freebsd-hackers@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 ACD78BA5 for ; Wed, 3 Jun 2015 11:46:20 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) (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 37E6B1C55 for ; Wed, 3 Jun 2015 11:46:19 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id ED35E2A1989; Wed, 3 Jun 2015 13:46:13 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id V6BaU5sOap6a; Wed, 3 Jun 2015 13:46:13 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 690AE2A1962; Wed, 3 Jun 2015 13:46:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7Kx9uFSD5CxU; Wed, 3 Jun 2015 13:46:13 +0200 (CEST) Received: from huber-linux.eb.localhost (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTP id 40C192A1939; Wed, 3 Jun 2015 13:46:13 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Cc: phk@phk.freebsd.dk, Sebastian Huber Subject: [PATCH] timecounters: Fix timehand generation read/write Date: Wed, 3 Jun 2015 13:46:06 +0200 Message-Id: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 1.8.4.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 11:46:20 -0000 The compiler is free to re-order load/store instructions to non-volatile variables around a load/store of a volatile variable. So the volatile generation counter is insufficent. In addition tests on a Freescale T4240 platform with 24 PowerPC processors showed that real memory barriers are required. Compiler memory barriers are not enough. For the test the timehand count was reduced to one with 10000 tc_windup() calls per second. The timehand memory location was adjusted so that the th_generation field was on its own cache line. --- sys/kern/kern_tc.c | 102 +++++++++++++++++++++++++++++++---------------------- 1 file changed, 60 insertions(+), 42 deletions(-) diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 9dca0e8..00768cf 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -71,7 +71,7 @@ struct timehands { struct timeval th_microtime; struct timespec th_nanotime; /* Fields not to be copied in tc_windup start with th_generation. */ - volatile u_int th_generation; + u_int th_generation; struct timehands *th_next; }; @@ -189,6 +189,24 @@ tc_delta(struct timehands *th) tc->tc_counter_mask); } +static u_int +tc_getgen(struct timehands *th) +{ + u_int gen; + + gen = th->th_generation; + rmb(); + return (gen); +} + +static void +tc_setgen(struct timehands *th, u_int newgen) +{ + + wmb(); + th->th_generation = newgen; +} + /* * Functions for reading the time. We have to loop until we are sure that * the timehands that we operated on was not updated under our feet. See @@ -204,10 +222,10 @@ fbclock_binuptime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; bintime_addx(bt, th->th_scale * tc_delta(th)); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -262,9 +280,9 @@ fbclock_getbinuptime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -275,9 +293,9 @@ fbclock_getnanouptime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); bintime2timespec(&th->th_offset, tsp); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -288,9 +306,9 @@ fbclock_getmicrouptime(struct timeval *tvp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); bintime2timeval(&th->th_offset, tvp); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -301,9 +319,9 @@ fbclock_getbintime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); bintime_add(bt, &boottimebin); } @@ -315,9 +333,9 @@ fbclock_getnanotime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tsp = th->th_nanotime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -328,9 +346,9 @@ fbclock_getmicrotime(struct timeval *tvp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tvp = th->th_microtime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } #else /* !FFCLOCK */ void @@ -341,10 +359,10 @@ binuptime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; bintime_addx(bt, th->th_scale * tc_delta(th)); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -399,9 +417,9 @@ getbinuptime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -412,9 +430,9 @@ getnanouptime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); bintime2timespec(&th->th_offset, tsp); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -425,9 +443,9 @@ getmicrouptime(struct timeval *tvp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); bintime2timeval(&th->th_offset, tvp); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -438,9 +456,9 @@ getbintime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); bintime_add(bt, &boottimebin); } @@ -452,9 +470,9 @@ getnanotime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tsp = th->th_nanotime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -465,9 +483,9 @@ getmicrotime(struct timeval *tvp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tvp = th->th_microtime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } #endif /* FFCLOCK */ @@ -880,11 +898,11 @@ ffclock_read_counter(ffcounter *ffcount) */ do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); ffth = fftimehands; delta = tc_delta(th); *ffcount = ffth->tick_ffcount; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); *ffcount += delta; } @@ -988,9 +1006,9 @@ dtrace_getnanotime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tsp = th->th_nanotime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } /* @@ -1028,7 +1046,7 @@ sysclock_getsnapshot(struct sysclock_snap *clock_snap, int fast) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); fbi->th_scale = th->th_scale; fbi->tick_time = th->th_offset; #ifdef FFCLOCK @@ -1042,7 +1060,7 @@ sysclock_getsnapshot(struct sysclock_snap *clock_snap, int fast) #endif if (!fast) delta = tc_delta(th); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); clock_snap->delta = delta; clock_snap->sysclock_active = sysclock_active; @@ -1259,8 +1277,8 @@ tc_windup(void) */ tho = timehands; th = tho->th_next; - ogen = th->th_generation; - th->th_generation = 0; + ogen = tc_getgen(th); + tc_setgen(th, 0); bcopy(tho, th, offsetof(struct timehands, th_generation)); /* @@ -1377,7 +1395,7 @@ tc_windup(void) */ if (++ogen == 0) ogen = 1; - th->th_generation = ogen; + tc_setgen(th, ogen); /* Go live with the new struct timehands. */ #ifdef FFCLOCK @@ -1651,13 +1669,13 @@ pps_capture(struct pps_state *pps) KASSERT(pps != NULL, ("NULL pps pointer in pps_capture")); th = timehands; - pps->capgen = th->th_generation; + pps->capgen = tc_getgen(th); pps->capth = th; #ifdef FFCLOCK pps->capffth = fftimehands; #endif pps->capcount = th->th_counter->tc_get_timecount(th->th_counter); - if (pps->capgen != th->th_generation) + if (pps->capgen != tc_getgen(th)) pps->capgen = 0; } @@ -1677,7 +1695,7 @@ pps_event(struct pps_state *pps, int event) KASSERT(pps != NULL, ("NULL pps pointer in pps_event")); /* If the timecounter was wound up underneath us, bail out. */ - if (pps->capgen == 0 || pps->capgen != pps->capth->th_generation) + if (pps->capgen == 0 || pps->capgen != tc_getgen(pps->capth)) return; /* Things would be easier with arrays. */ @@ -1727,7 +1745,7 @@ pps_event(struct pps_state *pps, int event) bintime2timespec(&bt, &ts); /* If the timecounter was wound up underneath us, bail out. */ - if (pps->capgen != pps->capth->th_generation) + if (pps->capgen != tc_getgen(pps->capth)) return; *pcount = pps->capcount; -- 1.8.4.5 From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 3 11:52:53 2015 Return-Path: Delivered-To: freebsd-hackers@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 D77F1D26 for ; Wed, 3 Jun 2015 11:52:53 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) (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 62A081E7C for ; Wed, 3 Jun 2015 11:52:53 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 24AEA2A198A; Wed, 3 Jun 2015 13:52:54 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4SJDVaVZO0tu; Wed, 3 Jun 2015 13:52:53 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 77E142A1989; Wed, 3 Jun 2015 13:52:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ifP8E69r4xtD; Wed, 3 Jun 2015 13:52:53 +0200 (CEST) Received: from huber-linux.eb.localhost (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTP id 4AED32A1939; Wed, 3 Jun 2015 13:52:53 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Cc: phk@phk.freebsd.dk, Sebastian Huber Subject: [PATCH v2] timecounters: Fix timehand generation read/write Date: Wed, 3 Jun 2015 13:52:48 +0200 Message-Id: <1433332368-27645-1-git-send-email-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 1.8.4.5 In-Reply-To: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 11:52:53 -0000 The compiler is free to re-order load/store instructions to non-volatile variables around a load/store of a volatile variable. So the volatile generation counter is insufficent. In addition tests on a Freescale T4240 platform with 24 PowerPC processors showed that real memory barriers are required. Compiler memory barriers are not enough. For the test the timehand count was reduced to one with 10000 tc_windup() calls per second. The timehand memory location was adjusted so that the th_generation field was on its own cache line. --- v2: Don't use tc_getgen() in tc_windup() since in the only writer there is no need for a read memory barrier. sys/kern/kern_tc.c | 100 +++++++++++++++++++++++++++++++---------------------- 1 file changed, 59 insertions(+), 41 deletions(-) diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 9dca0e8..bb9614a 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -71,7 +71,7 @@ struct timehands { struct timeval th_microtime; struct timespec th_nanotime; /* Fields not to be copied in tc_windup start with th_generation. */ - volatile u_int th_generation; + u_int th_generation; struct timehands *th_next; }; @@ -189,6 +189,24 @@ tc_delta(struct timehands *th) tc->tc_counter_mask); } +static u_int +tc_getgen(struct timehands *th) +{ + u_int gen; + + gen = th->th_generation; + rmb(); + return (gen); +} + +static void +tc_setgen(struct timehands *th, u_int newgen) +{ + + wmb(); + th->th_generation = newgen; +} + /* * Functions for reading the time. We have to loop until we are sure that * the timehands that we operated on was not updated under our feet. See @@ -204,10 +222,10 @@ fbclock_binuptime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; bintime_addx(bt, th->th_scale * tc_delta(th)); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -262,9 +280,9 @@ fbclock_getbinuptime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -275,9 +293,9 @@ fbclock_getnanouptime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); bintime2timespec(&th->th_offset, tsp); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -288,9 +306,9 @@ fbclock_getmicrouptime(struct timeval *tvp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); bintime2timeval(&th->th_offset, tvp); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -301,9 +319,9 @@ fbclock_getbintime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); bintime_add(bt, &boottimebin); } @@ -315,9 +333,9 @@ fbclock_getnanotime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tsp = th->th_nanotime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -328,9 +346,9 @@ fbclock_getmicrotime(struct timeval *tvp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tvp = th->th_microtime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } #else /* !FFCLOCK */ void @@ -341,10 +359,10 @@ binuptime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; bintime_addx(bt, th->th_scale * tc_delta(th)); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -399,9 +417,9 @@ getbinuptime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -412,9 +430,9 @@ getnanouptime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); bintime2timespec(&th->th_offset, tsp); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -425,9 +443,9 @@ getmicrouptime(struct timeval *tvp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); bintime2timeval(&th->th_offset, tvp); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -438,9 +456,9 @@ getbintime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); bintime_add(bt, &boottimebin); } @@ -452,9 +470,9 @@ getnanotime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tsp = th->th_nanotime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -465,9 +483,9 @@ getmicrotime(struct timeval *tvp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tvp = th->th_microtime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } #endif /* FFCLOCK */ @@ -880,11 +898,11 @@ ffclock_read_counter(ffcounter *ffcount) */ do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); ffth = fftimehands; delta = tc_delta(th); *ffcount = ffth->tick_ffcount; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); *ffcount += delta; } @@ -988,9 +1006,9 @@ dtrace_getnanotime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tsp = th->th_nanotime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } /* @@ -1028,7 +1046,7 @@ sysclock_getsnapshot(struct sysclock_snap *clock_snap, int fast) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); fbi->th_scale = th->th_scale; fbi->tick_time = th->th_offset; #ifdef FFCLOCK @@ -1042,7 +1060,7 @@ sysclock_getsnapshot(struct sysclock_snap *clock_snap, int fast) #endif if (!fast) delta = tc_delta(th); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); clock_snap->delta = delta; clock_snap->sysclock_active = sysclock_active; @@ -1260,7 +1278,7 @@ tc_windup(void) tho = timehands; th = tho->th_next; ogen = th->th_generation; - th->th_generation = 0; + tc_setgen(th, 0); bcopy(tho, th, offsetof(struct timehands, th_generation)); /* @@ -1377,7 +1395,7 @@ tc_windup(void) */ if (++ogen == 0) ogen = 1; - th->th_generation = ogen; + tc_setgen(th, ogen); /* Go live with the new struct timehands. */ #ifdef FFCLOCK @@ -1651,13 +1669,13 @@ pps_capture(struct pps_state *pps) KASSERT(pps != NULL, ("NULL pps pointer in pps_capture")); th = timehands; - pps->capgen = th->th_generation; + pps->capgen = tc_getgen(th); pps->capth = th; #ifdef FFCLOCK pps->capffth = fftimehands; #endif pps->capcount = th->th_counter->tc_get_timecount(th->th_counter); - if (pps->capgen != th->th_generation) + if (pps->capgen != tc_getgen(th)) pps->capgen = 0; } @@ -1677,7 +1695,7 @@ pps_event(struct pps_state *pps, int event) KASSERT(pps != NULL, ("NULL pps pointer in pps_event")); /* If the timecounter was wound up underneath us, bail out. */ - if (pps->capgen == 0 || pps->capgen != pps->capth->th_generation) + if (pps->capgen == 0 || pps->capgen != tc_getgen(pps->capth)) return; /* Things would be easier with arrays. */ @@ -1727,7 +1745,7 @@ pps_event(struct pps_state *pps, int event) bintime2timespec(&bt, &ts); /* If the timecounter was wound up underneath us, bail out. */ - if (pps->capgen != pps->capth->th_generation) + if (pps->capgen != tc_getgen(pps->capth)) return; *pcount = pps->capcount; -- 1.8.4.5 From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 3 14:56:19 2015 Return-Path: Delivered-To: freebsd-hackers@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 91298CE4 for ; Wed, 3 Jun 2015 14:56:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 04CA71BF2 for ; Wed, 3 Jun 2015 14:56:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t53Eu67w097596 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 3 Jun 2015 17:56:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t53Eu67w097596 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t53Eu660097595; Wed, 3 Jun 2015 17:56:06 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 3 Jun 2015 17:56:06 +0300 From: Konstantin Belousov To: Sebastian Huber Cc: freebsd-hackers@freebsd.org, phk@phk.freebsd.dk Subject: Re: [PATCH v2] timecounters: Fix timehand generation read/write Message-ID: <20150603145606.GW2499@kib.kiev.ua> References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> <1433332368-27645-1-git-send-email-sebastian.huber@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1433332368-27645-1-git-send-email-sebastian.huber@embedded-brains.de> 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 14:56:19 -0000 On Wed, Jun 03, 2015 at 01:52:48PM +0200, Sebastian Huber wrote: > The compiler is free to re-order load/store instructions to non-volatile > variables around a load/store of a volatile variable. So the volatile > generation counter is insufficent. In addition tests on a Freescale > T4240 platform with 24 PowerPC processors showed that real memory > barriers are required. Compiler memory barriers are not enough. > > For the test the timehand count was reduced to one with 10000 > tc_windup() calls per second. The timehand memory location was adjusted > so that the th_generation field was on its own cache line. > --- > > v2: Don't use tc_getgen() in tc_windup() since in the only writer there is no > need for a read memory barrier. > > sys/kern/kern_tc.c | 100 +++++++++++++++++++++++++++++++---------------------- > 1 file changed, 59 insertions(+), 41 deletions(-) > > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c > index 9dca0e8..bb9614a 100644 > --- a/sys/kern/kern_tc.c > +++ b/sys/kern/kern_tc.c > @@ -71,7 +71,7 @@ struct timehands { > struct timeval th_microtime; > struct timespec th_nanotime; > /* Fields not to be copied in tc_windup start with th_generation. */ > - volatile u_int th_generation; > + u_int th_generation; > struct timehands *th_next; > }; > > @@ -189,6 +189,24 @@ tc_delta(struct timehands *th) > tc->tc_counter_mask); > } > > +static u_int > +tc_getgen(struct timehands *th) > +{ > + u_int gen; > + > + gen = th->th_generation; > + rmb(); > + return (gen); Why not return (atomic_load_acq_int(&th->th_generation); ? > +} > + > +static void > +tc_setgen(struct timehands *th, u_int newgen) > +{ > + > + wmb(); > + th->th_generation = newgen; And there, atomic_store_rel_int(&th->th_generation, newgen); ? From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 3 15:36:08 2015 Return-Path: Delivered-To: freebsd-hackers@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 6250754A for ; Wed, 3 Jun 2015 15:36:08 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from nm49-vm10.bullet.mail.bf1.yahoo.com (nm49-vm10.bullet.mail.bf1.yahoo.com [216.109.114.251]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1031616B7 for ; Wed, 3 Jun 2015 15:36:07 +0000 (UTC) (envelope-from pfg@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1433345598; bh=GWLLLfjsBDjBg2E3EB2ywpcb9KccUZFtPlkeMhUXNeA=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=UTYIMvUQmUuGjhVglGGj/slg5C+i3IkyL8BJntekRe72etxKMwYKN8ps9Izfc43nuYoFGKrVoBmxnRByBgPO3EoXDCzfVHzTQOgaUf3upOewGqOFlPq2vqLWRx/BjuglnUK3R0iHEG8XphE8I6bKR8d7dSRKsHk7D8vmdK37UuY3B25Z9NUEBF0dP/p8VqYH/8t1fJ8ulvYNXUwDbnECVr0ExLLLdkVpFQ27/h2G0D9wh3/aOTd7w7H2P/XEHjFGdmgP/Fl1aJ7RFOCoXCoPrt7MXN+U40ZIQ/onAqwYBsuE2W+taq1YaR5YquzMgjvK4xeZX1smuF3Z7334HXZzGQ== Received: from [98.139.170.182] by nm49.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jun 2015 15:33:18 -0000 Received: from [98.139.211.160] by tm25.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jun 2015 15:33:18 -0000 Received: from [127.0.0.1] by smtp217.mail.bf1.yahoo.com with NNFMP; 03 Jun 2015 15:33:18 -0000 X-Yahoo-Newman-Id: 480741.30305.bm@smtp217.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Gng8hXcVM1lpCatuJSyjW9edj8ct8HHBd32djbGKDLI2KH5 LGJ_utln3ID7vpeZmiQXxJid2tIG4MEZR7ZaLRDgxSRBCLY3cUFlYdgoP.2l nZlOMUQF4GVNtEzDr.O7KIbdEzwobMWbuP2m8z0fuAK_QO_rtwvipqfQTQjv dHYJxcPSdlxkX33wL0X5yKOEKfVsY96abUwGWwfKeb74UTDN0Zp5NFMyROc. GxlK_r96Coal3RtJzNaQkFZUsXYmditoPygTSowlA_vP2dOHQ3ROW66bVMc7 mwRY0O55Os4lOhMkYwyandBiCdZ77sr_wxgF.bHXdMqhrj1vGEOtFdHLX_nx P78xn4ziTtnUCRT45Y5XiqzVN2pupO8sMACAlOjICUYHbvgfU_cwOSY5sGXe KrDhxgOhR9KIyBIpgAqYYjIkF1Y8TOSvHWAfJtPHR52WIU_5m3kIFEolWOIf goAsbvb..BVidz1YsaoahV4tQ8Fr8tUxmbiMGenR4OSo.iU39gfNtmT.tq72 GbcVCTJ4anEn7ZXnLzwvHGVh.XbbFgkg- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf Message-ID: <556F1E41.4090301@FreeBSD.org> Date: Wed, 03 Jun 2015 10:33:21 -0500 From: Pedro Giffuni User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Gumpula, Suresh" , FreeBSD Hackers Subject: Re: Use after free check for all private zones too References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 15:36:08 -0000 Hello; I have created a Code Differential for this: https://reviews.freebsd.org/D2725 Feel free to review, enhance, comment or even commit ;). Pedro. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 3 20:32:49 2015 Return-Path: Delivered-To: freebsd-hackers@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 CED19FBE for ; Wed, 3 Jun 2015 20:32:49 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CC9A1326 for ; Wed, 3 Jun 2015 20:32:48 +0000 (UTC) (envelope-from joerg@britannica.bec.de) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/afgnrylsiW+zbzV1rmQ= X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de (ip-109-45-150-98.web.vodafone.de [109.45.150.98]) by smtp.strato.de (RZmta 37.6 DYNA|AUTH) with ESMTPSA id a06f8dr53KWSEcO (using TLSv1 with cipher AES256-SHA (256 bits)) (Client did not present a certificate) for ; Wed, 3 Jun 2015 22:32:28 +0200 (CEST) Received: by britannica.bec.de (sSMTP sendmail emulation); Wed, 03 Jun 2015 22:32:28 +0200 Date: Wed, 3 Jun 2015 22:32:28 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: [PATCH] timecounters: Fix timehand generation read/write Message-ID: <20150603203228.GA9774@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 20:32:49 -0000 On Wed, Jun 03, 2015 at 01:46:06PM +0200, Sebastian Huber wrote: > The compiler is free to re-order load/store instructions to non-volatile > variables around a load/store of a volatile variable. This part is wrong. The *compiler* is not free to do such reorder. The CPU may, as it doesn't really care about volatile. Joerg From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 3 21:00:57 2015 Return-Path: Delivered-To: freebsd-hackers@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 D4E2D87D for ; Wed, 3 Jun 2015 21:00:57 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) (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 800DA1A1C for ; Wed, 3 Jun 2015 21:00:56 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 7B5862A1939; Wed, 3 Jun 2015 23:00:56 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id B62Wc92hibfz; Wed, 3 Jun 2015 23:00:54 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 12AD82A1962; Wed, 3 Jun 2015 23:00:54 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id yCJ-JgxUSI6t; Wed, 3 Jun 2015 23:00:53 +0200 (CEST) Received: from zimbra.eb.localhost (zimbra.eb.localhost [192.168.96.204]) by mail.embedded-brains.de (Postfix) with ESMTP id EF3692A1939; Wed, 3 Jun 2015 23:00:53 +0200 (CEST) Date: Wed, 3 Jun 2015 23:00:53 +0200 (CEST) From: Sebastian Huber To: Joerg Sonnenberger Cc: freebsd-hackers@freebsd.org Message-ID: <2023236942.13088.1433365253885.JavaMail.zimbra@embedded-brains.de> In-Reply-To: <20150603203228.GA9774@britannica.bec.de> References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> <20150603203228.GA9774@britannica.bec.de> Subject: Re: [PATCH] timecounters: Fix timehand generation read/write MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [192.168.102.3] X-Mailer: Zimbra 8.6.0_GA_1153 (zclient/8.6.0_GA_1153) Thread-Topic: timecounters: Fix timehand generation read/write Thread-Index: sIVYr1uuEJoSO7ZaiWVuDVOsoSEraA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 21:00:57 -0000 In my interpretation of the C standard this is implementation defined behav= iour. See also: https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html ----- Joerg Sonnenberger schrieb: > On Wed, Jun 03, 2015 at 01:46:06PM +0200, Sebastian Huber wrote: > > The compiler is free to re-order load/store instructions to non-volatil= e > > variables around a load/store of a volatile variable. >=20 > This part is wrong. The *compiler* is not free to do such reorder. The > CPU may, as it doesn't really care about volatile. >=20 > Joerg > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber at embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 3 21:19:51 2015 Return-Path: Delivered-To: freebsd-hackers@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 F2942E7F for ; Wed, 3 Jun 2015 21:19:50 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) (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 670021DD9 for ; Wed, 3 Jun 2015 21:19:50 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id A11C92A1962; Wed, 3 Jun 2015 23:19:51 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id kFzVZ2y9VEOV; Wed, 3 Jun 2015 23:19:49 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 412212A1989; Wed, 3 Jun 2015 23:19:49 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VGFvs_SJzERH; Wed, 3 Jun 2015 23:19:49 +0200 (CEST) Received: from zimbra.eb.localhost (zimbra.eb.localhost [192.168.96.204]) by mail.embedded-brains.de (Postfix) with ESMTP id 26E142A1962; Wed, 3 Jun 2015 23:19:49 +0200 (CEST) Date: Wed, 3 Jun 2015 23:19:49 +0200 (CEST) From: Sebastian Huber To: Konstantin Belousov Cc: freebsd-hackers@freebsd.org, phk@phk.freebsd.dk Message-ID: <2127254638.13127.1433366389045.JavaMail.zimbra@embedded-brains.de> In-Reply-To: <20150603145606.GW2499@kib.kiev.ua> References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> <1433332368-27645-1-git-send-email-sebastian.huber@embedded-brains.de> <20150603145606.GW2499@kib.kiev.ua> Subject: Re: [PATCH v2] timecounters: Fix timehand generation read/write MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [192.168.102.3] X-Mailer: Zimbra 8.6.0_GA_1153 (zclient/8.6.0_GA_1153) Thread-Topic: timecounters: Fix timehand generation read/write Thread-Index: d0P9aXUEWAbTrW5w2dcl2/Lw6RzpjQ== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2015 21:19:51 -0000 ----- Konstantin Belousov schrieb: > On Wed, Jun 03, 2015 at 01:52:48PM +0200, Sebastian Huber wrote: > > The compiler is free to re-order load/store instructions to non-volatil= e > > variables around a load/store of a volatile variable. So the volatile > > generation counter is insufficent. In addition tests on a Freescale > > T4240 platform with 24 PowerPC processors showed that real memory > > barriers are required. Compiler memory barriers are not enough. > >=20 > > For the test the timehand count was reduced to one with 10000 > > tc_windup() calls per second. The timehand memory location was adjuste= d > > so that the th_generation field was on its own cache line. > > --- > >=20 > > v2: Don't use tc_getgen() in tc_windup() since in the only writer there= is no > > need for a read memory barrier. > >=20 > > sys/kern/kern_tc.c | 100 +++++++++++++++++++++++++++++++--------------= -------- > > 1 file changed, 59 insertions(+), 41 deletions(-) > >=20 > > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c > > index 9dca0e8..bb9614a 100644 > > --- a/sys/kern/kern_tc.c > > +++ b/sys/kern/kern_tc.c > > @@ -71,7 +71,7 @@ struct timehands { > > =09struct timeval=09=09th_microtime; > > =09struct timespec=09=09th_nanotime; > > =09/* Fields not to be copied in tc_windup start with th_generation. *= / > > -=09volatile u_int=09=09th_generation; > > +=09u_int=09=09=09th_generation; > > =09struct timehands=09*th_next; > > }; > > =20 > > @@ -189,6 +189,24 @@ tc_delta(struct timehands *th) > > =09 tc->tc_counter_mask); > > } > > =20 > > +static u_int > > +tc_getgen(struct timehands *th) > > +{ > > +=09u_int gen; > > + > > +=09gen =3D th->th_generation; > > +=09rmb(); > > +=09return (gen); > Why not > =09return (atomic_load_acq_int(&th->th_generation); > ? >=20 > > +} > > + > > +static void > > +tc_setgen(struct timehands *th, u_int newgen) > > +{ > > + > > +=09wmb(); > > +=09th->th_generation =3D newgen; > And there, > =09atomic_store_rel_int(&th->th_generation, newgen); > ? Ok, I will send a second version of the patch next Tuesday. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber at embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 4 18:11:12 2015 Return-Path: Delivered-To: freebsd-hackers@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 4548492A for ; Thu, 4 Jun 2015 18:11:12 +0000 (UTC) (envelope-from joerg@britannica.bec.de) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.smtp.rzone.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D303E1A8A for ; Thu, 4 Jun 2015 18:11:11 +0000 (UTC) (envelope-from joerg@britannica.bec.de) X-RZG-AUTH: :JiIXek6mfvEEUpFQdo7Fj1/zg48CFjWjQv0cW+St/nW/afgnrylsiW+zbzV1rmQ= X-RZG-CLASS-ID: mo00 Received: from britannica.bec.de (ip-109-45-150-98.web.vodafone.de [109.45.150.98]) by smtp.strato.de (RZmta 37.6 DYNA|AUTH) with ESMTPSA id 20495fr54IApR2b (using TLSv1 with cipher AES256-SHA (256 bits)) (Client did not present a certificate) for ; Thu, 4 Jun 2015 20:10:51 +0200 (CEST) Received: by britannica.bec.de (sSMTP sendmail emulation); Thu, 04 Jun 2015 20:10:41 +0200 Date: Thu, 4 Jun 2015 20:10:41 +0200 From: Joerg Sonnenberger To: freebsd-hackers@freebsd.org Subject: Re: [PATCH] timecounters: Fix timehand generation read/write Message-ID: <20150604181041.GC11630@britannica.bec.de> Mail-Followup-To: freebsd-hackers@freebsd.org References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> <20150603203228.GA9774@britannica.bec.de> <2023236942.13088.1433365253885.JavaMail.zimbra@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2023236942.13088.1433365253885.JavaMail.zimbra@embedded-brains.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2015 18:11:12 -0000 On Wed, Jun 03, 2015 at 11:00:53PM +0200, Sebastian Huber wrote: > In my interpretation of the C standard this is implementation defined behaviour. See also: > > https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html I don't think that is nearly correct as far as any data accessibly from global objects is concerned beside the volatile. C11 5.1.2.3 (2) and (3) are the relevant clauses. An assignment to a volatile object is a sequence point with side effects. All assignments before that sequence point must be visible to whatever possible side effect the volatile has. Similar, it can implicitly change all globals, so no read can be moved from after the sequence point to before. This is much stricter than the normal as-if rule, since a sequence of side-effect-free operations can be implemented anyway the compiler likes. A different interpretation would be quite questionable. Note that this is all just about the rules of the C abstract machine. It is not about the observable behavior of a multi-processor machine. Whether or not TSO is enough for this purpose is a completely different question. Joerg From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 5 17:20:42 2015 Return-Path: Delivered-To: freebsd-hackers@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 00D8E83D for ; Fri, 5 Jun 2015 17:20:41 +0000 (UTC) (envelope-from S.Kuzminsky@f5.com) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.f5.com", Issuer "Entrust Certification Authority - L1C" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A828E18FB for ; Fri, 5 Jun 2015 17:20:41 +0000 (UTC) (envelope-from S.Kuzminsky@f5.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1433524843; x=1465060843; h=from:to:subject:date:message-id:mime-version; bh=vIBmPRZc6EBh9HCKMVZqhzq8Iw7tER7qvfMiJrcu47k=; b=nbPZ8GePH27223kuQ2eJwZp8I0lqE51HgnLBl7qHYoan857/GUTnEIaW IBH9sbzMnvt7T8fkq0art8zOHLqDEgNO66WO7HTciw96GnLaCHasOl9BP KJ+Rndt+hitFIwhsVTIP+WWkotlJkLwekvjclH0mf+2LkygZYhCApQFYI Y=; X-IronPort-AV: E=Sophos;i="5.13,560,1427760000"; d="scan'208,217,223";a="165179778" X-IPAS-Result: A2CmBADi2HFV/+sKqMBbgkWCA8A3iAcBAQEBAQGBC4QZEIELAQsBRDAnBCHkLAwBH5R9BYwUiSOgZIQbgjWBAQEBAQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 05 Jun 2015 17:19:34 +0000 Received: from SEAEXCHMBX01.olympus.F5Net.com (192.168.15.223) by SEAEXCHMBX06.olympus.F5Net.com (192.168.15.49) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 5 Jun 2015 10:19:32 -0700 Received: from SEAEXCHMBX01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75]) by seaexchmbx01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75%13]) with mapi id 15.00.1044.021; Fri, 5 Jun 2015 10:19:32 -0700 From: Sebastian Kuzminsky To: "freebsd-hackers@freebsd.org" Subject: Bug in FreeBSD 10.1's pthread barrier implementation? Thread-Topic: Bug in FreeBSD 10.1's pthread barrier implementation? Thread-Index: AQHQn7PJC5hZrU3GxUi463RFdcLO+Q== Date: Fri, 5 Jun 2015 17:19:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: multipart/mixed; boundary="_004_D19736448FD0sebf5com_" MIME-Version: 1.0 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 17:20:42 -0000 --_004_D19736448FD0sebf5com_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm running in to a situation where pthread_barrier_t is not completely ini= tialized, and later pthread_barrier_destroy() fails. The attached patch (against FreeBSD 10.1) fixes the issue for me. -- Sebastian Kuzminsky --_004_D19736448FD0sebf5com_ Content-Type: application/octet-stream; name="0001-initialize-pthread_barrier_t-s-b_destroying-field.patch" Content-Description: 0001-initialize-pthread_barrier_t-s-b_destroying-field.patch Content-Disposition: attachment; filename="0001-initialize-pthread_barrier_t-s-b_destroying-field.patch"; size=799; creation-date="Fri, 05 Jun 2015 17:19:31 GMT"; modification-date="Fri, 05 Jun 2015 17:19:31 GMT" Content-ID: Content-Transfer-Encoding: base64 RnJvbSBjMGFmNDkwNTk4NmZlMjhlNTQ2MThlMWFlNjBmNGY3Yzc0MjlmNGQ3IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTZWJhc3RpYW4gS3V6bWluc2t5IDxzZWJAaGlnaGxhYi5jb20+ CkRhdGU6IEZyaSwgNSBKdW4gMjAxNSAxMToxMzo0MyAtMDYwMApTdWJqZWN0OiBbUEFUQ0hdIGlu aXRpYWxpemUgcHRocmVhZF9iYXJyaWVyX3QncyBiX2Rlc3Ryb3lpbmcgZmllbGQKClRoaXMgaW50 ZXJuYWwgc3RhdGUgdmFyaWFibGUgbmVlZHMgdG8gYmUgemVyb2VkIGF0IGluaXQtdGltZS4KClNp Z25lZC1vZmYtYnk6IFNlYmFzdGlhbiBLdXptaW5za3kgPHNlYkBmNS5jb20+Ci0tLQogbGliL2xp YnRoci90aHJlYWQvdGhyX2JhcnJpZXIuYyB8IDEgKwogMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0 aW9uKCspCgpkaWZmIC0tZ2l0IGEvbGliL2xpYnRoci90aHJlYWQvdGhyX2JhcnJpZXIuYyBiL2xp Yi9saWJ0aHIvdGhyZWFkL3Rocl9iYXJyaWVyLmMKaW5kZXggODZmODgwZS4uMGFlYjk0YiAxMDA2 NDQKLS0tIGEvbGliL2xpYnRoci90aHJlYWQvdGhyX2JhcnJpZXIuYworKysgYi9saWIvbGlidGhy L3RocmVhZC90aHJfYmFycmllci5jCkBAIC05Niw2ICs5Niw3IEBAIF9wdGhyZWFkX2JhcnJpZXJf aW5pdChwdGhyZWFkX2JhcnJpZXJfdCAqYmFycmllciwKIAliYXItPmJfd2FpdGVycwk9IDA7CiAJ YmFyLT5iX2NvdW50CT0gY291bnQ7CiAJYmFyLT5iX3JlZmNvdW50ID0gMDsKKwliYXItPmJfZGVz dHJveWluZyA9IDA7CiAJKmJhcnJpZXIJPSBiYXI7CiAKIAlyZXR1cm4gKDApOwotLSAKMi40LjAK Cg== --_004_D19736448FD0sebf5com_-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 5 17:37:11 2015 Return-Path: Delivered-To: freebsd-hackers@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 93C86FDF for ; Fri, 5 Jun 2015 17:37:11 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 189791D96 for ; Fri, 5 Jun 2015 17:37:11 +0000 (UTC) (envelope-from s3erios@gmail.com) Received: by lbbqq2 with SMTP id qq2so50217508lbb.3 for ; Fri, 05 Jun 2015 10:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:to:subject:references:date:mime-version :content-transfer-encoding:from:message-id:in-reply-to:user-agent; bh=4UMBkIe8EiWAt15DHEhemDZVyV6TJtfsFvfpwmyjGfw=; b=Y7Bd5pqAhvdIZ8dUfLa1HJZ/qkrIlff2BuNwQGIavPpDJzf4zwspJVY5BUCHmSccgm VJtgDg79Ni723hCcdKgF8BmI1gsd0jncJ3+Q+SzNm0MUGGfkl8THuWTRtTqAwXjaQZ/F tP59ZuGXaA9hF0/qEyXnR7wvTayX89JiUaWMLwXkn9jbHbXpLabgDC3kANwkOLNAYnQM KDB6hfMtZ69HXaNUc25CxF2h3pGOIgdOz3yp0UjG7sN6aNHImKD/Z/2GrhO56r4BNv33 NjNN5/3MQnLwf4+Y6vSnjOzxZJJPERJi+Eh8KUJTB+vnQCg1vqi7LqJjkHaHD1lrW9dR dPcw== X-Received: by 10.112.170.167 with SMTP id an7mr4407113lbc.103.1433525829118; Fri, 05 Jun 2015 10:37:09 -0700 (PDT) Received: from localhost (host-176-37-109-22.la.net.ua. [176.37.109.22]) by mx.google.com with ESMTPSA id x9sm1918257lag.18.2015.06.05.10.37.07 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 05 Jun 2015 10:37:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "freebsd-hackers@freebsd.org" , "Sebastian Kuzminsky" Subject: Re: Bug in FreeBSD 10.1's pthread barrier implementation? References: Date: Fri, 05 Jun 2015 20:37:02 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Andriy Voskoboinyk" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.16 (FreeBSD) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 17:37:11 -0000 > I'm running in to a situation where pthread_barrier_t is not completely > initialized, and later pthread_barrier_destroy() fails. > > The attached patch (against FreeBSD 10.1) fixes the issue for me. > > -- > Sebastian Kuzminsky I think it was already fixed in 10-STABLE: https://svnweb.freebsd.org/base?view=revision&revision=278313 From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 5 17:38:23 2015 Return-Path: Delivered-To: freebsd-hackers@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 DA44E149 for ; Fri, 5 Jun 2015 17:38:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::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 6A5A71DAB for ; Fri, 5 Jun 2015 17:38:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t55HcEnS048578 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 5 Jun 2015 20:38:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t55HcEnS048578 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t55HcECY048577; Fri, 5 Jun 2015 20:38:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 5 Jun 2015 20:38:14 +0300 From: Konstantin Belousov To: Sebastian Kuzminsky Cc: "freebsd-hackers@freebsd.org" Subject: Re: Bug in FreeBSD 10.1's pthread barrier implementation? Message-ID: <20150605173814.GF2499@kib.kiev.ua> References: 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.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 17:38:23 -0000 On Fri, Jun 05, 2015 at 05:19:32PM +0000, Sebastian Kuzminsky wrote: > I'm running in to a situation where pthread_barrier_t is not completely initialized, and later pthread_barrier_destroy() fails. > > The attached patch (against FreeBSD 10.1) fixes the issue for me. This was already fixed by r278313/head and r278668/stable/10. From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 5 17:38:49 2015 Return-Path: Delivered-To: freebsd-hackers@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 1979322C for ; Fri, 5 Jun 2015 17:38:49 +0000 (UTC) (envelope-from S.Kuzminsky@f5.com) Received: from mail.f5.com (mail.f5.com [208.85.209.139]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.f5.com", Issuer "Entrust Certification Authority - L1C" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DEC4E1DB5 for ; Fri, 5 Jun 2015 17:38:48 +0000 (UTC) (envelope-from S.Kuzminsky@f5.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=f5.com; i=@f5.com; q=dns/txt; s=seattle; t=1433525928; x=1465061928; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CIwizfgDhAh+dK+yH5DXoj4zbrABUgboKO9weWpja1c=; b=Qw1OrTtvGIOa/IXsQTPCU9e2fxZzGf6nU/lt6qeGIZ6RL8KfjbU61Sr2 Ahms7ILrMo8EEe+tQQO1lI8NUtTbRBbjQ16KpzZwHkZIwTN8h1Q6Wdl8z ThPcDiToZcyq6oY3i/vVgHt+7RxzVVHYaLnI+KaZ1W2yj2wDTB2Q66Pw9 o=; X-IronPort-AV: E=Sophos;i="5.13,560,1427760000"; d="scan'208";a="165182843" X-IPAS-Result: A2C6BACh3XFV/+sKqMBbg2RSDAbAR4V3AoF/AQEBAQEBgQuEIwEBAwE6TwIBCA4oECERJQIEARKIGAMKFdZnDYUfAQEBAQEFAQEBAQEBAQEWBItDgk2CQIQtBZdehQmSK4cJhBtvgUaBAQEBAQ Received: from oracle-apps.f5net.com (HELO exchmail.f5net.com) ([192.168.10.235]) by mail.f5.com with ESMTP/TLS/AES256-SHA; 05 Jun 2015 17:38:48 +0000 Received: from SEAEXCHMBX01.olympus.F5Net.com (192.168.15.223) by seaexchmbx01.olympus.F5Net.com (192.168.15.223) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Fri, 5 Jun 2015 10:38:48 -0700 Received: from SEAEXCHMBX01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75]) by seaexchmbx01.olympus.F5Net.com ([fe80::143c:7597:6ad7:ce75%13]) with mapi id 15.00.1044.021; Fri, 5 Jun 2015 10:38:48 -0700 From: Sebastian Kuzminsky To: Andriy Voskoboinyk , "freebsd-hackers@freebsd.org" , Sebastian Kuzminsky Subject: Re: Bug in FreeBSD 10.1's pthread barrier implementation? Thread-Topic: Bug in FreeBSD 10.1's pthread barrier implementation? Thread-Index: AQHQn7PJC5hZrU3GxUi463RFdcLO+Z2eomcA//+b6IA= Date: Fri, 5 Jun 2015 17:38:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.15.239] Content-Type: text/plain; charset="us-ascii" Content-ID: <52572F81F4EB374D84B85AC0C14DCFDE@F5.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 17:38:49 -0000 On 6/5/15, 11:37 AM, "Andriy Voskoboinyk" wrote: >> I'm running in to a situation where pthread_barrier_t is not completely >>=20 >> initialized, and later pthread_barrier_destroy() fails. >> >> The attached patch (against FreeBSD 10.1) fixes the issue for me. >> >> -- >> Sebastian Kuzminsky > >I think it was already fixed in 10-STABLE: >https://svnweb.freebsd.org/base?view=3Drevision&revision=3D278313 Heh, yep! I should have checked there first. --=20 Sebastian Kuzminsky From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 5 17:41:31 2015 Return-Path: Delivered-To: freebsd-hackers@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 4CC243CC; Fri, 5 Jun 2015 17:41:31 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 346591F50; Fri, 5 Jun 2015 17:41:31 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from zeta.ixsystems.com (c-71-202-112-39.hsd1.ca.comcast.net [71.202.112.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 42B0E18246; Fri, 5 Jun 2015 10:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1433526090; x=1433540490; bh=jay0aVqMgKjpLbKbPachYNlkxb3DrjMvLPVl18T6HOM=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=Z501GS+I6ws5+p9K+GdMTD8C42GUn1UBiL1u7Rr5yH1JJZx23DIC/rWgA9ymFgL4W bAWL04yCBp774oevV+RbhwdNuJB8uCAfvxj2mAfCZwa3I1Y8U9kTi9d4CDn9hmoXgd /L4/nq7d43rBQU2330ajmB8pHsgECpiG9mqAWPQo= Message-ID: <5571DF49.4080703@delphij.net> Date: Fri, 05 Jun 2015 10:41:29 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Sebastian Kuzminsky , Andriy Voskoboinyk , "freebsd-hackers@freebsd.org" CC: Konstantin Belousov Subject: Re: Bug in FreeBSD 10.1's pthread barrier implementation? References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2015 17:41:31 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/05/15 10:38, Sebastian Kuzminsky wrote: > On 6/5/15, 11:37 AM, "Andriy Voskoboinyk" > wrote: > > >>> I'm running in to a situation where pthread_barrier_t is not >>> completely >>> >>> initialized, and later pthread_barrier_destroy() fails. >>> >>> The attached patch (against FreeBSD 10.1) fixes the issue for >>> me. >>> >>> -- Sebastian Kuzminsky >> >> I think it was already fixed in 10-STABLE: >> https://svnweb.freebsd.org/base?view=revision&revision=278313 > > Heh, yep! I should have checked there first. What's the application? If this have broad impact, perhaps we should issue an EN for it? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.4 (FreeBSD) iQIcBAEBCgAGBQJVcd9JAAoJEJW2GBstM+nstZUP/3a71ChXEqT/e/cjBaDHQTgm /+z34uqhn/F1uK3f9pxwlpABcylOUvIf282Ho66NeUHJX123QROPXaoRAQphsdvF kMDeULBrmTm4sp62nKSVPROrIeqgS18nISdQUcNGu2uaOVe+iSc+LVd5MbuNg2Fb Nsdd55hfd1pI1qYg2/bRgT/j3hVEoWQxvncsGtRG2CJrJYJui3VKzApufSdlRvxn xONgVpjUEiIv++bed5awvhvHMtwt2zTFkumEHrAcz2+i2TVk3PL4QyZYrEn1q1oa E2mLf1g1kbVsih/kfaTYVp/b76Ncy+ncV/gBja5/Xb4biio2X1jQmfZQjAXKO2s2 A0InVqIt+4HE57IgcQ1amhdqZ478dWCN3DNBazJ2OZ24AXCqrfKyom67ZyAmNTVw nXrd/1Db2tFyCQOirrTqHL8xM5sQeuOlHNhGEyMwllfS+buiyuxv9P0X2NJGlMbJ lWkMfMGiCVdkonKvCbfnT/SJRa53bqaWLnJCF+L/sSeceRM60GUjFm9rabEECnII C6FWghDhmG903TFJoKs3XmZidWKAvXLEkSEnGXC7z8wKo9FueIEAaNCWnENdyoas RShInbMgCBy7LIchKXayDsLGAkoDXTr74zk7AzidrQeDVIcmiVtBIYC/XY58KBj5 YS2ulz7YW8yjuzwF5u5c =eC0+ -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 6 19:11:54 2015 Return-Path: Delivered-To: freebsd-hackers@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 110B5F83; Sat, 6 Jun 2015 19:11:54 +0000 (UTC) (envelope-from hps@selasky.org) 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 C25F41CA0; Sat, 6 Jun 2015 19:11:49 +0000 (UTC) (envelope-from hps@selasky.org) 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 50FD91FE023; Sat, 6 Jun 2015 21:11:47 +0200 (CEST) Message-ID: <55734622.5090808@selasky.org> Date: Sat, 06 Jun 2015 21:12:34 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Julian Elischer , Ian Lepore , Poul-Henning Kamp CC: "freebsd-hackers@freebsd.org" Subject: Re: Make "sys/queue.h" usable with C++ References: <52D7D302.3090403@bitfrost.no> <1679.1389879981@critter.freebsd.dk> <52D7E674.4010501@bitfrost.no> <16417.1389881910@critter.freebsd.dk> <1389890913.1230.64.camel@revolution.hippie.lan> <52D8C268.1080009@bitfrost.no> <52D95A8E.3000006@freebsd.org> In-Reply-To: <52D95A8E.3000006@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 19:11:54 -0000 Hi, I've come up with a smarter way to do it, which I think is more acceptable. Simply we need to duplicate the ENTRY and HEAD macros for use with classes. Then use __typeof() where pointers are referred inside these macros. That's it. Can you checkout: https://reviews.freebsd.org/D2745 And give some comments? --HPS