From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 10:40: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 4782781B for ; Sun, 18 Jan 2015 10:40:04 +0000 (UTC) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::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 CCFD9970 for ; Sun, 18 Jan 2015 10:40:03 +0000 (UTC) Received: by mail-wg0-f51.google.com with SMTP id l18so5122141wgh.10 for ; Sun, 18 Jan 2015 02:40:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to :mime-version:content-type:content-disposition:user-agent; bh=36wJE9dLTfF7vJzgKWxxSalXTSOA5az07ZNUc6pDSvg=; b=lXAsdKNro0RZnW554asVNs/s6GPPd/5MxIkdMcKhDC4wSN6zz6EyrH65Pf36X8T38q Rtlb5kcSPOGFcW5DOMmkQ+fN8mJcyFWI7JO2LFoagA6ejb4G8bhSVp6zAyVCq6FU3ppL E1m1+CyOinvImgoDoOAAkyV/PqU+vwV6QD7hH9sxjmDM6BMcjAM+CZLAwDaRaILl9d3v rOwu8S4oO4fgt5Nw+ivYr4AjV4bgHvrthzkW2nhXoBI1nzqs++dK9Ms79ImZ4Qfsedcf nFnDS7GcS8FZBvbUoiZT3VG6asL3fcJhmATHqx+W+fzXT+tlTLCGdvj/Bm7K/WqkV62n nEdA== X-Received: by 10.180.104.9 with SMTP id ga9mr24315633wib.9.1421577602232; Sun, 18 Jan 2015 02:40:02 -0800 (PST) Received: from brick.home (adcv250.neoplus.adsl.tpnet.pl. [79.184.47.250]) by mx.google.com with ESMTPSA id pl1sm9840151wic.16.2015.01.18.02.40.01 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Jan 2015 02:40:01 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sun, 18 Jan 2015 11:39:59 +0100 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: arch@FreeBSD.org Subject: Access times on directories. Message-ID: <20150118103959.GA54396@brick.home> Mail-Followup-To: arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) 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, 18 Jan 2015 10:40:04 -0000 What is FreeBSD semantics for atime updates on directories? It does not seem to be working. Is that by design? The reason I'm asking is because it would allow autounmountd(8) to actually unmount filesystems some specified time after last use, by checking atime of filesystem's root, instead of just retrying unmount(2) until it succeeds. From owner-freebsd-arch@FreeBSD.ORG Sun Jan 18 11:55:18 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 D74D29B7; Sun, 18 Jan 2015 11:55:18 +0000 (UTC) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 99032FF2; Sun, 18 Jan 2015 11:55:18 +0000 (UTC) Received: from c122-106-147-133.carlnfd1.nsw.optusnet.com.au (c122-106-147-133.carlnfd1.nsw.optusnet.com.au [122.106.147.133]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 14C5D3C2CCE; Sun, 18 Jan 2015 22:55:09 +1100 (AEDT) Date: Sun, 18 Jan 2015 22:55:07 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= Subject: Re: Access times on directories. In-Reply-To: <20150118103959.GA54396@brick.home> Message-ID: <20150118221955.F60362@besplex.bde.org> References: <20150118103959.GA54396@brick.home> MIME-Version: 1.0 X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=R8o6R7hX c=1 sm=1 tr=0 a=7NqvjVvQucbO2RlWB8PEog==:117 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=nlC_4_pT8q9DhB4Ho9EA:9 a=cz2ZRIgtxKwA:10 a=wJWlkF7cXJYA:10 a=c3-DdYJoA5YA:10 a=dpdNnUpAj_AEh-B5uZ4A:9 a=45ClL6m2LaAA:10 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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: Sun, 18 Jan 2015 11:55:18 -0000 On Sun, 18 Jan 2015, Edward Tomasz [utf-8] Napiera=C5~Ba wrote: > What is FreeBSD semantics for atime updates on directories? It does not > seem to be working. Is that by design? read(2) marks the atime for update in the usual way for directories on most or all file systems that support read(2) on directories. That is about the only time atimes are marked on directories. However, read(2) is rarely used for reading directories. Most directory reads are probably done by readdir(2), and it uses getdirentries(2). POSIX requires readdir() to mark the atime for update if an (uncached) directory entry is actually read. This seems to be quite broken. There is no code in either readdir() or getdirentries to waste time marking the atime. I think directory searches for the purpose of creating a new entry also don't update the atime, but this is not required by POSIX. > The reason I'm asking is because it would allow autounmountd(8) to actual= ly > unmount filesystems some specified time after last use, by checking atime > of filesystem's root, instead of just retrying unmount(2) until it succee= ds. That wouldn't be a robust test. It would be guaranteed to not work for the r/o mount case. I would like file systems to do this. Actually, to automatically sync everything and mark the file system as clean if there have been no writes to it for some time. ffs should do this per cylinder group (not so easy) in such a way that only the unclean cg's need to be fscked. atime updates would get in the way of this. A file system with atime updates enabled would rarely remain unwritten to for sufficiently long to be marked as clean unless it is not used at all. Bruce From owner-freebsd-arch@FreeBSD.ORG Mon Jan 19 11:03:59 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 7E5FBB12; Mon, 19 Jan 2015 11:03:59 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (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 1A17AA76; Mon, 19 Jan 2015 11:03:59 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id l15so6365113wiw.4; Mon, 19 Jan 2015 03:03:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:mime-version:date:content-type:content-transfer-encoding :message-id:from:subject:to:cc:in-reply-to:references; bh=yooY94k7QoYhMmn8x05hn+sUbWy29tVUWma37teju7c=; b=UgXN93o1W2rBVbv7DFYQdFYfiuY3RFFfcecGP2nAtUlqdKB9fZHircRCWuMupel5dj Ww4KbEyKp/DeiKzEyVuKLCD2csbIff/dUqRnDO6EYYPhTl3dTogaF87TF/NyJYbGKlqi ofTaUBZ4PSjG9ExlqNoOVT1Qnac2lVlPGrSL2I81Nf/zzx+J6qDI/6cTuWARtOelxpLs U9nVWK4sCFw2/CwdAXC4o2vN2nMLY8AaE1U7DozbPBxwlEBGv6LrQ9Tt3l3d/ieY9yUk oBHcnT9Yeuev3Sv5Vs6RG9PVmj8VOjhjX4SykcpCNTyDeVb/4P+yieCu0sDxlitaKxIJ RHTQ== X-Received: by 10.180.74.146 with SMTP id t18mr33626803wiv.62.1421665437420; Mon, 19 Jan 2015 03:03:57 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id n3sm13768365wiw.5.2015.01.19.03.03.56 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 03:03:56 -0800 (PST) Sender: Baptiste Daroussin Received: from mail.etoilebsd.net (localhost [IPv6:::1]); by ivaldir.etoilebsd.net (OpenSMTPD) with ESMTP id 8c06d551; Mon, 19 Jan 2015 12:03:55 +0100 (CET) Mime-Version: 1.0 Date: Mon, 19 Jan 2015 11:03:55 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <23213143eab742c5b090a07817240a72@mail.etoilebsd.net> X-Mailer: RainLoop/1.7.2.220 From: "Baptiste Daroussin" Subject: Re: futimens/utimensat (was: Re: Change default VFS timestamp precision?) To: "Jilles Tjoelker" , "Garrett Wollman" In-Reply-To: <20150103161306.GB46373@stack.nl> References: <20150103161306.GB46373@stack.nl> <201412161348.41219.jhb@freebsd.org> <77322.1418933100@critter.freebsd.dk> <77371.1418933642@critter.freebsd.dk> <7567696.mqJ3jgzJgL@ralph.baldwin.cx> <82135.1419010861@critter.freebsd.dk> <20141219194800.GA29107@stack.nl> <201412192012.sBJKC1rW086109@hergotha.csail.mit.edu> Cc: portmgr@freebsd.org, pluknet@freebsd.org, 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, 19 Jan 2015 11:03:59 -0000 January 3 2015 5:13 PM, "Jilles Tjoelker" wrote: =0A> O= n Fri, Dec 19, 2014 at 03:12:01PM -0500, Garrett Wollman wrote:=0A> =0A>>= In article <20141219194800.GA29107@stack.nl>, jilles@stack.nl writes:=0A= >> =0A>>> Because there is no API to set timestamps with nanosecond resol= ution,=0A>>> and therefore a cp -p copy of a file will appear older than = the original=0A>>> with 99.9% probability. I think that is undesirable.= =0A>> =0A>> But that's something we can easily fix -- and should have don= e, years=0A>> ago. Why don't we just *do* that?=0A>> =0A>> Of course, in = the case of NFS clients, where this issue is most=0A>> severe, the RPCs a= re already defined. The underlying VOP_SETATTR has=0A>> no trouble with n= anoseconds, either. It's just a matter of providing=0A>> a standard libra= ry interface (and associated system call(s)) to do it,=0A>> and since Lin= ux has already implemented this, we can just implement=0A>> that interfac= e and applications will get it "for free".=0A> =0A> OK, I dusted off the = old patch from pluknet@ and added many necessary=0A> things.=0A> =0A> Ple= ase review at https://reviews.freebsd.org/D1426=0A> =0A> I added a compat= ibility wrapper, mainly to save portmgr some work. Of=0A> course, this do= es not add to the old kernel a version of lutimes() that=0A> works relati= ve to a file descriptor.=0A> =0A> I also have changes for cp, mv and more= utilities, but that's a=0A> different patch. There is also contrib code = that either only supports=0A> old calls or is explicitly configured to us= e only old calls.=0A> =0A=0AWhen you have the final version of the patch = and willing to commit please send portmgr a heads up.=0AFYI committing Th= ursday such patches is a good idea as it gives portmgr almost a week to u= pgrade the builders :)=0A=0ABest regards,=0ABapt From owner-freebsd-arch@FreeBSD.ORG Mon Jan 19 14:13:19 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 DB29B512; Mon, 19 Jan 2015 14:13:19 +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 90864240; Mon, 19 Jan 2015 14:13:19 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YDD4u-000Ea7-MA; Mon, 19 Jan 2015 17:13:16 +0300 Date: Mon, 19 Jan 2015 17:13:16 +0300 From: Slawa Olhovchenkov To: Baptiste Daroussin Subject: Re: futimens/utimensat (was: Re: Change default VFS timestamp precision?) Message-ID: <20150119141316.GA98162@zxy.spb.ru> References: <20150103161306.GB46373@stack.nl> <201412161348.41219.jhb@freebsd.org> <77322.1418933100@critter.freebsd.dk> <77371.1418933642@critter.freebsd.dk> <7567696.mqJ3jgzJgL@ralph.baldwin.cx> <82135.1419010861@critter.freebsd.dk> <20141219194800.GA29107@stack.nl> <201412192012.sBJKC1rW086109@hergotha.csail.mit.edu> <23213143eab742c5b090a07817240a72@mail.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23213143eab742c5b090a07817240a72@mail.etoilebsd.net> 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: freebsd-arch@freebsd.org, pluknet@freebsd.org, Garrett Wollman , Jilles Tjoelker , portmgr@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, 19 Jan 2015 14:13:20 -0000 On Mon, Jan 19, 2015 at 11:03:55AM +0000, Baptiste Daroussin wrote: > > When you have the final version of the patch and willing to commit please send portmgr a heads up. > FYI committing Thursday such patches is a good idea as it gives portmgr almost a week to upgrade the builders :) Do portmgr upgrade the builders on base security updates? Some software have strict depends on openssl version and can't be installed after freebsd-update From owner-freebsd-arch@FreeBSD.ORG Mon Jan 19 14:26:22 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 79FEA7BA; Mon, 19 Jan 2015 14:26:22 +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 034E2372; Mon, 19 Jan 2015 14:26:22 +0000 (UTC) Received: by mail-wg0-f43.google.com with SMTP id k14so32035429wgh.2; Mon, 19 Jan 2015 06:26:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:mime-version:date:content-type:content-transfer-encoding :message-id:from:subject:to:cc:in-reply-to:references; bh=7CcNXpV5ZRQVV/YPPipkGHzdUSX1M57qySowHh0Qz/g=; b=q+Gj6Y7TI23hTMY+9+RS8inhpKPx9i3DnsoyDbxd51hcbMyewSukxT7ci3CgRW6r5O fHT/c4P0a0hPBU68R+9kWRGO+WPqnSqUKFzpGwJBBbQL2I3cG7Lx20snegAk9N76Ot7C 0Z6sl253AE6g4erPGZSyfktXmVntXTD1E7uCkSeXr3AU1+YsezzIY8w+9IIEK49GM0EK +BGviVCEsoDctznwg7zMzP17kZ1kC4NbvbnhokhspfZj/Zd8smuKO5fV4mUUwGSQJrF7 U85NvLaQgLjYmrLnqg9alqN5bSRQxEnGeuJOG+3YdXS+y4BqRjKmxlOQ9p9oWMSjMfR2 gDjA== X-Received: by 10.180.103.231 with SMTP id fz7mr34111825wib.49.1421677578741; Mon, 19 Jan 2015 06:26:18 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id cs8sm14424001wib.1.2015.01.19.06.26.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Jan 2015 06:26:18 -0800 (PST) Sender: Baptiste Daroussin Received: from mail.etoilebsd.net (localhost [IPv6:::1]); by ivaldir.etoilebsd.net (OpenSMTPD) with ESMTP id da0f2fca; Mon, 19 Jan 2015 15:26:16 +0100 (CET) Mime-Version: 1.0 Date: Mon, 19 Jan 2015 14:26:16 +0000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-ID: <124280e55dfd675140e86111d0ea9db7@mail.etoilebsd.net> X-Mailer: RainLoop/1.7.2.220 From: "Baptiste Daroussin" Subject: Re: futimens/utimensat (was: Re: Change default VFS timestamp precision?) To: "Slawa Olhovchenkov" In-Reply-To: <20150119141316.GA98162@zxy.spb.ru> References: <20150119141316.GA98162@zxy.spb.ru> <20150103161306.GB46373@stack.nl> <201412161348.41219.jhb@freebsd.org> <77322.1418933100@critter.freebsd.dk> <77371.1418933642@critter.freebsd.dk> <7567696.mqJ3jgzJgL@ralph.baldwin.cx> <82135.1419010861@critter.freebsd.dk> <20141219194800.GA29107@stack.nl> <201412192012.sBJKC1rW086109@hergotha.csail.mit.edu> <23213143eab742c5b090a07817240a72@mail.etoilebsd.net> Cc: freebsd-arch@freebsd.org, pluknet@freebsd.org, Garrett Wollman , Jilles Tjoelker , portmgr@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, 19 Jan 2015 14:26:22 -0000 January 19 2015 3:13 PM, "Slawa Olhovchenkov" wrote: =0A= > On Mon, Jan 19, 2015 at 11:03:55AM +0000, Baptiste Daroussin wrote:=0A>= =0A>> When you have the final version of the patch and willing to commit= please send portmgr a heads=0A> up.=0A>> FYI committing Thursday such pa= tches is a good idea as it gives portmgr almost a week to upgrade=0A>> th= e builders :)=0A> =0A> Do portmgr upgrade the builders on base security u= pdates?=0A> Some software have strict depends on openssl version and can'= t be=0A> installed after freebsd-update=0A=0AYes we do=0ABapt From owner-freebsd-arch@FreeBSD.ORG Tue Jan 20 07:28:59 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 47BAE2D9; Tue, 20 Jan 2015 07:28:59 +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 F21DBE6; Tue, 20 Jan 2015 07:28:58 +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 4F3A11FE023; Tue, 20 Jan 2015 08:28:56 +0100 (CET) Message-ID: <54BE03EB.2070604@selasky.org> Date: Tue, 20 Jan 2015 08:29: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: Jason Wolfe , John Baldwin 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> <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <54BADFB3.3030405@selasky.org> In-Reply-To: <54BADFB3.3030405@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , FreeBSD Current , Sean Bruno , "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, 20 Jan 2015 07:28:59 -0000 On 01/17/15 23:18, Hans Petter Selasky wrote: > On 01/17/15 20:11, Jason Wolfe wrote: >> >> HPS, >> >> Just to give a quick status update, this patch has most certainly >> resolved our spin lock held too long panics on stable/10. >> >> Thank you to JHB for spending some time digging into the issue and >> leading us to td_slpcallout as the culprit, and HPS for your rewrite. >> I had heard rumors of other being affected by similar issues, so this >> seems like a fine candidate for an MFC if possible. >> >> Jason >> > > Hi Jason, > > I'm glad to hear that my patch has resolved your issue and I'm happy we > now have a more stable system. > > It was actually a co-worker at work which wrote some bad code which I > started debugging which then lead me to look at the callout subsystem. > One bug kills the other ;-) > > I'm planning a MFC to 10-stable - yes, and will possibly add the > _callout_stop_safe() function to not break binary compatibility with > existing drivers as part of the MFC. > > --HPS Hi, Here is a followup patch for the TCP stack like I mentioned in the beginning of the work done on the callout subsystem: https://reviews.freebsd.org/D1563 If someone has a setup for massive TCP testing please give it a spin. Thank you! --HPS From owner-freebsd-arch@FreeBSD.ORG Tue Jan 20 10:47:47 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 0CB9811F; Tue, 20 Jan 2015 10:47:47 +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 B4EFAA7E; Tue, 20 Jan 2015 10:47:46 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YDWLQ-000CZz-VR; Tue, 20 Jan 2015 13:47:36 +0300 Date: Tue, 20 Jan 2015 13:47:36 +0300 From: Slawa Olhovchenkov To: Hans Petter Selasky Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress Message-ID: <20150120104736.GA78629@zxy.spb.ru> References: <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <54BADFB3.3030405@selasky.org> <54BE03EB.2070604@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54BE03EB.2070604@selasky.org> 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: Adrian Chadd , FreeBSD Current , Jason Wolfe , "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, 20 Jan 2015 10:47:47 -0000 On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote: > On 01/17/15 23:18, Hans Petter Selasky wrote: > > On 01/17/15 20:11, Jason Wolfe wrote: > >> > >> HPS, > >> > >> Just to give a quick status update, this patch has most certainly > >> resolved our spin lock held too long panics on stable/10. > >> > >> Thank you to JHB for spending some time digging into the issue and > >> leading us to td_slpcallout as the culprit, and HPS for your rewrite. > >> I had heard rumors of other being affected by similar issues, so this > >> seems like a fine candidate for an MFC if possible. > >> > >> Jason > >> > > > > Hi Jason, > > > > I'm glad to hear that my patch has resolved your issue and I'm happy we > > now have a more stable system. > > > > It was actually a co-worker at work which wrote some bad code which I > > started debugging which then lead me to look at the callout subsystem. > > One bug kills the other ;-) > > > > I'm planning a MFC to 10-stable - yes, and will possibly add the > > _callout_stop_safe() function to not break binary compatibility with > > existing drivers as part of the MFC. > > > > --HPS > > Hi, > > Here is a followup patch for the TCP stack like I mentioned in the > beginning of the work done on the callout subsystem: > > https://reviews.freebsd.org/D1563 > > If someone has a setup for massive TCP testing please give it a spin. I have on 10.1 (with applied r261906). From owner-freebsd-arch@FreeBSD.ORG Tue Jan 20 19:02:43 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 DDAE95CB; Tue, 20 Jan 2015 19:02:43 +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 B81FCBCC; Tue, 20 Jan 2015 19:02:43 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B49C0B97F; Tue, 20 Jan 2015 14:02:42 -0500 (EST) From: John Baldwin To: freebsd-arch@freebsd.org Subject: Re: Access times on directories. Date: Tue, 20 Jan 2015 10:47:54 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20150118103959.GA54396@brick.home> <20150118221955.F60362@besplex.bde.org> In-Reply-To: <20150118221955.F60362@besplex.bde.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Message-Id: <201501201047.54379.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Jan 2015 14:02:42 -0500 (EST) Cc: Edward Tomasz =?utf-8?q?Napiera=C5=82a?= 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, 20 Jan 2015 19:02:44 -0000 On Sunday, January 18, 2015 6:55:07 am Bruce Evans wrote: > On Sun, 18 Jan 2015, Edward Tomasz [utf-8] Napiera=C5~Ba wrote: >=20 > > What is FreeBSD semantics for atime updates on directories? It does not > > seem to be working. Is that by design? >=20 > read(2) marks the atime for update in the usual way for directories > on most or all file systems that support read(2) on directories. That > is about the only time atimes are marked on directories. However, > read(2) is rarely used for reading directories. Most directory reads > are probably done by readdir(2), and it uses getdirentries(2). POSIX > requires readdir() to mark the atime for update if an (uncached) > directory entry is actually read. This seems to be quite broken. > There is no code in either readdir() or getdirentries to waste time > marking the atime. I think directory searches for the purpose of > creating a new entry also don't update the atime, but this is not > required by POSIX. Also, I suspect that lookups would not trigger an atime update even if you = fix=20 getdirentries (and of course that ignores the read-only mount case that Bru= ce=20 already mentioned). =2D-=20 John Baldwin From owner-freebsd-arch@FreeBSD.ORG Tue Jan 20 22:03:32 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 85BCE96F; Tue, 20 Jan 2015 22:03:32 +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 3967F280; Tue, 20 Jan 2015 22:03:32 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.84 (FreeBSD)) (envelope-from ) id 1YDgtT-000Oe0-Sw; Wed, 21 Jan 2015 01:03:27 +0300 Date: Wed, 21 Jan 2015 01:03:27 +0300 From: Slawa Olhovchenkov To: Baptiste Daroussin Subject: Re: futimens/utimensat (was: Re: Change default VFS timestamp precision?) Message-ID: <20150120220327.GA88631@zxy.spb.ru> References: <20150103161306.GB46373@stack.nl> <201412161348.41219.jhb@freebsd.org> <77322.1418933100@critter.freebsd.dk> <77371.1418933642@critter.freebsd.dk> <7567696.mqJ3jgzJgL@ralph.baldwin.cx> <82135.1419010861@critter.freebsd.dk> <20141219194800.GA29107@stack.nl> <201412192012.sBJKC1rW086109@hergotha.csail.mit.edu> <23213143eab742c5b090a07817240a72@mail.etoilebsd.net> <124280e55dfd675140e86111d0ea9db7@mail.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <124280e55dfd675140e86111d0ea9db7@mail.etoilebsd.net> 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: portmgr@freebsd.org, pluknet@freebsd.org, Garrett Wollman , Jilles Tjoelker , 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, 20 Jan 2015 22:03:32 -0000 On Mon, Jan 19, 2015 at 02:26:16PM +0000, Baptiste Daroussin wrote: > January 19 2015 3:13 PM, "Slawa Olhovchenkov" wrote: > > On Mon, Jan 19, 2015 at 11:03:55AM +0000, Baptiste Daroussin wrote: > > > >> When you have the final version of the patch and willing to commit please send portmgr a heads > > up. > >> FYI committing Thursday such patches is a good idea as it gives portmgr almost a week to upgrade > >> the builders :) > > > > Do portmgr upgrade the builders on base security updates? > > Some software have strict depends on openssl version and can't be > > installed after freebsd-update > > Yes we do And force rebuild freeradius, for example? From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 16:30:06 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 19D8D5EE for ; Wed, 21 Jan 2015 16:30:06 +0000 (UTC) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::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 D79AF992 for ; Wed, 21 Jan 2015 16:30:05 +0000 (UTC) Received: by mail-ie0-f173.google.com with SMTP id tr6so13023464ieb.4 for ; Wed, 21 Jan 2015 08:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=FyujZa/dgrJIxB5+yKuaKE/5/gahf//olhhFsvlfZz0=; b=x7Jek/b3hOUF06QdyFw3+7FFiqj96G3++NxpXV98/zsWpv5AJhwwKwtudTCxMxCute KcDJ1FkBA6Ckzs46sthuuul4Dma2Jjb7j+d6kG4OZx0JySo8Fv5a31xOTYHNvplUoKk1 t6uZaE4rANMT6nGIQGsg+T1pW836KhLVZBP8eiWIyq5L0Bm8mWt3tUSrJsQx0pSuOgT0 5rB1sqNBFHCXUF095codOmNCBfszXlPrz2CKKxFA8ZdbL9y5m+K2y0KMts+hnEj/a0X4 zRlDk7bMELYagFKxz0xTzJ4DOzyIzQzlsoOc/a5dCrMxojjcAAogyA4JkDbv5VCw7oys 5SRg== MIME-Version: 1.0 X-Received: by 10.50.66.171 with SMTP id g11mr5407902igt.49.1421857805238; Wed, 21 Jan 2015 08:30:05 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Wed, 21 Jan 2015 08:30:05 -0800 (PST) Date: Wed, 21 Jan 2015 08:30:05 -0800 X-Google-Sender-Auth: -7K8RtXULG4UOLoG21AkhA-5wJg Message-ID: Subject: please test: i386 bootloader changes From: Adrian Chadd To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 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, 21 Jan 2015 16:30:06 -0000 Hi, Here's something that I've been poking for a little while. The SeaBIOS emulation in the Chromebook C720 implements the E820 memory map by putting a hole between 15 and 16MiB. That's some really legacy PC-AT stuff right there. Unfortunately that stops kernel.GENERIC from loading as loader thinks there's only < 14MiB of extended RAM available. This patch: https://people.freebsd.org/~adrian/c720/20150121-seabios-loader-changes-2.diff updates it so if the first extended segment from the E820 call is too small, it tries the E801 call. It also fixes a bug in the E801 call that would treat the lower and upper memory regions returned as contiguous when they may indeed not be. Now - here be dragons. It's possible that fixing this stuff for one buggy bios makes freebsd's loader unhappy on other buggy bioses. So I'd really appreciate if it people would try this out on 32/64 bit x86 platforms and report back success/failures. So far nothing I have here complains, but I don't have /that/ much hardware. Thanks, -adrian From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 16:37:42 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 539229BF; Wed, 21 Jan 2015 16:37:42 +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 12858AA0; Wed, 21 Jan 2015 16:37:41 +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 56A3D1FE023; Wed, 21 Jan 2015 17:37:39 +0100 (CET) Message-ID: <54BFD605.7090603@selasky.org> Date: Wed, 21 Jan 2015 17:38:29 +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 , "freebsd-arch@freebsd.org" Subject: Re: please test: i386 bootloader changes References: In-Reply-To: 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: Wed, 21 Jan 2015 16:37:42 -0000 On 01/21/15 17:30, Adrian Chadd wrote: > Hi, > > Here's something that I've been poking for a little while. > > The SeaBIOS emulation in the Chromebook C720 implements the E820 > memory map by putting a hole between 15 and 16MiB. That's some really > legacy PC-AT stuff right there. Unfortunately that stops > kernel.GENERIC from loading as loader thinks there's only < 14MiB of > extended RAM available. > > This patch: > > https://people.freebsd.org/~adrian/c720/20150121-seabios-loader-changes-2.diff > > updates it so if the first extended segment from the E820 call is too > small, it tries the E801 call. It also fixes a bug in the E801 call > that would treat the lower and upper memory regions returned as > contiguous when they may indeed not be. > > Now - here be dragons. It's possible that fixing this stuff for one > buggy bios makes freebsd's loader unhappy on other buggy bioses. So > I'd really appreciate if it people would try this out on 32/64 bit x86 > platforms and report back success/failures. So far nothing I have here > complains, but I don't have /that/ much hardware. > > Thanks, > Hi, What is the simplest way to install the loader changes? Can it be tested by replacing "/boot/loader" or do I need to update any boot partition code using "gpart bootcode" ? --HPS From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 17:29:00 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 A0AA7B67 for ; Wed, 21 Jan 2015 17:29:00 +0000 (UTC) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 66E90E2 for ; Wed, 21 Jan 2015 17:29:00 +0000 (UTC) Received: by mail-ig0-f180.google.com with SMTP id b16so16149255igk.1 for ; Wed, 21 Jan 2015 09:28:59 -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=VWOsDORBrUUiYgvMAVKg1UWoKGXcehmfrIxuxfK8PfY=; b=eGv22e1hbYVJrLmUbnh4kBxHFyBl7AyWLFzYUcItQTeVlpk4BuWT7ubFrKZxYgoMdK QQODGMRSRfRFTuxYOrwbgVW7EhkorBn+Bt6zUTrkPc/9i2WG0efQ37+4b+xwCREHvYss N++tN30I12N4cE4DJ4Gijg0jOppr9vPPQEbqDo7smK3FZ2RfHK211Uzl1MIzDxmkGFGm TnzwxvjJN7tp7AgUfLSN62k3vWPR1I5fGZDfA3XSHuhjWphZJeZ+GDXL8QuaHK1v2kd0 wzg4qH/LGLu9WilK895C5g569oa7GH82rwNtnjT9e03DJ1L1pNaZKWcmzO3xTHxWSX/q 3xRQ== MIME-Version: 1.0 X-Received: by 10.50.55.98 with SMTP id r2mr35874403igp.6.1421861339823; Wed, 21 Jan 2015 09:28:59 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Wed, 21 Jan 2015 09:28:59 -0800 (PST) In-Reply-To: <54BFD605.7090603@selasky.org> References: <54BFD605.7090603@selasky.org> Date: Wed, 21 Jan 2015 09:28:59 -0800 X-Google-Sender-Auth: 7wRPky_od939Kll-kIE4ZDJNW84 Message-ID: Subject: Re: please test: i386 bootloader changes From: Adrian Chadd To: Hans Petter Selasky 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: Wed, 21 Jan 2015 17:29:00 -0000 It's just /boot/loader. You can just copy it there or boot it manually (eg name it /boot/loader2, and have boot0->boot1 boot /boot/loader2 instead.) -adrian On 21 January 2015 at 08:38, Hans Petter Selasky wrote: > On 01/21/15 17:30, Adrian Chadd wrote: >> >> Hi, >> >> Here's something that I've been poking for a little while. >> >> The SeaBIOS emulation in the Chromebook C720 implements the E820 >> memory map by putting a hole between 15 and 16MiB. That's some really >> legacy PC-AT stuff right there. Unfortunately that stops >> kernel.GENERIC from loading as loader thinks there's only < 14MiB of >> extended RAM available. >> >> This patch: >> >> >> https://people.freebsd.org/~adrian/c720/20150121-seabios-loader-changes-2.diff >> >> updates it so if the first extended segment from the E820 call is too >> small, it tries the E801 call. It also fixes a bug in the E801 call >> that would treat the lower and upper memory regions returned as >> contiguous when they may indeed not be. >> >> Now - here be dragons. It's possible that fixing this stuff for one >> buggy bios makes freebsd's loader unhappy on other buggy bioses. So >> I'd really appreciate if it people would try this out on 32/64 bit x86 >> platforms and report back success/failures. So far nothing I have here >> complains, but I don't have /that/ much hardware. >> >> Thanks, >> > > Hi, > > What is the simplest way to install the loader changes? > > Can it be tested by replacing "/boot/loader" or do I need to update any boot > partition code using "gpart bootcode" ? > > --HPS From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 19:32:26 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 97588BBA; Wed, 21 Jan 2015 19:32:26 +0000 (UTC) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (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 777151F0; Wed, 21 Jan 2015 19:32:26 +0000 (UTC) Received: from aurora.physics.berkeley.edu (aurora.Physics.Berkeley.EDU [128.32.117.67]) (authenticated bits=0) by c.mail.sonic.net (8.14.9/8.14.9) with ESMTP id t0LJWIci009073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Jan 2015 11:32:18 -0800 Message-ID: <54BFFEC2.5070909@freebsd.org> Date: Wed, 21 Jan 2015 11:32:18 -0800 From: Nathan Whitehorn 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, FreeBSD PowerPC ML Subject: Making the powerpc64 relocatable Content-Type: multipart/mixed; boundary="------------080909080605030806020708" X-Sonic-CAuth: UmFuZG9tSVYz054BBw4mQjeHeqof58Qc36fiVZWhlStR4Ac0oi+AMHAzWjYemaEgsbjAMSr57X5a6KZmuAnlThsyNasbd8pATTMBH6/gCuU= X-Sonic-ID: C;YOgJNqSh5BGi7KnrCx1YGw== M;DLVUNqSh5BGi7KnrCx1YGw== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd 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, 21 Jan 2015 19:32:26 -0000 This is a multi-part message in MIME format. --------------080909080605030806020708 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit In order to run natively on POWER8 hardware, the 64-bit PPC kernel needs to be relocatable. Some architectures do this by executing the kernel at a fixed virtual address with varying physical addresses. For PPC64, the kernel has a 1:1 direct map and the ABI is always PIC, so it's easier just to keep the 1:1 mapping and make both the kernel physical and virtual address range float (patch attached and at http://people.freebsd.org/~nwhitehorn/ppc64-pie-kernel.diff in case it gets stripped). This is the first architecture to have a PIE kernel, however, so I'd like some feedback on the approach. The major immediate difficulty is that PIE kernels are ET_DYN ELF executables. loader, however, thinks the kernel must be ET_EXEC and that anything that is ET_DYN is a loadable module. I have a somewhat hacky workaround in the patches to loader and kmod.mk, which uses the ELF entrypoint to decide whether something is a kernel or not (setting it to zero for modules). It's the simplest approach but I'm not sure the best one. -Nathan --------------080909080605030806020708 Content-Type: text/plain; charset=us-ascii; name="ppc64-pie-kernel.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ppc64-pie-kernel.diff" SW5kZXg6IGJvb3QvY29tbW9uL2xvYWRfZWxmLmMKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gYm9vdC9j b21tb24vbG9hZF9lbGYuYwkocmV2aXNpb24gMjc3NDM4KQorKysgYm9vdC9jb21tb24vbG9h ZF9lbGYuYwkod29ya2luZyBjb3B5KQpAQCAtMTc1LDcgKzE3NSwxMSBAQAogICAgICAqIENo ZWNrIHRvIHNlZSB3aGF0IHNvcnQgb2YgbW9kdWxlIHdlIGFyZS4KICAgICAgKi8KICAgICBr ZnAgPSBmaWxlX2ZpbmRmaWxlKE5VTEwsIF9fZWxmTihrZXJuZWx0eXBlKSk7CisjaWYgZGVm aW5lZChfX3Bvd2VycGNfXykgJiYgX19FTEZfV09SRF9TSVpFID09IDY0CisgICAgaWYgKGVo ZHItPmVfdHlwZSA9PSBFVF9EWU4gJiYgZWhkci0+ZV9lbnRyeSA9PSAwKSB7CisjZWxzZQog ICAgIGlmIChlaGRyLT5lX3R5cGUgPT0gRVRfRFlOKSB7CisjZW5kaWYKIAkvKiBMb29rcyBs aWtlIGEga2xkIG1vZHVsZSAqLwogCWlmIChtdWx0aWJvb3QgIT0gMCkgewogCQlwcmludGYo ImVsZiIgX19YU1RSSU5HKF9fRUxGX1dPUkRfU0laRSkgIl9sb2FkZmlsZTogY2FuJ3QgbG9h ZCBtb2R1bGUgYXMgbXVsdGlib290XG4iKTsKQEAgLTE5NSw3ICsxOTksMTIgQEAKIAkvKiBM b29rcyBPSywgZ290IGFoZWFkICovCiAJZWYua2VybmVsID0gMDsKIAorI2lmIGRlZmluZWQo X19wb3dlcnBjX18pICYmIF9fRUxGX1dPUkRfU0laRSA9PSA2NAorICAgIH0gZWxzZSBpZiAo ZWhkci0+ZV90eXBlID09IEVUX0VYRUMgfHwKKyAgICAgIChlaGRyLT5lX3R5cGUgPT0gRVRf RFlOICYmIGVoZHItPmVfZW50cnkgIT0gMCkpIHsKKyNlbHNlCiAgICAgfSBlbHNlIGlmIChl aGRyLT5lX3R5cGUgPT0gRVRfRVhFQykgeworI2VuZGlmCiAJLyogTG9va3MgbGlrZSBhIGtl cm5lbCAqLwogCWlmIChrZnAgIT0gTlVMTCkgewogCSAgICBwcmludGYoImVsZiIgX19YU1RS SU5HKF9fRUxGX1dPUkRfU0laRSkgIl9sb2FkZmlsZToga2VybmVsIGFscmVhZHkgbG9hZGVk XG4iKTsKSW5kZXg6IGNvbmYvTWFrZWZpbGUucG93ZXJwYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBj b25mL01ha2VmaWxlLnBvd2VycGMJKHJldmlzaW9uIDI3NzQzOCkKKysrIGNvbmYvTWFrZWZp bGUucG93ZXJwYwkod29ya2luZyBjb3B5KQpAQCAtMzcsNiArMzcsMTEgQEAKIAogQ0ZMQUdT Kz0gLW1zb2Z0LWZsb2F0IC1XYSwtbWFueQogCisuaWYgJHtNQUNISU5FX0FSQ0h9ID09ICJw b3dlcnBjNjQiCitDRkxBR1MrPSAtZlBJQworTERGTEFHUys9IC1waWUKKy5lbmRpZgorCiAu aWYgIWVtcHR5KEREQl9FTkFCTEVEKQogQ0ZMQUdTKz0JLWZuby1vbWl0LWZyYW1lLXBvaW50 ZXIKIC5lbmRpZgpJbmRleDogY29uZi9rbW9kLm1rCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGNvbmYv a21vZC5tawkocmV2aXNpb24gMjc3NDM4KQorKysgY29uZi9rbW9kLm1rCSh3b3JraW5nIGNv cHkpCkBAIC0xNzksNiArMTc5LDkgQEAKIAkke09CSkNPUFl9IC0tb25seS1rZWVwLWRlYnVn ICR7RlVMTFBST0d9ICR7LlRBUkdFVH0KIC5lbmRpZgogCisjIERvbid0IGFkZCBhIGZha2Ug ZW50cnkgcG9pbnQgdG8gbW9kdWxlcworX0xERkxBR1MrPSAtZSAwCisKIC5pZiAke19fS0xE X1NIQVJFRH0gPT0geWVzCiAke0ZVTExQUk9HfTogJHtLTU9EfS5rbGQKIAkke0xEfSAtQnNo YXJlYWJsZSAke19MREZMQUdTfSAtbyAkey5UQVJHRVR9ICR7S01PRH0ua2xkCg== --------------080909080605030806020708-- From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 21:58:07 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 1BF29E5C; Wed, 21 Jan 2015 21:58:07 +0000 (UTC) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps.rulingia.com", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 488F03ED; Wed, 21 Jan 2015 21:58:05 +0000 (UTC) Received: from server.rulingia.com (c220-239-242-83.belrs5.nsw.optusnet.com.au [220.239.242.83]) by vps.rulingia.com (8.14.9/8.14.9) with ESMTP id t0LLF8JR030205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 22 Jan 2015 08:15:13 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.9/8.14.9) with ESMTP id t0LLF21G032529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 22 Jan 2015 08:15:02 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.9/8.14.9/Submit) id t0LLF0bn032528; Thu, 22 Jan 2015 08:15:00 +1100 (AEDT) (envelope-from peter) Date: Thu, 22 Jan 2015 08:15:00 +1100 From: Peter Jeremy To: Bryan Venteicher Subject: Re: [CFT] Paravirtualized KVM clock Message-ID: <20150121211500.GA32478@server.rulingia.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="x+6KMIRAuhnl3hBn" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.23 (2014-03-12) 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: Wed, 21 Jan 2015 21:58:07 -0000 --x+6KMIRAuhnl3hBn Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2015-Jan-04 11:56:14 -0600, 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. A somewhat late response but have you looked at https://github.com/blitz/freebsd/commit/cdc5f872b3e48cc0dda031fc7d6bdedc65c= 3148f I've been running this[*] on a Google Compute Engine instance for about 6 months without problems. [*] I had to patch out the test for KVM_FEATURE_CLOCKSOURCE_STABLE_BIT but I think that's a GCE issue. --=20 Peter Jeremy --x+6KMIRAuhnl3hBn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUwBbUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0EPcP/1rx8DK61b3Bz7Oiju0gbkXd OJrhFO/WVuJ6P7yRW3Feg17C2+FVMqnqPZ5XyaaQNBGnUuHuEYx4o5JM7OlrfeLW WVog+gr0Gg7th/lMPkFFy+WK7QlX/nDFLbRnkcOdiuqGIJZ4EDqYTwkmJxCWqNOv ynlq8BrKUMV2Ff2NeUFx8EnoqxYiuP48ExpLTlJcbHylRKFWkBPUOjKX97ljsO9o X1WPzGH3XmHzEVkEANlwTDqV/hYVwKxcLuyTVsmxn5K0L/XV/jn/qI7ukWfWk0VO WDFXkZUZ4WkrrP5O/5C/7j7GjvPOk0JYK9YnI7wzrh9x5BI86L5PH//1CqL/splo 9MeiS95Pm8LVqK0ggjNt+kYhail1DdCrufH8OdPcE9/rQVCEXKTsxPygz3sdW5AE ttQlikoh2rXFfyPbJlYxTTpoJx6lHhx/eBlhTVgMoX32bAYlR4h7laXJ1q2/Mb1w FtzjKRjHGso2iiFiP+NsomHWNhJRGKTT/gcQnJ33xCa6B6Asew+UpeCAVM4brGxg NWeAkL6nt3JsOBgEKiuNksp7HZituMYRpEai2fkKCcqPcHplutD8qSd93ALO8anY M0Iggid9bE/zfMDQltm6A/SdYFb0HrXEFCDzQffLbU3nwOGi+CSM2BnoV/1uZggn 9v+JtxMBJBKhL+W20HK2 =PgOy -----END PGP SIGNATURE----- --x+6KMIRAuhnl3hBn-- From owner-freebsd-arch@FreeBSD.ORG Wed Jan 21 23:25: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 7CE6457B for ; Wed, 21 Jan 2015 23:25:22 +0000 (UTC) Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com [209.85.192.171]) (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 4E68EE98 for ; Wed, 21 Jan 2015 23:25:21 +0000 (UTC) Received: by mail-pd0-f171.google.com with SMTP id fp1so31225556pdb.2 for ; Wed, 21 Jan 2015 15:25:21 -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:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=zFxEy8ZmmcBnxPTq0j36rQjnakq3gklzwRzAUV12Vzk=; b=Vd95oBt1aOUttHhtDlR0J5JigqW0QqpL8BgjIYMIhN9IfEW4JDCo5HpeuNa35dmdhg Ei6N4pCvC2qzwgyc1/H1jCzGPvTDuOJtgQskJgsKbvdNfcHcu3g68AYYm1NT0mWhjH27 xuE9WyvWr49Bhcad0OJRwrnuG0grAp23kZU53VIb3ltPJSVw9/mq1VtwzmEbUXKfNhDD BSR6s0qi+WQMemUmlH3qAthhMc+EjW1hIDrEodUDkI872xHgyQbVMD3xJM8sNgycnn40 W4l8OVtss8jlDG1tBVvrD+mZ4D25aaOzkP1Tkd5ey26kuXoYuhQN2PLr3IrAsjcSjDyg BedA== X-Gm-Message-State: ALoCoQnMikE7FhEG8VTe8iv8Ynz5en4K84XipwuC0208THLDdVUYzzOJQNtul9x+lokNJk1Zu8KN X-Received: by 10.70.133.98 with SMTP id pb2mr65321464pdb.137.1421882721201; Wed, 21 Jan 2015 15:25:21 -0800 (PST) Received: from bsdimp.corp.netflix.com ([69.53.237.72]) by mx.google.com with ESMTPSA id nh4sm4101378pdb.37.2015.01.21.15.25.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 15:25:20 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: opt file processing From: Warner Losh In-Reply-To: <20150121221520.GY1949@funkthat.com> Date: Wed, 21 Jan 2015 16:25:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <672A7C0E-D710-4BB6-999E-C62D8698B442@bsdimp.com> References: <201501150042.t0F0g7Um018059@svn.freebsd.org> <20150115132303.GA245@zxy.spb.ru> <368B22F3-5607-46F8-B8D2-13CA59E94861@bsdimp.com> <20150121221520.GY1949@funkthat.com> To: John-Mark Gurney 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, 21 Jan 2015 23:25:22 -0000 [[ Moved to arch@ ]] > On Jan 21, 2015, at 3:15 PM, John-Mark Gurney = wrote: >=20 > Adrian Chadd wrote this message on Fri, Jan 16, 2015 at 10:43 -0800: >> When I've done what you're doing, I end up having these options in my >> minimal config file so opt_xxx.h is correctly populated. That way = when >> I point SYSDIR (or whichever variable it is) at the configured kernel >> directory with the opt_xxx.h files, it all works out correctly. >>=20 >> (I still think we shouldn't be relying on "defaults", but should ship >> the opt_xxx.h files or something to derive the opt_xxx.h and makefile >> config bits so things like external module building is possible >> against a kernel. Or, we just kill all module options that change >> behaviour/ABI of things in an incompatible way.) >=20 > I have the commands that are able to stash the opt files in a kernel > section, and then be able to extract them again so that when you build > a kernel module it will use the correct options to match the kernel.. >=20 > This is most useful for things like PAE which have a big impact... I have patches in review that I need to revise that allow the modules=E2=80= =99 Makefiles to know all the opts and select to include or exclude files based on that. Warner From owner-freebsd-arch@FreeBSD.ORG Thu Jan 22 01:06: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 409D9636 for ; Thu, 22 Jan 2015 01:06:47 +0000 (UTC) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) (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 DBCC6B8F for ; Thu, 22 Jan 2015 01:06:46 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id z12so21654891lbi.7 for ; Wed, 21 Jan 2015 17:06: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=QLHUUh3vO4ncsxCsjMXuT6DjfPAQiJ0erU3SyayxbK0=; b=ezBwVGCAYGS/D8s1lSMnF4Ifv3E9E49D3bc+xGIp8tEV9V9ejvoR5VcKU4ghvo41pE jDGa+NcOwsZFVXh5DdXgoi1UWFsPpTtSDx1AVeqIAaOjMGdPXxQVhVp3juOZ7JS99bLv DI8Cc1RT1eMQMZ8RlJAgRs0ZcZEbP1GBHJ78c5nmw7O4vNRGo4YKvSxE8Ch1D/xww1F2 n64VdXStENeniVAA/mmm1srNZK7Mh+2tLVy9wLs+9NmNcPr8CkvwBDPVkjLR5amain7S m/XhS/Eq7zmceUrBixm2kjplT/MnA48om0p7Z3SVRzqlrp9N/IUJlS8dD1lctxqi3R85 WUsg== X-Gm-Message-State: ALoCoQkxAeLToFxFw9q6FVsfghFTFu1vt1B2fQB1GBCvPqjGLKpP539auEuCqVw6RaH+68hVhUG9 X-Received: by 10.152.3.195 with SMTP id e3mr47529350lae.8.1421888804255; Wed, 21 Jan 2015 17:06:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.201.226 with HTTP; Wed, 21 Jan 2015 17:06:22 -0800 (PST) X-Originating-IP: [67.198.113.68] In-Reply-To: <20150121211500.GA32478@server.rulingia.com> References: <20150121211500.GA32478@server.rulingia.com> From: Bryan Venteicher Date: Wed, 21 Jan 2015 19:06:22 -0600 Message-ID: Subject: Re: [CFT] Paravirtualized KVM clock To: Peter Jeremy Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 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: Thu, 22 Jan 2015 01:06:47 -0000 On Wed, Jan 21, 2015 at 3:15 PM, Peter Jeremy wrote: > On 2015-Jan-04 11:56:14 -0600, Bryan Venteicher < > bryanv@daemoninthecloset.org> 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. > > A somewhat late response but have you looked at > > https://github.com/blitz/freebsd/commit/cdc5f872b3e48cc0dda031fc7d6bdedc65c3148f > I've been running this[*] on a Google Compute Engine instance for about 6 > months without problems. > > A goal of my work was to put a bit of infrastructure in place so FreeBSD can support pvops across a variety of hypervisors. KVMCLOCK happens to be about the easiest to implement, and has a decent performance win for many situations. I think that commit is broken on SMP guests: CPU_FOREACH() does not switch the current CPU, so it just keeps writing to the MSR on the BSP. [*] I had to patch out the test for KVM_FEATURE_CLOCKSOURCE_STABLE_BIT but > I think that's a GCE issue. > > -- > Peter Jeremy > From owner-freebsd-arch@FreeBSD.ORG Thu Jan 22 08:28:15 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 0488E322 for ; Thu, 22 Jan 2015 08:28:15 +0000 (UTC) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0C03C75 for ; Thu, 22 Jan 2015 08:28:14 +0000 (UTC) Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3kSc5m4YCWz3hjKf for ; Thu, 22 Jan 2015 09:22:04 +0100 (CET) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mail.mnet-online.de (Postfix) with ESMTP id 3kSc5m36X8zvh2M for ; Thu, 22 Jan 2015 09:22:04 +0100 (CET) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id 3BB55652CFD; Thu, 22 Jan 2015 09:22:03 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibusdmz X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from self.eb.z (unknown [192.168.100.11]) by mail.embedded-brains.de (Postfix) with ESMTP id A8A0C65253A; Thu, 22 Jan 2015 09:22:01 +0100 (CET) From: Sebastian Huber To: freebsd-arch@freebsd.org Subject: [PATCH] sys/tree.h: Add prototype and generate macros Date: Thu, 22 Jan 2015 09:22:00 +0100 Message-Id: <1421914920-31394-1-git-send-email-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 1.8.4.5 Cc: Sebastian Huber 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, 22 Jan 2015 08:28:15 -0000 Provide individual prototype and generate macros for the red-black tree. This helps to reduce code size in statically linked applications. --- sys/sys/tree.h | 86 +++++++++++++++++++++++++++++++++++++++++----------------- 1 file changed, 61 insertions(+), 25 deletions(-) diff --git a/sys/sys/tree.h b/sys/sys/tree.h index 1cce727..c9df686 100644 --- a/sys/sys/tree.h +++ b/sys/sys/tree.h @@ -383,16 +383,33 @@ struct { \ #define RB_PROTOTYPE_STATIC(name, type, field, cmp) \ RB_PROTOTYPE_INTERNAL(name, type, field, cmp, __unused static) #define RB_PROTOTYPE_INTERNAL(name, type, field, cmp, attr) \ -attr void name##_RB_INSERT_COLOR(struct name *, struct type *); \ -attr void name##_RB_REMOVE_COLOR(struct name *, struct type *, struct type *);\ -attr struct type *name##_RB_REMOVE(struct name *, struct type *); \ -attr struct type *name##_RB_INSERT(struct name *, struct type *); \ -attr struct type *name##_RB_FIND(struct name *, struct type *); \ -attr struct type *name##_RB_NFIND(struct name *, struct type *); \ -attr struct type *name##_RB_NEXT(struct type *); \ -attr struct type *name##_RB_PREV(struct type *); \ -attr struct type *name##_RB_MINMAX(struct name *, int); \ - \ + RB_PROTOTYPE_INSERT_COLOR(name, type, attr); \ + RB_PROTOTYPE_REMOVE_COLOR(name, type, attr); \ + RB_PROTOTYPE_INSERT(name, type, attr); \ + RB_PROTOTYPE_REMOVE(name, type, attr); \ + RB_PROTOTYPE_FIND(name, type, attr); \ + RB_PROTOTYPE_NFIND(name, type, attr); \ + RB_PROTOTYPE_NEXT(name, type, attr); \ + RB_PROTOTYPE_PREV(name, type, attr); \ + RB_PROTOTYPE_MINMAX(name, type, attr); +#define RB_PROTOTYPE_INSERT_COLOR(name, type, attr) \ + attr void name##_RB_INSERT_COLOR(struct name *, struct type *) +#define RB_PROTOTYPE_REMOVE_COLOR(name, type, attr) \ + attr void name##_RB_REMOVE_COLOR(struct name *, struct type *, struct type *) +#define RB_PROTOTYPE_REMOVE(name, type, attr) \ + attr struct type *name##_RB_REMOVE(struct name *, struct type *) +#define RB_PROTOTYPE_INSERT(name, type, attr) \ + attr struct type *name##_RB_INSERT(struct name *, struct type *) +#define RB_PROTOTYPE_FIND(name, type, attr) \ + attr struct type *name##_RB_FIND(struct name *, struct type *) +#define RB_PROTOTYPE_NFIND(name, type, attr) \ + attr struct type *name##_RB_NFIND(struct name *, struct type *) +#define RB_PROTOTYPE_NEXT(name, type, attr) \ + attr struct type *name##_RB_NEXT(struct type *) +#define RB_PROTOTYPE_PREV(name, type, attr) \ + attr struct type *name##_RB_PREV(struct type *) +#define RB_PROTOTYPE_MINMAX(name, type, attr) \ + attr struct type *name##_RB_MINMAX(struct name *, int) /* Main rb operation. * Moves node close to the key of elm to top @@ -402,6 +419,17 @@ attr struct type *name##_RB_MINMAX(struct name *, int); \ #define RB_GENERATE_STATIC(name, type, field, cmp) \ RB_GENERATE_INTERNAL(name, type, field, cmp, __unused static) #define RB_GENERATE_INTERNAL(name, type, field, cmp, attr) \ + RB_GENERATE_INSERT_COLOR(name, type, field, attr) \ + RB_GENERATE_REMOVE_COLOR(name, type, field, attr) \ + RB_GENERATE_INSERT(name, type, field, cmp, attr) \ + RB_GENERATE_REMOVE(name, type, field, attr) \ + RB_GENERATE_FIND(name, type, field, cmp, attr) \ + RB_GENERATE_NFIND(name, type, field, cmp, attr) \ + RB_GENERATE_NEXT(name, type, field, attr) \ + RB_GENERATE_PREV(name, type, field, attr) \ + RB_GENERATE_MINMAX(name, type, field, attr) + +#define RB_GENERATE_INSERT_COLOR(name, type, field, attr) \ attr void \ name##_RB_INSERT_COLOR(struct name *head, struct type *elm) \ { \ @@ -444,8 +472,9 @@ name##_RB_INSERT_COLOR(struct name *head, struct type *elm) \ } \ } \ RB_COLOR(head->rbh_root, field) = RB_BLACK; \ -} \ - \ +} + +#define RB_GENERATE_REMOVE_COLOR(name, type, field, attr) \ attr void \ name##_RB_REMOVE_COLOR(struct name *head, struct type *parent, struct type *elm) \ { \ @@ -522,8 +551,9 @@ name##_RB_REMOVE_COLOR(struct name *head, struct type *parent, struct type *elm) } \ if (elm) \ RB_COLOR(elm, field) = RB_BLACK; \ -} \ - \ +} + +#define RB_GENERATE_REMOVE(name, type, field, attr) \ attr struct type * \ name##_RB_REMOVE(struct name *head, struct type *elm) \ { \ @@ -590,7 +620,8 @@ color: \ name##_RB_REMOVE_COLOR(head, parent, child); \ return (old); \ } \ - \ + +#define RB_GENERATE_INSERT(name, type, field, cmp, attr) \ /* Inserts a node into the RB tree */ \ attr struct type * \ name##_RB_INSERT(struct name *head, struct type *elm) \ @@ -620,8 +651,9 @@ name##_RB_INSERT(struct name *head, struct type *elm) \ RB_ROOT(head) = elm; \ name##_RB_INSERT_COLOR(head, elm); \ return (NULL); \ -} \ - \ +} + +#define RB_GENERATE_FIND(name, type, field, cmp, attr) \ /* Finds the node with the same key as elm */ \ attr struct type * \ name##_RB_FIND(struct name *head, struct type *elm) \ @@ -638,8 +670,9 @@ name##_RB_FIND(struct name *head, struct type *elm) \ return (tmp); \ } \ return (NULL); \ -} \ - \ +} + +#define RB_GENERATE_NFIND(name, type, field, cmp, attr) \ /* Finds the first node greater than or equal to the search key */ \ attr struct type * \ name##_RB_NFIND(struct name *head, struct type *elm) \ @@ -659,8 +692,9 @@ name##_RB_NFIND(struct name *head, struct type *elm) \ return (tmp); \ } \ return (res); \ -} \ - \ +} + +#define RB_GENERATE_NEXT(name, type, field, attr) \ /* ARGSUSED */ \ attr struct type * \ name##_RB_NEXT(struct type *elm) \ @@ -681,8 +715,9 @@ name##_RB_NEXT(struct type *elm) \ } \ } \ return (elm); \ -} \ - \ +} + +#define RB_GENERATE_PREV(name, type, field, attr) \ /* ARGSUSED */ \ attr struct type * \ name##_RB_PREV(struct type *elm) \ @@ -703,8 +738,9 @@ name##_RB_PREV(struct type *elm) \ } \ } \ return (elm); \ -} \ - \ +} + +#define RB_GENERATE_MINMAX(name, type, field, attr) \ attr struct type * \ name##_RB_MINMAX(struct name *head, int val) \ { \ -- 1.8.4.5 From owner-freebsd-arch@FreeBSD.ORG Thu Jan 22 10:15: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 9A955A65; Thu, 22 Jan 2015 10:15:53 +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 53332AEC; Thu, 22 Jan 2015 10:15:52 +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 11AE91FE023; Thu, 22 Jan 2015 11:15:51 +0100 (CET) Message-ID: <54C0CE09.500@selasky.org> Date: Thu, 22 Jan 2015 11:16:41 +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: Slawa Olhovchenkov Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54A9A71E.70609@selasky.org> <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <54BADFB3.3030405@selasky.org> <54BE03EB.2070604@selasky.org> <20150120104736.GA78629@zxy.spb.ru> In-Reply-To: <20150120104736.GA78629@zxy.spb.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , FreeBSD Current , Jason Wolfe , "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: Thu, 22 Jan 2015 10:15:53 -0000 On 01/20/15 11:47, Slawa Olhovchenkov wrote: > On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote: > >> On 01/17/15 23:18, Hans Petter Selasky wrote: >>> On 01/17/15 20:11, Jason Wolfe wrote: >>>> >>>> HPS, >>>> >>>> Just to give a quick status update, this patch has most certainly >>>> resolved our spin lock held too long panics on stable/10. >>>> >>>> Thank you to JHB for spending some time digging into the issue and >>>> leading us to td_slpcallout as the culprit, and HPS for your rewrite. >>>> I had heard rumors of other being affected by similar issues, so this >>>> seems like a fine candidate for an MFC if possible. >>>> >>>> Jason >>>> >>> >>> Hi Jason, >>> >>> I'm glad to hear that my patch has resolved your issue and I'm happy we >>> now have a more stable system. >>> >>> It was actually a co-worker at work which wrote some bad code which I >>> started debugging which then lead me to look at the callout subsystem. >>> One bug kills the other ;-) >>> >>> I'm planning a MFC to 10-stable - yes, and will possibly add the >>> _callout_stop_safe() function to not break binary compatibility with >>> existing drivers as part of the MFC. >>> >>> --HPS >> >> Hi, >> >> Here is a followup patch for the TCP stack like I mentioned in the >> beginning of the work done on the callout subsystem: >> >> https://reviews.freebsd.org/D1563 >> >> If someone has a setup for massive TCP testing please give it a spin. > > I have on 10.1 (with applied r261906). FYI: r277213 is going to be pulled out from -current in at maximum a few hours from now, because developers need more time to review patches in surrounding areas like the TCP stack area to restore distribution of callouts on multiple CPUs when using MPSAFE callouts to avoid congestion in the TCP stack. --HPS From owner-freebsd-arch@FreeBSD.ORG Thu Jan 22 10:27:46 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 BA418D4A; Thu, 22 Jan 2015 10:27:46 +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 5C27ABF8; Thu, 22 Jan 2015 10:27:46 +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 t0MARe4r095047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 12:27:40 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0MARe4r095047 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0MARenC095046; Thu, 22 Jan 2015 12:27:40 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 22 Jan 2015 12:27:40 +0200 From: Konstantin Belousov To: Hans Petter Selasky Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress Message-ID: <20150122102740.GZ42409@kib.kiev.ua> References: <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <54BADFB3.3030405@selasky.org> <54BE03EB.2070604@selasky.org> <20150120104736.GA78629@zxy.spb.ru> <54C0CE09.500@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54C0CE09.500@selasky.org> 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: 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: Thu, 22 Jan 2015 10:27:46 -0000 On Thu, Jan 22, 2015 at 11:16:41AM +0100, Hans Petter Selasky wrote: > On 01/20/15 11:47, Slawa Olhovchenkov wrote: > > On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote: > > > >> On 01/17/15 23:18, Hans Petter Selasky wrote: > >>> On 01/17/15 20:11, Jason Wolfe wrote: > >>>> > >>>> HPS, > >>>> > >>>> Just to give a quick status update, this patch has most certainly > >>>> resolved our spin lock held too long panics on stable/10. > >>>> > >>>> Thank you to JHB for spending some time digging into the issue and > >>>> leading us to td_slpcallout as the culprit, and HPS for your rewrite. > >>>> I had heard rumors of other being affected by similar issues, so this > >>>> seems like a fine candidate for an MFC if possible. > >>>> > >>>> Jason > >>>> > >>> > >>> Hi Jason, > >>> > >>> I'm glad to hear that my patch has resolved your issue and I'm happy we > >>> now have a more stable system. > >>> > >>> It was actually a co-worker at work which wrote some bad code which I > >>> started debugging which then lead me to look at the callout subsystem. > >>> One bug kills the other ;-) > >>> > >>> I'm planning a MFC to 10-stable - yes, and will possibly add the > >>> _callout_stop_safe() function to not break binary compatibility with > >>> existing drivers as part of the MFC. > >>> > >>> --HPS > >> > >> Hi, > >> > >> Here is a followup patch for the TCP stack like I mentioned in the > >> beginning of the work done on the callout subsystem: > >> > >> https://reviews.freebsd.org/D1563 > >> > >> If someone has a setup for massive TCP testing please give it a spin. > > > > I have on 10.1 (with applied r261906). > > FYI: > > r277213 is going to be pulled out from -current in at maximum a few > hours from now, because developers need more time to review patches in > surrounding areas like the TCP stack area to restore distribution of > callouts on multiple CPUs when using MPSAFE callouts to avoid congestion > in the TCP stack. No, r277213 was requested to be reverted not due to TCP issues. The main complain is that you left indefinite amount of cases degraded, and there is no analysis of each such case, nor even a list of the cases that need to be fixed (or argumentation why consumer of the callout KPI could be left as is). Just providing fix for one place is not enough. From owner-freebsd-arch@FreeBSD.ORG Thu Jan 22 16:41:46 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 DF7BDEE8 for ; Thu, 22 Jan 2015 16:41:45 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (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 48CDEE15 for ; Thu, 22 Jan 2015 16:41:45 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id bs8so4688553wib.1 for ; Thu, 22 Jan 2015 08:41:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:reply-to:from:to:subject:date:mime-version:content-type :content-transfer-encoding; bh=+K2Jv07lLF56dW6EIAbmRc6z3OmNPqHtQ/82vdhmTWM=; b=i+6tXOx2S8UWL791CKdXZKu6Crw5Neaq9J+u6QP385p3XGGcnvdNZUiopld9/V9eW2 V2HsNMoHqIutkZ/iA1KJRfavhVBAcQ2+OyfUOA4hvDfZwqQNFAUp5OEq/5lhU09WN5NB UJcltYaTmaurz2mntp2JpvtwoTMaFfWvLwchRhH9TK5tPMk4rA5tXQZgaNc88LGHeRNM o9XcVxrqbJtnIS8olEmIwCKSTwe9UbNI3YgeqJ7cjyDCO8ngTLd6QEkKLTSLzUoesNvr lAK+FTaFZt4dYIwo9SDvyxTZhObKM0MsXIItbbiZOueSoFLP39x60FRxOscw5HNLmTsd XnxA== X-Received: by 10.194.122.233 with SMTP id lv9mr4649656wjb.95.1421944903622; Thu, 22 Jan 2015 08:41:43 -0800 (PST) Received: from alipour-PC ([5.234.117.68]) by mx.google.com with ESMTPSA id x6sm4640079wjf.24.2015.01.22.08.41.39 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 22 Jan 2015 08:41:42 -0800 (PST) Message-ID: <02206ea8-42026-01188414189815@alipour-pc> Reply-To: "Global Researchers Journals" From: "Global Researchers Journals" To: freebsd-arch@freebsd.org Subject: Call for Paper January 2015 { Vol 05 | Issue 01} Date: Thu, 22 Jan 2015 20:11:41 +0330 X-Priority: 3 MIME-Version: 1.0 Content-Type: text/plain 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: Thu, 22 Jan 2015 16:41:46 -0000 Call for Paper Dear Colleagues You are cordially invited to submit or recommend papers to: [1]http://www.grjournals.com January 2015 (Volume 05 | Issue 01) ·Journal of Physiology and Pharmacology Advances (JPPA) [2]http://grjournals.com/Default.aspx?tabid=6537 · Journal of Animal Production Advances (JAPA) [3]http://grjournals.com/Default.aspx?tabid=6538 Journal of Animal Science Advances (JASA) [4]http://grjournals.com/Default.aspx?tabid=6401 Journal of Veterinary Advances (JVA) [5]http://grjournals.com/Default.aspx?tabid=6536 Journal of Recent Advances in Agriculture (JRAA) http://grjournals.com/Default.aspx?tabid=6878 Global Researchers Journals, a fast track peer-reviewed and open access academic journal published by Grjournals Publishing, which is one of the largest open access journal publishers around the world. Grjournals is using online article submission, review and tracking system for quality and quick review processing. Journal provides rapid publication of research article. After 30 days Rapid Review Process by the editorial/review board members or outside experts, an accepted paper will be placed under In Press within 24 hours and will be published in the next issue. Instructions for authors are available on our website: [6]http://www.grjournals.com Submitted papers must follow the Instructions to authors to be considered for review and publication. Refereeing of manuscripts is conducted anonymously and the identity of the referees is not disclosed. The manuscripts which get an acceptance will publish with DOI number. Your Manuscript(s) can be one of these kinds: Review, Original Article, Case Report, Short Communications, Technical Notes, Mini Review Article and Hypothesis. Some of Abstracted/Index in: CAB reviews, Chemical Abstract Service (CAS), Genamics JournalSeek, Index Directory of Open Access Journals (DOAJ), Index Electronic Journals Library and SCIRUS, ISC and the World most Popular University Electronic Library. [7]http://grjournals.com/Defaul t.aspx?tabid=7329 Now you can clear the clutter by accessing your favorite journals online: · Full text, full archive that's always there when you need it · Easy access anywhere, anytime and anyhow · Impact your practice, not the environment NOTICE: Authors that cite [8]www.grjournals.com manuscripts as reference in their ISI articles, they can send their manuscripts to one of above journals as FREE of charge. After evaluation and get an acceptance it will publish without any Article Processing Fee with DOI. We apologize if you have received this email twice, or our journal is not your field. With Warm Regards Sincerely, Grjournals team Site: [9]www.grjournals.com E_Mail: [10]grjournals@gmail.com References 1. http://www.grjournals.com/ 2. http://grjournals.com/Default.aspx?tabid=6537 3. http://grjournals.com/Default.aspx?tabid=6538 4. http://grjournals.com/Default.aspx?tabid=6401 5. http://grjournals.com/Default.aspx?tabid=6536 6. http://www.grjournals.com/ 7. http://grjournals.com/Default.aspx?tabid=7329 8. http://www.grjournals.com/ 9. http://www.grjournals.com/ 10. mailto:grjournals@gmail.com From owner-freebsd-arch@FreeBSD.ORG Thu Jan 22 22:41:30 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 BEC8C6DA for ; Thu, 22 Jan 2015 22:41:30 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (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 9A59CF3A for ; Thu, 22 Jan 2015 22:41:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id t0MMfUAg055635 for ; Thu, 22 Jan 2015 22:41:30 GMT (envelope-from bdrewery@freefall.freebsd.org) Received: (from bdrewery@localhost) by freefall.freebsd.org (8.14.9/8.14.9/Submit) id t0MMfUj1055631 for freebsd-arch@freebsd.org; Thu, 22 Jan 2015 22:41:30 GMT (envelope-from bdrewery) Received: (qmail 25414 invoked from network); 22 Jan 2015 16:41:26 -0600 Received: from unknown (HELO ?10.10.1.139?) (freebsd@shatow.net@10.10.1.139) by sweb.xzibition.com with ESMTPA; 22 Jan 2015 16:41:26 -0600 Message-ID: <54C17CA5.9060703@FreeBSD.org> Date: Thu, 22 Jan 2015 16:41:41 -0600 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Konstantin Belousov , Hans Petter Selasky Subject: Re: [RFC] kern/kern_timeout.c rewrite in progress References: <54B29A49.3080600@selasky.org> <54B67DA7.3070106@selasky.org> <54B7DECF.8070209@selasky.org> <54BADFB3.3030405@selasky.org> <54BE03EB.2070604@selasky.org> <20150120104736.GA78629@zxy.spb.ru> <54C0CE09.500@selasky.org> <20150122102740.GZ42409@kib.kiev.ua> In-Reply-To: <20150122102740.GZ42409@kib.kiev.ua> OpenPGP: id=6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="V8R6iQUN5gKR6jDkMvLB0xg2tvPakJXN1" 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: Thu, 22 Jan 2015 22:41:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --V8R6iQUN5gKR6jDkMvLB0xg2tvPakJXN1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 1/22/2015 4:27 AM, Konstantin Belousov wrote: > On Thu, Jan 22, 2015 at 11:16:41AM +0100, Hans Petter Selasky wrote: >> On 01/20/15 11:47, Slawa Olhovchenkov wrote: >>> On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote: >>> >>>> On 01/17/15 23:18, Hans Petter Selasky wrote: >>>>> On 01/17/15 20:11, Jason Wolfe wrote: >>>>>> >>>>>> HPS, >>>>>> >>>>>> Just to give a quick status update, this patch has most certainly >>>>>> resolved our spin lock held too long panics on stable/10. >>>>>> >>>>>> Thank you to JHB for spending some time digging into the issue and= >>>>>> leading us to td_slpcallout as the culprit, and HPS for your rewri= te. >>>>>> I had heard rumors of other being affected by similar issues, so t= his >>>>>> seems like a fine candidate for an MFC if possible. >>>>>> >>>>>> Jason >>>>>> >>>>> >>>>> Hi Jason, >>>>> >>>>> I'm glad to hear that my patch has resolved your issue and I'm happ= y we >>>>> now have a more stable system. >>>>> >>>>> It was actually a co-worker at work which wrote some bad code which= I >>>>> started debugging which then lead me to look at the callout subsyst= em. >>>>> One bug kills the other ;-) >>>>> >>>>> I'm planning a MFC to 10-stable - yes, and will possibly add the >>>>> _callout_stop_safe() function to not break binary compatibility wit= h >>>>> existing drivers as part of the MFC. >>>>> >>>>> --HPS >>>> >>>> Hi, >>>> >>>> Here is a followup patch for the TCP stack like I mentioned in the >>>> beginning of the work done on the callout subsystem: >>>> >>>> https://reviews.freebsd.org/D1563 >>>> >>>> If someone has a setup for massive TCP testing please give it a spin= =2E >>> >>> I have on 10.1 (with applied r261906). >> >> FYI: >> >> r277213 is going to be pulled out from -current in at maximum a few=20 >> hours from now, because developers need more time to review patches in= =20 >> surrounding areas like the TCP stack area to restore distribution of=20 >> callouts on multiple CPUs when using MPSAFE callouts to avoid congesti= on=20 >> in the TCP stack. >=20 > No, r277213 was requested to be reverted not due to TCP issues. >=20 > The main complain is that you left indefinite amount of cases degraded,= > and there is no analysis of each such case, nor even a list of the case= s > that need to be fixed (or argumentation why consumer of the callout KPI= > could be left as is). >=20 > Just providing fix for one place is not enough. I have a similar concern about out-of-tree work. It would be surprising for a vendor or module developer to find their performance degrade if they missed accounting for this change. At a minimum, an UPDATING entry should be added explaining the change and what must be done for consumers= =2E --=20 Regards, Bryan Drewery --V8R6iQUN5gKR6jDkMvLB0xg2tvPakJXN1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJUwXylAAoJEDXXcbtuRpfP7dkIAM2nPjOqScYn2BhbXYckptZz fjScHRVBYGP03MCP1GGM6Jncr9uQrrzoOdp+8Bmn1ezquSdl5i7sLmVedVpuFKtP PzICFgl0pPkVie1ixByCqJ4ADiADmSU5sxOaDFOvQXtRaPEviHUnrhBaTWItHdEP ZUA8cHvzBgT2MXCmTCdFPnFJfxn3Ap+yvzL6lrgLuq+fVJNc23jTtRg12ipVzgGs LorIxFz/PUmrQ1tl8rb8ODk8rbeFQXiPCTMXHrFB0E6EGzrKQo6vRSLWAg7X2wQT xh+CReBtmRSNrP7C28ShBg5RmQVYzpurPFX+FWEMuqfGVbAiJzYRQozp1vSn0lI= =sTj3 -----END PGP SIGNATURE----- --V8R6iQUN5gKR6jDkMvLB0xg2tvPakJXN1-- From owner-freebsd-arch@FreeBSD.ORG Fri Jan 23 11:59:25 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 B85A8CF7 for ; Fri, 23 Jan 2015 11:59:25 +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 43F129B2 for ; Fri, 23 Jan 2015 11:59:25 +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 t0NBx90h050992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Jan 2015 13:59:09 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0NBx90h050992 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0NBx9Lo050991; Fri, 23 Jan 2015 13:59:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 23 Jan 2015 13:59:09 +0200 From: Konstantin Belousov To: Sebastian Huber Subject: Re: [PATCH] sys/tree.h: Add prototype and generate macros Message-ID: <20150123115909.GJ42409@kib.kiev.ua> References: <1421914920-31394-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: <1421914920-31394-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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home 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: Fri, 23 Jan 2015 11:59:25 -0000 On Thu, Jan 22, 2015 at 09:22:00AM +0100, Sebastian Huber wrote: > Provide individual prototype and generate macros for the red-black tree. > This helps to reduce code size in statically linked applications. This looks at least innocent, and probably is useful in other cases as well. Would you update the man page ? May be, the full list of subordinate macros for RB_PROTOTYPE/GENERATE is not needed, but the feature should be noted and header file referenced, at least. From owner-freebsd-arch@FreeBSD.ORG Fri Jan 23 14:11:42 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 C4FB214D for ; Fri, 23 Jan 2015 14:11:42 +0000 (UTC) Received: from mail-out.m-online.net (mail-out.m-online.net [212.18.0.9]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6EE5CAFD for ; Fri, 23 Jan 2015 14:11:41 +0000 (UTC) Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3kTMpX4Bzlz3hj6s for ; Fri, 23 Jan 2015 15:11:31 +0100 (CET) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) by mail.mnet-online.de (Postfix) with ESMTP id 3kTMpW4bD8zvjN0 for ; Fri, 23 Jan 2015 15:11:31 +0100 (CET) Received: by mail.embedded-brains.de (Postfix, from userid 65534) id 34E85652CFF; Fri, 23 Jan 2015 15:11:31 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on fidibusdmz X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from self.eb.z (unknown [192.168.100.11]) by mail.embedded-brains.de (Postfix) with ESMTP id 31B10652CFC; Fri, 23 Jan 2015 15:11:30 +0100 (CET) From: Sebastian Huber To: freebsd-arch@freebsd.org Subject: [PATCH v2] sys/tree.h: Add prototype and generate macros Date: Fri, 23 Jan 2015 15:11:28 +0100 Message-Id: <1422022288-17630-1-git-send-email-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 1.8.4.5 Cc: Sebastian Huber 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, 23 Jan 2015 14:11:42 -0000 Provide individual prototype and generate macros for the red-black tree. This helps to reduce code size in statically linked applications. v2: Update man page. --- share/man/man3/tree.3 | 71 ++++++++++++++++++++++++++++++++++++++++++ sys/sys/tree.h | 86 ++++++++++++++++++++++++++++++++++++--------------- 2 files changed, 132 insertions(+), 25 deletions(-) diff --git a/share/man/man3/tree.3 b/share/man/man3/tree.3 index 2e9c63c..0940a0c 100644 --- a/share/man/man3/tree.3 +++ b/share/man/man3/tree.3 @@ -53,8 +53,26 @@ .Nm SPLAY_REMOVE , .Nm RB_PROTOTYPE , .Nm RB_PROTOTYPE_STATIC , +.Nm RB_PROTOTYPE_INSERT , +.Nm RB_PROTOTYPE_INSERT_COLOR , +.Nm RB_PROTOTYPE_REMOVE , +.Nm RB_PROTOTYPE_REMOVE_COLOR , +.Nm RB_PROTOTYPE_FIND , +.Nm RB_PROTOTYPE_NFIND , +.Nm RB_PROTOTYPE_NEXT , +.Nm RB_PROTOTYPE_PREV , +.Nm RB_PROTOTYPE_MINMAX , .Nm RB_GENERATE , .Nm RB_GENERATE_STATIC , +.Nm RB_GENERATE_INSERT , +.Nm RB_GENERATE_INSERT_COLOR , +.Nm RB_GENERATE_REMOVE , +.Nm RB_GENERATE_REMOVE_COLOR , +.Nm RB_GENERATE_FIND , +.Nm RB_GENERATE_NFIND , +.Nm RB_GENERATE_NEXT , +.Nm RB_GENERATE_PREV , +.Nm RB_GENERATE_MINMAX , .Nm RB_ENTRY , .Nm RB_HEAD , .Nm RB_INITIALIZER , @@ -111,8 +129,26 @@ .Fn SPLAY_REMOVE NAME "SPLAY_HEAD *head" "struct TYPE *elm" .Fn RB_PROTOTYPE NAME TYPE FIELD CMP .Fn RB_PROTOTYPE_STATIC NAME TYPE FIELD CMP +.Fn RB_PROTOTYPE_INSERT NAME TYPE ATTR +.Fn RB_PROTOTYPE_INSERT_COLOR NAME TYPE ATTR +.Fn RB_PROTOTYPE_REMOVE NAME TYPE ATTR +.Fn RB_PROTOTYPE_REMOVE_COLOR NAME TYPE ATTR +.Fn RB_PROTOTYPE_FIND NAME TYPE ATTR +.Fn RB_PROTOTYPE_NFIND NAME TYPE ATTR +.Fn RB_PROTOTYPE_NEXT NAME TYPE ATTR +.Fn RB_PROTOTYPE_PREV NAME TYPE ATTR +.Fn RB_PROTOTYPE_MINMAX NAME TYPE ATTR .Fn RB_GENERATE NAME TYPE FIELD CMP .Fn RB_GENERATE_STATIC NAME TYPE FIELD CMP +.Fn RB_GENERATE_INSERT NAME TYPE FIELD CMP ATTR +.Fn RB_GENERATE_INSERT_COLOR NAME TYPE FIELD ATTR +.Fn RB_GENERATE_REMOVE NAME TYPE FIELD ATTR +.Fn RB_GENERATE_REMOVE_COLOR NAME TYPE FIELD ATTR +.Fn RB_GENERATE_FIND NAME TYPE FIELD CMP ATTR +.Fn RB_GENERATE_NFIND NAME TYPE FIELD CMP ATTR +.Fn RB_GENERATE_NEXT NAME TYPE FIELD ATTR +.Fn RB_GENERATE_PREV NAME TYPE FIELD ATTR +.Fn RB_GENERATE_MINMAX NAME TYPE FIELD ATTR .Fn RB_ENTRY TYPE .Fn RB_HEAD HEADNAME TYPE .Fn RB_INITIALIZER "RB_HEAD *head" @@ -377,6 +413,29 @@ The .Fa FIELD argument is the name of the element defined by .Fn RB_ENTRY . +Individual prototypes can be declared with +.Fn RB_PROTOTYPE_INSERT , +.Fn RB_PROTOTYPE_INSERT_COLOR , +.Fn RB_PROTOTYPE_REMOVE , +.Fn RB_PROTOTYPE_REMOVE_COLOR , +.Fn RB_PROTOTYPE_FIND , +.Fn RB_PROTOTYPE_NFIND , +.Fn RB_PROTOTYPE_NEXT , +.Fn RB_PROTOTYPE_PREV , +and +.Fn RB_PROTOTYPE_MINMAX +in case not all functions are required. The individual prototype macros expect +.Fa NAME , +.Fa TYPE , +and +.Fa ATTR +arguments. The +.Fa ATTR +argument must be +.Fa empty +for global functions or +.Fa static +for static functions. .Pp The function bodies are generated with the .Fn RB_GENERATE @@ -388,6 +447,18 @@ These macros take the same arguments as the and .Fn RB_PROTOTYPE_STATIC macros, but should be used only once. +As an alternative individual function bodies are generated with the +.Fn RB_GENERATE_INSERT , +.Fn RB_GENERATE_INSERT_COLOR , +.Fn RB_GENERATE_REMOVE , +.Fn RB_GENERATE_REMOVE_COLOR , +.Fn RB_GENERATE_FIND , +.Fn RB_GENERATE_NFIND , +.Fn RB_GENERATE_NEXT , +.Fn RB_GENERATE_PREV , +and +.Fn RB_GENERATE_MINMAX +macros. .Pp Finally, the diff --git a/sys/sys/tree.h b/sys/sys/tree.h index 1cce727..c9df686 100644 --- a/sys/sys/tree.h +++ b/sys/sys/tree.h @@ -383,16 +383,33 @@ struct { \ #define RB_PROTOTYPE_STATIC(name, type, field, cmp) \ RB_PROTOTYPE_INTERNAL(name, type, field, cmp, __unused static) #define RB_PROTOTYPE_INTERNAL(name, type, field, cmp, attr) \ -attr void name##_RB_INSERT_COLOR(struct name *, struct type *); \ -attr void name##_RB_REMOVE_COLOR(struct name *, struct type *, struct type *);\ -attr struct type *name##_RB_REMOVE(struct name *, struct type *); \ -attr struct type *name##_RB_INSERT(struct name *, struct type *); \ -attr struct type *name##_RB_FIND(struct name *, struct type *); \ -attr struct type *name##_RB_NFIND(struct name *, struct type *); \ -attr struct type *name##_RB_NEXT(struct type *); \ -attr struct type *name##_RB_PREV(struct type *); \ -attr struct type *name##_RB_MINMAX(struct name *, int); \ - \ + RB_PROTOTYPE_INSERT_COLOR(name, type, attr); \ + RB_PROTOTYPE_REMOVE_COLOR(name, type, attr); \ + RB_PROTOTYPE_INSERT(name, type, attr); \ + RB_PROTOTYPE_REMOVE(name, type, attr); \ + RB_PROTOTYPE_FIND(name, type, attr); \ + RB_PROTOTYPE_NFIND(name, type, attr); \ + RB_PROTOTYPE_NEXT(name, type, attr); \ + RB_PROTOTYPE_PREV(name, type, attr); \ + RB_PROTOTYPE_MINMAX(name, type, attr); +#define RB_PROTOTYPE_INSERT_COLOR(name, type, attr) \ + attr void name##_RB_INSERT_COLOR(struct name *, struct type *) +#define RB_PROTOTYPE_REMOVE_COLOR(name, type, attr) \ + attr void name##_RB_REMOVE_COLOR(struct name *, struct type *, struct type *) +#define RB_PROTOTYPE_REMOVE(name, type, attr) \ + attr struct type *name##_RB_REMOVE(struct name *, struct type *) +#define RB_PROTOTYPE_INSERT(name, type, attr) \ + attr struct type *name##_RB_INSERT(struct name *, struct type *) +#define RB_PROTOTYPE_FIND(name, type, attr) \ + attr struct type *name##_RB_FIND(struct name *, struct type *) +#define RB_PROTOTYPE_NFIND(name, type, attr) \ + attr struct type *name##_RB_NFIND(struct name *, struct type *) +#define RB_PROTOTYPE_NEXT(name, type, attr) \ + attr struct type *name##_RB_NEXT(struct type *) +#define RB_PROTOTYPE_PREV(name, type, attr) \ + attr struct type *name##_RB_PREV(struct type *) +#define RB_PROTOTYPE_MINMAX(name, type, attr) \ + attr struct type *name##_RB_MINMAX(struct name *, int) /* Main rb operation. * Moves node close to the key of elm to top @@ -402,6 +419,17 @@ attr struct type *name##_RB_MINMAX(struct name *, int); \ #define RB_GENERATE_STATIC(name, type, field, cmp) \ RB_GENERATE_INTERNAL(name, type, field, cmp, __unused static) #define RB_GENERATE_INTERNAL(name, type, field, cmp, attr) \ + RB_GENERATE_INSERT_COLOR(name, type, field, attr) \ + RB_GENERATE_REMOVE_COLOR(name, type, field, attr) \ + RB_GENERATE_INSERT(name, type, field, cmp, attr) \ + RB_GENERATE_REMOVE(name, type, field, attr) \ + RB_GENERATE_FIND(name, type, field, cmp, attr) \ + RB_GENERATE_NFIND(name, type, field, cmp, attr) \ + RB_GENERATE_NEXT(name, type, field, attr) \ + RB_GENERATE_PREV(name, type, field, attr) \ + RB_GENERATE_MINMAX(name, type, field, attr) + +#define RB_GENERATE_INSERT_COLOR(name, type, field, attr) \ attr void \ name##_RB_INSERT_COLOR(struct name *head, struct type *elm) \ { \ @@ -444,8 +472,9 @@ name##_RB_INSERT_COLOR(struct name *head, struct type *elm) \ } \ } \ RB_COLOR(head->rbh_root, field) = RB_BLACK; \ -} \ - \ +} + +#define RB_GENERATE_REMOVE_COLOR(name, type, field, attr) \ attr void \ name##_RB_REMOVE_COLOR(struct name *head, struct type *parent, struct type *elm) \ { \ @@ -522,8 +551,9 @@ name##_RB_REMOVE_COLOR(struct name *head, struct type *parent, struct type *elm) } \ if (elm) \ RB_COLOR(elm, field) = RB_BLACK; \ -} \ - \ +} + +#define RB_GENERATE_REMOVE(name, type, field, attr) \ attr struct type * \ name##_RB_REMOVE(struct name *head, struct type *elm) \ { \ @@ -590,7 +620,8 @@ color: \ name##_RB_REMOVE_COLOR(head, parent, child); \ return (old); \ } \ - \ + +#define RB_GENERATE_INSERT(name, type, field, cmp, attr) \ /* Inserts a node into the RB tree */ \ attr struct type * \ name##_RB_INSERT(struct name *head, struct type *elm) \ @@ -620,8 +651,9 @@ name##_RB_INSERT(struct name *head, struct type *elm) \ RB_ROOT(head) = elm; \ name##_RB_INSERT_COLOR(head, elm); \ return (NULL); \ -} \ - \ +} + +#define RB_GENERATE_FIND(name, type, field, cmp, attr) \ /* Finds the node with the same key as elm */ \ attr struct type * \ name##_RB_FIND(struct name *head, struct type *elm) \ @@ -638,8 +670,9 @@ name##_RB_FIND(struct name *head, struct type *elm) \ return (tmp); \ } \ return (NULL); \ -} \ - \ +} + +#define RB_GENERATE_NFIND(name, type, field, cmp, attr) \ /* Finds the first node greater than or equal to the search key */ \ attr struct type * \ name##_RB_NFIND(struct name *head, struct type *elm) \ @@ -659,8 +692,9 @@ name##_RB_NFIND(struct name *head, struct type *elm) \ return (tmp); \ } \ return (res); \ -} \ - \ +} + +#define RB_GENERATE_NEXT(name, type, field, attr) \ /* ARGSUSED */ \ attr struct type * \ name##_RB_NEXT(struct type *elm) \ @@ -681,8 +715,9 @@ name##_RB_NEXT(struct type *elm) \ } \ } \ return (elm); \ -} \ - \ +} + +#define RB_GENERATE_PREV(name, type, field, attr) \ /* ARGSUSED */ \ attr struct type * \ name##_RB_PREV(struct type *elm) \ @@ -703,8 +738,9 @@ name##_RB_PREV(struct type *elm) \ } \ } \ return (elm); \ -} \ - \ +} + +#define RB_GENERATE_MINMAX(name, type, field, attr) \ attr struct type * \ name##_RB_MINMAX(struct name *head, int val) \ { \ -- 1.8.4.5 From owner-freebsd-arch@FreeBSD.ORG Sat Jan 24 12:44:03 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 33D2C1F9 for ; Sat, 24 Jan 2015 12:44: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 B4F3DC58 for ; Sat, 24 Jan 2015 12:44: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 t0OChuaM011682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jan 2015 14:43:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t0OChuaM011682 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t0OChujp011681; Sat, 24 Jan 2015 14:43:56 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 24 Jan 2015 14:43:56 +0200 From: Konstantin Belousov To: Sebastian Huber Subject: Re: [PATCH v2] sys/tree.h: Add prototype and generate macros Message-ID: <20150124124356.GT42409@kib.kiev.ua> References: <1422022288-17630-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: <1422022288-17630-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.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home 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: Sat, 24 Jan 2015 12:44:03 -0000 On Fri, Jan 23, 2015 at 03:11:28PM +0100, Sebastian Huber wrote: > Provide individual prototype and generate macros for the red-black tree. > This helps to reduce code size in statically linked applications. Committed as r277642. Thank you. From owner-freebsd-arch@FreeBSD.ORG Sat Jan 24 14:34: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 E3FB997D for ; Sat, 24 Jan 2015 14:34:02 +0000 (UTC) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (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 74B1985E for ; Sat, 24 Jan 2015 14:34:02 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id b13so2161982wgh.9 for ; Sat, 24 Jan 2015 06:34:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=Q75xaXoPAQdeMkzyl3hfiraHCcHWKz0imcH3AOC30lE=; b=zehOg3cFdbg+Qj5e4T75p0W0XrXjUpW/hgBeI+AXHVYOF/CbYXf90qmfzP79AIJ2h4 byOcV2C32G4aCA6qJ+qu3QiFIfKs3yI3LkI+IZnkEQM7hGkg0UjZrKbQTkHKCPzQ5gWK 6FZFQdhTHkGJvJ35RmSdtSxiVf2ItE+ZulCY0wqbb8T975oNox/6zb1umDoPfCbzbkoa PAlJzLkyuQpV3EniPyur5PzuN8dopbBIt2C1CGKmLMBBCC+O7tn/VUfR1pcDOBO2lqas stIrwocUWeS+5OlZCZW063xUhBbx7NGGdatdb43FEjyio3rQQ+ALwvkJLA6IO1LDtdPa QYog== X-Received: by 10.180.210.174 with SMTP id mv14mr13899086wic.80.1422110040466; Sat, 24 Jan 2015 06:34:00 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id ha1sm6041601wib.24.2015.01.24.06.33.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 06:33:59 -0800 (PST) Sender: Baptiste Daroussin Date: Sat, 24 Jan 2015 15:33:57 +0100 From: Baptiste Daroussin To: arch@FreeBSD.org Subject: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150124143357.GI81001@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cVp8NMj01v+Em8Se" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) 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, 24 Jan 2015 14:34:03 -0000 --cVp8NMj01v+Em8Se Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, After a bit of hacking on libedit it is now able to handle unicode inputs in a better way. At least good enough for /bin/sh to work normally in unicode environements. Given that vt handles properly unicode inputs. I would like to propose that now we set the defaults locales on HEAD to en_US.UTF-8. https://reviews.freebsd.org/D1467 Best regards, Bapt --cVp8NMj01v+Em8Se Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTDrVUACgkQ8kTtMUmk6EycVQCfRNOF46E79iBUUVYVxgcvCzh+ Mf0AoJKzU0mSR11/m9biy785Yi60fIAy =qsuu -----END PGP SIGNATURE----- --cVp8NMj01v+Em8Se-- From owner-freebsd-arch@FreeBSD.ORG Sat Jan 24 17:52:10 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 6F7241A4 for ; Sat, 24 Jan 2015 17:52:10 +0000 (UTC) Received: from mail-ig0-f175.google.com (mail-ig0-f175.google.com [209.85.213.175]) (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 3BC8DBFE for ; Sat, 24 Jan 2015 17:52:09 +0000 (UTC) Received: by mail-ig0-f175.google.com with SMTP id hn18so2470869igb.2 for ; Sat, 24 Jan 2015 09:52:02 -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:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=QtWEPiRnb3b3Zj3rOiafokWiO5C2epGI9iiYwMEd/Cg=; b=JC+fP/Lw4BYtmnUlBJMg/LPOEO/zffsGnutFiXh1FSW4IxoU7ldu5K+J43Qcyqw+oZ +PYNwm/cxnacGD+gzzYDo2Rw+S3yGW/zm4PtGhz7UTgWe66ng9ovFdlxxTuaBgLQW2Xx hIKz/9PupHoLtRIubnu3DdMpkpmFA/OHkAg8C0cFlo0BRlidfxnz+aOIbxMhvS2Xy7yL OGGxxuYLTgjvO0yTYpRvFkT8M82pH6vEh5USDh8AhI5dlJKGg510BU5GNj2YF+eE6og4 /mQVKr0l4ECeGYRpPVHfjyn5lSQPVBw6FiXoTWNSsMSzMzybrio9tNzS9kgx0ADlUP+5 qSHA== X-Gm-Message-State: ALoCoQnVhV5SnycKKazC0lxVVeGSYg4jp3J12NWsgMKgbxXdffFVL2jw7gv1f0JvF9s9uFLPEJSR X-Received: by 10.43.66.9 with SMTP id xo9mr14072731icb.67.1422121922874; Sat, 24 Jan 2015 09:52:02 -0800 (PST) Received: from netflix-mac.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id v64sm2929896ioi.18.2015.01.24.09.52.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Jan 2015 09:52:02 -0800 (PST) Sender: Warner Losh Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: [RFC] Set the default locale to en_US.UTF-8 From: Warner Losh In-Reply-To: <20150124143357.GI81001@ivaldir.etoilebsd.net> Date: Sat, 24 Jan 2015 10:52:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150124143357.GI81001@ivaldir.etoilebsd.net> To: Baptiste Daroussin X-Mailer: Apple Mail (2.1993) 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: Sat, 24 Jan 2015 17:52:10 -0000 > On Jan 24, 2015, at 7:33 AM, Baptiste Daroussin = wrote: >=20 > Hi, >=20 > After a bit of hacking on libedit it is now able to handle unicode = inputs in a > better way. At least good enough for /bin/sh to work normally in = unicode > environements. >=20 > Given that vt handles properly unicode inputs. I would like to propose = that now > we set the defaults locales on HEAD to en_US.UTF-8. >=20 > https://reviews.freebsd.org/D1467 Do recent vintage Terms and its decedents handle UTF-8? If so, then = that=E2=80=99s likely a reasonable default change. Then again, I speak English, and the change does now explicitly specify = a language which before defaulted to English. Warner From owner-freebsd-arch@FreeBSD.ORG Sat Jan 24 18:10:21 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 2888F7EE for ; Sat, 24 Jan 2015 18:10:21 +0000 (UTC) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::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 AA040D30 for ; Sat, 24 Jan 2015 18:10:20 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id x3so2760538wes.1 for ; Sat, 24 Jan 2015 10:10:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=dZJhKK4KriTrsZniAwLNqJRXVnUrjMmaK2m1W823xM0=; b=QGUVK49Ld4/98x5016ew/QHFRnRCyOohH+drm9QBith+v714r7fqYYLDRVz98LOkiX ZMyDtHbPzC1OlD+8esY8J7vsADEzV6iq6NT4LSHsz1vy9CiY1qp1RJkliKQu18tcsjwy f+Rog24T/pD26EsQl2W6FTX1sTeOtymugAjEHR948Zv7hd0mKai10M/drVzouAUZ2kl0 zkV11vWidgV8Rhx3blBUUKSAks+RSzVtHVTn4LcLdcnDY0iTobM9E4Gqbt/H228QaSpl 2l9jKiV5UYwIuokbAO9nYfYTlGcrn+5Jk1NKWRsRI8BsIKBrRXn10z8T/9N152fdBaLW 9yXw== X-Received: by 10.180.126.99 with SMTP id mx3mr10670875wib.66.1422123019152; Sat, 24 Jan 2015 10:10:19 -0800 (PST) Received: from ivaldir.etoilebsd.net ([2001:41d0:8:db4c::1]) by mx.google.com with ESMTPSA id x10sm6746419wif.15.2015.01.24.10.10.17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jan 2015 10:10:18 -0800 (PST) Sender: Baptiste Daroussin Date: Sat, 24 Jan 2015 19:10:16 +0100 From: Baptiste Daroussin To: Warner Losh Subject: Re: [RFC] Set the default locale to en_US.UTF-8 Message-ID: <20150124181016.GK81001@ivaldir.etoilebsd.net> References: <20150124143357.GI81001@ivaldir.etoilebsd.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mGCtrYeZ202LI9ZG" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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: Sat, 24 Jan 2015 18:10:21 -0000 --mGCtrYeZ202LI9ZG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 24, 2015 at 10:52:01AM -0700, Warner Losh wrote: >=20 > > On Jan 24, 2015, at 7:33 AM, Baptiste Daroussin wrot= e: > >=20 > > Hi, > >=20 > > After a bit of hacking on libedit it is now able to handle unicode inpu= ts in a > > better way. At least good enough for /bin/sh to work normally in unicode > > environements. > >=20 > > Given that vt handles properly unicode inputs. I would like to propose = that now > > we set the defaults locales on HEAD to en_US.UTF-8. > >=20 > > https://reviews.freebsd.org/D1467 >=20 > Do recent vintage Terms and its decedents handle UTF-8? If so, then that= =E2=80=99s likely > a reasonable default change. =46rom what I'm aware of all modern (including the good old xterm) do suppo= rt UTF-8 correctly. >=20 > Then again, I speak English, and the change does now explicitly specify a= language > which before defaulted to English. Maybe the bsdconfig can be tweak to allow the user to chose the default language? Best regards, Bapt --mGCtrYeZ202LI9ZG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTD4AgACgkQ8kTtMUmk6EwbSwCfU4TCRlLhJ+ClHsPxrm+yttDh UG4An1oN8RT2xLvdhSE4vhVOtwRuPsGs =iX/Z -----END PGP SIGNATURE----- --mGCtrYeZ202LI9ZG-- From owner-freebsd-arch@FreeBSD.ORG Sat Jan 24 22:26:22 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 28E85B61 for ; Sat, 24 Jan 2015 22:26:22 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (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 E65F29D0 for ; Sat, 24 Jan 2015 22:26:21 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hl2so2340776igb.0 for ; Sat, 24 Jan 2015 14:26:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=t13PePcmJ8tV1Ej+ZQumCzf6j3c/CvgYCCNwypvv6xs=; b=0Zl7nY4559eV1DL+B6X/pCo/pAFUu1B08oHJGWysLRCxfc956vHYnF/uOUrIHdMcT8 MNhF9Caj1MQCHzESRbHZ5idB4CHxGBgYRjguxfWo++Prh7kiB0gvRmFOduWqUiL2X9XV mYbIuak/qzeTJwJGXDS9OMBCr7DPWaRUssU4OXYbVAPkRzYAbgrqCNyGHHzc3mAlXyO7 GtaWNU4ah0sNsNatH4LcAvYSUWB7zrfap3RksGik7Gzl3NhXyo9SdFJikNfCJrxA5LT1 5cU3hYN/IwnlwhJoratjDzfGZViXLWCmlnU9T8PDpgCid0EYXWh3piElt6l5WNx51nBU H/PA== MIME-Version: 1.0 X-Received: by 10.50.66.171 with SMTP id g11mr9103437igt.49.1422138381477; Sat, 24 Jan 2015 14:26:21 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.36.78.14 with HTTP; Sat, 24 Jan 2015 14:26:21 -0800 (PST) Date: Sat, 24 Jan 2015 14:26:21 -0800 X-Google-Sender-Auth: VUEV5KdenaEB9kUDnadOq6TDDlc Message-ID: Subject: CFR: WITNESS_WARN() in callout_drain() From: Adrian Chadd To: "freebsd-arch@freebsd.org" Content-Type: text/plain; charset=UTF-8 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, 24 Jan 2015 22:26:22 -0000 Hi, This tripped me up a couple months ago and I'm finally getting around to flushing my patch queue. https://reviews.freebsd.org/D1638 Comments? -a