From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 7 00:13:27 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C482FE9A for ; Sun, 7 Jun 2015 00:13:27 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 994231664 for ; Sun, 7 Jun 2015 00:13:27 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=7ngDWCIl/+mt/Iyfh/HI9qCWkYzc54Kpyf9orfxgBHY=; b=XJk0uJLA13/DZrS2DyoCHCcNm/ISYYn99v/Yfv3BTAcyh4VZps7SGc5rbJ4MblJ158oQk/chfUYsZ5+XU75UcFv/uTnpxkj6iy9o7hUXVAW/We7GeUjAqDcLASXZw683sBTVNWOxLUjK9ptRgy+pjWfz+dcyZ1OeMkcbAm2lCCE=; Received: from [114.124.31.137] (port=57424 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.85) (envelope-from ) id 1Z1ODH-003xrN-TR for freebsd-hackers@FreeBSD.org; Sat, 06 Jun 2015 18:13:20 -0600 Date: Sun, 7 Jun 2015 08:13:15 +0800 From: Erich Dollansky To: "freebsd-hackers@freebsd.org" Subject: allow ffs & co. a binary search Message-ID: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 00:13:27 -0000 Hi, I stumbled these days over the functions to find the first or last bit set. They are currently written like this: /* * Find First Set bit */ int ffs(int mask) { int bit; if (mask == 0) return (0); for (bit = 1; !(mask & 1); bit++) mask = (unsigned int)mask >> 1; return (bit); } With other words, the program loops until it finds what it searches for. Why not do it the binary way? int res; res = 0; IF (Number != 0) THEN res = 1; IF ((Number & 0xFFFFFFFF00000000) != 0) THEN Number = Number & 0xFFFFFFFF00000000; res = res + 32; END; IF ((Number & 0xFFFF0000FFFF0000) != 0) THEN Number = Number & 0xFFFF0000FFFF0000; res = res + 16; END; IF ((Number & 0xFF00FF00FF00FF00) != 0) THEN Number = Number & 0xFF00FF00FF00FF00; res = res + 8; END; IF ((Number & 0xF0F0F0F0F0F0F0F0) != 0) THEN Number = Number & 0xF0F0F0F0F0F0F0F0; res = res + 4; END; IF ((Number & 0xCCCCCCCCCCCCCCCC) != 0) THEN Number = Number & 0xCCCCCCCCCCCCCCCC; res = res + 2; END; IF ((Number & 0xAAAAAAAAAAAAAAAA) != 0) THEN Number = Number & 0xAAAAAAAAAAAAAAAA; res = res + 1; END; END; return res; If you like the binary way I could give you the sources for the complete family following your style to replace the older functions. Erich From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 7 07:02:33 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D04DD279 for ; Sun, 7 Jun 2015 07:02:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90AFE1269 for ; Sun, 7 Jun 2015 07:02:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id BF0901FE023; Sun, 7 Jun 2015 08:52:31 +0200 (CEST) Message-ID: <5573EA5E.40806@selasky.org> Date: Sun, 07 Jun 2015 08:53:18 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Erich Dollansky , "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> In-Reply-To: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 07:02:33 -0000 On 06/07/15 02:13, Erich Dollansky wrote: > Hi, > > I stumbled these days over the functions to find the first or last bit > set. They are currently written like this: > > /* > * Find First Set bit > */ > int > ffs(int mask) > { > int bit; > > if (mask == 0) > return (0); > for (bit = 1; !(mask & 1); bit++) > mask = (unsigned int)mask >> 1; > return (bit); > } > > With other words, the program loops until it finds what it searches for. > > Why not do it the binary way? > > int res; > > res = 0; > IF (Number != 0) THEN > res = 1; > IF ((Number & 0xFFFFFFFF00000000) != 0) THEN > Number = Number & 0xFFFFFFFF00000000; > res = res + 32; > END; > IF ((Number & 0xFFFF0000FFFF0000) != 0) THEN > Number = Number & 0xFFFF0000FFFF0000; > res = res + 16; > END; > IF ((Number & 0xFF00FF00FF00FF00) != 0) THEN > Number = Number & 0xFF00FF00FF00FF00; > res = res + 8; > END; > IF ((Number & 0xF0F0F0F0F0F0F0F0) != 0) THEN > Number = Number & 0xF0F0F0F0F0F0F0F0; > res = res + 4; > END; > IF ((Number & 0xCCCCCCCCCCCCCCCC) != 0) THEN > Number = Number & 0xCCCCCCCCCCCCCCCC; > res = res + 2; > END; > IF ((Number & 0xAAAAAAAAAAAAAAAA) != 0) THEN > Number = Number & 0xAAAAAAAAAAAAAAAA; > res = res + 1; > END; > END; > return res; > > If you like the binary way I could give you the sources for the > complete family following your style to replace the older functions. > Hi Erich, I think this is not the fastest way to do it. You first find the LSB, then you do a sumbits, which doesn't have any conditionals IF/ELSE and performs better with the CPU pipeline. I think the software ffs() is only used for platforms which doesn't have a hardware version btw: From my libmbin: > uint8_t > mbin_sumbits32(uint32_t val) > { > #if 0 > uint8_t t = 0; > > while (val) { > if (val & 1) > t++; > val >>= 1; > } > return (t); > #else > val = ((val & (1U * 0xAAAAAAAAU)) / 2U) + (val & (1U * 0x55555555U)); > val = ((val & (3U * 0x44444444U)) / 4U) + (val & (3U * 0x11111111U)); > val = ((val & (15U * 0x10101010U)) / 16U) + (val & (15U * 0x01010101U)); > val = ((val & (255U * 0x01000100U)) / 256U) + (val & (255U * 0x00010001U)); > val = ((val & (65535U * 0x00010000U)) / 65536U) + (val & (65535U * 0x00000001U)); > return (val); > #endif > } > uint32_t > mbin_lsb32(uint32_t val) > { > return ((~(val - 1)) & val); > } int ffs(int value) { int retval = mbin_sumbits32(mbin_lsb32(value) - 1); if (retval == 32) retval = 0; else retval++; return (retval); } --HPS From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 7 11:52:52 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B47E7DF4 for ; Sun, 7 Jun 2015 11:52:52 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 920E013A8 for ; Sun, 7 Jun 2015 11:52:52 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=d1bfNmuijitKM2q4PAyZgyXANXsz/14VkndlheZGA6s=; b=iN0nzxtSmYZE5L+tRUX8JrhVuwvgYte52jNmS05zXv9PKHZEtZgR5ntNd6QF12AXB+sJDuQHmpx8bINcrK7iV95eXKsIuj6wRSgfCHmLTqg/cCGeU71eUhO7d/DyqAMTPWho+GSQm4w6jdtmltu7HAFRnBNNpxzyqlQhRdutjcU=; Received: from [114.124.31.137] (port=40298 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.85) (envelope-from ) id 1Z1Z8D-001NIE-Uz; Sun, 07 Jun 2015 05:52:50 -0600 Date: Sun, 7 Jun 2015 19:52:45 +0800 From: Erich Dollansky To: Hans Petter Selasky Cc: "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search Message-ID: <20150607195245.62dc191f@B85M-HD3-0.alogt.com> In-Reply-To: <5573EA5E.40806@selasky.org> References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 11:52:52 -0000 Hi Hanns, On Sun, 07 Jun 2015 08:53:18 +0200 Hans Petter Selasky wrote: > On 06/07/15 02:13, Erich Dollansky wrote: > > > > If you like the binary way I could give you the sources for the > > complete family following your style to replace the older functions. > > > I think this is not the fastest way to do it. You first find the LSB, I never thought of this as I took the code a long, long time from university and expanded it over time from 8 to 64 bits. > then you do a sumbits, which doesn't have any conditionals IF/ELSE > and performs better with the CPU pipeline. I think the software ffs() > is only used for platforms which doesn't have a hardware version btw: The code is not x86 specific. > This one is the same: > From my libmbin: > > int ffs(int value) > { > int retval = mbin_sumbits32(mbin_lsb32(value) - 1); > if (retval == 32) > retval = 0; > else > retval++; > return (retval); > } > Where is this? Should this also be in 10.1? What I saw is that all CPUs except ARM uses the software version. Erich From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 7 13:55:04 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 371F7A30 for ; Sun, 7 Jun 2015 13:55:04 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0D691F25 for ; Sun, 7 Jun 2015 13:55:03 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t57Dssax090508 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 7 Jun 2015 16:54:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t57Dssax090508 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t57DssNK090507; Sun, 7 Jun 2015 16:54:54 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 7 Jun 2015 16:54:53 +0300 From: Konstantin Belousov To: Erich Dollansky Cc: Hans Petter Selasky , "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search Message-ID: <20150607135453.GH2499@kib.kiev.ua> References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150607195245.62dc191f@B85M-HD3-0.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150607195245.62dc191f@B85M-HD3-0.alogt.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 13:55:04 -0000 On Sun, Jun 07, 2015 at 07:52:45PM +0800, Erich Dollansky wrote: > What I saw is that all CPUs except ARM uses the software version [of ffs]. Without quantifiers, this statement is not true. i386 libc function ffs(3) uses bsfl instruction to do the job. Compilers know about ffs(3) and friends as well, so e.g. gcc 5.1.0 generates the following code for the given fragment: return (ffs(x) + 1); is translated to 0: 0f bc c7 bsf %edi,%eax 3: ba ff ff ff ff mov $0xffffffff,%edx 8: 0f 44 c2 cmove %edx,%eax b: 83 c0 02 add $0x2,%eax (arg in %edi, result in %eax). I wrote a patch for amd64 libc long time ago to convert ffs/fls etc to use of the bitstring instruction, but Bruce Evans argued that this would be excessive. Your patch is excessive for the similar reasons. My guess is that significantly clever compiler would recognize a pattern used by native ffs implementation and automatically use bitstring instructions. E.g., this already happens with popcnt and recent gcc/clang, I am just lazy to verify ffs. From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 7 15:01:51 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 602599E9 for ; Sun, 7 Jun 2015 15:01:51 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2102F1F4B for ; Sun, 7 Jun 2015 15:01:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (unknown [89.11.148.31]) (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 C25891FE023; Sun, 7 Jun 2015 17:01:46 +0200 (CEST) Message-ID: <55745D08.5000505@selasky.org> Date: Sun, 07 Jun 2015 17:02:32 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Erich Dollansky CC: "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150607195245.62dc191f@B85M-HD3-0.alogt.com> In-Reply-To: <20150607195245.62dc191f@B85M-HD3-0.alogt.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 15:01:51 -0000 On 06/07/15 13:52, Erich Dollansky wrote: > Hi Hanns, > > On Sun, 07 Jun 2015 08:53:18 +0200 > Hans Petter Selasky wrote: > >> On 06/07/15 02:13, Erich Dollansky wrote: >>> >>> If you like the binary way I could give you the sources for the >>> complete family following your style to replace the older functions. >>> >> I think this is not the fastest way to do it. You first find the LSB, > > I never thought of this as I took the code a long, long time from > university and expanded it over time from 8 to 64 bits. > >> then you do a sumbits, which doesn't have any conditionals IF/ELSE >> and performs better with the CPU pipeline. I think the software ffs() >> is only used for platforms which doesn't have a hardware version btw: > > The code is not x86 specific. >> > This one is the same: > >> From my libmbin: >> >> int ffs(int value) >> { >> int retval = mbin_sumbits32(mbin_lsb32(value) - 1); >> if (retval == 32) >> retval = 0; >> else >> retval++; >> return (retval); >> } >> > Where is this? Should this also be in 10.1? Hi Erich, It is currently nowhere, just in my private SVN. Would you wrap up complete patch, and I can put it into Phabricator and let more people look at it. Does your patch cover both kernel and userspace? > > What I saw is that all CPUs except ARM uses the software version. Kernel too? --HPS From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 7 16:37:25 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47451EAF for ; Sun, 7 Jun 2015 16:37:25 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 0177C1588 for ; Sun, 7 Jun 2015 16:37:25 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: by qkhg32 with SMTP id g32so66825026qkh.0 for ; Sun, 07 Jun 2015 09:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ub7p7sZLXy5JI3o/CF6vhQIuopszJ2SuHxlLXtBqyYA=; b=DJ46ffHFURNl5PVAfGPmX2BgInLdz6CWdA1+j43M8EPqQGlrAyI6OmvmmXzyjdK00i btOApBJPWHe8OAvGekoHw+XOp4vjsYgUOxWg4/FDY4eUzO9rh6PXfPbU30UlMKSAQrVP +d3B7tFGVmNoMxQofFDJeYBEo+3IyY/NNIFS0tomFYl+ynBxfsC0SDlh5n8kkVVySQxv atq0ABJCiwnmRx5Ma3lxiCdFTUp84bREvtFiCopF+Ik3JMUunEU/lLXPieeC3AABfWR8 UgoasRiIbmw+d0hKdttERdD2fGV20YT6vQaQHPWsGPdPC/8Y/Bz0ttk4TKnBXC3gfDQR /oAA== MIME-Version: 1.0 X-Received: by 10.229.185.68 with SMTP id cn4mr15761139qcb.12.1433695043803; Sun, 07 Jun 2015 09:37:23 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.96.106.234 with HTTP; Sun, 7 Jun 2015 09:37:23 -0700 (PDT) In-Reply-To: <20150607135453.GH2499@kib.kiev.ua> References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150607195245.62dc191f@B85M-HD3-0.alogt.com> <20150607135453.GH2499@kib.kiev.ua> Date: Sun, 7 Jun 2015 09:37:23 -0700 X-Google-Sender-Auth: oQLOZVQ2kvTOEuP88jc2p7QVRwg Message-ID: Subject: Re: allow ffs & co. a binary search From: Davide Italiano To: Konstantin Belousov Cc: Erich Dollansky , Hans Petter Selasky , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 16:37:25 -0000 On Sun, Jun 7, 2015 at 6:54 AM, Konstantin Belousov wrote: > On Sun, Jun 07, 2015 at 07:52:45PM +0800, Erich Dollansky wrote: >> What I saw is that all CPUs except ARM uses the software version [of ffs]. > > Without quantifiers, this statement is not true. i386 libc function ffs(3) > uses bsfl instruction to do the job. Compilers know about ffs(3) and friends > as well, so e.g. gcc 5.1.0 generates the following code for the given > fragment: > return (ffs(x) + 1); > is translated to > 0: 0f bc c7 bsf %edi,%eax > 3: ba ff ff ff ff mov $0xffffffff,%edx > 8: 0f 44 c2 cmove %edx,%eax > b: 83 c0 02 add $0x2,%eax > (arg in %edi, result in %eax). > > I wrote a patch for amd64 libc long time ago to convert ffs/fls etc to use > of the bitstring instruction, but Bruce Evans argued that this would be > excessive. Your patch is excessive for the similar reasons. > > My guess is that significantly clever compiler would recognize a pattern > used by native ffs implementation and automatically use bitstring > instructions. E.g., this already happens with popcnt and recent > gcc/clang, I am just lazy to verify ffs. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" Clang trunk to the best of my knowledgde hasn't a way to recognize ffs() pattern. http://llvm.org/docs/doxygen/html/LoopIdiomRecognize_8cpp_source.html I can't comment about gcc as long as I'm not familiar with the implementation. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 7 16:44:19 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDF80FBB for ; Sun, 7 Jun 2015 16:44:19 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::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 874E4176F for ; Sun, 7 Jun 2015 16:44:19 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: by qkhq76 with SMTP id q76so66873764qkh.2 for ; Sun, 07 Jun 2015 09:44:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=O2+DfmSP4jfRLxodknwoMEXMYNjbUz74Av/2fo1c+tY=; b=rJAuJXBOUej6jvt4WpwKD8MsP6lKrBCsfFIF93y4W8Iru9XeVFgGl6LW/5slXgdXyQ Xy+DbNJ+R91uy+QEZTY7wRh0Yf5HjMs8EIq69Gd/3GLFul1odNQ8TSu1Vfuim5w+oWxO ErgqJfbNfJHJOGisWPFQy4+ULpoX/CEDld2OUOnwFKdtLdVda/KWGzs6ANCBEEvHSPCX Ar15FN+Wd/QZbN1Bd1Ek9LoijNe1MhP5Qlbj50v4lBBaQ54MndLX3Zfx9V4B9IDhjWE0 QlHrPl4L/xOkIcyd7FLc7JR+tUBjdsr4ywiaDtWw9Zy0ZSsjZl5CojO4XA+WigMPSGmU fTlw== MIME-Version: 1.0 X-Received: by 10.140.145.202 with SMTP id 193mr15684402qhr.43.1433695458648; Sun, 07 Jun 2015 09:44:18 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.96.106.234 with HTTP; Sun, 7 Jun 2015 09:44:18 -0700 (PDT) In-Reply-To: References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150607195245.62dc191f@B85M-HD3-0.alogt.com> <20150607135453.GH2499@kib.kiev.ua> Date: Sun, 7 Jun 2015 09:44:18 -0700 X-Google-Sender-Auth: NDJ9u3YLOJXje3zKAYM74EO0tmc Message-ID: Subject: Re: allow ffs & co. a binary search From: Davide Italiano To: Konstantin Belousov Cc: Erich Dollansky , Hans Petter Selasky , "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 16:44:20 -0000 On Sun, Jun 7, 2015 at 9:37 AM, Davide Italiano wrote: > On Sun, Jun 7, 2015 at 6:54 AM, Konstantin Belousov wrote: >> On Sun, Jun 07, 2015 at 07:52:45PM +0800, Erich Dollansky wrote: >>> What I saw is that all CPUs except ARM uses the software version [of ffs]. >> >> Without quantifiers, this statement is not true. i386 libc function ffs(3) >> uses bsfl instruction to do the job. Compilers know about ffs(3) and friends >> as well, so e.g. gcc 5.1.0 generates the following code for the given >> fragment: >> return (ffs(x) + 1); >> is translated to >> 0: 0f bc c7 bsf %edi,%eax >> 3: ba ff ff ff ff mov $0xffffffff,%edx >> 8: 0f 44 c2 cmove %edx,%eax >> b: 83 c0 02 add $0x2,%eax >> (arg in %edi, result in %eax). >> >> I wrote a patch for amd64 libc long time ago to convert ffs/fls etc to use >> of the bitstring instruction, but Bruce Evans argued that this would be >> excessive. Your patch is excessive for the similar reasons. >> >> My guess is that significantly clever compiler would recognize a pattern >> used by native ffs implementation and automatically use bitstring >> instructions. E.g., this already happens with popcnt and recent >> gcc/clang, I am just lazy to verify ffs. >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > Clang trunk to the best of my knowledgde hasn't a way to recognize > ffs() pattern. > http://llvm.org/docs/doxygen/html/LoopIdiomRecognize_8cpp_source.html > I can't comment about gcc as long as I'm not familiar with the implementation. > > -- > Davide > > "There are no solved problems; there are only problems that are more > or less solved" -- Henri Poincare Also, FWIW, for the fragment provided by Kostik, clang seems to generate more instructions than gcc does, I'll bring this upstream. 0: 0f bc c7 bsf %edi,%eax 3: b9 20 00 00 00 mov $0x20,%ecx 8: 0f 45 c8 cmovne %eax,%ecx b: 83 c1 02 add $0x2,%ecx e: 85 ff test %edi,%edi 10: b8 01 00 00 00 mov $0x1,%eax 15: 0f 45 c1 cmovne %ecx,%eax -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 7 17:23:24 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C85A2E18; Sun, 7 Jun 2015 17:23:24 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 7A6E5108B; Sun, 7 Jun 2015 17:23:24 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by qkhg32 with SMTP id g32so67166447qkh.0; Sun, 07 Jun 2015 10:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=FLgpC/30tLv+15xAFqH1gdyobelGN3I5cEz9J9A4DwA=; b=CxVHraAw0PLhPHgvmP07Oe02I/wLiQBOM2ciWeXtM0cv4nJF7S/pTxf+aCRyKoIWHZ qJGK610Pf6o3Dg5plLPOSct/bvUCOQ9KOtKS8/ULYcwzNKdi8/vc7b1J9sYfrNJHL+d6 yaamvh5qHJ6StCIer2TSeLe7zYTket3s6LZ5hGd2UYFqU0JqgHlU59IDNMddM8fK77UW sD2DddrJun4Orvkup0ZGUpbixQtl9fzAdRypWIw7HWrm4ebhczEQZCkx5deYp81t3yig kw/cucaJvURQ7RdBdnEeKfR6dsvq9lu/mn5eNPgEf7345XFZEyw14cKhBZ3mV+7qcy13 SwRg== X-Received: by 10.55.33.155 with SMTP id f27mr25455260qki.106.1433697803544; Sun, 07 Jun 2015 10:23:23 -0700 (PDT) Received: from ?IPv6:2601:8:ab80:7d6:49db:f026:baaa:c5fb? ([2601:8:ab80:7d6:49db:f026:baaa:c5fb]) by mx.google.com with ESMTPSA id v13sm97191qhd.31.2015.06.07.10.23.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 07 Jun 2015 10:23:23 -0700 (PDT) Subject: Re: allow ffs & co. a binary search Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AC44E2AA-682D-4D46-B7CF-4BC54434962F"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Garrett Cooper In-Reply-To: Date: Sun, 7 Jun 2015 10:23:20 -0700 Cc: Konstantin Belousov , Hans Petter Selasky , "freebsd-hackers@freebsd.org" , Erich Dollansky Message-Id: References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150607195245.62dc191f@B85M-HD3-0.alogt.com> <20150607135453.GH2499@kib.kiev.ua> To: Davide Italiano X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 17:23:24 -0000 --Apple-Mail=_AC44E2AA-682D-4D46-B7CF-4BC54434962F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 7, 2015, at 9:44, Davide Italiano wrote: > On Sun, Jun 7, 2015 at 9:37 AM, Davide Italiano = wrote: >> On Sun, Jun 7, 2015 at 6:54 AM, Konstantin Belousov = wrote: >>> On Sun, Jun 07, 2015 at 07:52:45PM +0800, Erich Dollansky wrote: >>>> What I saw is that all CPUs except ARM uses the software version = [of ffs]. >>>=20 >>> Without quantifiers, this statement is not true. i386 libc function = ffs(3) >>> uses bsfl instruction to do the job. Compilers know about ffs(3) = and friends >>> as well, so e.g. gcc 5.1.0 generates the following code for the = given >>> fragment: >>> return (ffs(x) + 1); >>> is translated to >>> 0: 0f bc c7 bsf %edi,%eax >>> 3: ba ff ff ff ff mov $0xffffffff,%edx >>> 8: 0f 44 c2 cmove %edx,%eax >>> b: 83 c0 02 add $0x2,%eax >>> (arg in %edi, result in %eax). >>>=20 >>> I wrote a patch for amd64 libc long time ago to convert ffs/fls etc = to use >>> of the bitstring instruction, but Bruce Evans argued that this would = be >>> excessive. Your patch is excessive for the similar reasons. >>>=20 >>> My guess is that significantly clever compiler would recognize a = pattern >>> used by native ffs implementation and automatically use bitstring >>> instructions. E.g., this already happens with popcnt and recent >>> gcc/clang, I am just lazy to verify ffs. >>=20 >> Clang trunk to the best of my knowledgde hasn't a way to recognize >> ffs() pattern. >> http://llvm.org/docs/doxygen/html/LoopIdiomRecognize_8cpp_source.html >> I can't comment about gcc as long as I'm not familiar with the = implementation. >=20 > Also, FWIW, for the fragment provided by Kostik, clang seems to > generate more instructions than gcc does, > I'll bring this upstream. >=20 > 0: 0f bc c7 bsf %edi,%eax > 3: b9 20 00 00 00 mov $0x20,%ecx > 8: 0f 45 c8 cmovne %eax,%ecx > b: 83 c1 02 add $0x2,%ecx > e: 85 ff test %edi,%edi > 10: b8 01 00 00 00 mov $0x1,%eax > 15: 0f 45 c1 cmovne %ecx,%eax Hi Davide, Could you please post a) the clang/gcc compiler versions and b) = the compilation options used when producing the snippet? clang -O0 for = instance produces a lot of code, whereas -O2 produces considerably less = (to the point that there have been a lot of complaints at $work about = being able to debug clang-compiled programs because things have all been = optimized out). Thanks! -NGie --Apple-Mail=_AC44E2AA-682D-4D46-B7CF-4BC54434962F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJVdH4IAAoJEMZr5QU6S73e4UMH/3Ht4x4Vne1LFWrtW2kg4l04 rTJcOuUSBNJ/+VIG7GGvYWtNhXjRdDeNWJtl2tn5xh+GI4MozTz5dyejk78qg+l0 K59FypR1RoViTr3+jxj6scZpvm8mBUHZY5N+iIvgf2q4hRM78SFMrlk2i7Yu2JHk ZRWIDqpXNXGb1oJsKVA52D3NoAQfx9saXaqIibHB3oevI6sr6KD7oIFNkrLKuHLm 0aAxLz/H4FSnt+C7M2O7rqS54zxxzp+ag5LeBssnFutglqjSK7tYPsMbekNOkf7n dcJMnbGanBd5tklNRJNfYagZNixgE3R5QQJs5/mad6pEIwhX2KMrijPHmPITz5E= =ZLPe -----END PGP SIGNATURE----- --Apple-Mail=_AC44E2AA-682D-4D46-B7CF-4BC54434962F-- From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 7 17:43:04 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50EF1EB for ; Sun, 7 Jun 2015 17:43:04 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 078E915A5 for ; Sun, 7 Jun 2015 17:43:04 +0000 (UTC) (envelope-from davide.italiano@gmail.com) Received: by qkx62 with SMTP id 62so67244188qkx.3 for ; Sun, 07 Jun 2015 10:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=VJ2LToVLSThIcfR8iC9D+cKK3SmOlBQu63UsvS9pUiw=; b=RdMts/vdH6wBWuA1du8jSjP4KEOAlDdafX8eH0ocwLL7zT+lRbiDvrBbtMFqyCvtVZ /f1cLO/LQpsOdTKd/f62gPn0lvKIl2z0OzPwgbtghoLkbzQrLkLlHCW1/dP822J9jihx mjevJkGQR3qKUwgdjXS8YfgEilDQuttetdxlOEDvKpiM7zLuzyHvn+7LRirPvu/TS1mA mOxqxBbuan8ZVWW35/FihYKjLHsCXSdjA/l01UcdYJjqCCA8xWnPfEpyCoNv2AAjsVV/ ngTneqEiH8SX9Zmd/n7SmERMOPW/GxAsN8y2HVTbcNgwYDXUOONbeuG6goXeL02los0m Kzxw== MIME-Version: 1.0 X-Received: by 10.55.50.141 with SMTP id y135mr25213721qky.91.1433698983136; Sun, 07 Jun 2015 10:43:03 -0700 (PDT) Sender: davide.italiano@gmail.com Received: by 10.96.106.234 with HTTP; Sun, 7 Jun 2015 10:43:03 -0700 (PDT) In-Reply-To: References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150607195245.62dc191f@B85M-HD3-0.alogt.com> <20150607135453.GH2499@kib.kiev.ua> Date: Sun, 7 Jun 2015 10:43:03 -0700 X-Google-Sender-Auth: lvyheMGgorn0Z2l9OJmSHqqiTLk Message-ID: Subject: Re: allow ffs & co. a binary search From: Davide Italiano To: Garrett Cooper Cc: Konstantin Belousov , Hans Petter Selasky , "freebsd-hackers@freebsd.org" , Erich Dollansky Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 17:43:04 -0000 On Sun, Jun 7, 2015 at 10:23 AM, Garrett Cooper wro= te: > On Jun 7, 2015, at 9:44, Davide Italiano wrote: > >> On Sun, Jun 7, 2015 at 9:37 AM, Davide Italiano wro= te: >>> On Sun, Jun 7, 2015 at 6:54 AM, Konstantin Belousov wrote: >>>> On Sun, Jun 07, 2015 at 07:52:45PM +0800, Erich Dollansky wrote: >>>>> What I saw is that all CPUs except ARM uses the software version [of = ffs]. >>>> >>>> Without quantifiers, this statement is not true. i386 libc function ff= s(3) >>>> uses bsfl instruction to do the job. Compilers know about ffs(3) and = friends >>>> as well, so e.g. gcc 5.1.0 generates the following code for the given >>>> fragment: >>>> return (ffs(x) + 1); >>>> is translated to >>>> 0: 0f bc c7 bsf %edi,%eax >>>> 3: ba ff ff ff ff mov $0xffffffff,%edx >>>> 8: 0f 44 c2 cmove %edx,%eax >>>> b: 83 c0 02 add $0x2,%eax >>>> (arg in %edi, result in %eax). >>>> >>>> I wrote a patch for amd64 libc long time ago to convert ffs/fls etc to= use >>>> of the bitstring instruction, but Bruce Evans argued that this would b= e >>>> excessive. Your patch is excessive for the similar reasons. >>>> >>>> My guess is that significantly clever compiler would recognize a patte= rn >>>> used by native ffs implementation and automatically use bitstring >>>> instructions. E.g., this already happens with popcnt and recent >>>> gcc/clang, I am just lazy to verify ffs. >>> >>> Clang trunk to the best of my knowledgde hasn't a way to recognize >>> ffs() pattern. >>> http://llvm.org/docs/doxygen/html/LoopIdiomRecognize_8cpp_source.html >>> I can't comment about gcc as long as I'm not familiar with the implemen= tation. >> >> Also, FWIW, for the fragment provided by Kostik, clang seems to >> generate more instructions than gcc does, >> I'll bring this upstream. >> >> 0: 0f bc c7 bsf %edi,%eax >> 3: b9 20 00 00 00 mov $0x20,%ecx >> 8: 0f 45 c8 cmovne %eax,%ecx >> b: 83 c1 02 add $0x2,%ecx >> e: 85 ff test %edi,%edi >> 10: b8 01 00 00 00 mov $0x1,%eax >> 15: 0f 45 c1 cmovne %ecx,%eax > > Hi Davide, > Could you please post a) the clang/gcc compiler versions and b) t= he compilation options used when producing the snippet? clang -O0 for insta= nce produces a lot of code, whereas -O2 produces considerably less (to the = point that there have been a lot of complaints at $work about being able to= debug clang-compiled programs because things have all been optimized out). > Thanks! > -NGie About the version, as previously mentioned, it's trunk (as per today), r239= 228. About the flags, it's -O3 -fomit-frame-pointer. I'm able to obtain the same code Kostik got w/ gcc and the same flag, so I definitely feel like clang does something different, which result in more instructions, and I'll investigate further on this. Thanks, --=20 Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare From owner-freebsd-hackers@FreeBSD.ORG Sun Jun 7 23:47:56 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56343B99 for ; Sun, 7 Jun 2015 23:47:56 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 331691926 for ; Sun, 7 Jun 2015 23:47:56 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=INYp7HK41wtzr6Sztgq8ap5XSTwRvxVQ6aBxWPwK2+4=; b=gbk1YVeUdwD9QOx090RDs+LZKUBVL9zYgGHb+X2mR/KAWZciUpG3ZRYdz3qcMIXhA90RqR8whkD/dVnXE09Ap5oa1KNMTzZmXmbPaPFY4uDDTqnDDuNpKi15sfp34VcdUXPyZ5cfjhBmdEiXxnVUkNXa6rqXAeFnCFQ+CjPfelA=; Received: from [114.121.131.162] (port=30897 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.85) (envelope-from ) id 1Z1kID-001Un1-Jy; Sun, 07 Jun 2015 17:47:54 -0600 Date: Mon, 8 Jun 2015 07:47:47 +0800 From: Erich Dollansky To: Hans Petter Selasky Cc: "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search Message-ID: <20150608074747.55be51c8@B85M-HD3-0.alogt.com> In-Reply-To: <55745D08.5000505@selasky.org> References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150607195245.62dc191f@B85M-HD3-0.alogt.com> <55745D08.5000505@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 23:47:56 -0000 Hi Hans, On Sun, 07 Jun 2015 17:02:32 +0200 Hans Petter Selasky wrote: > On 06/07/15 13:52, Erich Dollansky wrote: > > On Sun, 07 Jun 2015 08:53:18 +0200 > > Hans Petter Selasky wrote: > >> On 06/07/15 02:13, Erich Dollansky wrote: > >>> If you like the binary way I could give you the sources for the > >>> complete family following your style to replace the older > >>> functions. > >>> > >> I think this is not the fastest way to do it. You first find the > >> LSB, > > > > I never thought of this as I took the code a long, long time from > > university and expanded it over time from 8 to 64 bits. > > > >> then you do a sumbits, which doesn't have any conditionals IF/ELSE > >> and performs better with the CPU pipeline. I think the software > >> ffs() is only used for platforms which doesn't have a hardware > >> version btw: > > > > The code is not x86 specific. > >> > > This one is the same: > > > >> From my libmbin: > >> > >> int ffs(int value) > >> { > >> int retval = mbin_sumbits32(mbin_lsb32(value) - 1); > >> if (retval == 32) > >> retval = 0; > >> else > >> retval++; > >> return (retval); > >> } > >> > > Where is this? Should this also be in 10.1? > > It is currently nowhere, just in my private SVN. Would you wrap up > complete patch, and I can put it into Phabricator and let more people > look at it. Does your patch cover both kernel and userspace? > I can do this but will need some help especially in the coding style department. Can I e-mail the source first to see if it matches the formal requirements? > > > > What I saw is that all CPUs except ARM uses the software version. > > Kernel too? I did not check. Erich From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 8 09:25:55 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BCA29EA4; Mon, 8 Jun 2015 09:25:55 +0000 (UTC) (envelope-from phk@freebsd.org) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 808631206; Mon, 8 Jun 2015 09:25:55 +0000 (UTC) (envelope-from phk@freebsd.org) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 279853BB88; Mon, 8 Jun 2015 09:25:48 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id t589PlPt029843; Mon, 8 Jun 2015 09:25:48 GMT (envelope-from phk@freebsd.org) To: Hans Petter Selasky cc: Julian Elischer , Ian Lepore , "freebsd-hackers@freebsd.org" Subject: Re: Make "sys/queue.h" usable with C++ In-reply-to: <55734622.5090808@selasky.org> From: "Poul-Henning Kamp" References: <52D7D302.3090403@bitfrost.no> <1679.1389879981@critter.freebsd.dk> <52D7E674.4010501@bitfrost.no> <16417.1389881910@critter.freebsd.dk> <1389890913.1230.64.camel@revolution.hippie.lan> <52D8C268.1080009@bitfrost.no> <52D95A8E.3000006@freebsd.org> <55734622.5090808@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <29841.1433755547.1@critter.freebsd.dk> Date: Mon, 08 Jun 2015 09:25:47 +0000 Message-ID: <29842.1433755547@critter.freebsd.dk> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 09:25:55 -0000 -------- In message <55734622.5090808@selasky.org>, Hans Petter Selasky writes: >I've come up with a smarter way to do it, which I think is more >acceptable. Simply we need to duplicate the ENTRY and HEAD macros for >use with classes. Then use __typeof() where pointers are referred inside >these macros. That's it. > >Can you checkout: > >https://reviews.freebsd.org/D2745 > >And give some comments? It's really a decision if we want to spread dependence on typeof() to /usr/include isn't it ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 8 19:30:04 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4492F667 for ; Mon, 8 Jun 2015 19:30:04 +0000 (UTC) (envelope-from bsdcon@bsdcon.com.br) Received: from leviatan.freebsdbrasil.com.br (leviatan.freebsdbrasil.com.br [177.10.156.9]) (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 95ACB1A98 for ; Mon, 8 Jun 2015 19:30:02 +0000 (UTC) (envelope-from bsdcon@bsdcon.com.br) Received: (qmail 5931 invoked from network); 8 Jun 2015 16:29:43 -0300 Received: from unknown (HELO [200.129.11.217]) (contato@bsdcon.com.br@[200.129.11.217]) (envelope-sender ) by capeta.freebsdbrasil.com.br (qmail-ldap-1.03) with SMTP for ; 8 Jun 2015 16:29:43 -0300 Message-ID: <5575ED27.4080501@bsdcon.com.br> Date: Mon, 08 Jun 2015 16:29:43 -0300 From: BSDCon Brasil 2015 Organization: BSDCon Brasil User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: BSDCon Brazil 2015 - 2nd Call for Papers Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 19:30:04 -0000 INTRODUCTION BSDCon Brazil (http://www.bsdcon.com.br) is the Brazilian BSD powered and flavored conference held in Brazil. The first edition was in 2003 (https://www.freebsd.org/events/events2003.html) and it brought together a great mix of *BSD developers and users for a nice blend of both developer-centric and user-centric presentations, and activities. The 2015 edition will be even more fun! This year BSDCon Brazil will be held from 9-10th October 2015, in Fortaleza (CE). The very first edition with people coming to Brazil from all around the globe! OFFICIAL CALL We've got extra room for the conference! Now we are proudly requesting proposals for even more presentations. We do not require academic or formal papers. If you wish to submit a formal paper, you are welcome to, but it is not required. Presentations are expected to be 45~60 minutes and are to be delivered in Portuguese (preferred), Spanish or English. The proposals presentation should be written with a very strong technical content bias. Proposals of a business development or marketing nature are not appropriate for this venue and will be rejected! Topics of interest to the conference include, but are not limited to: [*] Automation & Embedded Systems [*] Best Current Practices [*] Continuous Integration [*] Database Management Systems [*] Device Drivers [*] Documentation & Translation [*] Filesystems [*] Firewall & Routing [*] Getting Started to *BSD Systems [*] High Availability [*] Internet of Things (IoT) [*] IPv6 [*] Kernel Internals [*] Logging & Monitoring [*] Network Applications [*] Orchestration [*] Performance [*] Privacy & Security [*] Third-Party Applications Management [*] Virtualization [*] VoIP [*] Wireless Transmissions We are waiting to read what you got! Please send all proposals to: submissions@bsdcon.com.br The proposals should contain a short and concise text description. The submission should also include a short CV of the speaker and an estimate of the expected travel expenses. - Do not forget to tell us your host city; - If your quotes are in another currency than Brazilian Reais, please inform the day you got the prices for proper conversion. - We've got speakers who will pay for their own flight; if you would like to do the same, your name/company will be listed as sponsor. SCHEDULE Proposals Acceptance May 8th 2015 ----- BEGINS June 10th 2015 --- END OF PHASE 1 June 30th 2015 --- END OF PHASE 2 Contact to Accepted Proposals Authors July 10th 2015 --- CONTACT WITH PHASE 1's AUTHORS July 20th 2015 --- CONTACT WITH PHASE 2's AUTHORS NOTES * If your talk is accepted, you are expected to present your talk in person; * Speakers do not register or pay conference fees; * We can pay for speakers flight and accommodation; * You pay for your own food and drink; * There will be a digital projector available in each lecture room. -- BSDCon Brasil 2015 http://www.bsdcon.com.br http://twitter.com/bsdcon_br From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 8 22:59:41 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CA7CB6FC for ; Mon, 8 Jun 2015 22:59:41 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::103]) by mx1.freebsd.org (Postfix) with ESMTP id 235DD1E3F for ; Mon, 8 Jun 2015 22:59:41 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [192.168.3.88] (c-24-218-80-235.hsd1.ma.comcast.net [24.218.80.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id D3DC21AE7 for ; Mon, 8 Jun 2015 22:59:38 +0000 (UTC) Message-ID: <55761E58.6040704@metricspace.net> Date: Mon, 08 Jun 2015 18:59:36 -0400 From: Eric McCorkle User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: EFI ZFS loader successful load and boot References: <5560F4FE.4030502@metricspace.net> <5560F743.9000507@metricspace.net> <7CD9D028-8BCE-4361-966B-140642BAE341@metricspace.net> <98598C0A-D09A-4BC7-A15C-5422BBA2EE4C@gmail.com> In-Reply-To: <98598C0A-D09A-4BC7-A15C-5422BBA2EE4C@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9mXtQcxIOTeBwJJoa4u3PEkLG2JCiT7t8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 22:59:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9mXtQcxIOTeBwJJoa4u3PEkLG2JCiT7t8 Content-Type: multipart/mixed; boundary="------------040508010102090007040903" This is a multi-part message in MIME format. --------------040508010102090007040903 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable OK, finally got time to turn the knobs. This patch should make it through a buildworld. I will at some point add functionality to boot1 to actually check the partition type GUIDs. That aside, this is ready for testing, and I've been EFI-booting a ZFS partition from GRUB using this patch for a while now. On 05/26/2015 10:22 AM, Garrett Cooper wrote: >=20 >> On May 26, 2015, at 05:34, Eric McCorkle wrote:= >> >> Updates: with a new kernel, and the vt terminal, this works fine.=20 >> >> Unfortunately, the patch doesn't seem to work with a buildworld build = (I was doing make from within the directories). This is related to a hack= I do of copying zfs.c into the efi loader directory so it can be built w= ith fPIC. The build system seems to get tripped up in mkdep as a result. = >> >> Could someone with more knowledge of the build system give me some poi= nters here? Otherwise, is all set for testing. >=20 > DPSRCS/CLEANFILES are probably the knobs you're looking for... > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 --------------040508010102090007040903 Content-Type: text/x-patch; name="zfsefi.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="zfsefi.diff" Index: sys/boot/efi/boot1/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/boot1/Makefile (revision 283525) +++ sys/boot/efi/boot1/Makefile (working copy) @@ -13,7 +13,7 @@ INTERNALPROG=3D =20 # architecture-specific loader code -SRCS=3D boot1.c self_reloc.c start.S +SRCS=3D boot1.c self_reloc.c start.S ufs_module.c zfs_module.c =20 CFLAGS+=3D -I. CFLAGS+=3D -I${.CURDIR}/../include @@ -20,6 +20,8 @@ CFLAGS+=3D -I${.CURDIR}/../include/${MACHINE} CFLAGS+=3D -I${.CURDIR}/../../../contrib/dev/acpica/include CFLAGS+=3D -I${.CURDIR}/../../.. +CFLAGS+=3D -I${.CURDIR}/../../zfs/ +CFLAGS+=3D -I${.CURDIR}/../../../cddl/boot/zfs/ =20 # Always add MI sources and REGULAR efi loader bits .PATH: ${.CURDIR}/../loader/arch/${MACHINE} Index: sys/boot/efi/boot1/boot1.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/boot1/boot1.c (revision 283525) +++ sys/boot/efi/boot1/boot1.c (working copy) @@ -5,6 +5,8 @@ * All rights reserved. * Copyright (c) 2014 Nathan Whitehorn * All rights reserved. + * Copyright (c) 2014 Eric McCorkle + * All rights reverved. * * Redistribution and use in source and binary forms are freely * permitted provided that the above copyright notice and this @@ -21,7 +23,6 @@ __FBSDID("$FreeBSD$"); =20 #include -#include #include #include =20 @@ -28,6 +29,8 @@ #include #include =20 +#include "boot_module.h" + #define _PATH_LOADER "/boot/loader.efi" #define _PATH_KERNEL "/boot/kernel/kernel" =20 @@ -41,14 +44,20 @@ u_int sp_size; }; =20 +static const boot_module_t* const boot_modules[] =3D +{ +#ifdef ZFS_EFI_BOOT + &zfs_module, +#endif +#ifdef UFS_EFI_BOOT + &ufs_module +#endif +}; + +#define NUM_BOOT_MODULES (sizeof(boot_modules) / sizeof(boot_module_t*))= + static const char digits[] =3D "0123456789abcdef"; =20 -static void panic(const char *fmt, ...) __dead2; -static int printf(const char *fmt, ...); -static int putchar(char c, void *arg); -static int vprintf(const char *fmt, va_list ap); -static int vsnprintf(char *str, size_t sz, const char *fmt, va_list ap);= - static int __printf(const char *fmt, putc_func_t *putc, void *arg, va_li= st ap); static int __putc(char c, void *arg); static int __puts(const char *s, putc_func_t *putc, void *arg); @@ -62,9 +71,80 @@ static EFI_SYSTEM_TABLE *systab; static EFI_HANDLE *image; =20 -static void -bcopy(const void *src, void *dst, size_t len) + +void* Malloc(size_t len, const char* file, int line) { + void* out; + if (systab->BootServices->AllocatePool(EfiLoaderData, + len, &out) !=3D + EFI_SUCCESS) { + printf("Can't allocate memory pool\n"); + return NULL; + } + return out; +} + +char* strcpy(char* dst, const char* src) { + for(int i =3D 0; src[i]; i++) + dst[i] =3D src[i]; + + return dst; +} + +char* strchr(const char* s, int c) { + for(int i =3D 0; s[i]; i++) + if (s[i] =3D=3D c) + return (char*)(s + i); + + return NULL; +} + +int strncmp(const char *a, const char *b, size_t len) +{ + for (int i =3D 0; i < len; i++) + if(a[i] =3D=3D '\0' && b[i] =3D=3D '\0') { + return 0; + } else if(a[i] < b[i]) { + return -1; + } else if(a[i] > b[i]) { + return 1; + } + + return 0; +} + +char* strdup(const char* s) { + int len; + + for(len =3D 1; s[len]; len++); + + char* out =3D malloc(len); + + for(int i =3D 0; i < len; i++) + out[i] =3D s[i]; + + return out; +} + +int bcmp(const void *a, const void *b, size_t len) +{ + const char *sa =3D a; + const char *sb =3D b; + + for (int i =3D 0; i < len; i++) + if(sa[i] !=3D sb[i]) + return 1; + + return 0; +} + +int memcmp(const void *a, const void *b, size_t len) +{ + return bcmp(a, b, len); +} + +void bcopy(const void *src, void *dst, size_t len) +{ const char *s =3D src; char *d =3D dst; =20 @@ -72,23 +152,24 @@ *d++ =3D *s++; } =20 -static void -memcpy(void *dst, const void *src, size_t len) +void* memcpy(void *dst, const void *src, size_t len) { bcopy(src, dst, len); + return dst; } =20 -static void -bzero(void *b, size_t len) + +void* memset(void *b, int val, size_t len) { char *p =3D b; =20 while (len-- !=3D 0) - *p++ =3D 0; + *p++ =3D val; + + return b; } =20 -static int -strcmp(const char *s1, const char *s2) +int strcmp(const char *s1, const char *s2) { for (; *s1 =3D=3D *s2 && *s1; s1++, s2++) ; @@ -95,30 +176,99 @@ return ((u_char)*s1 - (u_char)*s2); } =20 +int putchr(char c, void *arg) +{ + CHAR16 buf[2]; + + if (c =3D=3D '\n') { + buf[0] =3D '\r'; + buf[1] =3D 0; + systab->ConOut->OutputString(systab->ConOut, buf); + } + buf[0] =3D c; + buf[1] =3D 0; + systab->ConOut->OutputString(systab->ConOut, buf); + return (1); +} + static EFI_GUID BlockIoProtocolGUID =3D BLOCK_IO_PROTOCOL; static EFI_GUID DevicePathGUID =3D DEVICE_PATH_PROTOCOL; +static EFI_GUID ConsoleControlGUID =3D EFI_CONSOLE_CONTROL_PROTOCOL_GUID= ; static EFI_GUID LoadedImageGUID =3D LOADED_IMAGE_PROTOCOL; -static EFI_GUID ConsoleControlGUID =3D EFI_CONSOLE_CONTROL_PROTOCOL_GUID= ; =20 -static EFI_BLOCK_IO *bootdev; -static EFI_DEVICE_PATH *bootdevpath; -static EFI_HANDLE *bootdevhandle; +#define MAX_DEVS 128 =20 -EFI_STATUS efi_main(EFI_HANDLE Ximage, EFI_SYSTEM_TABLE* Xsystab) +void try_load(const boot_module_t* const mod, + const dev_info_t devs[], + size_t ndevs) { - EFI_HANDLE handles[128]; + int idx; + size_t bufsize; + void* const buffer =3D mod->load(devs, ndevs, _PATH_LOADER, &idx= , &bufsize); + EFI_HANDLE loaderhandle; + EFI_LOADED_IMAGE *loaded_image; + + if (NULL =3D=3D buffer) { + printf("Could not load file\n"); + return; + } + //printf("Loaded file %s, image at %p\n" + // "Attempting to load as bootable image...", + // _PATH_LOADER, image); + if (systab->BootServices->LoadImage(TRUE, image, devs[idx].devpa= th, + buffer, bufsize, &loaderhand= le) !=3D + EFI_SUCCESS) { + //printf("failed\n"); + return; + } + //printf("success\n" + // "Preparing to execute image..."); + + if (systab->BootServices->HandleProtocol(loaderhandle, + &LoadedImageGUID, + (VOID**)&loaded_image) = !=3D + EFI_SUCCESS) { + //printf("failed\n"); + return; + } + + //printf("success\n"); + + loaded_image->DeviceHandle =3D devs[idx].devhandle; + + //printf("Image prepared, attempting to execute\n"); + // XXX Set up command args first + if (systab->BootServices->StartImage(loaderhandle, NULL, NULL) != =3D + EFI_SUCCESS) { + //printf("Failed to execute loader\n"); + return; + } + //printf("Shouldn't be here!\n"); +} + +void efi_main(EFI_HANDLE Ximage, EFI_SYSTEM_TABLE* Xsystab) +{ + EFI_HANDLE handles[MAX_DEVS]; + dev_info_t module_devs[NUM_BOOT_MODULES][MAX_DEVS]; + size_t dev_offsets[NUM_BOOT_MODULES]; EFI_BLOCK_IO *blkio; - UINTN i, nparts =3D sizeof(handles), cols, rows, max_dim, best_mode; + UINTN nparts =3D sizeof(handles); EFI_STATUS status; EFI_DEVICE_PATH *devpath; EFI_BOOT_SERVICES *BS; EFI_CONSOLE_CONTROL_PROTOCOL *ConsoleControl =3D NULL; SIMPLE_TEXT_OUTPUT_INTERFACE *conout =3D NULL; - char *path =3D _PATH_LOADER; =20 + // Basic initialization systab =3D Xsystab; image =3D Ximage; =20 + for(int i =3D 0; i < NUM_BOOT_MODULES; i++) + { + dev_offsets[i] =3D 0; + } + + // Set up the console, so printf works. BS =3D systab->BootServices; status =3D BS->LocateProtocol(&ConsoleControlGUID, NULL, (VOID **)&ConsoleControl); @@ -128,10 +278,14 @@ /* * Reset the console and find the best text mode. */ + UINTN max_dim; + UINTN best_mode; + UINTN cols; + UINTN rows; conout =3D systab->ConOut; conout->Reset(conout, TRUE); max_dim =3D best_mode =3D 0; - for (i =3D 0; ; i++) { + for (int i =3D 0; ; i++) { status =3D conout->QueryMode(conout, i, &cols, &rows); if (EFI_ERROR(status)) @@ -141,6 +295,7 @@ best_mode =3D i; } } + if (max_dim > 0) conout->SetMode(conout, best_mode); conout->EnableCursor(conout, TRUE); @@ -147,206 +302,94 @@ conout->ClearScreen(conout); =20 printf("\n" - ">> FreeBSD EFI boot block\n"); - printf(" Loader path: %s\n", path); + ">> FreeBSD ZFS-enabled EFI boot block\n"); + printf(" Loader path: %s\n\n", _PATH_LOADER); =20 + printf(" Initializing modules:"); + for(int i =3D 0; i < NUM_BOOT_MODULES; i++) + { + if (NULL !=3D boot_modules[i]) + { + printf(" %s", boot_modules[i]->name); + boot_modules[i]->init(image, systab, BS); + } + } + putchr('\n', NULL); + + // Get all the device handles status =3D systab->BootServices->LocateHandle(ByProtocol, &BlockIoProtocolGUID, NULL, &nparts, handles); nparts /=3D sizeof(handles[0]); + //printf(" Scanning %lu device handles\n", nparts); =20 - for (i =3D 0; i < nparts; i++) { + // Scan all partitions, probing with all modules. + for (int i =3D 0; i < nparts; i++) { + dev_info_t devinfo; + + // Figure out if we're dealing with an actual partition status =3D systab->BootServices->HandleProtocol(handles[i], &DevicePathGUID, (void **)&devpath); - if (EFI_ERROR(status)) + if (EFI_ERROR(status)) { + //printf(" Not a device path protocol\n")= ; continue; + } =20 - while (!IsDevicePathEnd(NextDevicePathNode(devpath))) + while (!IsDevicePathEnd(NextDevicePathNode(devpath))) { + //printf(" Advancing to next device\n"); devpath =3D NextDevicePathNode(devpath); + } =20 status =3D systab->BootServices->HandleProtocol(handles[i], &BlockIoProtocolGUID, (void **)&blkio); - if (EFI_ERROR(status)) + if (EFI_ERROR(status)) { + //printf(" Not a block device\n"); continue; + } =20 - if (!blkio->Media->LogicalPartition) + if (!blkio->Media->LogicalPartition) { + //printf(" Logical partition\n"); continue; + } =20 - if (domount(devpath, blkio, 1) >=3D 0) - break; - } + // Setup devinfo + devinfo.dev =3D blkio; + devinfo.devpath =3D devpath; + devinfo.devhandle =3D handles[i]; + devinfo.devdata =3D NULL; =20 - if (i =3D=3D nparts) - panic("No bootable partition found"); - - bootdevhandle =3D handles[i]; - load(path); - - panic("Load failed"); - - return EFI_SUCCESS; -} - -static int -dskread(void *buf, u_int64_t lba, int nblk) -{ - EFI_STATUS status; - int size; - - lba =3D lba / (bootdev->Media->BlockSize / DEV_BSIZE); - size =3D nblk * DEV_BSIZE; - status =3D bootdev->ReadBlocks(bootdev, bootdev->Media->MediaId, lba, - size, buf); - - if (EFI_ERROR(status)) - return (-1); - - return (0); -} - -#include "ufsread.c" - -static ssize_t -fsstat(ufs_ino_t inode) -{ -#ifndef UFS2_ONLY - static struct ufs1_dinode dp1; - ufs1_daddr_t addr1; -#endif -#ifndef UFS1_ONLY - static struct ufs2_dinode dp2; -#endif - static struct fs fs; - static ufs_ino_t inomap; - char *blkbuf; - void *indbuf; - size_t n, nb, size, off, vboff; - ufs_lbn_t lbn; - ufs2_daddr_t addr2, vbaddr; - static ufs2_daddr_t blkmap, indmap; - u_int u; - - blkbuf =3D dmadat->blkbuf; - indbuf =3D dmadat->indbuf; - if (!dsk_meta) { - inomap =3D 0; - for (n =3D 0; sblock_try[n] !=3D -1; n++) { - if (dskread(dmadat->sbbuf, sblock_try[n] / DEV_BSIZE, - SBLOCKSIZE / DEV_BSIZE)) - return -1; - memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); - if (( -#if defined(UFS1_ONLY) - fs.fs_magic =3D=3D FS_UFS1_MAGIC -#elif defined(UFS2_ONLY) - (fs.fs_magic =3D=3D FS_UFS2_MAGIC && - fs.fs_sblockloc =3D=3D sblock_try[n]) -#else - fs.fs_magic =3D=3D FS_UFS1_MAGIC || - (fs.fs_magic =3D=3D FS_UFS2_MAGIC && - fs.fs_sblockloc =3D=3D sblock_try[n]) -#endif - ) && - fs.fs_bsize <=3D MAXBSIZE && - fs.fs_bsize >=3D sizeof(struct fs)) - break; - } - if (sblock_try[n] =3D=3D -1) { - printf("Not ufs\n"); - return -1; - } - dsk_meta++; - } else - memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); - if (!inode) - return 0; - if (inomap !=3D inode) { - n =3D IPERVBLK(&fs); - if (dskread(blkbuf, INO_TO_VBA(&fs, n, inode), DBPERVBLK)) - return -1; - n =3D INO_TO_VBO(n, inode); -#if defined(UFS1_ONLY) - memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, - sizeof(struct ufs1_dinode)); -#elif defined(UFS2_ONLY) - memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, - sizeof(struct ufs2_dinode)); -#else - if (fs.fs_magic =3D=3D FS_UFS1_MAGIC) - memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, - sizeof(struct ufs1_dinode)); - else - memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, - sizeof(struct ufs2_dinode)); -#endif - inomap =3D inode; - fs_off =3D 0; - blkmap =3D indmap =3D 0; + // Run through each module, see if it can load this part= ition + for (int j =3D 0; j < NUM_BOOT_MODULES; j++ ) + { + if (NULL !=3D boot_modules[j] && + boot_modules[j]->probe(&devinfo)) + { + // If it can, save it to the device list= for + // that module + module_devs[j][dev_offsets[j]++] =3D dev= info; + } + } } - size =3D DIP(di_size); - n =3D size - fs_off; - return (n); -} =20 -static struct dmadat __dmadat; + // Select a partition to boot. We do this by trying each + // module in order. + for (int i =3D 0; i < NUM_BOOT_MODULES; i++) + { + if (NULL !=3D boot_modules[i]) + { + //printf(" Trying to load from %lu %s partitio= ns\n", + // dev_offsets[i], boot_modules[i]->name);= + try_load(boot_modules[i], module_devs[i], + dev_offsets[i]); + //printf(" Failed\n"); + } + } =20 -static int -domount(EFI_DEVICE_PATH *device, EFI_BLOCK_IO *blkio, int quiet) -{ - - dmadat =3D &__dmadat; - bootdev =3D blkio; - bootdevpath =3D device; - if (fsread(0, NULL, 0)) { - if (!quiet) - printf("domount: can't read superblock\n"); - return (-1); - } - if (!quiet) - printf("Succesfully mounted UFS filesystem\n"); - return (0); + // If we get here, we're out of luck... + panic("No bootable partitions found!"); } =20 -static void -load(const char *fname) +void panic(const char *fmt, ...) { - ufs_ino_t ino; - EFI_STATUS status; - EFI_HANDLE loaderhandle; - EFI_LOADED_IMAGE *loaded_image; - void *buffer; - size_t bufsize; - - if ((ino =3D lookup(fname)) =3D=3D 0) { - printf("File %s not found\n", fname); - return; - } - - bufsize =3D fsstat(ino); - status =3D systab->BootServices->AllocatePool(EfiLoaderData, - bufsize, &buffer); - fsread(ino, buffer, bufsize); - - /* XXX: For secure boot, we need our own loader here */ - status =3D systab->BootServices->LoadImage(TRUE, image, bootdevpath, - buffer, bufsize, &loaderhandle); - if (EFI_ERROR(status)) - printf("LoadImage failed with error %lx\n", status); - - status =3D systab->BootServices->HandleProtocol(loaderhandle, - &LoadedImageGUID, (VOID**)&loaded_image); - if (EFI_ERROR(status)) - printf("HandleProtocol failed with error %lx\n", status); - - loaded_image->DeviceHandle =3D bootdevhandle; - - status =3D systab->BootServices->StartImage(loaderhandle, NULL, NULL); - if (EFI_ERROR(status)) - printf("StartImage failed with error %lx\n", status); -} - -static void -panic(const char *fmt, ...) -{ char buf[128]; va_list ap; =20 @@ -358,50 +401,25 @@ while (1) {} } =20 -static int -printf(const char *fmt, ...) +int printf(const char *fmt, ...) { va_list ap; int ret; =20 - /* Don't annoy the user as we probe for partitions */ - if (strcmp(fmt,"Not ufs\n") =3D=3D 0) - return 0; =20 va_start(ap, fmt); - ret =3D vprintf(fmt, ap); + ret =3D __printf(fmt, putchr, 0, ap); va_end(ap); return (ret); } =20 -static int -putchar(char c, void *arg) +void vprintf(const char *fmt, va_list ap) { - CHAR16 buf[2]; - - if (c =3D=3D '\n') { - buf[0] =3D '\r'; - buf[1] =3D 0; - systab->ConOut->OutputString(systab->ConOut, buf); - } - buf[0] =3D c; - buf[1] =3D 0; - systab->ConOut->OutputString(systab->ConOut, buf); - return (1); + __printf(fmt, putchr, 0, ap); } =20 -static int -vprintf(const char *fmt, va_list ap) +int vsnprintf(char *str, size_t sz, const char *fmt, va_list ap) { - int ret; - - ret =3D __printf(fmt, putchar, 0, ap); - return (ret); -} - -static int -vsnprintf(char *str, size_t sz, const char *fmt, va_list ap) -{ struct sp_data sp; int ret; =20 Index: sys/boot/efi/boot1/boot_module.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/boot1/boot_module.h (revision 0) +++ sys/boot/efi/boot1/boot_module.h (working copy) @@ -0,0 +1,60 @@ +#ifndef _BOOT_MODULE_H_ +#define _BOOT_MODULE_H_ + +#include + +#include +#include +#include + +#define UFS_EFI_BOOT 1 +#define ZFS_EFI_BOOT 1 + +// EFI device info +typedef struct dev_info_t +{ + EFI_BLOCK_IO *dev; + EFI_DEVICE_PATH *devpath; + EFI_HANDLE *devhandle; + void *devdata; +} dev_info_t; + +// A boot loader module. This is a standard interface for filesystem +// modules in the EFI system. +typedef struct boot_module_t +{ + const char* const name; + + // Initialize the module. + void (* const init)(EFI_HANDLE image, + EFI_SYSTEM_TABLE* systab, + EFI_BOOT_SERVICES *bootsrv); + + // Check to see if curr_dev is a device that this module can han= dle. + bool (* const probe)(dev_info_t* dev); + + // Select the best out of a set of devices that probe indicated = were + // loadable, and load it. + void* (* const load)(const dev_info_t devs[], + size_t ndevs, + const char* loader_path, + int* idxref, + size_t* bufsizeref); +} boot_module_t; + +// Standard boot modules +#ifdef UFS_EFI_BOOT +extern const boot_module_t ufs_module; +#endif +#ifdef ZFS_EFI_BOOT +extern const boot_module_t zfs_module; +#endif + +// Functions available to modules +extern int strcmp(const char *s1, const char *s2); +extern void bcopy(const void *src, void *dst, size_t len); +extern void panic(const char *fmt, ...) __dead2; +extern int printf(const char *fmt, ...); +extern int vsnprintf(char *str, size_t sz, const char *fmt, va_list ap);= + +#endif Property changes on: sys/boot/efi/boot1/boot_module.h ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/efi/boot1/ufs_module.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/boot1/ufs_module.c (revision 0) +++ sys/boot/efi/boot1/ufs_module.c (working copy) @@ -0,0 +1,210 @@ +/*- + * Copyright (c) 1998 Robert Nordier + * All rights reserved. + * Copyright (c) 2001 Robert Drehmel + * All rights reserved. + * Copyright (c) 2014 Nathan Whitehorn + * All rights reserved. + * Copyright (c) 2015 Eric McCorkle + * All rights reverved. + * + * Redistribution and use in source and binary forms are freely + * permitted provided that the above copyright notice and this + * paragraph and the following disclaimer are duplicated in all + * such forms. + * + * This software is provided "AS IS" and without any express or + * implied warranties, including, without limitation, the implied + * warranties of merchantability and fitness for a particular + * purpose. + */ +#include +#include + +#include +#include + +#include + +#include "boot_module.h" + +static EFI_HANDLE image; +static EFI_SYSTEM_TABLE* systab; +static EFI_BOOT_SERVICES *bootsrv; +static dev_info_t devinfo; +static EFI_GUID LoadedImageGUID =3D LOADED_IMAGE_PROTOCOL; + +static int +dskread(void *buf, u_int64_t lba, int nblk) +{ + EFI_STATUS status; + int size; + + lba =3D lba / (devinfo.dev->Media->BlockSize / DEV_BSIZE); + size =3D nblk * DEV_BSIZE; + status =3D devinfo.dev->ReadBlocks(devinfo.dev, + devinfo.dev->Media->MediaId, lb= a, + size, buf); + + if (EFI_ERROR(status)) + return (-1); + + return (0); +} + +#include "ufsread.c" + +static ssize_t +fsstat(ufs_ino_t inode) +{ +#ifndef UFS2_ONLY + static struct ufs1_dinode dp1; + ufs1_daddr_t addr1; +#endif +#ifndef UFS1_ONLY + static struct ufs2_dinode dp2; +#endif + static struct fs fs; + static ufs_ino_t inomap; + char *blkbuf; + void *indbuf; + size_t n, nb, size, off, vboff; + ufs_lbn_t lbn; + ufs2_daddr_t addr2, vbaddr; + static ufs2_daddr_t blkmap, indmap; + u_int u; + + blkbuf =3D dmadat->blkbuf; + indbuf =3D dmadat->indbuf; + if (!dsk_meta) { + inomap =3D 0; + for (n =3D 0; sblock_try[n] !=3D -1; n++) { + if (dskread(dmadat->sbbuf, sblock_try[n] / DEV_BSIZE, + SBLOCKSIZE / DEV_BSIZE)) + return -1; + memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); + if (( +#if defined(UFS1_ONLY) + fs.fs_magic =3D=3D FS_UFS1_MAGIC +#elif defined(UFS2_ONLY) + (fs.fs_magic =3D=3D FS_UFS2_MAGIC && + fs.fs_sblockloc =3D=3D sblock_try[n]) +#else + fs.fs_magic =3D=3D FS_UFS1_MAGIC || + (fs.fs_magic =3D=3D FS_UFS2_MAGIC && + fs.fs_sblockloc =3D=3D sblock_try[n]) +#endif + ) && + fs.fs_bsize <=3D MAXBSIZE && + fs.fs_bsize >=3D sizeof(struct fs)) + break; + } + if (sblock_try[n] =3D=3D -1) { + return -1; + } + dsk_meta++; + } else + memcpy(&fs, dmadat->sbbuf, sizeof(struct fs)); + if (!inode) + return 0; + if (inomap !=3D inode) { + n =3D IPERVBLK(&fs); + if (dskread(blkbuf, INO_TO_VBA(&fs, n, inode), DBPERVBLK)) + return -1; + n =3D INO_TO_VBO(n, inode); +#if defined(UFS1_ONLY) + memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, + sizeof(struct ufs1_dinode)); +#elif defined(UFS2_ONLY) + memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, + sizeof(struct ufs2_dinode)); +#else + if (fs.fs_magic =3D=3D FS_UFS1_MAGIC) + memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, + sizeof(struct ufs1_dinode)); + else + memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, + sizeof(struct ufs2_dinode)); +#endif + inomap =3D inode; + fs_off =3D 0; + blkmap =3D indmap =3D 0; + } + size =3D DIP(di_size); + n =3D size - fs_off; + return (n); +} + +static struct dmadat __dmadat; + +static bool +probe(dev_info_t* const dev) +{ + devinfo =3D *dev; + dmadat =3D &__dmadat; + if (fsread(0, NULL, 0)) { + return 0; + } + return 1; +} + +static void* +try_load(const dev_info_t dev, + const char* const loader_path, + size_t* const bufsizeref) +{ + ufs_ino_t ino; + EFI_STATUS status; + void *buffer; + size_t bufsize; + + devinfo =3D dev; + if ((ino =3D lookup(loader_path)) =3D=3D 0) { + printf("File %s not found\n", loader_path); + return NULL; + } + + bufsize =3D fsstat(ino); + *bufsizeref =3D bufsize; + status =3D systab->BootServices->AllocatePool(EfiLoaderData, + bufsize, &buffer); + fsread(ino, buffer, bufsize); + return buffer; +} + +static void* +load(const dev_info_t devs[], + const size_t ndevs, + const char* const loader_path, + int* const idxref, + size_t* const bufsizeref) +{ + for(int i =3D 0; i < ndevs; i++) + { + void* const out =3D try_load(devs[i], loader_path, bufsiz= eref); + if (out !=3D NULL) + { + *idxref =3D i; + return out; + } + } + return NULL; +} + + +static void init(EFI_HANDLE xImage, + EFI_SYSTEM_TABLE* xSystab, + EFI_BOOT_SERVICES * xBootsrv) +{ + image =3D xImage; + systab =3D xSystab; + bootsrv =3D xBootsrv; +} + +const boot_module_t ufs_module =3D +{ + .name =3D "UFS", + .init =3D init, + .probe =3D probe, + .load =3D load +}; Property changes on: sys/boot/efi/boot1/ufs_module.c ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/efi/boot1/zfs_module.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/boot1/zfs_module.c (revision 0) +++ sys/boot/efi/boot1/zfs_module.c (working copy) @@ -0,0 +1,201 @@ +/* Copyright (c) 2015 Eric McCorkle. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * + * 2. Redistributions in binary form must reproduce the above + * copyright notice, this list of conditions and the following + * disclaimer in the documentation and/or other materials provided + * with the distribution. + * + * 3. Neither the name of the author nor the names of any contributors + * may be used to endorse or promote products derived from this + * software without specific prior written permission. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHORS AND CONTRIBUTORS ``AS IS'' + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED + * TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A + * PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR + * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, + * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT + * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND + * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, + * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT + * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + */ +#include +#include +#include + +#include +#include +#include + +#include + +#include "boot_module.h" + +#include "libzfs.h" +#include "zfsimpl.c" + +#define PATH_CONFIG "/boot/config" +#define PATH_DOTCONFIG "/boot/.config" + +static EFI_HANDLE image; +static EFI_SYSTEM_TABLE* systab; +static EFI_BOOT_SERVICES *bootsrv; + +static int +vdev_read(vdev_t * const vdev, + void * const priv, + const off_t off, + void * const buf, + const size_t bytes) +{ + const dev_info_t* const devinfo =3D (const dev_info_t*) priv; + const off_t lba =3D off / devinfo->dev->Media->BlockSize; + const EFI_STATUS status =3D + devinfo->dev->ReadBlocks(devinfo->dev, + devinfo->dev->Media->MediaId, + lba, bytes, buf); + if (EFI_ERROR(status)) + return (-1); + + return (0); +} + +static bool probe(dev_info_t* const dev) +{ + spa_t* spa; + int result =3D vdev_probe(vdev_read, dev, &spa); + dev->devdata =3D spa; + + return result =3D=3D 0; +} + +static void* try_load(const dev_info_t devinfo, + const char* const loader_path, + size_t* const bufsizeref) +{ + spa_t *spa =3D devinfo.devdata; + struct zfsmount zfsmount; + dnode_phys_t dn; + bool autoboot =3D true; + + if (zfs_spa_init(spa) !=3D 0) { + // Mount failed. Don't report this loudly + return NULL; + } + + // First, try mounting the ZFS volume + if (zfs_mount(spa, 0, &zfsmount) !=3D 0) { + // Mount failed. Don't report this loudly + return NULL; + } + + //vdev_t * const primary_vdev =3D spa_get_primary_vdev(spa); + + if (zfs_lookup(&zfsmount, loader_path, &dn) !=3D 0) { + return NULL; + } + + struct stat st; + if (zfs_dnode_stat(spa, &dn, &st)) { + return NULL; + } + + const size_t bufsize =3D st.st_size; + void* buffer; + EFI_STATUS status; + + *bufsizeref =3D bufsize; + + if (systab->BootServices->AllocatePool(EfiLoaderData, + bufsize, &buffer) !=3D + EFI_SUCCESS) { + return NULL; + } + + if (dnode_read(spa, &dn, 0, buffer, bufsize) < 0) { + return NULL; + } + + return buffer; +} + +static int zfs_mount_ds(const char * const dsname, + struct zfsmount * const zfsmount, + spa_t ** const spa) +{ + uint64_t newroot; + spa_t *newspa; + char *q; + + q =3D strchr(dsname, '/'); + if (q) + *q++ =3D '\0'; + newspa =3D spa_find_by_name(dsname); + if (newspa =3D=3D NULL) { + printf("\nCan't find ZFS pool %s\n", dsname); + return -1; + } + + if (zfs_spa_init(newspa)) + return -1; + + newroot =3D 0; + if (q) { + if (zfs_lookup_dataset(newspa, q, &newroot)) { + printf("\nCan't find dataset %s in ZFS pool %s\n= ", + q, newspa->spa_name); + return -1; + } + } + if (zfs_mount(newspa, newroot, zfsmount)) { + printf("\nCan't mount ZFS dataset\n"); + return -1; + } + *spa =3D newspa; + return (0); +} + +static void* load(const dev_info_t devs[], + const size_t ndevs, + const char* const loader_path, + int* const idxref, + size_t* const bufsizeref) +{ + for(int i =3D 0; i < ndevs; i++) { + void* const out =3D try_load(devs[i], loader_path, bufsi= zeref); + if (out !=3D NULL) + { + *idxref =3D i; + return out; + } + } + return NULL; +} + +static void init(EFI_HANDLE xImage, + EFI_SYSTEM_TABLE* xSystab, + EFI_BOOT_SERVICES * xBootsrv) +{ + image =3D xImage; + systab =3D xSystab; + bootsrv =3D xBootsrv; + zfs_init(); +} + +const boot_module_t zfs_module =3D +{ + .name =3D "ZFS", + .init =3D init, + .probe =3D probe, + .load =3D load +}; Property changes on: sys/boot/efi/boot1/zfs_module.c ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=3D%H \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Index: sys/boot/efi/include/efilib.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/include/efilib.h (revision 283525) +++ sys/boot/efi/include/efilib.h (working copy) @@ -43,7 +43,8 @@ =20 int efi_register_handles(struct devsw *, EFI_HANDLE *, EFI_HANDLE *, int= ); EFI_HANDLE efi_find_handle(struct devsw *, int); -int efi_handle_lookup(EFI_HANDLE, struct devsw **, int *); +void efi_handle_update_dev(EFI_HANDLE, struct devsw *, int, uint64_t); +int efi_handle_lookup(EFI_HANDLE, struct devsw **, int *, uint64_t *); =20 int efi_status_to_errno(EFI_STATUS); time_t efi_time(EFI_TIME *); Index: sys/boot/efi/libefi/handles.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/libefi/handles.c (revision 283525) +++ sys/boot/efi/libefi/handles.c (working copy) @@ -35,6 +35,7 @@ EFI_HANDLE alias; struct devsw *dev; int unit; + uint64_t extra; }; =20 struct entry *entry; @@ -78,8 +79,28 @@ return (NULL); } =20 +void efi_handle_update_dev(const EFI_HANDLE handle, + struct devsw * const dev, + int unit, + uint64_t guid) +{ + int idx; + + for (idx =3D 0; idx < nentries; idx++) { + if (entry[idx].handle !=3D handle) + continue; + entry[idx].dev =3D dev; + entry[idx].unit =3D unit; + entry[idx].alias =3D NULL; + entry[idx].extra =3D guid; + } +} + int -efi_handle_lookup(EFI_HANDLE h, struct devsw **dev, int *unit) +efi_handle_lookup(EFI_HANDLE h, + struct devsw **dev, + int *unit, + uint64_t *extra) { int idx; =20 @@ -90,6 +111,8 @@ *dev =3D entry[idx].dev; if (unit !=3D NULL) *unit =3D entry[idx].unit; + if (extra !=3D NULL) + *extra =3D entry[idx].extra; return (0); } return (ENOENT); Index: sys/boot/efi/loader/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/loader/Makefile (revision 283525) +++ sys/boot/efi/loader/Makefile (working copy) @@ -12,6 +12,8 @@ PROG=3D loader.sym INTERNALPROG=3D =20 +#LIBZFSBOOT=3D ${.OBJDIR}/../../zfs/libzfsboot.a + .PATH: ${.CURDIR}/../../efi/loader # architecture-specific loader code SRCS=3D autoload.c \ @@ -22,8 +24,11 @@ main.c \ self_reloc.c \ smbios.c \ - vers.c + vers.c \ + ${ZFS_C} =20 +ZFS_C =3D ${.CURDIR}/../../zfs/zfs.c + .PATH: ${.CURDIR}/arch/${MACHINE} # For smbios.c .PATH: ${.CURDIR}/../../i386/libi386 @@ -36,6 +41,8 @@ CFLAGS+=3D -I${.CURDIR}/../../../contrib/dev/acpica/include CFLAGS+=3D -I${.CURDIR}/../../.. CFLAGS+=3D -I${.CURDIR}/../../i386/libi386 +CFLAGS+=3D -I${.CURDIR}/../../zfs +CFLAGS+=3D -I${.CURDIR}/../../../cddl/boot/zfs CFLAGS+=3D -DNO_PCI -DEFI =20 # make buildenv doesn't set DESTDIR, this means LIBSTAND @@ -68,7 +75,7 @@ CFLAGS+=3D -DEFI_STAGING_SIZE=3D${EFI_STAGING_SIZE} .endif =20 -# Always add MI sources=20 +# Always add MI sources .PATH: ${.CURDIR}/../../common .include "${.CURDIR}/../../common/Makefile.inc" CFLAGS+=3D -I${.CURDIR}/../../common Index: sys/boot/efi/loader/conf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/loader/conf.c (revision 283525) +++ sys/boot/efi/loader/conf.c (working copy) @@ -31,14 +31,17 @@ #include #include #include +#include "../zfs/libzfs.h" =20 struct devsw *devsw[] =3D { &efipart_dev, &efinet_dev, + &zfs_dev, NULL }; =20 struct fs_ops *file_system[] =3D { + &zfs_fsops, &dosfs_fsops, &ufs_fsops, &cd9660_fsops, Index: sys/boot/efi/loader/devicename.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/loader/devicename.c (revision 283525) +++ sys/boot/efi/loader/devicename.c (working copy) @@ -32,6 +32,7 @@ #include #include #include "bootstrap.h" +#include "libzfs.h" =20 #include #include @@ -38,7 +39,7 @@ =20 static int efi_parsedev(struct devdesc **, const char *, const char **);= =20 -/*=20 +/* * Point (dev) at an allocated device specifier for the device matching = the * path in (devspec). If it contains an explicit device specification, * use that. If not, use the default device. @@ -48,7 +49,6 @@ { struct devdesc **dev =3D (struct devdesc **)vdev; int rv; - /* * If it looks like this is just a path and no device, then * use the current device instead. @@ -61,7 +61,8 @@ } =20 /* Parse the device name off the beginning of the devspec. */ - return (efi_parsedev(dev, devspec, path)); + const int out =3D efi_parsedev(dev, devspec, path); + return out; } =20 /* @@ -87,8 +88,9 @@ int i, err; =20 /* minimum length check */ - if (strlen(devspec) < 2) + if (strlen(devspec) < 2) { return (EINVAL); + } =20 /* look for a device that matches */ for (i =3D 0; devsw[i] !=3D NULL; i++) { @@ -96,27 +98,39 @@ if (!strncmp(devspec, dv->dv_name, strlen(dv->dv_name))) break; } - if (devsw[i] =3D=3D NULL) + if (devsw[i] =3D=3D NULL) { return (ENOENT); + } + np =3D devspec + strlen(dv->dv_name); =20 - idev =3D malloc(sizeof(struct devdesc)); - if (idev =3D=3D NULL) - return (ENOMEM); + if (DEVT_ZFS =3D=3D dv->dv_type) { + idev =3D malloc(sizeof(struct zfs_devdesc)); + int out =3D zfs_parsedev((struct zfs_devdesc*)idev, np, = path); + if (0 =3D=3D out) { + *dev =3D idev; + cp =3D strchr(np + 1, ':'); + } else { + free(idev); + return out; + } + } else { + idev =3D malloc(sizeof(struct devdesc)); + if (idev =3D=3D NULL) + return (ENOMEM); =20 - idev->d_dev =3D dv; - idev->d_type =3D dv->dv_type; - idev->d_unit =3D -1; - + idev->d_dev =3D dv; + idev->d_type =3D dv->dv_type; + idev->d_unit =3D -1; + if (*np !=3D '\0' && *np !=3D ':') { + idev->d_unit =3D strtol(np, &cp, 0); + if (cp =3D=3D np) { + idev->d_unit =3D -1; + free(idev); + return (EUNIT); + } + } + } err =3D 0; - np =3D devspec + strlen(dv->dv_name); - if (*np !=3D '\0' && *np !=3D ':') { - idev->d_unit =3D strtol(np, &cp, 0); - if (cp =3D=3D np) { - idev->d_unit =3D -1; - free(idev); - return (EUNIT); - } - } if (*cp !=3D '\0' && *cp !=3D ':') { free(idev); return (EINVAL); @@ -138,10 +152,11 @@ static char buf[32]; /* XXX device length constant? */ =20 switch(dev->d_type) { + case DEVT_ZFS: + return zfs_fmtdev(dev); case DEVT_NONE: strcpy(buf, "(no device)"); break; - default: sprintf(buf, "%s%d:", dev->d_dev->dv_name, dev->d_unit); break; Index: sys/boot/efi/loader/main.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/efi/loader/main.c (revision 283525) +++ sys/boot/efi/loader/main.c (working copy) @@ -39,6 +39,7 @@ #include =20 #include "loader_efi.h" +#include "libzfs.h" =20 extern char bootprog_name[]; extern char bootprog_rev[]; @@ -45,8 +46,9 @@ extern char bootprog_date[]; extern char bootprog_maker[]; =20 -struct devdesc currdev; /* our current device */ -struct arch_switch archsw; /* MI/MD interface boundary */ +/* our current device */ +/* MI/MD interface boundary */ +struct arch_switch archsw; =20 EFI_GUID acpi =3D ACPI_TABLE_GUID; EFI_GUID acpi20 =3D ACPI_20_TABLE_GUID; @@ -61,6 +63,70 @@ EFI_GUID debugimg =3D DEBUG_IMAGE_INFO_TABLE_GUID; EFI_GUID fdtdtb =3D FDT_TABLE_GUID; =20 +static void efi_zfs_probe(void); + +static void +print_str16(const CHAR16* const str) +{ + for(int i; str[i]; i++) + { + printf("%c", str[i]); + } +} + +/* +static int +str16cmp(const CHAR16 const *a, + const char* const b) +{ + for(int i =3D 0; a[i] || b[i]; i++) + { + const CHAR16 achr =3D a[i]; + const CHAR16 bchr =3D b[i]; + if (achr < bchr) + { + return -1; + } else if (achr > bchr) + { + return 1; + } + } + return 0; +} + +// Split an arg of the form "argname=3Dargval", replacing the '=3D' with= a \0 +static CHAR16* +split_arg(CHAR16 *const str) +{ + for (int i =3D 0; str[i]; i++) + { + if ('=3D' =3D=3D str[i]) + { + str[i] =3D 0; + return str + i + 1; + } + } + return NULL; +} + +static void +handle_arg(CHAR16 *const arg) +{ + const CHAR16* const argval =3D split_arg(arg); + const CHAR16* const argname =3D arg; + + if (NULL !=3D argval) + { + printf("Unrecognized argument \""); + print_arg(argname); + printf("\n"); + } else { + printf("Unrecognized argument \""); + print_arg(argname); + printf("\n"); + } +} +*/ EFI_STATUS main(int argc, CHAR16 *argv[]) { @@ -69,7 +135,15 @@ EFI_GUID *guid; int i; =20 - /* + archsw.arch_autoload =3D efi_autoload; + archsw.arch_getdev =3D efi_getdev; + archsw.arch_copyin =3D efi_copyin; + archsw.arch_copyout =3D efi_copyout; + archsw.arch_readin =3D efi_readin; + // Note this needs to be set before ZFS init + archsw.arch_zfs_probe =3D efi_zfs_probe; + + /* * XXX Chicken-and-egg problem; we want to have console output * early, but some console attributes may depend on reading from * eg. the boot device, which we can't do yet. We can use @@ -85,13 +159,22 @@ /* * March through the device switch probing for things. */ - for (i =3D 0; devsw[i] !=3D NULL; i++) - if (devsw[i]->dv_init !=3D NULL) + for (i =3D 0; devsw[i] !=3D NULL; i++) { + if (devsw[i]->dv_init !=3D NULL) { + printf("Initializing %s\n", devsw[i]->dv_name); (devsw[i]->dv_init)(); - + } + } /* Get our loaded image protocol interface structure. */ BS->HandleProtocol(IH, &imgid, (VOID**)&img); =20 + printf("Command line arguments:"); + for(i =3D 0; i < argc; i++) { + printf(" "); + print_str16(argv[i]); + } + printf("\n"); + printf("Image base: 0x%lx\n", (u_long)img->ImageBase); printf("EFI version: %d.%02d\n", ST->Hdr.Revision >> 16, ST->Hdr.Revision & 0xffff); @@ -105,8 +188,13 @@ printf("%s, Revision %s\n", bootprog_name, bootprog_rev); printf("(%s, %s)\n", bootprog_maker, bootprog_date); =20 - efi_handle_lookup(img->DeviceHandle, &currdev.d_dev, &currdev.d_unit); - currdev.d_type =3D currdev.d_dev->dv_type; + // Handle command-line arguments + /* + for(i =3D 1; i < argc; i++) + { + handle_arg(argv[i]); + } + */ =20 /* * Disable the watchdog timer. By default the boot manager sets @@ -119,19 +207,39 @@ */ BS->SetWatchdogTimer(0, 0, 0, NULL); =20 - env_setenv("currdev", EV_VOLATILE, efi_fmtdev(&currdev), - efi_setcurrdev, env_nounset); - env_setenv("loaddev", EV_VOLATILE, efi_fmtdev(&currdev), env_noset, - env_nounset); + struct devsw *dev; + int unit; + uint64_t pool_guid; + efi_handle_lookup(img->DeviceHandle, &dev, &unit, &pool_guid); + switch (dev->dv_type) { + case DEVT_ZFS: { + struct zfs_devdesc currdev; + currdev.d_dev =3D dev; + currdev.d_unit =3D unit; + currdev.d_type =3D currdev.d_dev->dv_type; + currdev.d_opendata =3D NULL; + currdev.pool_guid =3D pool_guid; + currdev.root_guid =3D 0; + env_setenv("currdev", EV_VOLATILE, efi_fmtdev(&currdev),= + efi_setcurrdev, env_nounset); + env_setenv("loaddev", EV_VOLATILE, efi_fmtdev(&currdev),= env_noset, + env_nounset); + } break; + default: { + struct devdesc currdev; + currdev.d_dev =3D dev; + currdev.d_unit =3D unit; + currdev.d_opendata =3D NULL; + currdev.d_type =3D currdev.d_dev->dv_type; + env_setenv("currdev", EV_VOLATILE, efi_fmtdev(&currdev),= + efi_setcurrdev, env_nounset); + env_setenv("loaddev", EV_VOLATILE, efi_fmtdev(&currdev),= env_noset, + env_nounset); + } break; + } =20 setenv("LINES", "24", 1); /* optional */ =20 - archsw.arch_autoload =3D efi_autoload; - archsw.arch_getdev =3D efi_getdev; - archsw.arch_copyin =3D efi_copyin; - archsw.arch_copyout =3D efi_copyout; - archsw.arch_readin =3D efi_readin; - for (i =3D 0; i < ST->NumberOfTableEntries; i++) { guid =3D &ST->ConfigurationTable[i].VendorGuid; if (!memcmp(guid, &smbios, sizeof(EFI_GUID))) { @@ -350,7 +458,6 @@ return (CMD_OK); } =20 - COMMAND_SET(nvram, "nvram", "get or set NVRAM variables", command_nvram)= ; =20 static int @@ -402,6 +509,27 @@ return (CMD_OK); } =20 +COMMAND_SET(lszfs, "lszfs", "list child datasets of a zfs dataset", + command_lszfs); + +static int +command_lszfs(int argc, char *argv[]) +{ + int err; + + if (argc !=3D 2) { + command_errmsg =3D "wrong number of arguments"; + return (CMD_ERROR); + } + + err =3D zfs_list(argv[1]); + if (err !=3D 0) { + command_errmsg =3D strerror(err); + return (CMD_ERROR); + } + return (CMD_OK); +} + #ifdef LOADER_FDT_SUPPORT extern int command_fdt_internal(int argc, char *argv[]); =20 @@ -420,3 +548,23 @@ =20 COMMAND_SET(fdt, "fdt", "flattened device tree handling", command_fdt); #endif + +static void +efi_zfs_probe(void) +{ + EFI_BLOCK_IO *blkio; + EFI_HANDLE h; + EFI_STATUS status; + u_int unit =3D 0; + char devname[32]; + uint64_t pool_guid; + + for (int i =3D 0, h =3D efi_find_handle(&efipart_dev, 0); + h !=3D NULL; h =3D efi_find_handle(&efipart_dev, ++i)) { + snprintf(devname, sizeof devname, "%s%d:", + efipart_dev.dv_name, i); + if(0 =3D=3D zfs_probe_dev(devname, &pool_guid)) { + efi_handle_update_dev(h, &zfs_dev, unit++, pool_= guid); + } + } +} Index: sys/boot/zfs/zfs.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/boot/zfs/zfs.c (revision 283525) +++ sys/boot/zfs/zfs.c (working copy) @@ -140,7 +140,7 @@ n =3D size; if (fp->f_seekp + n > sb.st_size) n =3D sb.st_size - fp->f_seekp; -=09 + rc =3D dnode_read(spa, &fp->f_dnode, fp->f_seekp, start, n); if (rc) return (rc); @@ -493,7 +493,7 @@ } } close(pa.fd); - return (0); + return (ret); } =20 /* --------------040508010102090007040903-- --9mXtQcxIOTeBwJJoa4u3PEkLG2JCiT7t8 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 iQIcBAEBAgAGBQJVdh5gAAoJEEGB2s+NNG0FiowQAL/TyR5NDvsJyybuIMCPigzD 2eSU5raV1osBX4v7bCTBl3bcXlbmKD4qKnsdSJ3l7Uq2Dcx5N0NuhrvDwexomT2G II3uQGpiTILin6/KGuGj+TySed59QEiTEe0Ue/GMi3hIjDZ16EoHamgTU5fdraG6 92zW/wfPCQS/hmruhnw6cUnHR0p4LwCERm0GnfHhoTYnLEVmiv9PLVoyWBoViRel R4A0WIIUJGDteonwCGo0u19fqnPvOuUs2Pfw9+T+Ds6QHE6QP6gOGHbRlkJKxYD6 Ci1iRZXGiCgs7YAgyv8k1uf9JELR4IOgsde39U0nY6h6WHAtPxGbXlrMH5rLlpQ8 5+vbXK9ndBf4a/YphrjfPWAr4vX/KJbC7UXIA88vgszPe6KPl1TBD7Z3GuGpotGK snS5yvFquWyXJkXq1V23da/aaaqLquILuZKeUqqcdRs80hkvRVCk2OZPuJYxMsQ/ IZG9AqYTjKzz+wN8J+IcRGFOtxmp+4TZFsFv8eBvY8FOuUHkCCwwpszFpTOW6qRc /cpfHODnMcpqjP7dBktShVgjP5/EZ4Yh/fg4vwVGWQeJC7MQgMXA/sTqf3V0+sde /5sgATJX4QE1fvu3ORD3oJTW730GVpPHd2YeUi9juYcoZ0dU3X1sxG6Y6jypgBJX m53qFGGi1Bj8PzLWlbq7 =YoaN -----END PGP SIGNATURE----- --9mXtQcxIOTeBwJJoa4u3PEkLG2JCiT7t8-- From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 9 07:24:04 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D338A13B for ; Tue, 9 Jun 2015 07:24:04 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D3C814BB for ; Tue, 9 Jun 2015 07:24:03 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id AB2232A1939 for ; Tue, 9 Jun 2015 09:24:04 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id imGqDD26O_tp for ; Tue, 9 Jun 2015 09:24:02 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 4DCBD2A1994 for ; Tue, 9 Jun 2015 09:24:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9JFFfCpn0gFu for ; Tue, 9 Jun 2015 09:24:02 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 1E1EE2A1989 for ; Tue, 9 Jun 2015 09:24:02 +0200 (CEST) Message-ID: <55769487.20901@embedded-brains.de> Date: Tue, 09 Jun 2015 09:23:51 +0200 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: [PATCH] timecounters: Fix timehand generation read/write References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> <20150603203228.GA9774@britannica.bec.de> <2023236942.13088.1433365253885.JavaMail.zimbra@embedded-brains.de> <20150604181041.GC11630@britannica.bec.de> In-Reply-To: <20150604181041.GC11630@britannica.bec.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 07:24:05 -0000 On 04/06/15 20:10, Joerg Sonnenberger wrote: > On Wed, Jun 03, 2015 at 11:00:53PM +0200, Sebastian Huber wrote: >> In my interpretation of the C standard this is implementation defined = behaviour. See also: >> >> https://gcc.gnu.org/onlinedocs/gcc/Volatiles.html > I don't think that is nearly correct as far as any data accessibly from > global objects is concerned beside the volatile. C11 5.1.2.3 (2) and (3= ) > are the relevant clauses. An assignment to a volatile object is a > sequence point with side effects. All assignments before that sequence > point must be visible to whatever possible side effect the volatile has= . > Similar, it can implicitly change all globals, so no read can be moved > from after the sequence point to before. This is much stricter than the > normal as-if rule, since a sequence of side-effect-free operations can > be implemented anyway the compiler likes. A different interpretation > would be quite questionable. > > Note that this is all just about the rules of the C abstract machine. I= t > is not about the observable behavior of a multi-processor machine. > Whether or not TSO is enough for this purpose is a completely different > question. I didn't want to start a discussion about the C standard interpretation.=20 GCC generates code according to their documentation: https://lists.freebsd.org/pipermail/freebsd-hackers/2015-May/047778.html In case you think GCC is doing something wrong, then maybe you can file=20 a bug report for GCC. Anyway we need real memory barriers. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=E4ftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 9 08:32:02 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 01C56ED6 for ; Tue, 9 Jun 2015 08:32:02 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 804E71561 for ; Tue, 9 Jun 2015 08:32:01 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 9D5B82A1992; Tue, 9 Jun 2015 10:32:08 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id dcqT5ayYFzrs; Tue, 9 Jun 2015 10:32:08 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 0D5802A1994; Tue, 9 Jun 2015 10:32:08 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Su78R1fT8B4p; Tue, 9 Jun 2015 10:32:07 +0200 (CEST) Received: from huber-linux.eb.localhost (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTP id D95572A1990; Tue, 9 Jun 2015 10:32:07 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Cc: phk@phk.freebsd.dk, Sebastian Huber Subject: [PATCH v3] timecounters: Fix timehand generation read/write Date: Tue, 9 Jun 2015 10:31:55 +0200 Message-Id: <1433838715-22850-1-git-send-email-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 1.8.4.5 In-Reply-To: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 08:32:02 -0000 The compiler is free to re-order load/store instructions to non-volatile variables around a load/store of a volatile variable. So the volatile generation counter is insufficent. In addition tests on a Freescale T4240 platform with 24 PowerPC processors showed that real memory barriers are required. Compiler memory barriers are not enough. For the test the timehand count was reduced to one with 10000 tc_windup() calls per second. The timehand memory location was adjusted so that the th_generation field was on its own cache line. --- v2: Don't use tc_getgen() in tc_windup() since in the only writer there is no need for a read memory barrier. v3: Use atomic load/store instead of explicit memory barriers. sys/kern/kern_tc.c | 97 +++++++++++++++++++++++++++++++----------------------- 1 file changed, 56 insertions(+), 41 deletions(-) diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 9dca0e8..0711979 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include /* * A large step happens on boot. This constant detects such steps. @@ -71,7 +72,7 @@ struct timehands { struct timeval th_microtime; struct timespec th_nanotime; /* Fields not to be copied in tc_windup start with th_generation. */ - volatile u_int th_generation; + u_int th_generation; struct timehands *th_next; }; @@ -189,6 +190,20 @@ tc_delta(struct timehands *th) tc->tc_counter_mask); } +static u_int +tc_getgen(struct timehands *th) +{ + + return (atomic_load_acq_int(&th->th_generation)); +} + +static void +tc_setgen(struct timehands *th, u_int newgen) +{ + + atomic_store_rel_int(&th->th_generation, newgen); +} + /* * Functions for reading the time. We have to loop until we are sure that * the timehands that we operated on was not updated under our feet. See @@ -204,10 +219,10 @@ fbclock_binuptime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; bintime_addx(bt, th->th_scale * tc_delta(th)); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -262,9 +277,9 @@ fbclock_getbinuptime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -275,9 +290,9 @@ fbclock_getnanouptime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); bintime2timespec(&th->th_offset, tsp); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -288,9 +303,9 @@ fbclock_getmicrouptime(struct timeval *tvp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); bintime2timeval(&th->th_offset, tvp); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -301,9 +316,9 @@ fbclock_getbintime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); bintime_add(bt, &boottimebin); } @@ -315,9 +330,9 @@ fbclock_getnanotime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tsp = th->th_nanotime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -328,9 +343,9 @@ fbclock_getmicrotime(struct timeval *tvp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tvp = th->th_microtime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } #else /* !FFCLOCK */ void @@ -341,10 +356,10 @@ binuptime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; bintime_addx(bt, th->th_scale * tc_delta(th)); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -399,9 +414,9 @@ getbinuptime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -412,9 +427,9 @@ getnanouptime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); bintime2timespec(&th->th_offset, tsp); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -425,9 +440,9 @@ getmicrouptime(struct timeval *tvp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); bintime2timeval(&th->th_offset, tvp); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -438,9 +453,9 @@ getbintime(struct bintime *bt) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *bt = th->th_offset; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); bintime_add(bt, &boottimebin); } @@ -452,9 +467,9 @@ getnanotime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tsp = th->th_nanotime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } void @@ -465,9 +480,9 @@ getmicrotime(struct timeval *tvp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tvp = th->th_microtime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } #endif /* FFCLOCK */ @@ -880,11 +895,11 @@ ffclock_read_counter(ffcounter *ffcount) */ do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); ffth = fftimehands; delta = tc_delta(th); *ffcount = ffth->tick_ffcount; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); *ffcount += delta; } @@ -988,9 +1003,9 @@ dtrace_getnanotime(struct timespec *tsp) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); *tsp = th->th_nanotime; - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); } /* @@ -1028,7 +1043,7 @@ sysclock_getsnapshot(struct sysclock_snap *clock_snap, int fast) do { th = timehands; - gen = th->th_generation; + gen = tc_getgen(th); fbi->th_scale = th->th_scale; fbi->tick_time = th->th_offset; #ifdef FFCLOCK @@ -1042,7 +1057,7 @@ sysclock_getsnapshot(struct sysclock_snap *clock_snap, int fast) #endif if (!fast) delta = tc_delta(th); - } while (gen == 0 || gen != th->th_generation); + } while (gen == 0 || gen != tc_getgen(th)); clock_snap->delta = delta; clock_snap->sysclock_active = sysclock_active; @@ -1260,7 +1275,7 @@ tc_windup(void) tho = timehands; th = tho->th_next; ogen = th->th_generation; - th->th_generation = 0; + tc_setgen(th, 0); bcopy(tho, th, offsetof(struct timehands, th_generation)); /* @@ -1377,7 +1392,7 @@ tc_windup(void) */ if (++ogen == 0) ogen = 1; - th->th_generation = ogen; + tc_setgen(th, ogen); /* Go live with the new struct timehands. */ #ifdef FFCLOCK @@ -1651,13 +1666,13 @@ pps_capture(struct pps_state *pps) KASSERT(pps != NULL, ("NULL pps pointer in pps_capture")); th = timehands; - pps->capgen = th->th_generation; + pps->capgen = tc_getgen(th); pps->capth = th; #ifdef FFCLOCK pps->capffth = fftimehands; #endif pps->capcount = th->th_counter->tc_get_timecount(th->th_counter); - if (pps->capgen != th->th_generation) + if (pps->capgen != tc_getgen(th)) pps->capgen = 0; } @@ -1677,7 +1692,7 @@ pps_event(struct pps_state *pps, int event) KASSERT(pps != NULL, ("NULL pps pointer in pps_event")); /* If the timecounter was wound up underneath us, bail out. */ - if (pps->capgen == 0 || pps->capgen != pps->capth->th_generation) + if (pps->capgen == 0 || pps->capgen != tc_getgen(pps->capth)) return; /* Things would be easier with arrays. */ @@ -1727,7 +1742,7 @@ pps_event(struct pps_state *pps, int event) bintime2timespec(&bt, &ts); /* If the timecounter was wound up underneath us, bail out. */ - if (pps->capgen != pps->capth->th_generation) + if (pps->capgen != tc_getgen(pps->capth)) return; *pcount = pps->capcount; -- 1.8.4.5 From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 9 09:53:29 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 71F2F9A6; Tue, 9 Jun 2015 09:53:29 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2F8EB184D; Tue, 9 Jun 2015 09:53:28 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 5BBD51FE023; Tue, 9 Jun 2015 11:53:24 +0200 (CEST) Message-ID: <5576B7C4.2050707@selasky.org> Date: Tue, 09 Jun 2015 11:54:12 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Poul-Henning Kamp CC: "freebsd-hackers@freebsd.org" , Ian Lepore Subject: Re: Make "sys/queue.h" usable with C++ References: <52D7D302.3090403@bitfrost.no> <1679.1389879981@critter.freebsd.dk> <52D7E674.4010501@bitfrost.no> <16417.1389881910@critter.freebsd.dk> <1389890913.1230.64.camel@revolution.hippie.lan> <52D8C268.1080009@bitfrost.no> <52D95A8E.3000006@freebsd.org> <55734622.5090808@selasky.org> <29842.1433755547@critter.freebsd.dk> In-Reply-To: <29842.1433755547@critter.freebsd.dk> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 09:53:29 -0000 On 06/08/15 11:25, Poul-Henning Kamp wrote: > It's really a decision if we want to spread dependence on typeof() > to /usr/include isn't it ? Hi Paul-Henning, I'm aware about the typeof. Without typeof we would have to duplicate more of the queue macros, because in C++ you can make lists with both structs and classes. Else like some have suggested, we might drop the class/struct keyword, but that again will not work in external C sections in C++ files. --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 9 10:55:37 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3CA2D42 for ; Tue, 9 Jun 2015 10:55:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37EB41867 for ; Tue, 9 Jun 2015 10:55:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t59AtRvj012214 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 9 Jun 2015 13:55:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t59AtRvj012214 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t59AtQXB012205; Tue, 9 Jun 2015 13:55:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Jun 2015 13:55:26 +0300 From: Konstantin Belousov To: Sebastian Huber Cc: freebsd-hackers@freebsd.org, phk@phk.freebsd.dk Subject: Re: [PATCH v3] timecounters: Fix timehand generation read/write Message-ID: <20150609105526.GK2499@kib.kiev.ua> References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> <1433838715-22850-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: <1433838715-22850-1-git-send-email-sebastian.huber@embedded-brains.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 10:55:37 -0000 On Tue, Jun 09, 2015 at 10:31:55AM +0200, Sebastian Huber wrote: > The compiler is free to re-order load/store instructions to non-volatile > variables around a load/store of a volatile variable. So the volatile > generation counter is insufficent. In addition tests on a Freescale > T4240 platform with 24 PowerPC processors showed that real memory > barriers are required. Compiler memory barriers are not enough. This looks fine. The only detail I changed is that I do not see a reason to use atomics or barriers on UP machines. See the fragment at the end of the message for the exact diff. > > For the test the timehand count was reduced to one with 10000 > tc_windup() calls per second. The timehand memory location was adjusted > so that the th_generation field was on its own cache line. You mean, that the 'th_generation for its own cache line' was done for testing only ? > --- > > v2: Don't use tc_getgen() in tc_windup() since in the only writer there is no > need for a read memory barrier. > > v3: Use atomic load/store instead of explicit memory barriers. > If you do not have any comments, I will commit this version. diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 9dca0e8..fabfe03 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -189,6 +190,28 @@ tc_delta(struct timehands *th) tc->tc_counter_mask); } +static u_int +tc_getgen(struct timehands *th) +{ + +#ifdef SMP + return (atomic_load_acq_int(&th->th_generation)); +#else + return (th->th_generation); +#endif +} + +static void +tc_setgen(struct timehands *th, u_int newgen) +{ + +#ifdef SMP + atomic_store_rel_int(&th->th_generation, newgen); +#else + th->th_generation = newgen; +#endif +} + /* * Functions for reading the time. We have to loop until we are sure that * the timehands that we operated on was not updated under our feet. See From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 9 11:07:59 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 095F2F43 for ; Tue, 9 Jun 2015 11:07:59 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7134B1ACE for ; Tue, 9 Jun 2015 11:07:58 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 7E4EE2A194C; Tue, 9 Jun 2015 13:08:05 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id mg9TypOI0gpa; Tue, 9 Jun 2015 13:08:05 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 075482A1992; Tue, 9 Jun 2015 13:08:05 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 3oz4TesUzRYs; Tue, 9 Jun 2015 13:08:04 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id DEEFE2A194C; Tue, 9 Jun 2015 13:08:04 +0200 (CEST) Message-ID: <5576C90A.9010807@embedded-brains.de> Date: Tue, 09 Jun 2015 13:07:54 +0200 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Konstantin Belousov CC: freebsd-hackers@freebsd.org, phk@phk.freebsd.dk Subject: Re: [PATCH v3] timecounters: Fix timehand generation read/write References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> <1433838715-22850-1-git-send-email-sebastian.huber@embedded-brains.de> <20150609105526.GK2499@kib.kiev.ua> In-Reply-To: <20150609105526.GK2499@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 11:07:59 -0000 On 09/06/15 12:55, Konstantin Belousov wrote: > On Tue, Jun 09, 2015 at 10:31:55AM +0200, Sebastian Huber wrote: >> The compiler is free to re-order load/store instructions to non-volati= le >> variables around a load/store of a volatile variable. So the volatile >> generation counter is insufficent. In addition tests on a Freescale >> T4240 platform with 24 PowerPC processors showed that real memory >> barriers are required. Compiler memory barriers are not enough. > This looks fine. The only detail I changed is that I do not see a reas= on > to use atomics or barriers on UP machines. See the fragment at the end > of the message for the exact diff. You still need the compiler memory barriers in the UP case (at least=20 with GCC 4.9 on PowerPC), e.g. something like this: static u_int tc_getgen(struct timehands *th) { u_int gen; gen =3D th->th_generation; __compiler_membar(); return (gen); } static void tc_setgen(struct timehands *th, u_int newgen) { __compiler_membar(); th->th_generation =3D newgen; } > >> For the test the timehand count was reduced to one with 10000 >> tc_windup() calls per second. The timehand memory location was adjust= ed >> so that the th_generation field was on its own cache line. > You mean, that the 'th_generation for its own cache line' was done for > testing only ? Yes, this was done for testing only. In case the timehand data is in one=20 cache line I don't think its possible to see the error case if no=20 barriers are present. > >> --- >> >> v2: Don't use tc_getgen() in tc_windup() since in the only writer ther= e is no >> need for a read memory barrier. >> >> v3: Use atomic load/store instead of explicit memory barriers. >> > If you do not have any comments, I will commit this version. > > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c > index 9dca0e8..fabfe03 100644 > --- a/sys/kern/kern_tc.c > +++ b/sys/kern/kern_tc.c > @@ -189,6 +190,28 @@ tc_delta(struct timehands *th) > tc->tc_counter_mask); > } > =20 > +static u_int > +tc_getgen(struct timehands *th) > +{ > + > +#ifdef SMP > + return (atomic_load_acq_int(&th->th_generation)); > +#else > + return (th->th_generation); > +#endif > +} > + > +static void > +tc_setgen(struct timehands *th, u_int newgen) > +{ > + > +#ifdef SMP > + atomic_store_rel_int(&th->th_generation, newgen); > +#else > + th->th_generation =3D newgen; > +#endif > +} > + > /* > * Functions for reading the time. We have to loop until we are sure= that > * the timehands that we operated on was not updated under our feet. = See --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=E4ftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 9 11:24:04 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BB504A1; Tue, 9 Jun 2015 11:24:04 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DCA061F80; Tue, 9 Jun 2015 11:24:03 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C98781FE023; Tue, 9 Jun 2015 13:23:59 +0200 (CEST) Message-ID: <5576CCFF.5040608@selasky.org> Date: Tue, 09 Jun 2015 13:24:47 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Poul-Henning Kamp CC: "freebsd-hackers@freebsd.org" , Ian Lepore Subject: Re: Make "sys/queue.h" usable with C++ References: <52D7D302.3090403@bitfrost.no> <1679.1389879981@critter.freebsd.dk> <52D7E674.4010501@bitfrost.no> <16417.1389881910@critter.freebsd.dk> <1389890913.1230.64.camel@revolution.hippie.lan> <52D8C268.1080009@bitfrost.no> <52D95A8E.3000006@freebsd.org> <55734622.5090808@selasky.org> <29842.1433755547@critter.freebsd.dk> <5576B7C4.2050707@selasky.org> In-Reply-To: <5576B7C4.2050707@selasky.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 11:24:04 -0000 On 06/09/15 11:54, Hans Petter Selasky wrote: > On 06/08/15 11:25, Poul-Henning Kamp wrote: >> It's really a decision if we want to spread dependence on typeof() >> to /usr/include isn't it ? > > Hi Paul-Henning, > > I'm aware about the typeof. Without typeof we would have to duplicate > more of the queue macros, because in C++ you can make lists with both > structs and classes. Else like some have suggested, we might drop the > class/struct keyword, but that again will not work in external C > sections in C++ files. > Hi Paul-Henning, From what I understand typeof() is a requirement for a C++ compiler while for C compilers not. I've update the patch to only use typeof for C++ where two different types can arise, and for C compilers keep the existing way in sys/queue.h. This also should make extern "C" code work assuming that if the C++ compiler supports typeof, it also works inside the extern "C". --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 9 11:28:48 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 986AD5F7 for ; Tue, 9 Jun 2015 11:28:48 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B0791FC3 for ; Tue, 9 Jun 2015 11:28:47 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t59BSbmH040721 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 9 Jun 2015 14:28:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t59BSbmH040721 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t59BSbjA040672; Tue, 9 Jun 2015 14:28:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 9 Jun 2015 14:28:37 +0300 From: Konstantin Belousov To: Sebastian Huber Cc: freebsd-hackers@freebsd.org, phk@phk.freebsd.dk Subject: Re: [PATCH v3] timecounters: Fix timehand generation read/write Message-ID: <20150609112837.GL2499@kib.kiev.ua> References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> <1433838715-22850-1-git-send-email-sebastian.huber@embedded-brains.de> <20150609105526.GK2499@kib.kiev.ua> <5576C90A.9010807@embedded-brains.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5576C90A.9010807@embedded-brains.de> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 11:28:48 -0000 On Tue, Jun 09, 2015 at 01:07:54PM +0200, Sebastian Huber wrote: > You still need the compiler memory barriers in the UP case (at least > with GCC 4.9 on PowerPC), e.g. something like this: Fair. diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c index 9dca0e8..01c61bd 100644 --- a/sys/kern/kern_tc.c +++ b/sys/kern/kern_tc.c @@ -189,6 +190,33 @@ tc_delta(struct timehands *th) tc->tc_counter_mask); } +static u_int +tc_getgen(struct timehands *th) +{ + +#ifdef SMP + return (atomic_load_acq_int(&th->th_generation)); +#else + u_int gen; + + gen = th->th_generation; + __compiler_membar(); + return (gen); +#endif +} + +static void +tc_setgen(struct timehands *th, u_int newgen) +{ + +#ifdef SMP + atomic_store_rel_int(&th->th_generation, newgen); +#else + __compiler_membar(); + th->th_generation = newgen; +#endif +} + /* * Functions for reading the time. We have to loop until we are sure that * the timehands that we operated on was not updated under our feet. See From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 9 11:32:30 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 379F8833 for ; Tue, 9 Jun 2015 11:32:30 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D54D9120D for ; Tue, 9 Jun 2015 11:32:29 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id EF3F32A194C; Tue, 9 Jun 2015 13:32:37 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 8otGm-n9-o4c; Tue, 9 Jun 2015 13:32:37 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 95A8A2A1992; Tue, 9 Jun 2015 13:32:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HR06oQzULysh; Tue, 9 Jun 2015 13:32:37 +0200 (CEST) Received: from [192.168.96.129] (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 773E62A194C; Tue, 9 Jun 2015 13:32:37 +0200 (CEST) Message-ID: <5576CECA.7070109@embedded-brains.de> Date: Tue, 09 Jun 2015 13:32:26 +0200 From: Sebastian Huber User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Konstantin Belousov CC: freebsd-hackers@freebsd.org, phk@phk.freebsd.dk Subject: Re: [PATCH v3] timecounters: Fix timehand generation read/write References: <1433331966-27548-1-git-send-email-sebastian.huber@embedded-brains.de> <1433838715-22850-1-git-send-email-sebastian.huber@embedded-brains.de> <20150609105526.GK2499@kib.kiev.ua> <5576C90A.9010807@embedded-brains.de> <20150609112837.GL2499@kib.kiev.ua> In-Reply-To: <20150609112837.GL2499@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 11:32:30 -0000 On 09/06/15 13:28, Konstantin Belousov wrote: > On Tue, Jun 09, 2015 at 01:07:54PM +0200, Sebastian Huber wrote: >> You still need the compiler memory barriers in the UP case (at least >> with GCC 4.9 on PowerPC), e.g. something like this: > Fair. > > diff --git a/sys/kern/kern_tc.c b/sys/kern/kern_tc.c > index 9dca0e8..01c61bd 100644 > --- a/sys/kern/kern_tc.c > +++ b/sys/kern/kern_tc.c > @@ -189,6 +190,33 @@ tc_delta(struct timehands *th) > tc->tc_counter_mask); > } > =20 > +static u_int > +tc_getgen(struct timehands *th) > +{ > + > +#ifdef SMP > + return (atomic_load_acq_int(&th->th_generation)); > +#else > + u_int gen; > + > + gen =3D th->th_generation; > + __compiler_membar(); > + return (gen); > +#endif > +} > + > +static void > +tc_setgen(struct timehands *th, u_int newgen) > +{ > + > +#ifdef SMP > + atomic_store_rel_int(&th->th_generation, newgen); > +#else > + __compiler_membar(); > + th->th_generation =3D newgen; > +#endif > +} > + > /* > * Functions for reading the time. We have to loop until we are sure= that > * the timehands that we operated on was not updated under our feet. = See Thanks, this looks good to me. --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=E4ftliche Mitteilung im Sinne des EHUG. From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 9 12:56:39 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9ED052DD; Tue, 9 Jun 2015 12:56:39 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) by mx1.freebsd.org (Postfix) with ESMTP id 8011116A3; Tue, 9 Jun 2015 12:56:38 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from marvin.lab.vangyzen.net (c-73-147-253-17.hsd1.va.comcast.net [73.147.253.17]) by smtp.vangyzen.net (Postfix) with ESMTPSA id CEFAC56475; Tue, 9 Jun 2015 07:56:31 -0500 (CDT) Message-ID: <5576E28A.90808@vangyzen.net> Date: Tue, 09 Jun 2015 08:56:42 -0400 From: Eric van Gyzen User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Hans Petter Selasky , Poul-Henning Kamp CC: "freebsd-hackers@freebsd.org" , Ian Lepore Subject: Re: Make "sys/queue.h" usable with C++ References: <52D7D302.3090403@bitfrost.no> <1679.1389879981@critter.freebsd.dk> <52D7E674.4010501@bitfrost.no> <16417.1389881910@critter.freebsd.dk> <1389890913.1230.64.camel@revolution.hippie.lan> <52D8C268.1080009@bitfrost.no> <52D95A8E.3000006@freebsd.org> <55734622.5090808@selasky.org> <29842.1433755547@critter.freebsd.dk> <5576B7C4.2050707@selasky.org> In-Reply-To: <5576B7C4.2050707@selasky.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 12:56:39 -0000 On 06/09/2015 05:54, Hans Petter Selasky wrote: > On 06/08/15 11:25, Poul-Henning Kamp wrote: >> It's really a decision if we want to spread dependence on typeof() >> to /usr/include isn't it ? > > Hi Paul-Henning, > > I'm aware about the typeof. Without typeof we would have to duplicate > more of the queue macros, because in C++ you can make lists with both > structs and classes. Else like some have suggested, we might drop the > class/struct keyword, but that again will not work in external C > sections in C++ files. Did you test your claim in the last sentence? I did. Dropping the class/struct keyword in __cplusplus works fine under 'extern "C"'. If you _did_ test and it failed, please show your code to clarify any miscommunication. Dropping the class/struct keyword has the advantage that it does not change the API. It has the disadvantage that types must be declared before they're used when #including in C++ code. The latter is simply good form. There are three trivial declarations to fix in the src tree. An exprun would find those in ports and give a feel for the incidence rate in non-ports code. I would request this if anyone else is interested in this alternative. https://reviews.freebsd.org/D2767 Eric From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 9 13:14:19 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3EBB39B; Tue, 9 Jun 2015 13:14:18 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2C751C40; Tue, 9 Jun 2015 13:14:18 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6BFF11FE023; Tue, 9 Jun 2015 15:14:14 +0200 (CEST) Message-ID: <5576E6D6.8050107@selasky.org> Date: Tue, 09 Jun 2015 15:15:02 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Eric van Gyzen , Poul-Henning Kamp CC: "freebsd-hackers@freebsd.org" , Ian Lepore Subject: Re: Make "sys/queue.h" usable with C++ References: <52D7D302.3090403@bitfrost.no> <1679.1389879981@critter.freebsd.dk> <52D7E674.4010501@bitfrost.no> <16417.1389881910@critter.freebsd.dk> <1389890913.1230.64.camel@revolution.hippie.lan> <52D8C268.1080009@bitfrost.no> <52D95A8E.3000006@freebsd.org> <55734622.5090808@selasky.org> <29842.1433755547@critter.freebsd.dk> <5576B7C4.2050707@selasky.org> <5576E28A.90808@vangyzen.net> In-Reply-To: <5576E28A.90808@vangyzen.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 13:14:19 -0000 On 06/09/15 14:56, Eric van Gyzen wrote: > On 06/09/2015 05:54, Hans Petter Selasky wrote: >> On 06/08/15 11:25, Poul-Henning Kamp wrote: >>> It's really a decision if we want to spread dependence on typeof() >>> to /usr/include isn't it ? >> >> Hi Paul-Henning, >> >> I'm aware about the typeof. Without typeof we would have to duplicate >> more of the queue macros, because in C++ you can make lists with both >> structs and classes. Else like some have suggested, we might drop the >> class/struct keyword, but that again will not work in external C >> sections in C++ files. > > Did you test your claim in the last sentence? I did. Hi, Just did and found you're right, at least with recent clang. My C++ grows a little bit every now and then ... > https://reviews.freebsd.org/D2767 > Seems like at least some consensus then :-) --HPS From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 9 13:44:33 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9CFFECA5; Tue, 9 Jun 2015 13:44:33 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from mail.embedded-brains.de (host-82-135-62-35.customer.m-online.net [82.135.62.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2712C136C; Tue, 9 Jun 2015 13:44:32 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 8FC7B2A198F; Tue, 9 Jun 2015 15:44:39 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qrJooCxmXdKP; Tue, 9 Jun 2015 15:44:39 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 033402A198D; Tue, 9 Jun 2015 15:44:39 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PIYi5nwgN5Iz; Tue, 9 Jun 2015 15:44:38 +0200 (CEST) Received: from huber-linux.eb.localhost (unknown [192.168.96.129]) by mail.embedded-brains.de (Postfix) with ESMTP id D0EC22A194C; Tue, 9 Jun 2015 15:44:38 +0200 (CEST) From: Sebastian Huber To: freebsd-hackers@freebsd.org Cc: brooks@FreeBSD.org, Sebastian Huber Subject: [PATCH] Split cfi_write_block() Date: Tue, 9 Jun 2015 15:44:26 +0200 Message-Id: <1433857466-22005-1-git-send-email-sebastian.huber@embedded-brains.de> X-Mailer: git-send-email 1.8.4.5 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 13:44:33 -0000 Split cfi_write_block() function into smaller functions to ease reuse of this code in other systems. In addition this makes the high level logic of cfi_write_block() more visible. --- dev/cfi/cfi_core.c | 198 ++++++++++++++++++++++++++++++----------------------- 1 file changed, 114 insertions(+), 84 deletions(-) diff --git a/dev/cfi/cfi_core.c b/dev/cfi/cfi_core.c index 934f4cc..da1b018 100644 --- a/dev/cfi/cfi_core.c +++ b/dev/cfi/cfi_core.c @@ -634,120 +634,133 @@ cfi_wait_ready(struct cfi_softc *sc, u_int ofs, sbintime_t start, return (error); } -int -cfi_write_block(struct cfi_softc *sc) +static void +cfi_unlock_flash(struct cfi_softc *sc, u_int ofs) { - union { - uint8_t *x8; - uint16_t *x16; - uint32_t *x32; - } ptr, cpyprt; - register_t intr; - int error, i, neederase = 0; - uint32_t st; - u_int wlen; - sbintime_t start; /* Intel flash must be unlocked before modification */ switch (sc->sc_cmdset) { case CFI_VEND_INTEL_ECS: case CFI_VEND_INTEL_SCS: - cfi_write(sc, sc->sc_wrofs, CFI_INTEL_LBS); - cfi_write(sc, sc->sc_wrofs, CFI_INTEL_UB); - cfi_write(sc, sc->sc_wrofs, CFI_BCS_READ_ARRAY); + cfi_write(sc, ofs, CFI_INTEL_LBS); + cfi_write(sc, ofs, CFI_INTEL_UB); + cfi_write(sc, ofs, CFI_BCS_READ_ARRAY); break; } +} - /* Check if an erase is required. */ - for (i = 0; i < sc->sc_wrbufsz; i++) - if ((sc->sc_wrbuf[i] & sc->sc_wrbufcpy[i]) != sc->sc_wrbuf[i]) { - neederase = 1; - break; - } +static void +cfi_relock_flash(struct cfi_softc *sc, u_int ofs) +{ - if (neederase) { - intr = intr_disable(); - start = sbinuptime(); - /* Erase the block. */ - switch (sc->sc_cmdset) { - case CFI_VEND_INTEL_ECS: - case CFI_VEND_INTEL_SCS: - cfi_write(sc, sc->sc_wrofs, CFI_BCS_BLOCK_ERASE); - cfi_write(sc, sc->sc_wrofs, CFI_BCS_CONFIRM); - break; - case CFI_VEND_AMD_SCS: - case CFI_VEND_AMD_ECS: - cfi_amd_write(sc, sc->sc_wrofs, AMD_ADDR_START, - CFI_AMD_ERASE_SECTOR); - cfi_amd_write(sc, sc->sc_wrofs, 0, CFI_AMD_BLOCK_ERASE); - break; - default: - /* Better safe than sorry... */ - intr_restore(intr); - return (ENODEV); - } + /* Relock Intel flash */ + switch (sc->sc_cmdset) { + case CFI_VEND_INTEL_ECS: + case CFI_VEND_INTEL_SCS: + cfi_write(sc, ofs, CFI_INTEL_LBS); + cfi_write(sc, ofs, CFI_INTEL_LB); + cfi_write(sc, ofs, CFI_BCS_READ_ARRAY); + break; + } +} + +static int +cfi_erase_block(struct cfi_softc *sc, u_int ofs) +{ + register_t intr; + sbintime_t start; + + intr = intr_disable(); + start = sbinuptime(); + /* Erase the block. */ + switch (sc->sc_cmdset) { + case CFI_VEND_INTEL_ECS: + case CFI_VEND_INTEL_SCS: + cfi_write(sc, ofs, CFI_BCS_BLOCK_ERASE); + cfi_write(sc, ofs, CFI_BCS_CONFIRM); + break; + case CFI_VEND_AMD_SCS: + case CFI_VEND_AMD_ECS: + cfi_amd_write(sc, ofs, AMD_ADDR_START, + CFI_AMD_ERASE_SECTOR); + cfi_amd_write(sc, ofs, 0, CFI_AMD_BLOCK_ERASE); + break; + default: + /* Better safe than sorry... */ intr_restore(intr); - error = cfi_wait_ready(sc, sc->sc_wrofs, start, - CFI_TIMEOUT_ERASE); - if (error) - goto out; - } else - error = 0; + return (ENODEV); + } + intr_restore(intr); + return (cfi_wait_ready(sc, ofs, start, CFI_TIMEOUT_ERASE)); +} + +static int +cfi_program_block(struct cfi_softc *sc, u_int ofs, u_char *wrbuf, + u_char *wrbufcpy, u_int wrbufsz, int neederase) +{ + union { + uint8_t *x8; + uint16_t *x16; + uint32_t *x32; + } ptr, cpyprt; + register_t intr; + int error = 0; + uint32_t st; + u_int i, wlen; + sbintime_t start; /* Write the block using a multibyte write if supported. */ - ptr.x8 = sc->sc_wrbuf; - cpyprt.x8 = sc->sc_wrbufcpy; + ptr.x8 = wrbuf; + cpyprt.x8 = wrbufcpy; if (sc->sc_maxbuf > sc->sc_width) { switch (sc->sc_cmdset) { case CFI_VEND_INTEL_ECS: case CFI_VEND_INTEL_SCS: - for (i = 0; i < sc->sc_wrbufsz; i += wlen) { - wlen = MIN(sc->sc_maxbuf, sc->sc_wrbufsz - i); + for (i = 0; i < wrbufsz; i += wlen) { + wlen = MIN(sc->sc_maxbuf, wrbufsz - i); intr = intr_disable(); start = sbinuptime(); do { - cfi_write(sc, sc->sc_wrofs + i, + cfi_write(sc, ofs + i, CFI_BCS_BUF_PROG_SETUP); if (sbinuptime() > start + sc->sc_max_timeouts[CFI_TIMEOUT_BUFWRITE]) { - error = ETIMEDOUT; - goto out; + return (ETIMEDOUT); } - st = cfi_read(sc, sc->sc_wrofs + i); + st = cfi_read(sc, ofs + i); } while (! (st & CFI_INTEL_STATUS_WSMS)); - cfi_write(sc, sc->sc_wrofs + i, + cfi_write(sc, ofs + i, (wlen / sc->sc_width) - 1); switch (sc->sc_width) { case 1: bus_space_write_region_1(sc->sc_tag, - sc->sc_handle, sc->sc_wrofs + i, + sc->sc_handle, ofs + i, ptr.x8 + i, wlen); break; case 2: bus_space_write_region_2(sc->sc_tag, - sc->sc_handle, sc->sc_wrofs + i, + sc->sc_handle, ofs + i, ptr.x16 + i / 2, wlen / 2); break; case 4: bus_space_write_region_4(sc->sc_tag, - sc->sc_handle, sc->sc_wrofs + i, + sc->sc_handle, ofs + i, ptr.x32 + i / 4, wlen / 4); break; } - cfi_write(sc, sc->sc_wrofs + i, - CFI_BCS_CONFIRM); + cfi_write(sc, ofs + i, CFI_BCS_CONFIRM); intr_restore(intr); - error = cfi_wait_ready(sc, sc->sc_wrofs + i, - start, CFI_TIMEOUT_BUFWRITE); + error = cfi_wait_ready(sc, ofs + i, start, + CFI_TIMEOUT_BUFWRITE); if (error != 0) - goto out; + return (error); } - goto out; + return (error); default: /* Fall through to single word case */ break; @@ -756,7 +769,7 @@ cfi_write_block(struct cfi_softc *sc) } /* Write the block one byte/word at a time. */ - for (i = 0; i < sc->sc_wrbufsz; i += sc->sc_width) { + for (i = 0; i < wrbufsz; i += sc->sc_width) { /* Avoid writing unless we are actually changing bits */ if (!neederase) { @@ -787,7 +800,7 @@ cfi_write_block(struct cfi_softc *sc) switch (sc->sc_cmdset) { case CFI_VEND_INTEL_ECS: case CFI_VEND_INTEL_SCS: - cfi_write(sc, sc->sc_wrofs + i, CFI_BCS_PROGRAM); + cfi_write(sc, ofs + i, CFI_BCS_PROGRAM); break; case CFI_VEND_AMD_SCS: case CFI_VEND_AMD_ECS: @@ -797,40 +810,57 @@ cfi_write_block(struct cfi_softc *sc) switch (sc->sc_width) { case 1: bus_space_write_1(sc->sc_tag, sc->sc_handle, - sc->sc_wrofs + i, *(ptr.x8 + i)); + ofs + i, *(ptr.x8 + i)); break; case 2: bus_space_write_2(sc->sc_tag, sc->sc_handle, - sc->sc_wrofs + i, *(ptr.x16 + i / 2)); + ofs + i, *(ptr.x16 + i / 2)); break; case 4: bus_space_write_4(sc->sc_tag, sc->sc_handle, - sc->sc_wrofs + i, *(ptr.x32 + i / 4)); + ofs + i, *(ptr.x32 + i / 4)); break; } - + intr_restore(intr); - error = cfi_wait_ready(sc, sc->sc_wrofs, start, - CFI_TIMEOUT_WRITE); + error = cfi_wait_ready(sc, ofs, start, CFI_TIMEOUT_WRITE); if (error) - goto out; + return (error); } /* error is 0. */ + return (error); +} + +int +cfi_write_block(struct cfi_softc *sc) +{ + int error, neederase = 0; + u_int i; + + cfi_unlock_flash(sc, sc->sc_wrofs); + + /* Check if an erase is required. */ + for (i = 0; i < sc->sc_wrbufsz; i++) + if ((sc->sc_wrbuf[i] & sc->sc_wrbufcpy[i]) != sc->sc_wrbuf[i]) { + neederase = 1; + break; + } + + if (neederase) { + error = cfi_erase_block(sc, sc->sc_wrofs); + if (error) + goto out; + } + + error = cfi_program_block(sc, sc->sc_wrofs, sc->sc_wrbuf, + sc->sc_wrbufcpy, sc->sc_wrbufsz, neederase); out: cfi_write(sc, 0, CFI_BCS_READ_ARRAY); - /* Relock Intel flash */ - switch (sc->sc_cmdset) { - case CFI_VEND_INTEL_ECS: - case CFI_VEND_INTEL_SCS: - cfi_write(sc, sc->sc_wrofs, CFI_INTEL_LBS); - cfi_write(sc, sc->sc_wrofs, CFI_INTEL_LB); - cfi_write(sc, sc->sc_wrofs, CFI_BCS_READ_ARRAY); - break; - } + cfi_relock_flash(sc, sc->sc_wrofs); return (error); } -- 1.8.4.5 From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 9 23:13:55 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DDF9D3B for ; Tue, 9 Jun 2015 23:13:55 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (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 EEB8C13B6 for ; Tue, 9 Jun 2015 23:13:54 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: by quine.pinyon.org (Postfix, from userid 122) id 35A9E1602CD; Tue, 9 Jun 2015 16:04:43 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 94976160166 for ; Tue, 9 Jun 2015 16:04:40 -0700 (MST) Message-ID: <55777108.5020206@pinyon.org> Date: Tue, 09 Jun 2015 16:04:40 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: umtx_lock and friends Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 23:13:55 -0000 Hi, I'm investigating what the most lightweight inter-process mutex technique on FreeBSD and have been looking at the infrastructure in /usr/include/sys/umtx.h However, my simple test program fails to link: #include #include #include #include #include int main(int, char **) { printf("Testing..."); struct umtx m; umtx_init(&m); u_long id=5; umtx_lock(&m, id); umtx_unlock(&m, id); printf("Test done."); return 0; } produces the following: tester.cpp:(.text+0x36): undefined reference to `_umtx_lock(umtx*)' tester.cpp:(.text+0x5f): undefined reference to `_umtx_unlock(umtx*)' I've tried linking against a variety of suspects in /usr/lib but no luck. go-lang uses _umtx_op but they make the syscall directly via asm, it seems. I can build an inter-process mutex over semaphores but the umtx stuff looks perfect if I can get it to work. Thanks, Russell From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 10 00:05:14 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 90D26C38 for ; Wed, 10 Jun 2015 00:05:14 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 554421F4D for ; Wed, 10 Jun 2015 00:05:13 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id t59Nvajw023874; Tue, 9 Jun 2015 19:57:36 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 09 Jun 2015 19:57:36 -0400 (EDT) Date: Tue, 9 Jun 2015 19:57:36 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: "Russell L. Carter" cc: freebsd-hackers@freebsd.org Subject: Re: umtx_lock and friends In-Reply-To: <55777108.5020206@pinyon.org> Message-ID: References: <55777108.5020206@pinyon.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 00:05:14 -0000 On Tue, 9 Jun 2015, Russell L. Carter wrote: > Hi, > > I'm investigating what the most lightweight inter-process mutex > technique on FreeBSD and have been looking at the > infrastructure in /usr/include/sys/umtx.h > > However, my simple test program fails to link: > > #include > #include > #include > #include > #include > > int main(int, char **) > { > printf("Testing..."); > struct umtx m; > umtx_init(&m); > u_long id=5; > umtx_lock(&m, id); > umtx_unlock(&m, id); > printf("Test done."); > return 0; > } > > produces the following: > > tester.cpp:(.text+0x36): undefined reference to `_umtx_lock(umtx*)' > tester.cpp:(.text+0x5f): undefined reference to `_umtx_unlock(umtx*)' > > I've tried linking against a variety of suspects in /usr/lib but > no luck. > > go-lang uses _umtx_op but they make the syscall directly via asm, > it seems. > > I can build an inter-process mutex over semaphores but the umtx > stuff looks perfect if I can get it to work. I'm not sure you are really suppose to be using those directly. They are provided for FreeBSD's libraries (libthr) to use. If they are meant for public consumption, I don't like how they are implemented as static inlines in sys/umtx.h - it's not possible to properly bind to these functions from non-C languages. But, nonetheless, your example compiles and runs just fine as a C program on FreeBSD 10-stable. -- DE From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 10 00:52:52 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B617163C; Wed, 10 Jun 2015 00:52:52 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (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 8E4281B20; Wed, 10 Jun 2015 00:52:52 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: by quine.pinyon.org (Postfix, from userid 122) id 0F5001602CD; Tue, 9 Jun 2015 17:52:51 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 931EC16014F; Tue, 9 Jun 2015 17:52:48 -0700 (MST) Message-ID: <55778A60.9090200@pinyon.org> Date: Tue, 09 Jun 2015 17:52:48 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Daniel Eischen CC: freebsd-hackers@freebsd.org Subject: Re: umtx_lock and friends References: <55777108.5020206@pinyon.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 00:52:52 -0000 Hi Daniel, On 06/09/15 16:57, Daniel Eischen wrote: > On Tue, 9 Jun 2015, Russell L. Carter wrote: > >> Hi, >> >> I'm investigating what the most lightweight inter-process mutex >> technique on FreeBSD and have been looking at the >> infrastructure in /usr/include/sys/umtx.h >> >> However, my simple test program fails to link: >> >> #include >> #include >> #include >> #include >> #include >> >> int main(int, char **) >> { >> printf("Testing..."); >> struct umtx m; >> umtx_init(&m); >> u_long id=5; >> umtx_lock(&m, id); >> umtx_unlock(&m, id); >> printf("Test done."); >> return 0; >> } >> >> produces the following: >> >> tester.cpp:(.text+0x36): undefined reference to `_umtx_lock(umtx*)' >> tester.cpp:(.text+0x5f): undefined reference to `_umtx_unlock(umtx*)' >> >> I've tried linking against a variety of suspects in /usr/lib but >> no luck. >> >> go-lang uses _umtx_op but they make the syscall directly via asm, >> it seems. >> >> I can build an inter-process mutex over semaphores but the umtx >> stuff looks perfect if I can get it to work. > > I'm not sure you are really suppose to be using those directly. > They are provided for FreeBSD's libraries (libthr) to use. But libthr doesn't support inter-process mutexes, correct? Here's the relevant excerpt from pthread_rwlockattr_setpshared(3): "BUGS The PTHREAD_PROCESS_SHARED attribute is not supported." > If they are meant for public consumption, I don't like how they > are implemented as static inlines in sys/umtx.h - it's not > possible to properly bind to these functions from non-C > languages. > > But, nonetheless, your example compiles and runs just fine as > a C program on FreeBSD 10-stable. > On FreeBSD 10-stable r283752 amd64, here is the compile line: /usr/bin/cc -O -Wall tester.cpp -o tester /tmp/tester-b681b3.o: In function `main': tester.cpp:(.text+0x35): undefined reference to `_umtx_lock(umtx*)' tester.cpp:(.text+0x5c): undefined reference to `_umtx_unlock(umtx*)' Compilers don't matter, linking against libthr or libstdthreads doesn't matter. Thanks, Russell From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 10 01:00:29 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 886C17A0 for ; Wed, 10 Jun 2015 01:00:29 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 332C11BB4 for ; Wed, 10 Jun 2015 01:00:28 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id t5A10RqK049398; Tue, 9 Jun 2015 21:00:27 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 09 Jun 2015 21:00:27 -0400 (EDT) Date: Tue, 9 Jun 2015 21:00:27 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: "Russell L. Carter" cc: freebsd-hackers@freebsd.org Subject: Re: umtx_lock and friends In-Reply-To: <55778A60.9090200@pinyon.org> Message-ID: References: <55777108.5020206@pinyon.org> <55778A60.9090200@pinyon.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 01:00:29 -0000 On Tue, 9 Jun 2015, Russell L. Carter wrote: > Hi Daniel, > > On 06/09/15 16:57, Daniel Eischen wrote: >> On Tue, 9 Jun 2015, Russell L. Carter wrote: >> >>> Hi, >>> >>> I'm investigating what the most lightweight inter-process mutex >>> technique on FreeBSD and have been looking at the >>> infrastructure in /usr/include/sys/umtx.h >>> >>> However, my simple test program fails to link: >>> >>> #include >>> #include >>> #include >>> #include >>> #include >>> >>> int main(int, char **) >>> { >>> printf("Testing..."); >>> struct umtx m; >>> umtx_init(&m); >>> u_long id=5; >>> umtx_lock(&m, id); >>> umtx_unlock(&m, id); >>> printf("Test done."); >>> return 0; >>> } >>> >>> produces the following: >>> >>> tester.cpp:(.text+0x36): undefined reference to `_umtx_lock(umtx*)' >>> tester.cpp:(.text+0x5f): undefined reference to `_umtx_unlock(umtx*)' >>> >>> I've tried linking against a variety of suspects in /usr/lib but >>> no luck. >>> >>> go-lang uses _umtx_op but they make the syscall directly via asm, >>> it seems. >>> >>> I can build an inter-process mutex over semaphores but the umtx >>> stuff looks perfect if I can get it to work. >> >> I'm not sure you are really suppose to be using those directly. >> They are provided for FreeBSD's libraries (libthr) to use. > > But libthr doesn't support inter-process mutexes, correct? Here's > the relevant excerpt from pthread_rwlockattr_setpshared(3): > > "BUGS > The PTHREAD_PROCESS_SHARED attribute is not supported." Correct, not supported yet. A rather large change to change pthread mutex and CV types from pointers to structs is needed. >> If they are meant for public consumption, I don't like how they >> are implemented as static inlines in sys/umtx.h - it's not >> possible to properly bind to these functions from non-C >> languages. >> >> But, nonetheless, your example compiles and runs just fine as >> a C program on FreeBSD 10-stable. >> > > On FreeBSD 10-stable r283752 amd64, here is the compile line: > > /usr/bin/cc -O -Wall tester.cpp -o tester > /tmp/tester-b681b3.o: In function `main': > tester.cpp:(.text+0x35): undefined reference to `_umtx_lock(umtx*)' > tester.cpp:(.text+0x5c): undefined reference to `_umtx_unlock(umtx*)' > > Compilers don't matter, linking against libthr or libstdthreads > doesn't matter. Is cc doing something special because it thinks it is C++? I'm on 10-stable amd64 and that example (saved as tester.c) works just fine. -- DE From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 10 01:03:55 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE229A58 for ; Wed, 10 Jun 2015 01:03:55 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 72E791D70 for ; Wed, 10 Jun 2015 01:03:55 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id t5A13rQq050923; Tue, 9 Jun 2015 21:03:53 -0400 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Tue, 09 Jun 2015 21:03:53 -0400 (EDT) Date: Tue, 9 Jun 2015 21:03:53 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: "Russell L. Carter" cc: freebsd-hackers@freebsd.org Subject: Re: umtx_lock and friends In-Reply-To: Message-ID: References: <55777108.5020206@pinyon.org> <55778A60.9090200@pinyon.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 01:03:55 -0000 On Tue, 9 Jun 2015, Daniel Eischen wrote: > On Tue, 9 Jun 2015, Russell L. Carter wrote: > >> On FreeBSD 10-stable r283752 amd64, here is the compile line: >> >> /usr/bin/cc -O -Wall tester.cpp -o tester >> /tmp/tester-b681b3.o: In function `main': >> tester.cpp:(.text+0x35): undefined reference to `_umtx_lock(umtx*)' >> tester.cpp:(.text+0x5c): undefined reference to `_umtx_unlock(umtx*)' >> >> Compilers don't matter, linking against libthr or libstdthreads >> doesn't matter. > > Is cc doing something special because it thinks it is C++? > I'm on 10-stable amd64 and that example (saved as tester.c) > works just fine. Try: /usr/bin/cc -O -Wall -x c tester.cpp -o tester -- DE From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 10 01:15:42 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A80E8C7B; Wed, 10 Jun 2015 01:15:42 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from quine.pinyon.org (quine.pinyon.org [65.101.5.249]) (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 8198A1FBA; Wed, 10 Jun 2015 01:15:42 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: by quine.pinyon.org (Postfix, from userid 122) id 824AB1602CD; Tue, 9 Jun 2015 18:15:41 -0700 (MST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on quine.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from feyerabend.n1.pinyon.org (feyerabend.n1.pinyon.org [10.0.10.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by quine.pinyon.org (Postfix) with ESMTPSA id 0F455160166; Tue, 9 Jun 2015 18:15:39 -0700 (MST) Message-ID: <55778FBA.5010004@pinyon.org> Date: Tue, 09 Jun 2015 18:15:38 -0700 From: "Russell L. Carter" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Daniel Eischen CC: freebsd-hackers@freebsd.org Subject: Re: umtx_lock and friends References: <55777108.5020206@pinyon.org> <55778A60.9090200@pinyon.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 01:15:42 -0000 On 06/09/15 18:03, Daniel Eischen wrote: > On Tue, 9 Jun 2015, Daniel Eischen wrote: > >> On Tue, 9 Jun 2015, Russell L. Carter wrote: >> >>> On FreeBSD 10-stable r283752 amd64, here is the compile line: >>> >>> /usr/bin/cc -O -Wall tester.cpp -o tester >>> /tmp/tester-b681b3.o: In function `main': >>> tester.cpp:(.text+0x35): undefined reference to `_umtx_lock(umtx*)' >>> tester.cpp:(.text+0x5c): undefined reference to `_umtx_unlock(umtx*)' >>> >>> Compilers don't matter, linking against libthr or libstdthreads >>> doesn't matter. >> >> Is cc doing something special because it thinks it is C++? >> I'm on 10-stable amd64 and that example (saved as tester.c) >> works just fine. Yep! That made me laugh. I generally test as c++ and I thought I would cut this one down to just c, but that extension matters to every c compiler I tried. Putting the standard extern "C" { ... } guards around #include cures this problem. Thanks! Russell > > Try: > > /usr/bin/cc -O -Wall -x c tester.cpp -o tester > From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 10 20:15:54 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84DEA69C for ; Wed, 10 Jun 2015 20:15:54 +0000 (UTC) (envelope-from stefan.andritoiu@gmail.com) Received: from mail-ob0-x242.google.com (mail-ob0-x242.google.com [IPv6:2607:f8b0:4003:c01::242]) (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 4CBA31464 for ; Wed, 10 Jun 2015 20:15:54 +0000 (UTC) (envelope-from stefan.andritoiu@gmail.com) Received: by obcwm4 with SMTP id wm4so5910900obc.3 for ; Wed, 10 Jun 2015 13:15:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jlxV0A7Y7cO2zwg4jE5bhg1yZpOJE4PEw3t7WWgwkqk=; b=QDbvnXJa6WbI0eX+23CkfNUYvGvtnZvdYqq3Jk2aTWgyOnPmzqZmMhCfqPIOZCHDY0 UK/56nawpY0TIbbDw56YGnOvzh1zfzk9Zrj56edxTyTgnQ1eIdoekFBNtja/MGIvhh0/ 2CudntNWjrkrQdIEXfkm++igy427DSbggSwd4So5oRGA5/RVrVAGTIf+Oh4SZxuzGQrP kEY7aPyTftgi64t1e5c0FjNru3sBf+c0v3XRtWDXjC/AAaKUkRSxMOfIyJCXwW4TdbZS r+FoHfjNj+w7FQ3tiAHHqABDKwme6erSHGCPE4JTFMr6OGRFCVX9mKqBa5ltTsNtzDje ycEQ== MIME-Version: 1.0 X-Received: by 10.60.80.229 with SMTP id u5mr4417704oex.27.1433967353676; Wed, 10 Jun 2015 13:15:53 -0700 (PDT) Received: by 10.60.82.168 with HTTP; Wed, 10 Jun 2015 13:15:53 -0700 (PDT) Date: Wed, 10 Jun 2015 23:15:53 +0300 Message-ID: Subject: Gang scheduling implementation in the ULE scheduler From: Stefan Andritoiu To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 10 Jun 2015 22:50:29 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 20:15:54 -0000 Hello, I am currently working on a gang scheduling implementation for the bhyve VCPU-threads on FreeBSD 10.1. I have added a new field "int gang" to the thread structure to specify the gang it is part of (0 for no gang), and have modified the bhyve code to initialize this field when a VCPU is created. I will post these modifications in another message. When I start a Virtual Machine, during the guest's boot, IPIs are sent and received correctly between CPUs, but after a few seconds I get: spin lock 0xffffffff8164c290 (smp rendezvous) held by 0xfffff8000296c000 (tid 100009) too long panic: spin lock held too long If I limit the number of IPIs that are sent, I do not have this problem. Which leads me to believe that (because of the constant context-switch when the guest boots), the high number of IPIs sent starve the system. Does anyone know what is happening? And maybe know of a possible solution? Thank you, Stefan ====================================================================================== I have added here the modifications to the sched_ule.c file and a brief explanation of it: In struct tdq, I have added two new field: - int scheduled_gang; /* Set to a non-zero value if the respective CPU is required to schedule a thread belonging to a gang. The value of scheduled_gang also being the ID of the gang that we want scheduled. For now I have considered only one running guest, so the value is 0 or 1 */ - int gang_leader; /* Set if the respective CPU is the one who has initialized gang scheduling. Zero otherwise. Not relevant to the final code and will be removed. Just for debugging purposes. */ Created a new function "static void schedule_gang(void * arg)" that will be called by each processor when it receives an IPI from the gang leader: - sets scheduled_gang = 1 - informs the system that it needs to reschedule. Not yet implemented In function "struct thread* tdq_choose (struct tdq * tdq)": if (tdq->scheduled_gang) - checks to see if a thread belonging to a gang must be scheduled. If so, calls functions that check the runqs and return a gang thread. I have yet to implement these functions. In function "sched_choose()": if (td->gang) - checks if the chosen thread is part of a gang. If so it signals all other CPUs to run function "schedule_gang(void * gang)". if (tdq->scheduled_gang) - if scheduled_gang is set it means that the scheduler is called after the the code in schedule_gang() has ran, and bypasses sending IPIs to the other CPUs. If not for this checkup, a CPU would receive a IPI; set scheduled_gang=1; the scheduler would be called and would choose a thread to run; that thread would be part of a gang; an IPI would be sent to all other CPUs. A constant back-and-forth of IPIs between the CPUs would be created. The CPU that initializes gang scheduling, does not receive an IPI, and does not even call the "schedule_gang(void * gang)" function. It continues in scheduling the gang-thread it selected, the one that started the gang scheduling process. =================================================================== --- sched_ule.c (revision 24) +++ sched_ule.c (revision 26) @@ -247,6 +247,9 @@ struct runq tdq_timeshare; /* timeshare run queue. */ struct runq tdq_idle; /* Queue of IDLE threads. */ char tdq_name[TDQ_NAME_LEN]; + + int gang_leader; + int scheduled_gang; #ifdef KTR char tdq_loadname[TDQ_LOADNAME_LEN]; #endif @@ -1308,6 +1311,20 @@ struct thread *td; TDQ_LOCK_ASSERT(tdq, MA_OWNED); + + /* Pick gang thread to run */ + if (tdq->scheduled_gang){ + /* basically the normal choosing of threads but with regards to scheduled_gang + tdq = runq_choose_gang(&tdq->realtime); + if (td != NULL) + return (td); + + td = runq_choose_from_gang(&tdq->tdq_timeshare, tdq->tdq_ridx); + if (td != NULL) + return (td); + */ + } + td = runq_choose(&tdq->tdq_realtime); if (td != NULL) return (td); @@ -2295,6 +2312,22 @@ return (load); } +static void +schedule_gang(void * arg){ + struct tdq *tdq; + struct tdq *from_tdq = arg; + tdq = TDQ_SELF(); + + if(tdq == from_tdq){ + /* Just for testing IPI. Code is never reached, and should never be*/ + tdq->scheduled_gang = 1; +// printf("[schedule_gang] received IPI from himself\n"); + } + else{ + tdq->scheduled_gang = 1; +// printf("[schedule_gang] received on cpu: %s \n", tdq->tdq_name); + } +} /* * Choose the highest priority thread to run. The thread is removed from * the run-queue while running however the load remains. For SMP we set @@ -2305,11 +2338,26 @@ { struct thread *td; struct tdq *tdq; + cpuset_t map; tdq = TDQ_SELF(); TDQ_LOCK_ASSERT(tdq, MA_OWNED); td = tdq_choose(tdq); if (td) { + if(tdq->scheduled_gang){ + /* Scheduler called after IPI + jump over rendezvous*/ + tdq->scheduled_gang = 0; + } + else{ + if(td->gang){ + map = all_cpus; + CPU_CLR(curcpu, &map); + + smp_rendezvous_cpus(map, NULL, schedule_gang, NULL, tdq); + } + } + tdq_runq_rem(tdq, td); tdq->tdq_lowpri = td->td_priority; return (td); From owner-freebsd-hackers@FreeBSD.ORG Wed Jun 10 20:26:32 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E386AB1A for ; Wed, 10 Jun 2015 20:26:32 +0000 (UTC) (envelope-from stefan.andritoiu@gmail.com) Received: from mail-ob0-x243.google.com (mail-ob0-x243.google.com [IPv6:2607:f8b0:4003:c01::243]) (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 AC98616FB for ; Wed, 10 Jun 2015 20:26:32 +0000 (UTC) (envelope-from stefan.andritoiu@gmail.com) Received: by obcwm4 with SMTP id wm4so5976542obc.3 for ; Wed, 10 Jun 2015 13:26:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jlxV0A7Y7cO2zwg4jE5bhg1yZpOJE4PEw3t7WWgwkqk=; b=EId704HiB2GrfBCpJi5tkkug0DkPHK69QWaxR+m04nKNxUpDfZq4p5AOKSrrj+4nFM r3uEsP/vXNRMtHiwUEOTR4YbOFcOVLMQbKXpCoc4bzAyEoCkZwc2pZhwg6QjC0IsNw4Q +8ikhGaqgjRxsJ586t0GTJ9byyxsLBJnRMrZjfvjbz4Guh8QraXzDno+X4JbNx64aOD6 sqYrSHxr3oFKkUP9gGoNL/xO7Vo3UTKguN5OMIbj0MKv4GHDSNi5jmCTSHpRRXK19LkO Qyf4UkXeJ1qZvNF8dJ8H1/mFnhx3EEI7oX5xCbYPy7Aqx7rCfaqqWCnmjcPO2PQZJ4Fw jtkA== MIME-Version: 1.0 X-Received: by 10.202.54.3 with SMTP id d3mr4126822oia.103.1433967992055; Wed, 10 Jun 2015 13:26:32 -0700 (PDT) Received: by 10.60.82.168 with HTTP; Wed, 10 Jun 2015 13:26:32 -0700 (PDT) Date: Wed, 10 Jun 2015 23:26:32 +0300 Message-ID: Subject: [Gang scheduling implementation in the ULE scheduler] Problem with sending IPIs to other CPUs From: Stefan Andritoiu To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Wed, 10 Jun 2015 23:52:49 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 20:26:33 -0000 Hello, I am currently working on a gang scheduling implementation for the bhyve VCPU-threads on FreeBSD 10.1. I have added a new field "int gang" to the thread structure to specify the gang it is part of (0 for no gang), and have modified the bhyve code to initialize this field when a VCPU is created. I will post these modifications in another message. When I start a Virtual Machine, during the guest's boot, IPIs are sent and received correctly between CPUs, but after a few seconds I get: spin lock 0xffffffff8164c290 (smp rendezvous) held by 0xfffff8000296c000 (tid 100009) too long panic: spin lock held too long If I limit the number of IPIs that are sent, I do not have this problem. Which leads me to believe that (because of the constant context-switch when the guest boots), the high number of IPIs sent starve the system. Does anyone know what is happening? And maybe know of a possible solution? Thank you, Stefan ====================================================================================== I have added here the modifications to the sched_ule.c file and a brief explanation of it: In struct tdq, I have added two new field: - int scheduled_gang; /* Set to a non-zero value if the respective CPU is required to schedule a thread belonging to a gang. The value of scheduled_gang also being the ID of the gang that we want scheduled. For now I have considered only one running guest, so the value is 0 or 1 */ - int gang_leader; /* Set if the respective CPU is the one who has initialized gang scheduling. Zero otherwise. Not relevant to the final code and will be removed. Just for debugging purposes. */ Created a new function "static void schedule_gang(void * arg)" that will be called by each processor when it receives an IPI from the gang leader: - sets scheduled_gang = 1 - informs the system that it needs to reschedule. Not yet implemented In function "struct thread* tdq_choose (struct tdq * tdq)": if (tdq->scheduled_gang) - checks to see if a thread belonging to a gang must be scheduled. If so, calls functions that check the runqs and return a gang thread. I have yet to implement these functions. In function "sched_choose()": if (td->gang) - checks if the chosen thread is part of a gang. If so it signals all other CPUs to run function "schedule_gang(void * gang)". if (tdq->scheduled_gang) - if scheduled_gang is set it means that the scheduler is called after the the code in schedule_gang() has ran, and bypasses sending IPIs to the other CPUs. If not for this checkup, a CPU would receive a IPI; set scheduled_gang=1; the scheduler would be called and would choose a thread to run; that thread would be part of a gang; an IPI would be sent to all other CPUs. A constant back-and-forth of IPIs between the CPUs would be created. The CPU that initializes gang scheduling, does not receive an IPI, and does not even call the "schedule_gang(void * gang)" function. It continues in scheduling the gang-thread it selected, the one that started the gang scheduling process. =================================================================== --- sched_ule.c (revision 24) +++ sched_ule.c (revision 26) @@ -247,6 +247,9 @@ struct runq tdq_timeshare; /* timeshare run queue. */ struct runq tdq_idle; /* Queue of IDLE threads. */ char tdq_name[TDQ_NAME_LEN]; + + int gang_leader; + int scheduled_gang; #ifdef KTR char tdq_loadname[TDQ_LOADNAME_LEN]; #endif @@ -1308,6 +1311,20 @@ struct thread *td; TDQ_LOCK_ASSERT(tdq, MA_OWNED); + + /* Pick gang thread to run */ + if (tdq->scheduled_gang){ + /* basically the normal choosing of threads but with regards to scheduled_gang + tdq = runq_choose_gang(&tdq->realtime); + if (td != NULL) + return (td); + + td = runq_choose_from_gang(&tdq->tdq_timeshare, tdq->tdq_ridx); + if (td != NULL) + return (td); + */ + } + td = runq_choose(&tdq->tdq_realtime); if (td != NULL) return (td); @@ -2295,6 +2312,22 @@ return (load); } +static void +schedule_gang(void * arg){ + struct tdq *tdq; + struct tdq *from_tdq = arg; + tdq = TDQ_SELF(); + + if(tdq == from_tdq){ + /* Just for testing IPI. Code is never reached, and should never be*/ + tdq->scheduled_gang = 1; +// printf("[schedule_gang] received IPI from himself\n"); + } + else{ + tdq->scheduled_gang = 1; +// printf("[schedule_gang] received on cpu: %s \n", tdq->tdq_name); + } +} /* * Choose the highest priority thread to run. The thread is removed from * the run-queue while running however the load remains. For SMP we set @@ -2305,11 +2338,26 @@ { struct thread *td; struct tdq *tdq; + cpuset_t map; tdq = TDQ_SELF(); TDQ_LOCK_ASSERT(tdq, MA_OWNED); td = tdq_choose(tdq); if (td) { + if(tdq->scheduled_gang){ + /* Scheduler called after IPI + jump over rendezvous*/ + tdq->scheduled_gang = 0; + } + else{ + if(td->gang){ + map = all_cpus; + CPU_CLR(curcpu, &map); + + smp_rendezvous_cpus(map, NULL, schedule_gang, NULL, tdq); + } + } + tdq_runq_rem(tdq, td); tdq->tdq_lowpri = td->td_priority; return (td); From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 11 06:52:39 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F265D55D for ; Thu, 11 Jun 2015 06:52:39 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: from mail-pa0-x242.google.com (mail-pa0-x242.google.com [IPv6:2607:f8b0:400e:c03::242]) (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 C16F3142B for ; Thu, 11 Jun 2015 06:52:39 +0000 (UTC) (envelope-from kmacybsd@gmail.com) Received: by pabli10 with SMTP id li10so14675583pab.2 for ; Wed, 10 Jun 2015 23:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FtvPDHVyG8RrwqHegCOz9Ql8gd4aRA78jQgiMnRejlg=; b=Eb0v9KtD8lRJHR6tNLxcKSPD2Ku3oKCmUNXCc17h4Wm6Ul/XHb1dejjIKDK8ijP6VU siEOEHMrRzLEXuMFPUEyToe6RI3hRFaZJ2bRO6ROK+EU0lNs0P5el9399kkZmmTDsBqh BBako5hZFqeDBCWS9PIoxq5HVkgGn49BgYMfYOwrPhIyHN/OOiVbvLMV0otWXRc7oh5z X8z4CApA+OYGVGA8oKXqZsqMn4/qaixTkIB4ub+iodDGuQGlWeFLm5HTuRdndolsDYNH eb3s1TDH+CT3r6X5rh10kRo9kIcIBqdN5Ago7V6EMQD/MWL4n1gEuvaahCgCtOmFQ4Ty /hOA== MIME-Version: 1.0 X-Received: by 10.70.93.69 with SMTP id cs5mr12249727pdb.165.1434005559368; Wed, 10 Jun 2015 23:52:39 -0700 (PDT) Sender: kmacybsd@gmail.com Received: by 10.66.236.36 with HTTP; Wed, 10 Jun 2015 23:52:39 -0700 (PDT) Received: by 10.66.236.36 with HTTP; Wed, 10 Jun 2015 23:52:39 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jun 2015 23:52:39 -0700 X-Google-Sender-Auth: 9f4D0KOY4oZ6oYa2dNQS6BBcPZE Message-ID: Subject: Re: Gang scheduling implementation in the ULE scheduler From: "K. Macy" To: Stefan Andritoiu Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 06:52:40 -0000 I just have a more general comment. There are a lot of different conflicting demands to adapt the scheduler for different workloads. Please try to encapsulate your changes such that common structures are changed as little as possible. Thanks. -K On Jun 10, 2015 3:50 PM, "Stefan Andritoiu" wrote: > Hello, > > I am currently working on a gang scheduling implementation for the > bhyve VCPU-threads on FreeBSD 10.1. > I have added a new field "int gang" to the thread structure to specify > the gang it is part of (0 for no gang), and have modified the bhyve > code to initialize this field when a VCPU is created. I will post > these modifications in another message. > > When I start a Virtual Machine, during the guest's boot, IPIs are sent > and received correctly between CPUs, but after a few seconds I get: > spin lock 0xffffffff8164c290 (smp rendezvous) held by > 0xfffff8000296c000 (tid 100009) too long > panic: spin lock held too long > > If I limit the number of IPIs that are sent, I do not have this > problem. Which leads me to believe that (because of the constant > context-switch when the guest boots), the high number of IPIs sent > starve the system. > > Does anyone know what is happening? And maybe know of a possible solution? > > Thank you, > Stefan > > > > ====================================================================================== > I have added here the modifications to the sched_ule.c file and a > brief explanation of it: > > In struct tdq, I have added two new field: > - int scheduled_gang; > /* Set to a non-zero value if the respective CPU is required to > schedule a thread belonging to a gang. The value of scheduled_gang > also being the ID of the gang that we want scheduled. For now I have > considered only one running guest, so the value is 0 or 1 */ > - int gang_leader; > /* Set if the respective CPU is the one who has initialized gang > scheduling. Zero otherwise. Not relevant to the final code and will be > removed. Just for debugging purposes. */ > > Created a new function "static void schedule_gang(void * arg)" that > will be called by each processor when it receives an IPI from the gang > leader: > - sets scheduled_gang = 1 > - informs the system that it needs to reschedule. Not yet implemented > > In function "struct thread* tdq_choose (struct tdq * tdq)": > if (tdq->scheduled_gang) - checks to see if a thread belonging to > a gang must be scheduled. If so, calls functions that check the runqs > and return a gang thread. I have yet to implement these functions. > > In function "sched_choose()": > if (td->gang) - checks if the chosen thread is part of a gang. If > so it signals all other CPUs to run function "schedule_gang(void * > gang)". > if (tdq->scheduled_gang) - if scheduled_gang is set it means that > the scheduler is called after the the code in schedule_gang() has ran, > and bypasses sending IPIs to the other CPUs. If not for this checkup, > a CPU would receive a IPI; set scheduled_gang=1; the scheduler would > be called and would choose a thread to run; that thread would be part > of a gang; an IPI would be sent to all other CPUs. A constant > back-and-forth of IPIs between the CPUs would be created. > > The CPU that initializes gang scheduling, does not receive an IPI, and > does not even call the "schedule_gang(void * gang)" function. It > continues in scheduling the gang-thread it selected, the one that > started the gang scheduling process. > > > =================================================================== > --- sched_ule.c (revision 24) > +++ sched_ule.c (revision 26) > @@ -247,6 +247,9 @@ > struct runq tdq_timeshare; /* timeshare run queue. */ > struct runq tdq_idle; /* Queue of IDLE threads. */ > char tdq_name[TDQ_NAME_LEN]; > + > + int gang_leader; > + int scheduled_gang; > #ifdef KTR > char tdq_loadname[TDQ_LOADNAME_LEN]; > #endif > @@ -1308,6 +1311,20 @@ > struct thread *td; > > TDQ_LOCK_ASSERT(tdq, MA_OWNED); > + > + /* Pick gang thread to run */ > + if (tdq->scheduled_gang){ > + /* basically the normal choosing of threads but with regards to > scheduled_gang > + tdq = runq_choose_gang(&tdq->realtime); > + if (td != NULL) > + return (td); > + > + td = runq_choose_from_gang(&tdq->tdq_timeshare, tdq->tdq_ridx); > + if (td != NULL) > + return (td); > + */ > + } > + > td = runq_choose(&tdq->tdq_realtime); > if (td != NULL) > return (td); > @@ -2295,6 +2312,22 @@ > return (load); > } > > +static void > +schedule_gang(void * arg){ > + struct tdq *tdq; > + struct tdq *from_tdq = arg; > + tdq = TDQ_SELF(); > + > + if(tdq == from_tdq){ > + /* Just for testing IPI. Code is never reached, and should never be*/ > + tdq->scheduled_gang = 1; > +// printf("[schedule_gang] received IPI from himself\n"); > + } > + else{ > + tdq->scheduled_gang = 1; > +// printf("[schedule_gang] received on cpu: %s \n", tdq->tdq_name); > + } > +} > /* > * Choose the highest priority thread to run. The thread is removed from > * the run-queue while running however the load remains. For SMP we set > @@ -2305,11 +2338,26 @@ > { > struct thread *td; > struct tdq *tdq; > + cpuset_t map; > > tdq = TDQ_SELF(); > TDQ_LOCK_ASSERT(tdq, MA_OWNED); > td = tdq_choose(tdq); > if (td) { > + if(tdq->scheduled_gang){ > + /* Scheduler called after IPI > + jump over rendezvous*/ > + tdq->scheduled_gang = 0; > + } > + else{ > + if(td->gang){ > + map = all_cpus; > + CPU_CLR(curcpu, &map); > + > + smp_rendezvous_cpus(map, NULL, schedule_gang, NULL, tdq); > + } > + } > + > tdq_runq_rem(tdq, td); > tdq->tdq_lowpri = td->td_priority; > return (td); > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 11 07:21:20 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C19B1B85 for ; Thu, 11 Jun 2015 07:21:20 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 9D8671AA9 for ; Thu, 11 Jun 2015 07:21:20 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=V/eJ0dVqq7TiyrakM1GeeUavEynB2UV1uDRHYtsDg9Q=; b=eCbjc0d7FS4fAxcJq4Ew3Ffh9Jqv6htooyD8zl0nCPooQS6RjtH/n64xyWrxivR1QWVuVYi4nZJJrCyd1jPrUJRv1bahwpAHAJFGvlDuI9M7zHdDhxmzjGynx+eslsDmi82/nY+o2gITliPNCZRzqB/qoAT8KvdCZ/awgJ53l98=; Received: from [114.124.3.227] (port=51490 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.85) (envelope-from ) id 1Z2wnY-000UYx-MY; Thu, 11 Jun 2015 01:21:13 -0600 Date: Thu, 11 Jun 2015 15:21:07 +0800 From: Erich Dollansky To: Hans Petter Selasky Cc: "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search Message-ID: <20150611152107.61f85189@B85M-HD3-0.alogt.com> In-Reply-To: <5573EA5E.40806@selasky.org> References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 07:21:20 -0000 Hi Hans, On Sun, 07 Jun 2015 08:53:18 +0200 Hans Petter Selasky wrote: > On 06/07/15 02:13, Erich Dollansky wrote: > > > > /* > > * Find First Set bit > > */ > > int > > ffs(int mask) > > { as I would replace all except of what I have left above, I think that the copyright notice also should be changed. Whom should I place in there? I think using my name for a simple thing like this is a bit overdone. Erich From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 11 12:57:59 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0DA1DA8 for ; Thu, 11 Jun 2015 12:57:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) by mx1.freebsd.org (Postfix) with SMTP id 7ED05125C for ; Thu, 11 Jun 2015 12:57:59 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 11 Jun 2015 12:57:59 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t5BCvpFv006478; Thu, 11 Jun 2015 06:57:51 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1434027471.1200.401.camel@freebsd.org> Subject: Re: allow ffs & co. a binary search From: Ian Lepore To: Erich Dollansky Cc: Hans Petter Selasky , "freebsd-hackers@freebsd.org" Date: Thu, 11 Jun 2015 06:57:51 -0600 In-Reply-To: <20150611152107.61f85189@B85M-HD3-0.alogt.com> References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150611152107.61f85189@B85M-HD3-0.alogt.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 12:57:59 -0000 On Thu, 2015-06-11 at 15:21 +0800, Erich Dollansky wrote: > Hi Hans, > > On Sun, 07 Jun 2015 08:53:18 +0200 > Hans Petter Selasky wrote: > > > On 06/07/15 02:13, Erich Dollansky wrote: > > > > > > /* > > > * Find First Set bit > > > */ > > > int > > > ffs(int mask) > > > { > > as I would replace all except of what I have left above, I think that > the copyright notice also should be changed. Whom should I place in > there? I think using my name for a simple thing like this is a bit > overdone. > Is there any reason that this whole change, userland and kernel, isn't just: #define ffs(n) __builtin_ffs(n) ? -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 11 14:43:55 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FABDFDA; Thu, 11 Jun 2015 14:43:55 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 59BA21143; Thu, 11 Jun 2015 14:43:55 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=juJQK5oWDi3gmOd3uHFqoX9nO40m3cF8YjeDCbqYDzo=; b=lsHn8wuFdR9HBMqcDeSmWLWHZ8Yt2K/oJVMSpCSsmBlmjKCa2NsM02ZGhJl0nekh5YnFyFKASDfJpIv4jej/zhqmXToDhSx/S+/l2kYae4a3k+vwcZXDF9mC9fgH+lFpzGYvh8EyeUM3SBginvJ2NkvE4hn+cbrKIrH7/8UlEPk=; Received: from [114.124.3.227] (port=17775 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.85) (envelope-from ) id 1Z33hw-000TWZ-NB; Thu, 11 Jun 2015 08:43:53 -0600 Date: Thu, 11 Jun 2015 22:43:47 +0800 From: Erich Dollansky To: Ian Lepore Cc: Hans Petter Selasky , "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search Message-ID: <20150611224347.64372a76@B85M-HD3-0.alogt.com> In-Reply-To: <1434027471.1200.401.camel@freebsd.org> References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150611152107.61f85189@B85M-HD3-0.alogt.com> <1434027471.1200.401.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 14:43:55 -0000 Hi, On Thu, 11 Jun 2015 06:57:51 -0600 Ian Lepore wrote: > On Thu, 2015-06-11 at 15:21 +0800, Erich Dollansky wrote: > > On Sun, 07 Jun 2015 08:53:18 +0200 > > Hans Petter Selasky wrote: > > > Is there any reason that this whole change, userland and kernel, isn't > just: > > #define ffs(n) __builtin_ffs(n) I did not see this. Where is it? Of course, if this is already done, it does not have to be done again. Erich From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 11 14:50:16 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FC0D313 for ; Thu, 11 Jun 2015 14:50:16 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 432A711B5 for ; Thu, 11 Jun 2015 14:50:15 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from [192.168.1.2] (pool-72-89-250-199.nycmny.fios.verizon.net [72.89.250.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 40A44340B78; Thu, 11 Jun 2015 14:50:07 +0000 (UTC) Message-ID: <5579A016.4040800@gentoo.org> Date: Thu, 11 Jun 2015 10:49:58 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Erich Dollansky , "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> In-Reply-To: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QQWswU3jpf8sjsFLUMgxAmaVKbCmIeGmK" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 14:50:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QQWswU3jpf8sjsFLUMgxAmaVKbCmIeGmK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/06/2015 08:13 PM, Erich Dollansky wrote: > Hi, >=20 > I stumbled these days over the functions to find the first or last bit > set. They are currently written like this: >=20 > /* > * Find First Set bit > */ > int > ffs(int mask) > { > int bit; >=20 > if (mask =3D=3D 0) > return (0); > for (bit =3D 1; !(mask & 1); bit++) > mask =3D (unsigned int)mask >> 1; > return (bit); > } >=20 > With other words, the program loops until it finds what it searches for= =2E >=20 > Why not do it the binary way? The fastest portable way of calculating highest bit set is to use a debrujin sequence: https://graphics.stanford.edu/~seander/bithacks.html#IntegerLogDeBruijn The binary approach is inferior, especially on Pentium 4 processors. Just my two cents. >=20 > int res; >=20 > res =3D 0; > IF (Number !=3D 0) THEN > res =3D 1; > IF ((Number & 0xFFFFFFFF00000000) !=3D 0) THEN > Number =3D Number & 0xFFFFFFFF00000000; > res =3D res + 32; > END; > IF ((Number & 0xFFFF0000FFFF0000) !=3D 0) THEN > Number =3D Number & 0xFFFF0000FFFF0000; > res =3D res + 16; > END; > IF ((Number & 0xFF00FF00FF00FF00) !=3D 0) THEN > Number =3D Number & 0xFF00FF00FF00FF00; > res =3D res + 8; > END; > IF ((Number & 0xF0F0F0F0F0F0F0F0) !=3D 0) THEN > Number =3D Number & 0xF0F0F0F0F0F0F0F0; > res =3D res + 4; > END; > IF ((Number & 0xCCCCCCCCCCCCCCCC) !=3D 0) THEN > Number =3D Number & 0xCCCCCCCCCCCCCCCC; > res =3D res + 2; > END; > IF ((Number & 0xAAAAAAAAAAAAAAAA) !=3D 0) THEN > Number =3D Number & 0xAAAAAAAAAAAAAAAA; > res =3D res + 1; > END; > END; > return res; >=20 > If you like the binary way I could give you the sources for the > complete family following your style to replace the older functions. >=20 > Erich > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 --QQWswU3jpf8sjsFLUMgxAmaVKbCmIeGmK 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 iQIcBAEBAgAGBQJVeaAZAAoJECDuEZm+6ExkNAYP/j1bHAYCDcaH7uIL2Ur9+Uck tOu8NKXY7L2U5oMXcDTaBIhlGGrAv2vmZl+Owdnwl7BqQ+igmYWtCvLN7KNB6Ok+ bnhUxunbyaWRgMKZMM3gWg3tICOcR4HAYjZR3qa0kXZplkWKJB1i9s6oXSvkN7Tr dzMESl+VfU8noE8nmhLCw4MVcmnjTEBfeXkeXjhJb38Go7Ed17zZoGWIbo1KyJ5p vtpe46NEXVL1htpCIR4Ck/dfOlzwNvbk7s+MoySuvKEWd27SWKyaopuyEDc969le Dbi3tv3yuNcvG6dOx4gq83DlPw8jZ86gjwMVKE1NBfTco/hGQrouv3MMttIDqHkE jobE+Fic+bSO+efVNqis+5gAwvEMMAeUhl+kM5hVbqBsDcFvisuwfFatXPYLYN7s iiy9Sw52wNog7eTll2ihH+ZFV/DcVlFam8pKynJZqk4hcKaubfGIy8/zeP75zmWn Iyh1sAMxkeHAopnL0DssKFD/sme51AcMmNlGV3UgYOz+Mpgw+Op2UhklR73NtaZp p6iEL2rBqWqW8Iz1cZ4sUrXYDfUgaKAVHheByga9KSEAIufyNGvBaWm8jpL14XVT SZ/cUpbPnNUM1Z8EtQS+h1Oq3OKvi8tQlO5qz+EDtPJJLd9dKnBpjxoAl5Qddtmn fpmj4nAQ+9a8JjNyd3cx =bvyf -----END PGP SIGNATURE----- --QQWswU3jpf8sjsFLUMgxAmaVKbCmIeGmK-- From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 11 14:52:54 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5E804455 for ; Thu, 11 Jun 2015 14:52:54 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) by mx1.freebsd.org (Postfix) with SMTP id 3B764151C for ; Thu, 11 Jun 2015 14:52:53 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 11 Jun 2015 14:51:58 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t5BEpopf006679; Thu, 11 Jun 2015 08:51:50 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1434034310.1415.2.camel@freebsd.org> Subject: Re: allow ffs & co. a binary search From: Ian Lepore To: Erich Dollansky Cc: Hans Petter Selasky , "freebsd-hackers@freebsd.org" Date: Thu, 11 Jun 2015 08:51:50 -0600 In-Reply-To: <20150611224347.64372a76@B85M-HD3-0.alogt.com> References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150611152107.61f85189@B85M-HD3-0.alogt.com> <1434027471.1200.401.camel@freebsd.org> <20150611224347.64372a76@B85M-HD3-0.alogt.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 14:52:54 -0000 On Thu, 2015-06-11 at 22:43 +0800, Erich Dollansky wrote: > Hi, > > On Thu, 11 Jun 2015 06:57:51 -0600 > Ian Lepore wrote: > > > On Thu, 2015-06-11 at 15:21 +0800, Erich Dollansky wrote: > > > On Sun, 07 Jun 2015 08:53:18 +0200 > > > Hans Petter Selasky wrote: > > > > > Is there any reason that this whole change, userland and kernel, isn't > > just: > > > > #define ffs(n) __builtin_ffs(n) > > I did not see this. Where is it? > > Of course, if this is already done, it does not have to be done again. > > Erich I'm not quite sure what you're asking. Both clang and gcc support __builtin_ffs(), so I'm saying why don't we just use it and call the whole problem solved? -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 11 14:52:55 2015 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CBD10456 for ; Thu, 11 Jun 2015 14:52:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery4.ore.mailhop.org (pmta2.delivery4.ore.mailhop.org [54.200.247.200]) by mx1.freebsd.org (Postfix) with SMTP id AB097151D for ; Thu, 11 Jun 2015 14:52:55 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 11 Jun 2015 14:52:54 +0000 (UTC) Received: from revolution.hippie.lan (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t5BEqrVX006682; Thu, 11 Jun 2015 08:52:53 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1434034373.1415.3.camel@freebsd.org> Subject: Re: allow ffs & co. a binary search From: Ian Lepore To: Richard Yao Cc: Erich Dollansky , "freebsd-hackers@freebsd.org" Date: Thu, 11 Jun 2015 08:52:53 -0600 In-Reply-To: <5579A016.4040800@gentoo.org> References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5579A016.4040800@gentoo.org> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 14:52:55 -0000 On Thu, 2015-06-11 at 10:49 -0400, Richard Yao wrote: > On 06/06/2015 08:13 PM, Erich Dollansky wrote: [...] > > The fastest portable way of calculating highest bit set is to use a > debrujin sequence: > > https://graphics.stanford.edu/~seander/bithacks.html#IntegerLogDeBruijn > > The binary approach is inferior, especially on Pentium 4 processors. And of course it's crucial that we optimize for Pentium 4 processors in 2015. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 11 14:59:13 2015 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6331197B; Thu, 11 Jun 2015 14:59:13 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 452F815BE; Thu, 11 Jun 2015 14:59:12 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from [192.168.1.2] (pool-72-89-250-199.nycmny.fios.verizon.net [72.89.250.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 7F122340C3E; Thu, 11 Jun 2015 14:59:11 +0000 (UTC) Message-ID: <5579A235.80609@gentoo.org> Date: Thu, 11 Jun 2015 10:59:01 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Ian Lepore CC: Erich Dollansky , "freebsd-hackers@freebsd.org" Subject: Re: allow ffs & co. a binary search References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5579A016.4040800@gentoo.org> <1434034373.1415.3.camel@freebsd.org> In-Reply-To: <1434034373.1415.3.camel@freebsd.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="UUSBrl9GXVe8oukFULg4KtKwCTV90NbEi" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 14:59:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UUSBrl9GXVe8oukFULg4KtKwCTV90NbEi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/11/2015 10:52 AM, Ian Lepore wrote: > On Thu, 2015-06-11 at 10:49 -0400, Richard Yao wrote: >> On 06/06/2015 08:13 PM, Erich Dollansky wrote: > [...] >> >> The fastest portable way of calculating highest bit set is to use a >> debrujin sequence: >> >> https://graphics.stanford.edu/~seander/bithacks.html#IntegerLogDeBruij= n >> >> The binary approach is inferior, especially on Pentium 4 processors. >=20 > And of course it's crucial that we optimize for Pentium 4 processors in= > 2015. The debrujin approach is fast regardless of the architecture. Anyway, this is a solved problem. There is no need to reinvent the wheel when the portable solutions are listed on that page at Stanford. --UUSBrl9GXVe8oukFULg4KtKwCTV90NbEi 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 iQIcBAEBAgAGBQJVeaI6AAoJECDuEZm+6Exk9AgQAJfN9OjSLJyOQF+HSRWfjXRw Nz3eX1Hn83PrjvJUUFBxDFqTQQYycjgAAk/vbqCuy/hflRakdlAclXuP+ZiW6y5C eMo9sV8LtaBFqZ45ACrRCFno/gSEq/OWgSa7/EhBiRHBfu0k0x8xJbZMdT1ZPzQM yGG4+DIBQtXj42KzKjYIXs3QRepff3qMXAi/78ksmd5PZ7jNa1x1LTe+qZJP4hUC OJ/2XR6VRD/fLXGzfxgAjZS9Y1f2mno1oxPm91CntnpLPAyBVR/CWCBeCUADcM0E nycezA5h0pUU/53ayWe+TUc9dmKEBQ4SKXdi1PBGK4mBzoDvesQDV9aEq8ujTR3x eHxAOA897No5MrpFBCbE5MwDLYcZFoWY9owBYIuHXCIKBFfXr+GXu7pY6dGIvEKg p8GUk84Y+cvHLSzXbZHJru8YCKUBLsgUMZCKwLMHqeTCLa3oW455hFjombtvVwJ7 FuQV10+BZ8exI14SeyyZfrQJnPeLhS//HWobYq6AL9xLDVmXVf9qP3+U6g8eisyo xHBOL6ZhEHHyIiLISJL4YYAyZzk3Sr843FuEfIr+j6dqO6wlBmuWY3NlsiL3lotN Mb3lorTn4j4LOth3R8C/S5rfWgqpYUXzN77rGUunXcQU4u3Q6fxLp4HpQyK8+CdG /xZwTAbNIawevTIUViey =oPoC -----END PGP SIGNATURE----- --UUSBrl9GXVe8oukFULg4KtKwCTV90NbEi-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 00:11:03 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 8022B726; Fri, 12 Jun 2015 00:11:03 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 5C621175A; Fri, 12 Jun 2015 00:11:03 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=HxTcRrgirz/MGp63FF6dEs/WeN8kZUGPTrcK9vDNEzA=; b=xIB0bbZAqccj5Ru3OLw7wwEKYUrtcPbUiCA4X61wzAw3fOk8wfGCNQZ4eF/ifLntrExu9CNGRKtBc6wA53d5VG9jTlkmOd7Ig+PoJtLa2tO1mrQIueLJP9TKTHKWzu0fIfEUuZLQxRXgP8Z5raAqoWkUic1ZLPyWPivOgJ5kpHI=; Received: from [39.255.137.235] (port=38526 helo=B85M-HD3-0.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.85) (envelope-from ) id 1Z3CYm-0043Qg-Jq; Thu, 11 Jun 2015 18:11:01 -0600 Date: Fri, 12 Jun 2015 08:10:54 +0800 From: Erich Dollansky To: Ian Lepore Cc: Hans Petter Selasky , "freebsd-hackers@freebsd.org\" Subject: Re: allow ffs & co. a binary search Message-ID: <20150612081054.4589dcc7@B85M-HD3-0.alogt.com> In-Reply-To: <1434034310.1415.2.camel@freebsd.org> References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150611152107.61f85189@B85M-HD3-0.alogt.com> <1434027471.1200.401.camel@freebsd.org> <20150611224347.64372a76@B85M-HD3-0.alogt.com> <1434034310.1415.2.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 00:11:03 -0000 Hi, On Thu, 11 Jun 2015 08:51:50 -0600 Ian Lepore wrote: > On Thu, 2015-06-11 at 22:43 +0800, Erich Dollansky wrote: > > Hi, > > > > On Thu, 11 Jun 2015 06:57:51 -0600 > > Ian Lepore wrote: > > > > > On Thu, 2015-06-11 at 15:21 +0800, Erich Dollansky wrote: > > > > On Sun, 07 Jun 2015 08:53:18 +0200 > > > > Hans Petter Selasky wrote: > > > > > > > Is there any reason that this whole change, userland and kernel, > > > isn't just: > > > > > > #define ffs(n) __builtin_ffs(n) > > > > I did not see this. Where is it? > > > > Of course, if this is already done, it does not have to be done > > again. > > > > Erich > > I'm not quite sure what you're asking. Both clang and gcc support > __builtin_ffs(), so I'm saying why don't we just use it and call the > whole problem solved? > so, it is not in the sources yet. Yes, then use it and let the compiler guys crack their heads. Erich From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 00:49:24 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 B54CAF21; Fri, 12 Jun 2015 00:49:24 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 712901FE1; Fri, 12 Jun 2015 00:49:23 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id B068F1FE023; Fri, 12 Jun 2015 02:49:19 +0200 (CEST) Message-ID: <557A2CC0.9010409@selasky.org> Date: Fri, 12 Jun 2015 02:50:08 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Erich Dollansky , Ian Lepore CC: freebsd-hackers@freebsd.org, freebsd-hackers@FreeBSD.org Subject: Re: allow ffs & co. a binary search References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5573EA5E.40806@selasky.org> <20150611152107.61f85189@B85M-HD3-0.alogt.com> <1434027471.1200.401.camel@freebsd.org> <20150611224347.64372a76@B85M-HD3-0.alogt.com> <1434034310.1415.2.camel@freebsd.org> <20150612081054.4589dcc7@B85M-HD3-0.alogt.com> In-Reply-To: <20150612081054.4589dcc7@B85M-HD3-0.alogt.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 00:49:24 -0000 On 06/12/15 02:10, Erich Dollansky wrote: > Hi, > > On Thu, 11 Jun 2015 08:51:50 -0600 > Ian Lepore wrote: > >> On Thu, 2015-06-11 at 22:43 +0800, Erich Dollansky wrote: >>> Hi, >>> >>> On Thu, 11 Jun 2015 06:57:51 -0600 >>> Ian Lepore wrote: >>> >>>> On Thu, 2015-06-11 at 15:21 +0800, Erich Dollansky wrote: >>>>> On Sun, 07 Jun 2015 08:53:18 +0200 >>>>> Hans Petter Selasky wrote: >>>>> >>>> Is there any reason that this whole change, userland and kernel, >>>> isn't just: >>>> >>>> #define ffs(n) __builtin_ffs(n) >>> >>> I did not see this. Where is it? >>> >>> Of course, if this is already done, it does not have to be done >>> again. >>> >>> Erich >> >> I'm not quite sure what you're asking. Both clang and gcc support >> __builtin_ffs(), so I'm saying why don't we just use it and call the >> whole problem solved? >> > so, it is not in the sources yet. Yes, then use it and let the compiler > guys crack their heads. > > Erich Hi, Are we depending on that ffs() is a valid symbol when linking? --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 01:17:54 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 E03513BF; Fri, 12 Jun 2015 01:17:54 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from vsmtp06.dti.ne.jp (vsmtp06.dti.ne.jp [202.216.231.141]) by mx1.freebsd.org (Postfix) with ESMTP id 83EAF17E0; Fri, 12 Jun 2015 01:17:54 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from mail.dream.jp (webmail02.ga.dti.ne.jp [202.216.229.153]) by vsmtp06.dti.ne.jp (3.11v) with ESMTP AUTH id t5C1Hkdb009515; Fri, 12 Jun 2015 10:17:47 +0900 (JST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_63617d2f0e214e52d0427b5986ad3c29" Date: Fri, 12 Jun 2015 10:17:46 +0900 From: To: , Subject: How to implement jail-aware SysV IPC (with my nasty patch) Message-ID: X-Sender: kikuchan@uranus.dti.ne.jp User-Agent: DTI MyMail/0.3-trunk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 01:17:55 -0000 --=_63617d2f0e214e52d0427b5986ad3c29 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=iso-2022-jp Hello, I'm (still) trying to figure out how jail-aware SysV IPC mechanism should be. I want to run PostgreSQL in each jail without changing UID for each jail. If you don't change UID on each jail, it doesn't work due to IPC objects conflict between jails. See also; https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 http://www.freebsddiary.org/jail-multiple.php https://wiki.freebsd.org/Jails https://forums.freebsd.org/threads/postgresql-in-jail.51528/ There is a patch for 4.7-STABLE on bugzilla (see above) to solve the problem by completely separating namespace for each jail in kernel, but I couldn't find any (other) implementation that works on recent FreeBSD. I've also tried to re-write the patch for recent FreeBSD, but I couldn't make it properly due to my limited kernel knowledge ;( Anyway, I created (and update) a patch to trying to solve the problem by simply separating IPC key_t space for each jail. The attached patch can be applied to 10-STABLE (or CURRENT?). After the patch is applied; - IPC objects created on parent jail, are invisible to children. - IPC objects created on neighbor jail, are also invisible each other. - IPC objects craeted on child jail, are VISIBLE from parent. - IPC key_t spaces are separated between jails. If you see the key_t named object from parent, it's shown as IPC_PRIVATE. I choose this design of feature, however, I'm not sure this is the right design for jail-aware IPC. If you prefer the completely separated namespace approach, it's ok. I want to focus on how the IPC mechanism dealing with hierarchical jail system. So I need more feedbacks. Could you help me please? You can dig and play with ipcs(1)/ipcrm(1) to see what happend on each jail. Thanks. -- Kikuchan --=_63617d2f0e214e52d0427b5986ad3c29 Content-Transfer-Encoding: base64 Content-Type: text/x-diff; name=jailed-sysvipc-for-stable10-again.patch; charset=UTF-8 Content-Disposition: attachment; filename=jailed-sysvipc-for-stable10-again.patch ZGlmZiAtLWdpdCBhL3N5cy9rZXJuL2tlcm5famFpbC5jIGIvc3lzL2tlcm4va2Vybl9qYWlsLmMK aW5kZXggZTljNzFjYS4uY2Y2MzE5NiAxMDA2NDQKLS0tIGEvc3lzL2tlcm4va2Vybl9qYWlsLmMK KysrIGIvc3lzL2tlcm4va2Vybl9qYWlsLmMKQEAgLTYwLDYgKzYwLDcgQEAgX19GQlNESUQoIiRG cmVlQlNEJCIpOwogI2luY2x1ZGUgPHN5cy9zeXNjYWxsc3Vici5oPgogI2luY2x1ZGUgPHN5cy9z eXNjdGwuaD4KICNpbmNsdWRlIDxzeXMvdm5vZGUuaD4KKyNpbmNsdWRlIDxzeXMvaXBjLmg+CiAK ICNpbmNsdWRlIDxuZXQvaWYuaD4KICNpbmNsdWRlIDxuZXQvdm5ldC5oPgpAQCAtMjMzMCw2ICsy MzMxLDkgQEAgcHJpc29uX3JlbW92ZV9vbmUoc3RydWN0IHByaXNvbiAqcHIpCiAJCXByLT5wcl9m bGFncyAmPSB+UFJfUEVSU0lTVDsKIAl9CiAKKwkvKiBTeXNWIElQQyBjbGVhbnVwIGZvciB0aGUg cHJpc29uICovCisJaXBjX2NsZWFudXBfZm9yX3ByaXNvbihwcik7CisKIAkvKgogCSAqIGphaWxf cmVtb3ZlIGFkZGVkIGEgcmVmZXJlbmNlLiAgSWYgdGhhdCdzIHRoZSBvbmx5IG9uZSwgcmVtb3Zl CiAJICogdGhlIHByaXNvbiBub3cuCmRpZmYgLS1naXQgYS9zeXMva2Vybi9zeXN2X2lwYy5jIGIv c3lzL2tlcm4vc3lzdl9pcGMuYwppbmRleCBlNDAyY2I1Li45OTg1Yjg3IDEwMDY0NAotLS0gYS9z eXMva2Vybi9zeXN2X2lwYy5jCisrKyBiL3N5cy9rZXJuL3N5c3ZfaXBjLmMKQEAgLTQ3LDkgKzQ3 LDEzIEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxzeXMvcHJpdi5oPgogI2lu Y2x1ZGUgPHN5cy9wcm9jLmg+CiAjaW5jbHVkZSA8c3lzL3VjcmVkLmg+CisjaW5jbHVkZSA8c3lz L2phaWwuaD4KIAogdm9pZCAoKnNobWZvcmtfaG9vaykoc3RydWN0IHByb2MgKiwgc3RydWN0IHBy b2MgKikgPSBOVUxMOwogdm9pZCAoKnNobWV4aXRfaG9vaykoc3RydWN0IHZtc3BhY2UgKikgPSBO VUxMOwordm9pZCAoKnN5c3ZzaG1fY2xlYW51cF9mb3JfcHJpc29uX2hvb2spKHN0cnVjdCBwcmlz b24gKikgPSBOVUxMOwordm9pZCAoKnN5c3Ztc2dfY2xlYW51cF9mb3JfcHJpc29uX2hvb2spKHN0 cnVjdCBwcmlzb24gKikgPSBOVUxMOwordm9pZCAoKnN5c3ZzZW1fY2xlYW51cF9mb3JfcHJpc29u X2hvb2spKHN0cnVjdCBwcmlzb24gKikgPSBOVUxMOwogCiAvKiBjYWxsZWQgZnJvbSBrZXJuX2Zv cmsuYyAqLwogdm9pZApAQCAtNzIsNiArNzYsMTkgQEAgc2htZXhpdChzdHJ1Y3Qgdm1zcGFjZSAq dm0pCiAJcmV0dXJuOwogfQogCisvKiBjYWxsZWQgZnJvbSBrZXJuX2phaWwuYyAqLwordm9pZAor aXBjX2NsZWFudXBfZm9yX3ByaXNvbihzdHJ1Y3QgcHJpc29uICpwcikKK3sKKworCWlmIChzeXN2 c2htX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rICE9IE5VTEwpCisJCXN5c3ZzaG1fY2xlYW51cF9m b3JfcHJpc29uX2hvb2socHIpOworCWlmIChzeXN2bXNnX2NsZWFudXBfZm9yX3ByaXNvbl9ob29r ICE9IE5VTEwpCisJCXN5c3Ztc2dfY2xlYW51cF9mb3JfcHJpc29uX2hvb2socHIpOworCWlmIChz eXN2c2VtX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rICE9IE5VTEwpCisJCXN5c3ZzZW1fY2xlYW51 cF9mb3JfcHJpc29uX2hvb2socHIpOworfQorCiAvKgogICogQ2hlY2sgZm9yIElQQyBwZXJtaXNz aW9uLgogICoKZGlmZiAtLWdpdCBhL3N5cy9rZXJuL3N5c3ZfbXNnLmMgYi9zeXMva2Vybi9zeXN2 X21zZy5jCmluZGV4IGQ1OGNiN2UuLjY4Nzc1YTYgMTAwNjQ0Ci0tLSBhL3N5cy9rZXJuL3N5c3Zf bXNnLmMKKysrIGIvc3lzL2tlcm4vc3lzdl9tc2cuYwpAQCAtNjgsNiArNjgsNyBAQCBfX0ZCU0RJ RCgiJEZyZWVCU0QkIik7CiAjaW5jbHVkZSA8c3lzL3N5c2NhbGxzdWJyLmg+CiAjaW5jbHVkZSA8 c3lzL3N5c2VudC5oPgogI2luY2x1ZGUgPHN5cy9zeXNjdGwuaD4KKyNpbmNsdWRlIDxzeXMvc2J1 Zi5oPgogI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KICNpbmNsdWRlIDxzeXMvamFpbC5oPgogCkBA IC04MCw2ICs4MSw5IEBAIHN0YXRpYyBNQUxMT0NfREVGSU5FKE1fTVNHLCAibXNnIiwgIlNWSUQg Y29tcGF0aWJsZSBtZXNzYWdlIHF1ZXVlcyIpOwogc3RhdGljIGludCBtc2dpbml0KHZvaWQpOwog c3RhdGljIGludCBtc2d1bmxvYWQodm9pZCk7CiBzdGF0aWMgaW50IHN5c3Ztc2dfbW9kbG9hZChz dHJ1Y3QgbW9kdWxlICosIGludCwgdm9pZCAqKTsKK3N0YXRpYyBpbnQgY3JfY2Fuc2VlX21zcShz dHJ1Y3QgdWNyZWQgKiwgc3RydWN0IG1zcWlkX2tlcm5lbCAqKTsKK3N0YXRpYyB2b2lkIG1zcV9y ZW1vdmUoc3RydWN0IG1zcWlkX2tlcm5lbCAqKTsKK3N0YXRpYyB2b2lkIHN5c3Ztc2dfY2xlYW51 cF9mb3JfcHJpc29uX215aG9vayhzdHJ1Y3QgcHJpc29uICopOwogCiAKICNpZmRlZiBNU0dfREVC VUcKQEAgLTI1Nyw2ICsyNjEsNyBAQCBtc2dpbml0KCkKICNlbmRpZgogCX0KIAltdHhfaW5pdCgm bXNxX210eCwgIm1zcSIsIE5VTEwsIE1UWF9ERUYpOworCXN5c3Ztc2dfY2xlYW51cF9mb3JfcHJp c29uX2hvb2sgPSAmc3lzdm1zZ19jbGVhbnVwX2Zvcl9wcmlzb25fbXlob29rOwogCiAJZXJyb3Ig PSBzeXNjYWxsX2hlbHBlcl9yZWdpc3Rlcihtc2dfc3lzY2FsbHMpOwogCWlmIChlcnJvciAhPSAw KQpAQCAtMjgyLDYgKzI4Nyw3IEBAIG1zZ3VubG9hZCgpCiAjaWZkZWYgQ09NUEFUX0ZSRUVCU0Qz MgogCXN5c2NhbGwzMl9oZWxwZXJfdW5yZWdpc3Rlcihtc2czMl9zeXNjYWxscyk7CiAjZW5kaWYK KwlzeXN2bXNnX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rID0gTlVMTDsKIAogCWZvciAobXNxaWQg PSAwOyBtc3FpZCA8IG1zZ2luZm8ubXNnbW5pOyBtc3FpZCsrKSB7CiAJCS8qCkBAIC0zNzIsNiAr Mzc4LDY5IEBAIG1zZ19mcmVlaGRyKG1zZ2hkcikKICNlbmRpZgogfQogCitzdGF0aWMgaW50Citj cl9jYW5zZWVfbXNxKHN0cnVjdCB1Y3JlZCAqY3JlZCwgc3RydWN0IG1zcWlkX2tlcm5lbCAqbXNx a3B0cikKK3sKKworCWlmIChtc3FrcHRyLT5jcmVkID09IE5VTEwgfHwgcHJpc29uX2NoZWNrKGNy ZWQsIG1zcWtwdHItPmNyZWQpKQorCQlyZXR1cm4gKEVJTlZBTCk7CisJcmV0dXJuICgwKTsKK30K Kworc3RhdGljIHZvaWQKK21zcV9yZW1vdmUoc3RydWN0IG1zcWlkX2tlcm5lbCAqbXNxa3B0cikK K3sKKwlzdHJ1Y3QgbXNnICptc2doZHI7CisKKwlyYWNjdF9zdWJfY3JlZChtc3FrcHRyLT5jcmVk LCBSQUNDVF9OTVNHUSwgMSk7CisJcmFjY3Rfc3ViX2NyZWQobXNxa3B0ci0+Y3JlZCwgUkFDQ1Rf TVNHUVFVRVVFRCwgbXNxa3B0ci0+dS5tc2dfcW51bSk7CisJcmFjY3Rfc3ViX2NyZWQobXNxa3B0 ci0+Y3JlZCwgUkFDQ1RfTVNHUVNJWkUsIG1zcWtwdHItPnUubXNnX2NieXRlcyk7CisJY3JmcmVl KG1zcWtwdHItPmNyZWQpOworCW1zcWtwdHItPmNyZWQgPSBOVUxMOworCisJLyogRnJlZSB0aGUg bWVzc2FnZSBoZWFkZXJzICovCisJbXNnaGRyID0gbXNxa3B0ci0+dS5tc2dfZmlyc3Q7CisJd2hp bGUgKG1zZ2hkciAhPSBOVUxMKSB7CisJCXN0cnVjdCBtc2cgKm1zZ2hkcl90bXA7CisKKwkJLyog RnJlZSB0aGUgc2VnbWVudHMgb2YgZWFjaCBtZXNzYWdlICovCisJCW1zcWtwdHItPnUubXNnX2Ni eXRlcyAtPSBtc2doZHItPm1zZ190czsKKwkJbXNxa3B0ci0+dS5tc2dfcW51bS0tOworCQltc2do ZHJfdG1wID0gbXNnaGRyOworCQltc2doZHIgPSBtc2doZHItPm1zZ19uZXh0OworCQltc2dfZnJl ZWhkcihtc2doZHJfdG1wKTsKKwl9CisKKwlpZiAobXNxa3B0ci0+dS5tc2dfY2J5dGVzICE9IDAp CisJCXBhbmljKCJtc2dfY2J5dGVzIGlzIHNjcmV3ZWQgdXAiKTsKKwlpZiAobXNxa3B0ci0+dS5t c2dfcW51bSAhPSAwKQorCQlwYW5pYygibXNnX3FudW0gaXMgc2NyZXdlZCB1cCIpOworCisJbXNx a3B0ci0+dS5tc2dfcWJ5dGVzID0gMDsJLyogTWFyayBpdCBhcyBmcmVlICovCisKKyNpZmRlZiBN QUMKKwltYWNfc3lzdm1zZ19jbGVhbnVwKG1zcWtwdHIpOworI2VuZGlmCisKKwl3YWtldXAobXNx a3B0cik7Cit9CisKK3N0YXRpYyB2b2lkCitzeXN2bXNnX2NsZWFudXBfZm9yX3ByaXNvbl9teWhv b2soc3RydWN0IHByaXNvbiAqcHIpCit7CisJaW50IGk7CisJc3RydWN0IG1zcWlkX2tlcm5lbCAq bXNxa3B0cjsKKworCW10eF9sb2NrKCZtc3FfbXR4KTsKKwlmb3IgKGkgPSAwOyBpIDwgbXNnaW5m by5tc2dtbmk7IGkrKykgeworCQltc3FrcHRyID0gJm1zcWlkc1tpXTsKKwkJaWYgKG1zcWtwdHIt PnUubXNnX3FieXRlcyAhPSAwICYmCisJCSAgICBtc3FrcHRyLT5jcmVkICYmIG1zcWtwdHItPmNy ZWQtPmNyX3ByaXNvbiA9PSBwcikKKwkJCW1zcV9yZW1vdmUobXNxa3B0cik7CisJfQorCW10eF91 bmxvY2soJm1zcV9tdHgpOworfQorCiAjaWZuZGVmIF9TWVNfU1lTUFJPVE9fSF8KIHN0cnVjdCBt c2djdGxfYXJncyB7CiAJaW50CW1zcWlkOwpAQCAtNDMzLDYgKzUwMiw5IEBAIGtlcm5fbXNnY3Rs KHRkLCBtc3FpZCwgY21kLCBtc3FidWYpCiAJCWVycm9yID0gRUlOVkFMOwogCQlnb3RvIGRvbmUy OwogCX0KKwllcnJvciA9IGNyX2NhbnNlZV9tc3EodGQtPnRkX3VjcmVkLCBtc3FrcHRyKTsKKwlp ZiAoZXJyb3IgIT0gMCkKKwkJZ290byBkb25lMjsKICNpZmRlZiBNQUMKIAllcnJvciA9IG1hY19z eXN2bXNxX2NoZWNrX21zcWN0bCh0ZC0+dGRfdWNyZWQsIG1zcWtwdHIsIGNtZCk7CiAJaWYgKGVy cm9yICE9IDApCkBAIC00NDYsNyArNTE4LDkgQEAga2Vybl9tc2djdGwodGQsIG1zcWlkLCBjbWQs IG1zcWJ1ZikKIAogCWNhc2UgSVBDX1JNSUQ6CiAJeworI2lmZGVmIE1BQwogCQlzdHJ1Y3QgbXNn ICptc2doZHI7CisjZW5kaWYKIAkJaWYgKChlcnJvciA9IGlwY3Blcm0odGQsICZtc3FrcHRyLT51 Lm1zZ19wZXJtLCBJUENfTSkpKQogCQkJZ290byBkb25lMjsKIApAQCAtNDY4LDM3ICs1NDIsNyBA QCBrZXJuX21zZ2N0bCh0ZCwgbXNxaWQsIGNtZCwgbXNxYnVmKQogCQl9CiAjZW5kaWYKIAotCQly YWNjdF9zdWJfY3JlZChtc3FrcHRyLT5jcmVkLCBSQUNDVF9OTVNHUSwgMSk7Ci0JCXJhY2N0X3N1 Yl9jcmVkKG1zcWtwdHItPmNyZWQsIFJBQ0NUX01TR1FRVUVVRUQsIG1zcWtwdHItPnUubXNnX3Fu dW0pOwotCQlyYWNjdF9zdWJfY3JlZChtc3FrcHRyLT5jcmVkLCBSQUNDVF9NU0dRU0laRSwgbXNx a3B0ci0+dS5tc2dfY2J5dGVzKTsKLQkJY3JmcmVlKG1zcWtwdHItPmNyZWQpOwotCQltc3FrcHRy LT5jcmVkID0gTlVMTDsKLQotCQkvKiBGcmVlIHRoZSBtZXNzYWdlIGhlYWRlcnMgKi8KLQkJbXNn aGRyID0gbXNxa3B0ci0+dS5tc2dfZmlyc3Q7Ci0JCXdoaWxlIChtc2doZHIgIT0gTlVMTCkgewot CQkJc3RydWN0IG1zZyAqbXNnaGRyX3RtcDsKLQotCQkJLyogRnJlZSB0aGUgc2VnbWVudHMgb2Yg ZWFjaCBtZXNzYWdlICovCi0JCQltc3FrcHRyLT51Lm1zZ19jYnl0ZXMgLT0gbXNnaGRyLT5tc2df dHM7Ci0JCQltc3FrcHRyLT51Lm1zZ19xbnVtLS07Ci0JCQltc2doZHJfdG1wID0gbXNnaGRyOwot CQkJbXNnaGRyID0gbXNnaGRyLT5tc2dfbmV4dDsKLQkJCW1zZ19mcmVlaGRyKG1zZ2hkcl90bXAp OwotCQl9Ci0KLQkJaWYgKG1zcWtwdHItPnUubXNnX2NieXRlcyAhPSAwKQotCQkJcGFuaWMoIm1z Z19jYnl0ZXMgaXMgc2NyZXdlZCB1cCIpOwotCQlpZiAobXNxa3B0ci0+dS5tc2dfcW51bSAhPSAw KQotCQkJcGFuaWMoIm1zZ19xbnVtIGlzIHNjcmV3ZWQgdXAiKTsKLQotCQltc3FrcHRyLT51Lm1z Z19xYnl0ZXMgPSAwOwkvKiBNYXJrIGl0IGFzIGZyZWUgKi8KLQotI2lmZGVmIE1BQwotCQltYWNf c3lzdm1zcV9jbGVhbnVwKG1zcWtwdHIpOwotI2VuZGlmCi0KLQkJd2FrZXVwKG1zcWtwdHIpOwor CQltc3FfcmVtb3ZlKG1zcWtwdHIpOwogCX0KIAogCQlicmVhazsKQEAgLTU3OCw2ICs2MjIsNyBA QCBzeXNfbXNnZ2V0KHRkLCB1YXApCiAJCWZvciAobXNxaWQgPSAwOyBtc3FpZCA8IG1zZ2luZm8u bXNnbW5pOyBtc3FpZCsrKSB7CiAJCQltc3FrcHRyID0gJm1zcWlkc1ttc3FpZF07CiAJCQlpZiAo bXNxa3B0ci0+dS5tc2dfcWJ5dGVzICE9IDAgJiYKKwkJCSAgICBtc3FrcHRyLT5jcmVkICYmIG1z cWtwdHItPmNyZWQtPmNyX3ByaXNvbiA9PSBjcmVkLT5jcl9wcmlzb24gJiYKIAkJCSAgICBtc3Fr cHRyLT51Lm1zZ19wZXJtLmtleSA9PSBrZXkpCiAJCQkJYnJlYWs7CiAJCX0KQEAgLTcxOCw2ICs3 NjMsOCBAQCBrZXJuX21zZ3NuZCh0ZCwgbXNxaWQsIG1zZ3AsIG1zZ3N6LCBtc2dmbGcsIG10eXBl KQogCQlnb3RvIGRvbmUyOwogCX0KIAorCWlmICgoZXJyb3IgPSBjcl9jYW5zZWVfbXNxKHRkLT50 ZF91Y3JlZCwgbXNxa3B0cikpKQorCQlnb3RvIGRvbmUyOwogCWlmICgoZXJyb3IgPSBpcGNwZXJt KHRkLCAmbXNxa3B0ci0+dS5tc2dfcGVybSwgSVBDX1cpKSkgewogCQlEUFJJTlRGKCgicmVxdWVz dGVyIGRvZXNuJ3QgaGF2ZSB3cml0ZSBhY2Nlc3NcbiIpKTsKIAkJZ290byBkb25lMjsKQEAgLTEw ODEsNiArMTEyOCw4IEBAIGtlcm5fbXNncmN2KHRkLCBtc3FpZCwgbXNncCwgbXNnc3osIG1zZ3R5 cCwgbXNnZmxnLCBtdHlwZSkKIAkJZ290byBkb25lMjsKIAl9CiAKKwlpZiAoKGVycm9yID0gY3Jf Y2Fuc2VlX21zcSh0ZC0+dGRfdWNyZWQsIG1zcWtwdHIpKSkKKwkJZ290byBkb25lMjsKIAlpZiAo KGVycm9yID0gaXBjcGVybSh0ZCwgJm1zcWtwdHItPnUubXNnX3Blcm0sIElQQ19SKSkpIHsKIAkJ RFBSSU5URigoInJlcXVlc3RlciBkb2Vzbid0IGhhdmUgcmVhZCBhY2Nlc3NcbiIpKTsKIAkJZ290 byBkb25lMjsKQEAgLTEzMjAsOSArMTM2OSwzNyBAQCBzeXNfbXNncmN2KHRkLCB1YXApCiBzdGF0 aWMgaW50CiBzeXNjdGxfbXNxaWRzKFNZU0NUTF9IQU5ETEVSX0FSR1MpCiB7CisJaW50IGVycm9y OworCXN0cnVjdCBzYnVmIHNiOworCXN0cnVjdCBtc3FpZF9rZXJuZWwgdG1wLCBlbXB0eTsKKwlp bnQgaTsKKworCWVycm9yID0gc3lzY3RsX3dpcmVfb2xkX2J1ZmZlcihyZXEsIDApOworCWlmIChl cnJvciAhPSAwKQorCQlnb3RvIGRvbmU7CisJc2J1Zl9uZXdfZm9yX3N5c2N0bCgmc2IsIE5VTEws IHNpemVvZihzdHJ1Y3QgbXNxaWRfa2VybmVsKSAqIG1zZ2luZm8ubXNnbW5pLCByZXEpOworCisJ Ynplcm8oJmVtcHR5LCBzaXplb2YoZW1wdHkpKTsKKwlmb3IgKGkgPSAwOyBpIDwgbXNnaW5mby5t c2dtbmk7IGkrKykgeworCQlzdHJ1Y3QgbXNxaWRfa2VybmVsICptc3FrcHRyOworCisJCW1zcWtw dHIgPSAmbXNxaWRzW2ldOworCQlpZiAobXNxa3B0ci0+dS5tc2dfcWJ5dGVzID09IDAgfHwKKwkJ ICAgIGNyX2NhbnNlZV9tc3EocmVxLT50ZC0+dGRfdWNyZWQsIG1zcWtwdHIpKSB7CisJCQltc3Fr cHRyID0gJmVtcHR5OworCQl9IGVsc2UgaWYgKHJlcS0+dGQtPnRkX3VjcmVkLT5jcl9wcmlzb24g IT0gbXNxa3B0ci0+Y3JlZC0+Y3JfcHJpc29uKSB7CisJCQliY29weShtc3FrcHRyLCAmdG1wLCBz aXplb2YodG1wKSk7CisJCQltc3FrcHRyID0gJnRtcDsKKwkJCW1zcWtwdHItPnUubXNnX3Blcm0u a2V5ID0gSVBDX1BSSVZBVEU7CisJCX0KIAotCXJldHVybiAoU1lTQ1RMX09VVChyZXEsIG1zcWlk cywKLQkgICAgc2l6ZW9mKHN0cnVjdCBtc3FpZF9rZXJuZWwpICogbXNnaW5mby5tc2dtbmkpKTsK KwkJc2J1Zl9iY2F0KCZzYiwgbXNxa3B0ciwgc2l6ZW9mKCptc3FrcHRyKSk7CisJfQorCWVycm9y ID0gc2J1Zl9maW5pc2goJnNiKTsKKwlzYnVmX2RlbGV0ZSgmc2IpOworCitkb25lOgorCXJldHVy biAoZXJyb3IpOwogfQogCiBTWVNDVExfSU5UKF9rZXJuX2lwYywgT0lEX0FVVE8sIG1zZ21heCwg Q1RMRkxBR19SRCwgJm1zZ2luZm8ubXNnbWF4LCAwLApkaWZmIC0tZ2l0IGEvc3lzL2tlcm4vc3lz dl9zZW0uYyBiL3N5cy9rZXJuL3N5c3Zfc2VtLmMKaW5kZXggZjlmZjIxNy4uNWI5ZTFjYSAxMDA2 NDQKLS0tIGEvc3lzL2tlcm4vc3lzdl9zZW0uYworKysgYi9zeXMva2Vybi9zeXN2X3NlbS5jCkBA IC01Nyw2ICs1Nyw3IEBAIF9fRkJTRElEKCIkRnJlZUJTRCQiKTsKICNpbmNsdWRlIDxzeXMvc3lz Y2FsbHN1YnIuaD4KICNpbmNsdWRlIDxzeXMvc3lzZW50Lmg+CiAjaW5jbHVkZSA8c3lzL3N5c2N0 bC5oPgorI2luY2x1ZGUgPHN5cy9zYnVmLmg+CiAjaW5jbHVkZSA8c3lzL3Vpby5oPgogI2luY2x1 ZGUgPHN5cy9tYWxsb2MuaD4KICNpbmNsdWRlIDxzeXMvamFpbC5oPgpAQCAtNzksNiArODAsOSBA QCBzdGF0aWMgaW50IHNlbXVubG9hZCh2b2lkKTsKIHN0YXRpYyB2b2lkIHNlbWV4aXRfbXlob29r KHZvaWQgKmFyZywgc3RydWN0IHByb2MgKnApOwogc3RhdGljIGludCBzeXNjdGxfc2VtYShTWVND VExfSEFORExFUl9BUkdTKTsKIHN0YXRpYyBpbnQgc2VtdmFsaWQoaW50IHNlbWlkLCBzdHJ1Y3Qg c2VtaWRfa2VybmVsICpzZW1ha3B0cik7CitzdGF0aWMgaW50IGNyX2NhbnNlZV9zZW0oc3RydWN0 IHVjcmVkICpjcmVkLCBzdHJ1Y3Qgc2VtaWRfa2VybmVsICpzZW1ha3B0cik7CitzdGF0aWMgdm9p ZCBzZW1fcmVtb3ZlKGludCBzZW1pZHgsIHN0cnVjdCB1Y3JlZCAqY3JlZCk7CitzdGF0aWMgdm9p ZCBzeXN2c2VtX2NsZWFudXBfZm9yX3ByaXNvbl9teWhvb2soc3RydWN0IHByaXNvbiAqcHIpOwog CiAjaWZuZGVmIF9TWVNfU1lTUFJPVE9fSF8KIHN0cnVjdCBfX3NlbWN0bF9hcmdzOwpAQCAtMjg3 LDYgKzI5MSw3IEBAIHNlbWluaXQodm9pZCkKIAltdHhfaW5pdCgmc2VtX3VuZG9fbXR4LCAic2Vt dSIsIE5VTEwsIE1UWF9ERUYpOwogCXNlbWV4aXRfdGFnID0gRVZFTlRIQU5ETEVSX1JFR0lTVEVS KHByb2Nlc3NfZXhpdCwgc2VtZXhpdF9teWhvb2ssIE5VTEwsCiAJICAgIEVWRU5USEFORExFUl9Q UklfQU5ZKTsKKwlzeXN2c2VtX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rID0gJnN5c3ZzZW1fY2xl YW51cF9mb3JfcHJpc29uX215aG9vazsKIAogCWVycm9yID0gc3lzY2FsbF9oZWxwZXJfcmVnaXN0 ZXIoc2VtX3N5c2NhbGxzKTsKIAlpZiAoZXJyb3IgIT0gMCkKQEAgLTMxMyw2ICszMTgsNyBAQCBz ZW11bmxvYWQodm9pZCkKICNlbmRpZgogCXN5c2NhbGxfaGVscGVyX3VucmVnaXN0ZXIoc2VtX3N5 c2NhbGxzKTsKIAlFVkVOVEhBTkRMRVJfREVSRUdJU1RFUihwcm9jZXNzX2V4aXQsIHNlbWV4aXRf dGFnKTsKKwlzeXN2c2VtX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rID0gTlVMTDsKICNpZmRlZiBN QUMKIAlmb3IgKGkgPSAwOyBpIDwgc2VtaW5mby5zZW1tbmk7IGkrKykKIAkJbWFjX3N5c3ZzZW1f ZGVzdHJveSgmc2VtYVtpXSk7CkBAIC01MDYsNiArNTEyLDcwIEBAIHNlbXZhbGlkKGludCBzZW1p ZCwgc3RydWN0IHNlbWlkX2tlcm5lbCAqc2VtYWtwdHIpCiAJICAgIHNlbWFrcHRyLT51LnNlbV9w ZXJtLnNlcSAhPSBJUENJRF9UT19TRVEoc2VtaWQpID8gRUlOVkFMIDogMCk7CiB9CiAKK3N0YXRp YyBpbnQKK2NyX2NhbnNlZV9zZW0oc3RydWN0IHVjcmVkICpjcmVkLCBzdHJ1Y3Qgc2VtaWRfa2Vy bmVsICpzZW1ha3B0cikKK3sKKworCWlmIChzZW1ha3B0ci0+Y3JlZCA9PSBOVUxMIHx8IHByaXNv bl9jaGVjayhjcmVkLCBzZW1ha3B0ci0+Y3JlZCkpCisJCXJldHVybiAoRUlOVkFMKTsKKwlyZXR1 cm4gKDApOworfQorCitzdGF0aWMgdm9pZAorc2VtX3JlbW92ZShpbnQgc2VtaWR4LCBzdHJ1Y3Qg dWNyZWQgKmNyZWQpCit7CisJaW50IGk7CisJc3RydWN0IHNlbWlkX2tlcm5lbCAqc2VtYWtwdHI7 CisKKwlLQVNTRVJUKHNlbWlkeCA+PSAwICYmIHNlbWlkeCA8IHNlbWluZm8uc2VtbW5pLCAoInNl bWlkeCBvdXQgb2YgYm91bmRzIikpOworCXNlbWFrcHRyID0gJnNlbWFbc2VtaWR4XTsKKwlzZW1h a3B0ci0+dS5zZW1fcGVybS5jdWlkID0gY3JlZCA/IGNyZWQtPmNyX3VpZCA6IDA7CisJc2VtYWtw dHItPnUuc2VtX3Blcm0udWlkID0gY3JlZCA/IGNyZWQtPmNyX3VpZCA6IDA7CisJc2VtYWtwdHIt PnUuc2VtX3Blcm0ubW9kZSA9IDA7CisJcmFjY3Rfc3ViX2NyZWQoc2VtYWtwdHItPmNyZWQsIFJB Q0NUX05TRU0sIHNlbWFrcHRyLT51LnNlbV9uc2Vtcyk7CisJY3JmcmVlKHNlbWFrcHRyLT5jcmVk KTsKKwlzZW1ha3B0ci0+Y3JlZCA9IE5VTEw7CisJU0VNVU5ET19MT0NLKCk7CisJc2VtdW5kb19j bGVhcihzZW1pZHgsIC0xKTsKKwlTRU1VTkRPX1VOTE9DSygpOworI2lmZGVmIE1BQworCW1hY19z eXN2c2VtX2NsZWFudXAoc2VtYWtwdHIpOworI2VuZGlmCisJd2FrZXVwKHNlbWFrcHRyKTsKKwlm b3IgKGkgPSAwOyBpIDwgc2VtaW5mby5zZW1tbmk7IGkrKykgeworCQlpZiAoKHNlbWFbaV0udS5z ZW1fcGVybS5tb2RlICYgU0VNX0FMTE9DKSAmJgorCQkgICAgc2VtYVtpXS51LnNlbV9iYXNlID4g c2VtYWtwdHItPnUuc2VtX2Jhc2UpCisJCQltdHhfbG9ja19mbGFncygmc2VtYV9tdHhbaV0sIExP UF9EVVBPSyk7CisJfQorCWZvciAoaSA9IHNlbWFrcHRyLT51LnNlbV9iYXNlIC0gc2VtOyBpIDwg c2VtdG90OyBpKyspCisJCXNlbVtpXSA9IHNlbVtpICsgc2VtYWtwdHItPnUuc2VtX25zZW1zXTsK Kwlmb3IgKGkgPSAwOyBpIDwgc2VtaW5mby5zZW1tbmk7IGkrKykgeworCQlpZiAoKHNlbWFbaV0u dS5zZW1fcGVybS5tb2RlICYgU0VNX0FMTE9DKSAmJgorCQkgICAgc2VtYVtpXS51LnNlbV9iYXNl ID4gc2VtYWtwdHItPnUuc2VtX2Jhc2UpIHsKKwkJCXNlbWFbaV0udS5zZW1fYmFzZSAtPSBzZW1h a3B0ci0+dS5zZW1fbnNlbXM7CisJCQltdHhfdW5sb2NrKCZzZW1hX210eFtpXSk7CisJCX0KKwl9 CisJc2VtdG90IC09IHNlbWFrcHRyLT51LnNlbV9uc2VtczsKK30KKworc3RhdGljIHZvaWQKK3N5 c3ZzZW1fY2xlYW51cF9mb3JfcHJpc29uX215aG9vayhzdHJ1Y3QgcHJpc29uICpwcikKK3sKKwlp bnQgaTsKKworCW10eF9sb2NrKCZzZW1fbXR4KTsKKwlmb3IgKGkgPSAwOyBpIDwgc2VtaW5mby5z ZW1tbmk7IGkrKykgeworCQlpZiAoKHNlbWFbaV0udS5zZW1fcGVybS5tb2RlICYgU0VNX0FMTE9D KSAmJgorCQkgICAgc2VtYVtpXS5jcmVkICYmIHNlbWFbaV0uY3JlZC0+Y3JfcHJpc29uID09IHBy KSB7CisJCQltdHhfbG9jaygmc2VtYV9tdHhbaV0pOworCQkJc2VtX3JlbW92ZShpLCBOVUxMKTsK KwkJCW10eF91bmxvY2soJnNlbWFfbXR4W2ldKTsKKwkJfQorCX0KKwltdHhfdW5sb2NrKCZzZW1f bXR4KTsKK30KKwogLyoKICAqIE5vdGUgdGhhdCB0aGUgdXNlci1tb2RlIGhhbGYgb2YgdGhpcyBw YXNzZXMgYSB1bmlvbiwgbm90IGEgcG9pbnRlci4KICAqLwpAQCAtNjEwLDYgKzY4MCw4IEBAIGtl cm5fc2VtY3RsKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQgc2VtaWQsIGludCBzZW1udW0sIGludCBj bWQsCiAJCQllcnJvciA9IEVJTlZBTDsKIAkJCWdvdG8gZG9uZTI7CiAJCX0KKwkJaWYgKChlcnJv ciA9IGNyX2NhbnNlZV9zZW0odGQtPnRkX3VjcmVkLCBzZW1ha3B0cikpICE9IDApCisJCQlnb3Rv IGRvbmUyOwogCQlpZiAoKGVycm9yID0gaXBjcGVybSh0ZCwgJnNlbWFrcHRyLT51LnNlbV9wZXJt LCBJUENfUikpKQogCQkJZ290byBkb25lMjsKICNpZmRlZiBNQUMKQEAgLTYzMiw2ICs3MDQsNyBA QCBrZXJuX3NlbWN0bChzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHNlbWlkLCBpbnQgc2VtbnVtLCBp bnQgY21kLAogCWlmIChjbWQgPT0gSVBDX1JNSUQpCiAJCW10eF9sb2NrKCZzZW1fbXR4KTsKIAlt dHhfbG9jayhzZW1hX210eHApOworCiAjaWZkZWYgTUFDCiAJZXJyb3IgPSBtYWNfc3lzdnNlbV9j aGVja19zZW1jdGwoY3JlZCwgc2VtYWtwdHIsIGNtZCk7CiAJaWYgKGVycm9yICE9IDApCkBAIC02 NDUsNDEgKzcxOCwxOCBAQCBrZXJuX3NlbWN0bChzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHNlbWlk LCBpbnQgc2VtbnVtLCBpbnQgY21kLAogCWNhc2UgSVBDX1JNSUQ6CiAJCWlmICgoZXJyb3IgPSBz ZW12YWxpZChzZW1pZCwgc2VtYWtwdHIpKSAhPSAwKQogCQkJZ290byBkb25lMjsKKwkJaWYgKChl cnJvciA9IGNyX2NhbnNlZV9zZW0odGQtPnRkX3VjcmVkLCBzZW1ha3B0cikpICE9IDApCisJCQln b3RvIGRvbmUyOwogCQlpZiAoKGVycm9yID0gaXBjcGVybSh0ZCwgJnNlbWFrcHRyLT51LnNlbV9w ZXJtLCBJUENfTSkpKQogCQkJZ290byBkb25lMjsKLQkJc2VtYWtwdHItPnUuc2VtX3Blcm0uY3Vp ZCA9IGNyZWQtPmNyX3VpZDsKLQkJc2VtYWtwdHItPnUuc2VtX3Blcm0udWlkID0gY3JlZC0+Y3Jf dWlkOwotCQlzZW1ha3B0ci0+dS5zZW1fcGVybS5tb2RlID0gMDsKLQkJcmFjY3Rfc3ViX2NyZWQo c2VtYWtwdHItPmNyZWQsIFJBQ0NUX05TRU0sIHNlbWFrcHRyLT51LnNlbV9uc2Vtcyk7Ci0JCWNy ZnJlZShzZW1ha3B0ci0+Y3JlZCk7Ci0JCXNlbWFrcHRyLT5jcmVkID0gTlVMTDsKLQkJU0VNVU5E T19MT0NLKCk7Ci0JCXNlbXVuZG9fY2xlYXIoc2VtaWR4LCAtMSk7Ci0JCVNFTVVORE9fVU5MT0NL KCk7Ci0jaWZkZWYgTUFDCi0JCW1hY19zeXN2c2VtX2NsZWFudXAoc2VtYWtwdHIpOwotI2VuZGlm Ci0JCXdha2V1cChzZW1ha3B0cik7Ci0JCWZvciAoaSA9IDA7IGkgPCBzZW1pbmZvLnNlbW1uaTsg aSsrKSB7Ci0JCQlpZiAoKHNlbWFbaV0udS5zZW1fcGVybS5tb2RlICYgU0VNX0FMTE9DKSAmJgot CQkJICAgIHNlbWFbaV0udS5zZW1fYmFzZSA+IHNlbWFrcHRyLT51LnNlbV9iYXNlKQotCQkJCW10 eF9sb2NrX2ZsYWdzKCZzZW1hX210eFtpXSwgTE9QX0RVUE9LKTsKLQkJfQotCQlmb3IgKGkgPSBz ZW1ha3B0ci0+dS5zZW1fYmFzZSAtIHNlbTsgaSA8IHNlbXRvdDsgaSsrKQotCQkJc2VtW2ldID0g c2VtW2kgKyBzZW1ha3B0ci0+dS5zZW1fbnNlbXNdOwotCQlmb3IgKGkgPSAwOyBpIDwgc2VtaW5m by5zZW1tbmk7IGkrKykgewotCQkJaWYgKChzZW1hW2ldLnUuc2VtX3Blcm0ubW9kZSAmIFNFTV9B TExPQykgJiYKLQkJCSAgICBzZW1hW2ldLnUuc2VtX2Jhc2UgPiBzZW1ha3B0ci0+dS5zZW1fYmFz ZSkgewotCQkJCXNlbWFbaV0udS5zZW1fYmFzZSAtPSBzZW1ha3B0ci0+dS5zZW1fbnNlbXM7Ci0J CQkJbXR4X3VubG9jaygmc2VtYV9tdHhbaV0pOwotCQkJfQotCQl9Ci0JCXNlbXRvdCAtPSBzZW1h a3B0ci0+dS5zZW1fbnNlbXM7CisJCXNlbV9yZW1vdmUoc2VtaWR4LCBjcmVkKTsKIAkJYnJlYWs7 CiAKIAljYXNlIElQQ19TRVQ6CiAJCWlmICgoZXJyb3IgPSBzZW12YWxpZChzZW1pZCwgc2VtYWtw dHIpKSAhPSAwKQogCQkJZ290byBkb25lMjsKKwkJaWYgKChlcnJvciA9IGNyX2NhbnNlZV9zZW0o dGQtPnRkX3VjcmVkLCBzZW1ha3B0cikpICE9IDApCisJCQlnb3RvIGRvbmUyOwogCQlpZiAoKGVy cm9yID0gaXBjcGVybSh0ZCwgJnNlbWFrcHRyLT51LnNlbV9wZXJtLCBJUENfTSkpKQogCQkJZ290 byBkb25lMjsKIAkJc2J1ZiA9IGFyZy0+YnVmOwpAQCAtNjkzLDYgKzc0Myw4IEBAIGtlcm5fc2Vt Y3RsKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQgc2VtaWQsIGludCBzZW1udW0sIGludCBjbWQsCiAJ Y2FzZSBJUENfU1RBVDoKIAkJaWYgKChlcnJvciA9IHNlbXZhbGlkKHNlbWlkLCBzZW1ha3B0cikp ICE9IDApCiAJCQlnb3RvIGRvbmUyOworCQlpZiAoKGVycm9yID0gY3JfY2Fuc2VlX3NlbSh0ZC0+ dGRfdWNyZWQsIHNlbWFrcHRyKSkgIT0gMCkKKwkJCWdvdG8gZG9uZTI7CiAJCWlmICgoZXJyb3Ig PSBpcGNwZXJtKHRkLCAmc2VtYWtwdHItPnUuc2VtX3Blcm0sIElQQ19SKSkpCiAJCQlnb3RvIGRv bmUyOwogCQliY29weSgmc2VtYWtwdHItPnUsIGFyZy0+YnVmLCBzaXplb2Yoc3RydWN0IHNlbWlk X2RzKSk7CkBAIC03MDEsNiArNzUzLDggQEAga2Vybl9zZW1jdGwoc3RydWN0IHRocmVhZCAqdGQs IGludCBzZW1pZCwgaW50IHNlbW51bSwgaW50IGNtZCwKIAljYXNlIEdFVE5DTlQ6CiAJCWlmICgo ZXJyb3IgPSBzZW12YWxpZChzZW1pZCwgc2VtYWtwdHIpKSAhPSAwKQogCQkJZ290byBkb25lMjsK KwkJaWYgKChlcnJvciA9IGNyX2NhbnNlZV9zZW0odGQtPnRkX3VjcmVkLCBzZW1ha3B0cikpICE9 IDApCisJCQlnb3RvIGRvbmUyOwogCQlpZiAoKGVycm9yID0gaXBjcGVybSh0ZCwgJnNlbWFrcHRy LT51LnNlbV9wZXJtLCBJUENfUikpKQogCQkJZ290byBkb25lMjsKIAkJaWYgKHNlbW51bSA8IDAg fHwgc2VtbnVtID49IHNlbWFrcHRyLT51LnNlbV9uc2VtcykgewpAQCAtNzEzLDYgKzc2Nyw4IEBA IGtlcm5fc2VtY3RsKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQgc2VtaWQsIGludCBzZW1udW0sIGlu dCBjbWQsCiAJY2FzZSBHRVRQSUQ6CiAJCWlmICgoZXJyb3IgPSBzZW12YWxpZChzZW1pZCwgc2Vt YWtwdHIpKSAhPSAwKQogCQkJZ290byBkb25lMjsKKwkJaWYgKChlcnJvciA9IGNyX2NhbnNlZV9z ZW0odGQtPnRkX3VjcmVkLCBzZW1ha3B0cikpICE9IDApCisJCQlnb3RvIGRvbmUyOwogCQlpZiAo KGVycm9yID0gaXBjcGVybSh0ZCwgJnNlbWFrcHRyLT51LnNlbV9wZXJtLCBJUENfUikpKQogCQkJ Z290byBkb25lMjsKIAkJaWYgKHNlbW51bSA8IDAgfHwgc2VtbnVtID49IHNlbWFrcHRyLT51LnNl bV9uc2VtcykgewpAQCAtNzI1LDYgKzc4MSw4IEBAIGtlcm5fc2VtY3RsKHN0cnVjdCB0aHJlYWQg KnRkLCBpbnQgc2VtaWQsIGludCBzZW1udW0sIGludCBjbWQsCiAJY2FzZSBHRVRWQUw6CiAJCWlm ICgoZXJyb3IgPSBzZW12YWxpZChzZW1pZCwgc2VtYWtwdHIpKSAhPSAwKQogCQkJZ290byBkb25l MjsKKwkJaWYgKChlcnJvciA9IGNyX2NhbnNlZV9zZW0odGQtPnRkX3VjcmVkLCBzZW1ha3B0cikp ICE9IDApCisJCQlnb3RvIGRvbmUyOwogCQlpZiAoKGVycm9yID0gaXBjcGVybSh0ZCwgJnNlbWFr cHRyLT51LnNlbV9wZXJtLCBJUENfUikpKQogCQkJZ290byBkb25lMjsKIAkJaWYgKHNlbW51bSA8 IDAgfHwgc2VtbnVtID49IHNlbWFrcHRyLT51LnNlbV9uc2VtcykgewpAQCAtNzYyLDYgKzgyMCw4 IEBAIGtlcm5fc2VtY3RsKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQgc2VtaWQsIGludCBzZW1udW0s IGludCBjbWQsCiAJCWlmICgoZXJyb3IgPSBzZW12YWxpZChzZW1pZCwgc2VtYWtwdHIpKSAhPSAw KQogCQkJZ290byBkb25lMjsKIAkJS0FTU0VSVChjb3VudCA9PSBzZW1ha3B0ci0+dS5zZW1fbnNl bXMsICgibnNlbXMgY2hhbmdlZCIpKTsKKwkJaWYgKChlcnJvciA9IGNyX2NhbnNlZV9zZW0odGQt PnRkX3VjcmVkLCBzZW1ha3B0cikpICE9IDApCisJCQlnb3RvIGRvbmUyOwogCQlpZiAoKGVycm9y ID0gaXBjcGVybSh0ZCwgJnNlbWFrcHRyLT51LnNlbV9wZXJtLCBJUENfUikpKQogCQkJZ290byBk b25lMjsKIAkJZm9yIChpID0gMDsgaSA8IHNlbWFrcHRyLT51LnNlbV9uc2VtczsgaSsrKQpAQCAt Nzc0LDYgKzgzNCw4IEBAIGtlcm5fc2VtY3RsKHN0cnVjdCB0aHJlYWQgKnRkLCBpbnQgc2VtaWQs IGludCBzZW1udW0sIGludCBjbWQsCiAJY2FzZSBHRVRaQ05UOgogCQlpZiAoKGVycm9yID0gc2Vt dmFsaWQoc2VtaWQsIHNlbWFrcHRyKSkgIT0gMCkKIAkJCWdvdG8gZG9uZTI7CisJCWlmICgoZXJy b3IgPSBjcl9jYW5zZWVfc2VtKHRkLT50ZF91Y3JlZCwgc2VtYWtwdHIpKSAhPSAwKQorCQkJZ290 byBkb25lMjsKIAkJaWYgKChlcnJvciA9IGlwY3Blcm0odGQsICZzZW1ha3B0ci0+dS5zZW1fcGVy bSwgSVBDX1IpKSkKIAkJCWdvdG8gZG9uZTI7CiAJCWlmIChzZW1udW0gPCAwIHx8IHNlbW51bSA+ PSBzZW1ha3B0ci0+dS5zZW1fbnNlbXMpIHsKQEAgLTc4Niw2ICs4NDgsOCBAQCBrZXJuX3NlbWN0 bChzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHNlbWlkLCBpbnQgc2VtbnVtLCBpbnQgY21kLAogCWNh c2UgU0VUVkFMOgogCQlpZiAoKGVycm9yID0gc2VtdmFsaWQoc2VtaWQsIHNlbWFrcHRyKSkgIT0g MCkKIAkJCWdvdG8gZG9uZTI7CisJCWlmICgoZXJyb3IgPSBjcl9jYW5zZWVfc2VtKHRkLT50ZF91 Y3JlZCwgc2VtYWtwdHIpKSAhPSAwKQorCQkJZ290byBkb25lMjsKIAkJaWYgKChlcnJvciA9IGlw Y3Blcm0odGQsICZzZW1ha3B0ci0+dS5zZW1fcGVybSwgSVBDX1cpKSkKIAkJCWdvdG8gZG9uZTI7 CiAJCWlmIChzZW1udW0gPCAwIHx8IHNlbW51bSA+PSBzZW1ha3B0ci0+dS5zZW1fbnNlbXMpIHsK QEAgLTgxOCw2ICs4ODIsOCBAQCBrZXJuX3NlbWN0bChzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHNl bWlkLCBpbnQgc2VtbnVtLCBpbnQgY21kLAogCQlpZiAoKGVycm9yID0gc2VtdmFsaWQoc2VtaWQs IHNlbWFrcHRyKSkgIT0gMCkKIAkJCWdvdG8gZG9uZTI7CiAJCUtBU1NFUlQoY291bnQgPT0gc2Vt YWtwdHItPnUuc2VtX25zZW1zLCAoIm5zZW1zIGNoYW5nZWQiKSk7CisJCWlmICgoZXJyb3IgPSBj cl9jYW5zZWVfc2VtKHRkLT50ZF91Y3JlZCwgc2VtYWtwdHIpKSAhPSAwKQorCQkJZ290byBkb25l MjsKIAkJaWYgKChlcnJvciA9IGlwY3Blcm0odGQsICZzZW1ha3B0ci0+dS5zZW1fcGVybSwgSVBD X1cpKSkKIAkJCWdvdG8gZG9uZTI7CiAJCWZvciAoaSA9IDA7IGkgPCBzZW1ha3B0ci0+dS5zZW1f bnNlbXM7IGkrKykgewpAQCAtODcyLDYgKzkzOCw3IEBAIHN5c19zZW1nZXQoc3RydWN0IHRocmVh ZCAqdGQsIHN0cnVjdCBzZW1nZXRfYXJncyAqdWFwKQogCWlmIChrZXkgIT0gSVBDX1BSSVZBVEUp IHsKIAkJZm9yIChzZW1pZCA9IDA7IHNlbWlkIDwgc2VtaW5mby5zZW1tbmk7IHNlbWlkKyspIHsK IAkJCWlmICgoc2VtYVtzZW1pZF0udS5zZW1fcGVybS5tb2RlICYgU0VNX0FMTE9DKSAmJgorCQkJ ICAgIHNlbWFbc2VtaWRdLmNyZWQgJiYgc2VtYVtzZW1pZF0uY3JlZC0+Y3JfcHJpc29uID09IGNy ZWQtPmNyX3ByaXNvbiAmJgogCQkJICAgIHNlbWFbc2VtaWRdLnUuc2VtX3Blcm0ua2V5ID09IGtl eSkKIAkJCQlicmVhazsKIAkJfQpAQCAtMTA0OSw2ICsxMTE2LDggQEAgc3lzX3NlbW9wKHN0cnVj dCB0aHJlYWQgKnRkLCBzdHJ1Y3Qgc2Vtb3BfYXJncyAqdWFwKQogCQllcnJvciA9IEVJTlZBTDsK IAkJZ290byBkb25lMjsKIAl9CisJaWYgKChlcnJvciA9IGNyX2NhbnNlZV9zZW0odGQtPnRkX3Vj cmVkLCBzZW1ha3B0cikpICE9IDApCisJCWdvdG8gZG9uZTI7CiAJLyoKIAkgKiBJbml0aWFsIHBh c3MgdGhydSBzb3BzIHRvIHNlZSB3aGF0IHBlcm1pc3Npb25zIGFyZSBuZWVkZWQuCiAJICogQWxz byBwZXJmb3JtIGFueSBjaGVja3MgdGhhdCBkb24ndCBuZWVkIHJlcGVhdGluZyBvbiBlYWNoCkBA IC0xMzcyLDkgKzE0NDEsMzcgQEAgc2VtZXhpdF9teWhvb2sodm9pZCAqYXJnLCBzdHJ1Y3QgcHJv YyAqcCkKIHN0YXRpYyBpbnQKIHN5c2N0bF9zZW1hKFNZU0NUTF9IQU5ETEVSX0FSR1MpCiB7CisJ aW50IGVycm9yOworCXN0cnVjdCBzYnVmIHNiOworCXN0cnVjdCBzZW1pZF9rZXJuZWwgdG1wLCBl bXB0eTsKKwlpbnQgaTsKKworCWVycm9yID0gc3lzY3RsX3dpcmVfb2xkX2J1ZmZlcihyZXEsIDAp OworCWlmIChlcnJvciAhPSAwKQorCQlnb3RvIGRvbmU7CisJc2J1Zl9uZXdfZm9yX3N5c2N0bCgm c2IsIE5VTEwsIHNpemVvZihzdHJ1Y3Qgc2VtaWRfa2VybmVsKSAqIHNlbWluZm8uc2VtbW5pLCBy ZXEpOwogCi0JcmV0dXJuIChTWVNDVExfT1VUKHJlcSwgc2VtYSwKLQkgICAgc2l6ZW9mKHN0cnVj dCBzZW1pZF9rZXJuZWwpICogc2VtaW5mby5zZW1tbmkpKTsKKwliemVybygmZW1wdHksIHNpemVv ZihlbXB0eSkpOworCWZvciAoaSA9IDA7IGkgPCBzZW1pbmZvLnNlbW1uaTsgaSsrKSB7CisJCXN0 cnVjdCBzZW1pZF9rZXJuZWwgKnNlbWFrcHRyOworCisJCXNlbWFrcHRyID0gJnNlbWFbaV07CisJ CWlmICgoc2VtYWtwdHItPnUuc2VtX3Blcm0ubW9kZSAmIFNFTV9BTExPQykgPT0gMCB8fAorCQkg ICAgY3JfY2Fuc2VlX3NlbShyZXEtPnRkLT50ZF91Y3JlZCwgc2VtYWtwdHIpKSB7CisJCQlzZW1h a3B0ciA9ICZlbXB0eTsKKwkJfSBlbHNlIGlmIChyZXEtPnRkLT50ZF91Y3JlZC0+Y3JfcHJpc29u ICE9IHNlbWFrcHRyLT5jcmVkLT5jcl9wcmlzb24pIHsKKwkJCWJjb3B5KHNlbWFrcHRyLCAmdG1w LCBzaXplb2YodG1wKSk7CisJCQlzZW1ha3B0ciA9ICZ0bXA7CisJCQlzZW1ha3B0ci0+dS5zZW1f cGVybS5rZXkgPSBJUENfUFJJVkFURTsKKwkJfQorCisJCXNidWZfYmNhdCgmc2IsIHNlbWFrcHRy LCBzaXplb2YoKnNlbWFrcHRyKSk7CisJfQorCWVycm9yID0gc2J1Zl9maW5pc2goJnNiKTsKKwlz YnVmX2RlbGV0ZSgmc2IpOworCitkb25lOgorCXJldHVybiAoZXJyb3IpOwogfQogCiAjaWYgZGVm aW5lZChDT01QQVRfRlJFRUJTRDQpIHx8IGRlZmluZWQoQ09NUEFUX0ZSRUVCU0Q1KSB8fCBcCmRp ZmYgLS1naXQgYS9zeXMva2Vybi9zeXN2X3NobS5jIGIvc3lzL2tlcm4vc3lzdl9zaG0uYwppbmRl eCA2NmEyYTQzLi41Mjc2MGNmIDEwMDY0NAotLS0gYS9zeXMva2Vybi9zeXN2X3NobS5jCisrKyBi L3N5cy9rZXJuL3N5c3Zfc2htLmMKQEAgLTg2LDYgKzg2LDcgQEAgX19GQlNESUQoIiRGcmVlQlNE JCIpOwogI2luY2x1ZGUgPHN5cy9zeXNlbnQuaD4KICNpbmNsdWRlIDxzeXMvc3lzcHJvdG8uaD4K ICNpbmNsdWRlIDxzeXMvamFpbC5oPgorI2luY2x1ZGUgPHN5cy9zYnVmLmg+CiAKICNpbmNsdWRl IDxzZWN1cml0eS9tYWMvbWFjX2ZyYW1ld29yay5oPgogCkBAIC0xMjAsNyArMTIxLDcgQEAgc3Ry dWN0IHNobW1hcF9zdGF0ZSB7CiB9OwogCiBzdGF0aWMgdm9pZCBzaG1fZGVhbGxvY2F0ZV9zZWdt ZW50KHN0cnVjdCBzaG1pZF9rZXJuZWwgKik7Ci1zdGF0aWMgaW50IHNobV9maW5kX3NlZ21lbnRf Ynlfa2V5KGtleV90KTsKK3N0YXRpYyBpbnQgc2htX2ZpbmRfc2VnbWVudF9ieV9rZXkoc3RydWN0 IHByaXNvbiAqLCBrZXlfdCk7CiBzdGF0aWMgc3RydWN0IHNobWlkX2tlcm5lbCAqc2htX2ZpbmRf c2VnbWVudChpbnQsIGJvb2wpOwogc3RhdGljIGludCBzaG1fZGVsZXRlX21hcHBpbmcoc3RydWN0 IHZtc3BhY2UgKnZtLCBzdHJ1Y3Qgc2htbWFwX3N0YXRlICopOwogc3RhdGljIHZvaWQgc2htcmVh bGxvYyh2b2lkKTsKQEAgLTEzMCw2ICsxMzEsOSBAQCBzdGF0aWMgaW50IHNobXVubG9hZCh2b2lk KTsKIHN0YXRpYyB2b2lkIHNobWV4aXRfbXlob29rKHN0cnVjdCB2bXNwYWNlICp2bSk7CiBzdGF0 aWMgdm9pZCBzaG1mb3JrX215aG9vayhzdHJ1Y3QgcHJvYyAqcDEsIHN0cnVjdCBwcm9jICpwMik7 CiBzdGF0aWMgaW50IHN5c2N0bF9zaG1zZWdzKFNZU0NUTF9IQU5ETEVSX0FSR1MpOworc3RhdGlj IGludCBjcl9jYW5zZWVfc2htKHN0cnVjdCB1Y3JlZCAqLCBzdHJ1Y3Qgc2htaWRfa2VybmVsICop Oworc3RhdGljIHZvaWQgc2htX3JlbW92ZShzdHJ1Y3Qgc2htaWRfa2VybmVsICosIGludCk7Citz dGF0aWMgdm9pZCBzeXN2c2htX2NsZWFudXBfZm9yX3ByaXNvbl9teWhvb2soc3RydWN0IHByaXNv biAqKTsKIAogLyoKICAqIFR1bmVhYmxlIHZhbHVlcy4KQEAgLTE4OSwxMiArMTkzLDEzIEBAIHN0 YXRpYyBzdHJ1Y3Qgc3ggc3lzdnNobXN4OwogI2RlZmluZQlTWVNWU0hNX0FTU0VSVF9MT0NLRUQo KQlzeF9hc3NlcnQoJnN5c3ZzaG1zeCwgU0FfWExPQ0tFRCkKIAogc3RhdGljIGludAotc2htX2Zp bmRfc2VnbWVudF9ieV9rZXkoa2V5X3Qga2V5KQorc2htX2ZpbmRfc2VnbWVudF9ieV9rZXkoc3Ry dWN0IHByaXNvbiAqcHIsIGtleV90IGtleSkKIHsKIAlpbnQgaTsKIAogCWZvciAoaSA9IDA7IGkg PCBzaG1hbGxvY2VkOyBpKyspCiAJCWlmICgoc2htc2Vnc1tpXS51LnNobV9wZXJtLm1vZGUgJiBT SE1TRUdfQUxMT0NBVEVEKSAmJgorCQkgICAgc2htc2Vnc1tpXS5jcmVkICYmIHNobXNlZ3NbaV0u Y3JlZC0+Y3JfcHJpc29uID09IHByICYmCiAJCSAgICBzaG1zZWdzW2ldLnUuc2htX3Blcm0ua2V5 ID09IGtleSkKIAkJCXJldHVybiAoaSk7CiAJcmV0dXJuICgtMSk7CkBAIC0yNzIsNiArMjc3LDQ1 IEBAIHNobV9kZWxldGVfbWFwcGluZyhzdHJ1Y3Qgdm1zcGFjZSAqdm0sIHN0cnVjdCBzaG1tYXBf c3RhdGUgKnNobW1hcF9zKQogfQogCiBzdGF0aWMgaW50Citjcl9jYW5zZWVfc2htKHN0cnVjdCB1 Y3JlZCAqY3JlZCwgc3RydWN0IHNobWlkX2tlcm5lbCAqc2htc2VnKQoreworCisJaWYgKHNobXNl Zy0+Y3JlZCA9PSBOVUxMIHx8IHByaXNvbl9jaGVjayhjcmVkLCBzaG1zZWctPmNyZWQpKQorCQly ZXR1cm4gKEVJTlZBTCk7CisJcmV0dXJuICgwKTsKK30KKworc3RhdGljIHZvaWQKK3NobV9yZW1v dmUoc3RydWN0IHNobWlkX2tlcm5lbCAqc2htc2VnLCBpbnQgc2VnbnVtKQoreworCisJc2htc2Vn LT51LnNobV9wZXJtLmtleSA9IElQQ19QUklWQVRFOworCXNobXNlZy0+dS5zaG1fcGVybS5tb2Rl IHw9IFNITVNFR19SRU1PVkVEOworCWlmIChzaG1zZWctPnUuc2htX25hdHRjaCA8PSAwKSB7CisJ CXNobV9kZWFsbG9jYXRlX3NlZ21lbnQoc2htc2VnKTsKKwkJc2htX2xhc3RfZnJlZSA9IHNlZ251 bTsKKwl9Cit9CisKK3N0YXRpYyB2b2lkCitzeXN2c2htX2NsZWFudXBfZm9yX3ByaXNvbl9teWhv b2soc3RydWN0IHByaXNvbiAqcHIpCit7CisJaW50IGk7CisKKwlTWVNWU0hNX0xPQ0soKTsKKwlm b3IgKGkgPSAwOyBpIDwgc2htYWxsb2NlZDsgaSsrKSB7CisJCXN0cnVjdCBzaG1pZF9rZXJuZWwg KnNobXNlZzsKKworCQlzaG1zZWcgPSAmc2htc2Vnc1tpXTsKKwkJaWYgKChzaG1zZWctPnUuc2ht X3Blcm0ubW9kZSAmIFNITVNFR19BTExPQ0FURUQpICYmCisJCSAgICBzaG1zZWctPmNyZWQtPmNy X3ByaXNvbiA9PSBwcikgeworCQkJc2htX3JlbW92ZShzaG1zZWcsIGkpOworCQl9CisJfQorCVNZ U1ZTSE1fVU5MT0NLKCk7Cit9CisKK3N0YXRpYyBpbnQKIGtlcm5fc2htZHRfbG9ja2VkKHN0cnVj dCB0aHJlYWQgKnRkLCBjb25zdCB2b2lkICpzaG1hZGRyKQogewogCXN0cnVjdCBwcm9jICpwID0g dGQtPnRkX3Byb2M7CkBAIC0zNDgsNiArMzkyLDkgQEAga2Vybl9zaG1hdF9sb2NrZWQoc3RydWN0 IHRocmVhZCAqdGQsIGludCBzaG1pZCwgY29uc3Qgdm9pZCAqc2htYWRkciwKIAlzaG1zZWcgPSBz aG1fZmluZF9zZWdtZW50KHNobWlkLCB0cnVlKTsKIAlpZiAoc2htc2VnID09IE5VTEwpCiAJCXJl dHVybiAoRUlOVkFMKTsKKwllcnJvciA9IGNyX2NhbnNlZV9zaG0odGQtPnRkX3VjcmVkLCBzaG1z ZWcpOworCWlmIChlcnJvciAhPSAwKQorCQlyZXR1cm4gKGVycm9yKTsKIAllcnJvciA9IGlwY3Bl cm0odGQsICZzaG1zZWctPnUuc2htX3Blcm0sCiAJICAgIChzaG1mbGcgJiBTSE1fUkRPTkxZKSA/ IElQQ19SIDogSVBDX1J8SVBDX1cpOwogCWlmIChlcnJvciAhPSAwKQpAQCAtNDc3LDYgKzUyNCw5 IEBAIGtlcm5fc2htY3RsX2xvY2tlZChzdHJ1Y3QgdGhyZWFkICp0ZCwgaW50IHNobWlkLCBpbnQg Y21kLCB2b2lkICpidWYsCiAJc2htc2VnID0gc2htX2ZpbmRfc2VnbWVudChzaG1pZCwgY21kICE9 IFNITV9TVEFUKTsKIAlpZiAoc2htc2VnID09IE5VTEwpCiAJCXJldHVybiAoRUlOVkFMKTsKKwll cnJvciA9IGNyX2NhbnNlZV9zaG0odGQtPnRkX3VjcmVkLCBzaG1zZWcpOworCWlmIChlcnJvciAh PSAwKQorCQlyZXR1cm4gKGVycm9yKTsKICNpZmRlZiBNQUMKIAllcnJvciA9IG1hY19zeXN2c2ht X2NoZWNrX3NobWN0bCh0ZC0+dGRfdWNyZWQsIHNobXNlZywgY21kKTsKIAlpZiAoZXJyb3IgIT0g MCkKQEAgLTUxMiwxMiArNTYyLDggQEAga2Vybl9zaG1jdGxfbG9ja2VkKHN0cnVjdCB0aHJlYWQg KnRkLCBpbnQgc2htaWQsIGludCBjbWQsIHZvaWQgKmJ1ZiwKIAkJZXJyb3IgPSBpcGNwZXJtKHRk LCAmc2htc2VnLT51LnNobV9wZXJtLCBJUENfTSk7CiAJCWlmIChlcnJvciAhPSAwKQogCQkJcmV0 dXJuIChlcnJvcik7Ci0JCXNobXNlZy0+dS5zaG1fcGVybS5rZXkgPSBJUENfUFJJVkFURTsKLQkJ c2htc2VnLT51LnNobV9wZXJtLm1vZGUgfD0gU0hNU0VHX1JFTU9WRUQ7Ci0JCWlmIChzaG1zZWct PnUuc2htX25hdHRjaCA8PSAwKSB7Ci0JCQlzaG1fZGVhbGxvY2F0ZV9zZWdtZW50KHNobXNlZyk7 Ci0JCQlzaG1fbGFzdF9mcmVlID0gSVBDSURfVE9fSVgoc2htaWQpOwotCQl9CisKKwkJc2htX3Jl bW92ZShzaG1zZWcsIElQQ0lEX1RPX0lYKHNobWlkKSk7CiAJCWJyZWFrOwogI2lmIDAKIAljYXNl IFNITV9MT0NLOgpAQCAtNzI3LDcgKzc3Myw3IEBAIHN5c19zaG1nZXQoc3RydWN0IHRocmVhZCAq dGQsIHN0cnVjdCBzaG1nZXRfYXJncyAqdWFwKQogCWlmICh1YXAtPmtleSA9PSBJUENfUFJJVkFU RSkgewogCQllcnJvciA9IHNobWdldF9hbGxvY2F0ZV9zZWdtZW50KHRkLCB1YXAsIG1vZGUpOwog CX0gZWxzZSB7Ci0JCXNlZ251bSA9IHNobV9maW5kX3NlZ21lbnRfYnlfa2V5KHVhcC0+a2V5KTsK KwkJc2VnbnVtID0gc2htX2ZpbmRfc2VnbWVudF9ieV9rZXkodGQtPnRkX3VjcmVkLT5jcl9wcmlz b24sIHVhcC0+a2V5KTsKIAkJaWYgKHNlZ251bSA+PSAwKQogCQkJZXJyb3IgPSBzaG1nZXRfZXhp c3RpbmcodGQsIHVhcCwgbW9kZSwgc2VnbnVtKTsKIAkJZWxzZSBpZiAoKHVhcC0+c2htZmxnICYg SVBDX0NSRUFUKSA9PSAwKQpAQCAtODgzLDYgKzkyOSw3IEBAIHNobWluaXQodm9pZCkKIAlzeF9p bml0KCZzeXN2c2htc3gsICJzeXN2c2htc3giKTsKIAlzaG1leGl0X2hvb2sgPSAmc2htZXhpdF9t eWhvb2s7CiAJc2htZm9ya19ob29rID0gJnNobWZvcmtfbXlob29rOworCXN5c3ZzaG1fY2xlYW51 cF9mb3JfcHJpc29uX2hvb2sgPSAmc3lzdnNobV9jbGVhbnVwX2Zvcl9wcmlzb25fbXlob29rOwog CiAJZXJyb3IgPSBzeXNjYWxsX2hlbHBlcl9yZWdpc3RlcihzaG1fc3lzY2FsbHMpOwogCWlmIChl cnJvciAhPSAwKQpAQCAtOTIzLDYgKzk3MCw3IEBAIHNobXVubG9hZCh2b2lkKQogCWZyZWUoc2ht c2VncywgTV9TSE0pOwogCXNobWV4aXRfaG9vayA9IE5VTEw7CiAJc2htZm9ya19ob29rID0gTlVM TDsKKwlzeXN2c2htX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rID0gTlVMTDsKIAlzeF9kZXN0cm95 KCZzeXN2c2htc3gpOwogCXJldHVybiAoMCk7CiB9CkBAIC05MzEsOSArOTc5LDM4IEBAIHN0YXRp YyBpbnQKIHN5c2N0bF9zaG1zZWdzKFNZU0NUTF9IQU5ETEVSX0FSR1MpCiB7CiAJaW50IGVycm9y OworCXN0cnVjdCBzYnVmIHNiOworCXN0cnVjdCBzaG1pZF9rZXJuZWwgdG1wLCBlbXB0eTsKKwlp bnQgaTsKIAogCVNZU1ZTSE1fTE9DSygpOwotCWVycm9yID0gU1lTQ1RMX09VVChyZXEsIHNobXNl Z3MsIHNobWFsbG9jZWQgKiBzaXplb2Yoc2htc2Vnc1swXSkpOworCisJZXJyb3IgPSBzeXNjdGxf d2lyZV9vbGRfYnVmZmVyKHJlcSwgMCk7CisJaWYgKGVycm9yICE9IDApCisJCWdvdG8gZG9uZTsK KwlzYnVmX25ld19mb3Jfc3lzY3RsKCZzYiwgTlVMTCwgc2htYWxsb2NlZCAqIHNpemVvZihzaG1z ZWdzWzBdKSwgcmVxKTsKKworCWJ6ZXJvKCZlbXB0eSwgc2l6ZW9mKGVtcHR5KSk7CisJZW1wdHku dS5zaG1fcGVybS5tb2RlID0gU0hNU0VHX0ZSRUU7CisJZm9yIChpID0gMDsgaSA8IHNobWFsbG9j ZWQ7IGkrKykgeworCQlzdHJ1Y3Qgc2htaWRfa2VybmVsICpzaG1zZWc7CisKKwkJc2htc2VnID0g JnNobXNlZ3NbaV07CisJCWlmICgoc2htc2VnLT51LnNobV9wZXJtLm1vZGUgJiBTSE1TRUdfQUxM T0NBVEVEKSA9PSAwIHx8CisJCSAgICBjcl9jYW5zZWVfc2htKHJlcS0+dGQtPnRkX3VjcmVkLCAm c2htc2Vnc1tpXSkpIHsKKwkJCXNobXNlZyA9ICZlbXB0eTsKKwkJfSBlbHNlIGlmIChyZXEtPnRk LT50ZF91Y3JlZC0+Y3JfcHJpc29uICE9IHNobXNlZy0+Y3JlZC0+Y3JfcHJpc29uKSB7CisJCQli Y29weShzaG1zZWcsICZ0bXAsIHNpemVvZih0bXApKTsKKwkJCXNobXNlZyA9ICZ0bXA7CisJCQlz aG1zZWctPnUuc2htX3Blcm0ua2V5ID0gSVBDX1BSSVZBVEU7CisJCX0KKworCQlzYnVmX2JjYXQo JnNiLCBzaG1zZWcsIHNpemVvZigqc2htc2VnKSk7CisJfQorCWVycm9yID0gc2J1Zl9maW5pc2go JnNiKTsKKwlzYnVmX2RlbGV0ZSgmc2IpOworCitkb25lOgogCVNZU1ZTSE1fVU5MT0NLKCk7CiAJ cmV0dXJuIChlcnJvcik7CiB9CkBAIC05NzcsNiArMTA1NCwxMSBAQCBvc2htY3RsKHN0cnVjdCB0 aHJlYWQgKnRkLCBzdHJ1Y3Qgb3NobWN0bF9hcmdzICp1YXApCiAJCVNZU1ZTSE1fVU5MT0NLKCk7 CiAJCXJldHVybiAoRUlOVkFMKTsKIAl9CisJZXJyb3IgPSBjcl9jYW5zZWVfc2htKHRkLT50ZF91 Y3JlZCwgc2htc2VnKTsKKwlpZiAoZXJyb3IgIT0gMCkgeworCQlTWVNWU0hNX1VOTE9DSygpOwor CQlyZXR1cm4gKGVycm9yKTsKKwl9CiAJZXJyb3IgPSBpcGNwZXJtKHRkLCAmc2htc2VnLT51LnNo bV9wZXJtLCBJUENfUik7CiAJaWYgKGVycm9yICE9IDApIHsKIAkJU1lTVlNITV9VTkxPQ0soKTsK ZGlmZiAtLWdpdCBhL3N5cy9zeXMvaXBjLmggYi9zeXMvc3lzL2lwYy5oCmluZGV4IGU2NDNkNDgu Ljg4YjVmMTQgMTAwNjQ0Ci0tLSBhL3N5cy9zeXMvaXBjLmgKKysrIGIvc3lzL3N5cy9pcGMuaApA QCAtMTI2LDYgKzEyNiw3IEBAIHN0cnVjdCBpcGNfcGVybSB7CiBzdHJ1Y3QgdGhyZWFkOwogc3Ry dWN0IHByb2M7CiBzdHJ1Y3Qgdm1zcGFjZTsKK3N0cnVjdCBwcmlzb247CiAKICNpZiBkZWZpbmVk KENPTVBBVF9GUkVFQlNENCkgfHwgZGVmaW5lZChDT01QQVRfRlJFRUJTRDUpIHx8IFwKICAgICBk ZWZpbmVkKENPTVBBVF9GUkVFQlNENikgfHwgZGVmaW5lZChDT01QQVRfRlJFRUJTRDcpCkBAIC0x MzMsOSArMTM0LDEzIEBAIHZvaWQJaXBjcGVybV9vbGQybmV3KHN0cnVjdCBpcGNfcGVybV9vbGQg Kiwgc3RydWN0IGlwY19wZXJtICopOwogdm9pZAlpcGNwZXJtX25ldzJvbGQoc3RydWN0IGlwY19w ZXJtICosIHN0cnVjdCBpcGNfcGVybV9vbGQgKik7CiAjZW5kaWYKIAordm9pZCBpcGNfY2xlYW51 cF9mb3JfcHJpc29uKHN0cnVjdCBwcmlzb24gKik7CiBpbnQJaXBjcGVybShzdHJ1Y3QgdGhyZWFk ICosIHN0cnVjdCBpcGNfcGVybSAqLCBpbnQpOwogZXh0ZXJuIHZvaWQgKCpzaG1mb3JrX2hvb2sp KHN0cnVjdCBwcm9jICosIHN0cnVjdCBwcm9jICopOwogZXh0ZXJuIHZvaWQgKCpzaG1leGl0X2hv b2spKHN0cnVjdCB2bXNwYWNlICopOworZXh0ZXJuIHZvaWQgKCpzeXN2c2htX2NsZWFudXBfZm9y X3ByaXNvbl9ob29rKShzdHJ1Y3QgcHJpc29uICopOworZXh0ZXJuIHZvaWQgKCpzeXN2bXNnX2Ns ZWFudXBfZm9yX3ByaXNvbl9ob29rKShzdHJ1Y3QgcHJpc29uICopOworZXh0ZXJuIHZvaWQgKCpz eXN2c2VtX2NsZWFudXBfZm9yX3ByaXNvbl9ob29rKShzdHJ1Y3QgcHJpc29uICopOwogCiAjZWxz ZSAvKiAhIF9LRVJORUwgKi8KIAo= --=_63617d2f0e214e52d0427b5986ad3c29-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 01:23:19 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 86F4A4F5; Fri, 12 Jun 2015 01:23:19 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 732491A13; Fri, 12 Jun 2015 01:23:19 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id 64FE4341F84E; Thu, 11 Jun 2015 18:23:13 -0700 (PDT) Message-ID: <557A34DB.9070103@freebsd.org> Date: Thu, 11 Jun 2015 18:24:43 -0700 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: kikuchan@uranus.dti.ne.jp, freebsd-jail@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 01:23:19 -0000 Can a bugzilla or github request please be made for this so that it doesn't get lost? thank you, -Alfred On 6/11/15 6:17 PM, kikuchan@uranus.dti.ne.jp wrote: > Hello, > > I'm (still) trying to figure out how jail-aware SysV IPC mechanism should be. > > I want to run PostgreSQL in each jail without changing UID for each jail. > If you don't change UID on each jail, it doesn't work due to IPC objects conflict between jails. > See also; > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 > http://www.freebsddiary.org/jail-multiple.php > https://wiki.freebsd.org/Jails > https://forums.freebsd.org/threads/postgresql-in-jail.51528/ > > There is a patch for 4.7-STABLE on bugzilla (see above) to solve the problem by completely separating namespace for each jail in kernel, > but I couldn't find any (other) implementation that works on recent FreeBSD. > I've also tried to re-write the patch for recent FreeBSD, but I couldn't make it properly due to my limited kernel knowledge ;( > > Anyway, I created (and update) a patch to trying to solve the problem by simply separating IPC key_t space for each jail. > The attached patch can be applied to 10-STABLE (or CURRENT?). > > After the patch is applied; > - IPC objects created on parent jail, are invisible to children. > - IPC objects created on neighbor jail, are also invisible each other. > - IPC objects craeted on child jail, are VISIBLE from parent. > - IPC key_t spaces are separated between jails. If you see the key_t named object from parent, it's shown as IPC_PRIVATE. > > I choose this design of feature, however, I'm not sure this is the right design for jail-aware IPC. > If you prefer the completely separated namespace approach, it's ok. I want to focus on how the IPC mechanism dealing with hierarchical jail system. > > So I need more feedbacks. Could you help me please? > You can dig and play with ipcs(1)/ipcrm(1) to see what happend on each jail. > > Thanks. > > -- > Kikuchan > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 01:58:31 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 EA84A186; Fri, 12 Jun 2015 01:58:31 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (mail.turbocat.net [IPv6:2a01:4f8:d16:4514::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AB8D810CF; Fri, 12 Jun 2015 01:58:31 +0000 (UTC) (envelope-from hps@selasky.org) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id F2CFA1FE023; Fri, 12 Jun 2015 03:58:26 +0200 (CEST) Message-ID: <557A3CF3.3050603@selasky.org> Date: Fri, 12 Jun 2015 03:59:15 +0200 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Richard Yao , Ian Lepore CC: "freebsd-hackers@freebsd.org" , Erich Dollansky Subject: Re: allow ffs & co. a binary search References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5579A016.4040800@gentoo.org> <1434034373.1415.3.camel@freebsd.org> <5579A235.80609@gentoo.org> In-Reply-To: <5579A235.80609@gentoo.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 01:58:32 -0000 On 06/11/15 16:59, Richard Yao wrote: > On 06/11/2015 10:52 AM, Ian Lepore wrote: >> On Thu, 2015-06-11 at 10:49 -0400, Richard Yao wrote: >>> On 06/06/2015 08:13 PM, Erich Dollansky wrote: >> [...] >>> >>> The fastest portable way of calculating highest bit set is to use a >>> debrujin sequence: >>> >>> https://graphics.stanford.edu/~seander/bithacks.html#IntegerLogDeBruijn >>> >>> The binary approach is inferior, especially on Pentium 4 processors. >> >> And of course it's crucial that we optimize for Pentium 4 processors in >> 2015. > > The debrujin approach is fast regardless of the architecture. Anyway, > this is a solved problem. There is no need to reinvent the wheel when > the portable solutions are listed on that page at Stanford. > Hi Richard, ffs() can be implemented like this simply: int ffs_A(uint32_t v) { static const int MultiplyDeBruijnBitPosition[32] = { 0, 9, 1, 10, 13, 21, 2, 29, 11, 14, 16, 18, 22, 25, 3, 30, 8, 12, 20, 28, 15, 17, 24, 7, 19, 27, 23, 6, 26, 5, 4, 31 }; v = ~(v - 1) & v; return (MultiplyDeBruijnBitPosition[(uint32_t)(v * 0x07C4ACDDU) >> 27]); } --HPS From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 02:11:34 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 A753636F; Fri, 12 Jun 2015 02:11:34 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from vsmtp07.dti.ne.jp (vsmtp07.dti.ne.jp [202.216.231.142]) by mx1.freebsd.org (Postfix) with ESMTP id DB0481642; Fri, 12 Jun 2015 02:11:33 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from mail.dream.jp (webmail01.ga.dti.ne.jp [202.216.229.152]) by vsmtp07.dti.ne.jp (3.11v) with ESMTP AUTH id t5C24PBc029633; Fri, 12 Jun 2015 11:04:25 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Date: Fri, 12 Jun 2015 11:04:25 +0900 From: To: Alfred Perlstein Cc: , Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) In-Reply-To: <557A34DB.9070103@freebsd.org> References: <557A34DB.9070103@freebsd.org> Message-ID: X-Sender: kikuchan@uranus.dti.ne.jp User-Agent: DTI MyMail/0.3-trunk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 02:11:34 -0000 Thank you for your reply! Just appended, is this OK? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 On Thu, 11 Jun 2015 18:24:43 -0700, Alfred Perlstein wrote: > Can a bugzilla or github request please be made for this so that it > doesn't get lost? > > thank you, > -Alfred > > On 6/11/15 6:17 PM, kikuchan@uranus.dti.ne.jp wrote: >> Hello, >> >> I'm (still) trying to figure out how jail-aware SysV IPC mechanism should be. >> >> I want to run PostgreSQL in each jail without changing UID for each jail. >> If you don't change UID on each jail, it doesn't work due to IPC objects conflict between jails. >> See also; >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 >> http://www.freebsddiary.org/jail-multiple.php >> https://wiki.freebsd.org/Jails >> https://forums.freebsd.org/threads/postgresql-in-jail.51528/ >> >> There is a patch for 4.7-STABLE on bugzilla (see above) to solve the problem by completely separating namespace for each jail in kernel, >> but I couldn't find any (other) implementation that works on recent FreeBSD. >> I've also tried to re-write the patch for recent FreeBSD, but I couldn't make it properly due to my limited kernel knowledge ;( >> >> Anyway, I created (and update) a patch to trying to solve the problem by simply separating IPC key_t space for each jail. >> The attached patch can be applied to 10-STABLE (or CURRENT?). >> >> After the patch is applied; >> - IPC objects created on parent jail, are invisible to children. >> - IPC objects created on neighbor jail, are also invisible each other. >> - IPC objects craeted on child jail, are VISIBLE from parent. >> - IPC key_t spaces are separated between jails. If you see the key_t named object from parent, it's shown as IPC_PRIVATE. >> >> I choose this design of feature, however, I'm not sure this is the right design for jail-aware IPC. >> If you prefer the completely separated namespace approach, it's ok. I want to focus on how the IPC mechanism dealing with hierarchical jail system. >> >> So I need more feedbacks. Could you help me please? >> You can dig and play with ipcs(1)/ipcrm(1) to see what happend on each jail. >> >> Thanks. >> >> -- >> Kikuchan >> >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 02:13:40 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 2800E560; Fri, 12 Jun 2015 02:13:40 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 162B8169B; Fri, 12 Jun 2015 02:13:39 +0000 (UTC) (envelope-from alfred@freebsd.org) Received: from u10-2-32-011.office.norse-data.com (unknown [50.204.88.51]) by elvis.mu.org (Postfix) with ESMTPSA id F29FD341F84E; Thu, 11 Jun 2015 19:13:38 -0700 (PDT) Message-ID: <557A40AE.3010804@freebsd.org> Date: Thu, 11 Jun 2015 19:15:10 -0700 From: Alfred Perlstein Organization: FreeBSD User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: kikuchan@uranus.dti.ne.jp CC: freebsd-jail@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: How to implement jail-aware SysV IPC (with my nasty patch) References: <557A34DB.9070103@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 02:13:40 -0000 Thank you! On 6/11/15 7:04 PM, kikuchan@uranus.dti.ne.jp wrote: > Thank you for your reply! > > Just appended, is this OK? > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 > > > On Thu, 11 Jun 2015 18:24:43 -0700, Alfred Perlstein wrote: >> Can a bugzilla or github request please be made for this so that it >> doesn't get lost? >> >> thank you, >> -Alfred >> >> On 6/11/15 6:17 PM, kikuchan@uranus.dti.ne.jp wrote: >>> Hello, >>> >>> I'm (still) trying to figure out how jail-aware SysV IPC mechanism should be. >>> >>> I want to run PostgreSQL in each jail without changing UID for each jail. >>> If you don't change UID on each jail, it doesn't work due to IPC objects conflict between jails. >>> See also; >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 >>> http://www.freebsddiary.org/jail-multiple.php >>> https://wiki.freebsd.org/Jails >>> https://forums.freebsd.org/threads/postgresql-in-jail.51528/ >>> >>> There is a patch for 4.7-STABLE on bugzilla (see above) to solve the problem by completely separating namespace for each jail in kernel, >>> but I couldn't find any (other) implementation that works on recent FreeBSD. >>> I've also tried to re-write the patch for recent FreeBSD, but I couldn't make it properly due to my limited kernel knowledge ;( >>> >>> Anyway, I created (and update) a patch to trying to solve the problem by simply separating IPC key_t space for each jail. >>> The attached patch can be applied to 10-STABLE (or CURRENT?). >>> >>> After the patch is applied; >>> - IPC objects created on parent jail, are invisible to children. >>> - IPC objects created on neighbor jail, are also invisible each other. >>> - IPC objects craeted on child jail, are VISIBLE from parent. >>> - IPC key_t spaces are separated between jails. If you see the key_t named object from parent, it's shown as IPC_PRIVATE. >>> >>> I choose this design of feature, however, I'm not sure this is the right design for jail-aware IPC. >>> If you prefer the completely separated namespace approach, it's ok. I want to focus on how the IPC mechanism dealing with hierarchical jail system. >>> >>> So I need more feedbacks. Could you help me please? >>> You can dig and play with ipcs(1)/ipcrm(1) to see what happend on each jail. >>> >>> Thanks. >>> >>> -- >>> Kikuchan >>> >>> >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 11:19:17 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 44B56D95 for ; Fri, 12 Jun 2015 11:19:17 +0000 (UTC) (envelope-from csprajeeth@gmail.com) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::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 05FA0119E for ; Fri, 12 Jun 2015 11:19:17 +0000 (UTC) (envelope-from csprajeeth@gmail.com) Received: by yhak3 with SMTP id k3so12605358yha.2 for ; Fri, 12 Jun 2015 04:19:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ow19Ft6ww46jBgS2LtOmZEI6zmQ1KGDyvfk/IVFRV7o=; b=VC3qI3kPJAHvaalEez9yZQFxkozJU//Pbx1vxVdu9wJ9ZqIqItS8L5CTQx1SVvw9ou c0YU9d/S7DoRu/ZQzpasW2bb8ahfE1D6CAHG23bSSHpx6tno7UGTblv1At5f1K7qEar9 T+qgTSKtbunag2wbsOK1fEDqM1WxAMEDQZOp4nO2YRFJB/UZ6bZOLq1WiOcQm295Bhkf nlrZDnjjqiXdXk98BPXoC19ICc8txLauv6751/s9w783jOyBKUkTBEyZQE8sc78AZyAX 0nVa5bCHLgLBC0E/yXtxfAnQ4BTp5jdGaE1oXxtXrEj5QPfj4MwVnojpwF8fvsfAiJWh aNmg== MIME-Version: 1.0 X-Received: by 10.13.245.69 with SMTP id e66mr17657474ywf.176.1434107956057; Fri, 12 Jun 2015 04:19:16 -0700 (PDT) Received: by 10.37.194.134 with HTTP; Fri, 12 Jun 2015 04:19:16 -0700 (PDT) Date: Fri, 12 Jun 2015 16:49:16 +0530 Message-ID: Subject: pmcstat profiles OS code? From: Sai Prajeeth To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 11:19:17 -0000 Hi, I would like to count hardware events such as instructions retired / unhalted-core-cycles for all the systems for BOTH OS and APPLICATION. I am aware that pmcstat has a system wide monitoring mode that counts events across all the CPUs for all processes. I want to know whether the statistics for kernel code are collected as well ? (which I dont think so). Thanks! From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 07:50:13 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 1A0DB67C for ; Fri, 12 Jun 2015 07:50:13 +0000 (UTC) (envelope-from stefan.andritoiu@gmail.com) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 D75471A8C for ; Fri, 12 Jun 2015 07:50:12 +0000 (UTC) (envelope-from stefan.andritoiu@gmail.com) Received: by obbsn1 with SMTP id sn1so18423941obb.1 for ; Fri, 12 Jun 2015 00:50:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=UFnGnixUEBqVQryd3v5YCLimJw4K9CFbJmau5WSH2wA=; b=dtBH6nP5tL325SrDmMGIRKTyMMLzkcdK2QP1I81cId9iG8ALZesPMrDcoEQ15fmnyg tg+gWTWUcEQb05H+7lu7zxJWLacFF1dyrPZNGQNrSuiFe68oonl+wYH/WUC9eTaVzKmu 0H2QH3POL01AoTSodB0j0/ifGo0xgcitTiAvUS7VMO6BY/ou8CZ69fXEDlmW5/61VBbv QfnecbQU3crd37pClMMMy4nc3SKh81KJTyxpm/Y3boQb5WbEbg6jO3a8q/0uQNIsiNXt We30LEJLCgSW6NR15HAfxUQIsr2lgbs0f4UeqzbqgTYCecUuzM6cMYDFGEKWM5v2j1Re vz9w== MIME-Version: 1.0 X-Received: by 10.202.129.70 with SMTP id c67mr10631797oid.42.1434095411906; Fri, 12 Jun 2015 00:50:11 -0700 (PDT) Received: by 10.60.82.168 with HTTP; Fri, 12 Jun 2015 00:50:11 -0700 (PDT) Date: Fri, 12 Jun 2015 10:50:11 +0300 Message-ID: Subject: Are the sched_choose() or tdq_choose() functions called after returning from an interrupt? From: Stefan Andritoiu To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Fri, 12 Jun 2015 11:19:45 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 07:50:13 -0000 Hello, When returning from an interrupt, does it switch directly the thread that was interrupted? Or is the scheduler called to choose a thread to run (most probable the thread that was interrupted)? More specifically, are the sched_choose() or tdq_choose() functions called after returning from an IPI? Does an interrupt have it's own thread, or does it run in the context of the interrupted thread as in Linux? Thank you, Stefan From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 13:04:01 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 79C51E89; Fri, 12 Jun 2015 13:04:01 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 42EB61025; Fri, 12 Jun 2015 13:04:00 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from [192.168.1.2] (pool-72-89-250-199.nycmny.fios.verizon.net [72.89.250.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id A3FFB33BEE9; Fri, 12 Jun 2015 13:03:55 +0000 (UTC) Message-ID: <557AD8B0.6000600@gentoo.org> Date: Fri, 12 Jun 2015 09:03:44 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Hans Petter Selasky , Ian Lepore CC: "freebsd-hackers@freebsd.org" , Erich Dollansky Subject: Re: allow ffs & co. a binary search References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5579A016.4040800@gentoo.org> <1434034373.1415.3.camel@freebsd.org> <5579A235.80609@gentoo.org> <557A3CF3.3050603@selasky.org> In-Reply-To: <557A3CF3.3050603@selasky.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="U4JivMVLK5eQHd2h7wGPxDqk94kmV7Ki8" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 13:04:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U4JivMVLK5eQHd2h7wGPxDqk94kmV7Ki8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/11/2015 09:59 PM, Hans Petter Selasky wrote: > On 06/11/15 16:59, Richard Yao wrote: >> On 06/11/2015 10:52 AM, Ian Lepore wrote: >>> On Thu, 2015-06-11 at 10:49 -0400, Richard Yao wrote: >>>> On 06/06/2015 08:13 PM, Erich Dollansky wrote: >>> [...] >>>> >>>> The fastest portable way of calculating highest bit set is to use a >>>> debrujin sequence: >>>> >>>> https://graphics.stanford.edu/~seander/bithacks.html#IntegerLogDeBru= ijn >>>> >>>> The binary approach is inferior, especially on Pentium 4 processors.= >>> >>> And of course it's crucial that we optimize for Pentium 4 processors = in >>> 2015. >> >> The debrujin approach is fast regardless of the architecture. Anyway, >> this is a solved problem. There is no need to reinvent the wheel when >> the portable solutions are listed on that page at Stanford. >> >=20 > Hi Richard, >=20 > ffs() can be implemented like this simply: >=20 > int ffs_A(uint32_t v) > { > static const int MultiplyDeBruijnBitPosition[32] =3D > { > 0, 9, 1, 10, 13, 21, 2, 29, 11, 14, 16, 18, 22, 25, 3, 30, > 8, 12, 20, 28, 15, 17, 24, 7, 19, 27, 23, 6, 26, 5, 4, 31 > }; > v =3D ~(v - 1) & v; > return (MultiplyDeBruijnBitPosition[(uint32_t)(v * 0x07C4ACDDU) >> 27])= ; > } There is a way to do that on the stanford page too: https://graphics.stanford.edu/~seander/bithacks.html#ZerosOnRightMultLook= up Using it, we would have: int ffs_A(uint32_t v) { unsigned int v; // find the number of trailing zeros in 32-bit v int r; // result goes here static const int MultiplyDeBruijnBitPosition[32] =3D { 0, 1, 28, 2, 29, 14, 24, 3, 30, 22, 20, 15, 25, 17, 4, 8, 31, 27, 13, 23, 21, 19, 16, 7, 26, 12, 18, 6, 11, 5, 10, 9 }; return MultiplyDeBruijnBitPosition[((uint32_t)((v & -v) * 0x077CB531U)) >> 27]; } That accomplishes ffs() in 1 less operation. These techniques can be extended to 64-bit too. > --HPS --U4JivMVLK5eQHd2h7wGPxDqk94kmV7Ki8 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 iQIcBAEBAgAGBQJVeti1AAoJECDuEZm+6Exks44P/RRviCqqLvsltiZYDM4rUMRH hWj6idmPn3O2xOdng9D802QgBzmemT40tP9O2SAJYI3x49VU3bU5liX6IRBlB//J cF/cq5WCLrPufO2zRLIRbY+/YwSXBxegbJE8EPDCIFTPYsj3XAxdWW1xgNoKx4Ve /y7sz7erk9UhANvTjonREtLeH5gpzLIsjL/F1qAWfIXWZn0z5N2XGqAB+cY25MMl q6jcQTwnwy/h6wjnRZQu6hMossDyH3cZdonXPybBX7xNJOImuiEaPvkFc+2N6Oir H3x5rHFvouRT8/BlSE6bM3O3Shw8tLWBdzlQlfgzNjN3m36Kje/OqUiSXlW6Z/bY a8a2lPaYbLhOF+fWmyGd8+zZz9Lg/DSstjFRyaTPAofnfxG0hmGC4AQDtJHXQZsA C/z2zAvB4crHXIMnb53dAx2T5BXZGmpyk1T28O6yov3glj/DzHk06ybJvPIvBDru vY2VuTUW/TkxqJFiCl5w04C+f708UCJaFgeNWnvYfoMolEU9I5vy83gidr3Eyulh BlGGwi34or2yzBltfD+Q4JS4p0Hy55t6nRLzUHm/9f10LdAWdlvMZbsX4fNIV70u 65splGzN6twmJrOWaGqQE8zQKHoT7o1noCvqDJ2i3Ksdk218pN9K8R3FSoa+PU2i aHvni+pptB/x3/upn3hh =qSqX -----END PGP SIGNATURE----- --U4JivMVLK5eQHd2h7wGPxDqk94kmV7Ki8-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 13:32:06 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 A4054621; Fri, 12 Jun 2015 13:32:06 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 853121AEE; Fri, 12 Jun 2015 13:32:06 +0000 (UTC) (envelope-from ryao@gentoo.org) Received: from [192.168.1.2] (pool-72-89-250-199.nycmny.fios.verizon.net [72.89.250.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id E1BD3340A35; Fri, 12 Jun 2015 13:32:02 +0000 (UTC) Message-ID: <557ADF46.6030004@gentoo.org> Date: Fri, 12 Jun 2015 09:31:50 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Hans Petter Selasky , Ian Lepore CC: "freebsd-hackers@freebsd.org" , Erich Dollansky Subject: Re: allow ffs & co. a binary search References: <20150607081315.7c0f09fb@B85M-HD3-0.alogt.com> <5579A016.4040800@gentoo.org> <1434034373.1415.3.camel@freebsd.org> <5579A235.80609@gentoo.org> <557A3CF3.3050603@selasky.org> <557AD8B0.6000600@gentoo.org> In-Reply-To: <557AD8B0.6000600@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="hhTGpjioERfbEjcS17L2fhVuxFmwKm8nX" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 13:32:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --hhTGpjioERfbEjcS17L2fhVuxFmwKm8nX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 06/12/2015 09:03 AM, Richard Yao wrote: > On 06/11/2015 09:59 PM, Hans Petter Selasky wrote: >> On 06/11/15 16:59, Richard Yao wrote: >>> On 06/11/2015 10:52 AM, Ian Lepore wrote: >>>> On Thu, 2015-06-11 at 10:49 -0400, Richard Yao wrote: >>>>> On 06/06/2015 08:13 PM, Erich Dollansky wrote: >>>> [...] >>>>> >>>>> The fastest portable way of calculating highest bit set is to use a= >>>>> debrujin sequence: >>>>> >>>>> https://graphics.stanford.edu/~seander/bithacks.html#IntegerLogDeBr= uijn >>>>> >>>>> The binary approach is inferior, especially on Pentium 4 processors= =2E >>>> >>>> And of course it's crucial that we optimize for Pentium 4 processors= in >>>> 2015. >>> >>> The debrujin approach is fast regardless of the architecture. Anyway,= >>> this is a solved problem. There is no need to reinvent the wheel when= >>> the portable solutions are listed on that page at Stanford. >>> >> >> Hi Richard, >> >> ffs() can be implemented like this simply: >> >> int ffs_A(uint32_t v) >> { >> static const int MultiplyDeBruijnBitPosition[32] =3D >> { >> 0, 9, 1, 10, 13, 21, 2, 29, 11, 14, 16, 18, 22, 25, 3, 30, >> 8, 12, 20, 28, 15, 17, 24, 7, 19, 27, 23, 6, 26, 5, 4, 31 >> }; >> v =3D ~(v - 1) & v; >> return (MultiplyDeBruijnBitPosition[(uint32_t)(v * 0x07C4ACDDU) >> 27]= ); >> } >=20 > There is a way to do that on the stanford page too: >=20 > https://graphics.stanford.edu/~seander/bithacks.html#ZerosOnRightMultLo= okup My apologies. I inadvertently linked to the wrong variant of that in my initial email. It has been a while since I visited that page and I was juggling a few things when I wrote that email, so it was easy to confuse the two. Anyway, it would be possible to do something like: #if defined(__GNUC__) || (defined(__clang__) && __has_builtin(__builtin_ffs)) # define ffs(n) __builtin_ffs(n) #else /* * From Sean Eron Anderson's Bit Twiddling Hacks * https://graphics.stanford.edu/~seander/bithacks.html#ZerosOnRightMultLook= up */ static inline int ffs(uint32_t v) { static const int MultiplyDeBruijnBitPosition[32] =3D { 0, 9, 1, 10, 13, 21, 2, 29, 11, 14, 16, 18, 22, 25, 3, 30, 8, 12, 20, 28, 15, 17, 24, 7, 19, 27, 23, 6, 26, 5, 4, 31 }; v =3D ~(v - 1) & v; return (MultiplyDeBruijnBitPosition[(uint32_t)(v * 0x07C4ACDDU) >> 27]); } #endif If there were an autotools-like check for `__has_builtin()`, then an explicit list of compilers known to support `__builtin_ffs()` would not be necessary, although a list of compilers that lack support for `__has_builtin()` (such as GCC) would still be necessary. Those building with compilers that do not support `__builtin_ffs()` could fallback to the DeBrujin approach. --hhTGpjioERfbEjcS17L2fhVuxFmwKm8nX 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 iQIcBAEBAgAGBQJVet9MAAoJECDuEZm+6ExkQYAQAJ/GHDJsSYXTjykmGCHP7K1A EcgXjS3FO4KLc97ArzS5JQ9zB+btAIwshbaUFqxINivkvRHPSHhLktiv/QUODL/l fVp6Pr43/rU6W7KTx1FO3WcJyr5/TYS0RSqH3VltZvneuXonuwyQTJNhggVhS8JW GxCV7Jtw2UrW/i1MwN1lCRbWdPmCQse18wWAhCwdUAuSI/8tluOOZUjiQ+iYMRuT 4MFutG0SrSHP6DToPWFcXFcf1v+/vrC0ROykugtbXqHFty/StthBFg1rsT668B15 3P+u7G+jYj+xaRekFFp8exi8II8il9179S+hsl5M3noVE58sL++HLPelDVLyTMzB BgyMhWEGV2b7S1Or0o5Vxa2eVLKIFI5ud4zY2OjGIR3kiYeuq+kn8R6AGlw2y5pR ushjLXunYm11uY8rCIZEeuP20RIyCs0nFksonOPqQi/B8b3qQ0YQuiCkf0vWlfbP uRt6svVn9jOBailAk4sxKWEoFD4k10r0qO2G2pHOHV8HeCtwbF4n44HR/NjbTq6E HxxAJpOeLuu8tSuKcPAvxCJ5mAfPW+RtegvY4ZvYyNNS9y0pm6APpN7pW/z57PC6 E1vxkMOX3U82mjTW26cTU2hFkU0rdSGu4arcLtQMZhFHK8Da6KkMZTSSCcCr0/iJ 6wVQg4wQp0OcmLTiX2Xk =Zv3N -----END PGP SIGNATURE----- --hhTGpjioERfbEjcS17L2fhVuxFmwKm8nX-- From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 17:17:05 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 BABBACF2 for ; Fri, 12 Jun 2015 17:17:05 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (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 8444EA3F for ; Fri, 12 Jun 2015 17:17:05 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by igbsb11 with SMTP id sb11so15132215igb.0 for ; Fri, 12 Jun 2015 10:17:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BxEcco7CKNecoqm+0rROd6jYSh0S/nxYm8kPDfnFwaM=; b=PYjLMW+cVCRO32acvTwZ0DpqzeiYPiT7K8+VEwCoZVTB9X8yEWGX8zhPQzlkMwUgRm 8WOg7XRworGCvxiCRWl7KLT4KrhfFA1uMEzg1AzPoH/1voTVMTq5j2/K6Om8Kr7OsjdY kXF1KNxr/Q1VcigLy82rOD2GfwuBpMPJ1DA+Quvj2W8fmorL9obpM97ErmcbZQ8aJvCx pjbNgHgzzL5+29QRhnI3r7kyc8JMbN58PcpJFn4+1bKm/DX4yFBWH1tR3u7PQfwIZAlN 0RSkpaKdwj4sDV9L+7RS+8lyQSgNb12aRiF0tghH3JFb/xoRBa8IZ6TVK4+t497PnnQN 9Adw== MIME-Version: 1.0 X-Received: by 10.50.108.7 with SMTP id hg7mr5699958igb.37.1434129424947; Fri, 12 Jun 2015 10:17:04 -0700 (PDT) Received: by 10.107.165.16 with HTTP; Fri, 12 Jun 2015 10:17:04 -0700 (PDT) Received: by 10.107.165.16 with HTTP; Fri, 12 Jun 2015 10:17:04 -0700 (PDT) In-Reply-To: References: Date: Fri, 12 Jun 2015 13:17:04 -0400 Message-ID: Subject: Re: pmcstat profiles OS code? From: Ryan Stone To: Sai Prajeeth Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 17:17:05 -0000 pmcstat -S will collect data for threads running in the kernel, both for kernel threads like interrupt threads as well as user threads running in kernel context (e.g performing a system call) On Jun 12, 2015 7:19 AM, "Sai Prajeeth" wrote: > Hi, > > I would like to count hardware events such as instructions retired / > unhalted-core-cycles for all the systems for BOTH OS and APPLICATION. I am > aware that pmcstat has a system wide monitoring mode that counts events > across all the CPUs for all processes. I want to know whether the > statistics for kernel code are collected as well ? (which I dont think so). > > Thanks! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > From owner-freebsd-hackers@FreeBSD.ORG Fri Jun 12 20:04:36 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 6065E244 for ; Fri, 12 Jun 2015 20:04:36 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C8C22796 for ; Fri, 12 Jun 2015 20:04:35 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t5CK4RFN053904 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 12 Jun 2015 23:04:27 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t5CK4RFN053904 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t5CK4QQX053844; Fri, 12 Jun 2015 23:04:26 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 12 Jun 2015 23:04:26 +0300 From: Konstantin Belousov To: Stefan Andritoiu Cc: freebsd-hackers@freebsd.org Subject: Re: Are the sched_choose() or tdq_choose() functions called after returning from an interrupt? Message-ID: <20150612200426.GG2080@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 20:04:36 -0000 On Fri, Jun 12, 2015 at 10:50:11AM +0300, Stefan Andritoiu wrote: > Hello, > > When returning from an interrupt, does it switch directly the thread > that was interrupted? Or is the scheduler called to choose a thread to > run (most probable the thread that was interrupted)? > > More specifically, are the sched_choose() or tdq_choose() functions > called after returning from an IPI? I do not quite understand why do you use the term IPI there, but it does not matter; both device interrupts and IPI cause similar > > Does an interrupt have it's own thread, or does it run in the context > of the interrupted thread as in Linux? Both, it is up to the interrupt code author to select model. Either you use fast interrupt filter, or thread, for interrupt handling code. Look at e.g. the lapic_handle_timer(), which is called from the assembler trampoline when LAPIC timer interrupt is generated. The code calls critical_enter()/critical_exit() pair, and critical_exit() checks the td_owepreempt member of the curthread to see if anything before or during processing of the timer tick interrupt (including the scheduler) tickled the preemption. If yes, mi_switch() is called to cause the context switch on the processor. Hardware interrupts result in the call to intr_event_handle(). There you can see the FILTER/THREAD cases. The FILTER is executed in whatever context that was active during the interrupt delivery, which of course causes severe restrictions on the things that can be used or accessed in the handler. THREAD handler results in the interrupt thread put on the run queue. Since the priority of the interrupt threads is very high, it should be put on CPU 'soon', in the critical_exit() in the intr_event_handle() (look only for the !INTR_FILTER variant of the function, INTR_FILTER is buggy). From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 13 09:27:10 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 440ABAB3 for ; Sat, 13 Jun 2015 09:27:10 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (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 CCA40315 for ; Sat, 13 Jun 2015 09:27:09 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: by wibdq8 with SMTP id dq8so34681081wib.1 for ; Sat, 13 Jun 2015 02:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:mail-followup-to :references:mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=jBm5Q6KpGxDYvpD7Q7vYqNQmbqGDluVZ86N4b4zrvwo=; b=lkxIHgFxfjRu38hL+vbjbE4Z8YocLavMDYWAwt7BMpaydCqnHePx76bbOI+NHg6oAW 1jtWqHsET7B8tDy2CS7f9GBhEPMnBp9fAJTEV/b5qeFzw2zxcMg8T58kzIgv8HCdyOEY oQa1J8swjRgF6WAeWxhwWDeHFRCqyH//d27Prp1B5Z4UbazBIljmVE3NYLK0xZDWM9+6 cwH9rcgwfA6VTeIWBWNSElHWQ9RVmgUmRFp5V9YLszCUsPaAa9Dmt9fcLaY2ULBNxJ1C ucdF45cxvL2r82XJ3wAT0fmREPhygufw4FNc+CXt8jQVNbpoHm0FjEnW4Kx7gai5rZ0W EYlQ== X-Received: by 10.180.73.10 with SMTP id h10mr13931654wiv.21.1434187628080; Sat, 13 Jun 2015 02:27:08 -0700 (PDT) Received: from brick.home (eug18.neoplus.adsl.tpnet.pl. [83.20.178.18]) by mx.google.com with ESMTPSA id pf4sm9533314wjb.23.2015.06.13.02.27.06 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 13 Jun 2015 02:27:06 -0700 (PDT) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Date: Sat, 13 Jun 2015 11:27:04 +0200 From: Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= To: Dirk-Willem van Gulik Cc: freebsd-hackers@freebsd.org Subject: Re: pivot_root() and FreeBSD Message-ID: <20150613092704.GA37870@brick.home> Mail-Followup-To: Dirk-Willem van Gulik , freebsd-hackers@freebsd.org References: <654E1C53-8536-406D-B218-EA6F20848821@webweaving.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <654E1C53-8536-406D-B218-EA6F20848821@webweaving.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 09:27:10 -0000 On 0303T1751, Dirk-Willem van Gulik wrote: > I am trying to do, in effect an PXE boot/install on a local volume - and would like the machine to cut over into normal running without a reboot*. > > So effectively I would like to do the equivalent of pivot_root() and perhaps something special for init(8), and then jettison md, nfs and what not. > > Is there any way to do this on 10.1 or -current ? Or has anyone recently done work on Adrian Steinmann his 'Pivot Root for BSD’** ? I have something similar in purpose in the works: https://reviews.freebsd.org/D2698 Perhaps you could take a look to see if it fits your use case? The code needs a rewrite, but the usage should stay the same. From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 13 10:34:53 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 67C3E5A2 for ; Sat, 13 Jun 2015 10:34:53 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EB4406AC for ; Sat, 13 Jun 2015 10:34:52 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from [192.168.1.115] ([67.212.197.98]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MgKUo-1YhFg20ud4-00Nhf3 for ; Sat, 13 Jun 2015 12:34:44 +0200 Message-ID: <557C073E.1060702@gmx.com> Date: Sat, 13 Jun 2015 03:34:38 -0700 From: Don whY User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: FreeBSD-Hackers Mailing List Subject: PXE boot an XIP image? Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:29J5+nso+N/eABtGK4AnKLJ9s0npFEu5j3SP8pBwetnV+ISrqIx RirJ4HOM/kN3ib+IM52flMeTb51JJZ6xX6AhY0aOSRrplcL/1CBHLD82gevEL++7T3FUZZW 5qU94qziZQCe0AHs+9sJ+0jHYo4ASGe3TbPUfRB1zNgXsW4DMvzFBj46Q5laahrYlacSHza 71ZgxCrh+Ke86JTfV+bYQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:TfawNQWlR2E=:FYcwiLkKLu2YVy9CYn7ya4 hbv5WoCaWWK+WwyF/pWxAjVhQAV94JUwLMr3/IheTRAshS4136Sf0hvcpYfRA42R/MCXJZ4VH 46IKKG2WU/Bk4wO5LyewkkEwHARolHnxMKw1nLaV/6O+3GOLOn9X42c7rMg+o2HRS82PTXiFx GNmi+sy5jK0D4Ld53YX1KF0asj2BwtkuJBgrvoQFKKUlAEUOZ1ZN3nc1EmRKwySA+ZB3wR+b7 OEpizm89XbMjCj3rkfx2NS+OYY8S8hCk7SSXAOCT1hYubm65pq34M0HazqE66GWGC2q0gxxtR K/DaQoG6bqlYtj63kpqiYkxKGYq0a+ypap9Ar6h93PdbxsK78uF1KLMlkOft1OOrDk+J7qalv KnJEhntPUdFbRVMJpIvNiXXLZ9hXlmdBChjc1qK5p0F102VEr4HGTOAG6KUKS1U4uVvs31dqo U53tg2RNV+e7uxnSRnaZ9bY/npyW3q5UheQehBv6xMxQvcLFhYJDbrgCN0eixXftq/c0qC598 FfpumE7typeVp/xm1JDD8thJrnDUGUfkbYDS2C3pkYyntKRoHbdYi35hD/cAMDGb+8T6ggEZH Vuf2XNs6e9V1PBNdL3nM6/i4Pn2698KR1ojeJD3+Yw6/EPFlg7KWWovGYhdBYvjdQseycpuZA LC4pDXexQ7mS5UolGEGC0fHlNgMajz9rLFqjIP66sKut6E8vR82LYz9SRF3rk4ryk0Bw= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 10:34:53 -0000 Hi, Apologies as to whether this belongs here... or on -embedded. :< I'd like to PXE boot a kernel then fetch (any choice of protocol) a *single* image to load into RAM thereafter not requiring any access to external media to operate. I.e., as if the image had resided in the device all along. A crude approach *might* be something like crunchgen'ing init with all of the (static linked) binaries that are required and letting the loaded kernel NFS read (load) that init(1). Obviously, I'd trim the kernel and other binaries down to the bare essentials to minimize RAM requirements (as there would be no swap, etc.) [I.e., creating a tiny filesystem that simply links every executable back to this *one* image] In practice, this won't (?) really work as hoped. Any pointers on a proven technique to achieve these results? Thanks! From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 13 13:10:59 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 131714B8 for ; Sat, 13 Jun 2015 13:10:59 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D3F3CCE6 for ; Sat, 13 Jun 2015 13:10:58 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-248-228.lns20.per4.internode.on.net [121.45.248.228]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t5DDArOr079628 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 13 Jun 2015 06:10:56 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <557C2BD7.1000104@freebsd.org> Date: Sat, 13 Jun 2015 21:10:47 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Don whY , FreeBSD-Hackers Mailing List Subject: Re: PXE boot an XIP image? References: <557C073E.1060702@gmx.com> In-Reply-To: <557C073E.1060702@gmx.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 13:10:59 -0000 On 6/13/15 6:34 PM, Don whY wrote: > Hi, > > Apologies as to whether this belongs here... or on -embedded. :< > > I'd like to PXE boot a kernel then fetch (any choice of protocol) > a *single* image to load into RAM thereafter not requiring any > access to external media to operate. I.e., as if the image > had resided in the device all along. what do you mean by "single"? any PXE boot is by definition a number of transactions. The regular PXE boot code from FreeBSD is capable of loading a kernel and a matching ram filesystem, which when executed, will boot up as a running system and not touch any medium. I haven't done it for a while but at one stage there used to be a suitable memory filesystem on one fo the boot media. (that may no longer be true) you can also boot a completely NFS system as well, and that will not touch media either. Finally, if having the network boot loader load TWO modules (kernel and FS) is too much, you could make a kernel that has the filesystem statically linked into it. But that's more work. > > A crude approach *might* be something like crunchgen'ing init > with all of the (static linked) binaries that are required > and letting the loaded kernel NFS read (load) that init(1). > Obviously, I'd trim the kernel and other binaries down to the > bare essentials to minimize RAM requirements (as there would be no > swap, etc.) > > [I.e., creating a tiny filesystem that simply links every executable > back to this *one* image] > > In practice, this won't (?) really work as hoped. Any pointers on > a proven technique to achieve these results? I don't know why that wouldn't work, but what you put in your memory filesystem is up to you. You dont say what your limits are. How much RAM is on the machine? All this is documented on many blogs, man pages, etc. so spend a while on google and you should be able to patch it together. remember: the bootblocks/loader used for Regular PXE booting can load using NFS or tftp. teh loader can link a file with the kernel that is just a filesystem image.. (I forget the exact 'type' is needs to use.. I'm sure the man pages would have it) teh filesystem image is just that.. you make it bu making a memory based drive, and formatting and filling it just as you would a regular drive. We DID at one stage have the ability to have the filesystem loaded be compressed. (in fact at one stag the kernel could also be compressed. I presume we cna stil do that but as I said, I haven't done this for some time. finally you can load the filesystem image and kernel from GRUB too, so if you get the net lodaing capable version of grub going you should be able to do exactly the same thing. it's just a case of giving the right 'type' and name for the image, and giving the right "mountfrom" value (ufs:md0 would be an expected value for example). > > Thanks! > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to > "freebsd-hackers-unsubscribe@freebsd.org" > > From owner-freebsd-hackers@FreeBSD.ORG Sat Jun 13 19:28:25 2015 Return-Path: Delivered-To: freebsd-hackers@hub.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 BE3C05CE; Sat, 13 Jun 2015 19:28:25 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4DDC0BF; Sat, 13 Jun 2015 19:28:25 +0000 (UTC) (envelope-from Don.whY@gmx.com) Received: from [192.168.1.115] ([67.212.197.98]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0LxPNC-1Z6bDI1h1O-016uMu; Sat, 13 Jun 2015 21:28:22 +0200 Message-ID: <557C844F.1010107@gmx.com> Date: Sat, 13 Jun 2015 12:28:15 -0700 From: Don whY User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Julian Elischer , FreeBSD-Hackers Mailing List Subject: Re: PXE boot an XIP image? References: <557C073E.1060702@gmx.com> <557C2BD7.1000104@freebsd.org> In-Reply-To: <557C2BD7.1000104@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:v59D1+WwZZbUN8Fqo6f7wunTqUvpyfuOdV30ZYYA1+39LZljkRF sdx/n3RCoKgFqRQYfhheDdxlhgcZqMtZPobTMncTh3duH+1LPaE0BOfnWcxONntz/CPb+2d 7u84+fYSZzti6ygBPJXvqyYop6uiMZzQGMTSQA2/QuVrOxTAvqDjljyovzUeeyO+xdai+CG eGjEAXAYFwksk6pVZ/j1Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:92IKfCUNFkE=:eY45LCNpm1L47VlSGIwq1N 4YKoasjZyOPWO9QhZIgQBdHgXd14xC60+MH8v+NCiXEhlSUkI5qm8L0mwx8ZFV1oyj6QFGILK teWjB7Mk27eN3YhMty1OBkPSp1Xhz7NGdUJzJT0clYjXG1sBYUXu5L0yAhx27CMO+6OvPs++7 SqUIQ2uASO1UXeOg4VjWKH29m84MF+I09fjDEM1LZC/1g4XzIMnvPJ0ZA4wsqQRDntk+gmEzM JYw08DQltHK2J7FyuGsR3Zz6X231zk+dtWbSG1c2ZIeSzKHCvwDHTRjF5+TnJ4BiVxvw8h2vA Qn9K01UsgjGjYMloIHC3K1kb3ZAj+fCOZnrReocw905vC5z+X2qSQJiOYLEFZlGuPk9lxaKof FW1RzypXB5AkOQHfBeiTywK6w1Inzi7sX+S4MAY/P0udsLxZZyAdizBxPVk/nsmrFedEK5Lw8 iAY0/sH8ChEam2wDV7v4Ueqq2JU771NaXrBvJHB05HZbLtoeZumPw7xHcWmRg9watawr3DRZS 8B0eKewJX5tk0U7JP/ST+fWV94kmiZY0HTG5+lHT9Dh1dgMValS7rVSnV8z41gXrwvkVqt9lK c+51eCnNwPyp8A6kJuhQNXnSl9RNEU2rgHjnmkV+T/y1nCXDC0g3gDpClNcuujTnwKe+yTzkU HYj/GIJpWsxn0QrW9k4of0B7rVZfTR1SLfBUxFGp0cOKSC7rCEWYQ3EXaXcf9xKrbytw= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2015 19:28:25 -0000 On 6/13/2015 6:10 AM, Julian Elischer wrote: > On 6/13/15 6:34 PM, Don whY wrote: > >> I'd like to PXE boot a kernel then fetch (any choice of protocol) >> a *single* image to load into RAM thereafter not requiring any >> access to external media to operate. I.e., as if the image >> had resided in the device all along. > > what do you mean by "single"? any PXE boot is by definition a number of > transactions. Load kernel, load *an* executable, CUT NETWORK CORD. Thereafter, behave as if the device was operating from built-in FLASH. > The regular PXE boot code from FreeBSD is capable of loading a kernel and a > matching ram filesystem, which when executed, will boot up as a running > system and not touch any medium. I haven't done it for a while but at > one stage there used to be a suitable memory filesystem on one fo the boot media. > (that may no longer be true) A memory filesystem is not the same as XIP. You'd have *two* copies of anything that is executing in RAM at any given time: the one stored in the filesystem and the one that is executing in process memory. I want to omit the "filesystem" aspect. E.g., load *everything* into process memory so the remaining "RAM" is available for use *by* those processes. Then, shrink the amount of RAM installed (think "appliance" -- hence the -embedded reference in my OP) to just that which is required to store the RUNNING code and it's data requirements. > you can also boot a completely NFS system as well, and that will not touch > media either. It touches the remote NFS mount ("external media"). I.e., once "loaded", the network should be not required for fetching other binaries. "Cut network cord". > Finally, if having the network boot loader load TWO modules (kernel and FS) is > too much, > you could make a kernel that has the filesystem statically linked into it. > But that's more work. I'm looking for a step beyond that: have a "process image" loaded directly alongside the kernel. >> A crude approach *might* be something like crunchgen'ing init >> with all of the (static linked) binaries that are required >> and letting the loaded kernel NFS read (load) that init(1). >> Obviously, I'd trim the kernel and other binaries down to the >> bare essentials to minimize RAM requirements (as there would be no >> swap, etc.) >> >> [I.e., creating a tiny filesystem that simply links every executable >> back to this *one* image] >> >> In practice, this won't (?) really work as hoped. Any pointers on >> a proven technique to achieve these results? > I don't know why that wouldn't work, but what you put in your memory filesystem > is up to you. The point is to get rid of the "memory filesystem". E.g., load kernel. Let kernel read init(1) via an NFS mount. Now, init resides in "process memory" -- we haven't built a filesystem with anything *in* it! Then, "cut network cord". I.e., as long as init doesn't exit, it remains in process memory. As init was crunchgen'd with all the other binaries, *they* also remain in memory. The fluke is requiring a nominal filesystem simply to point to the "other" entry points in that crunchgen'd image -- yet NOT require a second instance of it (i.e., init) to be loaded when one of those other entry points is invoked. E.g., imagine you use some set of "commands". Together, they create a crunchgen'd image that is ~1MB (arbitrary number chosen solely for discussion). Assume there are 200 of them (another arbitrary number). One of those components is "init". Kernel loads init (via NFS) and, with it, come ALL of these commands. You then invoke *all* of those commands, simultaneously. Each, of course, has some process-specific state. The goal is to only require 1MB of RAM (in addition to the kernel), *plus* that per-process state. Regardless of how many "commands" (processes) are running from that ONE crunchgen'd "init". The lower limit in the presence of an external store (for the individual, non-crunchgen'd executables) would be the sum of all their text segments and data segments. There would be some overlap in those text segments due to common library uses. And, some heap-related costs (ideally, tailored to each executable). Get to *this* point while eliminating the "external store" (i.e., allowing only "ONE" access to it at boot) -- without keeping a copy of that external store in a "memory filesystem". > You dont say what your limits are. How much RAM is on the machine? Again, think appliance. I have lots of machines to play with that include gobs of RAM. What I want is to trim that RAM requirement down to an affordable bill of materials, power budget, etc. Having a copy of the executables appear *twice* is just wasteful: "here's a copy that I use to load the *working* copy..." > All this is documented on many blogs, man pages, etc. so spend a while on > google and you should be able to patch it together. What's missing is how to do this without having a filesystem (duplicate copy of executables) on the target device! FOR EXAMPLE, look at the resources present in standalone X Terminals. Count the bytes of (EP)ROM. Count the bytes of RAM. How would you approach that level of resource utilization with the existing codebase? I can easily elide portions of the kernel that aren't important to that particular functionality (in this example, an X Terminal). And, I can omit all the executables that aren't pertinent to "the implementation of an X Terminal". But, the UN*X model doesn't easily lend itself to "load a composite image into memory and start the processes represented *in* that image" -- while the OS in an X Terminal can do this easily (because it was designed with that XIP capability). > remember: > the bootblocks/loader used for Regular PXE booting can load using NFS or tftp. > teh loader can link a file with the kernel that is just a filesystem image.. > (I forget the exact 'type' is needs to use.. I'm sure the man pages would have it) > teh filesystem image is just that.. you make it bu making a memory based drive, > and formatting and filling it just as you would a regular drive. > > We DID at one stage have the ability to have the filesystem loaded be compressed. > (in fact at one stag the kernel could also be compressed. I presume we cna stil > do that > but as I said, I haven't done this for some time. > > finally you can load the filesystem image and kernel from GRUB too, so if you > get the net lodaing capable version of grub going you should be able to do > exactly the same thing. it's just a case of giving the right 'type' and name > for the image, and giving the right "mountfrom" value (ufs:md0 would be an > expected value for example).