From owner-freebsd-hackers@freebsd.org Sun Oct 9 11:42:20 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E657FC079E1 for ; Sun, 9 Oct 2016 11:42:20 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 42AE3F6F for ; Sun, 9 Oct 2016 11:42:19 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id OAA15925 for ; Sun, 09 Oct 2016 14:42:17 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1btCUj-000DuQ-J1 for freebsd-hackers@FreeBSD.org; Sun, 09 Oct 2016 14:42:17 +0300 To: FreeBSD Hackers From: Andriy Gapon Subject: I/O-APIC redirection table on AMD chipsets Message-ID: <95ddd0c4-b001-e15e-75cc-79d69dca0518@FreeBSD.org> Date: Sun, 9 Oct 2016 14:41:21 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Oct 2016 11:42:21 -0000 I just want to share a small discovery. For AMD SB7x0 and SB8x0 southbridges (and maybe the newer chipsets too) the Delivery Mode bits in the IO-APIC redirection table MUST be programmed according to the HyperTransport specification, NOT the APIC specification and chipset documentations. For example, for NMIs the delivery mode has to be set to 3 (011b). BTW, the HyperTransport specification says that the destination ID should be 0xff (broadcast) for the NMI type, but in my tests it can be an individual APIC ID as well. Fixed, Lowest Priority and SMI modes have the same encoding in both specification. That explains why this peculiarity is not well known. Refer to Appendix F.1 of the HyperTransport 3.0 Specification for x86 interrupt delivery modes. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Mon Oct 10 05:07:16 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C0F61C0B6AD; Mon, 10 Oct 2016 05:07:16 +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 8661A8FB; Mon, 10 Oct 2016 05:07:16 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from julian-mbp3.pixel8networks.com (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u9A576x1072849 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 9 Oct 2016 22:07:08 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: fix for use-after-free problem in 10.x To: Oliver Pinter References: <7b732876-8cc3-a638-7ff1-e664060d4907@freebsd.org> Cc: FreeBSD Stable , freebsd From: Julian Elischer Message-ID: <0f543bb5-468e-e559-1bd8-8e2cf3f8bbc3@freebsd.org> Date: Sun, 9 Oct 2016 22:07:01 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 05:07:16 -0000 On 8/10/2016 5:36 AM, Oliver Pinter wrote: > On 10/5/16, Julian Elischer wrote: >> In 11 and 12 the taskqueue code has been rewritten in this area but >> under 10 this bug still occurs. >> >> On our appliances this bug stops the system from mounting the ZFS >> root, so it is quite severe. >> Basically while the thread is sleeping during the ZFS mount of root >> (in the while loop), another thread can free the 'task' item it is >> checking in that while loop and it can be reused or filled with >> 'deadcode' etc., with the waiting code unaware of the change.. The fix >> is to refetch the item at the end of the queue each time around the loop. >> I don't really want to do the bigger change of MFCing the change in >> 11, as it is more extensive, though if someone else does, that's ok by >> me. (If it's ABI compatible) >> >> Any comments or suggestions? > Yes, please commit them. This patch fixes the ZFS + GELI + INVARIANTS > problem for us. > There is the FreeBSD PR about the issue: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209580 I committed a slightly better version to stable/10 should I ask for a merge to releng/10.3? > >> here's the fix in diff form: >> >> >> [robot@porridge /usr/src]$ p4 diff -du ... >> --- //depot/pbranches/jelischer/FreeBSD-PZ/10.3/sys/kern/subr_taskqueue.c >> 2016-09-27 09:14:59.000000000 -0700 >> +++ /usr/src/sys/kern/subr_taskqueue.c 2016-09-27 09:14:59.000000000 -0700 >> @@ -441,9 +441,10 @@ >> >> TQ_LOCK(queue); >> task = STAILQ_LAST(&queue->tq_queue, task, ta_link); >> - if (task != NULL) >> - while (task->ta_pending != 0) >> - TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, "-", >> 0); >> + while (task != NULL && task->ta_pending != 0) { >> + TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, "-", 0); >> + task = STAILQ_LAST(&queue->tq_queue, task, ta_link); >> + } >> taskqueue_drain_running(queue); >> KASSERT(STAILQ_EMPTY(&queue->tq_queue), >> ("taskqueue queue is not empty after draining")); >> >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" >> From owner-freebsd-hackers@freebsd.org Mon Oct 10 05:16:14 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E152FC0BA0A; Mon, 10 Oct 2016 05:16:14 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (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 AE5C1ECA; Mon, 10 Oct 2016 05:16:14 +0000 (UTC) (envelope-from koobs.freebsd@gmail.com) Received: by mail-pa0-x235.google.com with SMTP id vu5so10485218pab.0; Sun, 09 Oct 2016 22:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:reply-to:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/LYvxSHckmjvWcbTe2FScXBZS03dwCUQZ7oNodn+xjQ=; b=HG1vq88I2f9Wjfb5gDu+2LiP62slLfiuPaUDg1lglK6bhwYq/0jd1sxlH/PE4+rFK3 rNSxtme1fYO/7L8704vxJRXK/3OiUaUlK1LK3QtnOrjVsgbuvD5RaWz45k484lh2lIHW Az9l8JpMdLgESmD5Zxh8YFHdaNSb5esmFSp9EZjjWni1LCclsICqh6Dv3mqd9JOaxbg0 E0O1ovTY5bI/QKzVPlrdR5wyhhYDTZckX2bhPgd0T2oUtukvFa/Nz9gnt27T8Dp0fUNy cf98n19Qta19jU638P+/05owbiDeHy7gLRsOQvRifntR847v6HWUkb8VrGFAdR3aJr3K ewDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:reply-to:subject:to:cc:references:from :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=/LYvxSHckmjvWcbTe2FScXBZS03dwCUQZ7oNodn+xjQ=; b=a7MS97DtAy9xoFyZI1q9RScx1xFHnJQx5psu9mp4iQk8rDTVb7ctFmsNWBAmxPIyix ob7vZOsdwv7ShHEbOrhpbxhilDaiSlSXNMANrj5TjrN7/uxMsHAnw3XPdrM4fIIdqj8I 3vaVuiepxSrgn/8NXI5LLThCIyi6kv7IYTbuttoPBDQ8PFnFLsKvCIVMBOrzMQIf4B4A QScoz13USqs2Nmi5BoweTSuxscJ8z0vzJ0XZQ3AjPwiuolDMMPK3z5nhZJL96+VwPdGv NPbSCr45aCM/EA9VjI9iXVNndxs0OnBa+qal2ACrqJUZMBcyiq714lCXW9vHIiyyMRVA pSmQ== X-Gm-Message-State: AA6/9RmpMwAI7wvurYCqJc6kfGDH+9rwPs47RQxlY0Osjh+oYsjc39X6iKpvhwhzqKuNwg== X-Received: by 10.66.254.170 with SMTP id aj10mr51500153pad.124.1476076574154; Sun, 09 Oct 2016 22:16:14 -0700 (PDT) Received: from ?IPv6:2001:44b8:31ae:7b01:1c1a:5103:265d:bfaf? (2001-44b8-31ae-7b01-1c1a-5103-265d-bfaf.static.ipv6.internode.on.net. [2001:44b8:31ae:7b01:1c1a:5103:265d:bfaf]) by smtp.gmail.com with ESMTPSA id h8sm19911260pab.9.2016.10.09.22.16.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Oct 2016 22:16:13 -0700 (PDT) Sender: Kubilay Kocak Reply-To: koobs@FreeBSD.org Subject: Re: Who wants to get paid to maintain sshuttle for FreeBSD ? To: John Kozubik Cc: freebsd-hackers@freebsd.org, "freebsd-jobs@freebsd.org" References: From: Kubilay Kocak Message-ID: <83e12460-088d-efbb-0725-ea0a465e7da7@FreeBSD.org> Date: Mon, 10 Oct 2016 16:15:21 +1100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Thunderbird/51.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-AU Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 05:16:15 -0000 On 30/09/2016 1:54 AM, John Kozubik wrote: > > > (yep, cross-posting to jobs and hackers ...) > > > Hello, > > We (myself, rsync.net, 0x.co) are very interested in using sshuttle > on FreeBSD: > > https://github.com/sshuttle > > However the tool has never quite worked properly on FreeBSD[1] and > there appears to be no FreeBSD specific development that gets > contributed to it. > > We would like to pay someone - first to do some heavy lifting and > bring the project up to speed for FreeBSD, but then on a continued > basis to ensure it *keeps* working over time. Presumably this > involves creating a FreeBSD port as well as fixing the big issues. > > This is a job for someone who understands well the FreeBSD > networking stack, ipfw and NAT rules, and who has a small but > consistent amount of time to devote to this over the next few years. > > You would be paid as an independent contractor by rsync.net, Inc. > > Please email me and let me now if this interests you. > > Thanks, > > John Kozubik rsync.net / 0x.co > > > [1] DNS and UDP "leak" from the tunnel, among other things... John, I've gone ahead and just created/committed a port for sshuttle, including hooking up the test suite to the ports make test command to make QA and reporting an initial set of issues upstream much easier: https://svnweb.freebsd.org/changeset/ports/423637 I note several test (F)ailures to the the use of raising exceptions (rather than failing assert()'s), some (most?) of which at initial glance appear to be related to tests that utilise or test tproxy() functionality. Tests failing in that manner should instead be skipped on FreeBSD (and any other environment without tproxy support). A second set of failing tests appears to be related to IPv6 (only supported by sshuttle for tproxy method, as per docs) which again I believe should be skipped on environments without tproxy support. Perhaps this is a good first step to progress upstream, but I'm also happy to provide upstream with FreeBSD buildbots to assist them if they use it (I already do for other OSS projects). Feel free to hit me up off list or on IRC (#freebsd @ freenode) -- Regards, Kubilay From owner-freebsd-hackers@freebsd.org Mon Oct 10 08:32:35 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 262E0C07FF0 for ; Mon, 10 Oct 2016 08:32:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 50256B1; Mon, 10 Oct 2016 08:32:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id LAA18316; Mon, 10 Oct 2016 11:32:27 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1btW0Z-000Exu-5X; Mon, 10 Oct 2016 11:32:27 +0300 Subject: Re: hpet as nmi watchdog To: John Baldwin , freebsd-hackers@FreeBSD.org References: <56DEB97D.2010804@FreeBSD.org> <2056148.ZvOkyra82H@ralph.baldwin.cx> From: Andriy Gapon Message-ID: <2dd34cf9-fc85-c598-e631-e5c79f5f35ae@FreeBSD.org> Date: Mon, 10 Oct 2016 11:31:30 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <2056148.ZvOkyra82H@ralph.baldwin.cx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 08:32:35 -0000 On 23/05/2016 23:44, John Baldwin wrote: > On Tuesday, March 08, 2016 01:37:33 PM Andriy Gapon wrote: >> >> I toyed a little bit with an idea of using a HPET timer as an NMI watchdog. >> The idea is that a HPET timer is somehow configured to generate an NMI when it >> fires. The timer normally would not fire, of course, as it is constantly being >> reprogrammed to some future time as is the case for all watchdogs. >> >> I have written some proof of concept code using two approaches. One approach is >> to use the "FSB" (MSI-like) mode of a HPET timer and program a corresponding FSB >> data register (HPET_TIMER_FSB_VAL) with a value that sets NMI delivery mode >> using the IO-APIC specification. The other approach is to use legacy interrupt >> mode for the HPET timer and program a corresponding IO-APIC pin for NMI deliver >> mode. >> In both cases I haven't got a desired result - instead of an NMI a test system >> gets reset when the timer fires. I wonder if this is a quirk of my old hardware >> (HPET in AMD SB7xx, family 10h processor) or if my idea is a non-starter. > > This is an interesting idea. You could also use one of the other timers (8254, > etc.) as a watchdog by setting the I/O APIC pin to NMI as well. It maybe that > for the MSI case the chipset treats the NMI delivery mode as an error, hence > the reset. :-/ > I got this working on the same hardware using HyperTransport definition of the NMI message type (see my recent post in this mailing list). Both in the FSB/MSI and I/O-APIC modes. -- Andriy Gapon From owner-freebsd-hackers@freebsd.org Mon Oct 10 12:14:40 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C1793C07538 for ; Mon, 10 Oct 2016 12:14:40 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from demig.de (demig.de [81.169.228.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Parallels Panel", Issuer "Parallels Panel" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1A451B6B for ; Mon, 10 Oct 2016 12:14:39 +0000 (UTC) (envelope-from nkoch@demig.de) Received: (qmail 30321 invoked from network); 10 Oct 2016 14:06:55 +0200 Received: from b2b-130-180-89-86.unitymedia.biz (HELO firewall.demig.intra) (130.180.89.86) by demig.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 10 Oct 2016 14:06:55 +0200 Received: from SRV-FS-2.Demig.intra (nameserver.demig.intra [192.168.148.248]) by firewall.demig.intra (8.14.4/8.14.4) with ESMTP id u9AC6lAR073358 for ; Mon, 10 Oct 2016 14:06:47 +0200 (CEST) (envelope-from nkoch@demig.de) Received: from [192.168.148.215] (192.168.148.215) by SRV-FS-2 (192.168.148.248) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 10 Oct 2016 14:06:41 +0200 From: Norbert Koch Subject: Why at least 4 cylinder groups? To: References: <56A9D502.7010809@demig.de> <1453995911.1275.14.camel@freebsd.org> <56AA42CF.10408@demig.de> <1454001217.1275.19.camel@freebsd.org> Message-ID: Date: Mon, 10 Oct 2016 14:06:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <1454001217.1275.19.camel@freebsd.org> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 192.168.148.235 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 12:14:40 -0000 Hello. In an embedded system I am having a rather small (static) ram disk of about 1.5MB, formatted as UFS(1). Under FreeBSD 4 dumpfs shows me there is 1 cylinder group. Under FreeBSD 9 and 10 I see 4 cylinder groups. 4 is hard coded as the minimum value in ufs/ffs/fs.h. Why? Is there any technical reason not to have less than 4 cylinder groups? For my application the wasted 188KB make a difference. Thank you, Norbert Koch From owner-freebsd-hackers@freebsd.org Mon Oct 10 15:26:44 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EEA4DC07ABD for ; Mon, 10 Oct 2016 15:26:44 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A30EA289 for ; Mon, 10 Oct 2016 15:26:44 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id u9AFQUZu091582; Mon, 10 Oct 2016 08:26:30 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id u9AFQNuH091581; Mon, 10 Oct 2016 08:26:23 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201610101526.u9AFQNuH091581@pdx.rh.CN85.dnsmgr.net> Subject: Re: Why at least 4 cylinder groups? In-Reply-To: To: Norbert Koch Date: Mon, 10 Oct 2016 08:26:23 -0700 (PDT) CC: freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Mon, 10 Oct 2016 16:23:08 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 15:26:45 -0000 > Hello. > > In an embedded system I am having a rather > small (static) ram disk of about 1.5MB, > formatted as UFS(1). > > Under FreeBSD 4 dumpfs shows me there is > 1 cylinder group. > > Under FreeBSD 9 and 10 I see 4 cylinder groups. > > 4 is hard coded as the minimum value in ufs/ffs/fs.h. Why? I beleive this constant only applies to UFS version 2, newfs -O 2, which is default in FreeBSD 9 and 10. > Is there any technical reason not to have less > than 4 cylinder groups? Probably on a UFS2 file system yes, but as far as I can see not on a UFS1 file system. > For my application the wasted 188KB make a difference. Try: newfs -O 1 > Thank you, > Norbert Koch -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Mon Oct 10 23:17:40 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2D96C07720 for ; Mon, 10 Oct 2016 23:17:40 +0000 (UTC) (envelope-from romapera15@gmail.com) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 64C19825 for ; Mon, 10 Oct 2016 23:17:40 +0000 (UTC) (envelope-from romapera15@gmail.com) Received: by mail-lf0-x230.google.com with SMTP id l131so7439288lfl.2 for ; Mon, 10 Oct 2016 16:17:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=N3lTfGdWcNESFeJwbtng9JNmoxZsgLOTVGWiWbgoLvc=; b=A931ieyujHG5s0uaNucuT/W5yJJdK6FzcpEiXiwnP6nRHYmsrZQ0vMEQP9lojI0Bjz GNB3g6X7SIxjiz0x+uMGqdgcZeYvneTywOkYNAduTmg1csC4eeiNH/2lR+jQnRFRtDFG dA8rUGQx8ybAUCK2xBJSTqy++TLWUoRNhajg8QhZbbi8nKPg3MMgoHmuYF1k6uiK3nC4 Q4nKICz8ON4FFQL+lUGr4UkpfA2aUNs/gHBhQdFqUnYfGxKejk/W8lUHGv5CB9oSeS+w cOM0nmin4AiAE0/LDPpTzG5EQnQXigcjITEvHNgAm6IDm66lekxIGCoOz74+IqeWAPIz +atg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=N3lTfGdWcNESFeJwbtng9JNmoxZsgLOTVGWiWbgoLvc=; b=erEikPCvClvNbsqSuR8IWEncyl33xtZRjyus/yGGd3kCUJDRJnOQK9npDxcTjjVnlW k3M801chkANqN4KDUuKp52ZFJexBNbj0vna/49CsUOLKkr0Sk5A4IVq1JgZ55g9Vq1T5 EH1edmkUbGsWZXQRGNwgKwRnTBN/HP6JcY6Z/pbljMG+sErmGPD889rGzqenqy/rECzR dLV2/SbnPWT3nXpbkwYIJHpR3BV1UyWMwZBL8OJSk2/hn5G22N+oQB7/tw8wPuS2IUgj 8wXV8IrUSgx0yV09YfuPnU3I7rf4ADszUGerbtMwaTWocbFDzHnCtF7m9nas+AbAfumc 1FUQ== X-Gm-Message-State: AA6/9RkZOCS+nwM/kHRST3AHUtvBxfIh727i/Z2zRyn109CrTolG0gAGtIqxLVA8lP8JxM5ANWCnmpTF9ki2cA== X-Received: by 10.46.1.209 with SMTP id f78mr399142lji.38.1476141457534; Mon, 10 Oct 2016 16:17:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.158.4 with HTTP; Mon, 10 Oct 2016 16:17:36 -0700 (PDT) From: =?UTF-8?Q?fran=C3=A7ai_s?= Date: Mon, 10 Oct 2016 20:17:36 -0300 Message-ID: Subject: What are the codes that contain the marcos that are created directly or the .word directives that are used in their work to make certain things work that cannot work otherwise? To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Oct 2016 23:17:41 -0000 It has come to my attention the following: "The minority of FreeBSD developers either create a macro expands to something like ".word =E2=80=9C or sometimes the .word is just = hard coded inline when there=E2=80=99s only going to be one of them, sometimes e= xpose them both in assembly and in C code, in which case what we do varies a bit to accommodate the different language=E2=80=99s syntax. It is rare, but has happened, that we only expose it to C code. Generally, though, the minority of FreeBSD developers try to add support for the opcodes to gas so that get the constraint testing it does (making sure the opcode is supported at the level you are compiling, making sure it isn=E2=80=99t in a delay slot or violating some other precondition for its = use). People generally don=E2=80=99t write in raw machine opcodes. That is indepe= ndent of FreeBSD. However, a few, specialized people will find the need to do it from time to time. Usually because they are porting FreeBSD to a newer processor that needs newer opcodes to do context switching, optimize interrupt handling, code with a new type of cache coherency, etc. These people look up the assembler in the docs from the vendor and then create the .word workaround to make sure things work. If they have the time, they may add it to our somewhat ancient gas assembler as well." What are the codes that contain the marcos that I described above sometimes when doing specific, low-level coding? What are the codes that contain the marcos that are created directly or the .word directives that are used in their work to make certain things work that cannot work otherwise? From owner-freebsd-hackers@freebsd.org Tue Oct 11 06:52:21 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B35EFC0D062 for ; Tue, 11 Oct 2016 06:52:21 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from demig.de (demig.de [81.169.228.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Parallels Panel", Issuer "Parallels Panel" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 21FC5DCC for ; Tue, 11 Oct 2016 06:52:20 +0000 (UTC) (envelope-from nkoch@demig.de) Received: (qmail 17394 invoked from network); 11 Oct 2016 08:51:15 +0200 Received: from b2b-130-180-89-86.unitymedia.biz (HELO firewall.demig.intra) (130.180.89.86) by demig.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 11 Oct 2016 08:51:15 +0200 Received: from SRV-FS-2.Demig.intra (nameserver.demig.intra [192.168.148.248]) by firewall.demig.intra (8.14.4/8.14.4) with ESMTP id u9B6ojKA083099 for ; Tue, 11 Oct 2016 08:50:45 +0200 (CEST) (envelope-from nkoch@demig.de) Received: from [192.168.148.215] (192.168.148.215) by SRV-FS-2 (192.168.148.248) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Oct 2016 08:50:44 +0200 Subject: Re: Why at least 4 cylinder groups? References: <201610101526.u9AFQNuH091581@pdx.rh.CN85.dnsmgr.net> From: Norbert Koch To: Message-ID: <24c7ca75-d50d-a7d2-933b-15ce4cf04b94@demig.de> Date: Tue, 11 Oct 2016 08:50:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <201610101526.u9AFQNuH091581@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 192.168.148.235 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 06:52:21 -0000 Am 2016-10-10 um 17:26 schrieb Rodney W. Grimes: >> Hello. >> >> In an embedded system I am having a rather >> small (static) ram disk of about 1.5MB, >> formatted as UFS(1). >> >> Under FreeBSD 4 dumpfs shows me there is >> 1 cylinder group. >> >> Under FreeBSD 9 and 10 I see 4 cylinder groups. >> >> 4 is hard coded as the minimum value in ufs/ffs/fs.h. Why? > I beleive this constant only applies to UFS version 2, newfs -O 2, > which is default in FreeBSD 9 and 10. > >> Is there any technical reason not to have less >> than 4 cylinder groups? > Probably on a UFS2 file system yes, but as far as I can > see not on a UFS1 file system. > >> For my application the wasted 188KB make a difference. > Try: > newfs -O 1 I already use UFS1. I compiled newfs with MINCYLGRPS=1. This is what dumpfs gives me before and after: --- //Entw-pr2/nk/x/de95b Mon Oct 10 13:07:47 2016 +++ //Entw-pr2/nk/x/de95c Mon Oct 10 14:27:52 2016 @@ -1,19 +1,19 @@ -magic 11954 (UFS1) time Mon Oct 10 11:07:39 2016 -id [ 57fb7662 72cbad24 ] -ncg 4 size 3072 blocks 2143 +magic 11954 (UFS1) time Mon Oct 10 12:29:18 2016 +id [ 57fb8985 18e78a1d ] +ncg 1 size 3072 blocks 2247 bsize 4096 shift 12 mask 0xfffff000 fsize 512 shift 9 mask 0xfffffe00 frag 8 shift 3 fsbtodb 0 minfree 8% optim time symlinklen 60 maxbpg 512 maxcontig 32 contigsumsize 16 -nbfree 258 ndir 4 nifree 3189 nffree 30 -cpg 1 bpg 97 fpg 776 ipg 800 +nbfree 273 ndir 4 nifree 3061 nffree 13 +cpg 1 bpg 384 fpg 3072 ipg 3072 nindir 1024 inopb 32 nspf 1 maxfilesize 4402345721855 -sbsize 1536 cgsize 512 cgoffset 0 cgmask 0xffffffff -csaddr 256 cssize 512 +sbsize 1536 cgsize 1536 cgoffset 0 cgmask 0xffffffff +csaddr 824 cssize 512 rotdelay 0ms rps 60 trackskew 0 interleave 1 -nsect 776 npsect 776 spc 776 -sblkno 32 cblkno 48 iblkno 56 dblkno 256 +nsect 3072 npsect 3072 spc 3072 +sblkno 32 cblkno 48 iblkno 56 dblkno 824 cgrotor 0 fmod 0 ronly 0 clean 0 avgfpdir 64 avgfilesize 16384 ... So, afaics technically one cylinder group would be ok for UFS1, right? From owner-freebsd-hackers@freebsd.org Tue Oct 11 07:14:43 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D23BC0D6C1 for ; Tue, 11 Oct 2016 07:14:43 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 00F3DB1F for ; Tue, 11 Oct 2016 07:14:42 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp59-167-167-3.static.internode.on.net [59.167.167.3]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u9B7EGpL004074 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 11 Oct 2016 18:14:22 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u9B7E9dK060849 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 11 Oct 2016 18:14:10 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u9B7E92B060848; Tue, 11 Oct 2016 18:14:09 +1100 (AEDT) (envelope-from peter) Date: Tue, 11 Oct 2016 18:14:09 +1100 From: Peter Jeremy To: Norbert Koch Cc: freebsd-hackers@freebsd.org Subject: Re: Why at least 4 cylinder groups? Message-ID: <20161011071409.GL76775@server.rulingia.com> References: <201610101526.u9AFQNuH091581@pdx.rh.CN85.dnsmgr.net> <24c7ca75-d50d-a7d2-933b-15ce4cf04b94@demig.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5G06lTa6Jq83wMTw" Content-Disposition: inline In-Reply-To: <24c7ca75-d50d-a7d2-933b-15ce4cf04b94@demig.de> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 07:14:43 -0000 --5G06lTa6Jq83wMTw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-Oct-11 08:50:44 +0200, Norbert Koch wrote: >Am 2016-10-10 um 17:26 schrieb Rodney W. Grimes: >>> In an embedded system I am having a rather >>> small (static) ram disk of about 1.5MB, >>> formatted as UFS(1). ufs2 is designed to work around some space limitations in ufs1 and so needs more space. If you're space-limited, ufs1 is probably a better choic= e. >>> Is there any technical reason not to have less >>> than 4 cylinder groups? >> Probably on a UFS2 file system yes, but as far as I can >> see not on a UFS1 file system. >> >>> For my application the wasted 188KB make a difference. =2E.. >So, afaics technically one cylinder group would be ok for UFS1, right? The reasons for multiple CGs are: 1) Improve performance by limiting the seek distance to a CG. 2) Provide redundant superblocks to protect against bad blocks. Neither of these reasons apply to a ramdisk. If you're keen to maximise data space, you might like to also reduce ipg (increase '-i'). --=20 Peter Jeremy --5G06lTa6Jq83wMTw Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJX/JFBXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0DfsQAJfr2izb/79SFJyitGZq4xal LCF5cvX+1j059fM1k+gZq9XgU1VhZAnr3vjtHzEj6+06YpY77MstoY6Nc+wuv06w xnacU+bxtJLQrhYBg5GemKo4zd1NL79ZizxxTpxRoqoxC3dmTYNMIPxF8kw7J+/w fF0V7cLyUcnIQtcMb3RDc0Db9mQGehZp8qYBwqXuUtrnUQlPWt5z0YxR7m3s+ei5 isq/oi5JV0i95MlelzWbYEe92CMuoPIu4IF8qBUNC45VcOnuif9oZnN+MWVW01gj MIGfStPGjY6hCzfOeogT8welXPrV0Sw/YaG3J0zPewVu/K4bIpYlswkoEOwvoQCj M8qsWn7nlRDFRHMPAeQWUqA6XUnTq+z9zd7HunAyYp3/9VeXk5jKBAcvSGA1q35E tBm3GgPrAUdIup6CHwKrGa+0tmFAj3jBLjuqz2fIOMedqJvEdV5Qel5cuL5In74f z6TjffsdBJQ0IRfVqnP2x6SOuAyRNnu4GnTmH/46rNONPoC8yi7/YE2/A1ByAnFg NsDD6AjiRAWDDwsj01wapBlpe7H8z99UikLv5PE1lY1ohIcydZN5MFfQxQNlYuhb HTIft9iRamp/6u7Q7BqLggou9UyMPy1ZhMqj3Sb26tP9BcsAwhGGttBU6CN4fmXz 6IZbv/CaXb4ggjwGfzH4 =BQOz -----END PGP SIGNATURE----- --5G06lTa6Jq83wMTw-- From owner-freebsd-hackers@freebsd.org Tue Oct 11 11:10:47 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BE9F2C0DE5F for ; Tue, 11 Oct 2016 11:10:47 +0000 (UTC) (envelope-from oliver.pinter@balabit.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 859CEEAC for ; Tue, 11 Oct 2016 11:10:47 +0000 (UTC) (envelope-from oliver.pinter@balabit.com) Received: by mail-qk0-x236.google.com with SMTP id o68so26920545qkf.3 for ; Tue, 11 Oct 2016 04:10:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=balabit-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZgP7+ZucgGo0z2mDCYbYIFZMTABuBdjYzkb5qlEsTRQ=; b=qqndJYdmaP17vPi0zA0jb/UUGgmWVEh90edbEvzlReEZpF05bwXNdMfhi5+8fMSO/6 LDrj/leCEIMD8RDRWoq/R/2Ma2TzyxDcf2CqeupPauB1iD7VlNiB7dp4p9gsaAN5WKsR +RCoa10x+0BT9wNgbye0M2xG30SiMHXeNzrGBbcf9By/vixTfUp4aNqIMJKefeKopOnr 4wEgY5LMx446nrfLhpp8LxoHqwBVdlAK5NhPMu2uzhPB/JlbLubkTpVoQOeRIuc4LWPi l6xsaKTJuTlOk6mNIAd5UdLHUySlGNm+G1B0SaXyyRe24jbGoabIVikkNgq7MBFt1vp5 RCKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZgP7+ZucgGo0z2mDCYbYIFZMTABuBdjYzkb5qlEsTRQ=; b=lAURPZvFkdPYRH+cWVBFNUQi8yzihxObaKYVLjQTD3dHGQmvAmyM9NxkPmx7fhJqA1 3Sk6Q2YaGvz1SuR7I2soZA8sXS953sL0xlQh3HxjzZUwkmGTw3qkRSBDTL08ZPjgr+Bt aDqSH12WQa0gysXAFjtFNAWin2myEtMDeuTYSI9zx1SdaOlvhgPXMfk254d5xiyRmu5j 5CnkmAcB2E563SX6X1zRf9od76+d3gTbXVmiWyUqiL07I+G9KIrVOgQtc77cY0KhYUgh jeCjR8DHWx0jJ8rLGo3q0NatyJlQo3Hvz5kPAuVtdRmFJDyXeA3ZYUCPW+3p8Y4qR4yX ezNA== X-Gm-Message-State: AA6/9RkMCRDgAjUkSAZ2FqFXTFVxsp/kwpwfFIEkMespqnNzEIuDUFD2+lmkJsW5PRc/Ru76lZ1o8tVlfPE2Ocem X-Received: by 10.194.220.232 with SMTP id pz8mr4215320wjc.154.1476184246566; Tue, 11 Oct 2016 04:10:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.162.103 with HTTP; Tue, 11 Oct 2016 04:10:45 -0700 (PDT) In-Reply-To: <0f543bb5-468e-e559-1bd8-8e2cf3f8bbc3@freebsd.org> References: <7b732876-8cc3-a638-7ff1-e664060d4907@freebsd.org> <0f543bb5-468e-e559-1bd8-8e2cf3f8bbc3@freebsd.org> From: =?UTF-8?B?UGludMOpciwgT2xpdsOpcg==?= Date: Tue, 11 Oct 2016 13:10:45 +0200 Message-ID: Subject: Re: fix for use-after-free problem in 10.x To: Julian Elischer Cc: Oliver Pinter , freebsd , FreeBSD Stable X-Mailman-Approved-At: Tue, 11 Oct 2016 11:33:25 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 11:10:47 -0000 On Mon, Oct 10, 2016 at 7:07 AM, Julian Elischer wrote: > On 8/10/2016 5:36 AM, Oliver Pinter wrote: > >> On 10/5/16, Julian Elischer wrote: >> >>> In 11 and 12 the taskqueue code has been rewritten in this area but >>> under 10 this bug still occurs. >>> >>> On our appliances this bug stops the system from mounting the ZFS >>> root, so it is quite severe. >>> Basically while the thread is sleeping during the ZFS mount of root >>> (in the while loop), another thread can free the 'task' item it is >>> checking in that while loop and it can be reused or filled with >>> 'deadcode' etc., with the waiting code unaware of the change.. The fix >>> is to refetch the item at the end of the queue each time around the loop. >>> I don't really want to do the bigger change of MFCing the change in >>> 11, as it is more extensive, though if someone else does, that's ok by >>> me. (If it's ABI compatible) >>> >>> Any comments or suggestions? >>> >> Yes, please commit them. This patch fixes the ZFS + GELI + INVARIANTS >> problem for us. >> There is the FreeBSD PR about the issue: >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=209580 >> > > I committed a slightly better version to stable/10 > should I ask for a merge to releng/10.3? Yes, it would be really nice! Thanks your effort! > > > > > >> here's the fix in diff form: >>> >>> >>> [robot@porridge /usr/src]$ p4 diff -du ... >>> --- //depot/pbranches/jelischer/FreeBSD-PZ/10.3/sys/kern/subr_ta >>> skqueue.c >>> 2016-09-27 09:14:59.000000000 -0700 >>> +++ /usr/src/sys/kern/subr_taskqueue.c 2016-09-27 09:14:59.000000000 >>> -0700 >>> @@ -441,9 +441,10 @@ >>> >>> TQ_LOCK(queue); >>> task = STAILQ_LAST(&queue->tq_queue, task, ta_link); >>> - if (task != NULL) >>> - while (task->ta_pending != 0) >>> - TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, >>> "-", >>> 0); >>> + while (task != NULL && task->ta_pending != 0) { >>> + TQ_SLEEP(queue, task, &queue->tq_mutex, PWAIT, "-", 0); >>> + task = STAILQ_LAST(&queue->tq_queue, task, ta_link); >>> + } >>> taskqueue_drain_running(queue); >>> KASSERT(STAILQ_EMPTY(&queue->tq_queue), >>> ("taskqueue queue is not empty after draining")); >>> >>> _______________________________________________ >>> freebsd-hackers@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers >>> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@f >>> reebsd.org" >>> >>> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-hackers@freebsd.org Tue Oct 11 16:06:55 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2DB6DC0D3F7 for ; Tue, 11 Oct 2016 16:06:55 +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 9D3F6B0C for ; Tue, 11 Oct 2016 16:06:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u9BG6lC9041927 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 11 Oct 2016 19:06:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u9BG6lC9041927 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u9BG6kfk041926; Tue, 11 Oct 2016 19:06:46 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Oct 2016 19:06:46 +0300 From: Konstantin Belousov To: Peter Jeremy Cc: Norbert Koch , freebsd-hackers@freebsd.org Subject: Re: Why at least 4 cylinder groups? Message-ID: <20161011160646.GT68202@kib.kiev.ua> References: <201610101526.u9AFQNuH091581@pdx.rh.CN85.dnsmgr.net> <24c7ca75-d50d-a7d2-933b-15ce4cf04b94@demig.de> <20161011071409.GL76775@server.rulingia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161011071409.GL76775@server.rulingia.com> User-Agent: Mutt/1.7.0 (2016-08-17) 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.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 16:06:55 -0000 On Tue, Oct 11, 2016 at 06:14:09PM +1100, Peter Jeremy wrote: > On 2016-Oct-11 08:50:44 +0200, Norbert Koch wrote: > >Am 2016-10-10 um 17:26 schrieb Rodney W. Grimes: > >>> In an embedded system I am having a rather > >>> small (static) ram disk of about 1.5MB, > >>> formatted as UFS(1). > > ufs2 is designed to work around some space limitations in ufs1 and so > needs more space. If you're space-limited, ufs1 is probably a better choice. > > >>> Is there any technical reason not to have less > >>> than 4 cylinder groups? > >> Probably on a UFS2 file system yes, but as far as I can > >> see not on a UFS1 file system. > >> > >>> For my application the wasted 188KB make a difference. > ... > >So, afaics technically one cylinder group would be ok for UFS1, right? > > The reasons for multiple CGs are: > 1) Improve performance by limiting the seek distance to a CG. > 2) Provide redundant superblocks to protect against bad blocks. > Neither of these reasons apply to a ramdisk. > > If you're keen to maximise data space, you might like to also reduce > ipg (increase '-i'). I am not aware of the reason why MINCYLGRPS exists at all. If your goal is reducing the memory consumption for the kernel and metadata overhead with the fixed amount of data to access, you may consider using tmpfs. The additional kernel text size is tiny 50K, comparing with the 1.5M disk size. If you mmap(2) the data from the ramdisk, then you will save the amount of memory twice the size of your mmaped data. tmpfs allows to set limits on mount, so you can have safety belts as well. The recommendation is valid if you use stable/10, 11 or HEAD. From owner-freebsd-hackers@freebsd.org Tue Oct 11 16:18:49 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8AD39C0D7F0 for ; Tue, 11 Oct 2016 16:18:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D3CE5FB for ; Tue, 11 Oct 2016 16:18:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id u9BGIavu096745; Tue, 11 Oct 2016 09:18:36 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id u9BGIEXg096743; Tue, 11 Oct 2016 09:18:14 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201610111618.u9BGIEXg096743@pdx.rh.CN85.dnsmgr.net> Subject: Re: Why at least 4 cylinder groups? In-Reply-To: <20161011160646.GT68202@kib.kiev.ua> To: Konstantin Belousov Date: Tue, 11 Oct 2016 09:18:14 -0700 (PDT) CC: Peter Jeremy , Norbert Koch , freebsd-hackers@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Mailman-Approved-At: Tue, 11 Oct 2016 16:26:48 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Oct 2016 16:18:49 -0000 > On Tue, Oct 11, 2016 at 06:14:09PM +1100, Peter Jeremy wrote: > > On 2016-Oct-11 08:50:44 +0200, Norbert Koch wrote: > > >Am 2016-10-10 um 17:26 schrieb Rodney W. Grimes: > > >>> In an embedded system I am having a rather > > >>> small (static) ram disk of about 1.5MB, > > >>> formatted as UFS(1). > > > > ufs2 is designed to work around some space limitations in ufs1 and so > > needs more space. If you're space-limited, ufs1 is probably a better choice. > > > > >>> Is there any technical reason not to have less > > >>> than 4 cylinder groups? > > >> Probably on a UFS2 file system yes, but as far as I can > > >> see not on a UFS1 file system. > > >> > > >>> For my application the wasted 188KB make a difference. > > ... > > >So, afaics technically one cylinder group would be ok for UFS1, right? > > > > The reasons for multiple CGs are: > > 1) Improve performance by limiting the seek distance to a CG. > > 2) Provide redundant superblocks to protect against bad blocks. > > Neither of these reasons apply to a ramdisk. > > > > If you're keen to maximise data space, you might like to also reduce > > ipg (increase '-i'). > > I am not aware of the reason why MINCYLGRPS exists at all. I tracked back in svn and this was infact added with the UFS2 support, I understand the goal in the code, which is good for larger file systems, but is probably a bad idea when the file system total size is so small that a CG would not contain at least something like 64 cylinders. This is a regersion, very old, but should probably be looked at by Kirk or another FS expert. Commit that added the relevant #define and code implementing MINCYLGRPS https://svnweb.freebsd.org/base?view=revision&revision=98542 And relative parts of that commit: https://svnweb.freebsd.org/base/head/sys/ufs/ffs/fs.h?r1=98542&r2=98541&pathrev=98542 https://svnweb.freebsd.org/base/head/sbin/newfs/mkfs.c?r1=98542&r2=98541&pathrev=98542 ... -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-hackers@freebsd.org Wed Oct 12 06:44:09 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DB619C0E9D3 for ; Wed, 12 Oct 2016 06:44:09 +0000 (UTC) (envelope-from nkoch@demig.de) Received: from demig.de (demig.de [81.169.228.196]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Parallels Panel", Issuer "Parallels Panel" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 33BC8CFE for ; Wed, 12 Oct 2016 06:44:08 +0000 (UTC) (envelope-from nkoch@demig.de) Received: (qmail 15396 invoked from network); 12 Oct 2016 08:43:00 +0200 Received: from b2b-130-180-89-86.unitymedia.biz (HELO firewall.demig.intra) (130.180.89.86) by demig.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 12 Oct 2016 08:43:00 +0200 Received: from SRV-FS-2.Demig.intra (nameserver.demig.intra [192.168.148.248]) by firewall.demig.intra (8.14.4/8.14.4) with ESMTP id u9C6gnJJ094914 for ; Wed, 12 Oct 2016 08:42:49 +0200 (CEST) (envelope-from nkoch@demig.de) Received: from [192.168.148.215] (192.168.148.215) by SRV-FS-2 (192.168.148.248) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 12 Oct 2016 08:42:44 +0200 Subject: Re: Why at least 4 cylinder groups? References: <201610101526.u9AFQNuH091581@pdx.rh.CN85.dnsmgr.net> <24c7ca75-d50d-a7d2-933b-15ce4cf04b94@demig.de> <20161011071409.GL76775@server.rulingia.com> <20161011160646.GT68202@kib.kiev.ua> From: Norbert Koch To: Message-ID: Date: Wed, 12 Oct 2016 08:42:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <20161011160646.GT68202@kib.kiev.ua> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.73 on 192.168.148.235 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 06:44:09 -0000 Am 2016-10-11 um 18:06 schrieb Konstantin Belousov: > If your goal is reducing the memory consumption for the kernel and metadata > overhead with the fixed amount of data to access, you may consider using > tmpfs. The additional kernel text size is tiny 50K, comparing with the > 1.5M disk size. If you mmap(2) the data from the ramdisk, then you will > save the amount of memory twice the size of your mmaped data. > > tmpfs allows to set limits on mount, so you can have safety belts as well. My ram disk is not a temporary storage. It is on a separate board equipped with battery backed static memory. So tmpfs is not an option for me. From owner-freebsd-hackers@freebsd.org Wed Oct 12 12:56:55 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCB32C0E058 for ; Wed, 12 Oct 2016 12:56:55 +0000 (UTC) (envelope-from pblok@bsd4all.org) Received: from mail.bsd4all.org (mail.bsd4all.org [78.47.125.12]) by mx1.freebsd.org (Postfix) with ESMTP id 83FCFC62 for ; Wed, 12 Oct 2016 12:56:55 +0000 (UTC) (envelope-from pblok@bsd4all.org) Received: from mail.bsd4all.org (localhost [127.0.0.1]) by mail.bsd4all.org (Postfix) with ESMTP id D489BD2FE for ; Wed, 12 Oct 2016 14:48:56 +0200 (CEST) X-Virus-Scanned: amavisd-new at bsd4all.org Received: from mail.bsd4all.org ([127.0.0.1]) by mail.bsd4all.org (newnas.bsd4all.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etDuKDBf4Ojv for ; Wed, 12 Oct 2016 14:48:56 +0200 (CEST) Received: from [192.168.1.64] (unknown [192.168.1.64]) by mail.bsd4all.org (Postfix) with ESMTPSA id 77708D2F8 for ; Wed, 12 Oct 2016 14:48:56 +0200 (CEST) From: Peter Blok Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: UEFI boot filter Message-Id: <1B741B89-B5CD-4EA4-9801-7B429CAF6792@bsd4all.org> Date: Wed, 12 Oct 2016 14:48:54 +0200 To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2016 12:56:55 -0000 My Asrock E3C224D4I-14S has a CSM option =E2=80=9CBoot option filter=E2=80= =9D which allows me to show only devices that can boot with UEFI. If it is set to UEFI and Legacy, FreeBSD boots fine over UEFI. If I set it to UEFI only, the disk is not found. I have Solaris 11.3 installed on a different disk and that one is listed = as =E2=80=9CORACLE Solaris 11.3=E2=80=9D in the list of bootable = devices, instead of the disk number and vendor id. FreeBSD doesn=E2=80=99t= show up in the list. Does anybody know how this mechanism works and how to make it work for = FreeBSD? Peter=