From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 11 07:43:05 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08956AE6; Sun, 11 Nov 2012 07:43:05 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 927A98FC0C; Sun, 11 Nov 2012 07:43:03 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so6665518oag.13 for ; Sat, 10 Nov 2012 23:43:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bJLwLbD6cfC6uEZM1jjvWX+SLJ5rstrj2uuziUHVoeI=; b=PMqxovCGdQ3rpDHm3wNDhJCmBF2AY+Ba9EHzQHge9go9LNPFZEAtThEyYxGUT8yRul Y3BqsKTXlySvUubg08YS2teey3MkJInlMp8CtOWeCY+VcmES50AmfGRSt8IFuZkczjfn uuIoKNlte+WR5+E3gE5oxSS/Gh7zxITB2XppWrIpfpRCHKavf+CdHZ91lK9Mhg5Xnu/O WdCug9Rn6DGNr4T+NM+78whSDQqnX0U58E+mJLb5JhGjxd02TMLMMgXzqY/4/+IT+ut6 bqGFH99l6yO+4SNf9IjpVfxUgiyY0X6oXuZFjOh/yt/QuJsCjHTJRLb90lniHlZiYQ// i3Hg== MIME-Version: 1.0 Received: by 10.182.127.102 with SMTP id nf6mr12909762obb.14.1352619783303; Sat, 10 Nov 2012 23:43:03 -0800 (PST) Received: by 10.182.133.40 with HTTP; Sat, 10 Nov 2012 23:43:03 -0800 (PST) In-Reply-To: References: <31C904E6-F230-4187-AE32-F9A7B1A7C38E@freebsd.org> <509CC1F6.1010308@freebsd.org> Date: Sun, 11 Nov 2012 09:43:03 +0200 Message-ID: Subject: Re: FreeBSD on RaspberryPi From: Sami Halabi To: Stefan Esser Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, Tim Kientzle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 07:43:05 -0000 ? On Sat, Nov 10, 2012 at 12:32 AM, Sami Halabi wrote: > Hi, > are there any plans to do images that support the hdmi output ? what about > analog sound vs the hdmi? > can the images be taken to the gui stage , ie xbmc or any other multimedia > screen ? > > Sami > > > On Fri, Nov 9, 2012 at 10:42 AM, Stefan Esser wrote: > >> Am 09.11.2012 05:44, schrieb Tim Kientzle: >> >> On Wed, Nov 7, 2012 at 6:01 PM, Tim Kientzle >> wrote: >> >> WARNING: This is still highly experimental and by no >> >> means ready for "production use", ... >> >> >> >> To boot FreeBSD on your RaspberryPi, you'll need: >> >> 1) A RaspberryPi. >> >> 2) A serial cable similar to this one: >> www.adafruit.com/products/954 >> > >> > >> > On Nov 8, 2012, at 9:13 AM, Sami Halabi wrote: >> >> >> >> why the console cable is needed ? >> >> >> > As far as I can tell, the code in FreeBSD-CURRENT >> > does not yet support the video out. So you need >> > a serial console cable to interact with it. >> >> All it takes to get the framebuffer working is that the hash chars are >> removed. I.e. the following works: >> >> device sc >> device kbdmux >> options SC_DFLT_FONT # compile font in >> makeoptions SC_DFLT_FONT=cp437 >> >> > You might be able to interact via SSH but >> > that requires a little bit more setup (a root >> > password needs to be set and you need to >> > edit /etc/ssh/sshd_config to allow root logins). >> >> I used SSH, and the framebuffer helps to see how far the boot process >> has come. It takes about 60 seconds to generate the SSH host keys, for >> example. >> >> [The following points are not specific to the R-PI, and I'm sure you >> know them, but I list them for others that may want to use their R-PI >> without serial console.] >> >> In order to use SSH I modified sshd_config to accept direct root logins. >> The root password must be set (best method: "vipw -d /mnt/etc", else >> you must remember to invoke "pwd_mkdb -d /mnt/etc" when you are done). >> >> The host name and IP address should be set in rc.conf (or assigned via >> DHCP). >> >> If you do not want to enable direct root login, then a non-privileged >> account in group wheel is required to be able to "su" to root. >> >> That's all I remember ... >> >> I used the build script from "http://kernelnomicon.org/?p=164" with >> one slight modification (tar -x ... --no-same-owner ...). >> >> My R-PI kernel contains MSDOSFS and NFS client support to allow it >> to mount its boot partition and NFS exported /usr/src, /usr/obj, >> /usr/ports and /usr/work (where I build ports). Most of them are >> R/O mounts. I have not tried to build world on the R-PI (cross >> building is so much faster ...). But ports can be build, if a swap >> partition is available (e.g. on SD card or via NFS - I did not try >> to mount a USB stick, but that might be another option). >> >> Regards, STefan >> _______________________________________________ >> 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 >> " >> > > > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert > > -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 11 20:40:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4DA0B2F5; Sun, 11 Nov 2012 20:40:11 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id 89EBB8FC08; Sun, 11 Nov 2012 20:40:10 +0000 (UTC) Received: from [207.6.254.8] (helo=[192.168.1.64]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1TXeK1-0008Fj-Su; Sun, 11 Nov 2012 12:40:03 -0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: FreeBSD on RaspberryPi From: Oleksandr Tymoshenko In-Reply-To: Date: Sun, 11 Nov 2012 12:39:42 -0800 Content-Transfer-Encoding: 7bit Message-Id: <1B7CD3EC-6F99-43A3-BAAA-EC6EA25D90A9@bluezbox.com> References: <31C904E6-F230-4187-AE32-F9A7B1A7C38E@freebsd.org> <509CC1F6.1010308@freebsd.org> To: Sami Halabi X-Mailer: Apple Mail (2.1499) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2012-11-09, at 2:32 PM, Sami Halabi wrote: > Hi, > are there any plans to do images that support the hdmi output ? what about > analog sound vs the hdmi? > can the images be taken to the gui stage , ie xbmc or any other multimedia > screen ? [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] Cc: freebsd-hackers@freebsd.org, Tim Kientzle X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 20:40:11 -0000 On 2012-11-09, at 2:32 PM, Sami Halabi wrote: > Hi, > are there any plans to do images that support the hdmi output ? what about > analog sound vs the hdmi? > can the images be taken to the gui stage , ie xbmc or any other multimedia > screen ? At the moment HDMI output works only in a sense of video output for simple frame buffer. I'm trying to get GPU support ported but not sure how much time it will take. Eventually we'd like to get audio support too. From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 11 20:46:36 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 80105553; Sun, 11 Nov 2012 20:46:36 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 445E18FC0C; Sun, 11 Nov 2012 20:46:36 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz17so2320593pbc.13 for ; Sun, 11 Nov 2012 12:46:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ORNwjDo8VzAwBLRefKCI4qslk/194c0FJ0f3MVcFQRY=; b=g5izqPEiQjHEf+XgDvuINjcHjeeKmkG1Vpw0tkbKxqYWCkghDTZorJfOor9YjUX+NO G5Fa9QUmHGTe7YWfNlqrUaoAmSyfjkZwVZ8/bi+nendamtjKoxDmn9N2j9TOXaogDa9R b+JlVsJxYmvABEmQ6ihyGVz9t2W8DjlPMny2sXJdHG+iuRVAu7et/FCE3nqsoctJF9xH C6+wLn7VL5SIfW/IS+o9kjmtH27NcXiypIKkvj7GbRwxhwAmu2kVswFFww6V35obpG+n 5akQBtn1uwDVGAuuGGO4W6abHJK0Kqx9e2nlCgB01jPQE3dxzuDIBkWFF/1rPt1/je7T hUbw== MIME-Version: 1.0 Received: by 10.68.137.198 with SMTP id qk6mr52008628pbb.60.1352666796013; Sun, 11 Nov 2012 12:46:36 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Sun, 11 Nov 2012 12:46:35 -0800 (PST) In-Reply-To: <1B7CD3EC-6F99-43A3-BAAA-EC6EA25D90A9@bluezbox.com> References: <31C904E6-F230-4187-AE32-F9A7B1A7C38E@freebsd.org> <509CC1F6.1010308@freebsd.org> <1B7CD3EC-6F99-43A3-BAAA-EC6EA25D90A9@bluezbox.com> Date: Sun, 11 Nov 2012 12:46:35 -0800 X-Google-Sender-Auth: EwxSzb054HqDDHfh8B8tk4yIoLQ Message-ID: Subject: Re: FreeBSD on RaspberryPi From: Adrian Chadd To: Oleksandr Tymoshenko Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Tim Kientzle , Sami Halabi X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 20:46:36 -0000 On 11 November 2012 12:39, Oleksandr Tymoshenko wrote: > At the moment HDMI output works only in a sense of video output for simple > frame buffer. I'm trying to get GPU support ported but not sure how much time > it will take. Eventually we'd like to get audio support too. How's the general, non-video support working out? Are there any random crashes or panics that people are seeing on R-PI right now? Adrian From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 11 21:40:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 85693D4F for ; Sun, 11 Nov 2012 21:40:26 +0000 (UTC) (envelope-from alan.l.cox@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id EDDF98FC15 for ; Sun, 11 Nov 2012 21:40:25 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id e12so5255816lag.13 for ; Sun, 11 Nov 2012 13:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=HLk8ubLil2s4zpDEwfxCwMvphaCvos32bD/SwF8yNbo=; b=MGcvzX5E7QxO/2bQBEa/zNpCfKbG2nFaqv3i5wCxQvvC5POkrNcZ/kKxoNzYAn0Azf DPEVbXwmgDvxQGM708whGh3iZgXLeOomCLuLFhOtt4EkWlIG8ILXxoDNSiJ+U7cuGQPp Z0N10TGs0P+lQPZnd5kGVj2qSdK0Kdo4Q6qNERJ2Er9UGD8lw4AsFrKgM0lgSSXiMi3v cX0bFfhRjesrIhawbJDnL+SBDfdq2euFxtG2B5JGvD3ziExub30t1lT6X3UlfU8XWIDO C8zZsUSpTuu2PWuA7n3Fr9riRLQzs503k/jG+rrnuhzjMHYAznGy8ivG2XW9kG2dioYI WXPw== MIME-Version: 1.0 Received: by 10.112.98.37 with SMTP id ef5mr7191435lbb.84.1352670024314; Sun, 11 Nov 2012 13:40:24 -0800 (PST) Received: by 10.114.61.103 with HTTP; Sun, 11 Nov 2012 13:40:24 -0800 (PST) In-Reply-To: <20121110132019.GP73505@kib.kiev.ua> References: <20121110132019.GP73505@kib.kiev.ua> Date: Sun, 11 Nov 2012 15:40:24 -0600 Message-ID: Subject: Re: Memory reserves or lack thereof From: Alan Cox To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-hackers@freebsd.org" , "Sears, Steven" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: alc@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 21:40:26 -0000 On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov wrote: > On Fri, Nov 09, 2012 at 07:10:04PM +0000, Sears, Steven wrote: > > I have a memory subsystem design question that I'm hoping someone can > answer. > > > > I've been looking at a machine that is completely out of memory, as in > > > > v_free_count = 0, > > v_cache_count = 0, > > > > I wondered how a machine could completely run out of memory like this, > especially after finding a lack of interrupt storms or other pathologies > that would tend to overcommit memory. So I started investigating. > > > > Most allocators come down to vm_page_alloc(), which has this guard: > > > > if ((curproc == pageproc) && (page_req != VM_ALLOC_INTERRUPT)) { > > page_req = VM_ALLOC_SYSTEM; > > }; > > > > if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved || > > (page_req == VM_ALLOC_SYSTEM && > > cnt.v_free_count + cnt.v_cache_count > > cnt.v_interrupt_free_min) || > > (page_req == VM_ALLOC_INTERRUPT && > > cnt.v_free_count + cnt.v_cache_count > 0)) { > > > > The key observation is if VM_ALLOC_INTERRUPT is set, it will allocate > every last page. > > > > >From the name one might expect VM_ALLOC_INTERRUPT to be somewhat rare, > perhaps only used from interrupt threads. Not so, see kmem_malloc() or > uma_small_alloc() which both contain this mapping: > > > > if ((flags & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) > > pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; > > else > > pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; > > > > Note that M_USE_RESERVE has been deprecated and is used in just a > handful of places. Also note that lots of code paths come through these > routines. > > > > What this means is essentially _any_ allocation using M_NOWAIT will > bypass whatever reserves have been held back and will take every last page > available. > > > > There is no documentation stating M_NOWAIT has this side effect of > essentially being privileged, so any innocuous piece of code that can't > block will use it. And of course M_NOWAIT is literally used all over. > > > > It looks to me like the design goal of the BSD allocators is on > recovery; it will give all pages away knowing it can recover. > > > > Am I missing anything? I would have expected some small number of pages > to be held in reserve just in case. And I didn't expect M_NOWAIT to be a > sort of back door for grabbing memory. > > > > Your analysis is right, there is nothing to add or correct. > This is the reason to strongly prefer M_WAITOK. > Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was well understand that it should only be used by interrupt handlers. The trouble is that M_NOWAIT conflates two orthogonal things. The obvious being that the allocation shouldn't sleep. The other being how far we're willing to deplete the cache/free page queues. When fine-grained locking got sprinkled throughout the kernel, we all to often found ourselves wanting to do allocations without the possibility of blocking. So, M_NOWAIT became commonplace, where it wasn't before. This had the unintended consequence of introducing a lot of memory allocations in the top-half of the kernel, i.e., non-interrupt handling code, that were digging deep into the cache/free page queues. Also, ironically, in today's kernel an "M_NOWAIT | M_USE_RESERVE" allocation is less likely to succeed than an "M_NOWAIT" allocation. However, prior to FreeBSD 7.x, M_NOWAIT couldn't allocate a cached page; it could only allocate a free page. M_USE_RESERVE said that it ok to allocate a cached page even though M_NOWAIT was specified. Consequently, the system wouldn't dig as far into the free page queue if M_USE_RESERVE was specified, because it was allowed to reclaim a cached page. In conclusion, I think it's time that we change M_NOWAIT so that it doesn't dig any deeper into the cache/free page queues than M_WAITOK does and reintroduce a M_USE_RESERVE-like flag that says dig deep into the cache/free page queues. The trouble is that we then need to identify all of those places that are implicitly depending on the current behavior of M_NOWAIT also digging deep into the cache/free page queues so that we can add an explicit M_USE_RESERVE. Alan P.S. I suspect that we should also increase the size of the "page reserve" that is kept for VM_ALLOC_INTERRUPT allocations in vm_page_alloc*(). How many legitimate users of a new M_USE_RESERVE-like flag in today's kernel could actually be satisfied by two pages? From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 00:36:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 424D5204 for ; Mon, 12 Nov 2012 00:36:32 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id D7A888FC0C for ; Mon, 12 Nov 2012 00:36:31 +0000 (UTC) Received: (qmail 18890 invoked by uid 0); 12 Nov 2012 00:32:15 -0000 Received: from 67.206.184.26 by rms-us014 with HTTP Content-Type: text/plain; charset="utf-8" Date: Sun, 11 Nov 2012 19:32:13 -0500 From: "Dieter BSD" Message-ID: <20121112003215.238950@gmx.com> MIME-Version: 1.0 Subject: Re: Memory reserves or lack thereof To: freebsd-hackers@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: 2CbScDM83zOlNR3dAHAh3Xh+IGRvb8DR X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 00:36:32 -0000 Alan writes: > In conclusion, I think it's time that we change M_NOWAIT so that it doesn't > dig any deeper into the cache/free page queues than M_WAITOK does and > reintroduce a M_USE_RESERVE-like flag that says dig deep into the > cache/free page queues.  The trouble is that we then need to identify all > of those places that are implicitly depending on the current behavior of > M_NOWAIT also digging deep into the cache/free page queues so that we can > add an explicit M_USE_RESERVE. find /usr/src/sys | xargs grep M_NOWAIT | wc -l 2101 Sounds like a lot of work that would need to happen atomically. Would this work: M_NO_WAIT       do not sleep, do not dig deep unless M_USE_RESERVE also set M_USE_RESERVE   dig deep M_NOWAIT        M_NO_WAIT | M_USE_RESERVE (deprecated) New code avoids using M_NOWAIT. Existing code continues working the same way. As time permits, old code is converted to new flags. Eventually M_NOWAIT goes away. Pro: the amount of code that needs to change atomically is much smaller. Con: (1) Have to remember (or look up) difference between M_NOWAIT and M_NO_WAIT. Maybe calling the new flag M_NO_SLEEP would help? (2) Would M_NOWAIT really ever go away? The spl() calls haven't, even after some cage rattling. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 02:02:38 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9D4EEF91; Mon, 12 Nov 2012 02:02:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 641108FC08; Mon, 12 Nov 2012 02:02:37 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so2605149dad.13 for ; Sun, 11 Nov 2012 18:02:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=UDXIH/xQjqib6FGZmZvCup0dN/GkLzBVvLAj1tU5dIk=; b=tcDpJ/ALGuUWwt+Q8P0HKwc9Xif0ioaOg38yNCp57Fc73JGEUA2PvrZwwBosDRgZPI ab0nmXsxQAOYWrL6tov2ZDxUXGGSCFj+h+1Gevudp+W5L/ss5xRazdM4rQjmNKCgFntC lwdBsg4zcoZCish5fdrOjZE0wx0bV2DteN+maOochoX7U2Be0YaB6GZUkID7hV7bvld+ EGD3kjJtyrYGlWSACogXDF0ra+0Myki8gf5BnCsdYZVIirWTRTyiwFRwsavqMa1CyAjR /V6ECUurcp7AnCxoQBZwPFyDUaX3+f+PhgdqSXEDqrZvSDZcLZTE+xSbXuwqpDNsQ9wn b+eQ== MIME-Version: 1.0 Received: by 10.68.247.134 with SMTP id ye6mr46861110pbc.69.1352685756831; Sun, 11 Nov 2012 18:02:36 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Sun, 11 Nov 2012 18:02:36 -0800 (PST) In-Reply-To: References: <20121110132019.GP73505@kib.kiev.ua> Date: Sun, 11 Nov 2012 18:02:36 -0800 X-Google-Sender-Auth: RRn8ERaobwyjxGBNFlVfOMvf7lY Message-ID: Subject: Re: Memory reserves or lack thereof From: Adrian Chadd To: alc@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" , "Sears, Steven" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 02:02:38 -0000 On 11 November 2012 13:40, Alan Cox wrote: > > Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was > well understand that it should only be used by interrupt handlers. > > The trouble is that M_NOWAIT conflates two orthogonal things. The obvious > being that the allocation shouldn't sleep. The other being how far we're > willing to deplete the cache/free page queues. > > When fine-grained locking got sprinkled throughout the kernel, we all to > often found ourselves wanting to do allocations without the possibility of > blocking. So, M_NOWAIT became commonplace, where it wasn't before. Well, what's the current set of best practices for allocating mbufs? I don't mind going through ath(4) and net80211(4), looking to make it behave better with mbuf allocations. There's 49 M_NOWAIT's in net80211 and 10 in ath(4). I wonder how many of them are synonyms with "don't fail allocating", too. Hm. Adrian From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 04:24:36 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9195A8FA for ; Mon, 12 Nov 2012 04:24:36 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 6F1788FC12 for ; Mon, 12 Nov 2012 04:24:36 +0000 (UTC) Received: from [10.245.102.125] (148.sub-174-253-233.myvzw.com [174.253.233.148]) by elvis.mu.org (Postfix) with ESMTPSA id D1ED11A3C54; Sun, 11 Nov 2012 20:24:34 -0800 (PST) References: <20121112003215.238950@gmx.com> In-Reply-To: <20121112003215.238950@gmx.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2CB113BD-D223-4BCF-AAB8-F3D3FA962168@mu.org> X-Mailer: iPhone Mail (9B206) From: Alfred Perlstein Subject: Re: Memory reserves or lack thereof Date: Sun, 11 Nov 2012 20:24:31 -0800 To: Dieter BSD Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 04:24:36 -0000 I think very few of the m_nowaits actually need the reserve behavior. We sho= uld probably switch away from it digging that deep by default and introduce a= flag and/or a per thread flag to set the behavior.=20 Sent from my iPhone On Nov 11, 2012, at 4:32 PM, "Dieter BSD" wrote: > Alan writes: >> In conclusion, I think it's time that we change M_NOWAIT so that it doesn= 't >> dig any deeper into the cache/free page queues than M_WAITOK does and >> reintroduce a M_USE_RESERVE-like flag that says dig deep into the >> cache/free page queues. The trouble is that we then need to identify all= >> of those places that are implicitly depending on the current behavior of >> M_NOWAIT also digging deep into the cache/free page queues so that we can= >> add an explicit M_USE_RESERVE. >=20 > find /usr/src/sys | xargs grep M_NOWAIT | wc -l > 2101 >=20 > Sounds like a lot of work that would need to happen atomically. > Would this work: >=20 > M_NO_WAIT do not sleep, do not dig deep unless M_USE_RESERVE also se= t > M_USE_RESERVE dig deep > M_NOWAIT M_NO_WAIT | M_USE_RESERVE (deprecated) >=20 > New code avoids using M_NOWAIT. Existing code continues working the same w= ay. > As time permits, old code is converted to new flags. Eventually M_NOWAIT > goes away. >=20 > Pro: the amount of code that needs to change atomically is much smaller. >=20 > Con: (1) Have to remember (or look up) difference between M_NOWAIT > and M_NO_WAIT. Maybe calling the new flag M_NO_SLEEP would help? > (2) Would M_NOWAIT really ever go away? The spl() calls haven't, > even after some cage rattling. > _______________________________________________ > 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 Mon Nov 12 09:40:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7176C7D9 for ; Mon, 12 Nov 2012 09:40:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3BA968FC12 for ; Mon, 12 Nov 2012 09:40:54 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so2765755dad.13 for ; Mon, 12 Nov 2012 01:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+SlT3zrrOfRFpe0GjVGC9sjsFrUdvBBmzxC1iddacQI=; b=SLa33iwi8inn+BBL7N5dFw8jLgOHNmzFIT/82skwqXnJn8MSWnd9FO1QnhjtIGH3Bc OglwTFZEjpM9MTbQNZA/PP/j9suzMNqKC+ECIIxKQlXFRHuikjuoYKj6UvpykDNbqhen O0/Q5ljjMhDjmOXMa1KPF5KlUClIzzD9b45WgLJ2FbM8g74PUbuj10BUuhgtfbVPrC0b Q5v0XL0arBDZYiRdMQoKO3s8tGzBmxRfnfpic2uuUD5UQ4ddnA+YlWyRY0iGjtisYRzp Y1wK1mIyen1Nl7nsUMNcLXN+mfnQvGdrD00ID54KJ6vbBt38olUNwFNAVBbbAhlZJzoI kJEw== MIME-Version: 1.0 Received: by 10.69.0.8 with SMTP id au8mr49338259pbd.58.1352713248832; Mon, 12 Nov 2012 01:40:48 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Mon, 12 Nov 2012 01:40:48 -0800 (PST) In-Reply-To: <2CB113BD-D223-4BCF-AAB8-F3D3FA962168@mu.org> References: <20121112003215.238950@gmx.com> <2CB113BD-D223-4BCF-AAB8-F3D3FA962168@mu.org> Date: Mon, 12 Nov 2012 01:40:48 -0800 X-Google-Sender-Auth: t999xq202iAsn76NVVJJH3_bVz4 Message-ID: Subject: Re: Memory reserves or lack thereof From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , Dieter BSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 09:40:54 -0000 On 11 November 2012 20:24, Alfred Perlstein wrote: > I think very few of the m_nowaits actually need the reserve behavior. We should probably switch away from it digging that deep by default and introduce a flag and/or a per thread flag to set the behavior. There's already a perfectly fine flag - M_WAITOK. Just don't hold any locks, right? :) Adrian From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 10:03:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 29BA4D36 for ; Mon, 12 Nov 2012 10:03:21 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9B4068FC15 for ; Mon, 12 Nov 2012 10:03:20 +0000 (UTC) Received: from irix.bris.ac.uk ([137.222.10.39] helo=ncs.bris.ac.uk) by dirg.bris.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1TXqr9-0003AL-Nb for freebsd-hackers@freebsd.org; Mon, 12 Nov 2012 10:03:13 +0000 Received: from mech-cluster241.men.bris.ac.uk ([137.222.187.241]) by ncs.bris.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1TXqr9-0004zd-ID for freebsd-hackers@freebsd.org; Mon, 12 Nov 2012 10:03:03 +0000 Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5) with ESMTP id qACA33kQ089268 for ; Mon, 12 Nov 2012 10:03:03 GMT (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.5/8.14.5/Submit) id qACA33du089267 for freebsd-hackers@freebsd.org; Mon, 12 Nov 2012 10:03:03 GMT (envelope-from mexas) Date: Mon, 12 Nov 2012 10:03:03 GMT From: Anton Shterenlikht Message-Id: <201211121003.qACA33du089267@mech-cluster241.men.bris.ac.uk> To: freebsd-hackers@freebsd.org Subject: help make sense of gdb backtrace X-Spam-Score: -3.6 X-Spam-Level: --- X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 10:03:21 -0000 I'm trying to debug firefox on ia64. It segfaults on startup. The output of "thread apply all bt" is at: http://seis.bris.ac.uk/~mexas/ff17.gdb.log or below. Thanks for any hints on where to dig next. Anton Core was generated by `firefox'. Program terminated with signal 11, Segmentation fault. #0 0x0000000120476a80 in thr_kill () from /lib/libc.so.7 [New Thread 1357a7800 (LWP 110621/Media Decode)] [New Thread 132b1f400 (LWP 110620/Media State)] [New Thread 132b1f800 (LWP 110619/firefox)] [New Thread 134fa0c00 (LWP 110618/mozStorage #4)] [New Thread 134f9a800 (LWP 110617/mozStorage #3)] [New Thread 133c4ec00 (LWP 110616/Cache Deleter)] [New Thread 1323cc400 (LWP 110615/URL Classifier)] [New Thread 1323cc800 (LWP 110614/Cache I/O)] [New Thread 1323ce000 (LWP 110613/mozStorage #2)] [New Thread 1323cec00 (LWP 107295/DNS Resolver #1)] [New Thread 132717c00 (LWP 110611/StreamTrans #2)] [New Thread 120803000 (LWP 110610/HTML5 Parser)] [New Thread 132754c00 (LWP 110609/mozStorage #1)] [New Thread 1304c6400 (LWP 110607/Cert Verify)] [New Thread 1304c2c00 (LWP 110606/Timer)] [New Thread 130190400 (LWP 110605/JS Watchdog)] [New Thread 1303ca800 (LWP 110604/firefox)] [New Thread 1303c9800 (LWP 109945/JS GC Helper)] [New Thread 1303c3800 (LWP 109944/Hang Monitor)] [New Thread 1303c5400 (LWP 109943/Socket Thread)] [New Thread 120810400 (LWP 108325/XPCOM CC)] [New Thread 120804000 (LWP 108320/Gecko_IOThread)] [New Thread 120802400 (LWP 109371/firefox)] Thread 23 (Thread 120802400 (LWP 109371/firefox)): #0 0x00000001291dfe21 in js::frontend::BytecodeEmitter::notes (this=0x7fffffffffffb360) at BytecodeEmitter.h:174 #1 0x00000001291fc830 in SetSrcNoteOffset (cx=0x132fe8200, bce=0x7fffffffffffb360, index=86, which=0, offset=25) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6838 #2 0x00000001291fd3c0 in js::frontend::NewSrcNote2 (cx=0x132fe8200, bce=0x7fffffffffffb360, type=js::SRC_PCBASE, offset=25) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6756 #3 0x0000000129235ea0 in EmitCallOrNew (cx=0x132fe8200, bce=0x7fffffffffffb360, pn=0x131683d58, top=229) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:5457 #4 0x0000000129210830 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffb360, pn=0x131683d58) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6484 #5 0x0000000129213a00 in EmitUnary (cx=0x132fe8200, bce=0x7fffffffffffb360, pn=0x131683848) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:5972 #6 0x00000001292100f0 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffb360, pn=0x131683848) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6420 #7 0x0000000129217c60 in EmitLogical (cx=0x132fe8200, bce=0x7fffffffffffb360, pn=0x131683d10) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:5528 #8 0x000000012920f550 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffb360, pn=0x131683d10) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6317 #9 0x000000012921b770 in EmitIf (cx=0x132fe8200, bce=0x7fffffffffffb360, pn=0x131683ec0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:4177 #10 0x000000012920e380 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffb360, pn=0x131683ec0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6173 #11 0x0000000129218320 in EmitStatementList (cx=0x132fe8200, bce=0x7fffffffffffb360, pn=0x131686218, top=0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:5189 #12 0x000000012920ee90 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffb360, pn=0x131686218) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6252 #13 0x000000012920e2c0 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffb360, pn=0x131685e78) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6168 #14 0x000000012921e910 in js::frontend::EmitFunctionScript (cx=0x132fe8200, bce=0x7fffffffffffb360, body=0x131685e78) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:2661 #15 0x000000012920b960 in EmitFunc (cx=0x132fe8200, bce=0x7fffffffffffbf30, pn=0x131685da0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:4905 #16 0x000000012920ce90 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffbf30, pn=0x131685da0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6068 #17 0x00000001292153c0 in EmitObject (cx=0x132fe8200, bce=0x7fffffffffffbf30, pn=0x1321032a8) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:5795 #18 0x0000000129210ca0 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffbf30, pn=0x1321032a8) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6527 #19 0x000000012922ac80 in EmitAssignment (cx=0x132fe8200, bce=0x7fffffffffffbf30, lhs=0x132103260, op=JSOP_NOP, rhs=0x1321032a8) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:3595 #20 0x000000012920f440 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffbf30, pn=0x132120490) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6307 #21 0x0000000129225490 in EmitStatement (cx=0x132fe8200, bce=0x7fffffffffffbf30, pn=0x1321204d8) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:5259 #22 0x000000012920ef60 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffbf30, pn=0x1321204d8) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6260 #23 0x0000000129218320 in EmitStatementList (cx=0x132fe8200, bce=0x7fffffffffffbf30, pn=0x13210f890, top=9) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:5189 #24 0x000000012920ee90 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffbf30, pn=0x13210f890) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6252 #25 0x000000012920e2c0 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffbf30, pn=0x13210e188) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6168 #26 0x000000012921e910 in js::frontend::EmitFunctionScript (cx=0x132fe8200, bce=0x7fffffffffffbf30, body=0x13210e188) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:2661 #27 0x000000012920b960 in EmitFunc (cx=0x132fe8200, bce=0x7fffffffffffc688, pn=0x13210f0b0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:4905 #28 0x000000012920ce90 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffc688, pn=0x13210f0b0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6068 #29 0x0000000129235d40 in EmitCallOrNew (cx=0x132fe8200, bce=0x7fffffffffffc688, pn=0x13210d2f8, top=332) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:5452 #30 0x0000000129210830 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffc688, pn=0x13210d2f8) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6484 #31 0x0000000129225490 in EmitStatement (cx=0x132fe8200, bce=0x7fffffffffffc688, pn=0x132120be0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:5259 #32 0x000000012920ef60 in js::frontend::EmitTree (cx=0x132fe8200, bce=0x7fffffffffffc688, pn=0x132120be0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeEmitter.cpp:6260 #33 0x00000001291ddf50 in js::frontend::CompileScript (cx=0x132fe8200, scopeChain= {> = {}, ptr = 0x7fffffffffffd0c8}, callerFrame=0x0, options=@0x7fffffffffffcfd0, chars=0x135e12008, length=166340, source_=0x0, staticLevel=0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/frontend/BytecodeCompiler.cpp:200 #34 0x0000000128a08d60 in JS::Evaluate (cx=0x132fe8200, obj= {> = {}, ptr = 0x7fffffffffffd0c8}, options= {principals = 0x134ef79e8, originPrincipals = 0x1323f1dd8, version = JSVERSION_DEFAULT, versionSet = true, utf8 = false, filename = 0x131298cf8 "http://a.l.yimg.com/pv/static/lib/syc_metro_201210020415.js", lineno = 1, compileAndGo = true, noScriptRval = true, selfHostingMode = false, sourcePolicy = JS::CompileOptions::SAVE_SOURCE}, chars=0x135e12008, length=166340, rval=0x0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/js/src/jsapi.cpp:5659 #35 0x000000012462e5b0 in nsJSContext::EvaluateString (this=0x1344ff100, aScript=@0x13128f428, aScopeObject=0x13119c020, aPrincipal=0x134ef79e0, aOriginPrincipal=0x1323f1dd0, aURL=0x131298cf8 "http://a.l.yimg.com/pv/static/lib/syc_metro_201210020415.js", aLineNo=1, aVersion=JSVERSION_DEFAULT, aRetValue=0x0, aIsUndefined=0x7fffffffffffd210) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/dom/base/nsJSEnvironment.cpp:1499 #36 0x00000001239ef310 in nsScriptLoader::EvaluateScript (this=0x134fd8780, aRequest=0x13128f400, aScript=@0x13128f428) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/content/base/src/nsScriptLoader.cpp:841 #37 0x00000001239efd90 in nsScriptLoader::ProcessRequest (this=0x134fd8780, aRequest=0x13128f400) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/content/base/src/nsScriptLoader.cpp:734 #38 0x00000001239f0820 in nsScriptLoader::ProcessPendingRequests (this=0x134fd8780) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/content/base/src/nsScriptLoader.cpp:890 #39 0x00000001239f1d10 in nsScriptLoader::OnStreamComplete (this=0x134fd8780, aLoader=0x1325ae200, aContext=0x13128f400, aStatus=0, aStringLen=166340, aString=0x135dc2000 "if(typeof YUI!=\"undefined\"){YUI._YUI=YUI}var YUI=function(){var c=0,f=this,b=arguments,a=b.length,e=function(h,g){return(h&&h.hasOwnProperty&&(h instanceof g))},d=(typeof YUI_config!==\"undefined\")&&YU"...) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/content/base/src/nsScriptLoader.cpp:1109 #40 0x000000012226a000 in nsStreamLoader::OnStopRequest (this=0x1325ae200, request=0x13140bc58, ctxt=0x13128f400, aStatus=0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/netwerk/base/src/nsStreamLoader.cpp:95 #41 0x00000001222f6340 in nsHTTPCompressConv::OnStopRequest (this=0x135130e80, request=0x13140bc58, aContext=0x13128f400, aStatus=0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/netwerk/streamconv/converters/nsHTTPCompressConv.cpp:94 #42 0x0000000122268070 in nsStreamListenerTee::OnStopRequest (this=0x134e026c0, request=0x13140bc58, context=0x13128f400, status=0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/netwerk/base/src/nsStreamListenerTee.cpp:49 #43 0x0000000122570140 in mozilla::net::nsHttpChannel::OnStopRequest (this=0x13140bc00, request=0x13437a580, ctxt=0x0, status=0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/netwerk/protocol/http/nsHttpChannel.cpp:4957 #44 0x000000012219c550 in nsInputStreamPump::OnStateStop (this=0x13437a580) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/netwerk/base/src/nsInputStreamPump.cpp:559 #45 0x000000012219c960 in nsInputStreamPump::OnInputStreamReady (this=0x13437a580, stream=0x135124b98) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/netwerk/base/src/nsInputStreamPump.cpp:374 #46 0x00000001279f67e0 in nsInputStreamReadyEvent::Run (this=0x134e02780) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/xpcom/io/nsStreamUtils.cpp:82 #47 0x0000000127a6ec80 in nsThread::ProcessNextEvent (this=0x120885520, mayWait=false, result=0x7fffffffffffd6a0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/xpcom/threads/nsThread.cpp:624 #48 0x00000001278e90e0 in NS_ProcessNextEvent_P (thread=0x120885520, mayWait=false) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/xpcom/build/nsThreadUtils.cpp:220 #49 0x0000000126fe8580 in mozilla::ipc::MessagePump::Run (this=0x1208136c0, aDelegate=0x1208f6180) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/ipc/glue/MessagePump.cpp:82 #50 0x0000000127bacf30 in MessageLoop::RunInternal (this=0x1208f6180) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/ipc/chromium/src/base/message_loop.cc:208 #51 0x0000000127bacf90 in MessageLoop::RunHandler (this=0x1208f6180) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/ipc/chromium/src/base/message_loop.cc:201 #52 0x0000000127bad120 in MessageLoop::Run (this=0x1208f6180) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/ipc/chromium/src/base/message_loop.cc:175 #53 0x0000000126b4bde0 in nsBaseAppShell::Run (this=0x12f7c9350) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/widget/xpwidgets/nsBaseAppShell.cpp:163 #54 0x000000012621d940 in nsAppStartup::Run (this=0x12f8beca0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/toolkit/components/startup/nsAppStartup.cpp:296 #55 0x00000001220da0c0 in XREMain::XRE_mainRun (this=0x7fffffffffffda88) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/toolkit/xre/nsAppRunner.cpp:3807 #56 0x00000001220df150 in XREMain::XRE_main (this=0x7fffffffffffda88, argc=1, argv=0x7fffffffffffe5e8, aAppData=0x100054aa8) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/toolkit/xre/nsAppRunner.cpp:3884 #57 0x00000001220df810 in XRE_main (argc=1, argv=0x7fffffffffffe5e8, aAppData=0x100054aa8, aFlags=0) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/toolkit/xre/nsAppRunner.cpp:3960 #58 0x0000000100004080 in do_main (argc=1, argv=0x7fffffffffffe5e8) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/browser/app/nsBrowserApp.cpp:174 #59 0x0000000100004700 in main (argc=1, argv=0x7fffffffffffe5e8) at /usr/ports/freebsd-gecko/www/firefox/work/mozilla-beta/browser/app/nsBrowserApp.cpp:280 Thread 22 (Thread 120804000 (LWP 108320/Gecko_IOThread)): #0 0x00000001205b8e00 in kevent () from /lib/libc.so.7 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 21 (Thread 120810400 (LWP 108325/XPCOM CC)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Current language: auto; currently asm Thread 20 (Thread 1303c5400 (LWP 109943/Socket Thread)): #0 0x000000012051efa0 in poll () from /lib/libc.so.7 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 19 (Thread 1303c3800 (LWP 109944/Hang Monitor)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 18 (Thread 1303c9800 (LWP 109945/JS GC Helper)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 17 (Thread 1303ca800 (LWP 110604/firefox)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 16 (Thread 130190400 (LWP 110605/JS Watchdog)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 15 (Thread 1304c2c00 (LWP 110606/Timer)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 14 (Thread 1304c6400 (LWP 110607/Cert Verify)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 13 (Thread 132754c00 (LWP 110609/mozStorage #1)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 12 (Thread 120803000 (LWP 110610/HTML5 Parser)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 11 (Thread 132717c00 (LWP 110611/StreamTrans #2)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 10 (Thread 1323cec00 (LWP 107295/DNS Resolver #1)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 9 (Thread 1323ce000 (LWP 110613/mozStorage #2)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 8 (Thread 1323cc800 (LWP 110614/Cache I/O)): #0 0x00000001204755c0 in posix_fallocate () from /lib/libc.so.7 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 7 (Thread 1323cc400 (LWP 110615/URL Classifier)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 6 (Thread 133c4ec00 (LWP 110616/Cache Deleter)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 5 (Thread 134f9a800 (LWP 110617/mozStorage #3)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 4 (Thread 134fa0c00 (LWP 110618/mozStorage #4)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 3 (Thread 132b1f800 (LWP 110619/firefox)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 2 (Thread 132b1f400 (LWP 110620/Media State)): #0 0x00000001203a63e0 in _umtx_op_err () at /usr/src/lib/libthr/arch/ia64/ia64/_umtx_op_err.S:33 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) Thread 1 (Thread 1357a7800 (LWP 110621/Media Decode)): #0 0x0000000120476a80 in thr_kill () from /lib/libc.so.7 #1 0x0000000000000000 in ?? () Previous frame identical to this frame (corrupt stack?) From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 12:10:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 747B51E6 for ; Mon, 12 Nov 2012 12:10:14 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id CEDD78FC15 for ; Mon, 12 Nov 2012 12:10:13 +0000 (UTC) Received: (qmail 96107 invoked from network); 12 Nov 2012 13:44:35 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2012 13:44:35 -0000 Message-ID: <50A0E77C.6010108@freebsd.org> Date: Mon, 12 Nov 2012 13:11:40 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: alc@freebsd.org Subject: Re: Memory reserves or lack thereof References: <20121110132019.GP73505@kib.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , "freebsd-hackers@freebsd.org" , Alan Cox , "Sears, Steven" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 12:10:14 -0000 On 11.11.2012 22:40, Alan Cox wrote: > On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov wrote: >> Your analysis is right, there is nothing to add or correct. >> This is the reason to strongly prefer M_WAITOK. >> > > Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was > well understand that it should only be used by interrupt handlers. > > The trouble is that M_NOWAIT conflates two orthogonal things. The obvious > being that the allocation shouldn't sleep. The other being how far we're > willing to deplete the cache/free page queues. > > When fine-grained locking got sprinkled throughout the kernel, we all to > often found ourselves wanting to do allocations without the possibility of > blocking. So, M_NOWAIT became commonplace, where it wasn't before. Yes, we have many places where we don't want to sleep for example in the network code. There we simply want to be told that we've run out of memory and handle the failure. It's expected to happen from time to time. We don't need or want to dig deep or into reserves. Packets are expected to get lost from time to time and upper layer protocols will handle retransmits just fine. What we *don't* want normally is to get blocked on a failing memory allocation. We'd rather drop this one and go on with the next packet to avoid the head of line blocking problem where everything cascades to a total halt. As a side note we don't do many, if any, true interrupt time allocations anymore. Usually the interrupt is just acknowledged in interrupt context and a taskqueue or ithread is scheduled to do all the hard work. Neither runs in interrupt context. > This had the unintended consequence of introducing a lot of memory > allocations in the top-half of the kernel, i.e., non-interrupt handling > code, that were digging deep into the cache/free page queues. > > Also, ironically, in today's kernel an "M_NOWAIT | M_USE_RESERVE" > allocation is less likely to succeed than an "M_NOWAIT" allocation. > However, prior to FreeBSD 7.x, M_NOWAIT couldn't allocate a cached page; it > could only allocate a free page. M_USE_RESERVE said that it ok to allocate > a cached page even though M_NOWAIT was specified. Consequently, the system > wouldn't dig as far into the free page queue if M_USE_RESERVE was > specified, because it was allowed to reclaim a cached page. > > In conclusion, I think it's time that we change M_NOWAIT so that it doesn't > dig any deeper into the cache/free page queues than M_WAITOK does and > reintroduce a M_USE_RESERVE-like flag that says dig deep into the > cache/free page queues. The trouble is that we then need to identify all > of those places that are implicitly depending on the current behavior of > M_NOWAIT also digging deep into the cache/free page queues so that we can > add an explicit M_USE_RESERVE. I don't think many places depend on M_NOWAIT digging deep. I'm perfectly happy with having M_NOWAIT give up on first try. Only together with M_TRY_REALLY_HARD it would dig into reserves. PS: We have a really nasty namespace collision with the mbuf flags which use the M_* prefix as well. -- Andre From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 12:16:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9C67D4E8 for ; Mon, 12 Nov 2012 12:16:43 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id F00008FC12 for ; Mon, 12 Nov 2012 12:16:42 +0000 (UTC) Received: (qmail 96184 invoked from network); 12 Nov 2012 13:51:05 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2012 13:51:05 -0000 Message-ID: <50A0E902.3080201@freebsd.org> Date: Mon, 12 Nov 2012 13:18:10 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Memory reserves or lack thereof References: <20121110132019.GP73505@kib.kiev.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, Konstantin Belousov , "Sears, Steven" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 12:16:43 -0000 On 12.11.2012 03:02, Adrian Chadd wrote: > On 11 November 2012 13:40, Alan Cox wrote: > >> >> Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was >> well understand that it should only be used by interrupt handlers. >> >> The trouble is that M_NOWAIT conflates two orthogonal things. The obvious >> being that the allocation shouldn't sleep. The other being how far we're >> willing to deplete the cache/free page queues. >> >> When fine-grained locking got sprinkled throughout the kernel, we all to >> often found ourselves wanting to do allocations without the possibility of >> blocking. So, M_NOWAIT became commonplace, where it wasn't before. > > Well, what's the current set of best practices for allocating mbufs? If an allocation is driven by user space then you can use M_WAITOK. If an allocation is driven by the driver or kernel (callout and so on) you do M_NOWAIT and handle a failure by trying again later either directly by rescheduling the callout or by the upper layer retransmit logic. On top of that individual mbuf allocation or stitching mbufs and clusters together manually is deprecated. If every possible you should use m_getm2(). > I don't mind going through ath(4) and net80211(4), looking to make it > behave better with mbuf allocations. There's 49 M_NOWAIT's in net80211 > and 10 in ath(4). I wonder how many of them are synonyms with "don't > fail allocating", too. Hm. Mbuf allocations are normally allowed to fail without serious after effects other than retransmits and some overall recovery pain. Only non-mbuf memory allocations for important structures or state that can't be recreated on retransmit should dig into reserves. Normally this is a very rare case in network related code. -- Andre From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 13:36:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 73A14232; Mon, 12 Nov 2012 13:36:54 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 908D88FC08; Mon, 12 Nov 2012 13:36:53 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qACDadMB007137; Mon, 12 Nov 2012 15:36:39 +0200 (EET) (envelope-from kostikbel@gmail.com) X-DKIM: OpenDKIM Filter v2.5.2 kib.kiev.ua qACDadMB007137 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qACDacqC007136; Mon, 12 Nov 2012 15:36:38 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Nov 2012 15:36:38 +0200 From: Konstantin Belousov To: alc@freebsd.org Subject: Re: Memory reserves or lack thereof Message-ID: <20121112133638.GZ73505@kib.kiev.ua> References: <20121110132019.GP73505@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Epw7rTp1fwvhE3T0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: pho@freebsd.org, "Sears, Steven" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 13:36:54 -0000 --Epw7rTp1fwvhE3T0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote: > On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov wrote: >=20 > > On Fri, Nov 09, 2012 at 07:10:04PM +0000, Sears, Steven wrote: > > > I have a memory subsystem design question that I'm hoping someone can > > answer. > > > > > > I've been looking at a machine that is completely out of memory, as in > > > > > > v_free_count =3D 0, > > > v_cache_count =3D 0, > > > > > > I wondered how a machine could completely run out of memory like this, > > especially after finding a lack of interrupt storms or other pathologies > > that would tend to overcommit memory. So I started investigating. > > > > > > Most allocators come down to vm_page_alloc(), which has this guard: > > > > > > if ((curproc =3D=3D pageproc) && (page_req !=3D VM_ALLOC_INTERR= UPT)) { > > > page_req =3D VM_ALLOC_SYSTEM; > > > }; > > > > > > if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved = || > > > (page_req =3D=3D VM_ALLOC_SYSTEM && > > > cnt.v_free_count + cnt.v_cache_count > > > cnt.v_interrupt_free_min) || > > > (page_req =3D=3D VM_ALLOC_INTERRUPT && > > > cnt.v_free_count + cnt.v_cache_count > 0)) { > > > > > > The key observation is if VM_ALLOC_INTERRUPT is set, it will allocate > > every last page. > > > > > > >From the name one might expect VM_ALLOC_INTERRUPT to be somewhat rar= e, > > perhaps only used from interrupt threads. Not so, see kmem_malloc() or > > uma_small_alloc() which both contain this mapping: > > > > > > if ((flags & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) > > > pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; > > > else > > > pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; > > > > > > Note that M_USE_RESERVE has been deprecated and is used in just a > > handful of places. Also note that lots of code paths come through these > > routines. > > > > > > What this means is essentially _any_ allocation using M_NOWAIT will > > bypass whatever reserves have been held back and will take every last p= age > > available. > > > > > > There is no documentation stating M_NOWAIT has this side effect of > > essentially being privileged, so any innocuous piece of code that can't > > block will use it. And of course M_NOWAIT is literally used all over. > > > > > > It looks to me like the design goal of the BSD allocators is on > > recovery; it will give all pages away knowing it can recover. > > > > > > Am I missing anything? I would have expected some small number of pag= es > > to be held in reserve just in case. And I didn't expect M_NOWAIT to be a > > sort of back door for grabbing memory. > > > > > > > Your analysis is right, there is nothing to add or correct. > > This is the reason to strongly prefer M_WAITOK. > > >=20 > Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was > well understand that it should only be used by interrupt handlers. >=20 > The trouble is that M_NOWAIT conflates two orthogonal things. The obvious > being that the allocation shouldn't sleep. The other being how far we're > willing to deplete the cache/free page queues. >=20 > When fine-grained locking got sprinkled throughout the kernel, we all to > often found ourselves wanting to do allocations without the possibility of > blocking. So, M_NOWAIT became commonplace, where it wasn't before. >=20 > This had the unintended consequence of introducing a lot of memory > allocations in the top-half of the kernel, i.e., non-interrupt handling > code, that were digging deep into the cache/free page queues. >=20 > Also, ironically, in today's kernel an "M_NOWAIT | M_USE_RESERVE" > allocation is less likely to succeed than an "M_NOWAIT" allocation. > However, prior to FreeBSD 7.x, M_NOWAIT couldn't allocate a cached page; = it > could only allocate a free page. M_USE_RESERVE said that it ok to alloca= te > a cached page even though M_NOWAIT was specified. Consequently, the syst= em > wouldn't dig as far into the free page queue if M_USE_RESERVE was > specified, because it was allowed to reclaim a cached page. >=20 > In conclusion, I think it's time that we change M_NOWAIT so that it doesn= 't > dig any deeper into the cache/free page queues than M_WAITOK does and > reintroduce a M_USE_RESERVE-like flag that says dig deep into the > cache/free page queues. The trouble is that we then need to identify all > of those places that are implicitly depending on the current behavior of > M_NOWAIT also digging deep into the cache/free page queues so that we can > add an explicit M_USE_RESERVE. >=20 > Alan >=20 > P.S. I suspect that we should also increase the size of the "page reserve" > that is kept for VM_ALLOC_INTERRUPT allocations in vm_page_alloc*(). How > many legitimate users of a new M_USE_RESERVE-like flag in today's kernel > could actually be satisfied by two pages? I am almost sure that most of people who put the M_NOWAIT flag, do not know the 'allow the deeper drain of free queue' effect. As such, I believe we should flip the meaning of M_NOWAIT/M_USE_RESERVE. My only expectations of the problematic places would be in the swapout path. I found a single explicit use of M_USE_RESERVE in the kernel, so the flip is relatively simple. Below is the patch which I only compile-tested on amd64, and which booted fine. Peter, could you, please, give it a run, to see obvious deadlocks, if any ? diff --git a/sys/amd64/amd64/uma_machdep.c b/sys/amd64/amd64/uma_machdep.c index dc9c307..ab1e869 100644 --- a/sys/amd64/amd64/uma_machdep.c +++ b/sys/amd64/amd64/uma_machdep.c @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$"); =20 #include #include +#include #include #include #include @@ -48,12 +49,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *fl= ags, int wait) int pflags; =20 *flags =3D UMA_SLAB_PRIV; - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_NOOBJ | VM_ALLOC_WIRED); for (;;) { m =3D vm_page_alloc(NULL, 0, pflags); if (m =3D=3D NULL) { diff --git a/sys/arm/arm/vm_machdep.c b/sys/arm/arm/vm_machdep.c index f60cdb1..75366e3 100644 --- a/sys/arm/arm/vm_machdep.c +++ b/sys/arm/arm/vm_machdep.c @@ -651,12 +651,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *= flags, int wait) ret =3D ((void *)kmem_malloc(kmem_map, bytes, M_NOWAIT)); return (ret); } - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_WIRED); for (;;) { m =3D vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); if (m =3D=3D NULL) { diff --git a/sys/fs/devfs/devfs_devs.c b/sys/fs/devfs/devfs_devs.c index 71caa29..2ce1ca6 100644 --- a/sys/fs/devfs/devfs_devs.c +++ b/sys/fs/devfs/devfs_devs.c @@ -121,7 +121,7 @@ devfs_alloc(int flags) struct cdev *cdev; struct timespec ts; =20 - cdp =3D malloc(sizeof *cdp, M_CDEVP, M_USE_RESERVE | M_ZERO | + cdp =3D malloc(sizeof *cdp, M_CDEVP, M_ZERO | ((flags & MAKEDEV_NOWAIT) ? M_NOWAIT : M_WAITOK)); if (cdp =3D=3D NULL) return (NULL); diff --git a/sys/ia64/ia64/uma_machdep.c b/sys/ia64/ia64/uma_machdep.c index 37353ff..9f77762 100644 --- a/sys/ia64/ia64/uma_machdep.c +++ b/sys/ia64/ia64/uma_machdep.c @@ -46,12 +46,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *fl= ags, int wait) int pflags; =20 *flags =3D UMA_SLAB_PRIV; - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_WIRED); =20 for (;;) { m =3D vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); diff --git a/sys/mips/mips/uma_machdep.c b/sys/mips/mips/uma_machdep.c index 798e632..24baef0 100644 --- a/sys/mips/mips/uma_machdep.c +++ b/sys/mips/mips/uma_machdep.c @@ -48,11 +48,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *fl= ags, int wait) void *va; =20 *flags =3D UMA_SLAB_PRIV; - - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT; - else - pflags =3D VM_ALLOC_SYSTEM; + pflags =3D m2vm_flags(wait, 0); =20 for (;;) { m =3D pmap_alloc_direct_page(0, pflags); diff --git a/sys/powerpc/aim/mmu_oea64.c b/sys/powerpc/aim/mmu_oea64.c index a491680..3e320b9 100644 --- a/sys/powerpc/aim/mmu_oea64.c +++ b/sys/powerpc/aim/mmu_oea64.c @@ -1369,12 +1369,7 @@ moea64_uma_page_alloc(uma_zone_t zone, int bytes, u_= int8_t *flags, int wait) *flags =3D UMA_SLAB_PRIV; needed_lock =3D !PMAP_LOCKED(kernel_pmap); =20 - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_WIRED); =20 for (;;) { m =3D vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); diff --git a/sys/powerpc/aim/slb.c b/sys/powerpc/aim/slb.c index 162c7fb..3882bfa 100644 --- a/sys/powerpc/aim/slb.c +++ b/sys/powerpc/aim/slb.c @@ -483,12 +483,7 @@ slb_uma_real_alloc(uma_zone_t zone, int bytes, u_int8_= t *flags, int wait) realmax =3D platform_real_maxaddr(); =20 *flags =3D UMA_SLAB_PRIV; - if ((wait & (M_NOWAIT | M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_NOOBJ | VM_ALLOC_WIRED); =20 for (;;) { m =3D vm_page_alloc_contig(NULL, 0, pflags, 1, 0, realmax, diff --git a/sys/powerpc/aim/uma_machdep.c b/sys/powerpc/aim/uma_machdep.c index 39deb43..23a333f 100644 --- a/sys/powerpc/aim/uma_machdep.c +++ b/sys/powerpc/aim/uma_machdep.c @@ -56,12 +56,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *fl= ags, int wait) int pflags; =09 *flags =3D UMA_SLAB_PRIV; - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_WIRED); =20 for (;;) { m =3D vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); diff --git a/sys/sparc64/sparc64/vm_machdep.c b/sys/sparc64/sparc64/vm_mach= dep.c index cdb94c7..573ab3a 100644 --- a/sys/sparc64/sparc64/vm_machdep.c +++ b/sys/sparc64/sparc64/vm_machdep.c @@ -501,14 +501,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *= flags, int wait) PMAP_STATS_INC(uma_nsmall_alloc); =20 *flags =3D UMA_SLAB_PRIV; - - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; - - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_WIRED); =20 for (;;) { m =3D vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); diff --git a/sys/vm/vm_kern.c b/sys/vm/vm_kern.c index 46e7f1c..e4c3704 100644 --- a/sys/vm/vm_kern.c +++ b/sys/vm/vm_kern.c @@ -222,12 +222,7 @@ kmem_alloc_attr(vm_map_t map, vm_size_t size, int flag= s, vm_paddr_t low, vm_object_reference(object); vm_map_insert(map, object, offset, addr, addr + size, VM_PROT_ALL, VM_PROT_ALL, 0); - if ((flags & (M_NOWAIT | M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_NOBUSY; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_NOBUSY; - if (flags & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(flags, VM_ALLOC_NOBUSY); VM_OBJECT_LOCK(object); end_offset =3D offset + size; for (; offset < end_offset; offset +=3D PAGE_SIZE) { @@ -296,14 +291,7 @@ kmem_alloc_contig(vm_map_t map, vm_size_t size, int fl= ags, vm_paddr_t low, vm_object_reference(object); vm_map_insert(map, object, offset, addr, addr + size, VM_PROT_ALL, VM_PROT_ALL, 0); - if ((flags & (M_NOWAIT | M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_NOBUSY; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_NOBUSY; - if (flags & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; - if (flags & M_NODUMP) - pflags |=3D VM_ALLOC_NODUMP; + pflags =3D m2vm_flags(flags, VM_ALLOC_NOBUSY); VM_OBJECT_LOCK(object); tries =3D 0; retry: @@ -487,11 +475,7 @@ kmem_back(vm_map_t map, vm_offset_t addr, vm_size_t si= ze, int flags) entry->wired_count =3D=3D 0 && (entry->eflags & MAP_ENTRY_IN_TRANSITI= ON) =3D=3D 0, ("kmem_back: entry not found or misaligned")); =20 - if ((flags & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; - + pflags =3D m2vm_flags(flags, VM_ALLOC_WIRED); if (flags & M_ZERO) pflags |=3D VM_ALLOC_ZERO; if (flags & M_NODUMP) diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h index 70b8416..0286a6d 100644 --- a/sys/vm/vm_page.h +++ b/sys/vm/vm_page.h @@ -344,6 +344,24 @@ extern struct mtx_padalign vm_page_queue_mtx; #define VM_ALLOC_COUNT_SHIFT 16 #define VM_ALLOC_COUNT(count) ((count) << VM_ALLOC_COUNT_SHIFT) =20 +#ifdef M_NOWAIT +static inline int +m2vm_flags(int malloc_flags, int alloc_flags) +{ + int pflags; + + if ((malloc_flags & (M_NOWAIT | M_USE_RESERVE)) =3D=3D M_NOWAIT) + pflags =3D VM_ALLOC_SYSTEM | alloc_flags; + else + pflags =3D VM_ALLOC_INTERRUPT | alloc_flags; + if (malloc_flags & M_ZERO) + pflags |=3D VM_ALLOC_ZERO; + if (malloc_flags & M_NODUMP) + pflags |=3D VM_ALLOC_NODUMP; + return (pflags); +} +#endif + void vm_page_busy(vm_page_t m); void vm_page_flash(vm_page_t m); void vm_page_io_start(vm_page_t m); --Epw7rTp1fwvhE3T0 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCg+2YACgkQC3+MBN1Mb4jquwCgzO2KOt+by4oQxAyMXj+Ly4yA oAQAoNRcAkSA2OIC9wAQ+5pvrIWQib1l =J4Rs -----END PGP SIGNATURE----- --Epw7rTp1fwvhE3T0-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 13:58:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3FCF65A8 for ; Mon, 12 Nov 2012 13:58:46 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by mx1.freebsd.org (Postfix) with SMTP id F06848FC12 for ; Mon, 12 Nov 2012 13:58:45 +0000 (UTC) Received: (qmail 23935 invoked from network); 12 Nov 2012 13:58:39 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay00.pair.com with SMTP; 12 Nov 2012 13:58:39 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id qACDwdQ3080086; Mon, 12 Nov 2012 14:58:39 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id qACDwduS080085; Mon, 12 Nov 2012 14:58:39 +0100 (CET) (envelope-from pho) Date: Mon, 12 Nov 2012 14:58:38 +0100 From: Peter Holm To: Konstantin Belousov Subject: Re: Memory reserves or lack thereof Message-ID: <20121112135838.GA80041@x2.osted.lan> References: <20121110132019.GP73505@kib.kiev.ua> <20121112133638.GZ73505@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20121112133638.GZ73505@kib.kiev.ua> User-Agent: Mutt/1.4.2.3i Cc: alc@freebsd.org, "freebsd-hackers@freebsd.org" , "Sears, Steven" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 13:58:46 -0000 On Mon, Nov 12, 2012 at 03:36:38PM +0200, Konstantin Belousov wrote: > On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote: > > On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov wrote: > > > > > On Fri, Nov 09, 2012 at 07:10:04PM +0000, Sears, Steven wrote: > > > > I have a memory subsystem design question that I'm hoping someone can > > > answer. > > > > > > > > I've been looking at a machine that is completely out of memory, as in > > > > > > > > v_free_count = 0, > > > > v_cache_count = 0, > > > > > > > > I wondered how a machine could completely run out of memory like this, > > > especially after finding a lack of interrupt storms or other pathologies > > > that would tend to overcommit memory. So I started investigating. > > > > > > > > Most allocators come down to vm_page_alloc(), which has this guard: > > > > > > > > if ((curproc == pageproc) && (page_req != VM_ALLOC_INTERRUPT)) { > > > > page_req = VM_ALLOC_SYSTEM; > > > > }; > > > > > > > > if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved || > > > > (page_req == VM_ALLOC_SYSTEM && > > > > cnt.v_free_count + cnt.v_cache_count > > > > cnt.v_interrupt_free_min) || > > > > (page_req == VM_ALLOC_INTERRUPT && > > > > cnt.v_free_count + cnt.v_cache_count > 0)) { > > > > > > > > The key observation is if VM_ALLOC_INTERRUPT is set, it will allocate > > > every last page. > > > > > > > > >From the name one might expect VM_ALLOC_INTERRUPT to be somewhat rare, > > > perhaps only used from interrupt threads. Not so, see kmem_malloc() or > > > uma_small_alloc() which both contain this mapping: > > > > > > > > if ((flags & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) > > > > pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; > > > > else > > > > pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; > > > > > > > > Note that M_USE_RESERVE has been deprecated and is used in just a > > > handful of places. Also note that lots of code paths come through these > > > routines. > > > > > > > > What this means is essentially _any_ allocation using M_NOWAIT will > > > bypass whatever reserves have been held back and will take every last page > > > available. > > > > > > > > There is no documentation stating M_NOWAIT has this side effect of > > > essentially being privileged, so any innocuous piece of code that can't > > > block will use it. And of course M_NOWAIT is literally used all over. > > > > > > > > It looks to me like the design goal of the BSD allocators is on > > > recovery; it will give all pages away knowing it can recover. > > > > > > > > Am I missing anything? I would have expected some small number of pages > > > to be held in reserve just in case. And I didn't expect M_NOWAIT to be a > > > sort of back door for grabbing memory. > > > > > > > > > > Your analysis is right, there is nothing to add or correct. > > > This is the reason to strongly prefer M_WAITOK. > > > > > > > Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was > > well understand that it should only be used by interrupt handlers. > > > > The trouble is that M_NOWAIT conflates two orthogonal things. The obvious > > being that the allocation shouldn't sleep. The other being how far we're > > willing to deplete the cache/free page queues. > > > > When fine-grained locking got sprinkled throughout the kernel, we all to > > often found ourselves wanting to do allocations without the possibility of > > blocking. So, M_NOWAIT became commonplace, where it wasn't before. > > > > This had the unintended consequence of introducing a lot of memory > > allocations in the top-half of the kernel, i.e., non-interrupt handling > > code, that were digging deep into the cache/free page queues. > > > > Also, ironically, in today's kernel an "M_NOWAIT | M_USE_RESERVE" > > allocation is less likely to succeed than an "M_NOWAIT" allocation. > > However, prior to FreeBSD 7.x, M_NOWAIT couldn't allocate a cached page; it > > could only allocate a free page. M_USE_RESERVE said that it ok to allocate > > a cached page even though M_NOWAIT was specified. Consequently, the system > > wouldn't dig as far into the free page queue if M_USE_RESERVE was > > specified, because it was allowed to reclaim a cached page. > > > > In conclusion, I think it's time that we change M_NOWAIT so that it doesn't > > dig any deeper into the cache/free page queues than M_WAITOK does and > > reintroduce a M_USE_RESERVE-like flag that says dig deep into the > > cache/free page queues. The trouble is that we then need to identify all > > of those places that are implicitly depending on the current behavior of > > M_NOWAIT also digging deep into the cache/free page queues so that we can > > add an explicit M_USE_RESERVE. > > > > Alan > > > > P.S. I suspect that we should also increase the size of the "page reserve" > > that is kept for VM_ALLOC_INTERRUPT allocations in vm_page_alloc*(). How > > many legitimate users of a new M_USE_RESERVE-like flag in today's kernel > > could actually be satisfied by two pages? > > I am almost sure that most of people who put the M_NOWAIT flag, do not > know the 'allow the deeper drain of free queue' effect. As such, I believe > we should flip the meaning of M_NOWAIT/M_USE_RESERVE. My only expectations > of the problematic places would be in the swapout path. > > I found a single explicit use of M_USE_RESERVE in the kernel, > so the flip is relatively simple. > > Below is the patch which I only compile-tested on amd64, and which booted > fine. > > Peter, could you, please, give it a run, to see obvious deadlocks, if any ? > Glad to. - Peter From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 14:47:56 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23AF5CB8; Mon, 12 Nov 2012 14:47:56 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 86EAB8FC18; Mon, 12 Nov 2012 14:47:54 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qACElrPn009623; Mon, 12 Nov 2012 07:47:53 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qACElnjg021331; Mon, 12 Nov 2012 07:47:49 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Memory reserves or lack thereof From: Ian Lepore To: Andre Oppermann In-Reply-To: <50A0E902.3080201@freebsd.org> References: <20121110132019.GP73505@kib.kiev.ua> <50A0E902.3080201@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Mon, 12 Nov 2012 07:47:49 -0700 Message-ID: <1352731669.1217.22.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, Konstantin Belousov , Adrian Chadd , "Sears, Steven" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 14:47:56 -0000 On Mon, 2012-11-12 at 13:18 +0100, Andre Oppermann wrote: > > Well, what's the current set of best practices for allocating mbufs? > > If an allocation is driven by user space then you can use M_WAITOK. > > If an allocation is driven by the driver or kernel (callout and so on) > you do M_NOWAIT and handle a failure by trying again later either > directly by rescheduling the callout or by the upper layer retransmit > logic. > > On top of that individual mbuf allocation or stitching mbufs and > clusters together manually is deprecated. If every possible you > should use m_getm2(). root@pico:/root # man m_getm2 No manual entry for m_getm2 So when you say manually stitching mbufs together is deprecated, I take you mean in the case where you're letting the mbuf routines allocate the actual buffer space for you? I've got an ethernet driver on an ARM SoC in which the hardware receives into a series of buffers fixed at 128 bytes. Right now the code is allocating a cluster and then looping using m_append() to reassemble these buffers back into a full contiguous frame in a cluster. I was going to have a shot at using MEXTADD() to manually string the series of hardware/dma buffers together without copying the data. Is that sort of usage still a good idea? (And would it actually be a performance win? If I hand it off to the net stack and an m_pullup() or similar is going to happen along the way anyway, I might as well do it at driver level.) -- Ian From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 15:23:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 609D7692 for ; Mon, 12 Nov 2012 15:23:47 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id B6D3A8FC1D for ; Mon, 12 Nov 2012 15:23:46 +0000 (UTC) Received: (qmail 2751 invoked from network); 12 Nov 2012 16:58:07 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Nov 2012 16:58:07 -0000 Message-ID: <50A1147E.2070807@freebsd.org> Date: Mon, 12 Nov 2012 16:23:42 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Memory reserves or lack thereof References: <20121110132019.GP73505@kib.kiev.ua> <50A0E902.3080201@freebsd.org> <1352731669.1217.22.camel@revolution.hippie.lan> In-Reply-To: <1352731669.1217.22.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, Konstantin Belousov , Adrian Chadd , "Sears, Steven" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 15:23:47 -0000 On 12.11.2012 15:47, Ian Lepore wrote: > On Mon, 2012-11-12 at 13:18 +0100, Andre Oppermann wrote: >>> Well, what's the current set of best practices for allocating mbufs? >> >> If an allocation is driven by user space then you can use M_WAITOK. >> >> If an allocation is driven by the driver or kernel (callout and so on) >> you do M_NOWAIT and handle a failure by trying again later either >> directly by rescheduling the callout or by the upper layer retransmit >> logic. >> >> On top of that individual mbuf allocation or stitching mbufs and >> clusters together manually is deprecated. If every possible you >> should use m_getm2(). > > root@pico:/root # man m_getm2 > No manual entry for m_getm2 Oops... Have to fix that. > So when you say manually stitching mbufs together is deprecated, I take > you mean in the case where you're letting the mbuf routines allocate the > actual buffer space for you? I mean allocating an mbuf, a cluster and then stitching them together. You can it in one with m_getcl(). > I've got an ethernet driver on an ARM SoC in which the hardware receives > into a series of buffers fixed at 128 bytes. Right now the code is > allocating a cluster and then looping using m_append() to reassemble > these buffers back into a full contiguous frame in a cluster. I was > going to have a shot at using MEXTADD() to manually string the series of > hardware/dma buffers together without copying the data. Is that sort of > usage still a good idea? (And would it actually be a performance win? That really depends on the particular usage. Attaching the 128 byte buffers to mbufs probably isn't much of a win considering an mbuf is 256 bytes in size. You could just as well copy each 128 buf into the data section. Allocating a 2K cluster and copying into it is more efficient on the overall system. > If I hand it off to the net stack and an m_pullup() or similar is going > to happen along the way anyway, I might as well do it at driver level.) If you properly m_align() the mbuf cluster before you copy into it there shouldn't be any m_pullup's happening. -- Andre From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 17:35:53 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 879CB28F; Mon, 12 Nov 2012 17:35:53 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh10.mail.rice.edu (mh10.mail.rice.edu [128.42.201.30]) by mx1.freebsd.org (Postfix) with ESMTP id 411998FC08; Mon, 12 Nov 2012 17:35:52 +0000 (UTC) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id BD4AD6047D; Mon, 12 Nov 2012 11:35:45 -0600 (CST) Received: from mh10.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh10.mail.rice.edu (Postfix) with ESMTP id BB584603DA; Mon, 12 Nov 2012 11:35:45 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh10.mail.rice.edu, auth channel Received: from mh10.mail.rice.edu ([127.0.0.1]) by mh10.mail.rice.edu (mh10.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id vjGfkXT2BfZ1; Mon, 12 Nov 2012 11:35:45 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh10.mail.rice.edu (Postfix) with ESMTPSA id 92AC4603DB; Mon, 12 Nov 2012 11:35:44 -0600 (CST) Message-ID: <50A1336E.5040401@rice.edu> Date: Mon, 12 Nov 2012 11:35:42 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Memory reserves or lack thereof References: <20121110132019.GP73505@kib.kiev.ua> <20121112133638.GZ73505@kib.kiev.ua> In-Reply-To: <20121112133638.GZ73505@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, pho@freebsd.org, "Sears, Steven" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 17:35:53 -0000 On 11/12/2012 07:36, Konstantin Belousov wrote: > On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote: >> On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov wrote: >> >>> On Fri, Nov 09, 2012 at 07:10:04PM +0000, Sears, Steven wrote: >>>> I have a memory subsystem design question that I'm hoping someone can >>> answer. >>>> I've been looking at a machine that is completely out of memory, as in >>>> >>>> v_free_count = 0, >>>> v_cache_count = 0, >>>> >>>> I wondered how a machine could completely run out of memory like this, >>> especially after finding a lack of interrupt storms or other pathologies >>> that would tend to overcommit memory. So I started investigating. >>>> Most allocators come down to vm_page_alloc(), which has this guard: >>>> >>>> if ((curproc == pageproc) && (page_req != VM_ALLOC_INTERRUPT)) { >>>> page_req = VM_ALLOC_SYSTEM; >>>> }; >>>> >>>> if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved || >>>> (page_req == VM_ALLOC_SYSTEM && >>>> cnt.v_free_count + cnt.v_cache_count > >>> cnt.v_interrupt_free_min) || >>>> (page_req == VM_ALLOC_INTERRUPT && >>>> cnt.v_free_count + cnt.v_cache_count > 0)) { >>>> >>>> The key observation is if VM_ALLOC_INTERRUPT is set, it will allocate >>> every last page. >>>> >From the name one might expect VM_ALLOC_INTERRUPT to be somewhat rare, >>> perhaps only used from interrupt threads. Not so, see kmem_malloc() or >>> uma_small_alloc() which both contain this mapping: >>>> if ((flags & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>>> pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >>>> else >>>> pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >>>> >>>> Note that M_USE_RESERVE has been deprecated and is used in just a >>> handful of places. Also note that lots of code paths come through these >>> routines. >>>> What this means is essentially _any_ allocation using M_NOWAIT will >>> bypass whatever reserves have been held back and will take every last page >>> available. >>>> There is no documentation stating M_NOWAIT has this side effect of >>> essentially being privileged, so any innocuous piece of code that can't >>> block will use it. And of course M_NOWAIT is literally used all over. >>>> It looks to me like the design goal of the BSD allocators is on >>> recovery; it will give all pages away knowing it can recover. >>>> Am I missing anything? I would have expected some small number of pages >>> to be held in reserve just in case. And I didn't expect M_NOWAIT to be a >>> sort of back door for grabbing memory. >>> Your analysis is right, there is nothing to add or correct. >>> This is the reason to strongly prefer M_WAITOK. >>> >> Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was >> well understand that it should only be used by interrupt handlers. >> >> The trouble is that M_NOWAIT conflates two orthogonal things. The obvious >> being that the allocation shouldn't sleep. The other being how far we're >> willing to deplete the cache/free page queues. >> >> When fine-grained locking got sprinkled throughout the kernel, we all to >> often found ourselves wanting to do allocations without the possibility of >> blocking. So, M_NOWAIT became commonplace, where it wasn't before. >> >> This had the unintended consequence of introducing a lot of memory >> allocations in the top-half of the kernel, i.e., non-interrupt handling >> code, that were digging deep into the cache/free page queues. >> >> Also, ironically, in today's kernel an "M_NOWAIT | M_USE_RESERVE" >> allocation is less likely to succeed than an "M_NOWAIT" allocation. >> However, prior to FreeBSD 7.x, M_NOWAIT couldn't allocate a cached page; it >> could only allocate a free page. M_USE_RESERVE said that it ok to allocate >> a cached page even though M_NOWAIT was specified. Consequently, the system >> wouldn't dig as far into the free page queue if M_USE_RESERVE was >> specified, because it was allowed to reclaim a cached page. >> >> In conclusion, I think it's time that we change M_NOWAIT so that it doesn't >> dig any deeper into the cache/free page queues than M_WAITOK does and >> reintroduce a M_USE_RESERVE-like flag that says dig deep into the >> cache/free page queues. The trouble is that we then need to identify all >> of those places that are implicitly depending on the current behavior of >> M_NOWAIT also digging deep into the cache/free page queues so that we can >> add an explicit M_USE_RESERVE. >> >> Alan >> >> P.S. I suspect that we should also increase the size of the "page reserve" >> that is kept for VM_ALLOC_INTERRUPT allocations in vm_page_alloc*(). How >> many legitimate users of a new M_USE_RESERVE-like flag in today's kernel >> could actually be satisfied by two pages? > I am almost sure that most of people who put the M_NOWAIT flag, do not > know the 'allow the deeper drain of free queue' effect. As such, I believe > we should flip the meaning of M_NOWAIT/M_USE_RESERVE. My only expectations > of the problematic places would be in the swapout path. > > I found a single explicit use of M_USE_RESERVE in the kernel, > so the flip is relatively simple. Agreed. Most recently I eliminated several uses from the arm pmap implementations. There is, however, one other use: ofed/include/linux/gfp.h:#define GFP_ATOMIC (M_NOWAIT | M_USE_RESERVE) > Below is the patch which I only compile-tested on amd64, and which booted > fine. > > Peter, could you, please, give it a run, to see obvious deadlocks, if any ? > > diff --git a/sys/amd64/amd64/uma_machdep.c b/sys/amd64/amd64/uma_machdep.c > index dc9c307..ab1e869 100644 > --- a/sys/amd64/amd64/uma_machdep.c > +++ b/sys/amd64/amd64/uma_machdep.c > @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$"); > > #include > #include > +#include > #include > #include > #include > @@ -48,12 +49,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) > int pflags; > > *flags = UMA_SLAB_PRIV; > - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; > - else > - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; > - if (wait & M_ZERO) > - pflags |= VM_ALLOC_ZERO; > + pflags = m2vm_flags(wait, VM_ALLOC_NOOBJ | VM_ALLOC_WIRED); > for (;;) { > m = vm_page_alloc(NULL, 0, pflags); > if (m == NULL) { > diff --git a/sys/arm/arm/vm_machdep.c b/sys/arm/arm/vm_machdep.c > index f60cdb1..75366e3 100644 > --- a/sys/arm/arm/vm_machdep.c > +++ b/sys/arm/arm/vm_machdep.c > @@ -651,12 +651,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) > ret = ((void *)kmem_malloc(kmem_map, bytes, M_NOWAIT)); > return (ret); > } > - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; > - else > - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; > - if (wait & M_ZERO) > - pflags |= VM_ALLOC_ZERO; > + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); > for (;;) { > m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); > if (m == NULL) { > diff --git a/sys/fs/devfs/devfs_devs.c b/sys/fs/devfs/devfs_devs.c > index 71caa29..2ce1ca6 100644 > --- a/sys/fs/devfs/devfs_devs.c > +++ b/sys/fs/devfs/devfs_devs.c > @@ -121,7 +121,7 @@ devfs_alloc(int flags) > struct cdev *cdev; > struct timespec ts; > > - cdp = malloc(sizeof *cdp, M_CDEVP, M_USE_RESERVE | M_ZERO | > + cdp = malloc(sizeof *cdp, M_CDEVP, M_ZERO | > ((flags & MAKEDEV_NOWAIT) ? M_NOWAIT : M_WAITOK)); > if (cdp == NULL) > return (NULL); > diff --git a/sys/ia64/ia64/uma_machdep.c b/sys/ia64/ia64/uma_machdep.c > index 37353ff..9f77762 100644 > --- a/sys/ia64/ia64/uma_machdep.c > +++ b/sys/ia64/ia64/uma_machdep.c > @@ -46,12 +46,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) > int pflags; > > *flags = UMA_SLAB_PRIV; > - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; > - else > - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; > - if (wait & M_ZERO) > - pflags |= VM_ALLOC_ZERO; > + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); > > for (;;) { > m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); > diff --git a/sys/mips/mips/uma_machdep.c b/sys/mips/mips/uma_machdep.c > index 798e632..24baef0 100644 > --- a/sys/mips/mips/uma_machdep.c > +++ b/sys/mips/mips/uma_machdep.c > @@ -48,11 +48,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) > void *va; > > *flags = UMA_SLAB_PRIV; > - > - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT; > - else > - pflags = VM_ALLOC_SYSTEM; > + pflags = m2vm_flags(wait, 0); > > for (;;) { > m = pmap_alloc_direct_page(0, pflags); This smells fishy, but not because of anything that you did. It appears that the mips uma_small_alloc() is unconditionally asking for a pre-zeroed page. I'll take a look at this later today. > diff --git a/sys/powerpc/aim/mmu_oea64.c b/sys/powerpc/aim/mmu_oea64.c > index a491680..3e320b9 100644 > --- a/sys/powerpc/aim/mmu_oea64.c > +++ b/sys/powerpc/aim/mmu_oea64.c > @@ -1369,12 +1369,7 @@ moea64_uma_page_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) > *flags = UMA_SLAB_PRIV; > needed_lock = !PMAP_LOCKED(kernel_pmap); > > - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; > - else > - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; > - if (wait & M_ZERO) > - pflags |= VM_ALLOC_ZERO; > + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); > > for (;;) { > m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); > diff --git a/sys/powerpc/aim/slb.c b/sys/powerpc/aim/slb.c > index 162c7fb..3882bfa 100644 > --- a/sys/powerpc/aim/slb.c > +++ b/sys/powerpc/aim/slb.c > @@ -483,12 +483,7 @@ slb_uma_real_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) > realmax = platform_real_maxaddr(); > > *flags = UMA_SLAB_PRIV; > - if ((wait & (M_NOWAIT | M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; > - else > - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; > - if (wait & M_ZERO) > - pflags |= VM_ALLOC_ZERO; > + pflags = m2vm_flags(wait, VM_ALLOC_NOOBJ | VM_ALLOC_WIRED); > > for (;;) { > m = vm_page_alloc_contig(NULL, 0, pflags, 1, 0, realmax, > diff --git a/sys/powerpc/aim/uma_machdep.c b/sys/powerpc/aim/uma_machdep.c > index 39deb43..23a333f 100644 > --- a/sys/powerpc/aim/uma_machdep.c > +++ b/sys/powerpc/aim/uma_machdep.c > @@ -56,12 +56,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) > int pflags; > > *flags = UMA_SLAB_PRIV; > - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; > - else > - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; > - if (wait & M_ZERO) > - pflags |= VM_ALLOC_ZERO; > + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); > > for (;;) { > m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); > diff --git a/sys/sparc64/sparc64/vm_machdep.c b/sys/sparc64/sparc64/vm_machdep.c > index cdb94c7..573ab3a 100644 > --- a/sys/sparc64/sparc64/vm_machdep.c > +++ b/sys/sparc64/sparc64/vm_machdep.c > @@ -501,14 +501,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) > PMAP_STATS_INC(uma_nsmall_alloc); > > *flags = UMA_SLAB_PRIV; > - > - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; > - else > - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; > - > - if (wait & M_ZERO) > - pflags |= VM_ALLOC_ZERO; > + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); > > for (;;) { > m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); > diff --git a/sys/vm/vm_kern.c b/sys/vm/vm_kern.c > index 46e7f1c..e4c3704 100644 > --- a/sys/vm/vm_kern.c > +++ b/sys/vm/vm_kern.c > @@ -222,12 +222,7 @@ kmem_alloc_attr(vm_map_t map, vm_size_t size, int flags, vm_paddr_t low, > vm_object_reference(object); > vm_map_insert(map, object, offset, addr, addr + size, VM_PROT_ALL, > VM_PROT_ALL, 0); > - if ((flags & (M_NOWAIT | M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_NOBUSY; > - else > - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_NOBUSY; > - if (flags & M_ZERO) > - pflags |= VM_ALLOC_ZERO; > + pflags = m2vm_flags(flags, VM_ALLOC_NOBUSY); > VM_OBJECT_LOCK(object); > end_offset = offset + size; > for (; offset < end_offset; offset += PAGE_SIZE) { > @@ -296,14 +291,7 @@ kmem_alloc_contig(vm_map_t map, vm_size_t size, int flags, vm_paddr_t low, > vm_object_reference(object); > vm_map_insert(map, object, offset, addr, addr + size, VM_PROT_ALL, > VM_PROT_ALL, 0); > - if ((flags & (M_NOWAIT | M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_NOBUSY; > - else > - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_NOBUSY; > - if (flags & M_ZERO) > - pflags |= VM_ALLOC_ZERO; > - if (flags & M_NODUMP) > - pflags |= VM_ALLOC_NODUMP; > + pflags = m2vm_flags(flags, VM_ALLOC_NOBUSY); > VM_OBJECT_LOCK(object); > tries = 0; > retry: > @@ -487,11 +475,7 @@ kmem_back(vm_map_t map, vm_offset_t addr, vm_size_t size, int flags) > entry->wired_count == 0 && (entry->eflags & MAP_ENTRY_IN_TRANSITION) > == 0, ("kmem_back: entry not found or misaligned")); > > - if ((flags & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; > - else > - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; > - > + pflags = m2vm_flags(flags, VM_ALLOC_WIRED); > if (flags & M_ZERO) > pflags |= VM_ALLOC_ZERO; > if (flags & M_NODUMP) The conversion of these flags is already handled by m2vm_flags(). You can eliminate these lines. > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > index 70b8416..0286a6d 100644 > --- a/sys/vm/vm_page.h > +++ b/sys/vm/vm_page.h > @@ -344,6 +344,24 @@ extern struct mtx_padalign vm_page_queue_mtx; > #define VM_ALLOC_COUNT_SHIFT 16 > #define VM_ALLOC_COUNT(count) ((count) << VM_ALLOC_COUNT_SHIFT) > > +#ifdef M_NOWAIT > +static inline int > +m2vm_flags(int malloc_flags, int alloc_flags) > +{ > + int pflags; > + > + if ((malloc_flags & (M_NOWAIT | M_USE_RESERVE)) == M_NOWAIT) > + pflags = VM_ALLOC_SYSTEM | alloc_flags; > + else > + pflags = VM_ALLOC_INTERRUPT | alloc_flags; This can be simplified to: if ((malloc_flags & M_USE_RESERVE) != 0) pflags = VM_ALLOC_INTERRUPT | alloc_flags; else pflags = VM_ALLOC_SYSTEM | alloc_flags; > + if (malloc_flags & M_ZERO) > + pflags |= VM_ALLOC_ZERO; > + if (malloc_flags & M_NODUMP) > + pflags |= VM_ALLOC_NODUMP; > + return (pflags); > +} > +#endif > + > void vm_page_busy(vm_page_t m); > void vm_page_flash(vm_page_t m); > void vm_page_io_start(vm_page_t m); From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 17:48:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6F03162D; Mon, 12 Nov 2012 17:48:02 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 48D298FC0C; Mon, 12 Nov 2012 17:48:02 +0000 (UTC) Received: from [10.0.1.17] (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id E2FEF1A3CEB; Mon, 12 Nov 2012 09:48:01 -0800 (PST) References: <20121110132019.GP73505@kib.kiev.ua> <50A0E77C.6010108@freebsd.org> In-Reply-To: <50A0E77C.6010108@freebsd.org> Mime-Version: 1.0 (1.0) Message-Id: <22625087-4579-44AA-9633-CA81FAF6E8E7@mu.org> X-Mailer: iPhone Mail (9B206) From: Alfred Perlstein Subject: Re: Memory reserves or lack thereof Date: Mon, 12 Nov 2012 09:47:59 -0800 To: Andre Oppermann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "alc@freebsd.org" , Konstantin Belousov , Alan Cox , "Sears, Steven" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 17:48:02 -0000 On Nov 12, 2012, at 4:11 AM, Andre Oppermann wrote: > > > I don't think many places depend on M_NOWAIT digging deep. I'm > perfectly happy with having M_NOWAIT give up on first try. Only > together with M_TRY_REALLY_HARD it would dig into reserves. > > PS: We have a really nasty namespace collision with the mbuf flags > which use the M_* prefix as well. Agreed. > From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 18:49:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7B87A6BA; Mon, 12 Nov 2012 18:49:52 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id DAE808FC08; Mon, 12 Nov 2012 18:49:51 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qACInkZF037131; Mon, 12 Nov 2012 20:49:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-DKIM: OpenDKIM Filter v2.5.2 kib.kiev.ua qACInkZF037131 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qACInjI8037130; Mon, 12 Nov 2012 20:49:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Nov 2012 20:49:45 +0200 From: Konstantin Belousov To: Alan Cox Subject: Re: Memory reserves or lack thereof Message-ID: <20121112184945.GE73505@kib.kiev.ua> References: <20121110132019.GP73505@kib.kiev.ua> <20121112133638.GZ73505@kib.kiev.ua> <50A1336E.5040401@rice.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Gdkky/UkxKPTIP6j" Content-Disposition: inline In-Reply-To: <50A1336E.5040401@rice.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: alc@freebsd.org, pho@freebsd.org, "Sears, Steven" , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 18:49:52 -0000 --Gdkky/UkxKPTIP6j Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 12, 2012 at 11:35:42AM -0600, Alan Cox wrote: > Agreed. Most recently I eliminated several uses from the arm pmap > implementations. There is, however, one other use: >=20 > ofed/include/linux/gfp.h:#define GFP_ATOMIC (M_NOWAIT | > M_USE_RESERVE) Yes, I forgot to mention this. I have no idea about semantic of GFP_ATOMIC compat flag. Below is the updated patch with two your notes applied. diff --git a/sys/amd64/amd64/uma_machdep.c b/sys/amd64/amd64/uma_machdep.c index dc9c307..ab1e869 100644 --- a/sys/amd64/amd64/uma_machdep.c +++ b/sys/amd64/amd64/uma_machdep.c @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$"); =20 #include #include +#include #include #include #include @@ -48,12 +49,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *fl= ags, int wait) int pflags; =20 *flags =3D UMA_SLAB_PRIV; - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_NOOBJ | VM_ALLOC_WIRED); for (;;) { m =3D vm_page_alloc(NULL, 0, pflags); if (m =3D=3D NULL) { diff --git a/sys/arm/arm/vm_machdep.c b/sys/arm/arm/vm_machdep.c index f60cdb1..75366e3 100644 --- a/sys/arm/arm/vm_machdep.c +++ b/sys/arm/arm/vm_machdep.c @@ -651,12 +651,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *= flags, int wait) ret =3D ((void *)kmem_malloc(kmem_map, bytes, M_NOWAIT)); return (ret); } - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_WIRED); for (;;) { m =3D vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); if (m =3D=3D NULL) { diff --git a/sys/fs/devfs/devfs_devs.c b/sys/fs/devfs/devfs_devs.c index 71caa29..2ce1ca6 100644 --- a/sys/fs/devfs/devfs_devs.c +++ b/sys/fs/devfs/devfs_devs.c @@ -121,7 +121,7 @@ devfs_alloc(int flags) struct cdev *cdev; struct timespec ts; =20 - cdp =3D malloc(sizeof *cdp, M_CDEVP, M_USE_RESERVE | M_ZERO | + cdp =3D malloc(sizeof *cdp, M_CDEVP, M_ZERO | ((flags & MAKEDEV_NOWAIT) ? M_NOWAIT : M_WAITOK)); if (cdp =3D=3D NULL) return (NULL); diff --git a/sys/ia64/ia64/uma_machdep.c b/sys/ia64/ia64/uma_machdep.c index 37353ff..9f77762 100644 --- a/sys/ia64/ia64/uma_machdep.c +++ b/sys/ia64/ia64/uma_machdep.c @@ -46,12 +46,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *fl= ags, int wait) int pflags; =20 *flags =3D UMA_SLAB_PRIV; - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_WIRED); =20 for (;;) { m =3D vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); diff --git a/sys/mips/mips/uma_machdep.c b/sys/mips/mips/uma_machdep.c index 798e632..24baef0 100644 --- a/sys/mips/mips/uma_machdep.c +++ b/sys/mips/mips/uma_machdep.c @@ -48,11 +48,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *fl= ags, int wait) void *va; =20 *flags =3D UMA_SLAB_PRIV; - - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT; - else - pflags =3D VM_ALLOC_SYSTEM; + pflags =3D m2vm_flags(wait, 0); =20 for (;;) { m =3D pmap_alloc_direct_page(0, pflags); diff --git a/sys/powerpc/aim/mmu_oea64.c b/sys/powerpc/aim/mmu_oea64.c index a491680..3e320b9 100644 --- a/sys/powerpc/aim/mmu_oea64.c +++ b/sys/powerpc/aim/mmu_oea64.c @@ -1369,12 +1369,7 @@ moea64_uma_page_alloc(uma_zone_t zone, int bytes, u_= int8_t *flags, int wait) *flags =3D UMA_SLAB_PRIV; needed_lock =3D !PMAP_LOCKED(kernel_pmap); =20 - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_WIRED); =20 for (;;) { m =3D vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); diff --git a/sys/powerpc/aim/slb.c b/sys/powerpc/aim/slb.c index 162c7fb..3882bfa 100644 --- a/sys/powerpc/aim/slb.c +++ b/sys/powerpc/aim/slb.c @@ -483,12 +483,7 @@ slb_uma_real_alloc(uma_zone_t zone, int bytes, u_int8_= t *flags, int wait) realmax =3D platform_real_maxaddr(); =20 *flags =3D UMA_SLAB_PRIV; - if ((wait & (M_NOWAIT | M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_NOOBJ | VM_ALLOC_WIRED); =20 for (;;) { m =3D vm_page_alloc_contig(NULL, 0, pflags, 1, 0, realmax, diff --git a/sys/powerpc/aim/uma_machdep.c b/sys/powerpc/aim/uma_machdep.c index 39deb43..23a333f 100644 --- a/sys/powerpc/aim/uma_machdep.c +++ b/sys/powerpc/aim/uma_machdep.c @@ -56,12 +56,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *fl= ags, int wait) int pflags; =09 *flags =3D UMA_SLAB_PRIV; - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_WIRED); =20 for (;;) { m =3D vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); diff --git a/sys/sparc64/sparc64/vm_machdep.c b/sys/sparc64/sparc64/vm_mach= dep.c index cdb94c7..573ab3a 100644 --- a/sys/sparc64/sparc64/vm_machdep.c +++ b/sys/sparc64/sparc64/vm_machdep.c @@ -501,14 +501,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *= flags, int wait) PMAP_STATS_INC(uma_nsmall_alloc); =20 *flags =3D UMA_SLAB_PRIV; - - if ((wait & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; - - if (wait & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(wait, VM_ALLOC_WIRED); =20 for (;;) { m =3D vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); diff --git a/sys/vm/vm_kern.c b/sys/vm/vm_kern.c index 46e7f1c..ad396f5 100644 --- a/sys/vm/vm_kern.c +++ b/sys/vm/vm_kern.c @@ -222,12 +222,7 @@ kmem_alloc_attr(vm_map_t map, vm_size_t size, int flag= s, vm_paddr_t low, vm_object_reference(object); vm_map_insert(map, object, offset, addr, addr + size, VM_PROT_ALL, VM_PROT_ALL, 0); - if ((flags & (M_NOWAIT | M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_NOBUSY; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_NOBUSY; - if (flags & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; + pflags =3D m2vm_flags(flags, VM_ALLOC_NOBUSY); VM_OBJECT_LOCK(object); end_offset =3D offset + size; for (; offset < end_offset; offset +=3D PAGE_SIZE) { @@ -296,14 +291,7 @@ kmem_alloc_contig(vm_map_t map, vm_size_t size, int fl= ags, vm_paddr_t low, vm_object_reference(object); vm_map_insert(map, object, offset, addr, addr + size, VM_PROT_ALL, VM_PROT_ALL, 0); - if ((flags & (M_NOWAIT | M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_NOBUSY; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_NOBUSY; - if (flags & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; - if (flags & M_NODUMP) - pflags |=3D VM_ALLOC_NODUMP; + pflags =3D m2vm_flags(flags, VM_ALLOC_NOBUSY); VM_OBJECT_LOCK(object); tries =3D 0; retry: @@ -487,15 +475,7 @@ kmem_back(vm_map_t map, vm_offset_t addr, vm_size_t si= ze, int flags) entry->wired_count =3D=3D 0 && (entry->eflags & MAP_ENTRY_IN_TRANSITI= ON) =3D=3D 0, ("kmem_back: entry not found or misaligned")); =20 - if ((flags & (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT) - pflags =3D VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; - else - pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; - - if (flags & M_ZERO) - pflags |=3D VM_ALLOC_ZERO; - if (flags & M_NODUMP) - pflags |=3D VM_ALLOC_NODUMP; + pflags =3D m2vm_flags(flags, VM_ALLOC_WIRED); =20 VM_OBJECT_LOCK(kmem_object); for (i =3D 0; i < size; i +=3D PAGE_SIZE) { diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h index 70b8416..ce23c51 100644 --- a/sys/vm/vm_page.h +++ b/sys/vm/vm_page.h @@ -344,6 +344,24 @@ extern struct mtx_padalign vm_page_queue_mtx; #define VM_ALLOC_COUNT_SHIFT 16 #define VM_ALLOC_COUNT(count) ((count) << VM_ALLOC_COUNT_SHIFT) =20 +#ifdef M_NOWAIT +static inline int +m2vm_flags(int malloc_flags, int alloc_flags) +{ + int pflags; + + if ((malloc_flags & M_USE_RESERVE) !=3D 0) + pflags =3D VM_ALLOC_INTERRUPT | alloc_flags; + else + pflags =3D VM_ALLOC_SYSTEM | alloc_flags; + if (malloc_flags & M_ZERO) + pflags |=3D VM_ALLOC_ZERO; + if (malloc_flags & M_NODUMP) + pflags |=3D VM_ALLOC_NODUMP; + return (pflags); +} +#endif + void vm_page_busy(vm_page_t m); void vm_page_flash(vm_page_t m); void vm_page_io_start(vm_page_t m); --Gdkky/UkxKPTIP6j Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlChRMkACgkQC3+MBN1Mb4jkDQCgtaeBjw0lhFY/urUbAZ8ymbb3 A0YAoPVimReG0ohpA1lWpP05t4QeKDXH =2UzS -----END PGP SIGNATURE----- --Gdkky/UkxKPTIP6j-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 21:28:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6ECC2B59 for ; Mon, 12 Nov 2012 21:28:10 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm15.bullet.mail.ac4.yahoo.com (nm15.bullet.mail.ac4.yahoo.com [98.139.52.212]) by mx1.freebsd.org (Postfix) with ESMTP id D2A078FC16 for ; Mon, 12 Nov 2012 21:28:09 +0000 (UTC) Received: from [98.139.52.197] by nm15.bullet.mail.ac4.yahoo.com with NNFMP; 12 Nov 2012 21:28:03 -0000 Received: from [66.94.237.125] by tm10.bullet.mail.ac4.yahoo.com with NNFMP; 12 Nov 2012 21:28:03 -0000 Received: from [127.0.0.1] by omp1030.access.mail.mud.yahoo.com with NNFMP; 12 Nov 2012 21:28:03 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 298519.99504.bm@omp1030.access.mail.mud.yahoo.com Received: (qmail 93633 invoked by uid 60001); 12 Nov 2012 21:28:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352755682; bh=XF9N9CavLNk6v8p6bUVHSlqA87vevDVADQV0xfI/pE4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=BrSQf+Z/H3JL6GEXBxwwocrQyrk6i5iEgaJXjBVv573MoPWgQ6Ieu0I/aWP9L9Eh0GH0hDFlyhZng3AU1BsBAWpK9pZ/S9iGb69OOv9UYnHvzB2jveF2dRfGa76JlrPN9PjDDBJe03qv6OFbZbPej5+KufAgftb75Tp+ZdDgTLE= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=h5qukJsRrXnTmaq35UhyStvWzaEwfcbcycJUUfwA3XyKYS8Qd3JfYG8dEsp31eoUL2JrsvJdVUQAkgGWecSMqrZ6MQRt6yJ+VmeSXYiW1UiHsrM+U9ZFd53lOx8TXhiQj5eC5wI8+iMQi0a5cbmVy1MN6fzDqNE9iMM873yql/k=; X-YMail-OSG: CFo9HJgVM1m3ECsTwvvG1GOIr.QGO0Q1NO7xJVelWPqrdk2 o3_Z3dDEjvPR9SCRyBhiBt3VDjeHiz_snykMeND0VDNMgrabxuRGZygop7OY bio4859VWO0JF.asIKj6102a6CO1aftITl9TZ.KFiSZwYl.oEw76WxZWez79 _.7byO8KZMKL1r2ykbYBZyFBHD0..a9HDQ89sHLq7JzIp47D.yKyf1t65Miz kOZGQ3nANA0zD7TY_TEpwLTBHV1JGEVOPyknXYrXPEwoW_cc07nbdwKOcmWp C2itZZcbkfYjri__UNfE0hoMh0d3K4srpGJdigte.48aCysKJhs9qEMR2eec i54zUw967nG0LdLZES8JLMLfOH8YoiHhlUblKmLyUCVHLVoLRvuINNo8NZwG YqrSw1vCWcYI1RtQpCBWOAqlGVRr1FLgv8gYMQTMTF71kb_AEGeQ89qIwvge MA.zlKW0ysurL.h2z3FKTf4C_KSpDUMFo0RhINBVWmv48bi.uHyhNn_opWMs Q.RKUCsJsVAxftw-- Received: from [209.119.38.67] by web181701.mail.ne1.yahoo.com via HTTP; Mon, 12 Nov 2012 13:28:02 PST X-Rocket-MIMEInfo: 001.001, VGhpcyBwYXRjaCBzdGlsbCBkb2Vzbid0IGFkZHJlc3MgdGhlIGlzc3VlIG9mIE1fTk9XQUlUIGNhbGxzIGRyaXZpbmcgdGhlIG1lbW9yeSB0aGUgYWxsIHRoZSB3YXkgZG93biB0byAyIHBhZ2VzLCByaWdodCA_IEl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZSBNX05PV0FJVCBqdXN0IGRvIG5vbi1zbGVlcCB2ZXJzaW9uIG9mIE1fV0FJVE9LIGFuZCBNX1VTRV9SRVNFUlZFIGZsYWcgdG8gZGlnIGRlZXAuIAoKU3VzaGFudGggCgotLS0gT24gTW9uLCAxMS8xMi8xMiwgS29uc3RhbnRpbiBCZWxvdXNvdiA8a29zdGkBMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1352755682.93266.YahooMailClassic@web181701.mail.ne1.yahoo.com> Date: Mon, 12 Nov 2012 13:28:02 -0800 (PST) From: Sushanth Rai Subject: Re: Memory reserves or lack thereof To: alc@freebsd.org, Konstantin Belousov In-Reply-To: <20121112133638.GZ73505@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: pho@freebsd.org, StevenSears , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:28:10 -0000 This patch still doesn't address the issue of M_NOWAIT calls driving the me= mory the all the way down to 2 pages, right ? It would be nice to have M_NO= WAIT just do non-sleep version of M_WAITOK and M_USE_RESERVE flag to dig de= ep. =0A=0ASushanth =0A=0A--- On Mon, 11/12/12, Konstantin Belousov wrote:=0A=0A> From: Konstantin Belousov = =0A> Subject: Re: Memory reserves or lack thereof=0A> To: alc@freebsd.org= =0A> Cc: pho@freebsd.org, "Sears, Steven" , "freeb= sd-hackers@freebsd.org" =0A> Date: Monday, Nov= ember 12, 2012, 5:36 AM=0A> On Sun, Nov 11, 2012 at 03:40:24PM=0A> -0600, A= lan Cox wrote:=0A> > On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov= =0A> wrote:=0A> > =0A> > > On Fri, Nov 09, 2012 at 07:= 10:04PM +0000, Sears,=0A> Steven wrote:=0A> > > > I have a memory subsystem= design question=0A> that I'm hoping someone can=0A> > > answer.=0A> > > >= =0A> > > > I've been looking at a machine that is=0A> completely out of mem= ory, as in=0A> > > >=0A> > > >=A0 v_free_count =3D 0,=0A> > > >=A0 v_cache_= count =3D 0,=0A> > > >=0A> > > > I wondered how a machine could completely = run=0A> out of memory like this,=0A> > > especially after finding a lack of= interrupt=0A> storms or other pathologies=0A> > > that would tend to overc= ommit memory. So I started=0A> investigating.=0A> > > >=0A> > > > Most allo= cators come down to vm_page_alloc(),=0A> which has this guard:=0A> > > >=0A= > > > >=A0 =A0 =A0=A0=A0if ((curproc=0A> =3D=3D pageproc) && (page_req !=3D= VM_ALLOC_INTERRUPT)) {=0A> > > >=A0 =A0 =A0 =A0 =A0 =A0=0A> =A0=A0=A0page_= req =3D VM_ALLOC_SYSTEM;=0A> > > >=A0 =A0 =A0=A0=A0};=0A> > > >=0A> > > >= =A0 =A0 =A0=A0=A0if=0A> (cnt.v_free_count + cnt.v_cache_count >=0A> cnt.v_f= ree_reserved ||=0A> > > >=A0 =A0 =A0 =A0=0A> =A0=A0=A0(page_req =3D=3D VM_A= LLOC_SYSTEM &&=0A> > > >=A0 =A0 =A0 =A0=0A> =A0=A0=A0cnt.v_free_count + cnt= .v_cache_count >=0A> > > cnt.v_interrupt_free_min) ||=0A> > > >=A0 =A0 =A0 = =A0=0A> =A0=A0=A0(page_req =3D=3D VM_ALLOC_INTERRUPT=0A> &&=0A> > > >=A0 = =A0 =A0 =A0=0A> =A0=A0=A0cnt.v_free_count + cnt.v_cache_count >=0A> 0)) {= =0A> > > >=0A> > > > The key observation is if VM_ALLOC_INTERRUPT=0A> is se= t, it will allocate=0A> > > every last page.=0A> > > >=0A> > > > >From the = name one might expect=0A> VM_ALLOC_INTERRUPT to be somewhat rare,=0A> > > p= erhaps only used from interrupt threads. Not so,=0A> see kmem_malloc() or= =0A> > > uma_small_alloc() which both contain this=0A> mapping:=0A> > > >= =0A> > > >=A0 =A0 =A0=A0=A0if ((flags=0A> & (M_NOWAIT|M_USE_RESERVE)) =3D= =3D M_NOWAIT)=0A> > > >=A0 =A0 =A0 =A0 =A0 =A0=0A> =A0=A0=A0pflags =3D VM_A= LLOC_INTERRUPT |=0A> VM_ALLOC_WIRED;=0A> > > >=A0 =A0 =A0=A0=A0else=0A> > >= >=A0 =A0 =A0 =A0 =A0 =A0=0A> =A0=A0=A0pflags =3D VM_ALLOC_SYSTEM |=0A> VM_= ALLOC_WIRED;=0A> > > >=0A> > > > Note that M_USE_RESERVE has been deprecate= d=0A> and is used in just a=0A> > > handful of places. Also note that lots = of code=0A> paths come through these=0A> > > routines.=0A> > > >=0A> > > > = What this means is essentially _any_=0A> allocation using M_NOWAIT will=0A>= > > bypass whatever reserves have been held back and=0A> will take every l= ast page=0A> > > available.=0A> > > >=0A> > > > There is no documentation s= tating M_NOWAIT=0A> has this side effect of=0A> > > essentially being privi= leged, so any innocuous=0A> piece of code that can't=0A> > > block will use= it. And of course M_NOWAIT is=0A> literally used all over.=0A> > > >=0A> >= > > It looks to me like the design goal of the=0A> BSD allocators is on=0A= > > > recovery; it will give all pages away knowing it=0A> can recover.=0A>= > > >=0A> > > > Am I missing anything? I would have expected=0A> some smal= l number of pages=0A> > > to be held in reserve just in case. And I didn't= =0A> expect M_NOWAIT to be a=0A> > > sort of back door for grabbing memory.= =0A> > > >=0A> > >=0A> > > Your analysis is right, there is nothing to add = or=0A> correct.=0A> > > This is the reason to strongly prefer M_WAITOK.=0A>= > >=0A> > =0A> > Agreed.=A0 Once upon time, before SMPng, M_NOWAIT=0A> was= rarely used.=A0 It was=0A> > well understand that it should only be used b= y=0A> interrupt handlers.=0A> > =0A> > The trouble is that M_NOWAIT conflat= es two orthogonal=0A> things.=A0 The obvious=0A> > being that the allocatio= n shouldn't sleep.=A0 The=0A> other being how far we're=0A> > willing to de= plete the cache/free page queues.=0A> > =0A> > When fine-grained locking go= t sprinkled throughout the=0A> kernel, we all to=0A> > often found ourselve= s wanting to do allocations without=0A> the possibility of=0A> > blocking.= =A0 So, M_NOWAIT became commonplace, where=0A> it wasn't before.=0A> > =0A>= > This had the unintended consequence of introducing a=0A> lot of memory= =0A> > allocations in the top-half of the kernel, i.e.,=0A> non-interrupt h= andling=0A> > code, that were digging deep into the cache/free page=0A> que= ues.=0A> > =0A> > Also, ironically, in today's kernel an "M_NOWAIT |=0A> M_= USE_RESERVE"=0A> > allocation is less likely to succeed than an "M_NOWAIT"= =0A> allocation.=0A> > However, prior to FreeBSD 7.x, M_NOWAIT couldn't=0A>= allocate a cached page; it=0A> > could only allocate a free page.=A0 M_USE= _RESERVE=0A> said that it ok to allocate=0A> > a cached page even though M_= NOWAIT was specified.=A0=0A> Consequently, the system=0A> > wouldn't dig as= far into the free page queue if=0A> M_USE_RESERVE was=0A> > specified, bec= ause it was allowed to reclaim a cached=0A> page.=0A> > =0A> > In conclusio= n, I think it's time that we change=0A> M_NOWAIT so that it doesn't=0A> > d= ig any deeper into the cache/free page queues than=0A> M_WAITOK does and=0A= > > reintroduce a M_USE_RESERVE-like flag that says dig=0A> deep into the= =0A> > cache/free page queues.=A0 The trouble is that we=0A> then need to i= dentify all=0A> > of those places that are implicitly depending on the=0A> = current behavior of=0A> > M_NOWAIT also digging deep into the cache/free pa= ge=0A> queues so that we can=0A> > add an explicit M_USE_RESERVE.=0A> > =0A= > > Alan=0A> > =0A> > P.S. I suspect that we should also increase the size = of=0A> the "page reserve"=0A> > that is kept for VM_ALLOC_INTERRUPT allocat= ions in=0A> vm_page_alloc*().=A0 How=0A> > many legitimate users of a new M= _USE_RESERVE-like flag=0A> in today's kernel=0A> > could actually be satisf= ied by two pages?=0A> =0A> I am almost sure that most of people who put the= M_NOWAIT=0A> flag, do not=0A> know the 'allow the deeper drain of free que= ue' effect. As=0A> such, I believe=0A> we should flip the meaning of M_NOWA= IT/M_USE_RESERVE. My=0A> only expectations=0A> of the problematic places wo= uld be in the swapout path.=0A> =0A> I found a single explicit use of M_USE= _RESERVE in the=0A> kernel,=0A> so the flip is relatively simple.=0A> =0A> = Below is the patch which I only compile-tested on amd64, and=0A> which boot= ed=0A> fine.=0A> =0A> Peter, could you, please, give it a run, to see obvio= us=0A> deadlocks, if any ?=0A> =0A> diff --git a/sys/amd64/amd64/uma_machde= p.c=0A> b/sys/amd64/amd64/uma_machdep.c=0A> index dc9c307..ab1e869 100644= =0A> --- a/sys/amd64/amd64/uma_machdep.c=0A> +++ b/sys/amd64/amd64/uma_mach= dep.c=0A> @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$");=0A> =0A> #include =0A> #include =0A> +#include =0A> #inc= lude =0A> #include =0A> #include =0A> = @@ -48,12 +49,7 @@ uma_small_alloc(uma_zone_t zone, int=0A> bytes, u_int8_t= *flags, int wait)=0A> =A0=A0=A0 int pflags;=0A> =0A> =A0=A0=A0 *flags = =3D UMA_SLAB_PRIV;=0A> -=A0=A0=A0 if ((wait &=0A> (M_NOWAIT|M_USE_RESERVE))= =3D=3D M_NOWAIT)=0A> -=A0=A0=A0 =A0=A0=A0 pflags =3D=0A> VM_ALLOC_INTERRUP= T | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED;=0A> -=A0=A0=A0 else=0A> -=A0=A0=A0 =A0= =A0=A0 pflags =3D=0A> VM_ALLOC_SYSTEM | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED;=0A= > -=A0=A0=A0 if (wait & M_ZERO)=0A> -=A0=A0=A0 =A0=A0=A0 pflags |=3D=0A> VM= _ALLOC_ZERO;=0A> +=A0=A0=A0 pflags =3D m2vm_flags(wait, VM_ALLOC_NOOBJ=0A> = | VM_ALLOC_WIRED);=0A> =A0=A0=A0 for (;;) {=0A> =A0=A0=A0 =A0=A0=A0 m =3D= =0A> vm_page_alloc(NULL, 0, pflags);=0A> =A0=A0=A0 =A0=A0=A0 if (m =3D=3D = NULL) {=0A> diff --git a/sys/arm/arm/vm_machdep.c=0A> b/sys/arm/arm/vm_mach= dep.c=0A> index f60cdb1..75366e3 100644=0A> --- a/sys/arm/arm/vm_machdep.c= =0A> +++ b/sys/arm/arm/vm_machdep.c=0A> @@ -651,12 +651,7 @@ uma_small_allo= c(uma_zone_t zone, int=0A> bytes, u_int8_t *flags, int wait)=0A> =A0=A0=A0= =A0=A0=A0 =A0=A0=A0=0A> ret =3D ((void *)kmem_malloc(kmem_map, bytes, M_NO= WAIT));=0A> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0=0A> return (ret);=0A> =A0=A0=A0= =A0=A0=A0 }=0A> -=A0=A0=A0 =A0=A0=A0 if ((wait &=0A> (M_NOWAIT|M_USE_RESER= VE)) =3D=3D M_NOWAIT)=0A> -=A0=A0=A0 =A0=A0=A0 =A0=A0=A0=0A> pflags =3D VM_= ALLOC_INTERRUPT | VM_ALLOC_WIRED;=0A> -=A0=A0=A0 =A0=A0=A0 else=0A> -=A0=A0= =A0 =A0=A0=A0 =A0=A0=A0=0A> pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED;=0A= > -=A0=A0=A0 =A0=A0=A0 if (wait &=0A> M_ZERO)=0A> -=A0=A0=A0 =A0=A0=A0 =A0= =A0=A0=0A> pflags |=3D VM_ALLOC_ZERO;=0A> +=A0=A0=A0 =A0=A0=A0 pflags =3D= =0A> m2vm_flags(wait, VM_ALLOC_WIRED);=0A> =A0=A0=A0 =A0=A0=A0 for (;;) {= =0A> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 m=0A> =3D vm_page_alloc(NULL, 0, pflags= | VM_ALLOC_NOOBJ);=0A> =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 if=0A> (m =3D=3D NUL= L) {=0A> diff --git a/sys/fs/devfs/devfs_devs.c=0A> b/sys/fs/devfs/devfs_de= vs.c=0A> index 71caa29..2ce1ca6 100644=0A> --- a/sys/fs/devfs/devfs_devs.c= =0A> +++ b/sys/fs/devfs/devfs_devs.c=0A> @@ -121,7 +121,7 @@ devfs_alloc(in= t flags)=0A> =A0=A0=A0 struct cdev *cdev;=0A> =A0=A0=A0 struct timespec t= s;=0A> =0A> -=A0=A0=A0 cdp =3D malloc(sizeof *cdp, M_CDEVP,=0A> M_USE_RESE= RVE | M_ZERO |=0A> +=A0=A0=A0 cdp =3D malloc(sizeof *cdp, M_CDEVP,=0A> M_ZE= RO |=0A> =A0=A0=A0 =A0 =A0 ((flags &=0A> MAKEDEV_NOWAIT) ? M_NOWAIT : M_WA= ITOK));=0A> =A0=A0=A0 if (cdp =3D=3D NULL)=0A> =A0=A0=A0 =A0=A0=A0 return= (NULL);=0A> diff --git a/sys/ia64/ia64/uma_machdep.c=0A> b/sys/ia64/ia64/u= ma_machdep.c=0A> index 37353ff..9f77762 100644=0A> --- a/sys/ia64/ia64/uma_= machdep.c=0A> +++ b/sys/ia64/ia64/uma_machdep.c=0A> @@ -46,12 +46,7 @@ uma_= small_alloc(uma_zone_t zone, int=0A> bytes, u_int8_t *flags, int wait)=0A> = =A0=A0=A0 int pflags;=0A> =0A> =A0=A0=A0 *flags =3D UMA_SLAB_PRIV;=0A> -= =A0=A0=A0 if ((wait &=0A> (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT)=0A> -= =A0=A0=A0 =A0=A0=A0 pflags =3D=0A> VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED;=0A>= -=A0=A0=A0 else=0A> -=A0=A0=A0 =A0=A0=A0 pflags =3D=0A> VM_ALLOC_SYSTEM | = VM_ALLOC_WIRED;=0A> -=A0=A0=A0 if (wait & M_ZERO)=0A> -=A0=A0=A0 =A0=A0=A0 = pflags |=3D=0A> VM_ALLOC_ZERO;=0A> +=A0=A0=A0 pflags =3D m2vm_flags(wait,= =0A> VM_ALLOC_WIRED);=0A> =0A> =A0=A0=A0 for (;;) {=0A> =A0=A0=A0 =A0=A0= =A0 m =3D=0A> vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ);=0A> diff --g= it a/sys/mips/mips/uma_machdep.c=0A> b/sys/mips/mips/uma_machdep.c=0A> inde= x 798e632..24baef0 100644=0A> --- a/sys/mips/mips/uma_machdep.c=0A> +++ b/s= ys/mips/mips/uma_machdep.c=0A> @@ -48,11 +48,7 @@ uma_small_alloc(uma_zone_= t zone, int=0A> bytes, u_int8_t *flags, int wait)=0A> =A0=A0=A0 void *va;= =0A> =0A> =A0=A0=A0 *flags =3D UMA_SLAB_PRIV;=0A> -=0A> -=A0=A0=A0 if ((w= ait &=0A> (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT)=0A> -=A0=A0=A0 =A0=A0= =A0 pflags =3D=0A> VM_ALLOC_INTERRUPT;=0A> -=A0=A0=A0 else=0A> -=A0=A0=A0 = =A0=A0=A0 pflags =3D=0A> VM_ALLOC_SYSTEM;=0A> +=A0=A0=A0 pflags =3D m2vm_fl= ags(wait, 0);=0A> =0A> =A0=A0=A0 for (;;) {=0A> =A0=A0=A0 =A0=A0=A0 m = =3D=0A> pmap_alloc_direct_page(0, pflags);=0A> diff --git a/sys/powerpc/aim= /mmu_oea64.c=0A> b/sys/powerpc/aim/mmu_oea64.c=0A> index a491680..3e320b9 1= 00644=0A> --- a/sys/powerpc/aim/mmu_oea64.c=0A> +++ b/sys/powerpc/aim/mmu_o= ea64.c=0A> @@ -1369,12 +1369,7 @@ moea64_uma_page_alloc(uma_zone_t=0A> zone= , int bytes, u_int8_t *flags, int wait)=0A> =A0=A0=A0 *flags =3D UMA_SLAB_= PRIV;=0A> =A0=A0=A0 needed_lock =3D=0A> !PMAP_LOCKED(kernel_pmap);=0A> = =0A> -=A0 =A0 =A0 =A0 if ((wait &=0A> (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NO= WAIT)=0A> -=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> pflags =3D VM_ALLOC_INTERRUP= T | VM_ALLOC_WIRED;=0A> -=A0 =A0 =A0 =A0 else=0A> -=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0=0A> pflags =3D VM_ALLOC_SYSTEM | VM_ALLOC_WIRED;=0A> -=A0 =A0 =A0 = =A0 if (wait & M_ZERO)=0A> -=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=0A> pflags |=3D= VM_ALLOC_ZERO;=0A> +=A0=A0=A0 pflags =3D m2vm_flags(wait,=0A> VM_ALLOC_WIR= ED);=0A> =0A> =A0 =A0 =A0 =A0=A0=A0for (;;) {=0A> =A0 =A0 =A0 =A0 =A0 =A0 = =A0=0A> =A0=A0=A0m =3D vm_page_alloc(NULL, 0, pflags |=0A> VM_ALLOC_NOOBJ);= =0A> diff --git a/sys/powerpc/aim/slb.c b/sys/powerpc/aim/slb.c=0A> index 1= 62c7fb..3882bfa 100644=0A> --- a/sys/powerpc/aim/slb.c=0A> +++ b/sys/powerp= c/aim/slb.c=0A> @@ -483,12 +483,7 @@ slb_uma_real_alloc(uma_zone_t zone, in= t=0A> bytes, u_int8_t *flags, int wait)=0A> =A0=A0=A0 =A0=A0=A0 realmax = =3D=0A> platform_real_maxaddr();=0A> =0A> =A0=A0=A0 *flags =3D UMA_SLAB_P= RIV;=0A> -=A0=A0=A0 if ((wait & (M_NOWAIT |=0A> M_USE_RESERVE)) =3D=3D M_NO= WAIT)=0A> -=A0=A0=A0 =A0=A0=A0 pflags =3D=0A> VM_ALLOC_INTERRUPT | VM_ALLOC= _NOOBJ | VM_ALLOC_WIRED;=0A> -=A0=A0=A0 else=0A> -=A0=A0=A0 =A0=A0=A0 pflag= s =3D=0A> VM_ALLOC_SYSTEM | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED;=0A> -=A0=A0=A0= if (wait & M_ZERO)=0A> -=A0=A0=A0 =A0=A0=A0 pflags |=3D=0A> VM_ALLOC_ZERO;= =0A> +=A0=A0=A0 pflags =3D m2vm_flags(wait, VM_ALLOC_NOOBJ=0A> | VM_ALLOC_W= IRED);=0A> =0A> =A0=A0=A0 for (;;) {=0A> =A0=A0=A0 =A0=A0=A0 m =3D=0A> v= m_page_alloc_contig(NULL, 0, pflags, 1, 0, realmax,=0A> diff --git a/sys/po= werpc/aim/uma_machdep.c=0A> b/sys/powerpc/aim/uma_machdep.c=0A> index 39deb= 43..23a333f 100644=0A> --- a/sys/powerpc/aim/uma_machdep.c=0A> +++ b/sys/po= werpc/aim/uma_machdep.c=0A> @@ -56,12 +56,7 @@ uma_small_alloc(uma_zone_t z= one, int=0A> bytes, u_int8_t *flags, int wait)=0A> =A0=A0=A0 int pflags;= =0A> =A0=A0=A0 =0A> =A0=A0=A0 *flags =3D UMA_SLAB_PRIV;=0A> -=A0=A0=A0 if= ((wait &=0A> (M_NOWAIT|M_USE_RESERVE)) =3D=3D M_NOWAIT)=0A> -=A0=A0=A0 =A0= =A0=A0 pflags =3D=0A> VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED;=0A> -=A0=A0=A0 e= lse=0A> -=A0=A0=A0 =A0=A0=A0 pflags =3D=0A> VM_ALLOC_SYSTEM | VM_ALLOC_WIRE= D;=0A> -=A0=A0=A0 if (wait & M_ZERO)=0A> -=A0=A0=A0 =A0=A0=A0 pflags |=3D= =0A> VM_ALLOC_ZERO;=0A> +=A0=A0=A0 pflags =3D m2vm_flags(wait,=0A> VM_ALLOC= _WIRED);=0A> =0A> =A0=A0=A0 for (;;) {=0A> =A0=A0=A0 =A0=A0=A0 m =3D=0A>= vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ);=0A> diff --git a/sys/spar= c64/sparc64/vm_machdep.c=0A> b/sys/sparc64/sparc64/vm_machdep.c=0A> index c= db94c7..573ab3a 100644=0A> --- a/sys/sparc64/sparc64/vm_machdep.c=0A> +++ b= /sys/sparc64/sparc64/vm_machdep.c=0A> @@ -501,14 +501,7 @@ uma_small_alloc(= uma_zone_t zone, int=0A> bytes, u_int8_t *flags, int wait)=0A> =A0=A0=A0 P= MAP_STATS_INC(uma_nsmall_alloc);=0A> =0A> =A0=A0=A0 *flags =3D UMA_SLAB_P= RIV;=0A> -=0A> -=A0=A0=A0 if ((wait &=0A> (M_NOWAIT|M_USE_RESERVE)) =3D=3D = M_NOWAIT)=0A> -=A0=A0=A0 =A0=A0=A0 pflags =3D=0A> VM_ALLOC_INTERRUPT | VM_A= LLOC_WIRED;=0A> -=A0=A0=A0 else=0A> -=A0=A0=A0 =A0=A0=A0 pflags =3D=0A> VM_= ALLOC_SYSTEM | VM_ALLOC_WIRED;=0A> -=0A> -=A0=A0=A0 if (wait & M_ZERO)=0A> = -=A0=A0=A0 =A0=A0=A0 pflags |=3D=0A> VM_ALLOC_ZERO;=0A> +=A0=A0=A0 pflags = =3D m2vm_flags(wait,=0A> VM_ALLOC_WIRED);=0A> =0A> =A0=A0=A0 for (;;) {= =0A> =A0=A0=A0 =A0=A0=A0 m =3D=0A> vm_page_alloc(NULL, 0, pflags | VM_ALLO= C_NOOBJ);=0A> diff --git a/sys/vm/vm_kern.c b/sys/vm/vm_kern.c=0A> index 46= e7f1c..e4c3704 100644=0A> --- a/sys/vm/vm_kern.c=0A> +++ b/sys/vm/vm_kern.c= =0A> @@ -222,12 +222,7 @@ kmem_alloc_attr(vm_map_t map, vm_size_t=0A> size,= int flags, vm_paddr_t low,=0A> =A0=A0=A0 vm_object_reference(object);=0A>= =A0=A0=A0 vm_map_insert(map, object, offset, addr,=0A> addr + size, VM_PR= OT_ALL,=0A> =A0=A0=A0 =A0 =A0 VM_PROT_ALL, 0);=0A> -=A0=A0=A0 if ((flags &= (M_NOWAIT |=0A> M_USE_RESERVE)) =3D=3D M_NOWAIT)=0A> -=A0=A0=A0 =A0=A0=A0 = pflags =3D=0A> VM_ALLOC_INTERRUPT | VM_ALLOC_NOBUSY;=0A> -=A0=A0=A0 else=0A= > -=A0=A0=A0 =A0=A0=A0 pflags =3D=0A> VM_ALLOC_SYSTEM | VM_ALLOC_NOBUSY;=0A= > -=A0=A0=A0 if (flags & M_ZERO)=0A> -=A0=A0=A0 =A0=A0=A0 pflags |=3D=0A> V= M_ALLOC_ZERO;=0A> +=A0=A0=A0 pflags =3D m2vm_flags(flags,=0A> VM_ALLOC_NOBU= SY);=0A> =A0=A0=A0 VM_OBJECT_LOCK(object);=0A> =A0=A0=A0 end_offset =3D o= ffset + size;=0A> =A0=A0=A0 for (; offset < end_offset; offset +=3D=0A> PA= GE_SIZE) {=0A> @@ -296,14 +291,7 @@ kmem_alloc_contig(vm_map_t map,=0A> vm_= size_t size, int flags, vm_paddr_t low,=0A> =A0=A0=A0 vm_object_reference(= object);=0A> =A0=A0=A0 vm_map_insert(map, object, offset, addr,=0A> addr += size, VM_PROT_ALL,=0A> =A0=A0=A0 =A0 =A0 VM_PROT_ALL, 0);=0A> -=A0=A0=A0 = if ((flags & (M_NOWAIT |=0A> M_USE_RESERVE)) =3D=3D M_NOWAIT)=0A> -=A0=A0= =A0 =A0=A0=A0 pflags =3D=0A> VM_ALLOC_INTERRUPT | VM_ALLOC_NOBUSY;=0A> -=A0= =A0=A0 else=0A> -=A0=A0=A0 =A0=A0=A0 pflags =3D=0A> VM_ALLOC_SYSTEM | VM_AL= LOC_NOBUSY;=0A> -=A0=A0=A0 if (flags & M_ZERO)=0A> -=A0=A0=A0 =A0=A0=A0 pfl= ags |=3D=0A> VM_ALLOC_ZERO;=0A> -=A0=A0=A0 if (flags & M_NODUMP)=0A> -=A0= =A0=A0 =A0=A0=A0 pflags |=3D=0A> VM_ALLOC_NODUMP;=0A> +=A0=A0=A0 pflags =3D= m2vm_flags(flags,=0A> VM_ALLOC_NOBUSY);=0A> =A0=A0=A0 VM_OBJECT_LOCK(obje= ct);=0A> =A0=A0=A0 tries =3D 0;=0A> retry:=0A> @@ -487,11 +475,7 @@ kmem_= back(vm_map_t map, vm_offset_t=0A> addr, vm_size_t size, int flags)=0A> = =A0=A0=A0 =A0 =A0 entry->wired_count =3D=3D 0=0A> && (entry->eflags & MAP_E= NTRY_IN_TRANSITION)=0A> =A0=A0=A0 =A0 =A0 =3D=3D 0, ("kmem_back: entry=0A>= not found or misaligned"));=0A> =0A> -=A0=A0=A0 if ((flags &=0A> (M_NOWAI= T|M_USE_RESERVE)) =3D=3D M_NOWAIT)=0A> -=A0=A0=A0 =A0=A0=A0 pflags =3D=0A> = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED;=0A> -=A0=A0=A0 else=0A> -=A0=A0=A0 =A0= =A0=A0 pflags =3D=0A> VM_ALLOC_SYSTEM | VM_ALLOC_WIRED;=0A> -=0A> +=A0=A0= =A0 pflags =3D m2vm_flags(flags,=0A> VM_ALLOC_WIRED);=0A> =A0=A0=A0 if (fl= ags & M_ZERO)=0A> =A0=A0=A0 =A0=A0=A0 pflags |=3D=0A> VM_ALLOC_ZERO;=0A> = =A0=A0=A0 if (flags & M_NODUMP)=0A> diff --git a/sys/vm/vm_page.h b/sys/vm/= vm_page.h=0A> index 70b8416..0286a6d 100644=0A> --- a/sys/vm/vm_page.h=0A> = +++ b/sys/vm/vm_page.h=0A> @@ -344,6 +344,24 @@ extern struct mtx_padalign= =0A> vm_page_queue_mtx;=0A> #define=A0=A0=A0=0A> VM_ALLOC_COUNT_SHIFT=A0= =A0=A0 16=0A> #define=A0=A0=A0=0A> VM_ALLOC_COUNT(count)=A0=A0=A0 ((count)= <<=0A> VM_ALLOC_COUNT_SHIFT)=0A> =0A> +#ifdef M_NOWAIT=0A> +static inline= int=0A> +m2vm_flags(int malloc_flags, int alloc_flags)=0A> +{=0A> +=A0=A0= =A0 int pflags;=0A> +=0A> +=A0=A0=A0 if ((malloc_flags & (M_NOWAIT |=0A> M_= USE_RESERVE)) =3D=3D M_NOWAIT)=0A> +=A0=A0=A0 =A0=A0=A0 pflags =3D=0A> VM_A= LLOC_SYSTEM | alloc_flags;=0A> +=A0=A0=A0 else=0A> +=A0=A0=A0 =A0=A0=A0 pfl= ags =3D=0A> VM_ALLOC_INTERRUPT | alloc_flags;=0A> +=A0=A0=A0 if (malloc_fla= gs & M_ZERO)=0A> +=A0=A0=A0 =A0=A0=A0 pflags |=3D=0A> VM_ALLOC_ZERO;=0A> += =A0=A0=A0 if (malloc_flags & M_NODUMP)=0A> +=A0=A0=A0 =A0=A0=A0 pflags |=3D= =0A> VM_ALLOC_NODUMP;=0A> +=A0=A0=A0 return (pflags);=0A> +}=0A> +#endif=0A= > +=0A> void vm_page_busy(vm_page_t m);=0A> void vm_page_flash(vm_page_t = m);=0A> void vm_page_io_start(vm_page_t m);=0A> From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 21:48:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8872A2B2; Mon, 12 Nov 2012 21:48:12 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0A78FC12; Mon, 12 Nov 2012 21:48:11 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qACLm86W054707; Mon, 12 Nov 2012 23:48:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-DKIM: OpenDKIM Filter v2.5.2 kib.kiev.ua qACLm86W054707 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qACLm8PM054706; Mon, 12 Nov 2012 23:48:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 12 Nov 2012 23:48:08 +0200 From: Konstantin Belousov To: Sushanth Rai Subject: Re: Memory reserves or lack thereof Message-ID: <20121112214808.GH73505@kib.kiev.ua> References: <20121112133638.GZ73505@kib.kiev.ua> <1352755682.93266.YahooMailClassic@web181701.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QkB+3dXt7G8Wz8Uy" Content-Disposition: inline In-Reply-To: <1352755682.93266.YahooMailClassic@web181701.mail.ne1.yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: alc@freebsd.org, pho@freebsd.org, StevenSears , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:48:12 -0000 --QkB+3dXt7G8Wz8Uy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote: > This patch still doesn't address the issue of M_NOWAIT calls driving > the memory the all the way down to 2 pages, right ? It would be nice to > have M_NOWAIT just do non-sleep version of M_WAITOK and M_USE_RESERVE > flag to dig deep. This is out of scope of the change. But it is required for any further adjustements. --QkB+3dXt7G8Wz8Uy Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlChbpcACgkQC3+MBN1Mb4ix0QCeM2Cp5w4BZKRLoFCIetw16dZc Wf4AoJAEOnFOgLyNtnCKXgmkUKAgVpYE =yg4x -----END PGP SIGNATURE----- --QkB+3dXt7G8Wz8Uy-- From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 23:09:54 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E07A8B7A; Mon, 12 Nov 2012 23:09:54 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh3.mail.rice.edu (mh3.mail.rice.edu [128.42.199.10]) by mx1.freebsd.org (Postfix) with ESMTP id AA65A8FC0C; Mon, 12 Nov 2012 23:09:54 +0000 (UTC) Received: from mh3.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh3.mail.rice.edu (Postfix) with ESMTP id A1E864018D; Mon, 12 Nov 2012 17:09:53 -0600 (CST) Received: from mh3.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh3.mail.rice.edu (Postfix) with ESMTP id A0DBE4018C; Mon, 12 Nov 2012 17:09:53 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh3.mail.rice.edu, auth channel Received: from mh3.mail.rice.edu ([127.0.0.1]) by mh3.mail.rice.edu (mh3.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id XAR2eXVjcQkA; Mon, 12 Nov 2012 17:09:53 -0600 (CST) Received: from [10.212.194.246] (unknown [10.212.194.246]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh3.mail.rice.edu (Postfix) with ESMTPSA id 84D2540186; Mon, 12 Nov 2012 17:09:53 -0600 (CST) Message-ID: <50A181C9.7030209@rice.edu> Date: Mon, 12 Nov 2012 17:10:01 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Memory reserves or lack thereof References: <20121112133638.GZ73505@kib.kiev.ua> <1352755682.93266.YahooMailClassic@web181701.mail.ne1.yahoo.com> <20121112214808.GH73505@kib.kiev.ua> In-Reply-To: <20121112214808.GH73505@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, pho@freebsd.org, Sushanth Rai , StevenSears , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:09:55 -0000 On 11/12/2012 3:48 PM, Konstantin Belousov wrote: > On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote: >> This patch still doesn't address the issue of M_NOWAIT calls driving >> the memory the all the way down to 2 pages, right ? It would be nice to >> have M_NOWAIT just do non-sleep version of M_WAITOK and M_USE_RESERVE >> flag to dig deep. > This is out of scope of the change. But it is required for any further > adjustements. I would suggest a somewhat different response: The patch does make M_NOWAIT into a "non-sleep version of M_WAITOK" and does reintroduce M_USE_RESERVE as a way to specify "dig deep". Currently, both M_NOWAIT and M_WAITOK can drive the cache/free memory down to two pages. The effect of the patch is to stop M_NOWAIT at two pages rather than allowing it to continue to zero pages. When you say, "This is out of scope ...", I believe that you are referring to changing two pages into something larger. I agree that this is out of scope for the current change. Alan From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 23:24:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07A9B10A; Mon, 12 Nov 2012 23:24:22 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id BCA5A8FC08; Mon, 12 Nov 2012 23:24:21 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so3066266dad.13 for ; Mon, 12 Nov 2012 15:24:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3QA5sInvNfE1exFJgf5QPvA6d5WFsS0CRvHVCnXVOBg=; b=ROvAeyJCTxOQQhLpYr/vhBRLrxRCTbffQ8thqsc72FCxb2UnjYNXYsXIOaQYVFYI7d eqYc+yWZ2sIszdoKK9bNPlZMNhJtEPrygqCnFOGvCx6y67J0WOsa4nOy5XmYGHCrfARc o1yqbhMOn9AwfCk5tKGbCaslBrkjATit2/jJPBen2juQXK5mACUP9W24mRPfl8vuN0wY gConyxCqizixvBNGznvgly7VAZ0RnpLbf1/6AT3JqpA1JuzWUDnzwDU9m/JDjKRJ7RnE oD5L8AbOOoLHG7Qk7bqlooAOX0y692b8jY5RiRjuetYjMeSAAUghU5IruTwWtfHxmz6Q JjtA== MIME-Version: 1.0 Received: by 10.66.77.74 with SMTP id q10mr58907618paw.81.1352762661239; Mon, 12 Nov 2012 15:24:21 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Mon, 12 Nov 2012 15:24:21 -0800 (PST) In-Reply-To: <50A181C9.7030209@rice.edu> References: <20121112133638.GZ73505@kib.kiev.ua> <1352755682.93266.YahooMailClassic@web181701.mail.ne1.yahoo.com> <20121112214808.GH73505@kib.kiev.ua> <50A181C9.7030209@rice.edu> Date: Mon, 12 Nov 2012 15:24:21 -0800 X-Google-Sender-Auth: sYHHp4_Ww-RVC3BJmWVci__8jvA Message-ID: Subject: Re: Memory reserves or lack thereof From: Adrian Chadd To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Cc: StevenSears , alc@freebsd.org, "freebsd-hackers@freebsd.org" , Sushanth Rai , pho@freebsd.org, Konstantin Belousov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:24:22 -0000 .. wait, so what exactly would the difference be between M_NOWAIT and M_WAITOK? adrian From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 23:36:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E5B8C34A; Mon, 12 Nov 2012 23:36:18 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh2.mail.rice.edu (mh2.mail.rice.edu [128.42.201.21]) by mx1.freebsd.org (Postfix) with ESMTP id B076D8FC0C; Mon, 12 Nov 2012 23:36:18 +0000 (UTC) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 3250D500127; Mon, 12 Nov 2012 17:26:33 -0600 (CST) Received: from mh2.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh2.mail.rice.edu (Postfix) with ESMTP id 2EE69500125; Mon, 12 Nov 2012 17:26:33 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh2.mail.rice.edu, auth channel Received: from mh2.mail.rice.edu ([127.0.0.1]) by mh2.mail.rice.edu (mh2.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id EdZfd6T4rOWB; Mon, 12 Nov 2012 17:26:33 -0600 (CST) Received: from [10.212.194.246] (unknown [10.212.194.246]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh2.mail.rice.edu (Postfix) with ESMTPSA id 0DB5950011C; Mon, 12 Nov 2012 17:26:33 -0600 (CST) Message-ID: <50A185B0.3030309@rice.edu> Date: Mon, 12 Nov 2012 17:26:40 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Memory reserves or lack thereof References: <20121112133638.GZ73505@kib.kiev.ua> <1352755682.93266.YahooMailClassic@web181701.mail.ne1.yahoo.com> <20121112214808.GH73505@kib.kiev.ua> <50A181C9.7030209@rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: StevenSears , alc@freebsd.org, "freebsd-hackers@freebsd.org" , Sushanth Rai , pho@freebsd.org, Konstantin Belousov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:36:19 -0000 On 11/12/2012 5:24 PM, Adrian Chadd wrote: > .. wait, so what exactly would the difference be between M_NOWAIT and M_WAITOK? Whether or not the allocation can sleep until memory becomes available. From owner-freebsd-hackers@FreeBSD.ORG Mon Nov 12 23:49:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B320B6C4; Mon, 12 Nov 2012 23:49:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 729468FC12; Mon, 12 Nov 2012 23:49:11 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz17so3185530pbc.13 for ; Mon, 12 Nov 2012 15:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1HCRcQwtM4jFwiwkcOsunmOqfpR3+nMj6Jch0wtrELY=; b=tPHkiMqW+opuZJHIock2sGEZhm6Y3QfPI3ShVSLOU/ic3Y8rEpLjsuA844d8QcvJk8 YzXIvMTlAG3OgvldfG0yQ0Aj5fA18tAwyf/4SI0y2uk+L7rZG2BwwERQUAm0q9U/cjhS g5R9EY8JOxzf39BEGySN5q+jdcr/xh6CgEFG8SPKqKycq+EhmLcoFGWYf2BJbytM4pzn PDIfS+gohZ1LE58ZjoaXqyn42zi4dgKu156SATRzD7I5+SotddaKwqpVsUV5cHgI0pWC 0ZBaquqO9+OwQCisDQp6/NwuZstgGXJVSh7v+iPmoB5N9TtNsyuP3dKFqvZOJWE+vdbW mI7g== MIME-Version: 1.0 Received: by 10.68.209.166 with SMTP id mn6mr34085109pbc.95.1352764151086; Mon, 12 Nov 2012 15:49:11 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Mon, 12 Nov 2012 15:49:11 -0800 (PST) In-Reply-To: <50A185B0.3030309@rice.edu> References: <20121112133638.GZ73505@kib.kiev.ua> <1352755682.93266.YahooMailClassic@web181701.mail.ne1.yahoo.com> <20121112214808.GH73505@kib.kiev.ua> <50A181C9.7030209@rice.edu> <50A185B0.3030309@rice.edu> Date: Mon, 12 Nov 2012 15:49:11 -0800 X-Google-Sender-Auth: G6U4KIFbFxqYwj6udtB544mTOx8 Message-ID: Subject: Re: Memory reserves or lack thereof From: Adrian Chadd To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Cc: StevenSears , alc@freebsd.org, "freebsd-hackers@freebsd.org" , Sushanth Rai , pho@freebsd.org, Konstantin Belousov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:49:11 -0000 On 12 November 2012 15:26, Alan Cox wrote: > On 11/12/2012 5:24 PM, Adrian Chadd wrote: >> >> .. wait, so what exactly would the difference be between M_NOWAIT and >> M_WAITOK? > > > Whether or not the allocation can sleep until memory becomes available. Ok, so we're still maintaining that particular behaviour. Cool. Adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 00:06:07 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9E58B70 for ; Tue, 13 Nov 2012 00:06:06 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm30.bullet.mail.sp2.yahoo.com (nm30.bullet.mail.sp2.yahoo.com [98.139.91.100]) by mx1.freebsd.org (Postfix) with ESMTP id B12CC8FC13 for ; Tue, 13 Nov 2012 00:06:06 +0000 (UTC) Received: from [98.139.91.70] by nm30.bullet.mail.sp2.yahoo.com with NNFMP; 13 Nov 2012 00:06:05 -0000 Received: from [98.139.44.76] by tm10.bullet.mail.sp2.yahoo.com with NNFMP; 13 Nov 2012 00:06:05 -0000 Received: from [127.0.0.1] by omp1013.access.mail.sp2.yahoo.com with NNFMP; 13 Nov 2012 00:06:05 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 694875.91033.bm@omp1013.access.mail.sp2.yahoo.com Received: (qmail 25839 invoked by uid 60001); 13 Nov 2012 00:06:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1352765165; bh=D531nGUWFUkHKL/DBsuitZerruL1++if0KwaCpB3Lf4=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=6ARo/LeZX57RwXwUagDBeePsDxnPZnh6kKKsTB8FP7kA92haMfbB+C4kFqH7u7zKnAKjo10Cr1V25oeDCK7zF27yWOZ9HlbgRmVA/DiH7lscC5J/vI7BTeLAmQZr0SuEIOepEtze3c7Ind8rPCB0himL3RbSebOiK20irrcVMeI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=o9+3cY1o44/kRtNgK0F/5dq5CsNcHyayzwuVoa+MJ+taOAJ1hI7SGeR4D0ZRAV+rL2+Xxw6pSk9poac+H5li9GAt2/TZFCr4LaO9rWLQgE9qsXGzTCFOmQX41OkkGIntqAfyl2tTa4+0DfNqkO2s6gVBPi1GtltewFHdYHcmkBo=; X-YMail-OSG: DFx8eRwVM1kuouj4aOKOQzvbgZBOhNI0TdoeTcdfC0m69GR PWTUnWIpRKJBKh7E4puLWj1Ef3AyX6NbDkY6F9YC7Y2McdKMC6XU0uMajK6H 2FNQf2PVWFulS0irdib_MsOF0nNiBOzo8WrbUwoOtcuMz1klaNj_UjrjK5mN uzTwukVfxJvfvGnxlcHJWRa8mSzLD9DNfSQdqSl.BpcIftumMAkM3ku.e9cE BSeI6i7rqgKfWhltXt6sD27iJr26l1UJEG7HKm89dYgg3WiNtX0zexnelhG7 KWPGB8l0O_L.KkpSqfSH1b9ofYiDD6Gtq0ebzxMI8Zx67DkcPrCwLL8Zf_wj KYy.0CH1zYs8x6GF.XZDhVPg7U4ZXMPKbnnuMdiIt0GWUM.ELhChsmEsB9qk 1D1NP9K8j7Erc9xOM13_2.npkcQNZg94ft_3HWt4xrB2.yzmSKi6SIw6.C2m DrUhfVY3wAwzry92jsZ3j6ibvyaYWPJUybla1z5u42vz1.FmAsKdv3ZeeKnP Zb6clPtYXbV3LVw-- Received: from [209.119.38.67] by web181702.mail.ne1.yahoo.com via HTTP; Mon, 12 Nov 2012 16:06:04 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gTW9uLCAxMS8xMi8xMiwgQWxhbiBDb3ggPGFsY0ByaWNlLmVkdT4gd3JvdGU6Cgo.IEZyb206IEFsYW4gQ294IDxhbGNAcmljZS5lZHU.Cj4gU3ViamVjdDogUmU6IE1lbW9yeSByZXNlcnZlcyBvciBsYWNrIHRoZXJlb2YKPiBUbzogIktvbnN0YW50aW4gQmVsb3Vzb3YiIDxrb3N0aWtiZWxAZ21haWwuY29tPgo.IENjOiAiU3VzaGFudGggUmFpIiA8c3VzaGFudGhfcmFpQHlhaG9vLmNvbT4sIGFsY0BmcmVlYnNkLm9yZywgcGhvQGZyZWVic2Qub3JnLCAiU3RldmVuU2VhcnMiIDxTdGV2ZW4uU2UBMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1352765164.25812.YahooMailClassic@web181702.mail.ne1.yahoo.com> Date: Mon, 12 Nov 2012 16:06:04 -0800 (PST) From: Sushanth Rai Subject: Re: Memory reserves or lack thereof To: Konstantin Belousov , Alan Cox In-Reply-To: <50A181C9.7030209@rice.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: alc@freebsd.org, pho@freebsd.org, StevenSears , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 00:06:07 -0000 =0A=0A--- On Mon, 11/12/12, Alan Cox wrote:=0A=0A> From: Ala= n Cox =0A> Subject: Re: Memory reserves or lack thereof=0A> T= o: "Konstantin Belousov" =0A> Cc: "Sushanth Rai" , alc@freebsd.org, pho@freebsd.org, "StevenSears" , "freebsd-hackers@freebsd.org" =0A> Date: Monday, November 12, 2012, 3:10 PM=0A> On 11/12/2012 3:48 P= M, Konstantin=0A> Belousov wrote:=0A> > On Mon, Nov 12, 2012 at 01:28:02PM = -0800, Sushanth Rai=0A> wrote:=0A> >> This patch still doesn't address the = issue of=0A> M_NOWAIT calls driving=0A> >> the memory the all the way down = to 2 pages, right ?=0A> It would be nice to=0A> >> have M_NOWAIT just do no= n-sleep version of M_WAITOK=0A> and M_USE_RESERVE=0A> >> flag to dig deep.= =0A> > This is out of scope of the change. But it is required=0A> for any f= urther=0A> > adjustements.=0A> =0A> I would suggest a somewhat different re= sponse:=0A> =0A> The patch does make M_NOWAIT into a "non-sleep version of= =0A> M_WAITOK" and does reintroduce M_USE_RESERVE as a way to=0A> specify "= dig deep".=0A> =0A> Currently, both M_NOWAIT and M_WAITOK can drive the=0A>= cache/free memory down to two pages.=A0 The effect of the=0A> patch is to = stop M_NOWAIT at two pages rather than allowing=0A> it to continue to zero = pages.=0A=0A=0AThanks for the correction. I was associating VM_ALLOC_SYSTEM= with just M_NOWAIT as it seemed in the first verion of the patch.=0A=0ASus= hanth From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 00:12:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2AA17E4D; Tue, 13 Nov 2012 00:12:18 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id E2CD08FC14; Tue, 13 Nov 2012 00:12:17 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-149-146.hsd1.ca.comcast.net [50.143.149.146]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id qAD0CFs0097895 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 16:12:16 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50A1905A.6020406@freebsd.org> Date: Mon, 12 Nov 2012 16:12:10 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Memory reserves or lack thereof References: <20121112133638.GZ73505@kib.kiev.ua> <1352755682.93266.YahooMailClassic@web181701.mail.ne1.yahoo.com> <20121112214808.GH73505@kib.kiev.ua> <50A181C9.7030209@rice.edu> <50A185B0.3030309@rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: StevenSears , Alan Cox , alc@freebsd.org, "freebsd-hackers@freebsd.org" , Sushanth Rai , pho@freebsd.org, Konstantin Belousov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 00:12:18 -0000 On 11/12/12 3:49 PM, Adrian Chadd wrote: > On 12 November 2012 15:26, Alan Cox wrote: >> On 11/12/2012 5:24 PM, Adrian Chadd wrote: >>> .. wait, so what exactly would the difference be between M_NOWAIT and >>> M_WAITOK? >> >> Whether or not the allocation can sleep until memory becomes available. > Ok, so we're still maintaining that particular behaviour. Cool. no mem | mem avail ---------------------------------------------- M_WAITOK | wait, then success | success | ---------------------------------------------- M_NOWAIT | returns failure | success | ---------------------------------------------- the question is whether the top left can ever fail for any other reason. > > > > Adrian > _______________________________________________ > 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 Tue Nov 13 03:07:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 09309DD0 for ; Tue, 13 Nov 2012 03:07:49 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF928FC08 for ; Tue, 13 Nov 2012 03:07:48 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so181029lah.13 for ; Mon, 12 Nov 2012 19:07:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:from:date:message-id:subject:to:content-type; bh=eJ1UXbfZvyF10llfNIDs+bis8Qo7jKAnsOepUVTXdXY=; b=t4nLyRm9/vaTc09jG+tGmxaKPHZxULez10ChaTR+PhdlabbUOCvrU+UBFbqNUcMhXE Op74ftzHy2kyD7h0Qp14znJo4nP2ggX2IVtZD/ZyPJTrRU/efrGaQQJ/1/st4JPiNA1T AGPuiQ9/mdiEakT3sNPL6otmeUp/ivhXmBM5o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=eJ1UXbfZvyF10llfNIDs+bis8Qo7jKAnsOepUVTXdXY=; b=ZIMtu/a4rD73FXtnvmotmW6SMRArIm41/zC7j0irnLr8FkTbwW5Sk6wqIkRjHtCAqT 2g/k1dFJuNZNkzJnlJ5zau47zvGcLaZtfe5mQeAOOoAwQo+sBvRJx6B0OYLpOfWdmBN9 IYmHgCMCZz8znw/iwHUBF3u8dUgNia27y5gYxR5QMuHyZ9uArvrSNGXjwR8yczy0ahoZ wkjPAPc9mPVskQ2l8bZ9SN46NPc7w+l8g37MlSQ51+CFHIYotJ2A417tZZyAMQ5huJq1 NLKntTHzJoMkSOl9qxZiaj2MvQ4e4/GtJcSbw7nn7HdSHwQxZD3siDDeoVDzGn6CoexL xaUw== Received: by 10.152.104.115 with SMTP id gd19mr20334946lab.13.1352776067375; Mon, 12 Nov 2012 19:07:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.166 with HTTP; Mon, 12 Nov 2012 19:07:16 -0800 (PST) From: Eitan Adler Date: Mon, 12 Nov 2012 22:07:16 -0500 Message-ID: Subject: Give users a hint when their locate database is too small. To: FreeBSD Hackers Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnmaA/NWhODgEeIQZHAj0D731yqYgKgQQv5yb0PXuQE8ZBvfrHOiZWFEsznkUKb95lgbtCM X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 03:07:49 -0000 What do people think of this? Maybe /usr/libexec/locate.updatedb is a better pointer? commit fb03b777daf2c69bb9612902e38fdb25b256be72 Author: Eitan Adler Date: Mon Nov 12 22:05:55 2012 -0500 Give users a hint when their locate database is too small. Reviwed by: ??? Approved by: ??? MFC after: 3 weeks diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/locate.c index b0faefb..f0c8c37 100644 --- a/usr.bin/locate/locate/locate.c +++ b/usr.bin/locate/locate/locate.c @@ -292,7 +292,7 @@ search_mmap(db, s) err(1, "`%s'", db); len = sb.st_size; if (len < (2*NBG)) - errx(1, "database too small: %s", db); + errx(1, "database too small: %s\nTry running /etc/periodic/weekly/310.locate", db); if ((p = mmap((caddr_t)0, (size_t)len, PROT_READ, MAP_SHARED, -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 11:54:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 049563BA; Tue, 13 Nov 2012 11:54:55 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 60A7F8FC08; Tue, 13 Nov 2012 11:54:54 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qADBsk1h037572; Tue, 13 Nov 2012 13:54:46 +0200 (EET) (envelope-from kostikbel@gmail.com) X-DKIM: OpenDKIM Filter v2.5.2 kib.kiev.ua qADBsk1h037572 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qADBsjGu037571; Tue, 13 Nov 2012 13:54:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 13 Nov 2012 13:54:45 +0200 From: Konstantin Belousov To: Alan Cox Subject: Re: Memory reserves or lack thereof Message-ID: <20121113115445.GK73505@kib.kiev.ua> References: <20121112133638.GZ73505@kib.kiev.ua> <1352755682.93266.YahooMailClassic@web181701.mail.ne1.yahoo.com> <20121112214808.GH73505@kib.kiev.ua> <50A181C9.7030209@rice.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xno7jeNlVet1RwPO" Content-Disposition: inline In-Reply-To: <50A181C9.7030209@rice.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: alc@freebsd.org, pho@freebsd.org, Sushanth Rai , StevenSears , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 11:54:55 -0000 --xno7jeNlVet1RwPO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 12, 2012 at 05:10:01PM -0600, Alan Cox wrote: > On 11/12/2012 3:48 PM, Konstantin Belousov wrote: > > On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote: > >> This patch still doesn't address the issue of M_NOWAIT calls driving > >> the memory the all the way down to 2 pages, right ? It would be nice to > >> have M_NOWAIT just do non-sleep version of M_WAITOK and M_USE_RESERVE > >> flag to dig deep. > > This is out of scope of the change. But it is required for any further > > adjustements. >=20 > I would suggest a somewhat different response: >=20 > The patch does make M_NOWAIT into a "non-sleep version of M_WAITOK" and= =20 > does reintroduce M_USE_RESERVE as a way to specify "dig deep". >=20 > Currently, both M_NOWAIT and M_WAITOK can drive the cache/free memory=20 > down to two pages. The effect of the patch is to stop M_NOWAIT at two=20 > pages rather than allowing it to continue to zero pages. >=20 > When you say, "This is out of scope ...", I believe that you are=20 > referring to changing two pages into something larger. I agree that=20 > this is out of scope for the current change. I referred exactly to the difference between M_USE_RESERVE set or not. IMO this is what was asked by the question author. So yes, my mean of the 'out of scope' is about tweaking the 'two pages reserve' in some way. --xno7jeNlVet1RwPO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCiNQQACgkQC3+MBN1Mb4g3HgCfRdJiDZjLzVoW2ncDOfrwMGay DIsAn2jfyPpt6vmGm40KixF/0Qwdz2qV =+XXH -----END PGP SIGNATURE----- --xno7jeNlVet1RwPO-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 12:06:45 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A55E8CD; Tue, 13 Nov 2012 12:06:45 +0000 (UTC) (envelope-from uqs@FreeBSD.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by mx1.freebsd.org (Postfix) with ESMTP id 213C98FC19; Tue, 13 Nov 2012 12:06:44 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a01:4f8:131:23c2::1]) by acme.spoerlein.net (8.14.5/8.14.5) with ESMTP id qADC6hp5027808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 13 Nov 2012 13:06:43 +0100 (CET) (envelope-from uqs@FreeBSD.org) Date: Tue, 13 Nov 2012 13:06:43 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: hiren panchasara Subject: Re: Porting patch(1) from NetBSD to FreeBSD (was Re: FreeBSD in Google Code-In 2012? You can help too!) Message-ID: <20121113120642.GW69724@acme.spoerlein.net> Mail-Followup-To: hiren panchasara , Garrett Cooper , Gabor Kovesdan , freebsd-hackers@freebsd.org, Adrian Chadd , Pedro Giffuni References: <508D0F11.1060203@kovesdan.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Garrett Cooper , Gabor Kovesdan , Adrian Chadd , Pedro Giffuni , freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 12:06:45 -0000 On Mon, 2012-10-29 at 23:13:00 -0700, hiren panchasara wrote: > Thank you all for the inputs. > I understand this is a long grueling process so I will attempt to do things > in approximately following order: > > 1) prepare a new port for bsd patch > 2) make sure new bsd patch has all options of existing gnu patch > 3) merge outstanding patches: > http://svnweb.freebsd.org/base/head/gnu/usr.bin/patch/?view=log > 4) bug compatibility > 5) performance For 2) and 4) (maybe also 5?) you really should look into ATF and come up with some test cases for each option, someone else also mentioned unit tests that GNU patch ships with? We really would like to see *BSD patch in the base, but it should come with unit tests; it is 2012, after all :) Thanks! Uli From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 08:37:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A09D976 for ; Tue, 13 Nov 2012 08:37:10 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) by mx1.freebsd.org (Postfix) with ESMTP id 4FDE58FC0C for ; Tue, 13 Nov 2012 08:37:10 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 8A5B36A6004; Tue, 13 Nov 2012 09:37:09 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.5/8.14.5) with ESMTP id qAD8b9H0034687; Tue, 13 Nov 2012 09:37:09 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.5/8.14.5/Submit) id qAD8b9mk033364; Tue, 13 Nov 2012 09:37:09 +0100 (CET) (envelope-from lars) Date: Tue, 13 Nov 2012 09:37:09 +0100 From: Lars Engels To: Eitan Adler Subject: Re: Give users a hint when their locate database is too small. Message-ID: <20121113083709.GC96846@e-new.0x20.net> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eRtJSFbw+EEWtPj3" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.3-RELEASE-p4 User-Agent: Mutt/1.5.21 (2010-09-15) X-Mailman-Approved-At: Tue, 13 Nov 2012 12:23:53 +0000 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:37:10 -0000 --eRtJSFbw+EEWtPj3 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Nov 12, 2012 at 10:07:16PM -0500, Eitan Adler wrote: > What do people think of this? Maybe /usr/libexec/locate.updatedb is a > better pointer? >=20 > commit fb03b777daf2c69bb9612902e38fdb25b256be72 > Author: Eitan Adler > Date: Mon Nov 12 22:05:55 2012 -0500 >=20 > Give users a hint when their locate database is too small. >=20 > Reviwed by: ??? > Approved by: ??? > MFC after: 3 weeks >=20 > diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/locat= e.c > index b0faefb..f0c8c37 100644 > --- a/usr.bin/locate/locate/locate.c > +++ b/usr.bin/locate/locate/locate.c > @@ -292,7 +292,7 @@ search_mmap(db, s) > err(1, "`%s'", db); > len =3D sb.st_size; > if (len < (2*NBG)) > - errx(1, "database too small: %s", db); > + errx(1, "database too small: %s\nTry running > /etc/periodic/weekly/310.locate", db); >=20 > if ((p =3D mmap((caddr_t)0, (size_t)len, > PROT_READ, MAP_SHARED, >=20 Enlarge your .... database! ;-) --eRtJSFbw+EEWtPj3 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlCiBrUACgkQKc512sD3afj3mgCfQBf0+cjXnsP/BXKyBNjNn8Vn CLoAn0REvYsefzf0LRKzl5UdhIoMpb92 =vfFD -----END PGP SIGNATURE----- --eRtJSFbw+EEWtPj3-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 12:30:11 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EEFBEDD2; Tue, 13 Nov 2012 12:30:11 +0000 (UTC) (envelope-from masked@internode.on.net) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by mx1.freebsd.org (Postfix) with ESMTP id 32F6F8FC14; Tue, 13 Nov 2012 12:30:09 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAJABQ8olCWZd2M/2dsb2JhbABEgkmDUbxaA4IFghUYG2EKAwYBPgJfARoJh3inc4I9kDSNBoRcMmEDjXSBB4EhliODAw Received: from ppp221-140.static.internode.on.net (HELO forexamplePC) ([150.101.221.140]) by ipmail07.adl2.internode.on.net with SMTP; 13 Nov 2012 23:00:08 +1030 Message-ID: From: "Michael Vale" To: , , Subject: my work on cross-build for mips, arm, etc - your help, please! Date: Tue, 13 Nov 2012 23:30:10 +1100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0018_01CDC1F6.D29750E0" X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 12:30:12 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0018_01CDC1F6.D29750E0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was just going to continuing hacking away at this but adri was really = keen that i post this stuff.. So far with what i=E2=80=99ve got I can cross-build just about anything, = but it=E2=80=99s not automated, there is issues with finding and = building dependencies. i=E2=80=99m using XDEV as the cross compiler a command line such as=20 env TARGET=3Dmips TARGET_ARCH=3Dmips make _TARGET_CROSS_DEFS=3D = =E2=80=93C /usr/ports/net/asterisk10 all should get the ball rolling ------=_NextPart_000_0018_01CDC1F6.D29750E0 Content-Type: application/octet-stream; name="bsd.cross.mk" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="bsd.cross.mk" #########################=0A= #=0A= # Ports CROSS COMPILING=0A= #=0A= #########################=0A= #=0A= # Variables:=0A= #=0A= # X_STAGING_ROOT =3D Defaults to ${OBJ_DIR}/${TARGET}.${TARGET_ARCH}=0A= #=0A= =0A= X_STAGING_ROOT=3D${OBJ_DIR}/${TARGET}.${TARGET_ARCH}/rootfs=0A= =0A= #TARGET_ARCH!=3Dmips=0A= #ARCH!=3D ${UNAME} -p=0A= =0A= #_TARGET_DEFS =3D \=0A= # TARGET_VENDOR=3D${TARGET_VENDOR} \=0A= # TARGET_DEVICE=3D${TARGET_DEVICE} \=0A= # FREEBSD_SRC_TREE=3D${FREEBSD_SRC_TREE} \=0A= # TARGET_PROFILES=3D"${TARGET_PROFILES}"=0A= =0A= CFLAGS=3D"-I${X_STAGING_ROOT}/lib -I${X_STAGING_ROOT}/include -std=3Dc99"=0A= =0A= _TARGET_CROSS_DEFS =3D \=0A= CHROOTED=3Dno \=0A= DESTDIR=3D${X_STAGING_ROOT} \=0A= LOCALBASE=3D${X_STAGING_ROOT} \=0A= CFLAGS=3D"-I${X_STAGING_ROOT}/lib -I${X_STAGING_ROOT}/include = -std=3Dc99" \=0A= CXXFLAGS=3D"-I${X_STAGING_ROOT}/include = -I${X_STAGING_ROOT}/include/json" \=0A= NO_PKG_REGISTER=3Dyes \=0A= INSTALL_AS_USER=3D2=0A= =0A= PATH=3D/usr/mips-freebsd/usr/bin:${PATH}=0A= PKG_CONFIG_PATH=3D${X_STAGING_ROOT}/libdata/pkgconfig/=0A= PKG_DBDIR=3D${X_STAGING_ROOT}/libdata/var/db/pkg=0A= NO_INSTALL_MANPAGES=3Dyes=0A= WITHOUT_CHECK=3Dyes=0A= NOPORTDOCS=3Dyes=0A= NOPORTEXAMPLES=3Dyes=0A= ac_cv_func_malloc_0_nonnull=3Dyes=0A= ac_cv_func_realloc_0_nonnull=3Dyes=0A= AUTOTOOLS_LOCALBASE=3D/usr/local=0A= LIBTOOL=3D/usr/local/bin/libtool=0A= CONFIGURE_HOST=3Dmips-freebsd=0A= LD_LIBRARY_PATH+=3D${X_STAGING_ROOT}/lib=0A= LD_FLAGS=3D${X_STAGING_ROOT}/lib=0A= =0A= #######=0A= #=0A= # Custom definition variables per-port (WORKAROUND: as to not break/fix = /usr/ports/*/*/Makefile's yet!)=0A= #=0A= #######=0A= =0A= .for port in ${PKGORIGIN}=0A= .if make(devel/pcre)=0A= _TARGET_CROSS_DEFS =3D ${TARGET_CROSS_DEFS} \=0A= CC_FOR_BUILD=3D/usr/bin/cc=0A= .endif=0A= .endfor=0A= =0A= #.for port in ${BUILD_DEPENDS_LIST}=0A= # @echo "Start ${port} port building..."=0A= # mkdir -p ${X_STAGING_ROOT}/libdata/var/db/pkg=0A= # cd ${X_STAGING_ROOT} ;${MAKE} PORT_BUILD_DEPEND_CROSS=3D${port} = port-build-depend-cross=0A= #.endfor=0A= # @echo "----> Ports dependencies build done ..."=0A= =0A= =0A= # Cross-compilation of dependency, build dependency must be built with = host env=0A= # LIB and RUN dependency should be builded with cross environment=0A= # Else (FETCH, EXTRACT, PATCH, BUILD dependency) with host env=0A= =0A= port-build-depend-cross:=0A= .for port in ${PORT_BUILD_DEPEND_CROSS}=0A= @echo "--------> Start ${port} port building ..."=0A= @echo "------------> Test FETCH EXTRACT PATCH BUILD dependency for = ${dir}..."=0A= _DEPENDS=3D$$(cd ${dir} ; ${MAKE} -VFETCH_DEPENDS -VEXTRACT_DEPENDS = -VPATCH_DEPENDS -VBUILD_DEPENDS) ; \=0A= if [ "x$${_DEPENDS}" !=3D "x" ] ; then \=0A= echo "$${_DEPENDS}" ; \=0A= ${MAKE} -f /usr/ports/Mk/bsd.port.mk BUILD_DEPENDS=3D"$${_DEPENDS}" = depends ; \=0A= fi=0A= @echo "------------> Test LIB dependency for ${dir}..."=0A= @_DEPENDS=3D$$(cd ${dir} ; ${MAKE} -VLIB_DEPENDS) ; \=0A= echo "LIB_DEPENDS=3D$${_DEPENDS}" ; \=0A= for _DEP in $${_DEPENDS} ; do \=0A= _DEPTEST=3D$${_DEP%%:*} ; \=0A= echo "Test if $${_DEPTEST} present" ; \=0A= LIBNAME=3D$${_DEPTEST%.*} ; \=0A= LIBVER=3D$${_DEPTEST#*.} ; \=0A= if [ "$${LIBNAME}" =3D "$${LIBVER}" ] ; then LIBVER=3D"" ; else = LIBVER=3D".$${LIBVER}" ; fi ; \=0A= SONAME=3Dlib$${LIBNAME}.so$${LIBVER} ; \=0A= echo Search for $${SONAME} ; \=0A= MATCHED_LIBS=3D$$(find ${X_STAGING_ROOT}/lib ${X_STAGING_ROOT}/usr/lib = -name $${SONAME}) ; \=0A= _DEPPATH=3D$${_DEP#*:} ; \=0A= if [ -z $${MATCHED_LIBS} ] ; then \=0A= cd ${ZROUTER_ROOT} ; ${MAKE} ${_TARGET_DEFS} = PORT_BUILD_DEPEND_CROSS=3D$${_DEPPATH} port-build-depend-cross ; \=0A= fi ; \=0A= done=0A= @echo "------------> Test RUN dependency for ${dir}..."=0A= @_DEPENDS=3D$$(cd ${dir} ; ${MAKE} -VRUN_DEPENDS) ; \=0A= echo "RUN_DEPENDS=3D$${_DEPENDS}" ; \=0A= for _DEP in $${_DEPENDS} ; do \=0A= _DEPTEST=3D$${_DEP%%:*} ; \=0A= echo "$${_DEPTEST} is pkg-config?" ; \=0A= if [ "$${_DEPTEST}" =3D "pkg-config" ] ; then continue ; fi ; \=0A= echo "Test if $${_DEPTEST} present" ; \=0A= _DEPPATH=3D$${_DEP#*:} ; \=0A= cd ${ZROUTER_ROOT} ; ${MAKE} ${_TARGET_DEFS} = PORT_BUILD_DEPEND_CROSS=3D$${_DEPPATH} port-build-depend-cross ; \=0A= done=0A= @echo "------------> Build ${dir}..."=0A= @cd ${dir} ; ${MAKE} ${_TARGET_CROSS_DEFS} = WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} generate-plist=0A= @PORT_PLIST=3D$$( cd ${dir} ; ${MAKE} ${_TARGET_CROSS_DEFS} = WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} -VTMPPLIST ) ; \=0A= PORT_STATUS=3D$$( ${ZROUTER_ROOT}/tools/checkdep.pl libs = $${PORT_PLIST} ${WORLDDESTDIR} ) ; \=0A= if [ $${PORT_STATUS} -lt 50 ] ; then \=0A= echo "$${PORT_STATUS}% of files matched, do install" ; \=0A= rm -f ${ZROUTER_OBJ}/ports/${dir}/.install* ; \=0A= echo cd ${dir} ; echo ${MAKE} ${_TARGET_CROSS_DEFS} = WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} install; \=0A= cd ${dir} ; PATH=3D${FREEBSD_BUILD_ENV_PATH} ${MAKE} = ${_TARGET_CROSS_DEFS} WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} install || \=0A= ( ${MAKE} WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} clean && \=0A= echo ${MAKE} WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} configure && \=0A= ${MAKE} WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} configure && \=0A= mv `${MAKE} WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} -VPATCH_COOKIE` = `${MAKE} ${_TARGET_CROSS_DEFS} WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} = -VPATCH_COOKIE` && \=0A= mv `${MAKE} WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} = -VEXTRACT_COOKIE` `${MAKE} ${_TARGET_CROSS_DEFS} = WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} -VEXTRACT_COOKIE` && \=0A= mv `${MAKE} WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} = -VCONFIGURE_COOKIE` `${MAKE} ${_TARGET_CROSS_DEFS} = WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} -VCONFIGURE_COOKIE` && \=0A= echo ${MAKE} ${_TARGET_CROSS_DEFS} = WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} all && \=0A= ${MAKE} ${_TARGET_CROSS_DEFS} = WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} all && \=0A= echo ${MAKE} ${_TARGET_CROSS_DEFS} = WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} install && \=0A= ${MAKE} ${_TARGET_CROSS_DEFS} = WRKDIR=3D${ZROUTER_OBJ}/ports/${dir} install ) ; \=0A= fi=0A= .endfor=0A= @echo "--------> Done building ${dir} port ..."=0A= =0A= =0A= # Host tools required for extract, patch, configure, build etc.=0A= # All dependency should be built and installed with host environment=0A= # so now we don`t care about dependency type.=0A= =0A= port-build-depend-host:=0A= @echo "Start ${PORTNAME} port building..."=0A= .for port in ${PORT_BUILD_DEPEND_HOST}=0A= @echo "---------> build/install/clean for port ${port} as dependency = with host environment"=0A= cd ${dir} ; ${MAKE} install clean=0A= @echo "---------> port ${dir} done (dependency)"=0A= .endfor=0A= ------=_NextPart_000_0018_01CDC1F6.D29750E0 Content-Type: application/octet-stream; name="bsd.port.mk.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="bsd.port.mk.diff" 1845c1845=0A= < USE_LDCONFIG=3D ${DESTDIR}${PREFIX}/lib=0A= ---=0A= > USE_LDCONFIG=3D ${PREFIX}/lib=0A= 2204,2208d2203=0A= < .if defined(CROSS_COMPILE)=0A= < .include "${PORTSDIR}/Mk/bsd.cross.mk"=0A= < #CROSS_COMPILE?=3D ${TARGET_ARCH}-freebsd-=0A= < #CROSS_COMPILE:=3D ${CROSS_COMPILE:S/^/'CROSS_COMPILE=3D'/}=0A= < .endif=0A= 2368,2386d2362=0A= < #__DESTDIRD_PREFIX=3D=0A= < #_USE_DESTDIR=3D=0A= < #.for component in ${PREFIX}=0A= < #.if ${__DESTDIRD_PREFIX:M${component}} !=3D "" &&=0A= < #.if ${DESTDIR} !=3D "" &&=0A= < #.if ${PREFIX} !=3D ""=0A= < #__DESTDIRD_PREFIX+=3D ${DESTDIR}${component}=0A= < #PREFIX=3D${__DESTDIRD_PREFIX}=0A= < #.endif=0A= < #.endif=0A= < #.endif=0A= < #.endfor=0A= < =0A= < #.for f in ${PREFIX}=0A= < # @${SED} -i.bak -i '' -e 's/^M$$/${DESTDIR}/' ${WRKSRC}/${f}=0A= < #.endfor=0A= < =0A= < =0A= < =0A= 2959,2964c2935,2936=0A= < #CONFIGURE_BUILD?=3D ${ARCH}-freebsd=0A= < #CONFIGURE_BUILD:=3D ${CONFIGURE_BUILD:S/^/--build=3D/}=0A= < #CONFIGURE_TARGET?=3D ${TARGET_ARCH}-freebsd=0A= < #CONFIGURE_TARGET:=3D ${CONFIGURE_TARGET:S/--target=3D//}=0A= < CONFIGURE_HOST?=3D ${TARGET_ARCH}-freebsd=0A= < CONFIGURE_HOST:=3D ${CONFIGURE_HOST:S/^/--host=3D/}=0A= ---=0A= > CONFIGURE_TARGET?=3D ${ARCH}-portbld-freebsd${OSREL}=0A= > CONFIGURE_TARGET:=3D ${CONFIGURE_TARGET:S/--build=3D//}=0A= 2991c2963=0A= < _LATE_CONFIGURE_ARGS=3D"$${_LATE_CONFIGURE_ARGS} ${CONFIGURE_TARGET} = --with-sysroot=3D${WORLDDESTDIR}" ; \=0A= ---=0A= > _LATE_CONFIGURE_ARGS=3D"$${_LATE_CONFIGURE_ARGS} = ${CONFIGURE_TARGET}" ; \=0A= 3761c3733=0A= < CFLAGS+=3D"${CFLAGS}" CPPFLAGS+=3D"${CPPFLAGS}" = CXXFLAGS+=3D"${CXXFLAGS}" \=0A= ---=0A= > CFLAGS=3D"${CFLAGS}" CPPFLAGS=3D"${CPPFLAGS}" = CXXFLAGS=3D"${CXXFLAGS}" \=0A= 3768c3740=0A= < ${CONFIGURE_ENV} ./${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS} = ${CONFIGURE_HOST}; then \=0A= ---=0A= > ${CONFIGURE_ENV} ./${CONFIGURE_SCRIPT} ${CONFIGURE_ARGS}; then \=0A= 3920c3892=0A= < .if defined(USE_GMAKE) && !defined(TARGET_ARCH)=0A= ---=0A= > .if defined(USE_GMAKE)=0A= 3929d3900=0A= < #.endif=0A= 3932a3904=0A= > =0A= 4015c3987=0A= < ${MKDIR} -p ${PREFIX}${PKG_DBDIR}; \=0A= ---=0A= > ${MKDIR} ${PKG_DBDIR}; \=0A= 4029,4030c4001,4002=0A= < if [ -d ${PREFIX}${PKG_DBDIR}/${PKGNAME} -o -n "$${found_package}" = ]; then \=0A= < if [ -d ${PREFIX}${PKG_DBDIR}/${PKGNAME} ]; then \=0A= ---=0A= > if [ -d ${PKG_DBDIR}/${PKGNAME} -o -n "$${found_package}" ]; then \=0A= > if [ -d ${PKG_DBDIR}/${PKGNAME} ]; then \=0A= 4058c4030=0A= < @${MKDIR} ${DESTDIR}/${PREFIX}=0A= ---=0A= > @${MKDIR} ${PREFIX}=0A= 4060c4032=0A= < if [ -w ${DESTDIR}/${PREFIX}/ ]; then \=0A= ---=0A= > if [ -w ${PREFIX}/ ]; then \=0A= 4063c4035=0A= < ${ECHO_MSG} "Error: ${DESTDIR}/${PREFIX}/ not writable."; \=0A= ---=0A= > ${ECHO_MSG} "Error: ${PREFIX}/ not writable."; \=0A= 4074,4076c4046,4048=0A= < ${MTREE_CMD} ${MTREE_ARGS} ${DESTDIR}${PREFIX}/ >/dev/null; \=0A= < if [ ${DESTDIR}${PREFIX} =3D ${LOCALBASE} -a = "${MTREE_FILE_DEFAULT}" =3D "yes" ]; then \=0A= < cd ${DESTDIR}${PREFIX}/share/nls; \=0A= ---=0A= > ${MTREE_CMD} ${MTREE_ARGS} ${PREFIX}/ >/dev/null; \=0A= > if [ ${PREFIX} =3D ${LOCALBASE} -a "${MTREE_FILE_DEFAULT}" =3D = "yes" ]; then \=0A= > cd ${PREFIX}/share/nls; \=0A= 4111c4083=0A= < @${MKDIR} -p ${DESTDIR}${PREFIX}/${LDCONFIG_DIR}=0A= ---=0A= > @${MKDIR} ${PREFIX}/${LDCONFIG_DIR}=0A= 4114c4086=0A= < > ${DESTDIR}${PREFIX}/${LDCONFIG_DIR}/${UNIQUENAME}=0A= ---=0A= > > ${PREFIX}/${LDCONFIG_DIR}/${UNIQUENAME}=0A= 4134c4106=0A= < @${MKDIR} ${DESTDIR}${PREFIX}/${LDCONFIG_32DIR}=0A= ---=0A= > @${MKDIR} ${PREFIX}/${LDCONFIG_32DIR}=0A= 4137c4109=0A= < > ${DESTDIR}${PREFIX}/${LDCONFIG32_DIR}/${UNIQUENAME}=0A= ---=0A= > > ${PREFIX}/${LDCONFIG32_DIR}/${UNIQUENAME}=0A= 4273c4245=0A= < match($$0, /^@cwd /) { prefix =3D substr($$0, RSTART + RLENGTH); if = (prefix =3D=3D "/") prefix=3D""; if (destdir !=3D "") = prefix=3D"$destdir"; next; } \=0A= ---=0A= > match($$0, /^@cwd /) { prefix =3D substr($$0, RSTART + RLENGTH); if = (prefix =3D=3D "/") prefix=3D""; next; } \=0A= 4315c4287=0A= < .if !defined(CHROOTED)=0A= ---=0A= > .if defined(CHROOTED)=0A= 5698c5670=0A= < @for i in ${_TMLINKS:M${_PREFIX}*:S|^${_PREFIX}||}; do \=0A= ---=0A= > @for i in ${_TMLINKS:M${_PREFIX}*:S|^${_PREFIX}/||}; do \=0A= 5766c5738=0A= < ${ECHO_CMD} "@cwd ${DESTDIR}${PREFIX}" >> ${TMPPLIST}; \=0A= ---=0A= > ${ECHO_CMD} "@cwd ${PREFIX}" >> ${TMPPLIST}; \=0A= 5775c5747=0A= < ${SED} -ne 's,^${DESTDIR}${PREFIX},,p' >> ${TMPPLIST}=0A= ---=0A= > ${SED} -ne 's,^${PREFIX}/,,p' >> ${TMPPLIST}=0A= 5777c5749=0A= < ${SED} -ne 's,^${DESTDIR}${PREFIX}/,@dirrm ,p' >> ${TMPPLIST}=0A= ---=0A= > ${SED} -ne 's,^${PREFIX}/,@dirrm ,p' >> ${TMPPLIST}=0A= 5789c5761=0A= < ${ECHO_CMD} "@cwd ${DESTDIR}${PREFIX}" >> ${TMPPLIST}; \=0A= ---=0A= > ${ECHO_CMD} "@cwd ${PREFIX}" >> ${TMPPLIST}; \=0A= 5795c5767=0A= < ${SED} -e 's,^${DESTDIR}${PREFIX}/,,' >> ${TMPPLIST}; \=0A= ---=0A= > ${SED} -e 's,^${PREFIX}/,,' >> ${TMPPLIST}; \=0A= 5802c5774=0A= < @${ECHO_CMD} "@dirrm ${EXAMPLESDIR:S,^${DESTDIR}${PREFIX}/,,}" >> = ${TMPPLIST}=0A= ---=0A= > @${ECHO_CMD} "@dirrm ${EXAMPLESDIR:S,^${PREFIX}/,,}" >> ${TMPPLIST}=0A= 5813c5785=0A= < ${ECHO_CMD} "@cwd ${DESTDIR}${PREFIX}" >> ${TMPPLIST}; \=0A= ---=0A= > ${ECHO_CMD} "@cwd ${PREFIX}" >> ${TMPPLIST}; \=0A= 5819c5791=0A= < ${SED} -e 's,^${DESTDIR}/${PREFIX}/,,' >> ${TMPPLIST}; \=0A= ---=0A= > ${SED} -e 's,^${PREFIX}/,,' >> ${TMPPLIST}; \=0A= 5823c5795=0A= < ${SED} -ne 's,^${DESTDIR}/${PREFIX}/,,p' >> ${TMPPLIST}=0A= ---=0A= > ${SED} -ne 's,^${PREFIX}/,,p' >> ${TMPPLIST}=0A= 5825,5826c5797,5798=0A= < ${SED} -ne 's,^${DESTDIR}/${PREFIX}/,@dirrm ,p' >> ${TMPPLIST}=0A= < @${ECHO_CMD} "@dirrm ${DATADIR:S,^${DESTDIR}/${PREFIX}/,,}" >> = ${TMPPLIST}=0A= ---=0A= > ${SED} -ne 's,^${PREFIX}/,@dirrm ,p' >> ${TMPPLIST}=0A= > @${ECHO_CMD} "@dirrm ${DATADIR:S,^${PREFIX}/,,}" >> ${TMPPLIST}=0A= 5844c5816=0A= < install-info --quiet ${DESTDIR}/${PREFIX}/${INFO_PATH}/$i.info = ${DESTDIR}/${PREFIX}/${INFO_PATH}/dir=0A= ---=0A= > install-info --quiet ${PREFIX}/${INFO_PATH}/$i.info = ${PREFIX}/${INFO_PATH}/dir=0A= 5847c5819=0A= < @${LS} ${DESTDIR}/${PREFIX}/${INFO_PATH}/$i.info* | ${SED} -e = s:${DESTDIR}/${PREFIX}/::g >> ${TMPPLIST}=0A= ---=0A= > @${LS} ${PREFIX}/${INFO_PATH}/$i.info* | ${SED} -e s:${PREFIX}/::g >> = ${TMPPLIST}=0A= 5881c5853=0A= < ${INSTALL_SCRIPT} ${WRKDIR}/$${i} ${DESTDIR}/etc/rc.d/$${i%.sh}; \=0A= ---=0A= > ${INSTALL_SCRIPT} ${WRKDIR}/$${i} /etc/rc.d/$${i%.sh}; \=0A= 5884c5856=0A= < @${ECHO_CMD} "@cwd ${DESTDIR}/${PREFIX}" >> ${TMPPLIST}=0A= ---=0A= > @${ECHO_CMD} "@cwd ${PREFIX}" >> ${TMPPLIST}=0A= 5888c5860=0A= < @${ECHO_CMD} "@cwd ${DESTDIR}${PREFIX}" >> ${TMPPLIST}=0A= ---=0A= > @${ECHO_CMD} "@cwd ${PREFIX}" >> ${TMPPLIST}=0A= 5890c5862=0A= < ${INSTALL_SCRIPT} ${WRKDIR}/$${i} = ${DESTDIR}${PREFIX}/etc/rc.d/$${i%.sh}; \=0A= ---=0A= > ${INSTALL_SCRIPT} ${WRKDIR}/$${i} ${PREFIX}/etc/rc.d/$${i%.sh}; \=0A= 5935c5907=0A= < @if [ ! -d ${DESTDIR}${PREFIX}${PKG_DBDIR} ]; then ${RM} -f = ${DESTDIR}${PREFIX}${PKG_DBDIR}; ${MKDIR} ${PKG_DBDIR}; fi=0A= ---=0A= > @if [ ! -d ${PKG_DBDIR} ]; then ${RM} -f ${PKG_DBDIR}; ${MKDIR} = ${PKG_DBDIR}; fi=0A= 5938,5939c5910,5911=0A= < @if [ -e ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}/+REQUIRED_BY ]; = then \=0A= < ${CP} ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}/+REQUIRED_BY = /tmp/${PKGNAME}-required-by; \=0A= ---=0A= > @if [ -e ${PKG_DBDIR}/${PKGNAME}/+REQUIRED_BY ]; then \=0A= > ${CP} ${PKG_DBDIR}/${PKGNAME}/+REQUIRED_BY = /tmp/${PKGNAME}-required-by; \=0A= 5941c5913=0A= < @${RM} -rf ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}=0A= ---=0A= > @${RM} -rf ${PKG_DBDIR}/${PKGNAME}=0A= 5943,5948c5915,5920=0A= < @if [ ! -d ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME} ]; then \=0A= < ${ECHO_MSG} "=3D=3D=3D> Registering installation for = ${DESTDIR}/${PKGNAME}"; \=0A= < ${MKDIR} ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}; \=0A= < ${PKG_CMD} ${PKG_ARGS} -O ${PKGFILE} > = ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}/+CONTENTS; \=0A= < ${CP} ${DESCR} ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}/+DESC; \=0A= < ${ECHO_CMD} ${COMMENT:Q} > = ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}/+COMMENT; \=0A= ---=0A= > @if [ ! -d ${PKG_DBDIR}/${PKGNAME} ]; then \=0A= > ${ECHO_MSG} "=3D=3D=3D> Registering installation for ${PKGNAME}"; \=0A= > ${MKDIR} ${PKG_DBDIR}/${PKGNAME}; \=0A= > ${PKG_CMD} ${PKG_ARGS} -O ${PKGFILE} > = ${PKG_DBDIR}/${PKGNAME}/+CONTENTS; \=0A= > ${CP} ${DESCR} ${PKG_DBDIR}/${PKGNAME}/+DESC; \=0A= > ${ECHO_CMD} ${COMMENT:Q} > ${PKG_DBDIR}/${PKGNAME}/+COMMENT; \=0A= 5950c5922=0A= < ${CP} ${PKGINSTALL} = ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}/+INSTALL; \=0A= ---=0A= > ${CP} ${PKGINSTALL} ${PKG_DBDIR}/${PKGNAME}/+INSTALL; \=0A= 5953c5925=0A= < ${CP} ${PKGDEINSTALL} = ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}/+DEINSTALL; \=0A= ---=0A= > ${CP} ${PKGDEINSTALL} ${PKG_DBDIR}/${PKGNAME}/+DEINSTALL; \=0A= 5956c5928=0A= < ${CP} ${PKGREQ} = ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}/+REQUIRE; \=0A= ---=0A= > ${CP} ${PKGREQ} ${PKG_DBDIR}/${PKGNAME}/+REQUIRE; \=0A= 5959,5960c5931,5932=0A= < ${CP} ${PKGMESSAGE} = ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}/+DISPLAY; \=0A= < ${ECHO_CMD} "@display +DISPLAY" >> = ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}/+CONTENTS; \=0A= ---=0A= > ${CP} ${PKGMESSAGE} ${PKG_DBDIR}/${PKGNAME}/+DISPLAY; \=0A= > ${ECHO_CMD} "@display +DISPLAY" >> = ${PKG_DBDIR}/${PKGNAME}/+CONTENTS; \=0A= 5963,5964c5935,5936=0A= < if [ -d ${DESTDIR}${PREFIX}${PKG_DBDIR}/$$dep -a -z `${ECHO_CMD} = $$dep | ${GREP} -E ${PKG_IGNORE_DEPENDS}` ]; then \=0A= < if ! ${GREP} ^${PKGNAME}$$ = ${DESTDIR}${PREFIX}${PKG_DBDIR}/$$dep/+REQUIRED_BY \=0A= ---=0A= > if [ -d ${PKG_DBDIR}/$$dep -a -z `${ECHO_CMD} $$dep | ${GREP} -E = ${PKG_IGNORE_DEPENDS}` ]; then \=0A= > if ! ${GREP} ^${PKGNAME}$$ ${PKG_DBDIR}/$$dep/+REQUIRED_BY \=0A= 5966c5938=0A= < ${ECHO_CMD} ${PKGNAME} >> = ${DESTDIR}${PREFIX}${PKG_DBDIR}/$$dep/+REQUIRED_BY; \=0A= ---=0A= > ${ECHO_CMD} ${PKGNAME} >> ${PKG_DBDIR}/$$dep/+REQUIRED_BY; \=0A= 5973c5945=0A= < ${CP} ${MTREE_FILE} = ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}/+MTREE_DIRS; \=0A= ---=0A= > ${CP} ${MTREE_FILE} ${PKG_DBDIR}/${PKGNAME}/+MTREE_DIRS; \=0A= 5977c5949=0A= < ${CAT} /tmp/${PKGNAME}-required-by >> = ${DESTDIR}${PREFIX}${PKG_DBDIR}/${PKGNAME}/+REQUIRED_BY; \=0A= ---=0A= > ${CAT} /tmp/${PKGNAME}-required-by >> = ${PKG_DBDIR}/${PKGNAME}/+REQUIRED_BY; \=0A= 6499c6471=0A= < ${ECHO_CMD} "@cwd ${DESTDIR}${PREFIX}" >> ${TMPPLIST}; \=0A= ---=0A= > ${ECHO_CMD} "@cwd ${PREFIX}" >> ${TMPPLIST}; \=0A= ------=_NextPart_000_0018_01CDC1F6.D29750E0-- From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 12:31:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5AE1AFF3; Tue, 13 Nov 2012 12:31:26 +0000 (UTC) (envelope-from masked@internode.on.net) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by mx1.freebsd.org (Postfix) with ESMTP id 7E6748FC13; Tue, 13 Nov 2012 12:31:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EADY9olCWZd2M/2dsb2JhbABEgkmDUb5igh4BAQ0bYQoDAwQNBAEBKwJRDgESCAmHeKd6gj2QNYwhhUEyYQONdJhLgwM Received: from ppp221-140.static.internode.on.net (HELO forexamplePC) ([150.101.221.140]) by ipmail07.adl2.internode.on.net with SMTP; 13 Nov 2012 23:01:24 +1030 Message-ID: <0728FA19E18F48E89964934E5FCA5A4B@forexamplePC> From: "Michael Vale" To: , , Subject: Re: my work on cross-build for mips, arm, etc - your help, please! Date: Tue, 13 Nov 2012 23:31:25 +1100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 12:31:26 -0000 P.S. some of the ${DESTDIR} things i added can be removed!!! From: Michael Vale=20 Sent: Tuesday, November 13, 2012 11:30 PM To: freebsd-embedded@freebsd.org ; freebsd-ports@freebsd.org ; = freebsd-hackers@freebsd.org=20 Subject: my work on cross-build for mips, arm, etc - your help, please! I was just going to continuing hacking away at this but adri was really = keen that i post this stuff.. So far with what i=E2=80=99ve got I can cross-build just about anything, = but it=E2=80=99s not automated, there is issues with finding and = building dependencies. i=E2=80=99m using XDEV as the cross compiler a command line such as=20 env TARGET=3Dmips TARGET_ARCH=3Dmips make _TARGET_CROSS_DEFS=3D = =E2=80=93C /usr/ports/net/asterisk10 all should get the ball rolling From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 12:47:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 123F8405; Tue, 13 Nov 2012 12:47:30 +0000 (UTC) (envelope-from masked@internode.on.net) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by mx1.freebsd.org (Postfix) with ESMTP id 0FD1B8FC08; Tue, 13 Nov 2012 12:47:28 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQJABFAolCWZd2M/2dsb2JhbABEhhq8WgOCBYIeAQEBBAEBAQUbDwEFFiAWAQQFAwMRBAEBAwImAgInAQkeCAYBBwcEAQcJDASHaAyncoI9kDSBIop/GoEFhCIyYQONdIVbg0mPJ4MDgVA Received: from ppp221-140.static.internode.on.net (HELO forexamplePC) ([150.101.221.140]) by ipmail07.adl2.internode.on.net with SMTP; 13 Nov 2012 23:17:27 +1030 Message-ID: <3C014C6EE9954A44B8261F6CBD94C838@forexamplePC> From: "Michael Vale" To: , , References: <0728FA19E18F48E89964934E5FCA5A4B@forexamplePC> In-Reply-To: <0728FA19E18F48E89964934E5FCA5A4B@forexamplePC> Subject: Re: my work on cross-build for mips, arm, etc - your help, please! Date: Tue, 13 Nov 2012 23:47:29 +1100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3505.912 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3505.912 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 12:47:30 -0000 you might find some more success with this: make _TARGET_CROSS_DEFS= LOCALBASE=/usr/obj/mips.mips/rootfs CONFIGURE_HOST=mips-freebsd LIBTOOL=/usr/local/bin/libtool all sorry about all the mess! i'm sure most of you out there will be able to decifer it! -----Original Message----- From: Michael Vale Sent: Tuesday, November 13, 2012 11:31 PM To: freebsd-embedded@freebsd.org ; freebsd-ports@freebsd.org ; freebsd-hackers@freebsd.org Subject: Re: my work on cross-build for mips, arm, etc - your help, please! P.S. some of the ${DESTDIR} things i added can be removed!!! From: Michael Vale Sent: Tuesday, November 13, 2012 11:30 PM To: freebsd-embedded@freebsd.org ; freebsd-ports@freebsd.org ; freebsd-hackers@freebsd.org Subject: my work on cross-build for mips, arm, etc - your help, please! I was just going to continuing hacking away at this but adri was really keen that i post this stuff.. So far with what i’ve got I can cross-build just about anything, but it’s not automated, there is issues with finding and building dependencies. i’m using XDEV as the cross compiler a command line such as env TARGET=mips TARGET_ARCH=mips make _TARGET_CROSS_DEFS= –C /usr/ports/net/asterisk10 all should get the ball rolling _______________________________________________ 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 Tue Nov 13 14:33:16 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C60D038A for ; Tue, 13 Nov 2012 14:33:16 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 7E5CE8FC14 for ; Tue, 13 Nov 2012 14:33:14 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id qADEX6NN043579; Tue, 13 Nov 2012 07:33:06 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id qADEX6U7043576; Tue, 13 Nov 2012 07:33:06 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 13 Nov 2012 07:33:06 -0700 (MST) From: Warren Block To: Eitan Adler Subject: Re: Give users a hint when their locate database is too small. In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 13 Nov 2012 07:33:06 -0700 (MST) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 14:33:16 -0000 On Mon, 12 Nov 2012, Eitan Adler wrote: > What do people think of this? Maybe /usr/libexec/locate.updatedb is a > better pointer? > > commit fb03b777daf2c69bb9612902e38fdb25b256be72 > Author: Eitan Adler > Date: Mon Nov 12 22:05:55 2012 -0500 > > Give users a hint when their locate database is too small. > > Reviwed by: ??? > Approved by: ??? > MFC after: 3 weeks > > diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/locate.c > index b0faefb..f0c8c37 100644 > --- a/usr.bin/locate/locate/locate.c > +++ b/usr.bin/locate/locate/locate.c > @@ -292,7 +292,7 @@ search_mmap(db, s) > err(1, "`%s'", db); > len = sb.st_size; > if (len < (2*NBG)) > - errx(1, "database too small: %s", db); > + errx(1, "database too small: %s\nTry running /etc/periodic/weekly/310.locate", db); > > if ((p = mmap((caddr_t)0, (size_t)len, > PROT_READ, MAP_SHARED, > Don't use the unsure "try", just say "Run /etc/periodic/weekly/310.locate". And hope it doesn't get renumbered. From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 15:55:34 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 654A1517 for ; Tue, 13 Nov 2012 15:55:34 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id C34A38FC08 for ; Tue, 13 Nov 2012 15:55:33 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so747230lah.13 for ; Tue, 13 Nov 2012 07:55:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=oLQ1npUwCnknzC1bytV28FSMzsyuG9Mk3UvrB5XA/38=; b=QQ4id9AeLqcJG78+lX0/UrAAUZGir8O47j5T770Oe3hlG/VTYuEZXh7Ts2DiIgYMqM oGoE2yNVI4OXDj6jEJN7wV8uXQzJq3mWoAa85NfnYMqr3893JCC1etcO8d2F4RMLLoYR tqCRn/gL9+TeTivFoOEMUMVwZQPT5HHOVRfV0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=oLQ1npUwCnknzC1bytV28FSMzsyuG9Mk3UvrB5XA/38=; b=XvYkKPI5MNCFGdGqjsis0OQyh2iFeN3GOmJAsxbCNMsNLFDxyhJwTstXm9Vj1ChE3v UerxiH+PYS7dXEZy4T8ZuevefjAbtADhvu1Vou+v5E+7YvLupvNl+7ivIeclbBVASr5u /ITMfWlKwkFHbN/O4KhY7wNZJRSKwEBKxVVLa3zOF88LoJZpshmZeFfoyNBtCt05MEAM tDw6iuatuemr8m/piPZ4UMxZmqOAC1vKs0Pnr9gqErg7Zi3EeK8Puiv3oe6f324x3irH rVtxi6b3sAydo/hss2IabgN982/QIh33vVzhkoplvqtn6tIhlC4EW0F9fufsQMChl845 7Awg== Received: by 10.112.100.102 with SMTP id ex6mr9655237lbb.130.1352822132425; Tue, 13 Nov 2012 07:55:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.166 with HTTP; Tue, 13 Nov 2012 07:55:02 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Tue, 13 Nov 2012 10:55:02 -0500 Message-ID: Subject: Re: Give users a hint when their locate database is too small. To: Warren Block Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQnANtCs7s/t/wFKJYwLSVGyUbkD977xxo57Djr18meGzRNRWp4bDKEqU1rMJxk7JvuLILvj Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:55:34 -0000 On 13 November 2012 09:33, Warren Block wrote: ... Ack to all. Final patch sent for approval: commit 33ed38e54bf7c7c5f0531afa5501f501e1a67279 Author: Eitan Adler Date: Mon Nov 12 22:05:55 2012 -0500 Give users a hint when their locate database is too small. Reviwed by: wblock Reviewed by: gcooper Reviwed by: "Lowell Gilbert" Approved by: cperciva MFC after: 3 weeks diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/locate.c index b0faefb..95b3fed 100644 --- a/usr.bin/locate/locate/locate.c +++ b/usr.bin/locate/locate/locate.c @@ -292,7 +292,7 @@ search_mmap(db, s) err(1, "`%s'", db); len = sb.st_size; if (len < (2*NBG)) - errx(1, "database too small: %s", db); + errx(1, "database too small: %s\nRun /usr/libexec/locate.updatedb", db); if ((p = mmap((caddr_t)0, (size_t)len, PROT_READ, MAP_SHARED, -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 15:58:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7A5B279D for ; Tue, 13 Nov 2012 15:58:46 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id E3A058FC19 for ; Tue, 13 Nov 2012 15:58:45 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2435942lbb.13 for ; Tue, 13 Nov 2012 07:58:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=vmqbsQUPXOF1DzYTV25zGFEB81EJXe2mn2mRlYgZblQ=; b=JSU5QdacX7QNGbMWh555Q+Y8C/JC/Zn3ZVDNwCk+yPdMadZtyadK6KD2V+WXaHjb4L 7UuPnpIvtW8uJri3ZO07491d1PkX73V5BiCy6A3seRs2SgUwbSVVKzOp9npWV+Hf8EcC sVuq97Kdgwk+m/f8/CALK1xUqnRjhV8CLE8yM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=vmqbsQUPXOF1DzYTV25zGFEB81EJXe2mn2mRlYgZblQ=; b=Hnrp+LRoIZAARFSGv5Bw/aIEk205eEy8OmRZhBgu1+OuEbbJ3ht5xoxNjO4jMcLelp PcSTkZl5KpXXjfvb7iP39lfzZaaO+VFXGqIreVFT5sHq4ZvAvpZnyjmT+KQseBt/alQ5 QXPlIwOpy3xppoMxfmG4HvL2fuO5ppTP9GAsBS7zyFRrKpMzRvRdk4jIGSDjTRK66oqF pZ5BD2of5W9RWy7ugGYlpag5prYrzXFqsMNTR6T5Z+HeZfc8+l9JJAblG3yAgfelUJCA WgtQal79awdVE5On+9cuu3oxX3ukrDcUHvB7VPTjM/KDiSK4YrTBqnWs9NqrODNQiBqx UfWQ== Received: by 10.112.85.199 with SMTP id j7mr9445324lbz.69.1352822325431; Tue, 13 Nov 2012 07:58:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.166 with HTTP; Tue, 13 Nov 2012 07:58:12 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Tue, 13 Nov 2012 10:58:12 -0500 Message-ID: Subject: Re: Give users a hint when their locate database is too small. To: Warren Block Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmHPSXP1Q+osEMBuNIR+gluCS/s737UoDIA5Y6rWFJ7X67WigQSyFATt141C0EE9yUtE+t1 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:58:46 -0000 On 13 November 2012 10:55, Eitan Adler wrote: > On 13 November 2012 09:33, Warren Block wrote: > ... > > Ack to all. Final patch sent for approval: > > commit 33ed38e54bf7c7c5f0531afa5501f501e1a67279 > Author: Eitan Adler > Date: Mon Nov 12 22:05:55 2012 -0500 > > Give users a hint when their locate database is too small. > > Reviwed by: wblock > Reviewed by: gcooper > Reviwed by: "Lowell Gilbert" with these typos fixed ;) -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 16:05:50 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 57571A5D for ; Tue, 13 Nov 2012 16:05:50 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id B648C8FC17 for ; Tue, 13 Nov 2012 16:05:49 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2445860lbb.13 for ; Tue, 13 Nov 2012 08:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uazUVrcNFq7ANLsm/fZzkdjvchLFFriVKFpzBqJvLdI=; b=rH1V4414yIR3jaFBelFT13eM/PNA9HaMC6cPjnzO7ipG7eC9UW028PWe5RykGZIV/v P7RtffGqC0ev/df19arP4qErMNOWk8oi1U3siTYFqUUaW0z8OufhpEJ6ZYz9O+Ezj1h8 TUVvTcPyLqNlq60pEaOI0pFUBeNmxs/XXob68= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=uazUVrcNFq7ANLsm/fZzkdjvchLFFriVKFpzBqJvLdI=; b=L+GnaFAa4Hex7mXmDnS7OwkKuycy58WMyEhC7lt9OdbRhCVYN4goa7su21g+YZQeM8 CT78EXFu4NFRgCczZmJBhpw0V3mCj0216/COph1kjup6axVMYfwgITWZWejv6u8QFRpX EoRBfX8grmzQaI9C8hkzpK8UdlplQ2kfu6i8tXLaDu4WMKrQAfsYCk3N2bR0YQ6LqLIF 0Ul7YEY0DhyO+ypwuob8FezwCGnWSkuffRs8uhT4V+Qu9Sm6gq8HKpxguxKCWMdczhkm 4urMBLdGZc3d/Qd+8eiXL7HDVJ6uU/t8cJz92jf2zjhuA4co102TGrQp9exe+DS1yVll 0N6w== Received: by 10.152.104.148 with SMTP id ge20mr21619446lab.51.1352822748505; Tue, 13 Nov 2012 08:05:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.166 with HTTP; Tue, 13 Nov 2012 08:05:17 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Tue, 13 Nov 2012 11:05:17 -0500 Message-ID: Subject: Re: Give users a hint when their locate database is too small. To: Warren Block Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmKRsovTwGqRlFb09LGP7AALwMxuRWbi0aLi//83brlzaF6W9bon5i9+XeDpPsGyELtLnKN Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 16:05:50 -0000 On 13 November 2012 10:58, Eitan Adler wrote: Okay... sorry for the spam. I remember there was a reason I used /etc/periodic/weekly/310.locate instead of /usr/libexec/locate.updatedb. The latter must not be run as root, and the former takes care of this work. Since the default is to enable weekly updates I am inclined to use the 310.locate script instead. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 16:10:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EBAC6B81 for ; Tue, 13 Nov 2012 16:10:26 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 6ECAF8FC13 for ; Tue, 13 Nov 2012 16:10:26 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qADGAPTP053452 for ; Tue, 13 Nov 2012 09:10:25 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qADGAM93022575; Tue, 13 Nov 2012 09:10:22 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: Give users a hint when their locate database is too small. From: Ian Lepore To: Eitan Adler In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Tue, 13 Nov 2012 09:10:22 -0700 Message-ID: <1352823022.1217.109.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 16:10:27 -0000 On Tue, 2012-11-13 at 11:05 -0500, Eitan Adler wrote: > On 13 November 2012 10:58, Eitan Adler wrote: > > Okay... sorry for the spam. I remember there was a reason I used > /etc/periodic/weekly/310.locate instead of /usr/libexec/locate.updatedb. > The latter must not be run as root, and the former takes care of this work. > > Since the default is to enable weekly updates I am inclined to use the > 310.locate script instead. > > > Would it work to refer them to the locate.updatedb manpage (which references the periodic script, and presumably would be kept up to date with any script renaming/numbering)? -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 16:14:44 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D392DCEC for ; Tue, 13 Nov 2012 16:14:44 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3EA738FC0C for ; Tue, 13 Nov 2012 16:14:43 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so770923lah.13 for ; Tue, 13 Nov 2012 08:14:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2trL210CGxyp9kO7SHlFvRhd8CywWa2hW6ECr4tTkLk=; b=an/1X5P30X8NQ4Hr4FOaSMqhwgm+nCqdz4CMqLlUqggUnxQ1I/LSZaocReswb0xFpe KTTOWQnVskX2K4Pa6UAjl7dnzAwmpQ3669xMXoSMfBpZEnsJ8a21+08ql6foXDRLwIbZ CywQT/m1SCzY7ke1JeeNhkQIi7f3jwjCwXvzs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=2trL210CGxyp9kO7SHlFvRhd8CywWa2hW6ECr4tTkLk=; b=YBt7wORHYTi3NVRdNixv7GLR80wzGZ81Gb+7Hc+0AXA/5uM/4Lbli4Z9x3bVU3AVxd uYwfgP6O7uTU4YE4w7GyVJOUOqjvtfWkbTfiCmshrWfv4y7RM+/jlna+PnecUB5RlsTP 5OuD16rKW1QFg8pPbEGfaqbE+uXtze+fNDPcTOYBZ2Y2ganucn+VErIYOzlBlh4Xcoze fNrav9fVDlHyUx4Wf7VIRJKzfnFL72w7y2FXvmBPwWkdGJDCqsy3q2CMy4JSNaTgDlWt QVAC5S8FQl3BWjYRRXcg09AB3HQ6kYeBh5JhFsq5Vg7vqbzkakChl+EBKd21lom5t8KA cvOg== Received: by 10.152.144.70 with SMTP id sk6mr8135043lab.27.1352823281712; Tue, 13 Nov 2012 08:14:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.166 with HTTP; Tue, 13 Nov 2012 08:14:11 -0800 (PST) In-Reply-To: <1352823022.1217.109.camel@revolution.hippie.lan> References: <1352823022.1217.109.camel@revolution.hippie.lan> From: Eitan Adler Date: Tue, 13 Nov 2012 11:14:11 -0500 Message-ID: Subject: Re: Give users a hint when their locate database is too small. To: Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmSnTOnN6aWiEFptWag9h/ErK7AiLhUpgNgi4nTYZyFAwIJ2eump+Pa5Fwi5/pMSpTTvv6l Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 16:14:44 -0000 On 13 November 2012 11:10, Ian Lepore wrote: > Would it work to refer them to the locate.updatedb manpage (which > references the periodic script, and presumably would be kept up to date > with any script renaming/numbering)? If I could avoid the indirection I'd like to avoid it. "Do this" is more helpful than "See this which tells you what to do." -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 16:15:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 76935DDE for ; Tue, 13 Nov 2012 16:15:40 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3E4F58FC15 for ; Tue, 13 Nov 2012 16:15:39 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so631436pab.13 for ; Tue, 13 Nov 2012 08:15:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=D0EcgEuKNekLO7gkrS/4Ds5C4/IwzJBdR48+K39aMBs=; b=SwHeepag0mzjWBUlQNTPkXY1AWXMOZZwKVkKDlFA2zz5l9ZNyK96yBwL4E3GiFPpEd hKrbn5wkMus914zUpCbigzFIzQUi6V7X0s3UTx0cXvgIBPEAXWCT2oqA8TWBYttS3x6b YNiXTAn3CLJAxYXcZy6hzJLCoby9mg0sBC3FTW9KtJTcUQ0n+nDNFPOKtGlzkOvPDo5S LM4MsksNSDr0aQbIqsK8JpeNew4YP2DyVvxrrWoqILMIw2SRFSlwD8WsRJjTJiLvT+ck lIT15ZQLm4in3Eg8sGP/wD0lpYf5Y1wcRWR8sU9URhpPrAWnYLmVwBZHwfpGsoZX5QVi geig== Received: by 10.66.72.136 with SMTP id d8mr65748941pav.4.1352823339617; Tue, 13 Nov 2012 08:15:39 -0800 (PST) Received: from [192.168.20.12] (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id uq5sm6161024pbc.56.2012.11.13.08.15.36 (version=SSLv3 cipher=OTHER); Tue, 13 Nov 2012 08:15:37 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A523) From: Garrett Cooper Subject: Re: Give users a hint when their locate database is too small. Date: Tue, 13 Nov 2012 08:15:36 -0800 To: Eitan Adler Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 16:15:40 -0000 On Nov 13, 2012, at 8:05 AM, Eitan Adler wrote: > On 13 November 2012 10:58, Eitan Adler wrote: >=20 > Okay... sorry for the spam. I remember there was a reason I used > /etc/periodic/weekly/310.locate instead of /usr/libexec/locate.updatedb. > The latter must not be run as root, and the former takes care of this work= . >=20 > Since the default is to enable weekly updates I am inclined to use the > 310.locate script instead. Ok. The only thing about hardcoding an=20 RC script name into a binary is that I felt it was more likely to change whe= reas locate.updatedb is more constant.. Thanks! -Garrett= From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 14:27:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A4A48F65 for ; Tue, 13 Nov 2012 14:27:55 +0000 (UTC) (envelope-from lgusenet@be-well.ilk.org) Received: from asbnvacz-mailrelay01.megapath.net (asbnvacz-mailrelay01.megapath.net [207.145.128.243]) by mx1.freebsd.org (Postfix) with ESMTP id 602B28FC08 for ; Tue, 13 Nov 2012 14:27:55 +0000 (UTC) Received: from mail8.sea5.speakeasy.net (mail8.sea5.speakeasy.net [69.17.117.53]) by asbnvacz-mailrelay01.megapath.net (Postfix) with ESMTP id 7A610A72EE9 for ; Tue, 13 Nov 2012 09:05:53 -0500 (EST) Received: (qmail 29114 invoked from network); 13 Nov 2012 14:05:53 -0000 Received: by simscan 1.4.0 ppid: 24614, pid: 4456, t: 0.1763s scanners: clamav: 0.88.2/m:52/d:13495 Received: from unknown (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail8.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 13 Nov 2012 14:05:52 -0000 Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.8]) by be-well.ilk.org (Postfix) with ESMTP id 45BFF33C23; Tue, 13 Nov 2012 09:05:47 -0500 (EST) Received: by lowell-desk.lan (Postfix, from userid 1147) id E8A5439843; Tue, 13 Nov 2012 09:05:46 -0500 (EST) From: Lowell Gilbert To: Eitan Adler , freebsd-hackers@freebsd.org Subject: Re: Give users a hint when their locate database is too small. References: Date: Tue, 13 Nov 2012 09:05:46 -0500 In-Reply-To: (Eitan Adler's message of "Mon, 12 Nov 2012 22:07:16 -0500") Message-ID: <44wqxpegxx.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Tue, 13 Nov 2012 17:20:29 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 14:27:55 -0000 Eitan Adler writes: > What do people think of this? Maybe /usr/libexec/locate.updatedb is a > better pointer? Yes, I would think locate.updatedb(8) would be the appropriate reference, because it's possible to build locate databases in ways and for reasons other than the weekly script. I assume that the precise cutoff value is chosen not because the number of bigrams is important but because the size of the bigram buffer is, and that it's only notated as (2*NBG) because BGBUFSIZE isn't defined in a header... > commit fb03b777daf2c69bb9612902e38fdb25b256be72 > Author: Eitan Adler > Date: Mon Nov 12 22:05:55 2012 -0500 > > Give users a hint when their locate database is too small. > > Reviwed by: ??? > Approved by: ??? > MFC after: 3 weeks > > diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/locate.c > index b0faefb..f0c8c37 100644 > --- a/usr.bin/locate/locate/locate.c > +++ b/usr.bin/locate/locate/locate.c > @@ -292,7 +292,7 @@ search_mmap(db, s) > err(1, "`%s'", db); > len = sb.st_size; > if (len < (2*NBG)) > - errx(1, "database too small: %s", db); > + errx(1, "database too small: %s\nTry running > /etc/periodic/weekly/310.locate", db); > > if ((p = mmap((caddr_t)0, (size_t)len, > PROT_READ, MAP_SHARED, From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 20:04:05 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAA22994; Tue, 13 Nov 2012 20:04:05 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by mx1.freebsd.org (Postfix) with ESMTP id 833568FC13; Tue, 13 Nov 2012 20:04:05 +0000 (UTC) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 764044C0243; Tue, 13 Nov 2012 14:04:04 -0600 (CST) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id 74D984C0235; Tue, 13 Nov 2012 14:04:04 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from mh11.mail.rice.edu ([127.0.0.1]) by mh11.mail.rice.edu (mh11.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id R8hsA5VhGzKj; Tue, 13 Nov 2012 14:04:04 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id A6BC84C0248; Tue, 13 Nov 2012 14:04:03 -0600 (CST) Message-ID: <50A2A7B2.2020302@rice.edu> Date: Tue, 13 Nov 2012 14:04:02 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: Re: Memory reserves or lack thereof References: <20121110132019.GP73505@kib.kiev.ua> <20121112133638.GZ73505@kib.kiev.ua> <50A1336E.5040401@rice.edu> In-Reply-To: <50A1336E.5040401@rice.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Konstantin Belousov , alc@freebsd.org, mips@freebsd.org, "Sears, Steven" , pho@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 20:04:05 -0000 On 11/12/2012 11:35, Alan Cox wrote: > On 11/12/2012 07:36, Konstantin Belousov wrote: >> On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote: >>> On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov wrote: >>> >>>> On Fri, Nov 09, 2012 at 07:10:04PM +0000, Sears, Steven wrote: >>>>> I have a memory subsystem design question that I'm hoping someone can >>>> answer. >>>>> I've been looking at a machine that is completely out of memory, as in >>>>> >>>>> v_free_count = 0, >>>>> v_cache_count = 0, >>>>> >>>>> I wondered how a machine could completely run out of memory like this, >>>> especially after finding a lack of interrupt storms or other pathologies >>>> that would tend to overcommit memory. So I started investigating. >>>>> Most allocators come down to vm_page_alloc(), which has this guard: >>>>> >>>>> if ((curproc == pageproc) && (page_req != VM_ALLOC_INTERRUPT)) { >>>>> page_req = VM_ALLOC_SYSTEM; >>>>> }; >>>>> >>>>> if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved || >>>>> (page_req == VM_ALLOC_SYSTEM && >>>>> cnt.v_free_count + cnt.v_cache_count > >>>> cnt.v_interrupt_free_min) || >>>>> (page_req == VM_ALLOC_INTERRUPT && >>>>> cnt.v_free_count + cnt.v_cache_count > 0)) { >>>>> >>>>> The key observation is if VM_ALLOC_INTERRUPT is set, it will allocate >>>> every last page. >>>>> >From the name one might expect VM_ALLOC_INTERRUPT to be somewhat rare, >>>> perhaps only used from interrupt threads. Not so, see kmem_malloc() or >>>> uma_small_alloc() which both contain this mapping: >>>>> if ((flags & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>>>> pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >>>>> else >>>>> pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >>>>> >>>>> Note that M_USE_RESERVE has been deprecated and is used in just a >>>> handful of places. Also note that lots of code paths come through these >>>> routines. >>>>> What this means is essentially _any_ allocation using M_NOWAIT will >>>> bypass whatever reserves have been held back and will take every last page >>>> available. >>>>> There is no documentation stating M_NOWAIT has this side effect of >>>> essentially being privileged, so any innocuous piece of code that can't >>>> block will use it. And of course M_NOWAIT is literally used all over. >>>>> It looks to me like the design goal of the BSD allocators is on >>>> recovery; it will give all pages away knowing it can recover. >>>>> Am I missing anything? I would have expected some small number of pages >>>> to be held in reserve just in case. And I didn't expect M_NOWAIT to be a >>>> sort of back door for grabbing memory. >>>> Your analysis is right, there is nothing to add or correct. >>>> This is the reason to strongly prefer M_WAITOK. >>>> >>> Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was >>> well understand that it should only be used by interrupt handlers. >>> >>> The trouble is that M_NOWAIT conflates two orthogonal things. The obvious >>> being that the allocation shouldn't sleep. The other being how far we're >>> willing to deplete the cache/free page queues. >>> >>> When fine-grained locking got sprinkled throughout the kernel, we all to >>> often found ourselves wanting to do allocations without the possibility of >>> blocking. So, M_NOWAIT became commonplace, where it wasn't before. >>> >>> This had the unintended consequence of introducing a lot of memory >>> allocations in the top-half of the kernel, i.e., non-interrupt handling >>> code, that were digging deep into the cache/free page queues. >>> >>> Also, ironically, in today's kernel an "M_NOWAIT | M_USE_RESERVE" >>> allocation is less likely to succeed than an "M_NOWAIT" allocation. >>> However, prior to FreeBSD 7.x, M_NOWAIT couldn't allocate a cached page; it >>> could only allocate a free page. M_USE_RESERVE said that it ok to allocate >>> a cached page even though M_NOWAIT was specified. Consequently, the system >>> wouldn't dig as far into the free page queue if M_USE_RESERVE was >>> specified, because it was allowed to reclaim a cached page. >>> >>> In conclusion, I think it's time that we change M_NOWAIT so that it doesn't >>> dig any deeper into the cache/free page queues than M_WAITOK does and >>> reintroduce a M_USE_RESERVE-like flag that says dig deep into the >>> cache/free page queues. The trouble is that we then need to identify all >>> of those places that are implicitly depending on the current behavior of >>> M_NOWAIT also digging deep into the cache/free page queues so that we can >>> add an explicit M_USE_RESERVE. >>> >>> Alan >>> >>> P.S. I suspect that we should also increase the size of the "page reserve" >>> that is kept for VM_ALLOC_INTERRUPT allocations in vm_page_alloc*(). How >>> many legitimate users of a new M_USE_RESERVE-like flag in today's kernel >>> could actually be satisfied by two pages? >> I am almost sure that most of people who put the M_NOWAIT flag, do not >> know the 'allow the deeper drain of free queue' effect. As such, I believe >> we should flip the meaning of M_NOWAIT/M_USE_RESERVE. My only expectations >> of the problematic places would be in the swapout path. >> >> I found a single explicit use of M_USE_RESERVE in the kernel, >> so the flip is relatively simple. > Agreed. Most recently I eliminated several uses from the arm pmap > implementations. There is, however, one other use: > > ofed/include/linux/gfp.h:#define GFP_ATOMIC (M_NOWAIT | > M_USE_RESERVE) > >> Below is the patch which I only compile-tested on amd64, and which booted >> fine. >> >> Peter, could you, please, give it a run, to see obvious deadlocks, if any ? >> >> diff --git a/sys/amd64/amd64/uma_machdep.c b/sys/amd64/amd64/uma_machdep.c >> index dc9c307..ab1e869 100644 >> --- a/sys/amd64/amd64/uma_machdep.c >> +++ b/sys/amd64/amd64/uma_machdep.c >> @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$"); >> >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -48,12 +49,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >> int pflags; >> >> *flags = UMA_SLAB_PRIV; >> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >> - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; >> - else >> - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; >> - if (wait & M_ZERO) >> - pflags |= VM_ALLOC_ZERO; >> + pflags = m2vm_flags(wait, VM_ALLOC_NOOBJ | VM_ALLOC_WIRED); >> for (;;) { >> m = vm_page_alloc(NULL, 0, pflags); >> if (m == NULL) { >> diff --git a/sys/arm/arm/vm_machdep.c b/sys/arm/arm/vm_machdep.c >> index f60cdb1..75366e3 100644 >> --- a/sys/arm/arm/vm_machdep.c >> +++ b/sys/arm/arm/vm_machdep.c >> @@ -651,12 +651,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >> ret = ((void *)kmem_malloc(kmem_map, bytes, M_NOWAIT)); >> return (ret); >> } >> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >> - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >> - else >> - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >> - if (wait & M_ZERO) >> - pflags |= VM_ALLOC_ZERO; >> + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); >> for (;;) { >> m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); >> if (m == NULL) { >> diff --git a/sys/fs/devfs/devfs_devs.c b/sys/fs/devfs/devfs_devs.c >> index 71caa29..2ce1ca6 100644 >> --- a/sys/fs/devfs/devfs_devs.c >> +++ b/sys/fs/devfs/devfs_devs.c >> @@ -121,7 +121,7 @@ devfs_alloc(int flags) >> struct cdev *cdev; >> struct timespec ts; >> >> - cdp = malloc(sizeof *cdp, M_CDEVP, M_USE_RESERVE | M_ZERO | >> + cdp = malloc(sizeof *cdp, M_CDEVP, M_ZERO | >> ((flags & MAKEDEV_NOWAIT) ? M_NOWAIT : M_WAITOK)); >> if (cdp == NULL) >> return (NULL); >> diff --git a/sys/ia64/ia64/uma_machdep.c b/sys/ia64/ia64/uma_machdep.c >> index 37353ff..9f77762 100644 >> --- a/sys/ia64/ia64/uma_machdep.c >> +++ b/sys/ia64/ia64/uma_machdep.c >> @@ -46,12 +46,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >> int pflags; >> >> *flags = UMA_SLAB_PRIV; >> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >> - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >> - else >> - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >> - if (wait & M_ZERO) >> - pflags |= VM_ALLOC_ZERO; >> + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); >> >> for (;;) { >> m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); >> diff --git a/sys/mips/mips/uma_machdep.c b/sys/mips/mips/uma_machdep.c >> index 798e632..24baef0 100644 >> --- a/sys/mips/mips/uma_machdep.c >> +++ b/sys/mips/mips/uma_machdep.c >> @@ -48,11 +48,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >> void *va; >> >> *flags = UMA_SLAB_PRIV; >> - >> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >> - pflags = VM_ALLOC_INTERRUPT; >> - else >> - pflags = VM_ALLOC_SYSTEM; >> + pflags = m2vm_flags(wait, 0); >> >> for (;;) { >> m = pmap_alloc_direct_page(0, pflags); > > This smells fishy, but not because of anything that you did. It appears > that the mips uma_small_alloc() is unconditionally asking for a > pre-zeroed page. I'll take a look at this later today. > I verified this. The current implementation of uma_small_alloc() on MIPS unconditionally zeroes the page. Moreover, if M_ZERO is specified to uma_small_alloc(), the same page is zeroed twice, once in pmap_alloc_direct_page() and again in uma_small_alloc(). I expect to commit the following patch tomorrow. Kostik, it will trivially conflict with your current patch. Index: mips/include/pmap.h =================================================================== --- mips/include/pmap.h (revision 242939) +++ mips/include/pmap.h (working copy) @@ -179,7 +179,6 @@ void pmap_kenter_temporary_free(vm_paddr_t pa); void pmap_flush_pvcache(vm_page_t m); int pmap_emulate_modified(pmap_t pmap, vm_offset_t va); void pmap_grow_direct_page_cache(void); -vm_page_t pmap_alloc_direct_page(unsigned int index, int req); #endif /* _KERNEL */ Index: mips/mips/pmap.c =================================================================== --- mips/mips/pmap.c (revision 242939) +++ mips/mips/pmap.c (working copy) @@ -163,6 +163,7 @@ static vm_page_t pmap_pv_reclaim(pmap_t locked_pma static void pmap_pvh_free(struct md_page *pvh, pmap_t pmap, vm_offset_t va); static pv_entry_t pmap_pvh_remove(struct md_page *pvh, pmap_t pmap, vm_offset_t va); +static vm_page_t pmap_alloc_direct_page(unsigned int index, int req); static vm_page_t pmap_enter_quick_locked(pmap_t pmap, vm_offset_t va, vm_page_t m, vm_prot_t prot, vm_page_t mpte); static int pmap_remove_pte(struct pmap *pmap, pt_entry_t *ptq, vm_offset_t va, @@ -1041,7 +1042,7 @@ pmap_grow_direct_page_cache() #endif } -vm_page_t +static vm_page_t pmap_alloc_direct_page(unsigned int index, int req) { vm_page_t m; Index: mips/mips/uma_machdep.c =================================================================== --- mips/mips/uma_machdep.c (revision 242939) +++ mips/mips/uma_machdep.c (working copy) @@ -50,12 +50,14 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8 *flags = UMA_SLAB_PRIV; if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) - pflags = VM_ALLOC_INTERRUPT; + pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; else - pflags = VM_ALLOC_SYSTEM; + pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; + if (wait & M_ZERO) + pflags |= VM_ALLOC_ZERO; for (;;) { - m = pmap_alloc_direct_page(0, pflags); + m = vm_page_alloc_freelist(VM_FREELIST_DIRECT, pflags); if (m == NULL) { if (wait & M_NOWAIT) return (NULL); From owner-freebsd-hackers@FreeBSD.ORG Tue Nov 13 20:13:34 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 94E9BCC8; Tue, 13 Nov 2012 20:13:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4AEBB8FC0C; Tue, 13 Nov 2012 20:13:33 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so630637pbc.13 for ; Tue, 13 Nov 2012 12:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=wq/D18NoN540dXG/FHe9zJ/s/tZTkAqFfgiIMuVlh5A=; b=vpwlU6W0rjw/fBtbwY7q+1vuKPf9zu1DPnC0qkvmnax1ZQpNwSVtuj8aIl5570vXlK SbaH8hUCnzzTHvCoZzZi2lah7LHreBVbyToFeqLXg7yCV0K/JICS1r8/BaqXcRguj+tM Zh3lYRKzn8k/UqdJ90yj425QxzZ04QboJj/ctYuPU2h4pXBXEYf+2t3WH8nGdv21bXZk g/48MaujUfVs6qGnHC+yyEr+J+vTCWYa6cL00aZd5BHQZNP+izltzIfKSbMiKyUo8sQH /c8PjSptFMgCenKGC44+ictnG07KGMgogNEhiLQ4uCwSiaW69TpRvyzgAynywmGvZgtT PPhw== MIME-Version: 1.0 Received: by 10.68.238.199 with SMTP id vm7mr69602826pbc.105.1352837613714; Tue, 13 Nov 2012 12:13:33 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Tue, 13 Nov 2012 12:13:33 -0800 (PST) In-Reply-To: <50A2A7B2.2020302@rice.edu> References: <20121110132019.GP73505@kib.kiev.ua> <20121112133638.GZ73505@kib.kiev.ua> <50A1336E.5040401@rice.edu> <50A2A7B2.2020302@rice.edu> Date: Tue, 13 Nov 2012 12:13:33 -0800 X-Google-Sender-Auth: pZCrI_8vcUeb_JQ2fymMp9GLB-Y Message-ID: Subject: Re: Memory reserves or lack thereof From: Adrian Chadd To: Alan Cox Content-Type: text/plain; charset=ISO-8859-1 Cc: mips@freebsd.org, "Sears, Steven" , alc@freebsd.org, "freebsd-hackers@freebsd.org" , pho@freebsd.org, Konstantin Belousov X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 20:13:34 -0000 Hey, great catch! adrian On 13 November 2012 12:04, Alan Cox wrote: > On 11/12/2012 11:35, Alan Cox wrote: >> On 11/12/2012 07:36, Konstantin Belousov wrote: >>> On Sun, Nov 11, 2012 at 03:40:24PM -0600, Alan Cox wrote: >>>> On Sat, Nov 10, 2012 at 7:20 AM, Konstantin Belousov wrote: >>>> >>>>> On Fri, Nov 09, 2012 at 07:10:04PM +0000, Sears, Steven wrote: >>>>>> I have a memory subsystem design question that I'm hoping someone can >>>>> answer. >>>>>> I've been looking at a machine that is completely out of memory, as in >>>>>> >>>>>> v_free_count = 0, >>>>>> v_cache_count = 0, >>>>>> >>>>>> I wondered how a machine could completely run out of memory like this, >>>>> especially after finding a lack of interrupt storms or other pathologies >>>>> that would tend to overcommit memory. So I started investigating. >>>>>> Most allocators come down to vm_page_alloc(), which has this guard: >>>>>> >>>>>> if ((curproc == pageproc) && (page_req != VM_ALLOC_INTERRUPT)) { >>>>>> page_req = VM_ALLOC_SYSTEM; >>>>>> }; >>>>>> >>>>>> if (cnt.v_free_count + cnt.v_cache_count > cnt.v_free_reserved || >>>>>> (page_req == VM_ALLOC_SYSTEM && >>>>>> cnt.v_free_count + cnt.v_cache_count > >>>>> cnt.v_interrupt_free_min) || >>>>>> (page_req == VM_ALLOC_INTERRUPT && >>>>>> cnt.v_free_count + cnt.v_cache_count > 0)) { >>>>>> >>>>>> The key observation is if VM_ALLOC_INTERRUPT is set, it will allocate >>>>> every last page. >>>>>> >From the name one might expect VM_ALLOC_INTERRUPT to be somewhat rare, >>>>> perhaps only used from interrupt threads. Not so, see kmem_malloc() or >>>>> uma_small_alloc() which both contain this mapping: >>>>>> if ((flags & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>>>>> pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >>>>>> else >>>>>> pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >>>>>> >>>>>> Note that M_USE_RESERVE has been deprecated and is used in just a >>>>> handful of places. Also note that lots of code paths come through these >>>>> routines. >>>>>> What this means is essentially _any_ allocation using M_NOWAIT will >>>>> bypass whatever reserves have been held back and will take every last page >>>>> available. >>>>>> There is no documentation stating M_NOWAIT has this side effect of >>>>> essentially being privileged, so any innocuous piece of code that can't >>>>> block will use it. And of course M_NOWAIT is literally used all over. >>>>>> It looks to me like the design goal of the BSD allocators is on >>>>> recovery; it will give all pages away knowing it can recover. >>>>>> Am I missing anything? I would have expected some small number of pages >>>>> to be held in reserve just in case. And I didn't expect M_NOWAIT to be a >>>>> sort of back door for grabbing memory. >>>>> Your analysis is right, there is nothing to add or correct. >>>>> This is the reason to strongly prefer M_WAITOK. >>>>> >>>> Agreed. Once upon time, before SMPng, M_NOWAIT was rarely used. It was >>>> well understand that it should only be used by interrupt handlers. >>>> >>>> The trouble is that M_NOWAIT conflates two orthogonal things. The obvious >>>> being that the allocation shouldn't sleep. The other being how far we're >>>> willing to deplete the cache/free page queues. >>>> >>>> When fine-grained locking got sprinkled throughout the kernel, we all to >>>> often found ourselves wanting to do allocations without the possibility of >>>> blocking. So, M_NOWAIT became commonplace, where it wasn't before. >>>> >>>> This had the unintended consequence of introducing a lot of memory >>>> allocations in the top-half of the kernel, i.e., non-interrupt handling >>>> code, that were digging deep into the cache/free page queues. >>>> >>>> Also, ironically, in today's kernel an "M_NOWAIT | M_USE_RESERVE" >>>> allocation is less likely to succeed than an "M_NOWAIT" allocation. >>>> However, prior to FreeBSD 7.x, M_NOWAIT couldn't allocate a cached page; it >>>> could only allocate a free page. M_USE_RESERVE said that it ok to allocate >>>> a cached page even though M_NOWAIT was specified. Consequently, the system >>>> wouldn't dig as far into the free page queue if M_USE_RESERVE was >>>> specified, because it was allowed to reclaim a cached page. >>>> >>>> In conclusion, I think it's time that we change M_NOWAIT so that it doesn't >>>> dig any deeper into the cache/free page queues than M_WAITOK does and >>>> reintroduce a M_USE_RESERVE-like flag that says dig deep into the >>>> cache/free page queues. The trouble is that we then need to identify all >>>> of those places that are implicitly depending on the current behavior of >>>> M_NOWAIT also digging deep into the cache/free page queues so that we can >>>> add an explicit M_USE_RESERVE. >>>> >>>> Alan >>>> >>>> P.S. I suspect that we should also increase the size of the "page reserve" >>>> that is kept for VM_ALLOC_INTERRUPT allocations in vm_page_alloc*(). How >>>> many legitimate users of a new M_USE_RESERVE-like flag in today's kernel >>>> could actually be satisfied by two pages? >>> I am almost sure that most of people who put the M_NOWAIT flag, do not >>> know the 'allow the deeper drain of free queue' effect. As such, I believe >>> we should flip the meaning of M_NOWAIT/M_USE_RESERVE. My only expectations >>> of the problematic places would be in the swapout path. >>> >>> I found a single explicit use of M_USE_RESERVE in the kernel, >>> so the flip is relatively simple. >> Agreed. Most recently I eliminated several uses from the arm pmap >> implementations. There is, however, one other use: >> >> ofed/include/linux/gfp.h:#define GFP_ATOMIC (M_NOWAIT | >> M_USE_RESERVE) >> >>> Below is the patch which I only compile-tested on amd64, and which booted >>> fine. >>> >>> Peter, could you, please, give it a run, to see obvious deadlocks, if any ? >>> >>> diff --git a/sys/amd64/amd64/uma_machdep.c b/sys/amd64/amd64/uma_machdep.c >>> index dc9c307..ab1e869 100644 >>> --- a/sys/amd64/amd64/uma_machdep.c >>> +++ b/sys/amd64/amd64/uma_machdep.c >>> @@ -29,6 +29,7 @@ __FBSDID("$FreeBSD$"); >>> >>> #include >>> #include >>> +#include >>> #include >>> #include >>> #include >>> @@ -48,12 +49,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >>> int pflags; >>> >>> *flags = UMA_SLAB_PRIV; >>> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>> - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; >>> - else >>> - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_NOOBJ | VM_ALLOC_WIRED; >>> - if (wait & M_ZERO) >>> - pflags |= VM_ALLOC_ZERO; >>> + pflags = m2vm_flags(wait, VM_ALLOC_NOOBJ | VM_ALLOC_WIRED); >>> for (;;) { >>> m = vm_page_alloc(NULL, 0, pflags); >>> if (m == NULL) { >>> diff --git a/sys/arm/arm/vm_machdep.c b/sys/arm/arm/vm_machdep.c >>> index f60cdb1..75366e3 100644 >>> --- a/sys/arm/arm/vm_machdep.c >>> +++ b/sys/arm/arm/vm_machdep.c >>> @@ -651,12 +651,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >>> ret = ((void *)kmem_malloc(kmem_map, bytes, M_NOWAIT)); >>> return (ret); >>> } >>> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>> - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >>> - else >>> - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >>> - if (wait & M_ZERO) >>> - pflags |= VM_ALLOC_ZERO; >>> + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); >>> for (;;) { >>> m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); >>> if (m == NULL) { >>> diff --git a/sys/fs/devfs/devfs_devs.c b/sys/fs/devfs/devfs_devs.c >>> index 71caa29..2ce1ca6 100644 >>> --- a/sys/fs/devfs/devfs_devs.c >>> +++ b/sys/fs/devfs/devfs_devs.c >>> @@ -121,7 +121,7 @@ devfs_alloc(int flags) >>> struct cdev *cdev; >>> struct timespec ts; >>> >>> - cdp = malloc(sizeof *cdp, M_CDEVP, M_USE_RESERVE | M_ZERO | >>> + cdp = malloc(sizeof *cdp, M_CDEVP, M_ZERO | >>> ((flags & MAKEDEV_NOWAIT) ? M_NOWAIT : M_WAITOK)); >>> if (cdp == NULL) >>> return (NULL); >>> diff --git a/sys/ia64/ia64/uma_machdep.c b/sys/ia64/ia64/uma_machdep.c >>> index 37353ff..9f77762 100644 >>> --- a/sys/ia64/ia64/uma_machdep.c >>> +++ b/sys/ia64/ia64/uma_machdep.c >>> @@ -46,12 +46,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >>> int pflags; >>> >>> *flags = UMA_SLAB_PRIV; >>> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>> - pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; >>> - else >>> - pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; >>> - if (wait & M_ZERO) >>> - pflags |= VM_ALLOC_ZERO; >>> + pflags = m2vm_flags(wait, VM_ALLOC_WIRED); >>> >>> for (;;) { >>> m = vm_page_alloc(NULL, 0, pflags | VM_ALLOC_NOOBJ); >>> diff --git a/sys/mips/mips/uma_machdep.c b/sys/mips/mips/uma_machdep.c >>> index 798e632..24baef0 100644 >>> --- a/sys/mips/mips/uma_machdep.c >>> +++ b/sys/mips/mips/uma_machdep.c >>> @@ -48,11 +48,7 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8_t *flags, int wait) >>> void *va; >>> >>> *flags = UMA_SLAB_PRIV; >>> - >>> - if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) >>> - pflags = VM_ALLOC_INTERRUPT; >>> - else >>> - pflags = VM_ALLOC_SYSTEM; >>> + pflags = m2vm_flags(wait, 0); >>> >>> for (;;) { >>> m = pmap_alloc_direct_page(0, pflags); >> >> This smells fishy, but not because of anything that you did. It appears >> that the mips uma_small_alloc() is unconditionally asking for a >> pre-zeroed page. I'll take a look at this later today. >> > > I verified this. The current implementation of uma_small_alloc() on > MIPS unconditionally zeroes the page. Moreover, if M_ZERO is specified > to uma_small_alloc(), the same page is zeroed twice, once in > pmap_alloc_direct_page() and again in uma_small_alloc(). > > I expect to commit the following patch tomorrow. Kostik, it will > trivially conflict with your current patch. > > Index: mips/include/pmap.h > =================================================================== > --- mips/include/pmap.h (revision 242939) > +++ mips/include/pmap.h (working copy) > @@ -179,7 +179,6 @@ void pmap_kenter_temporary_free(vm_paddr_t pa); > void pmap_flush_pvcache(vm_page_t m); > int pmap_emulate_modified(pmap_t pmap, vm_offset_t va); > void pmap_grow_direct_page_cache(void); > -vm_page_t pmap_alloc_direct_page(unsigned int index, int req); > > #endif /* _KERNEL */ > > Index: mips/mips/pmap.c > =================================================================== > --- mips/mips/pmap.c (revision 242939) > +++ mips/mips/pmap.c (working copy) > @@ -163,6 +163,7 @@ static vm_page_t pmap_pv_reclaim(pmap_t locked_pma > static void pmap_pvh_free(struct md_page *pvh, pmap_t pmap, vm_offset_t > va); > static pv_entry_t pmap_pvh_remove(struct md_page *pvh, pmap_t pmap, > vm_offset_t va); > +static vm_page_t pmap_alloc_direct_page(unsigned int index, int req); > static vm_page_t pmap_enter_quick_locked(pmap_t pmap, vm_offset_t va, > vm_page_t m, vm_prot_t prot, vm_page_t mpte); > static int pmap_remove_pte(struct pmap *pmap, pt_entry_t *ptq, > vm_offset_t va, > @@ -1041,7 +1042,7 @@ pmap_grow_direct_page_cache() > #endif > } > > -vm_page_t > +static vm_page_t > pmap_alloc_direct_page(unsigned int index, int req) > { > vm_page_t m; > Index: mips/mips/uma_machdep.c > =================================================================== > --- mips/mips/uma_machdep.c (revision 242939) > +++ mips/mips/uma_machdep.c (working copy) > @@ -50,12 +50,14 @@ uma_small_alloc(uma_zone_t zone, int bytes, u_int8 > *flags = UMA_SLAB_PRIV; > > if ((wait & (M_NOWAIT|M_USE_RESERVE)) == M_NOWAIT) > - pflags = VM_ALLOC_INTERRUPT; > + pflags = VM_ALLOC_INTERRUPT | VM_ALLOC_WIRED; > else > - pflags = VM_ALLOC_SYSTEM; > + pflags = VM_ALLOC_SYSTEM | VM_ALLOC_WIRED; > + if (wait & M_ZERO) > + pflags |= VM_ALLOC_ZERO; > > for (;;) { > - m = pmap_alloc_direct_page(0, pflags); > + m = vm_page_alloc_freelist(VM_FREELIST_DIRECT, pflags); > if (m == NULL) { > if (wait & M_NOWAIT) > return (NULL); > > _______________________________________________ > 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 Wed Nov 14 04:15:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 72793814 for ; Wed, 14 Nov 2012 04:15:30 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by mx1.freebsd.org (Postfix) with ESMTP id 19B6A8FC08 for ; Wed, 14 Nov 2012 04:15:29 +0000 (UTC) X-AuditID: 1209190e-b7f756d000000904-b2-50a319afbedd Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 39.95.02308.FA913A05; Tue, 13 Nov 2012 23:10:23 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id qAE4ANDq004867; Tue, 13 Nov 2012 23:10:23 -0500 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id qAE4AL1T020084 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Nov 2012 23:10:22 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id qAE4AKf9028697; Tue, 13 Nov 2012 23:10:20 -0500 (EST) Date: Tue, 13 Nov 2012 23:10:20 -0500 (EST) From: Benjamin Kaduk To: Eitan Adler Subject: Re: Give users a hint when their locate database is too small. In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrbtecnGAwf9PfBbbN/9jtFh0op3J gclj2uaDbB4zPs1nCWCK4rJJSc3JLEst0rdL4Mr4svs6Y8Ee9oobq5awNjBOYuti5OCQEDCR mLbKpIuRE8gUk7hwbz1QmItDSGAfo8Tak+ehnA2MEr8fTGKHcE4wSZy5eogZwmlglJgzrYEd pJ9FQFtiVcclFhCbTUBFYuabjWwgtoiAmsS7192MIOuYBQwlzm3wBwkLC7hLLN3zAKyEUyBQ 4sqpfkYQm1fAQeL5yt1Qm48zSvRf7QWbLyqgI7F6/xQWiCJBiZMzn4DZzAKWEuf+XGebwCg4 C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbrGermZJXqpKaWbGMGhKsm3g/HrQaVD jAIcjEo8vC/qFgUIsSaWFVfmHmKU5GBSEuU9L7o4QIgvKT+lMiOxOCO+qDQntfgQowQHs5II r+VZoHLelMTKqtSifJiUNAeLkjjvlZSb/kIC6YklqdmpqQWpRTBZGQ4OJQnefAmgoYJFqemp FWmZOSUIaSYOTpDhPEDDD4DU8BYXJOYWZ6ZD5E8xKkqJ87aAJARAEhmleXC9sFTyilEc6BVh Xi2QKh5gGoLrfgU0mAlocPJUkKuLSxIRUlINjILCPKskn1VX/TW9J3FAybeX6/QzwR155r0/ upvq2Tjebj2U+ETac5OviGnw79PMR5MrXVzjG1/2bHhTZPB1G6P06mk/RI1mnZyRk3K6b/u6 Gx9nd3J9/CVePGeRXICkYslHjUVPTnt596o0XT9XKmVUlV1vKxixRDBYa5ed19tC6b7XwUdn KbEUZyQaajEXFScCAHD0B34AAwAA Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 04:15:30 -0000 On Tue, 13 Nov 2012, Eitan Adler wrote: > > Ack to all. Final patch sent for approval: > > diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/locate.c > index b0faefb..95b3fed 100644 > --- a/usr.bin/locate/locate/locate.c > +++ b/usr.bin/locate/locate/locate.c > @@ -292,7 +292,7 @@ search_mmap(db, s) > err(1, "`%s'", db); > len = sb.st_size; > if (len < (2*NBG)) > - errx(1, "database too small: %s", db); > + errx(1, "database too small: %s\nRun /usr/libexec/locate.updatedb", db); That looks longer than 80 characters, a limit given implicitly in style.9. -Ben > > if ((p = mmap((caddr_t)0, (size_t)len, > PROT_READ, MAP_SHARED, > > -- > Eitan Adler > _______________________________________________ > 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 Wed Nov 14 08:08:52 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5881AD4B for ; Wed, 14 Nov 2012 08:08:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 8D3278FC0C for ; Wed, 14 Nov 2012 08:08:51 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA18845 for ; Wed, 14 Nov 2012 10:08:50 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TYY1h-000JvG-Pf for freebsd-hackers@FreeBSD.org; Wed, 14 Nov 2012 10:08:49 +0200 Message-ID: <50A3518F.7000707@FreeBSD.org> Date: Wed, 14 Nov 2012 10:08:47 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org Subject: dtrace anonymous tracing X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 08:08:52 -0000 Do we have support for DTrace anonymous tracing (boot-time tracing) on FreeBSD? -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 14 16:32:43 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BBA7522 for ; Wed, 14 Nov 2012 16:32:43 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 211348FC08 for ; Wed, 14 Nov 2012 16:32:42 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id qAEGWemf054206; Wed, 14 Nov 2012 09:32:40 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id qAEGWeQ2054203; Wed, 14 Nov 2012 09:32:40 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Wed, 14 Nov 2012 09:32:40 -0700 (MST) From: Warren Block To: Benjamin Kaduk Subject: Re: Give users a hint when their locate database is too small. In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Wed, 14 Nov 2012 09:32:40 -0700 (MST) Cc: Eitan Adler , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:32:43 -0000 On Tue, 13 Nov 2012, Benjamin Kaduk wrote: >> if (len < (2*NBG)) >> - errx(1, "database too small: %s", db); >> + errx(1, "database too small: %s\nRun /usr/libexec/locate.updatedb", db); > > That looks longer than 80 characters, a limit given implicitly in style.9. There's a \n in there. From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 14 16:35:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64A1474B for ; Wed, 14 Nov 2012 16:35:40 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id C714D8FC12 for ; Wed, 14 Nov 2012 16:35:39 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so634535lah.13 for ; Wed, 14 Nov 2012 08:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AtcjBqELp1Ny7l+2d2Kj+QAadcWjQ6zchXx5Jqd/EmQ=; b=t6RjEa33/MuRIO5p+Zkm9TzWkVKijA3a6beoQz8TGXyAqnJEszyoewxGAkNbJcnymJ so0cjzlYnFuJ5nrxPsZhhwI+2HYEJ8QR36ulLOT5NU5zoLpWTlGd4Tdl9fNHqNczAq6h anucx4PfiBB63jblBkz/7G3wcl7F6Xf3t4Bug= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=AtcjBqELp1Ny7l+2d2Kj+QAadcWjQ6zchXx5Jqd/EmQ=; b=PjaclNcEk9QtRDxqv9qV6593DgR83eEpIKuN90zdzUvOdcmvnaHW68Yj91KGymEivw 2b4IX7hUSo4zrFxy6fSLAunc0d4iAY52W47Av3kHEyya8rHg/yF3CRLhTjC51Pr2rVRL s0ljxrPAg4oUrSFtZr9fd9UtfIuVOv2OeTbXUzxFv6++L0ZhJKbGwAFoeKjn4IieU6ct 9p7taq3Wf3loEAlmLdIkbeoFPrarNX4MBCaQmvKToSRgiaG2JeY1yeCea5jt00uPCrDT IvEM3VjlFihn1sdjy3cDL/V6/JRJnEsAPsFezbb2lQzxFsOs4KU9qNfCGUVQNiglxa+v D69g== Received: by 10.112.104.2 with SMTP id ga2mr11074614lbb.48.1352910938467; Wed, 14 Nov 2012 08:35:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.25.166 with HTTP; Wed, 14 Nov 2012 08:35:08 -0800 (PST) In-Reply-To: References: From: Eitan Adler Date: Wed, 14 Nov 2012 11:35:08 -0500 Message-ID: Subject: Re: Give users a hint when their locate database is too small. To: Warren Block Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQn2EgzR2eiHkfkVUihQhNMgG7OW8+P2CB1BP1OZ9dM3KXG645HFcFG/+fClaoCegnV6P+Cm Cc: FreeBSD Hackers , Benjamin Kaduk X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:35:40 -0000 On 14 November 2012 11:32, Warren Block wrote: > On Tue, 13 Nov 2012, Benjamin Kaduk wrote: >>> >>> if (len < (2*NBG)) >>> - errx(1, "database too small: %s", db); >>> + errx(1, "database too small: %s\nRun >>> /usr/libexec/locate.updatedb", db); >> >> >> That looks longer than 80 characters, a limit given implicitly in style.9. I think he meant the source line is too long. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 14 17:53:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5325BA78; Wed, 14 Nov 2012 17:53:18 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id DC2168FC12; Wed, 14 Nov 2012 17:53:17 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo13so940510vcb.13 for ; Wed, 14 Nov 2012 09:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=R6IE9tYJfcRU1htYMtdBafw2QYb+Qo3QzJQTiE+1RsI=; b=ntNZ2K+LCT8Ta6R1NTnPJSoZlkqc5+13jwP8z+A1UhYfmTuO+CGqT+2hJYobTcEUq8 2fOPgkD1KrGQE1rPGv5mq3KMby++6xYlXI9mg5f1oofz8LKyhtrIzhhArG4V9wYPNinj OXevSAmEKwtGyCp/nOMzyTSGRuMcpJ9hDRkMMg9N8VCl5pAXod4LerZ1G5LsV0sYwK/i kLRUkE7OzTffi0RCBsDHaSn/7KCCYk4NAfpRDCQ1zFbwkCvwFp5+GBBH0NdQDHb8ay1H bfJZfadds6qp+ryN9Ly5XI+s8mIhAPdMwXS6TGS6wwNB8dwuFX0o62DiKo0ODUe8j8K9 4A6g== MIME-Version: 1.0 Received: by 10.52.155.199 with SMTP id vy7mr2970795vdb.54.1352915591477; Wed, 14 Nov 2012 09:53:11 -0800 (PST) Received: by 10.58.207.114 with HTTP; Wed, 14 Nov 2012 09:53:11 -0800 (PST) In-Reply-To: <50A3518F.7000707@FreeBSD.org> References: <50A3518F.7000707@FreeBSD.org> Date: Wed, 14 Nov 2012 12:53:11 -0500 Message-ID: Subject: Re: dtrace anonymous tracing From: Ryan Stone To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 17:53:18 -0000 Not to my knowledge, I'm afraid. On Wed, Nov 14, 2012 at 3:08 AM, Andriy Gapon wrote: > > Do we have support for DTrace anonymous tracing (boot-time tracing) on > FreeBSD? > > -- > Andriy Gapon > > _______________________________________________ > 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 Wed Nov 14 20:46:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E710BD8 for ; Wed, 14 Nov 2012 20:46:40 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 083B58FC14 for ; Wed, 14 Nov 2012 20:46:39 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so899769lah.13 for ; Wed, 14 Nov 2012 12:46:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=gkVc2yjyYOKuwvdiimVvOJ7i+j52oZrKxTdtQ8Jn9/0=; b=PC67WoBL/RcTYFZKNU6YXVfwPzVrMV5TDQwZPAwC2mm79k6mb9XxKGDZ56Zc+OLeJX rUOLawqjsnuj5YLrcalbVs2AvJjNZxP0zg4C+HgzSlswHeN0X0eUc0n68Cya1vhou+dq lF1K3sm8Nhj55WnhhEMT01VlL3mPsRcW7Q8cAk/7j0XB8pvfcEY1GMA0XsVKfJoVuT4j vTZL1FVWIdMj2zogoXwf3JfGxvKtejmpl+mMEHwIHI6YmuuL6e2xmdECOeOmNtXXQdim KtQWiIO4D9m3EQrJBxV71dbXkiMWD2kiDbUJW45YjR7T4sgIhBHZEPHiR7cI3U8kL9im LMBQ== Received: by 10.152.114.100 with SMTP id jf4mr26430299lab.47.1352925998470; Wed, 14 Nov 2012 12:46:38 -0800 (PST) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.112.131.232 with HTTP; Wed, 14 Nov 2012 12:46:08 -0800 (PST) In-Reply-To: References: From: Chris Rees Date: Wed, 14 Nov 2012 20:46:08 +0000 X-Google-Sender-Auth: AHfEFrHlR4Hl1-1D9sqVAq0iuP8 Message-ID: Subject: Re: Ports cross-compiling To: Alexander Yerenkow Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 20:46:40 -0000 On 5 September 2012 07:40, Alexander Yerenkow wrote: > Hello all. > I'm currently trying to make poudriere cross compile some ports for arm > arch. > I'm using such command (as example): > > env TARGET=arm TARGET_ARCH=armv6 TARGET_CPUARCH=armv6 > PATH=/usr/obj/arm.armv6/usr/src/tmp/usr/bin:${PATH} CONFIGURE_HOST=amd64 > STRIP_CMD=true make PKGNAMESUFFIX=-arm WRKDIRPREFIX=/tmp WITHOUT_CHECKS=yes > LOCALBASE=/usr/localarm6 -C /usr/ports/A/B package > > I have problem: > 1. When I run this command from chrooted env, all builds fine; configure > script make check if we cross-compiling, somehow it gets "no" and all goes > well. > 2. When this command run by poudriere in jail, all fails as here: > > checking whether we are cross compiling... configure: error: in > `/tmp/usr/ports/devel/pcre/work/pcre-8.31': > configure: error: cannot run C compiled programs. > If you meant to cross compile, use `--host'. > See `config.log' for more details > ===> Script "configure" failed unexpectedly. > > > So, I'd like to propose small changes to ports/Mk/bsd.port.mk > > SET_LATE_CONFIGURE_ARGS= \ > > ..... > if [ ! -z "${CONFIGURE_HOST}" ]; then \ > _LATE_CONFIGURE_ARGS="$${_LATE_CONFIGURE_ARGS} --host=${CONFIGURE_HOST}" ; \ > fi ; \ > ..... > > > And after this, builds going just fine (of course for ports that can be > cross-built). > > Is it possible to accept this? Seems to me non-destructive patch. Hi Alexander, Sorry for the late reply. You're definitely better off discussing this on ports@-- there has been some work done on cross-building ports, but it's fairly early days yet; the only real cross that can be done with much degree of success is i386 on amd64 currently. Your patch doesn't look destructive, but it could be better integrated with TARGET_ARCH setting. Chris From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 14 21:48:32 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E982867 for ; Wed, 14 Nov 2012 21:48:32 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (DMZ-MAILSEC-SCANNER-6.MIT.EDU [18.7.68.35]) by mx1.freebsd.org (Postfix) with ESMTP id 304EB8FC12 for ; Wed, 14 Nov 2012 21:48:31 +0000 (UTC) X-AuditID: 12074423-b7fab6d0000008f9-22-50a4107d90c6 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 03.43.02297.D7014A05; Wed, 14 Nov 2012 16:43:25 -0500 (EST) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id qAELhOoE023507; Wed, 14 Nov 2012 16:43:24 -0500 Received: from multics.mit.edu (SYSTEM-LOW-SIPB.MIT.EDU [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id qAELhMt1006937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 14 Nov 2012 16:43:23 -0500 (EST) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id qAELhLgX015944; Wed, 14 Nov 2012 16:43:21 -0500 (EST) Date: Wed, 14 Nov 2012 16:43:21 -0500 (EST) From: Benjamin Kaduk To: Eitan Adler Subject: Re: Give users a hint when their locate database is too small. In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixG6nrlsrsCTAYOkiNovtm/8xWiw60c5k 8euUhwOzx7TNB9k8Znyaz+JxpOMRYwBzFJdNSmpOZllqkb5dAldG78/pTAUnWSo2LjnH3MC4 hbmLkYNDQsBE4lCLSBcjJ5ApJnHh3nq2LkYuDiGBfYwSezd+hHI2MEq8WrKKGcI5wSSx8ehM dgingVGi/+NuRpB+FgFticfTGlhAbDYBFYmZbzaygdgiAmoS7153g9UwC8RKnHn+F6xGWMBd YumeB2A1nAKBEhveHger4RVwkFh5cRrU6q9MEoffTwdrEBXQkVi9fwoLRJGgxMmZT1gghlpK /Fv7i3UCo+AsJKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrp5WaW6KWmlG5iBIev i/IOxj8HlQ4xCnAwKvHwnri5OECINbGsuDL3EKMkB5OSKG8e15IAIb6k/JTKjMTijPii0pzU 4kOMEhzMSiK8Lw4ClfOmJFZWpRblw6SkOViUxHmvpdz0FxJITyxJzU5NLUgtgsnKcHAoSfB+ 5gMaKliUmp5akZaZU4KQZuLgBBnOAzSchx+ohre4IDG3ODMdIn+KUVFKnPcDSLMASCKjNA+u F5ZeXjGKA70iDNHOA0xNcN2vgAYzAQ3evxvk6uKSRISUVAPjvGVzfgfU2LLc7Xho8a/qdjnz 7QUrre0+5/gqKNSlvLhze42lC9exJ4GVu4UFagsPvtuY+iDsbPmVjDfejrXuhx5GHDqQ/D3i kHy7hTeP91/+447iVxTLEllvukrIP+Cdd9Fz/sont8tO/LEuXm/1sO/Clp8bVtXfVdE78Vii 8s4avjpN9WsxSizFGYmGWsxFxYkAkF9P9AoDAAA= Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:48:32 -0000 On Wed, 14 Nov 2012, Eitan Adler wrote: > On 14 November 2012 11:32, Warren Block wrote: >> On Tue, 13 Nov 2012, Benjamin Kaduk wrote: >>>> >>>> if (len < (2*NBG)) >>>> - errx(1, "database too small: %s", db); >>>> + errx(1, "database too small: %s\nRun >>>> /usr/libexec/locate.updatedb", db); >>> >>> >>> That looks longer than 80 characters, a limit given implicitly in style.9. > > I think he meant the source line is too long. Indeed. Apparently alpine wrapped it for my reply; I'm not sure why. -Ben From owner-freebsd-hackers@FreeBSD.ORG Wed Nov 14 21:54:25 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FE48A4C; Wed, 14 Nov 2012 21:54:25 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id C53EE8FC12; Wed, 14 Nov 2012 21:54:24 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so653743pab.13 for ; Wed, 14 Nov 2012 13:54:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4UvfWI6vwjSdKN+9eMSy21XP6oqrIvPF9HfqR3hV29s=; b=xvr5PmF+J0XtBDgqmbcDvJpQ0YUjpeGEdNdlztGb/RE7yBACvAmXZjqmxs+1+4SohP sm2Ah5Gw/02A1bEygcLpgDHsh7i6sE9mKPJS5jtbhxQks2MJD/g1cGvG9QxzQlELlHOk av7R4YmK38nwl8/JMZ6bVHzXUX2fyIXQHhk5cUoXPI7DMOBTS+GwKBAPZ1BTBAlJ/u1l oJDjsQ+yIs5ig6ZCjvsg4p1Myrr13KcqyDy0U5QrXstpNKx6mVVmMuUu1uufPLXA36mi Ox+ayJGJ7KZnxjQvVbZqJkwkfSp57egGRk0gE1szcsRapvllV+HPjGpj07HjGA/T4zAq b03w== MIME-Version: 1.0 Received: by 10.68.247.134 with SMTP id ye6mr1796224pbc.69.1352930064502; Wed, 14 Nov 2012 13:54:24 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Wed, 14 Nov 2012 13:54:24 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 13:54:24 -0800 X-Google-Sender-Auth: LcXJresFgNzg42D8O-2f_UnEcmo Message-ID: Subject: Re: my work on cross-build for mips, arm, etc - your help, please! From: Adrian Chadd To: Michael Vale Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-embedded@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:54:25 -0000 Hiya, Would you mind re-ubmitting the diff but using "diff -u" instead? It's hard to read a non-context diff these days! Thanks, ADrian On 13 November 2012 04:30, Michael Vale wrote: > I was just going to continuing hacking away at this but adri was really k= een that i post this stuff.. > > So far with what i=92ve got I can cross-build just about anything, but it= =92s not automated, there is issues with finding and building dependencies. > > i=92m using XDEV as the cross compiler > > a command line such as > > env TARGET=3Dmips TARGET_ARCH=3Dmips make _TARGET_CROSS_DEFS=3D =96C /usr= /ports/net/asterisk10 all > > should get the ball rolling > _______________________________________________ > 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 Wed Nov 14 21:55:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9A51FC16; Wed, 14 Nov 2012 21:55:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 5D1C58FC13; Wed, 14 Nov 2012 21:55:48 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so730741pbc.13 for ; Wed, 14 Nov 2012 13:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=47oitZ2pnqsZ0jQHiF3V+lgJp/+jqWpHuLS/kkdSHEQ=; b=PDKUguDI9mPziQ9lbZNdggNLExNUDzhHyTJ2APan7w49Hglp38xz+R5VmzM3D/krao Zrg5upFyEKmKXqs8/WxPQD4250gADJse4W1zD114ZrhLoA2em+AUKuVwpRSBdFIfrwLq FkA0fHaJ8uePApP9UwxJ7R3pRVbPy2/Z0jPt60lCH2pCnwJX/z6TDqlWNwJvf3pL9ZGF otgwQU2GeoLtzWHIXdBGO6yK8Z+RQwJVt4arkJfK1TQpEbZ8TLJ6ITOOIBO3xWSfJzII SPWPC6CSISOvSVP5RtKGIV6dhYPIIlsuKKYKlkSZUv5nD1t5acCfv0rQU5e8G4iLngJh Na4Q== MIME-Version: 1.0 Received: by 10.66.89.9 with SMTP id bk9mr1624637pab.67.1352930148009; Wed, 14 Nov 2012 13:55:48 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Wed, 14 Nov 2012 13:55:47 -0800 (PST) In-Reply-To: References: Date: Wed, 14 Nov 2012 13:55:47 -0800 X-Google-Sender-Auth: DhZbiRiZp4-UGJOM9xGpDOCH1c8 Message-ID: Subject: Re: my work on cross-build for mips, arm, etc - your help, please! From: Adrian Chadd To: Michael Vale Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, freebsd-embedded@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 21:55:48 -0000 Hi, Ok, I've stared at it. :) You've hard-coded the autotools/libtool directory. Why'd you do that? adrian From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 05:02:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3025AE72 for ; Thu, 15 Nov 2012 05:02:55 +0000 (UTC) (envelope-from rebel.kishore@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id D6D508FC08 for ; Thu, 15 Nov 2012 05:02:54 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so1624569vba.13 for ; Wed, 14 Nov 2012 21:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ADFckBgk1qLDN/EUMF1mteScBlm5g3j8zxv8q/fSgDQ=; b=v64KrZ8zFW4+HHK6z1jlhs3MkvdqyWUs9ESjvNEUbWouvTfgwYz1XdQYjfgwc3QKoC H7+Iw+TfAtTfdtdiZSFvzpAt2zB+h6YWFeyHPrmtD8xxFDa6IEZdLulAUULM9UY/MtS0 dr6tClC5nOwr75PEAEsul01XT5IWsgLfOvcSopzMJO4qAJXr5X6EamuwXdf6dobTBSbc 5SDOU1tpR6twJKseo6ga6MJJxzNspm+MJ2P1NYSfzgM32c5mDIlyOe0cqRGB7DR5Bnyb 8ZB9gIWwyDkqduuCD3YYZviFPGI6LfkpPibSsNCvzy/JsSInnLVfXJznPjwINOmUoFUO n8vQ== MIME-Version: 1.0 Received: by 10.58.94.109 with SMTP id db13mr35584566veb.39.1352955773987; Wed, 14 Nov 2012 21:02:53 -0800 (PST) Received: by 10.220.117.17 with HTTP; Wed, 14 Nov 2012 21:02:53 -0800 (PST) Date: Thu, 15 Nov 2012 10:32:53 +0530 Message-ID: Subject: Performance Issues of File package From: Kishore Kumar To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 05:02:55 -0000 Hi, - Is there any performance drop in file package version file-5.11 when compared to file-5.03? - Is the performance of file package and libmagic dependent on the size of magic database by any chance? - Does the new magic wrappers have any kind of performance issue? - How efficient is the magic database parsing done by libmagic? Thanks, Rebel From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 04:58:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 39E33DB2 for ; Thu, 15 Nov 2012 04:58:52 +0000 (UTC) (envelope-from rebel.kishore@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id DEFA98FC12 for ; Thu, 15 Nov 2012 04:58:51 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo13so1673036vcb.13 for ; Wed, 14 Nov 2012 20:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=83upzhtENZAvBtzyFeFv8qQFjSM6L58OKwy6aL32zNQ=; b=XL04fJ7lEEt/4TKo22Qh6gJcT8dYZyoeYwr9FU1S/oY1yMP9sC4cmAq1yOC40ZMZnj HJBdX+C1QJxrTCKhr4gHWsiA4fas3kPimc1zGDFjBOzvbkhRlaa366qjb7AaoKTOFRR0 oVyL7JlBq3cH0pm7vohcPJE3j8zh3eO/HAtUzrATfwS2I9arKqypmeUE8dKjbj+uQIWE ACRKJAbBThdJ8bbykEiccJ4IM/cb4mczDAlavFZbN0+hATBg90fhoclV5/g8rhKx3z5e fdVDEGtBrufvMwLmCBGgeI8+hZ1NKuNH8TIGeW4cjUeUTrypYLIanw7w0PfIRCxkZfJa WI2w== MIME-Version: 1.0 Received: by 10.58.94.109 with SMTP id db13mr35575442veb.39.1352955530846; Wed, 14 Nov 2012 20:58:50 -0800 (PST) Received: by 10.220.117.17 with HTTP; Wed, 14 Nov 2012 20:58:50 -0800 (PST) Date: Thu, 15 Nov 2012 10:28:50 +0530 Message-ID: Subject: performance variation of file package From: Kishore Kumar To: freebsd-hackers@freebsd.org X-Mailman-Approved-At: Thu, 15 Nov 2012 05:06:18 +0000 Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 04:58:52 -0000 Hi, - Is there any performance drop in file package version file-5.11 when compared to file-5.03? - Is the performance of file package and libmagic dependent on the size of magic database by any chance? - Does the new magic wrappers have any kind of performance issue? - How efficient is the magic database parsing done by libmagic? Thanks, Rebel From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 06:15:48 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 152D09E4; Thu, 15 Nov 2012 06:15:48 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id B7B0A8FC08; Thu, 15 Nov 2012 06:15:47 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so1654740obc.13 for ; Wed, 14 Nov 2012 22:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=+X3hI/ivxIXd0+H7ewJ23HBr6k+KpZ9WITZjfUjX/Yk=; b=IafJ1gysZKKUZlwTlbfs9FmDYKfS/ZcbL8uPQI7JemgHxTLyfXPYFWpXQ1HwnSEULE i+6ySnP5hNWjz8zrZ6hia0TVioK3R89tev5WtjRYig9qXHjk8eZzXmehlJ3vVBWzCg1O HHHZWEMJFfNJZWsGhjitQPkCqpbVR/iYFksxHfuxwG+tZsTMoSQCnfnqofAaPtFJsUxm nO4CzMFvgWSnT5PtTI+//VGltF9FWUEA4f7K0hqA33B9vCjT7+y9xcnZgV/ym+lLMmrU XHRHAJwRb7FauzhRZC3CkrfNikpR7t7zjq6YXdCmTOg53O7Wyh8rzjwcyTclMfD8Iwek 3u/Q== MIME-Version: 1.0 Received: by 10.182.69.50 with SMTP id b18mr52208obu.75.1352960146780; Wed, 14 Nov 2012 22:15:46 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.76.27.65 with HTTP; Wed, 14 Nov 2012 22:15:46 -0800 (PST) Date: Wed, 14 Nov 2012 22:15:46 -0800 X-Google-Sender-Auth: 0Rz1azTUUeP__CP-U11sAXzxaeA Message-ID: Subject: [RFQ] make witness panic an option From: Adrian Chadd To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=14dae93b5780f1b3ca04ce8294f5 Cc: freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 06:15:48 -0000 --14dae93b5780f1b3ca04ce8294f5 Content-Type: text/plain; charset=ISO-8859-1 Hi all, When debugging and writing wireless drivers/stack code, I like to sprinkle lots of locking assertions everywhere. However, this does cause things to panic quite often during active development. This patch (against stable/9) makes the actual panic itself configurable. It still prints the message regardless. This has allowed me to sprinkle more locking assertions everywhere to investigate whether particular paths have been hit or not. I don't necessarily want those to panic the kernel. I'd like everyone to consider this for FreeBSD-HEAD. Thanks! Adrian --14dae93b5780f1b3ca04ce8294f5 Content-Type: application/octet-stream; name="20121114-witness-1.diff" Content-Disposition: attachment; filename="20121114-witness-1.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h9jhl24w0 SW5kZXg6IHN5cy9rZXJuL3N1YnJfd2l0bmVzcy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9rZXJuL3N1 YnJfd2l0bmVzcy5jCShyZXZpc2lvbiAyNDE0OTEpCisrKyBzeXMva2Vybi9zdWJyX3dpdG5lc3Mu Ywkod29ya2luZyBjb3B5KQpAQCAtMzE5LDYgKzMxOSwyOCBAQAogCXJldHVybiAoYS0+ZnJvbSA9 PSBiLT5mcm9tICYmIGEtPnRvID09IGItPnRvKTsKIH0KIAorLyoKKyAqIFdoZXRoZXIgdG8gcGFu aWMgb3Igbm90IHdoZW4gYSB3aXRuZXNzIGNvbmRpdGlvbiBvY2N1cnMuCisgKi8KK3N0YXRpYyBp bnQgd2l0bmVzc19kb3BhbmljID0gMTsKKworLyoKKyAqIEhhbmRsZSB3aGV0aGVyIHRvIHBhbmlj IG9yIG1lcmVseSBwcmludCBhbiBpbmZvcm1hdGl2ZSBtZXNzYWdlLgorICovCitzdGF0aWMgdm9p ZAord2l0bmVzc19wYW5pYyhjb25zdCBjaGFyICpmbXQsIC4uLikKK3sKKwl2YV9saXN0IGFwOwor CisJdmFfc3RhcnQoYXAsIGZtdCk7CisJdnByaW50ZihmbXQsIGFwKTsKKwl2YV9lbmQoYXApOwor CisJLyogWFhYIGl0J2QgYmUgbmljZSB0byBtYWludGFpbiB0aGUgY29ycmVjdCBwYW5pY3N0ciAq LworCWlmICh3aXRuZXNzX2RvcGFuaWMpCisJCXBhbmljKCJ3aXRuZXNzXG4iKTsKK30KKwogc3Rh dGljIGludAlfaXNpdG15eChzdHJ1Y3Qgd2l0bmVzcyAqdzEsIHN0cnVjdCB3aXRuZXNzICp3Miwg aW50IHJtYXNrLAogCQkgICAgY29uc3QgY2hhciAqZm5hbWUpOwogI2lmZGVmIEtEQgpAQCAtNDA1 LDYgKzQyNyw5IEBACiBUVU5BQkxFX0lOVCgiZGVidWcud2l0bmVzcy5rZGIiLCAmd2l0bmVzc19r ZGIpOwogU1lTQ1RMX0lOVChfZGVidWdfd2l0bmVzcywgT0lEX0FVVE8sIGtkYiwgQ1RMRkxBR19S VywgJndpdG5lc3Nfa2RiLCAwLCAiIik7CiAKK1RVTkFCTEVfSU5UKCJkZWJ1Zy53aXRuZXNzLnBh bmljIiwgJndpdG5lc3NfZG9wYW5pYyk7CitTWVNDVExfSU5UKF9kZWJ1Z193aXRuZXNzLCBPSURf QVVUTywgcGFuaWMsIENUTEZMQUdfUlcsICZ3aXRuZXNzX2RvcGFuaWMsIDAsICIiKTsKKwogLyoK ICAqIFdoZW4gS0RCIGlzIGVuYWJsZWQgYW5kIHdpdG5lc3NfdHJhY2UgaXMgMSwgaXQgd2lsbCBj YXVzZSB0aGUgc3lzdGVtCiAgKiB0byBwcmludCBhIHN0YWNrIHRyYWNlOgpAQCAtNzIyLDE4ICs3 NDcsNiBAQAogICovCiBzdGF0aWMgaW50IHdpdG5lc3Nfc3Bpbl93YXJuID0gMDsKIAotLyogVHJp bSB1c2VsZXNzIGdhcmJhZ2UgZnJvbSBmaWxlbmFtZXMuICovCi1zdGF0aWMgY29uc3QgY2hhciAq Ci1maXh1cF9maWxlbmFtZShjb25zdCBjaGFyICpmaWxlKQotewotCi0JaWYgKGZpbGUgPT0gTlVM TCkKLQkJcmV0dXJuIChOVUxMKTsKLQl3aGlsZSAoc3RybmNtcChmaWxlLCAiLi4vIiwgMykgPT0g MCkKLQkJZmlsZSArPSAzOwotCXJldHVybiAoZmlsZSk7Ci19Ci0KIC8qCiAgKiBUaGUgV0lUTkVT Uy1lbmFibGVkIGRpYWdub3N0aWMgY29kZS4gIE5vdGUgdGhhdCB0aGUgd2l0bmVzcyBjb2RlIGRv ZXMKICAqIGFzc3VtZSB0aGF0IHRoZSBlYXJseSBib290IGlzIHNpbmdsZS10aHJlYWRlZCBhdCBs ZWFzdCB1bnRpbCBhZnRlciB0aGlzCkBAIC04MjQsMTUgKzgzNywxNSBAQAogCWNsYXNzID0gTE9D S19DTEFTUyhsb2NrKTsKIAlpZiAoKGxvY2stPmxvX2ZsYWdzICYgTE9fUkVDVVJTQUJMRSkgIT0g MCAmJgogCSAgICAoY2xhc3MtPmxjX2ZsYWdzICYgTENfUkVDVVJTQUJMRSkgPT0gMCkKLQkJcGFu aWMoIiVzOiBsb2NrICglcykgJXMgY2FuIG5vdCBiZSByZWN1cnNhYmxlIiwgX19mdW5jX18sCisJ CXdpdG5lc3NfcGFuaWMoIiVzOiBsb2NrICglcykgJXMgY2FuIG5vdCBiZSByZWN1cnNhYmxlIiwg X19mdW5jX18sCiAJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSk7CiAJaWYgKChs b2NrLT5sb19mbGFncyAmIExPX1NMRUVQQUJMRSkgIT0gMCAmJgogCSAgICAoY2xhc3MtPmxjX2Zs YWdzICYgTENfU0xFRVBBQkxFKSA9PSAwKQotCQlwYW5pYygiJXM6IGxvY2sgKCVzKSAlcyBjYW4g bm90IGJlIHNsZWVwYWJsZSIsIF9fZnVuY19fLAorCQl3aXRuZXNzX3BhbmljKCIlczogbG9jayAo JXMpICVzIGNhbiBub3QgYmUgc2xlZXBhYmxlIiwgX19mdW5jX18sCiAJCSAgICBjbGFzcy0+bGNf bmFtZSwgbG9jay0+bG9fbmFtZSk7CiAJaWYgKChsb2NrLT5sb19mbGFncyAmIExPX1VQR1JBREFC TEUpICE9IDAgJiYKIAkgICAgKGNsYXNzLT5sY19mbGFncyAmIExDX1VQR1JBREFCTEUpID09IDAp Ci0JCXBhbmljKCIlczogbG9jayAoJXMpICVzIGNhbiBub3QgYmUgdXBncmFkYWJsZSIsIF9fZnVu Y19fLAorCQl3aXRuZXNzX3BhbmljKCIlczogbG9jayAoJXMpICVzIGNhbiBub3QgYmUgdXBncmFk YWJsZSIsIF9fZnVuY19fLAogCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUpOwog CiAJLyoKQEAgLTg0OSw3ICs4NjIsNyBAQAogCQlwZW5kaW5nX2xvY2tzW3BlbmRpbmdfY250XS53 aF9sb2NrID0gbG9jazsKIAkJcGVuZGluZ19sb2Nrc1twZW5kaW5nX2NudCsrXS53aF90eXBlID0g dHlwZTsKIAkJaWYgKHBlbmRpbmdfY250ID4gV0lUTkVTU19QRU5ETElTVCkKLQkJCXBhbmljKCIl czogcGVuZGluZyBsb2NrcyBsaXN0IGlzIHRvbyBzbWFsbCwgYnVtcCBpdFxuIiwKKwkJCXdpdG5l c3NfcGFuaWMoIiVzOiBwZW5kaW5nIGxvY2tzIGxpc3QgaXMgdG9vIHNtYWxsLCBidW1wIGl0XG4i LAogCQkJICAgIF9fZnVuY19fKTsKIAl9IGVsc2UKIAkJbG9jay0+bG9fd2l0bmVzcyA9IGVucm9s bCh0eXBlLCBjbGFzcyk7CkBAIC04NjQsNyArODc3LDcgQEAKIAljbGFzcyA9IExPQ0tfQ0xBU1Mo bG9jayk7CiAKIAlpZiAod2l0bmVzc19jb2xkKQotCQlwYW5pYygibG9jayAoJXMpICVzIGRlc3Ry b3llZCB3aGlsZSB3aXRuZXNzX2NvbGQiLAorCQl3aXRuZXNzX3BhbmljKCJsb2NrICglcykgJXMg ZGVzdHJveWVkIHdoaWxlIHdpdG5lc3NfY29sZCIsCiAJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9j ay0+bG9fbmFtZSk7CiAKIAkvKiBYWFg6IG5lZWQgdG8gdmVyaWZ5IHRoYXQgbm8gb25lIGhvbGRz IHRoZSBsb2NrICovCkBAIC05MzksNyArOTUyLDcgQEAKICAJfQogIAl3LT53X2Rpc3BsYXllZCA9 IDE7CiAJaWYgKHctPndfZmlsZSAhPSBOVUxMICYmIHctPndfbGluZSAhPSAwKQotCQlwcm50KCIg LS0gbGFzdCBhY3F1aXJlZCBAICVzOiVkXG4iLCBmaXh1cF9maWxlbmFtZSh3LT53X2ZpbGUpLAor CQlwcm50KCIgLS0gbGFzdCBhY3F1aXJlZCBAICVzOiVkXG4iLCB3LT53X2ZpbGUsCiAJCSAgICB3 LT53X2xpbmUpOwogCWVsc2UKIAkJcHJudCgiIC0tIG5ldmVyIGFjcXVpcmVkXG4iKTsKQEAgLTEw MTUsNiArMTAyOCwxOCBAQAogfQogI2VuZGlmIC8qIEREQiAqLwogCisvKiBUcmltIHVzZWxlc3Mg Z2FyYmFnZSBmcm9tIGZpbGVuYW1lcy4gKi8KK3N0YXRpYyBjb25zdCBjaGFyICoKK2ZpeHVwX2Zp bGVuYW1lKGNvbnN0IGNoYXIgKmZpbGUpCit7CisKKwlpZiAoZmlsZSA9PSBOVUxMKQorCQlyZXR1 cm4gKE5VTEwpOworCXdoaWxlIChzdHJuY21wKGZpbGUsICIuLi8iLCAzKSA9PSAwKQorCQlmaWxl ICs9IDM7CisJcmV0dXJuIChmaWxlKTsKK30KKwogaW50CiB3aXRuZXNzX2RlZmluZW9yZGVyKHN0 cnVjdCBsb2NrX29iamVjdCAqbG9jazEsIHN0cnVjdCBsb2NrX29iamVjdCAqbG9jazIpCiB7CkBA IC0xMDc1LDkgKzExMDAsOCBAQAogCQkgKiBhbGwgc3BpbiBsb2Nrcy4KIAkJICovCiAJCWlmICh0 ZC0+dGRfY3JpdG5lc3QgIT0gMCAmJiAha2RiX2FjdGl2ZSkKLQkJCXBhbmljKCJibG9ja2FibGUg c2xlZXAgbG9jayAoJXMpICVzIEAgJXM6JWQiLAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2Nr LT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdpdG5l c3NfcGFuaWMoImJsb2NrYWJsZSBzbGVlcCBsb2NrICglcykgJXMgQCAlczolZCIsCisJCQkgICAg Y2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5l KTsKIAogCQkvKgogCQkgKiBJZiB0aGlzIGlzIHRoZSBmaXJzdCBsb2NrIGFjcXVpcmVkIHRoZW4g anVzdCByZXR1cm4gYXMKQEAgLTExMTUsMjAgKzExMzksMTggQEAKIAkJaWYgKChsb2NrMS0+bGlf ZmxhZ3MgJiBMSV9FWENMVVNJVkUpICE9IDAgJiYKIAkJICAgIChmbGFncyAmIExPUF9FWENMVVNJ VkUpID09IDApIHsKIAkJCXByaW50Zigic2hhcmVkIGxvY2sgb2YgKCVzKSAlcyBAICVzOiVkXG4i LAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2Zp bGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFt ZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQkJcHJpbnRmKCJ3aGlsZSBleGNsdXNp dmVseSBsb2NrZWQgZnJvbSAlczolZFxuIiwKIAkJCSAgICBmaXh1cF9maWxlbmFtZShsb2NrMS0+ bGlfZmlsZSksIGxvY2sxLT5saV9saW5lKTsKLQkJCXBhbmljKCJzaGFyZS0+ZXhjbCIpOworCQkJ d2l0bmVzc19wYW5pYygic2hhcmUtPmV4Y2wiKTsKIAkJfQogCQlpZiAoKGxvY2sxLT5saV9mbGFn cyAmIExJX0VYQ0xVU0lWRSkgPT0gMCAmJgogCQkgICAgKGZsYWdzICYgTE9QX0VYQ0xVU0lWRSkg IT0gMCkgewogCQkJcHJpbnRmKCJleGNsdXNpdmUgbG9jayBvZiAoJXMpICVzIEAgJXM6JWRcbiIs Ci0JCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsCi0JCQkgICAgZml4dXBfZmls ZW5hbWUoZmlsZSksIGxpbmUpOworCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1l LCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJCQlwcmludGYoIndoaWxlIHNoYXJlIGxv Y2tlZCBmcm9tICVzOiVkXG4iLAogCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGxvY2sxLT5saV9maWxl KSwgbG9jazEtPmxpX2xpbmUpOwotCQkJcGFuaWMoImV4Y2wtPnNoYXJlIik7CisJCQl3aXRuZXNz X3BhbmljKCJleGNsLT5zaGFyZSIpOwogCQl9CiAJCXJldHVybjsKIAl9CkBAIC0xMTgwLDEyICsx MjAyLDExIEBACiAJCQkgICAgImFjcXVpcmluZyBkdXBsaWNhdGUgbG9jayBvZiBzYW1lIHR5cGU6 IFwiJXNcIlxuIiwgCiAJCQkgICAgdy0+d19uYW1lKTsKIAkJCXByaW50ZigiIDFzdCAlcyBAICVz OiVkXG4iLCBwbG9jay0+bGlfbG9jay0+bG9fbmFtZSwKLQkJCSAgICBmaXh1cF9maWxlbmFtZShw bG9jay0+bGlfZmlsZSksIHBsb2NrLT5saV9saW5lKTsKLQkJCXByaW50ZigiIDJuZCAlcyBAICVz OiVkXG4iLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5l KTsKKwkJCSAgICAgICBmaXh1cF9maWxlbmFtZShwbG9jay0+bGlfZmlsZSksIHBsb2NrLT5saV9s aW5lKTsKKwkJCXByaW50ZigiIDJuZCAlcyBAICVzOiVkXG4iLCBsb2NrLT5sb19uYW1lLCBmaXh1 cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJCQl3aXRuZXNzX2RlYnVnZ2VyKDEpOwotCQl9IGVs c2UKLQkJCW10eF91bmxvY2tfc3Bpbigmd19tdHgpOworCQkgICAgfSBlbHNlCisJCQkgICAgbXR4 X3VubG9ja19zcGluKCZ3X210eCk7CiAJCXJldHVybjsKIAl9CiAJbXR4X2Fzc2VydCgmd19tdHgs IE1BX09XTkVEKTsKQEAgLTEzMjMsMjQgKzEzNDQsMTkgQEAKIAkJCWlmIChpIDwgMCkgewogCQkJ CXByaW50ZigiIDFzdCAlcCAlcyAoJXMpIEAgJXM6JWRcbiIsCiAJCQkJICAgIGxvY2sxLT5saV9s b2NrLCBsb2NrMS0+bGlfbG9jay0+bG9fbmFtZSwKLQkJCQkgICAgdzEtPndfbmFtZSwgZml4dXBf ZmlsZW5hbWUobG9jazEtPmxpX2ZpbGUpLAotCQkJCSAgICBsb2NrMS0+bGlfbGluZSk7CisJCQkJ ICAgIHcxLT53X25hbWUsIGZpeHVwX2ZpbGVuYW1lKGxvY2sxLT5saV9maWxlKSwgbG9jazEtPmxp X2xpbmUpOwogCQkJCXByaW50ZigiIDJuZCAlcCAlcyAoJXMpIEAgJXM6JWRcbiIsIGxvY2ssCi0J CQkJICAgIGxvY2stPmxvX25hbWUsIHctPndfbmFtZSwKLQkJCQkgICAgZml4dXBfZmlsZW5hbWUo ZmlsZSksIGxpbmUpOworCQkJCSAgICBsb2NrLT5sb19uYW1lLCB3LT53X25hbWUsIGZpeHVwX2Zp bGVuYW1lKGZpbGUpLCBsaW5lKTsKIAkJCX0gZWxzZSB7CiAJCQkJcHJpbnRmKCIgMXN0ICVwICVz ICglcykgQCAlczolZFxuIiwKIAkJCQkgICAgbG9jazItPmxpX2xvY2ssIGxvY2syLT5saV9sb2Nr LT5sb19uYW1lLAogCQkJCSAgICBsb2NrMi0+bGlfbG9jay0+bG9fd2l0bmVzcy0+d19uYW1lLAot CQkJCSAgICBmaXh1cF9maWxlbmFtZShsb2NrMi0+bGlfZmlsZSksCi0JCQkJICAgIGxvY2syLT5s aV9saW5lKTsKKwkJCQkgICAgZml4dXBfZmlsZW5hbWUobG9jazItPmxpX2ZpbGUpLCBsb2NrMi0+ bGlfbGluZSk7CiAJCQkJcHJpbnRmKCIgMm5kICVwICVzICglcykgQCAlczolZFxuIiwKIAkJCQkg ICAgbG9jazEtPmxpX2xvY2ssIGxvY2sxLT5saV9sb2NrLT5sb19uYW1lLAotCQkJCSAgICB3MS0+ d19uYW1lLCBmaXh1cF9maWxlbmFtZShsb2NrMS0+bGlfZmlsZSksCi0JCQkJICAgIGxvY2sxLT5s aV9saW5lKTsKKwkJCQkgICAgdzEtPndfbmFtZSwgZml4dXBfZmlsZW5hbWUobG9jazEtPmxpX2Zp bGUpLCBsb2NrMS0+bGlfbGluZSk7CiAJCQkJcHJpbnRmKCIgM3JkICVwICVzICglcykgQCAlczol ZFxuIiwgbG9jaywKLQkJCQkgICAgbG9jay0+bG9fbmFtZSwgdy0+d19uYW1lLAotCQkJCSAgICBm aXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCQkJICAgIGxvY2stPmxvX25hbWUsIHctPndf bmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQkJfQogCQkJd2l0bmVzc19kZWJ1 Z2dlcigxKTsKIAkJCXJldHVybjsKQEAgLTE0MzUsMjkgKzE0NTEsMjQgQEAKIAljbGFzcyA9IExP Q0tfQ0xBU1MobG9jayk7CiAJaWYgKHdpdG5lc3Nfd2F0Y2gpIHsKIAkJaWYgKChsb2NrLT5sb19m bGFncyAmIExPX1VQR1JBREFCTEUpID09IDApCi0JCQlwYW5pYygidXBncmFkZSBvZiBub24tdXBn cmFkYWJsZSBsb2NrICglcykgJXMgQCAlczolZCIsCi0JCQkgICAgY2xhc3MtPmxjX25hbWUsIGxv Y2stPmxvX25hbWUsCi0JCQkgICAgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOworCQkJd2l0 bmVzc19wYW5pYygidXBncmFkZSBvZiBub24tdXBncmFkYWJsZSBsb2NrICglcykgJXMgQCAlczol ZCIsCisJCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1l KGZpbGUpLCBsaW5lKTsKIAkJaWYgKChjbGFzcy0+bGNfZmxhZ3MgJiBMQ19TTEVFUExPQ0spID09 IDApCi0JCQlwYW5pYygidXBncmFkZSBvZiBub24tc2xlZXAgbG9jayAoJXMpICVzIEAgJXM6JWQi LAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2Zp bGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdpdG5lc3NfcGFuaWMoInVwZ3JhZGUgb2Ygbm9uLXNs ZWVwIGxvY2sgKCVzKSAlcyBAICVzOiVkIiwKKwkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+ bG9fbmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCX0KIAlpbnN0YW5jZSA9IGZp bmRfaW5zdGFuY2UoY3VydGhyZWFkLT50ZF9zbGVlcGxvY2tzLCBsb2NrKTsKIAlpZiAoaW5zdGFu Y2UgPT0gTlVMTCkKLQkJcGFuaWMoInVwZ3JhZGUgb2YgdW5sb2NrZWQgbG9jayAoJXMpICVzIEAg JXM6JWQiLAotCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsCi0JCSAgICBmaXh1 cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCXdpdG5lc3NfcGFuaWMoInVwZ3JhZGUgb2YgdW5s b2NrZWQgbG9jayAoJXMpICVzIEAgJXM6JWQiLAorCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2st PmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAlpZiAod2l0bmVzc193YXRj aCkgewogCQlpZiAoKGluc3RhbmNlLT5saV9mbGFncyAmIExJX0VYQ0xVU0lWRSkgIT0gMCkKLQkJ CXBhbmljKCJ1cGdyYWRlIG9mIGV4Y2x1c2l2ZSBsb2NrICglcykgJXMgQCAlczolZCIsCi0JCQkg ICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsCi0JCQkgICAgZml4dXBfZmlsZW5hbWUo ZmlsZSksIGxpbmUpOworCQkJd2l0bmVzc19wYW5pYygidXBncmFkZSBvZiBleGNsdXNpdmUgbG9j ayAoJXMpICVzIEAgJXM6JWQiLAorCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1l LCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJCWlmICgoaW5zdGFuY2UtPmxpX2ZsYWdz ICYgTElfUkVDVVJTRU1BU0spICE9IDApCi0JCQlwYW5pYygidXBncmFkZSBvZiByZWN1cnNlZCBs b2NrICglcykgJXMgcj0lZCBAICVzOiVkIiwKKwkJCXdpdG5lc3NfcGFuaWMoInVwZ3JhZGUgb2Yg cmVjdXJzZWQgbG9jayAoJXMpICVzIHI9JWQgQCAlczolZCIsCiAJCQkgICAgY2xhc3MtPmxjX25h bWUsIGxvY2stPmxvX25hbWUsCi0JCQkgICAgaW5zdGFuY2UtPmxpX2ZsYWdzICYgTElfUkVDVVJT RU1BU0ssCi0JCQkgICAgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOworCQkJICAgIGluc3Rh bmNlLT5saV9mbGFncyAmIExJX1JFQ1VSU0VNQVNLLCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGlu ZSk7CiAJfQogCWluc3RhbmNlLT5saV9mbGFncyB8PSBMSV9FWENMVVNJVkU7CiB9CkBAIC0xNDc1 LDI5ICsxNDg2LDI0IEBACiAJY2xhc3MgPSBMT0NLX0NMQVNTKGxvY2spOwogCWlmICh3aXRuZXNz X3dhdGNoKSB7CiAJCWlmICgobG9jay0+bG9fZmxhZ3MgJiBMT19VUEdSQURBQkxFKSA9PSAwKQot CQlwYW5pYygiZG93bmdyYWRlIG9mIG5vbi11cGdyYWRhYmxlIGxvY2sgKCVzKSAlcyBAICVzOiVk IiwKLQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwKLQkJCSAgICBmaXh1cF9m aWxlbmFtZShmaWxlKSwgbGluZSk7CisJCXdpdG5lc3NfcGFuaWMoImRvd25ncmFkZSBvZiBub24t dXBncmFkYWJsZSBsb2NrICglcykgJXMgQCAlczolZCIsCisJCQkgICAgY2xhc3MtPmxjX25hbWUs IGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAkJaWYgKChjbGFz cy0+bGNfZmxhZ3MgJiBMQ19TTEVFUExPQ0spID09IDApCi0JCQlwYW5pYygiZG93bmdyYWRlIG9m IG5vbi1zbGVlcCBsb2NrICglcykgJXMgQCAlczolZCIsCi0JCQkgICAgY2xhc3MtPmxjX25hbWUs IGxvY2stPmxvX25hbWUsCi0JCQkgICAgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOworCQkJ d2l0bmVzc19wYW5pYygiZG93bmdyYWRlIG9mIG5vbi1zbGVlcCBsb2NrICglcykgJXMgQCAlczol ZCIsCisJCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1l KGZpbGUpLCBsaW5lKTsKIAl9CiAJaW5zdGFuY2UgPSBmaW5kX2luc3RhbmNlKGN1cnRocmVhZC0+ dGRfc2xlZXBsb2NrcywgbG9jayk7CiAJaWYgKGluc3RhbmNlID09IE5VTEwpCi0JCXBhbmljKCJk b3duZ3JhZGUgb2YgdW5sb2NrZWQgbG9jayAoJXMpICVzIEAgJXM6JWQiLAotCQkgICAgY2xhc3Mt PmxjX25hbWUsIGxvY2stPmxvX25hbWUsCi0JCSAgICBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGlu ZSk7CisJCXdpdG5lc3NfcGFuaWMoImRvd25ncmFkZSBvZiB1bmxvY2tlZCBsb2NrICglcykgJXMg QCAlczolZCIsCisJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwgZml4dXBfZmls ZW5hbWUoZmlsZSksIGxpbmUpOwogCWlmICh3aXRuZXNzX3dhdGNoKSB7CiAJCWlmICgoaW5zdGFu Y2UtPmxpX2ZsYWdzICYgTElfRVhDTFVTSVZFKSA9PSAwKQotCQkJcGFuaWMoImRvd25ncmFkZSBv ZiBzaGFyZWQgbG9jayAoJXMpICVzIEAgJXM6JWQiLAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBs b2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdp dG5lc3NfcGFuaWMoImRvd25ncmFkZSBvZiBzaGFyZWQgbG9jayAoJXMpICVzIEAgJXM6JWQiLAor CQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShmaWxl KSwgbGluZSk7CiAJCWlmICgoaW5zdGFuY2UtPmxpX2ZsYWdzICYgTElfUkVDVVJTRU1BU0spICE9 IDApCi0JCQlwYW5pYygiZG93bmdyYWRlIG9mIHJlY3Vyc2VkIGxvY2sgKCVzKSAlcyByPSVkIEAg JXM6JWQiLAorCQkJd2l0bmVzc19wYW5pYygiZG93bmdyYWRlIG9mIHJlY3Vyc2VkIGxvY2sgKCVz KSAlcyByPSVkIEAgJXM6JWQiLAogCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1l LAotCQkJICAgIGluc3RhbmNlLT5saV9mbGFncyAmIExJX1JFQ1VSU0VNQVNLLAotCQkJICAgIGZp eHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCSAgICBpbnN0YW5jZS0+bGlfZmxhZ3MgJiBM SV9SRUNVUlNFTUFTSywgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCX0KIAlpbnN0YW5j ZS0+bGlfZmxhZ3MgJj0gfkxJX0VYQ0xVU0lWRTsKIH0KQEAgLTE1MDYsMTEgKzE1MTIsMTEgQEAK IHdpdG5lc3NfdW5sb2NrKHN0cnVjdCBsb2NrX29iamVjdCAqbG9jaywgaW50IGZsYWdzLCBjb25z dCBjaGFyICpmaWxlLCBpbnQgbGluZSkKIHsKIAlzdHJ1Y3QgbG9ja19saXN0X2VudHJ5ICoqbG9j a19saXN0LCAqbGxlOwotCXN0cnVjdCBsb2NrX2luc3RhbmNlICppbnN0YW5jZTsKKwlzdHJ1Y3Qg bG9ja19pbnN0YW5jZSAqaW5zdGFuY2UgPSBOVUxMOwogCXN0cnVjdCBsb2NrX2NsYXNzICpjbGFz czsKIAlzdHJ1Y3QgdGhyZWFkICp0ZDsKIAlyZWdpc3Rlcl90IHM7Ci0JaW50IGksIGo7CisJaW50 IGkgPSAwLCBqOwogCiAJaWYgKHdpdG5lc3NfY29sZCB8fCBsb2NrLT5sb193aXRuZXNzID09IE5V TEwgfHwgcGFuaWNzdHIgIT0gTlVMTCkKIAkJcmV0dXJuOwpAQCAtMTUzNyw3ICsxNTQzLDcgQEAK IAkgKiBldmVudHVhbCByZWdpc3RlciBsb2NrcyBhbmQgcmVtb3ZlIHRoZW0uCiAJICovCiAJaWYg KHdpdG5lc3Nfd2F0Y2ggPiAwKQotCQlwYW5pYygibG9jayAoJXMpICVzIG5vdCBsb2NrZWQgQCAl czolZCIsIGNsYXNzLT5sY19uYW1lLAorCQl3aXRuZXNzX3BhbmljKCJsb2NrICglcykgJXMgbm90 IGxvY2tlZCBAICVzOiVkIiwgY2xhc3MtPmxjX25hbWUsCiAJCSAgICBsb2NrLT5sb19uYW1lLCBm aXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJZWxzZQogCQlyZXR1cm47CkBAIC0xNTUwLDE2 ICsxNTU2LDE1IEBACiAJCSAgICBsb2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShmaWxlKSwg bGluZSk7CiAJCXByaW50Zigid2hpbGUgZXhjbHVzaXZlbHkgbG9ja2VkIGZyb20gJXM6JWRcbiIs CiAJCSAgICBmaXh1cF9maWxlbmFtZShpbnN0YW5jZS0+bGlfZmlsZSksIGluc3RhbmNlLT5saV9s aW5lKTsKLQkJcGFuaWMoImV4Y2wtPnVzaGFyZSIpOworCQl3aXRuZXNzX3BhbmljKCJleGNsLT51 c2hhcmUiKTsKIAl9CiAJaWYgKChpbnN0YW5jZS0+bGlfZmxhZ3MgJiBMSV9FWENMVVNJVkUpID09 IDAgJiYgd2l0bmVzc193YXRjaCA+IDAgJiYKIAkgICAgKGZsYWdzICYgTE9QX0VYQ0xVU0lWRSkg IT0gMCkgewogCQlwcmludGYoImV4Y2x1c2l2ZSB1bmxvY2sgb2YgKCVzKSAlcyBAICVzOiVkXG4i LCBjbGFzcy0+bGNfbmFtZSwKIAkJICAgIGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1lKGZp bGUpLCBsaW5lKTsKLQkJcHJpbnRmKCJ3aGlsZSBzaGFyZSBsb2NrZWQgZnJvbSAlczolZFxuIiwK LQkJICAgIGZpeHVwX2ZpbGVuYW1lKGluc3RhbmNlLT5saV9maWxlKSwKKwkJcHJpbnRmKCJ3aGls ZSBzaGFyZSBsb2NrZWQgZnJvbSAlczolZFxuIiwgZml4dXBfZmlsZW5hbWUoaW5zdGFuY2UtPmxp X2ZpbGUpLAogCQkgICAgaW5zdGFuY2UtPmxpX2xpbmUpOwotCQlwYW5pYygic2hhcmUtPnVleGNs Iik7CisJCXdpdG5lc3NfcGFuaWMoInNoYXJlLT51ZXhjbCIpOwogCX0KIAkvKiBJZiB3ZSBhcmUg cmVjdXJzZWQsIHVucmVjdXJzZS4gKi8KIAlpZiAoKGluc3RhbmNlLT5saV9mbGFncyAmIExJX1JF Q1VSU0VNQVNLKSA+IDApIHsKQEAgLTE1NzMsNyArMTU3OCw3IEBACiAJaWYgKChpbnN0YW5jZS0+ bGlfZmxhZ3MgJiBMSV9OT1JFTEVBU0UpICE9IDAgJiYgd2l0bmVzc193YXRjaCA+IDApIHsKIAkJ cHJpbnRmKCJmb3JiaWRkZW4gdW5sb2NrIG9mICglcykgJXMgQCAlczolZFxuIiwgY2xhc3MtPmxj X25hbWUsCiAJCSAgICBsb2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7 Ci0JCXBhbmljKCJsb2NrIG1hcmtlZCBub3JlbGVhc2UiKTsKKwkJd2l0bmVzc19wYW5pYygibG9j ayBtYXJrZWQgbm9yZWxlYXNlIik7CiAJfQogCiAJLyogT3RoZXJ3aXNlLCByZW1vdmUgdGhpcyBp dGVtIGZyb20gdGhlIGxpc3QuICovCkBAIC0xNjI4LDcgKzE2MzMsNyBAQAogCQkJCXdpdG5lc3Nf bGlzdF9sb2NrKCZsbGUtPmxsX2NoaWxkcmVuW2ldLCBwcmludGYpOwogCQkJCQogCQkJfQotCQlw YW5pYygiVGhyZWFkICVwIGNhbm5vdCBleGl0IHdoaWxlIGhvbGRpbmcgc2xlZXBsb2Nrc1xuIiwg dGQpOworCQl3aXRuZXNzX3BhbmljKCJUaHJlYWQgJXAgY2Fubm90IGV4aXQgd2hpbGUgaG9sZGlu ZyBzbGVlcGxvY2tzXG4iLCB0ZCk7CiAJfQogCXdpdG5lc3NfbG9ja19saXN0X2ZyZWUobGxlKTsK IH0KQEAgLTE3MDksNyArMTcxNCw3IEBACiAJfSBlbHNlCiAJCXNjaGVkX3VucGluKCk7CiAJaWYg KGZsYWdzICYgV0FSTl9QQU5JQyAmJiBuKQotCQlwYW5pYygiJXMiLCBfX2Z1bmNfXyk7CisJCXdp dG5lc3NfcGFuaWMoIiVzIiwgX19mdW5jX18pOwogCWVsc2UKIAkJd2l0bmVzc19kZWJ1Z2dlcihu KTsKIAlyZXR1cm4gKG4pOwpAQCAtMTc1NSw3ICsxNzYwLDcgQEAKIAl9IGVsc2UgaWYgKChsb2Nr X2NsYXNzLT5sY19mbGFncyAmIExDX1NMRUVQTE9DSykpCiAJCXR5cGVsaXN0ID0gJndfc2xlZXA7 CiAJZWxzZQotCQlwYW5pYygibG9jayBjbGFzcyAlcyBpcyBub3Qgc2xlZXAgb3Igc3BpbiIsCisJ CXdpdG5lc3NfcGFuaWMoImxvY2sgY2xhc3MgJXMgaXMgbm90IHNsZWVwIG9yIHNwaW4iLAogCQkg ICAgbG9ja19jbGFzcy0+bGNfbmFtZSk7CiAKIAltdHhfbG9ja19zcGluKCZ3X210eCk7CkBAIC0x Nzg2LDcgKzE3OTEsNyBAQAogCXctPndfcmVmY291bnQrKzsKIAltdHhfdW5sb2NrX3NwaW4oJndf bXR4KTsKIAlpZiAobG9ja19jbGFzcyAhPSB3LT53X2NsYXNzKQotCQlwYW5pYygKKwkJd2l0bmVz c19wYW5pYygKIAkJCSJsb2NrICglcykgJXMgZG9lcyBub3QgbWF0Y2ggZWFybGllciAoJXMpIGxv Y2siLAogCQkJZGVzY3JpcHRpb24sIGxvY2tfY2xhc3MtPmxjX25hbWUsCiAJCQl3LT53X2NsYXNz LT5sY19uYW1lKTsKQEAgLTE5MjAsNyArMTkyNSw3IEBACiAJaWYgKCF3aXRuZXNzX2xvY2tfdHlw ZV9lcXVhbChwYXJlbnQsIGNoaWxkKSkgewogCQlpZiAod2l0bmVzc19jb2xkID09IDApCiAJCQlt dHhfdW5sb2NrX3NwaW4oJndfbXR4KTsKLQkJcGFuaWMoIiVzOiBwYXJlbnQgXCIlc1wiICglcykg YW5kIGNoaWxkIFwiJXNcIiAoJXMpIGFyZSBub3QgIgorCQl3aXRuZXNzX3BhbmljKCIlczogcGFy ZW50IFwiJXNcIiAoJXMpIGFuZCBjaGlsZCBcIiVzXCIgKCVzKSBhcmUgbm90ICIKIAkJICAgICJ0 aGUgc2FtZSBsb2NrIHR5cGUiLCBfX2Z1bmNfXywgcGFyZW50LT53X25hbWUsCiAJCSAgICBwYXJl bnQtPndfY2xhc3MtPmxjX25hbWUsIGNoaWxkLT53X25hbWUsCiAJCSAgICBjaGlsZC0+d19jbGFz cy0+bGNfbmFtZSk7CkBAIC0yMTAyLDggKzIxMDcsOCBAQAogCWlmIChsb2NrLT5sb193aXRuZXNz LT53X25hbWUgIT0gbG9jay0+bG9fbmFtZSkKIAkJcHJudCgiICglcykiLCBsb2NrLT5sb193aXRu ZXNzLT53X25hbWUpOwogCXBybnQoIiByID0gJWQgKCVwKSBsb2NrZWQgQCAlczolZFxuIiwKLQkg ICAgaW5zdGFuY2UtPmxpX2ZsYWdzICYgTElfUkVDVVJTRU1BU0ssIGxvY2ssCi0JICAgIGZpeHVw X2ZpbGVuYW1lKGluc3RhbmNlLT5saV9maWxlKSwgaW5zdGFuY2UtPmxpX2xpbmUpOworCSAgICBp bnN0YW5jZS0+bGlfZmxhZ3MgJiBMSV9SRUNVUlNFTUFTSywgbG9jaywgZml4dXBfZmlsZW5hbWUo aW5zdGFuY2UtPmxpX2ZpbGUpLAorCSAgICBpbnN0YW5jZS0+bGlfbGluZSk7CiB9CiAKICNpZmRl ZiBEREIKQEAgLTIxNzQsMTMgKzIxNzksNiBAQAogCXN0cnVjdCBsb2NrX2luc3RhbmNlICppbnN0 YW5jZTsKIAlzdHJ1Y3QgbG9ja19jbGFzcyAqY2xhc3M7CiAKLQkvKgotCSAqIFRoaXMgZnVuY3Rp b24gaXMgdXNlZCBpbmRlcGVuZGVudGx5IGluIGxvY2tpbmcgY29kZSB0byBkZWFsIHdpdGgKLQkg KiBHaWFudCwgU0NIRURVTEVSX1NUT1BQRUQoKSBjaGVjayBjYW4gYmUgcmVtb3ZlZCBoZXJlIGFm dGVyIEdpYW50Ci0JICogaXMgZ29uZS4KLQkgKi8KLQlpZiAoU0NIRURVTEVSX1NUT1BQRUQoKSkK LQkJcmV0dXJuOwogCUtBU1NFUlQod2l0bmVzc19jb2xkID09IDAsICgiJXM6IHdpdG5lc3NfY29s ZCIsIF9fZnVuY19fKSk7CiAJaWYgKGxvY2stPmxvX3dpdG5lc3MgPT0gTlVMTCB8fCB3aXRuZXNz X3dhdGNoID09IC0xIHx8IHBhbmljc3RyICE9IE5VTEwpCiAJCXJldHVybjsKQEAgLTIxOTQsNyAr MjE5Miw3IEBACiAJfQogCWluc3RhbmNlID0gZmluZF9pbnN0YW5jZShsb2NrX2xpc3QsIGxvY2sp OwogCWlmIChpbnN0YW5jZSA9PSBOVUxMKQotCQlwYW5pYygiJXM6IGxvY2sgKCVzKSAlcyBub3Qg bG9ja2VkIiwgX19mdW5jX18sCisJCXdpdG5lc3NfcGFuaWMoIiVzOiBsb2NrICglcykgJXMgbm90 IGxvY2tlZCIsIF9fZnVuY19fLAogCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUp OwogCSpmaWxlcCA9IGluc3RhbmNlLT5saV9maWxlOwogCSpsaW5lcCA9IGluc3RhbmNlLT5saV9s aW5lOwpAQCAtMjIwNywxMyArMjIwNSw2IEBACiAJc3RydWN0IGxvY2tfaW5zdGFuY2UgKmluc3Rh bmNlOwogCXN0cnVjdCBsb2NrX2NsYXNzICpjbGFzczsKIAotCS8qCi0JICogVGhpcyBmdW5jdGlv biBpcyB1c2VkIGluZGVwZW5kZW50bHkgaW4gbG9ja2luZyBjb2RlIHRvIGRlYWwgd2l0aAotCSAq IEdpYW50LCBTQ0hFRFVMRVJfU1RPUFBFRCgpIGNoZWNrIGNhbiBiZSByZW1vdmVkIGhlcmUgYWZ0 ZXIgR2lhbnQKLQkgKiBpcyBnb25lLgotCSAqLwotCWlmIChTQ0hFRFVMRVJfU1RPUFBFRCgpKQot CQlyZXR1cm47CiAJS0FTU0VSVCh3aXRuZXNzX2NvbGQgPT0gMCwgKCIlczogd2l0bmVzc19jb2xk IiwgX19mdW5jX18pKTsKIAlpZiAobG9jay0+bG9fd2l0bmVzcyA9PSBOVUxMIHx8IHdpdG5lc3Nf d2F0Y2ggPT0gLTEgfHwgcGFuaWNzdHIgIT0gTlVMTCkKIAkJcmV0dXJuOwpAQCAtMjIyNyw3ICsy MjE4LDcgQEAKIAl9CiAJaW5zdGFuY2UgPSBmaW5kX2luc3RhbmNlKGxvY2tfbGlzdCwgbG9jayk7 CiAJaWYgKGluc3RhbmNlID09IE5VTEwpCi0JCXBhbmljKCIlczogbG9jayAoJXMpICVzIG5vdCBs b2NrZWQiLCBfX2Z1bmNfXywKKwkJd2l0bmVzc19wYW5pYygiJXM6IGxvY2sgKCVzKSAlcyBub3Qg bG9ja2VkIiwgX19mdW5jX18sCiAJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSk7 CiAJbG9jay0+bG9fd2l0bmVzcy0+d19maWxlID0gZmlsZTsKIAlsb2NrLT5sb193aXRuZXNzLT53 X2xpbmUgPSBsaW5lOwpAQCAtMjIzOSw3ICsyMjMwLDcgQEAKIHdpdG5lc3NfYXNzZXJ0KHN0cnVj dCBsb2NrX29iamVjdCAqbG9jaywgaW50IGZsYWdzLCBjb25zdCBjaGFyICpmaWxlLCBpbnQgbGlu ZSkKIHsKICNpZmRlZiBJTlZBUklBTlRfU1VQUE9SVAotCXN0cnVjdCBsb2NrX2luc3RhbmNlICpp bnN0YW5jZTsKKwlzdHJ1Y3QgbG9ja19pbnN0YW5jZSAqaW5zdGFuY2UgPSBOVUxMOwogCXN0cnVj dCBsb2NrX2NsYXNzICpjbGFzczsKIAogCWlmIChsb2NrLT5sb193aXRuZXNzID09IE5VTEwgfHwg d2l0bmVzc193YXRjaCA8IDEgfHwgcGFuaWNzdHIgIT0gTlVMTCkKQEAgLTIyNTAsMTUgKzIyNDEs MTQgQEAKIAllbHNlIGlmICgoY2xhc3MtPmxjX2ZsYWdzICYgTENfU1BJTkxPQ0spICE9IDApCiAJ CWluc3RhbmNlID0gZmluZF9pbnN0YW5jZShQQ1BVX0dFVChzcGlubG9ja3MpLCBsb2NrKTsKIAll bHNlIHsKLQkJcGFuaWMoIkxvY2sgKCVzKSAlcyBpcyBub3Qgc2xlZXAgb3Igc3BpbiEiLAorCQl3 aXRuZXNzX3BhbmljKCJMb2NrICglcykgJXMgaXMgbm90IHNsZWVwIG9yIHNwaW4hIiwKIAkJICAg IGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lKTsKIAl9CiAJc3dpdGNoIChmbGFncykgewog CWNhc2UgTEFfVU5MT0NLRUQ6CiAJCWlmIChpbnN0YW5jZSAhPSBOVUxMKQotCQkJcGFuaWMoIkxv Y2sgKCVzKSAlcyBsb2NrZWQgQCAlczolZC4iLAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2Nr LT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdpdG5l c3NfcGFuaWMoIkxvY2sgKCVzKSAlcyBsb2NrZWQgQCAlczolZC4iLAorCQkJICAgIGNsYXNzLT5s Y19uYW1lLCBsb2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJCWJy ZWFrOwogCWNhc2UgTEFfTE9DS0VEOgogCWNhc2UgTEFfTE9DS0VEIHwgTEFfUkVDVVJTRUQ6CkBA IC0yMjcwLDM1ICsyMjYwLDI5IEBACiAJY2FzZSBMQV9YTE9DS0VEIHwgTEFfUkVDVVJTRUQ6CiAJ Y2FzZSBMQV9YTE9DS0VEIHwgTEFfTk9UUkVDVVJTRUQ6CiAJCWlmIChpbnN0YW5jZSA9PSBOVUxM KSB7Ci0JCQlwYW5pYygiTG9jayAoJXMpICVzIG5vdCBsb2NrZWQgQCAlczolZC4iLAotCQkJICAg IGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZp bGUpLCBsaW5lKTsKKwkJCXdpdG5lc3NfcGFuaWMoIkxvY2sgKCVzKSAlcyBub3QgbG9ja2VkIEAg JXM6JWQuIiwKKwkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwgZml4dXBfZmls ZW5hbWUoZmlsZSksIGxpbmUpOwogCQkJYnJlYWs7CiAJCX0KIAkJaWYgKChmbGFncyAmIExBX1hM T0NLRUQpICE9IDAgJiYKIAkJICAgIChpbnN0YW5jZS0+bGlfZmxhZ3MgJiBMSV9FWENMVVNJVkUp ID09IDApCi0JCQlwYW5pYygiTG9jayAoJXMpICVzIG5vdCBleGNsdXNpdmVseSBsb2NrZWQgQCAl czolZC4iLAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZp eHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdpdG5lc3NfcGFuaWMoIkxvY2sgKCVzKSAl cyBub3QgZXhjbHVzaXZlbHkgbG9ja2VkIEAgJXM6JWQuIiwKKwkJCSAgICBjbGFzcy0+bGNfbmFt ZSwgbG9jay0+bG9fbmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQlpZiAoKGZs YWdzICYgTEFfU0xPQ0tFRCkgIT0gMCAmJgogCQkgICAgKGluc3RhbmNlLT5saV9mbGFncyAmIExJ X0VYQ0xVU0lWRSkgIT0gMCkKLQkJCXBhbmljKCJMb2NrICglcykgJXMgZXhjbHVzaXZlbHkgbG9j a2VkIEAgJXM6JWQuIiwKLQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwKLQkJ CSAgICBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCQl3aXRuZXNzX3BhbmljKCJMb2Nr ICglcykgJXMgZXhjbHVzaXZlbHkgbG9ja2VkIEAgJXM6JWQuIiwKKwkJCSAgICBjbGFzcy0+bGNf bmFtZSwgbG9jay0+bG9fbmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQlpZiAo KGZsYWdzICYgTEFfUkVDVVJTRUQpICE9IDAgJiYKIAkJICAgIChpbnN0YW5jZS0+bGlfZmxhZ3Mg JiBMSV9SRUNVUlNFTUFTSykgPT0gMCkKLQkJCXBhbmljKCJMb2NrICglcykgJXMgbm90IHJlY3Vy c2VkIEAgJXM6JWQuIiwKLQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwKLQkJ CSAgICBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCQl3aXRuZXNzX3BhbmljKCJMb2Nr ICglcykgJXMgbm90IHJlY3Vyc2VkIEAgJXM6JWQuIiwKKwkJCSAgICBjbGFzcy0+bGNfbmFtZSwg bG9jay0+bG9fbmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQlpZiAoKGZsYWdz ICYgTEFfTk9UUkVDVVJTRUQpICE9IDAgJiYKIAkJICAgIChpbnN0YW5jZS0+bGlfZmxhZ3MgJiBM SV9SRUNVUlNFTUFTSykgIT0gMCkKLQkJCXBhbmljKCJMb2NrICglcykgJXMgcmVjdXJzZWQgQCAl czolZC4iLAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZp eHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdpdG5lc3NfcGFuaWMoIkxvY2sgKCVzKSAl cyByZWN1cnNlZCBAICVzOiVkLiIsCisJCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25h bWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAkJYnJlYWs7CiAJZGVmYXVsdDoKLQkJ cGFuaWMoIkludmFsaWQgbG9jayBhc3NlcnRpb24gYXQgJXM6JWQuIiwKLQkJICAgIGZpeHVwX2Zp bGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJd2l0bmVzc19wYW5pYygiSW52YWxpZCBsb2NrIGFzc2Vy dGlvbiBhdCAlczolZC4iLCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAKIAl9CiAjZW5k aWYJLyogSU5WQVJJQU5UX1NVUFBPUlQgKi8KQEAgLTIzMjMsNyArMjMwNyw3IEBACiAJfQogCWlu c3RhbmNlID0gZmluZF9pbnN0YW5jZShsb2NrX2xpc3QsIGxvY2spOwogCWlmIChpbnN0YW5jZSA9 PSBOVUxMKQotCQlwYW5pYygiJXM6IGxvY2sgKCVzKSAlcyBub3QgbG9ja2VkIiwgX19mdW5jX18s CisJCXdpdG5lc3NfcGFuaWMoIiVzOiBsb2NrICglcykgJXMgbm90IGxvY2tlZCIsIF9fZnVuY19f LAogCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUpOwogCiAJaWYgKHNldCkK --14dae93b5780f1b3ca04ce8294f5-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 06:18:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F1239B82; Thu, 15 Nov 2012 06:18:32 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 888E38FC12; Thu, 15 Nov 2012 06:18:32 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so1656611obc.13 for ; Wed, 14 Nov 2012 22:18:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=4CcpiinliKUIH0pZHxGMUjpYQKH32I9qfbto6cmhCeA=; b=JtJ+RMLddkv4ck1uGfr99lxlTIFaGFa+5tzXMyPTQvQlmjCbnqsYl0u1cyMVpkCios EkoJIYqt/50HSwzhDbhoDrQKnzcY+G1VWlNiPAZP0z3GQ8Gi46HKnzXHtWu6rqEnnA1z /qRCThNafKAIIXr+4P4uDWrI4K9mE5cpr3TrucLLaodpyRkExRm9SubgySP2tn7Er9+/ Ul+ncDroaxwZb+gCcS1bmcUoQJE6+FKsJ6uIWgVfI95BMzEPGmLZpC2hkOEBXcIOcjdh ngnuYT146O7ukr5kHmmjS50SWulG8QdimXqCazHAJWF6PRjxIiTciV9I+6DWWltJlPL8 hLFA== MIME-Version: 1.0 Received: by 10.60.11.197 with SMTP id s5mr104246oeb.29.1352960312126; Wed, 14 Nov 2012 22:18:32 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.76.27.65 with HTTP; Wed, 14 Nov 2012 22:18:31 -0800 (PST) In-Reply-To: <201210291115.23845.zec@fer.hr> References: <201210291115.23845.zec@fer.hr> Date: Wed, 14 Nov 2012 22:18:31 -0800 X-Google-Sender-Auth: sJMFxyn6ZdMsU2s-vEvBpK8LauI Message-ID: Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices From: Adrian Chadd To: Marko Zec Content-Type: multipart/mixed; boundary=e89a8fb202eaccab6a04ce829ea2 Cc: freebsd-net@freebsd.org, Hans Petter Selasky , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 06:18:33 -0000 --e89a8fb202eaccab6a04ce829ea2 Content-Type: text/plain; charset=ISO-8859-1 Hi, Here's what I have thus far. Please ignore the device_printf() change. This works for me, both for hotplug cardbus wireless devices as well as (inadvertently!) a USB bluetooth device. What do you think? Adrian --e89a8fb202eaccab6a04ce829ea2 Content-Type: application/octet-stream; name="20121114-vimage-1.diff" Content-Disposition: attachment; filename="20121114-vimage-1.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_h9jhpwt20 SW5kZXg6IHN5cy9rZXJuL3N1YnJfYnVzLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL2tlcm4vc3Vicl9i dXMuYwkocmV2aXNpb24gMjQxNDkxKQorKysgc3lzL2tlcm4vc3Vicl9idXMuYwkod29ya2luZyBj b3B5KQpAQCAtMzksNiArMzksNyBAQAogI2luY2x1ZGUgPHN5cy9tYWxsb2MuaD4KICNpbmNsdWRl IDxzeXMvbW9kdWxlLmg+CiAjaW5jbHVkZSA8c3lzL211dGV4Lmg+CisjaW5jbHVkZSA8c3lzL3Bj cHUuaD4KICNpbmNsdWRlIDxzeXMvcG9sbC5oPgogI2luY2x1ZGUgPHN5cy9wcm9jLmg+CiAjaW5j bHVkZSA8c3lzL2NvbmR2YXIuaD4KQEAgLTUzLDYgKzU0LDggQEAKICNpbmNsdWRlIDxzeXMvYnVz Lmg+CiAjaW5jbHVkZSA8c3lzL2ludGVycnVwdC5oPgogCisjaW5jbHVkZSA8bmV0L3ZuZXQuaD4K KwogI2luY2x1ZGUgPG1hY2hpbmUvc3RkYXJnLmg+CiAKICNpbmNsdWRlIDx2bS91bWEuaD4KQEAg LTIzMTAsNiArMjMxMyw3IEBACiAJdmFfbGlzdCBhcDsKIAlpbnQgcmV0dmFsOwogCisJcHJpbnRm KCJbJWxsZF0gIiwgKGxvbmcgbG9uZyBpbnQpIGN1cnRocmVhZC0+dGRfdGlkKTsKIAlyZXR2YWwg PSBkZXZpY2VfcHJpbnRfcHJldHR5bmFtZShkZXYpOwogCXZhX3N0YXJ0KGFwLCBmbXQpOwogCXJl dHZhbCArPSB2cHJpbnRmKGZtdCwgYXApOwpAQCAtMjcxNiw3ICsyNzIwLDcgQEAKIGludAogZGV2 aWNlX3Byb2JlX2FuZF9hdHRhY2goZGV2aWNlX3QgZGV2KQogewotCWludCBlcnJvcjsKKwlpbnQg ZXJyb3IsIGlzX2RlZmF1bHRfdm5ldDsKIAogCUdJQU5UX1JFUVVJUkVEOwogCkBAIC0yNzI1LDcg KzI3MjksMTggQEAKIAkJcmV0dXJuICgwKTsKIAllbHNlIGlmIChlcnJvciAhPSAwKQogCQlyZXR1 cm4gKGVycm9yKTsKLQlyZXR1cm4gKGRldmljZV9hdHRhY2goZGV2KSk7CisKKwkvKgorCSAqIE9u bHkgc2V0IHRoZSBkZWZhdWx0IHZuZXQgdG8gdm5ldDAgaWYgdGhlIGN1cnJlbnQKKwkgKiB2bmV0 IGlzbid0IHZuZXQwLgorCSAqLworCWlzX2RlZmF1bHRfdm5ldCA9ICEhIElTX0RFRkFVTFRfVk5F VChjdXJ2bmV0KTsKKwlpZiAoISBpc19kZWZhdWx0X3ZuZXQpCisJCUNVUlZORVRfU0VUX1FVSUVU KHZuZXQwKTsKKwllcnJvciA9IGRldmljZV9hdHRhY2goZGV2KTsKKwlpZiAoISBpc19kZWZhdWx0 X3ZuZXQpCisJCUNVUlZORVRfUkVTVE9SRSgpOworCXJldHVybiBlcnJvcjsKIH0KIAogLyoqCklu ZGV4OiBzeXMva2Vybi9zdWJyX3dpdG5lc3MuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMva2Vybi9zdWJy X3dpdG5lc3MuYwkocmV2aXNpb24gMjQxNDkxKQorKysgc3lzL2tlcm4vc3Vicl93aXRuZXNzLmMJ KHdvcmtpbmcgY29weSkKQEAgLTMxOSw2ICszMTksMjggQEAKIAlyZXR1cm4gKGEtPmZyb20gPT0g Yi0+ZnJvbSAmJiBhLT50byA9PSBiLT50byk7CiB9CiAKKy8qCisgKiBXaGV0aGVyIHRvIHBhbmlj IG9yIG5vdCB3aGVuIGEgd2l0bmVzcyBjb25kaXRpb24gb2NjdXJzLgorICovCitzdGF0aWMgaW50 IHdpdG5lc3NfZG9wYW5pYyA9IDE7CisKKy8qCisgKiBIYW5kbGUgd2hldGhlciB0byBwYW5pYyBv ciBtZXJlbHkgcHJpbnQgYW4gaW5mb3JtYXRpdmUgbWVzc2FnZS4KKyAqLworc3RhdGljIHZvaWQK K3dpdG5lc3NfcGFuaWMoY29uc3QgY2hhciAqZm10LCAuLi4pCit7CisJdmFfbGlzdCBhcDsKKwor CXZhX3N0YXJ0KGFwLCBmbXQpOworCXZwcmludGYoZm10LCBhcCk7CisJdmFfZW5kKGFwKTsKKwor CS8qIFhYWCBpdCdkIGJlIG5pY2UgdG8gbWFpbnRhaW4gdGhlIGNvcnJlY3QgcGFuaWNzdHIgKi8K KwlpZiAod2l0bmVzc19kb3BhbmljKQorCQlwYW5pYygid2l0bmVzc1xuIik7Cit9CisKIHN0YXRp YyBpbnQJX2lzaXRteXgoc3RydWN0IHdpdG5lc3MgKncxLCBzdHJ1Y3Qgd2l0bmVzcyAqdzIsIGlu dCBybWFzaywKIAkJICAgIGNvbnN0IGNoYXIgKmZuYW1lKTsKICNpZmRlZiBLREIKQEAgLTQwNSw2 ICs0MjcsOSBAQAogVFVOQUJMRV9JTlQoImRlYnVnLndpdG5lc3Mua2RiIiwgJndpdG5lc3Nfa2Ri KTsKIFNZU0NUTF9JTlQoX2RlYnVnX3dpdG5lc3MsIE9JRF9BVVRPLCBrZGIsIENUTEZMQUdfUlcs ICZ3aXRuZXNzX2tkYiwgMCwgIiIpOwogCitUVU5BQkxFX0lOVCgiZGVidWcud2l0bmVzcy5wYW5p YyIsICZ3aXRuZXNzX2RvcGFuaWMpOworU1lTQ1RMX0lOVChfZGVidWdfd2l0bmVzcywgT0lEX0FV VE8sIHBhbmljLCBDVExGTEFHX1JXLCAmd2l0bmVzc19kb3BhbmljLCAwLCAiIik7CisKIC8qCiAg KiBXaGVuIEtEQiBpcyBlbmFibGVkIGFuZCB3aXRuZXNzX3RyYWNlIGlzIDEsIGl0IHdpbGwgY2F1 c2UgdGhlIHN5c3RlbQogICogdG8gcHJpbnQgYSBzdGFjayB0cmFjZToKQEAgLTcyMiwxOCArNzQ3 LDYgQEAKICAqLwogc3RhdGljIGludCB3aXRuZXNzX3NwaW5fd2FybiA9IDA7CiAKLS8qIFRyaW0g dXNlbGVzcyBnYXJiYWdlIGZyb20gZmlsZW5hbWVzLiAqLwotc3RhdGljIGNvbnN0IGNoYXIgKgot Zml4dXBfZmlsZW5hbWUoY29uc3QgY2hhciAqZmlsZSkKLXsKLQotCWlmIChmaWxlID09IE5VTEwp Ci0JCXJldHVybiAoTlVMTCk7Ci0Jd2hpbGUgKHN0cm5jbXAoZmlsZSwgIi4uLyIsIDMpID09IDAp Ci0JCWZpbGUgKz0gMzsKLQlyZXR1cm4gKGZpbGUpOwotfQotCiAvKgogICogVGhlIFdJVE5FU1Mt ZW5hYmxlZCBkaWFnbm9zdGljIGNvZGUuICBOb3RlIHRoYXQgdGhlIHdpdG5lc3MgY29kZSBkb2Vz CiAgKiBhc3N1bWUgdGhhdCB0aGUgZWFybHkgYm9vdCBpcyBzaW5nbGUtdGhyZWFkZWQgYXQgbGVh c3QgdW50aWwgYWZ0ZXIgdGhpcwpAQCAtODI0LDE1ICs4MzcsMTUgQEAKIAljbGFzcyA9IExPQ0tf Q0xBU1MobG9jayk7CiAJaWYgKChsb2NrLT5sb19mbGFncyAmIExPX1JFQ1VSU0FCTEUpICE9IDAg JiYKIAkgICAgKGNsYXNzLT5sY19mbGFncyAmIExDX1JFQ1VSU0FCTEUpID09IDApCi0JCXBhbmlj KCIlczogbG9jayAoJXMpICVzIGNhbiBub3QgYmUgcmVjdXJzYWJsZSIsIF9fZnVuY19fLAorCQl3 aXRuZXNzX3BhbmljKCIlczogbG9jayAoJXMpICVzIGNhbiBub3QgYmUgcmVjdXJzYWJsZSIsIF9f ZnVuY19fLAogCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUpOwogCWlmICgobG9j ay0+bG9fZmxhZ3MgJiBMT19TTEVFUEFCTEUpICE9IDAgJiYKIAkgICAgKGNsYXNzLT5sY19mbGFn cyAmIExDX1NMRUVQQUJMRSkgPT0gMCkKLQkJcGFuaWMoIiVzOiBsb2NrICglcykgJXMgY2FuIG5v dCBiZSBzbGVlcGFibGUiLCBfX2Z1bmNfXywKKwkJd2l0bmVzc19wYW5pYygiJXM6IGxvY2sgKCVz KSAlcyBjYW4gbm90IGJlIHNsZWVwYWJsZSIsIF9fZnVuY19fLAogCQkgICAgY2xhc3MtPmxjX25h bWUsIGxvY2stPmxvX25hbWUpOwogCWlmICgobG9jay0+bG9fZmxhZ3MgJiBMT19VUEdSQURBQkxF KSAhPSAwICYmCiAJICAgIChjbGFzcy0+bGNfZmxhZ3MgJiBMQ19VUEdSQURBQkxFKSA9PSAwKQot CQlwYW5pYygiJXM6IGxvY2sgKCVzKSAlcyBjYW4gbm90IGJlIHVwZ3JhZGFibGUiLCBfX2Z1bmNf XywKKwkJd2l0bmVzc19wYW5pYygiJXM6IGxvY2sgKCVzKSAlcyBjYW4gbm90IGJlIHVwZ3JhZGFi bGUiLCBfX2Z1bmNfXywKIAkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lKTsKIAog CS8qCkBAIC04NDksNyArODYyLDcgQEAKIAkJcGVuZGluZ19sb2Nrc1twZW5kaW5nX2NudF0ud2hf bG9jayA9IGxvY2s7CiAJCXBlbmRpbmdfbG9ja3NbcGVuZGluZ19jbnQrK10ud2hfdHlwZSA9IHR5 cGU7CiAJCWlmIChwZW5kaW5nX2NudCA+IFdJVE5FU1NfUEVORExJU1QpCi0JCQlwYW5pYygiJXM6 IHBlbmRpbmcgbG9ja3MgbGlzdCBpcyB0b28gc21hbGwsIGJ1bXAgaXRcbiIsCisJCQl3aXRuZXNz X3BhbmljKCIlczogcGVuZGluZyBsb2NrcyBsaXN0IGlzIHRvbyBzbWFsbCwgYnVtcCBpdFxuIiwK IAkJCSAgICBfX2Z1bmNfXyk7CiAJfSBlbHNlCiAJCWxvY2stPmxvX3dpdG5lc3MgPSBlbnJvbGwo dHlwZSwgY2xhc3MpOwpAQCAtODY0LDcgKzg3Nyw3IEBACiAJY2xhc3MgPSBMT0NLX0NMQVNTKGxv Y2spOwogCiAJaWYgKHdpdG5lc3NfY29sZCkKLQkJcGFuaWMoImxvY2sgKCVzKSAlcyBkZXN0cm95 ZWQgd2hpbGUgd2l0bmVzc19jb2xkIiwKKwkJd2l0bmVzc19wYW5pYygibG9jayAoJXMpICVzIGRl c3Ryb3llZCB3aGlsZSB3aXRuZXNzX2NvbGQiLAogCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2st PmxvX25hbWUpOwogCiAJLyogWFhYOiBuZWVkIHRvIHZlcmlmeSB0aGF0IG5vIG9uZSBob2xkcyB0 aGUgbG9jayAqLwpAQCAtOTM5LDcgKzk1Miw3IEBACiAgCX0KICAJdy0+d19kaXNwbGF5ZWQgPSAx OwogCWlmICh3LT53X2ZpbGUgIT0gTlVMTCAmJiB3LT53X2xpbmUgIT0gMCkKLQkJcHJudCgiIC0t IGxhc3QgYWNxdWlyZWQgQCAlczolZFxuIiwgZml4dXBfZmlsZW5hbWUody0+d19maWxlKSwKKwkJ cHJudCgiIC0tIGxhc3QgYWNxdWlyZWQgQCAlczolZFxuIiwgdy0+d19maWxlLAogCQkgICAgdy0+ d19saW5lKTsKIAllbHNlCiAJCXBybnQoIiAtLSBuZXZlciBhY3F1aXJlZFxuIik7CkBAIC0xMDE1 LDYgKzEwMjgsMTggQEAKIH0KICNlbmRpZiAvKiBEREIgKi8KIAorLyogVHJpbSB1c2VsZXNzIGdh cmJhZ2UgZnJvbSBmaWxlbmFtZXMuICovCitzdGF0aWMgY29uc3QgY2hhciAqCitmaXh1cF9maWxl bmFtZShjb25zdCBjaGFyICpmaWxlKQoreworCisJaWYgKGZpbGUgPT0gTlVMTCkKKwkJcmV0dXJu IChOVUxMKTsKKwl3aGlsZSAoc3RybmNtcChmaWxlLCAiLi4vIiwgMykgPT0gMCkKKwkJZmlsZSAr PSAzOworCXJldHVybiAoZmlsZSk7Cit9CisKIGludAogd2l0bmVzc19kZWZpbmVvcmRlcihzdHJ1 Y3QgbG9ja19vYmplY3QgKmxvY2sxLCBzdHJ1Y3QgbG9ja19vYmplY3QgKmxvY2syKQogewpAQCAt MTA3NSw5ICsxMTAwLDggQEAKIAkJICogYWxsIHNwaW4gbG9ja3MuCiAJCSAqLwogCQlpZiAodGQt PnRkX2NyaXRuZXN0ICE9IDAgJiYgIWtkYl9hY3RpdmUpCi0JCQlwYW5pYygiYmxvY2thYmxlIHNs ZWVwIGxvY2sgKCVzKSAlcyBAICVzOiVkIiwKLQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+ bG9fbmFtZSwKLQkJCSAgICBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCQl3aXRuZXNz X3BhbmljKCJibG9ja2FibGUgc2xlZXAgbG9jayAoJXMpICVzIEAgJXM6JWQiLAorCQkJICAgIGNs YXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7 CiAKIAkJLyoKIAkJICogSWYgdGhpcyBpcyB0aGUgZmlyc3QgbG9jayBhY3F1aXJlZCB0aGVuIGp1 c3QgcmV0dXJuIGFzCkBAIC0xMTE1LDIwICsxMTM5LDE4IEBACiAJCWlmICgobG9jazEtPmxpX2Zs YWdzICYgTElfRVhDTFVTSVZFKSAhPSAwICYmCiAJCSAgICAoZmxhZ3MgJiBMT1BfRVhDTFVTSVZF KSA9PSAwKSB7CiAJCQlwcmludGYoInNoYXJlZCBsb2NrIG9mICglcykgJXMgQCAlczolZFxuIiwK LQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwKLQkJCSAgICBmaXh1cF9maWxl bmFtZShmaWxlKSwgbGluZSk7CisJCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUs IGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAkJCXByaW50Zigid2hpbGUgZXhjbHVzaXZl bHkgbG9ja2VkIGZyb20gJXM6JWRcbiIsCiAJCQkgICAgZml4dXBfZmlsZW5hbWUobG9jazEtPmxp X2ZpbGUpLCBsb2NrMS0+bGlfbGluZSk7Ci0JCQlwYW5pYygic2hhcmUtPmV4Y2wiKTsKKwkJCXdp dG5lc3NfcGFuaWMoInNoYXJlLT5leGNsIik7CiAJCX0KIAkJaWYgKChsb2NrMS0+bGlfZmxhZ3Mg JiBMSV9FWENMVVNJVkUpID09IDAgJiYKIAkJICAgIChmbGFncyAmIExPUF9FWENMVVNJVkUpICE9 IDApIHsKIAkJCXByaW50ZigiZXhjbHVzaXZlIGxvY2sgb2YgKCVzKSAlcyBAICVzOiVkXG4iLAot CQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVu YW1lKGZpbGUpLCBsaW5lKTsKKwkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwg Zml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQkJcHJpbnRmKCJ3aGlsZSBzaGFyZSBsb2Nr ZWQgZnJvbSAlczolZFxuIiwKIAkJCSAgICBmaXh1cF9maWxlbmFtZShsb2NrMS0+bGlfZmlsZSks IGxvY2sxLT5saV9saW5lKTsKLQkJCXBhbmljKCJleGNsLT5zaGFyZSIpOworCQkJd2l0bmVzc19w YW5pYygiZXhjbC0+c2hhcmUiKTsKIAkJfQogCQlyZXR1cm47CiAJfQpAQCAtMTE4MCwxMiArMTIw MiwxMSBAQAogCQkJICAgICJhY3F1aXJpbmcgZHVwbGljYXRlIGxvY2sgb2Ygc2FtZSB0eXBlOiBc IiVzXCJcbiIsIAogCQkJICAgIHctPndfbmFtZSk7CiAJCQlwcmludGYoIiAxc3QgJXMgQCAlczol ZFxuIiwgcGxvY2stPmxpX2xvY2stPmxvX25hbWUsCi0JCQkgICAgZml4dXBfZmlsZW5hbWUocGxv Y2stPmxpX2ZpbGUpLCBwbG9jay0+bGlfbGluZSk7Ci0JCQlwcmludGYoIiAybmQgJXMgQCAlczol ZFxuIiwgbG9jay0+bG9fbmFtZSwKLQkJCSAgICBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7 CisJCQkgICAgICAgZml4dXBfZmlsZW5hbWUocGxvY2stPmxpX2ZpbGUpLCBwbG9jay0+bGlfbGlu ZSk7CisJCQlwcmludGYoIiAybmQgJXMgQCAlczolZFxuIiwgbG9jay0+bG9fbmFtZSwgZml4dXBf ZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQkJd2l0bmVzc19kZWJ1Z2dlcigxKTsKLQkJfSBlbHNl Ci0JCQltdHhfdW5sb2NrX3NwaW4oJndfbXR4KTsKKwkJICAgIH0gZWxzZQorCQkJICAgIG10eF91 bmxvY2tfc3Bpbigmd19tdHgpOwogCQlyZXR1cm47CiAJfQogCW10eF9hc3NlcnQoJndfbXR4LCBN QV9PV05FRCk7CkBAIC0xMzIzLDI0ICsxMzQ0LDE5IEBACiAJCQlpZiAoaSA8IDApIHsKIAkJCQlw cmludGYoIiAxc3QgJXAgJXMgKCVzKSBAICVzOiVkXG4iLAogCQkJCSAgICBsb2NrMS0+bGlfbG9j aywgbG9jazEtPmxpX2xvY2stPmxvX25hbWUsCi0JCQkJICAgIHcxLT53X25hbWUsIGZpeHVwX2Zp bGVuYW1lKGxvY2sxLT5saV9maWxlKSwKLQkJCQkgICAgbG9jazEtPmxpX2xpbmUpOworCQkJCSAg ICB3MS0+d19uYW1lLCBmaXh1cF9maWxlbmFtZShsb2NrMS0+bGlfZmlsZSksIGxvY2sxLT5saV9s aW5lKTsKIAkJCQlwcmludGYoIiAybmQgJXAgJXMgKCVzKSBAICVzOiVkXG4iLCBsb2NrLAotCQkJ CSAgICBsb2NrLT5sb19uYW1lLCB3LT53X25hbWUsCi0JCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZp bGUpLCBsaW5lKTsKKwkJCQkgICAgbG9jay0+bG9fbmFtZSwgdy0+d19uYW1lLCBmaXh1cF9maWxl bmFtZShmaWxlKSwgbGluZSk7CiAJCQl9IGVsc2UgewogCQkJCXByaW50ZigiIDFzdCAlcCAlcyAo JXMpIEAgJXM6JWRcbiIsCiAJCQkJICAgIGxvY2syLT5saV9sb2NrLCBsb2NrMi0+bGlfbG9jay0+ bG9fbmFtZSwKIAkJCQkgICAgbG9jazItPmxpX2xvY2stPmxvX3dpdG5lc3MtPndfbmFtZSwKLQkJ CQkgICAgZml4dXBfZmlsZW5hbWUobG9jazItPmxpX2ZpbGUpLAotCQkJCSAgICBsb2NrMi0+bGlf bGluZSk7CisJCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGxvY2syLT5saV9maWxlKSwgbG9jazItPmxp X2xpbmUpOwogCQkJCXByaW50ZigiIDJuZCAlcCAlcyAoJXMpIEAgJXM6JWRcbiIsCiAJCQkJICAg IGxvY2sxLT5saV9sb2NrLCBsb2NrMS0+bGlfbG9jay0+bG9fbmFtZSwKLQkJCQkgICAgdzEtPndf bmFtZSwgZml4dXBfZmlsZW5hbWUobG9jazEtPmxpX2ZpbGUpLAotCQkJCSAgICBsb2NrMS0+bGlf bGluZSk7CisJCQkJICAgIHcxLT53X25hbWUsIGZpeHVwX2ZpbGVuYW1lKGxvY2sxLT5saV9maWxl KSwgbG9jazEtPmxpX2xpbmUpOwogCQkJCXByaW50ZigiIDNyZCAlcCAlcyAoJXMpIEAgJXM6JWRc biIsIGxvY2ssCi0JCQkJICAgIGxvY2stPmxvX25hbWUsIHctPndfbmFtZSwKLQkJCQkgICAgZml4 dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOworCQkJCSAgICBsb2NrLT5sb19uYW1lLCB3LT53X25h bWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAkJCX0KIAkJCXdpdG5lc3NfZGVidWdn ZXIoMSk7CiAJCQlyZXR1cm47CkBAIC0xNDM1LDI5ICsxNDUxLDI0IEBACiAJY2xhc3MgPSBMT0NL X0NMQVNTKGxvY2spOwogCWlmICh3aXRuZXNzX3dhdGNoKSB7CiAJCWlmICgobG9jay0+bG9fZmxh Z3MgJiBMT19VUEdSQURBQkxFKSA9PSAwKQotCQkJcGFuaWMoInVwZ3JhZGUgb2Ygbm9uLXVwZ3Jh ZGFibGUgbG9jayAoJXMpICVzIEAgJXM6JWQiLAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2Nr LT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdpdG5l c3NfcGFuaWMoInVwZ3JhZGUgb2Ygbm9uLXVwZ3JhZGFibGUgbG9jayAoJXMpICVzIEAgJXM6JWQi LAorCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShm aWxlKSwgbGluZSk7CiAJCWlmICgoY2xhc3MtPmxjX2ZsYWdzICYgTENfU0xFRVBMT0NLKSA9PSAw KQotCQkJcGFuaWMoInVwZ3JhZGUgb2Ygbm9uLXNsZWVwIGxvY2sgKCVzKSAlcyBAICVzOiVkIiwK LQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwKLQkJCSAgICBmaXh1cF9maWxl bmFtZShmaWxlKSwgbGluZSk7CisJCQl3aXRuZXNzX3BhbmljKCJ1cGdyYWRlIG9mIG5vbi1zbGVl cCBsb2NrICglcykgJXMgQCAlczolZCIsCisJCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxv X25hbWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAl9CiAJaW5zdGFuY2UgPSBmaW5k X2luc3RhbmNlKGN1cnRocmVhZC0+dGRfc2xlZXBsb2NrcywgbG9jayk7CiAJaWYgKGluc3RhbmNl ID09IE5VTEwpCi0JCXBhbmljKCJ1cGdyYWRlIG9mIHVubG9ja2VkIGxvY2sgKCVzKSAlcyBAICVz OiVkIiwKLQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkgICAgZml4dXBf ZmlsZW5hbWUoZmlsZSksIGxpbmUpOworCQl3aXRuZXNzX3BhbmljKCJ1cGdyYWRlIG9mIHVubG9j a2VkIGxvY2sgKCVzKSAlcyBAICVzOiVkIiwKKwkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5s b19uYW1lLCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJaWYgKHdpdG5lc3Nfd2F0Y2gp IHsKIAkJaWYgKChpbnN0YW5jZS0+bGlfZmxhZ3MgJiBMSV9FWENMVVNJVkUpICE9IDApCi0JCQlw YW5pYygidXBncmFkZSBvZiBleGNsdXNpdmUgbG9jayAoJXMpICVzIEAgJXM6JWQiLAotCQkJICAg IGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZp bGUpLCBsaW5lKTsKKwkJCXdpdG5lc3NfcGFuaWMoInVwZ3JhZGUgb2YgZXhjbHVzaXZlIGxvY2sg KCVzKSAlcyBAICVzOiVkIiwKKwkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwg Zml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQlpZiAoKGluc3RhbmNlLT5saV9mbGFncyAm IExJX1JFQ1VSU0VNQVNLKSAhPSAwKQotCQkJcGFuaWMoInVwZ3JhZGUgb2YgcmVjdXJzZWQgbG9j ayAoJXMpICVzIHI9JWQgQCAlczolZCIsCisJCQl3aXRuZXNzX3BhbmljKCJ1cGdyYWRlIG9mIHJl Y3Vyc2VkIGxvY2sgKCVzKSAlcyByPSVkIEAgJXM6JWQiLAogCQkJICAgIGNsYXNzLT5sY19uYW1l LCBsb2NrLT5sb19uYW1lLAotCQkJICAgIGluc3RhbmNlLT5saV9mbGFncyAmIExJX1JFQ1VSU0VN QVNLLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCSAgICBpbnN0YW5j ZS0+bGlfZmxhZ3MgJiBMSV9SRUNVUlNFTUFTSywgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUp OwogCX0KIAlpbnN0YW5jZS0+bGlfZmxhZ3MgfD0gTElfRVhDTFVTSVZFOwogfQpAQCAtMTQ3NSwy OSArMTQ4NiwyNCBAQAogCWNsYXNzID0gTE9DS19DTEFTUyhsb2NrKTsKIAlpZiAod2l0bmVzc193 YXRjaCkgewogCQlpZiAoKGxvY2stPmxvX2ZsYWdzICYgTE9fVVBHUkFEQUJMRSkgPT0gMCkKLQkJ cGFuaWMoImRvd25ncmFkZSBvZiBub24tdXBncmFkYWJsZSBsb2NrICglcykgJXMgQCAlczolZCIs Ci0JCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsCi0JCQkgICAgZml4dXBfZmls ZW5hbWUoZmlsZSksIGxpbmUpOworCQl3aXRuZXNzX3BhbmljKCJkb3duZ3JhZGUgb2Ygbm9uLXVw Z3JhZGFibGUgbG9jayAoJXMpICVzIEAgJXM6JWQiLAorCQkJICAgIGNsYXNzLT5sY19uYW1lLCBs b2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJCWlmICgoY2xhc3Mt PmxjX2ZsYWdzICYgTENfU0xFRVBMT0NLKSA9PSAwKQotCQkJcGFuaWMoImRvd25ncmFkZSBvZiBu b24tc2xlZXAgbG9jayAoJXMpICVzIEAgJXM6JWQiLAotCQkJICAgIGNsYXNzLT5sY19uYW1lLCBs b2NrLT5sb19uYW1lLAotCQkJICAgIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKKwkJCXdp dG5lc3NfcGFuaWMoImRvd25ncmFkZSBvZiBub24tc2xlZXAgbG9jayAoJXMpICVzIEAgJXM6JWQi LAorCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShm aWxlKSwgbGluZSk7CiAJfQogCWluc3RhbmNlID0gZmluZF9pbnN0YW5jZShjdXJ0aHJlYWQtPnRk X3NsZWVwbG9ja3MsIGxvY2spOwogCWlmIChpbnN0YW5jZSA9PSBOVUxMKQotCQlwYW5pYygiZG93 bmdyYWRlIG9mIHVubG9ja2VkIGxvY2sgKCVzKSAlcyBAICVzOiVkIiwKLQkJICAgIGNsYXNzLT5s Y19uYW1lLCBsb2NrLT5sb19uYW1lLAotCQkgICAgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUp OworCQl3aXRuZXNzX3BhbmljKCJkb3duZ3JhZGUgb2YgdW5sb2NrZWQgbG9jayAoJXMpICVzIEAg JXM6JWQiLAorCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVu YW1lKGZpbGUpLCBsaW5lKTsKIAlpZiAod2l0bmVzc193YXRjaCkgewogCQlpZiAoKGluc3RhbmNl LT5saV9mbGFncyAmIExJX0VYQ0xVU0lWRSkgPT0gMCkKLQkJCXBhbmljKCJkb3duZ3JhZGUgb2Yg c2hhcmVkIGxvY2sgKCVzKSAlcyBAICVzOiVkIiwKLQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9j ay0+bG9fbmFtZSwKLQkJCSAgICBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCQl3aXRu ZXNzX3BhbmljKCJkb3duZ3JhZGUgb2Ygc2hhcmVkIGxvY2sgKCVzKSAlcyBAICVzOiVkIiwKKwkJ CSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSks IGxpbmUpOwogCQlpZiAoKGluc3RhbmNlLT5saV9mbGFncyAmIExJX1JFQ1VSU0VNQVNLKSAhPSAw KQotCQkJcGFuaWMoImRvd25ncmFkZSBvZiByZWN1cnNlZCBsb2NrICglcykgJXMgcj0lZCBAICVz OiVkIiwKKwkJCXdpdG5lc3NfcGFuaWMoImRvd25ncmFkZSBvZiByZWN1cnNlZCBsb2NrICglcykg JXMgcj0lZCBAICVzOiVkIiwKIAkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwK LQkJCSAgICBpbnN0YW5jZS0+bGlfZmxhZ3MgJiBMSV9SRUNVUlNFTUFTSywKLQkJCSAgICBmaXh1 cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCQkgICAgaW5zdGFuY2UtPmxpX2ZsYWdzICYgTElf UkVDVVJTRU1BU0ssIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAl9CiAJaW5zdGFuY2Ut PmxpX2ZsYWdzICY9IH5MSV9FWENMVVNJVkU7CiB9CkBAIC0xNTA2LDExICsxNTEyLDExIEBACiB3 aXRuZXNzX3VubG9jayhzdHJ1Y3QgbG9ja19vYmplY3QgKmxvY2ssIGludCBmbGFncywgY29uc3Qg Y2hhciAqZmlsZSwgaW50IGxpbmUpCiB7CiAJc3RydWN0IGxvY2tfbGlzdF9lbnRyeSAqKmxvY2tf bGlzdCwgKmxsZTsKLQlzdHJ1Y3QgbG9ja19pbnN0YW5jZSAqaW5zdGFuY2U7CisJc3RydWN0IGxv Y2tfaW5zdGFuY2UgKmluc3RhbmNlID0gTlVMTDsKIAlzdHJ1Y3QgbG9ja19jbGFzcyAqY2xhc3M7 CiAJc3RydWN0IHRocmVhZCAqdGQ7CiAJcmVnaXN0ZXJfdCBzOwotCWludCBpLCBqOworCWludCBp ID0gMCwgajsKIAogCWlmICh3aXRuZXNzX2NvbGQgfHwgbG9jay0+bG9fd2l0bmVzcyA9PSBOVUxM IHx8IHBhbmljc3RyICE9IE5VTEwpCiAJCXJldHVybjsKQEAgLTE1MzcsNyArMTU0Myw3IEBACiAJ ICogZXZlbnR1YWwgcmVnaXN0ZXIgbG9ja3MgYW5kIHJlbW92ZSB0aGVtLgogCSAqLwogCWlmICh3 aXRuZXNzX3dhdGNoID4gMCkKLQkJcGFuaWMoImxvY2sgKCVzKSAlcyBub3QgbG9ja2VkIEAgJXM6 JWQiLCBjbGFzcy0+bGNfbmFtZSwKKwkJd2l0bmVzc19wYW5pYygibG9jayAoJXMpICVzIG5vdCBs b2NrZWQgQCAlczolZCIsIGNsYXNzLT5sY19uYW1lLAogCQkgICAgbG9jay0+bG9fbmFtZSwgZml4 dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCWVsc2UKIAkJcmV0dXJuOwpAQCAtMTU1MCwxNiAr MTU1NiwxNSBAQAogCQkgICAgbG9jay0+bG9fbmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxp bmUpOwogCQlwcmludGYoIndoaWxlIGV4Y2x1c2l2ZWx5IGxvY2tlZCBmcm9tICVzOiVkXG4iLAog CQkgICAgZml4dXBfZmlsZW5hbWUoaW5zdGFuY2UtPmxpX2ZpbGUpLCBpbnN0YW5jZS0+bGlfbGlu ZSk7Ci0JCXBhbmljKCJleGNsLT51c2hhcmUiKTsKKwkJd2l0bmVzc19wYW5pYygiZXhjbC0+dXNo YXJlIik7CiAJfQogCWlmICgoaW5zdGFuY2UtPmxpX2ZsYWdzICYgTElfRVhDTFVTSVZFKSA9PSAw ICYmIHdpdG5lc3Nfd2F0Y2ggPiAwICYmCiAJICAgIChmbGFncyAmIExPUF9FWENMVVNJVkUpICE9 IDApIHsKIAkJcHJpbnRmKCJleGNsdXNpdmUgdW5sb2NrIG9mICglcykgJXMgQCAlczolZFxuIiwg Y2xhc3MtPmxjX25hbWUsCiAJCSAgICBsb2NrLT5sb19uYW1lLCBmaXh1cF9maWxlbmFtZShmaWxl KSwgbGluZSk7Ci0JCXByaW50Zigid2hpbGUgc2hhcmUgbG9ja2VkIGZyb20gJXM6JWRcbiIsCi0J CSAgICBmaXh1cF9maWxlbmFtZShpbnN0YW5jZS0+bGlfZmlsZSksCisJCXByaW50Zigid2hpbGUg c2hhcmUgbG9ja2VkIGZyb20gJXM6JWRcbiIsIGZpeHVwX2ZpbGVuYW1lKGluc3RhbmNlLT5saV9m aWxlKSwKIAkJICAgIGluc3RhbmNlLT5saV9saW5lKTsKLQkJcGFuaWMoInNoYXJlLT51ZXhjbCIp OworCQl3aXRuZXNzX3BhbmljKCJzaGFyZS0+dWV4Y2wiKTsKIAl9CiAJLyogSWYgd2UgYXJlIHJl Y3Vyc2VkLCB1bnJlY3Vyc2UuICovCiAJaWYgKChpbnN0YW5jZS0+bGlfZmxhZ3MgJiBMSV9SRUNV UlNFTUFTSykgPiAwKSB7CkBAIC0xNTczLDcgKzE1NzgsNyBAQAogCWlmICgoaW5zdGFuY2UtPmxp X2ZsYWdzICYgTElfTk9SRUxFQVNFKSAhPSAwICYmIHdpdG5lc3Nfd2F0Y2ggPiAwKSB7CiAJCXBy aW50ZigiZm9yYmlkZGVuIHVubG9jayBvZiAoJXMpICVzIEAgJXM6JWRcbiIsIGNsYXNzLT5sY19u YW1lLAogCQkgICAgbG9jay0+bG9fbmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwot CQlwYW5pYygibG9jayBtYXJrZWQgbm9yZWxlYXNlIik7CisJCXdpdG5lc3NfcGFuaWMoImxvY2sg bWFya2VkIG5vcmVsZWFzZSIpOwogCX0KIAogCS8qIE90aGVyd2lzZSwgcmVtb3ZlIHRoaXMgaXRl bSBmcm9tIHRoZSBsaXN0LiAqLwpAQCAtMTYyOCw3ICsxNjMzLDcgQEAKIAkJCQl3aXRuZXNzX2xp c3RfbG9jaygmbGxlLT5sbF9jaGlsZHJlbltpXSwgcHJpbnRmKTsKIAkJCQkKIAkJCX0KLQkJcGFu aWMoIlRocmVhZCAlcCBjYW5ub3QgZXhpdCB3aGlsZSBob2xkaW5nIHNsZWVwbG9ja3NcbiIsIHRk KTsKKwkJd2l0bmVzc19wYW5pYygiVGhyZWFkICVwIGNhbm5vdCBleGl0IHdoaWxlIGhvbGRpbmcg c2xlZXBsb2Nrc1xuIiwgdGQpOwogCX0KIAl3aXRuZXNzX2xvY2tfbGlzdF9mcmVlKGxsZSk7CiB9 CkBAIC0xNzA5LDcgKzE3MTQsNyBAQAogCX0gZWxzZQogCQlzY2hlZF91bnBpbigpOwogCWlmIChm bGFncyAmIFdBUk5fUEFOSUMgJiYgbikKLQkJcGFuaWMoIiVzIiwgX19mdW5jX18pOworCQl3aXRu ZXNzX3BhbmljKCIlcyIsIF9fZnVuY19fKTsKIAllbHNlCiAJCXdpdG5lc3NfZGVidWdnZXIobik7 CiAJcmV0dXJuIChuKTsKQEAgLTE3NTUsNyArMTc2MCw3IEBACiAJfSBlbHNlIGlmICgobG9ja19j bGFzcy0+bGNfZmxhZ3MgJiBMQ19TTEVFUExPQ0spKQogCQl0eXBlbGlzdCA9ICZ3X3NsZWVwOwog CWVsc2UKLQkJcGFuaWMoImxvY2sgY2xhc3MgJXMgaXMgbm90IHNsZWVwIG9yIHNwaW4iLAorCQl3 aXRuZXNzX3BhbmljKCJsb2NrIGNsYXNzICVzIGlzIG5vdCBzbGVlcCBvciBzcGluIiwKIAkJICAg IGxvY2tfY2xhc3MtPmxjX25hbWUpOwogCiAJbXR4X2xvY2tfc3Bpbigmd19tdHgpOwpAQCAtMTc4 Niw3ICsxNzkxLDcgQEAKIAl3LT53X3JlZmNvdW50Kys7CiAJbXR4X3VubG9ja19zcGluKCZ3X210 eCk7CiAJaWYgKGxvY2tfY2xhc3MgIT0gdy0+d19jbGFzcykKLQkJcGFuaWMoCisJCXdpdG5lc3Nf cGFuaWMoCiAJCQkibG9jayAoJXMpICVzIGRvZXMgbm90IG1hdGNoIGVhcmxpZXIgKCVzKSBsb2Nr IiwKIAkJCWRlc2NyaXB0aW9uLCBsb2NrX2NsYXNzLT5sY19uYW1lLAogCQkJdy0+d19jbGFzcy0+ bGNfbmFtZSk7CkBAIC0xOTIwLDcgKzE5MjUsNyBAQAogCWlmICghd2l0bmVzc19sb2NrX3R5cGVf ZXF1YWwocGFyZW50LCBjaGlsZCkpIHsKIAkJaWYgKHdpdG5lc3NfY29sZCA9PSAwKQogCQkJbXR4 X3VubG9ja19zcGluKCZ3X210eCk7Ci0JCXBhbmljKCIlczogcGFyZW50IFwiJXNcIiAoJXMpIGFu ZCBjaGlsZCBcIiVzXCIgKCVzKSBhcmUgbm90ICIKKwkJd2l0bmVzc19wYW5pYygiJXM6IHBhcmVu dCBcIiVzXCIgKCVzKSBhbmQgY2hpbGQgXCIlc1wiICglcykgYXJlIG5vdCAiCiAJCSAgICAidGhl IHNhbWUgbG9jayB0eXBlIiwgX19mdW5jX18sIHBhcmVudC0+d19uYW1lLAogCQkgICAgcGFyZW50 LT53X2NsYXNzLT5sY19uYW1lLCBjaGlsZC0+d19uYW1lLAogCQkgICAgY2hpbGQtPndfY2xhc3Mt PmxjX25hbWUpOwpAQCAtMjEwMiw4ICsyMTA3LDggQEAKIAlpZiAobG9jay0+bG9fd2l0bmVzcy0+ d19uYW1lICE9IGxvY2stPmxvX25hbWUpCiAJCXBybnQoIiAoJXMpIiwgbG9jay0+bG9fd2l0bmVz cy0+d19uYW1lKTsKIAlwcm50KCIgciA9ICVkICglcCkgbG9ja2VkIEAgJXM6JWRcbiIsCi0JICAg IGluc3RhbmNlLT5saV9mbGFncyAmIExJX1JFQ1VSU0VNQVNLLCBsb2NrLAotCSAgICBmaXh1cF9m aWxlbmFtZShpbnN0YW5jZS0+bGlfZmlsZSksIGluc3RhbmNlLT5saV9saW5lKTsKKwkgICAgaW5z dGFuY2UtPmxpX2ZsYWdzICYgTElfUkVDVVJTRU1BU0ssIGxvY2ssIGZpeHVwX2ZpbGVuYW1lKGlu c3RhbmNlLT5saV9maWxlKSwKKwkgICAgaW5zdGFuY2UtPmxpX2xpbmUpOwogfQogCiAjaWZkZWYg RERCCkBAIC0yMTc0LDEzICsyMTc5LDYgQEAKIAlzdHJ1Y3QgbG9ja19pbnN0YW5jZSAqaW5zdGFu Y2U7CiAJc3RydWN0IGxvY2tfY2xhc3MgKmNsYXNzOwogCi0JLyoKLQkgKiBUaGlzIGZ1bmN0aW9u IGlzIHVzZWQgaW5kZXBlbmRlbnRseSBpbiBsb2NraW5nIGNvZGUgdG8gZGVhbCB3aXRoCi0JICog R2lhbnQsIFNDSEVEVUxFUl9TVE9QUEVEKCkgY2hlY2sgY2FuIGJlIHJlbW92ZWQgaGVyZSBhZnRl ciBHaWFudAotCSAqIGlzIGdvbmUuCi0JICovCi0JaWYgKFNDSEVEVUxFUl9TVE9QUEVEKCkpCi0J CXJldHVybjsKIAlLQVNTRVJUKHdpdG5lc3NfY29sZCA9PSAwLCAoIiVzOiB3aXRuZXNzX2NvbGQi LCBfX2Z1bmNfXykpOwogCWlmIChsb2NrLT5sb193aXRuZXNzID09IE5VTEwgfHwgd2l0bmVzc193 YXRjaCA9PSAtMSB8fCBwYW5pY3N0ciAhPSBOVUxMKQogCQlyZXR1cm47CkBAIC0yMTk0LDcgKzIx OTIsNyBAQAogCX0KIAlpbnN0YW5jZSA9IGZpbmRfaW5zdGFuY2UobG9ja19saXN0LCBsb2NrKTsK IAlpZiAoaW5zdGFuY2UgPT0gTlVMTCkKLQkJcGFuaWMoIiVzOiBsb2NrICglcykgJXMgbm90IGxv Y2tlZCIsIF9fZnVuY19fLAorCQl3aXRuZXNzX3BhbmljKCIlczogbG9jayAoJXMpICVzIG5vdCBs b2NrZWQiLCBfX2Z1bmNfXywKIAkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lKTsK IAkqZmlsZXAgPSBpbnN0YW5jZS0+bGlfZmlsZTsKIAkqbGluZXAgPSBpbnN0YW5jZS0+bGlfbGlu ZTsKQEAgLTIyMDcsMTMgKzIyMDUsNiBAQAogCXN0cnVjdCBsb2NrX2luc3RhbmNlICppbnN0YW5j ZTsKIAlzdHJ1Y3QgbG9ja19jbGFzcyAqY2xhc3M7CiAKLQkvKgotCSAqIFRoaXMgZnVuY3Rpb24g aXMgdXNlZCBpbmRlcGVuZGVudGx5IGluIGxvY2tpbmcgY29kZSB0byBkZWFsIHdpdGgKLQkgKiBH aWFudCwgU0NIRURVTEVSX1NUT1BQRUQoKSBjaGVjayBjYW4gYmUgcmVtb3ZlZCBoZXJlIGFmdGVy IEdpYW50Ci0JICogaXMgZ29uZS4KLQkgKi8KLQlpZiAoU0NIRURVTEVSX1NUT1BQRUQoKSkKLQkJ cmV0dXJuOwogCUtBU1NFUlQod2l0bmVzc19jb2xkID09IDAsICgiJXM6IHdpdG5lc3NfY29sZCIs IF9fZnVuY19fKSk7CiAJaWYgKGxvY2stPmxvX3dpdG5lc3MgPT0gTlVMTCB8fCB3aXRuZXNzX3dh dGNoID09IC0xIHx8IHBhbmljc3RyICE9IE5VTEwpCiAJCXJldHVybjsKQEAgLTIyMjcsNyArMjIx OCw3IEBACiAJfQogCWluc3RhbmNlID0gZmluZF9pbnN0YW5jZShsb2NrX2xpc3QsIGxvY2spOwog CWlmIChpbnN0YW5jZSA9PSBOVUxMKQotCQlwYW5pYygiJXM6IGxvY2sgKCVzKSAlcyBub3QgbG9j a2VkIiwgX19mdW5jX18sCisJCXdpdG5lc3NfcGFuaWMoIiVzOiBsb2NrICglcykgJXMgbm90IGxv Y2tlZCIsIF9fZnVuY19fLAogCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUpOwog CWxvY2stPmxvX3dpdG5lc3MtPndfZmlsZSA9IGZpbGU7CiAJbG9jay0+bG9fd2l0bmVzcy0+d19s aW5lID0gbGluZTsKQEAgLTIyMzksNyArMjIzMCw3IEBACiB3aXRuZXNzX2Fzc2VydChzdHJ1Y3Qg bG9ja19vYmplY3QgKmxvY2ssIGludCBmbGFncywgY29uc3QgY2hhciAqZmlsZSwgaW50IGxpbmUp CiB7CiAjaWZkZWYgSU5WQVJJQU5UX1NVUFBPUlQKLQlzdHJ1Y3QgbG9ja19pbnN0YW5jZSAqaW5z dGFuY2U7CisJc3RydWN0IGxvY2tfaW5zdGFuY2UgKmluc3RhbmNlID0gTlVMTDsKIAlzdHJ1Y3Qg bG9ja19jbGFzcyAqY2xhc3M7CiAKIAlpZiAobG9jay0+bG9fd2l0bmVzcyA9PSBOVUxMIHx8IHdp dG5lc3Nfd2F0Y2ggPCAxIHx8IHBhbmljc3RyICE9IE5VTEwpCkBAIC0yMjUwLDE1ICsyMjQxLDE0 IEBACiAJZWxzZSBpZiAoKGNsYXNzLT5sY19mbGFncyAmIExDX1NQSU5MT0NLKSAhPSAwKQogCQlp bnN0YW5jZSA9IGZpbmRfaW5zdGFuY2UoUENQVV9HRVQoc3BpbmxvY2tzKSwgbG9jayk7CiAJZWxz ZSB7Ci0JCXBhbmljKCJMb2NrICglcykgJXMgaXMgbm90IHNsZWVwIG9yIHNwaW4hIiwKKwkJd2l0 bmVzc19wYW5pYygiTG9jayAoJXMpICVzIGlzIG5vdCBzbGVlcCBvciBzcGluISIsCiAJCSAgICBj bGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSk7CiAJfQogCXN3aXRjaCAoZmxhZ3MpIHsKIAlj YXNlIExBX1VOTE9DS0VEOgogCQlpZiAoaW5zdGFuY2UgIT0gTlVMTCkKLQkJCXBhbmljKCJMb2Nr ICglcykgJXMgbG9ja2VkIEAgJXM6JWQuIiwKLQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+ bG9fbmFtZSwKLQkJCSAgICBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCQl3aXRuZXNz X3BhbmljKCJMb2NrICglcykgJXMgbG9ja2VkIEAgJXM6JWQuIiwKKwkJCSAgICBjbGFzcy0+bGNf bmFtZSwgbG9jay0+bG9fbmFtZSwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCQlicmVh azsKIAljYXNlIExBX0xPQ0tFRDoKIAljYXNlIExBX0xPQ0tFRCB8IExBX1JFQ1VSU0VEOgpAQCAt MjI3MCwzNSArMjI2MCwyOSBAQAogCWNhc2UgTEFfWExPQ0tFRCB8IExBX1JFQ1VSU0VEOgogCWNh c2UgTEFfWExPQ0tFRCB8IExBX05PVFJFQ1VSU0VEOgogCQlpZiAoaW5zdGFuY2UgPT0gTlVMTCkg ewotCQkJcGFuaWMoIkxvY2sgKCVzKSAlcyBub3QgbG9ja2VkIEAgJXM6JWQuIiwKLQkJCSAgICBj bGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwKLQkJCSAgICBmaXh1cF9maWxlbmFtZShmaWxl KSwgbGluZSk7CisJCQl3aXRuZXNzX3BhbmljKCJMb2NrICglcykgJXMgbm90IGxvY2tlZCBAICVz OiVkLiIsCisJCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVu YW1lKGZpbGUpLCBsaW5lKTsKIAkJCWJyZWFrOwogCQl9CiAJCWlmICgoZmxhZ3MgJiBMQV9YTE9D S0VEKSAhPSAwICYmCiAJCSAgICAoaW5zdGFuY2UtPmxpX2ZsYWdzICYgTElfRVhDTFVTSVZFKSA9 PSAwKQotCQkJcGFuaWMoIkxvY2sgKCVzKSAlcyBub3QgZXhjbHVzaXZlbHkgbG9ja2VkIEAgJXM6 JWQuIiwKLQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwKLQkJCSAgICBmaXh1 cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCQl3aXRuZXNzX3BhbmljKCJMb2NrICglcykgJXMg bm90IGV4Y2x1c2l2ZWx5IGxvY2tlZCBAICVzOiVkLiIsCisJCQkgICAgY2xhc3MtPmxjX25hbWUs IGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAkJaWYgKChmbGFn cyAmIExBX1NMT0NLRUQpICE9IDAgJiYKIAkJICAgIChpbnN0YW5jZS0+bGlfZmxhZ3MgJiBMSV9F WENMVVNJVkUpICE9IDApCi0JCQlwYW5pYygiTG9jayAoJXMpICVzIGV4Y2x1c2l2ZWx5IGxvY2tl ZCBAICVzOiVkLiIsCi0JCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsCi0JCQkg ICAgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOworCQkJd2l0bmVzc19wYW5pYygiTG9jayAo JXMpICVzIGV4Y2x1c2l2ZWx5IGxvY2tlZCBAICVzOiVkLiIsCisJCQkgICAgY2xhc3MtPmxjX25h bWUsIGxvY2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAkJaWYgKChm bGFncyAmIExBX1JFQ1VSU0VEKSAhPSAwICYmCiAJCSAgICAoaW5zdGFuY2UtPmxpX2ZsYWdzICYg TElfUkVDVVJTRU1BU0spID09IDApCi0JCQlwYW5pYygiTG9jayAoJXMpICVzIG5vdCByZWN1cnNl ZCBAICVzOiVkLiIsCi0JCQkgICAgY2xhc3MtPmxjX25hbWUsIGxvY2stPmxvX25hbWUsCi0JCQkg ICAgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOworCQkJd2l0bmVzc19wYW5pYygiTG9jayAo JXMpICVzIG5vdCByZWN1cnNlZCBAICVzOiVkLiIsCisJCQkgICAgY2xhc3MtPmxjX25hbWUsIGxv Y2stPmxvX25hbWUsIGZpeHVwX2ZpbGVuYW1lKGZpbGUpLCBsaW5lKTsKIAkJaWYgKChmbGFncyAm IExBX05PVFJFQ1VSU0VEKSAhPSAwICYmCiAJCSAgICAoaW5zdGFuY2UtPmxpX2ZsYWdzICYgTElf UkVDVVJTRU1BU0spICE9IDApCi0JCQlwYW5pYygiTG9jayAoJXMpICVzIHJlY3Vyc2VkIEAgJXM6 JWQuIiwKLQkJCSAgICBjbGFzcy0+bGNfbmFtZSwgbG9jay0+bG9fbmFtZSwKLQkJCSAgICBmaXh1 cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CisJCQl3aXRuZXNzX3BhbmljKCJMb2NrICglcykgJXMg cmVjdXJzZWQgQCAlczolZC4iLAorCQkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1l LCBmaXh1cF9maWxlbmFtZShmaWxlKSwgbGluZSk7CiAJCWJyZWFrOwogCWRlZmF1bHQ6Ci0JCXBh bmljKCJJbnZhbGlkIGxvY2sgYXNzZXJ0aW9uIGF0ICVzOiVkLiIsCi0JCSAgICBmaXh1cF9maWxl bmFtZShmaWxlKSwgbGluZSk7CisJCXdpdG5lc3NfcGFuaWMoIkludmFsaWQgbG9jayBhc3NlcnRp b24gYXQgJXM6JWQuIiwgZml4dXBfZmlsZW5hbWUoZmlsZSksIGxpbmUpOwogCiAJfQogI2VuZGlm CS8qIElOVkFSSUFOVF9TVVBQT1JUICovCkBAIC0yMzIzLDcgKzIzMDcsNyBAQAogCX0KIAlpbnN0 YW5jZSA9IGZpbmRfaW5zdGFuY2UobG9ja19saXN0LCBsb2NrKTsKIAlpZiAoaW5zdGFuY2UgPT0g TlVMTCkKLQkJcGFuaWMoIiVzOiBsb2NrICglcykgJXMgbm90IGxvY2tlZCIsIF9fZnVuY19fLAor CQl3aXRuZXNzX3BhbmljKCIlczogbG9jayAoJXMpICVzIG5vdCBsb2NrZWQiLCBfX2Z1bmNfXywK IAkJICAgIGNsYXNzLT5sY19uYW1lLCBsb2NrLT5sb19uYW1lKTsKIAogCWlmIChzZXQpCkluZGV4 OiBzeXMvbmV0L2lmLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldC9pZi5jCShyZXZpc2lvbiAyNDE0 OTEpCisrKyBzeXMvbmV0L2lmLmMJKHdvcmtpbmcgY29weSkKQEAgLTgyMSw3ICs4MjEsOSBAQAog aWZfZGV0YWNoKHN0cnVjdCBpZm5ldCAqaWZwKQogewogCisJQ1VSVk5FVF9TRVRfUVVJRVQoaWZw LT5pZl92bmV0KTsKIAlpZl9kZXRhY2hfaW50ZXJuYWwoaWZwLCAwKTsKKwlDVVJWTkVUX1JFU1RP UkUoKTsKIH0KIAogc3RhdGljIHZvaWQK --e89a8fb202eaccab6a04ce829ea2-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 11:45:03 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AA2E3BA4 for ; Thu, 15 Nov 2012 11:45:03 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 569B38FC0C for ; Thu, 15 Nov 2012 11:45:02 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TYxsW-0007ul-AU for freebsd-hackers@freebsd.org; Thu, 15 Nov 2012 12:45:04 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Nov 2012 12:45:04 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 15 Nov 2012 12:45:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Subject: Re: Give users a hint when their locate database is too small. Date: Thu, 15 Nov 2012 12:43:55 +0100 Lines: 65 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig09F4CC78D9BDE9AE0890B4B4" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 In-Reply-To: X-Enigmail-Version: 1.4.3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 11:45:03 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09F4CC78D9BDE9AE0890B4B4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 13/11/2012 04:07, Eitan Adler wrote: > What do people think of this? Maybe /usr/libexec/locate.updatedb is a > better pointer? =2E.. or, make it automagical by adding a rc.d script which will test the= database exists (or is "too small") and start locate.updatedb as a background / detached process? Orthogonal to that, I'm always surprise by how fast Linux's updatedb is. I don't know if it is due to file system differences or some fundamental differences (incremental updates?), but updatedb on Linux usually takes 1-3 seconds, while on FreeBSD it is 10-120 seconds. > commit fb03b777daf2c69bb9612902e38fdb25b256be72 > Author: Eitan Adler > Date: Mon Nov 12 22:05:55 2012 -0500 >=20 > Give users a hint when their locate database is too small. >=20 > Reviwed by: ??? > Approved by: ??? > MFC after: 3 weeks >=20 > diff --git a/usr.bin/locate/locate/locate.c b/usr.bin/locate/locate/loc= ate.c > index b0faefb..f0c8c37 100644 > --- a/usr.bin/locate/locate/locate.c > +++ b/usr.bin/locate/locate/locate.c > @@ -292,7 +292,7 @@ search_mmap(db, s) > err(1, "`%s'", db); > len =3D sb.st_size; > if (len < (2*NBG)) > - errx(1, "database too small: %s", db); > + errx(1, "database too small: %s\nTry running > /etc/periodic/weekly/310.locate", db); >=20 > if ((p =3D mmap((caddr_t)0, (size_t)len, > PROT_READ, MAP_SHARED, >=20 >=20 --------------enig09F4CC78D9BDE9AE0890B4B4 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.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCk1XsACgkQ/QjVBj3/HSy1zACglc4uBDxpT+44uR0cDg7BVXSG JNIAoJkfXsC84LutQ3rnoH/2OlrjYgoY =5YYu -----END PGP SIGNATURE----- --------------enig09F4CC78D9BDE9AE0890B4B4-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 13:06:12 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3E09FA5; Thu, 15 Nov 2012 13:06:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 084FE8FC12; Thu, 15 Nov 2012 13:06:10 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA02734; Thu, 15 Nov 2012 15:06:09 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TYz8z-000Nc0-7A; Thu, 15 Nov 2012 15:06:09 +0200 Message-ID: <50A4E8C0.5030608@FreeBSD.org> Date: Thu, 15 Nov 2012 15:06:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org Subject: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 13:06:12 -0000 To people knowing the code, do the following documentation changes look correct? --- a/share/man/man9/lock.9 +++ b/share/man/man9/lock.9 @@ -148,7 +148,9 @@ Flags indicating what action is to be taken. .Bl -tag -width ".Dv LK_CANRECURSE" .It Dv LK_SHARED Acquire a shared lock. -If an exclusive lock is currently held, it will be downgraded. +If an exclusive lock is currently held, +.Dv EDEADLK +will be returned. .It Dv LK_EXCLUSIVE Acquire an exclusive lock. If an exclusive lock is already held, and @@ -158,7 +160,8 @@ is not set, the system will .It Dv LK_DOWNGRADE Downgrade exclusive lock to a shared lock. Downgrading a shared lock is not permitted. -If an exclusive lock has been recursed, all references will be downgraded. +If an exclusive lock has been recursed, the system will +.Xr panic 9 . .It Dv LK_UPGRADE Upgrade a shared lock to an exclusive lock. If this call fails, the shared lock is lost. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 13:27:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90B2F502; Thu, 15 Nov 2012 13:27:35 +0000 (UTC) (envelope-from giovanni.trematerra@gmail.com) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2A18FC0C; Thu, 15 Nov 2012 13:27:34 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so1277747qcs.13 for ; Thu, 15 Nov 2012 05:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kjp9lZN2nPy3aTeCO34QPAJrwBvbhN2Gcdqfz/q9588=; b=MelmHWl1d6Ri1A+qjO/0uSUpCfC8YkuYIL12cqmGtERcuuG+89aJ4Iz//rHTQVIQEG 7HIZN1leMQyrDq0H7ymD5KpszHo5Qkow0Py2J88liumlEJadAv9MCYu0dNedvgyR0IqF Z6THrbrqwkEjMTcqXghg0yjMwVJ1Lsj7uU/KOMYS1jmF/sYZFAXdJXgpUfoJ7Wr8kNgA 2oMa1ODCxilaEZnJVzW3HPVA+/CmoeTSfD4vJrHAcOgT+aZiJCaucrFreofYdiGDSYVk 5rXpjlEibKhdoheRuNUX1izGEhqXmGCNG7OouSlIXc4cvHFUkBa7jS4g9pIVPLgoJpTI 3b4A== MIME-Version: 1.0 Received: by 10.224.194.134 with SMTP id dy6mr1044256qab.81.1352986053363; Thu, 15 Nov 2012 05:27:33 -0800 (PST) Received: by 10.229.117.1 with HTTP; Thu, 15 Nov 2012 05:27:33 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 14:27:33 +0100 Message-ID: Subject: Re: [RFQ] make witness panic an option From: Giovanni Trematerra To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Thu, 15 Nov 2012 13:33:56 +0000 Cc: "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 13:27:35 -0000 On Thu, Nov 15, 2012 at 7:15 AM, Adrian Chadd wrote: > Hi all, > > When debugging and writing wireless drivers/stack code, I like to > sprinkle lots of locking assertions everywhere. However, this does > cause things to panic quite often during active development. > > This patch (against stable/9) makes the actual panic itself > configurable. It still prints the message regardless. > This has allowed me to sprinkle more locking assertions everywhere to > investigate whether particular paths have been hit or not. I don't > necessarily want those to panic the kernel. > > I'd like everyone to consider this for FreeBSD-HEAD. I really do think that is a very bad idea. When a locking assertion fails you have just to stop your mind and think what's wrong, no way to postpone on this. -- Gianni From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 16:37:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BE3E36B5; Thu, 15 Nov 2012 16:37:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 85F538FC0C; Thu, 15 Nov 2012 16:37:51 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so1279899pab.13 for ; Thu, 15 Nov 2012 08:37:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Hax9OoliXpccxGrtLR2vkRCIXBxNG1yKwlvMk0RUXRc=; b=YUxsYsXpQYRrHi8ba8waS60qRly4mwRxmt8wvejHSObD5gp5uo0QLvl3gZUbH1yQQ9 mVZY647PS18OjpK3XpxHTyVDLu49JITMnAiZVqAppZB/nmBQxlvqYs6yi3yLM3ndQuEf Q6InGF7axUveopUVKrQATrsmzCNqTrT7/CiwJya0rjRFcFWk9cU0XLg3nsWWD/PKImGU rZo0u8E65t34ewA2anP9XQpPBqGbpVkAlCRyEVhh6unq8HmWKIh3wARjvy2ci1NdBefm XEA7z72KoiK4iF5oXVrJcpM63EEGltKsFabjzkX6v+WvMCKKM/fxYGt9C/NlGwccISku vTcA== MIME-Version: 1.0 Received: by 10.66.85.134 with SMTP id h6mr4714259paz.36.1352997471336; Thu, 15 Nov 2012 08:37:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 15 Nov 2012 08:37:51 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 08:37:51 -0800 X-Google-Sender-Auth: t1znI8gbjtaOqflWpgDKI8n8H7s Message-ID: Subject: Re: [RFQ] make witness panic an option From: Adrian Chadd To: Giovanni Trematerra Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 16:37:51 -0000 On 15 November 2012 05:27, Giovanni Trematerra wrote: > I really do think that is a very bad idea. > When a locking assertion fails you have just to stop your mind and > think what's wrong, > no way to postpone on this. Not all witness panics are actually fatal. For a developer who is sufficiently cluey in their area, they are quite likely able to just stare at the code paths for a while to figure out why the incorrectness occured. As I said, I do this primarily so I can sprinkle lots of lock owned/unowned assertions around my driver(s) and then use that to catch when things aren't being correct. Having to reboot upon _every_ lock assertion quickly got old. Adrian From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 16:39:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 23A7792D; Thu, 15 Nov 2012 16:39:58 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3821C8FC08; Thu, 15 Nov 2012 16:39:56 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1730127lah.13 for ; Thu, 15 Nov 2012 08:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Dm8wzhvVjwZHDAUWyfOaV34sC0YK7PLTTtxqJBJVjVY=; b=amuffdSsc1OvbxmqYBOusT1dRYIxigWVRJhkxeOAz6eW/B4XtnKqqZVLyPoIx0ksx1 xOYfhsZDY2wjXAheIZsS82CYN0m+h2UNBltPaP2e8MbwONrUTTrS9KhVaMXr0qIDZCW9 uxEMUQOR0EVPaNOZogn16DGk+/pH8cH4cH+70NovUaDTMnQH6N+UPQKJljnUmcxFXxfX naN3IGKih5RzoK3CqdTGicBr3to3GdW9pzFLN6frmANy16zceCzn6b6N59z5KdAI+7cz 13/3LLffBkLS6It5WH/LMoaRvyXQcCk14Vm9edOWF1Mco+zVxWJHtf2oCnw7JyXetIkC 67XA== MIME-Version: 1.0 Received: by 10.152.132.3 with SMTP id oq3mr1598733lab.18.1352997596012; Thu, 15 Nov 2012 08:39:56 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 08:39:55 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 16:39:55 +0000 X-Google-Sender-Auth: l4M5Za3t4iOfBIVQh5SEs-Izwcs Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" , Giovanni Trematerra , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 16:39:58 -0000 On 11/15/12, Adrian Chadd wrote: > On 15 November 2012 05:27, Giovanni Trematerra > wrote: > >> I really do think that is a very bad idea. >> When a locking assertion fails you have just to stop your mind and >> think what's wrong, >> no way to postpone on this. > > Not all witness panics are actually fatal. For a developer who is > sufficiently cluey in their area, they are quite likely able to just > stare at the code paths for a while to figure out why the > incorrectness occured. The problem is that such mechanism can be abused, just like the BLESSING one and that's why this is disabled by default. I believe having a mechanism to use printf for witness is not a good idea. > As I said, I do this primarily so I can sprinkle lots of lock > owned/unowned assertions around my driver(s) and then use that to > catch when things aren't being correct. Having to reboot upon _every_ > lock assertion quickly got old. You can use it as a local patch then. This is not really the usual way to develop locking policies. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 17:32:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3F336AEB; Thu, 15 Nov 2012 17:32:21 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by mx1.freebsd.org (Postfix) with ESMTP id 09B1F8FC12; Thu, 15 Nov 2012 17:32:20 +0000 (UTC) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 2951346023A; Thu, 15 Nov 2012 11:32:20 -0600 (CST) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 26D764601DA; Thu, 15 Nov 2012 11:32:20 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id bXWmeBH51LAk; Thu, 15 Nov 2012 11:32:20 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 8168B460197; Thu, 15 Nov 2012 11:32:19 -0600 (CST) Message-ID: <50A52722.7050100@rice.edu> Date: Thu, 15 Nov 2012 11:32:18 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Memory reserves or lack thereof References: <20121112133638.GZ73505@kib.kiev.ua> <1352755682.93266.YahooMailClassic@web181701.mail.ne1.yahoo.com> <20121112214808.GH73505@kib.kiev.ua> <50A181C9.7030209@rice.edu> <20121113115445.GK73505@kib.kiev.ua> In-Reply-To: <20121113115445.GK73505@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, pho@freebsd.org, Sushanth Rai , StevenSears , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:32:21 -0000 On 11/13/2012 05:54, Konstantin Belousov wrote: > On Mon, Nov 12, 2012 at 05:10:01PM -0600, Alan Cox wrote: >> On 11/12/2012 3:48 PM, Konstantin Belousov wrote: >>> On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote: >>>> This patch still doesn't address the issue of M_NOWAIT calls driving >>>> the memory the all the way down to 2 pages, right ? It would be nice to >>>> have M_NOWAIT just do non-sleep version of M_WAITOK and M_USE_RESERVE >>>> flag to dig deep. >>> This is out of scope of the change. But it is required for any further >>> adjustements. >> I would suggest a somewhat different response: >> >> The patch does make M_NOWAIT into a "non-sleep version of M_WAITOK" and >> does reintroduce M_USE_RESERVE as a way to specify "dig deep". >> >> Currently, both M_NOWAIT and M_WAITOK can drive the cache/free memory >> down to two pages. The effect of the patch is to stop M_NOWAIT at two >> pages rather than allowing it to continue to zero pages. >> >> When you say, "This is out of scope ...", I believe that you are >> referring to changing two pages into something larger. I agree that >> this is out of scope for the current change. > I referred exactly to the difference between M_USE_RESERVE set or not. > IMO this is what was asked by the question author. So yes, my mean of > the 'out of scope' is about tweaking the 'two pages reserve' in some > way. Since M_USE_RESERVE is no longer deprecated in HEAD, here is my proposed man page update to malloc(9): Index: share/man/man9/malloc.9 =================================================================== --- share/man/man9/malloc.9 (revision 243091) +++ share/man/man9/malloc.9 (working copy) @@ -29,7 +29,7 @@ .\" $NetBSD: malloc.9,v 1.3 1996/11/11 00:05:11 lukem Exp $ .\" $FreeBSD$ .\" -.Dd January 28, 2012 +.Dd November 15, 2012 .Dt MALLOC 9 .Os .Sh NAME @@ -153,13 +153,12 @@ if .Dv M_WAITOK is specified. .It Dv M_USE_RESERVE -Indicates that the system can dig into its reserve in order to obtain the -requested memory. -This option used to be called -.Dv M_KERNEL -but has been renamed to something more obvious. -This option has been deprecated and is slowly being removed from the kernel, -and so should not be used with any new programming. +Indicates that the system can use its reserve of memory to satisfy the +request. +This option should only be used in combination with +.Dv M_NOWAIT +when an allocation failure cannot be tolerated by the caller without +catastrophic effects on the system. .El .Pp Exactly one of either From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 17:37:28 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1B4C4C68; Thu, 15 Nov 2012 17:37:28 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 5987F8FC08; Thu, 15 Nov 2012 17:37:26 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.318.4; Thu, 15 Nov 2012 18:36:14 +0100 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Nov 2012 18:36:14 +0100 Received: from localhost ([161.53.19.8]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Nov 2012 18:36:14 +0100 From: Marko Zec To: Adrian Chadd Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Thu, 15 Nov 2012 18:36:04 +0100 User-Agent: KMail/1.9.10 References: <201210291115.23845.zec@fer.hr> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="Boundary-00=_EgSpQL+nIDcE64N" Message-ID: <201211151836.04709.zec@fer.hr> X-OriginalArrivalTime: 15 Nov 2012 17:36:14.0549 (UTC) FILETIME=[B5EE8050:01CDC357] Cc: freebsd-net@freebsd.org, Hans Petter Selasky , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:37:28 -0000 --Boundary-00=_EgSpQL+nIDcE64N Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline On Thursday 15 November 2012 07:18:31 Adrian Chadd wrote: > Hi, > > Here's what I have thus far. Please ignore the device_printf() change. > > This works for me, both for hotplug cardbus wireless devices as well > as (inadvertently!) a USB bluetooth device. > > What do you think? It looks that you've hit the right spot to set curvnet context in device_probe_and_attach(). Could you try out a slightly revised verstion (attached) - this one also removes now redundant curvnet setting from linker routines (kldload / kldunload), and adds a few extra bits which might be necessary for a broader range of drivers to work. Note that I haven't tested this myself as I don't have a -CURRENT machine ATM, but a similar patch for 8.3 apparently works fine, though I don't have hotplugabble network cards to play with (neither cardbus nor USB)... Cheers, Marko --Boundary-00=_EgSpQL+nIDcE64N Content-Type: text/x-diff; charset="iso 8859-15"; name="hotplug_vnet_20121115.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="hotplug_vnet_20121115.diff" Index: sys/kern/subr_bus.c =================================================================== --- sys/kern/subr_bus.c (revision 243091) +++ sys/kern/subr_bus.c (working copy) @@ -53,6 +53,8 @@ #include #include +#include + #include #include @@ -2735,7 +2737,11 @@ return (0); else if (error != 0) return (error); - return (device_attach(dev)); + + CURVNET_SET_QUIET(vnet0); + error = device_attach(dev); + CURVNET_RESTORE(); + return (error); } /** Index: sys/kern/kern_linker.c =================================================================== --- sys/kern/kern_linker.c (revision 243091) +++ sys/kern/kern_linker.c (working copy) @@ -53,8 +53,6 @@ #include #include -#include - #include #include "linker_if.h" @@ -1019,12 +1017,6 @@ return (error); /* - * It is possible that kldloaded module will attach a new ifnet, - * so vnet context must be set when this ocurs. - */ - CURVNET_SET(TD_TO_VNET(td)); - - /* * If file does not contain a qualified name or any dot in it * (kldname.ko, or kldname.ver.ko) treat it as an interface * name. @@ -1041,7 +1033,7 @@ error = linker_load_module(kldname, modname, NULL, NULL, &lf); if (error) { KLD_UNLOCK(); - goto done; + return (error); } lf->userrefs++; if (fileid != NULL) @@ -1055,9 +1047,6 @@ #else KLD_UNLOCK(); #endif - -done: - CURVNET_RESTORE(); return (error); } @@ -1095,7 +1084,6 @@ if ((error = priv_check(td, PRIV_KLD_UNLOAD)) != 0) return (error); - CURVNET_SET(TD_TO_VNET(td)); KLD_LOCK(); lf = linker_find_file_by_id(fileid); if (lf) { @@ -1137,7 +1125,6 @@ #else KLD_UNLOCK(); #endif - CURVNET_RESTORE(); return (error); } Index: sys/netgraph/bluetooth/socket/ng_btsocket.c =================================================================== --- sys/netgraph/bluetooth/socket/ng_btsocket.c (revision 243091) +++ sys/netgraph/bluetooth/socket/ng_btsocket.c (working copy) @@ -46,6 +46,8 @@ #include #include +#include + #include #include #include @@ -285,4 +287,4 @@ return (error); } /* ng_btsocket_modevent */ -DOMAIN_SET(ng_btsocket_); +VNET_DOMAIN_SET(ng_btsocket_); Index: sys/net/if.c =================================================================== --- sys/net/if.c (revision 243091) +++ sys/net/if.c (working copy) @@ -504,6 +504,7 @@ ifp->if_flags |= IFF_DYING; /* XXX: Locking */ + CURVNET_SET_QUIET(ifp->if_vnet); IFNET_WLOCK(); KASSERT(ifp == ifnet_byindex_locked(ifp->if_index), ("%s: freeing unallocated ifnet", ifp->if_xname)); @@ -511,9 +512,9 @@ ifindex_free_locked(ifp->if_index); IFNET_WUNLOCK(); - if (!refcount_release(&ifp->if_refcount)) - return; - if_free_internal(ifp); + if (refcount_release(&ifp->if_refcount)) + if_free_internal(ifp); + CURVNET_RESTORE(); } /* @@ -793,7 +794,9 @@ if_detach(struct ifnet *ifp) { + CURVNET_SET_QUIET(ifp->if_vnet); if_detach_internal(ifp, 0); + CURVNET_RESTORE(); } static void --Boundary-00=_EgSpQL+nIDcE64N-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 17:39:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C439FE05; Thu, 15 Nov 2012 17:39:46 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 903FB8FC12; Thu, 15 Nov 2012 17:39:46 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qAFHdcDt039031; Thu, 15 Nov 2012 10:39:38 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qAFHdZMB024995; Thu, 15 Nov 2012 10:39:35 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: [RFQ] make witness panic an option From: Ian Lepore To: Adrian Chadd In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Nov 2012 10:39:35 -0700 Message-ID: <1353001175.1217.153.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:39:46 -0000 On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: > Hi all, > > When debugging and writing wireless drivers/stack code, I like to > sprinkle lots of locking assertions everywhere. However, this does > cause things to panic quite often during active development. > > This patch (against stable/9) makes the actual panic itself > configurable. It still prints the message regardless. > > This has allowed me to sprinkle more locking assertions everywhere to > investigate whether particular paths have been hit or not. I don't > necessarily want those to panic the kernel. > > I'd like everyone to consider this for FreeBSD-HEAD. > > Thanks! I strongly support this, because I'm tired of having to hack it in by hand every time I need it. You can't boot an arm platform right now (on freebsd 8, 9, or 10) without a LOR very early in the boot. Once you get past that, 2 or 3 device drivers I use panic way before we even get to mounting root. Those panics can clearly be ignored, because we've been shipping products for years based on this code. (It's on my to-do list to fix them, but more pressing problems are higher on the list.) When a new problem crops up that isn't harmless, it totally sucks that I can't just turn on witness without first hacking the code to make the known problems non-panicky. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 17:48:00 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A824975; Thu, 15 Nov 2012 17:48:00 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id BF46C8FC12; Thu, 15 Nov 2012 17:47:59 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1803763lah.13 for ; Thu, 15 Nov 2012 09:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Xw6bdC+I6eFvkTXqwe+Mo9bEXEeVNz0MqNR4heZsnOk=; b=N9Gwly5kod5mO29CnLO8nyvOhkfhF556UHnKZi/wd0FLvllKajx+KSHvHsm3GkYa97 VcnnV3sDXLoXSuaxN5IOwNMtrrrBEw1RFlIXgDpsVES0itXR9d96T5QSPOc6ictejUl0 1u5/VOQNi7l2P7lJzoxP0jbjTApgK4TdYPxXdId6hI9R1g7MQJRx7CzXoRGi02pGneqL aRJcM9jpRVodpD1KgMcNmk2yBtupKINTxcb3rhUv1sp676evlItueRQHXBmbfDpXihze 0TxbD2BEC4iYA5DyZbsePWfHjRwA2Vi61zhjCRRjSM58OyjLZUq1MwP/WQDwvX7/60ye DCuQ== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr1839112lab.15.1353001678357; Thu, 15 Nov 2012 09:47:58 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 09:47:58 -0800 (PST) In-Reply-To: <1353001175.1217.153.camel@revolution.hippie.lan> References: <1353001175.1217.153.camel@revolution.hippie.lan> Date: Thu, 15 Nov 2012 17:47:58 +0000 X-Google-Sender-Auth: acsIoPDz87qrn1kfVH81V7-EOkQ Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Ian Lepore Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Adrian Chadd , freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:48:00 -0000 On 11/15/12, Ian Lepore wrote: > On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: >> Hi all, >> >> When debugging and writing wireless drivers/stack code, I like to >> sprinkle lots of locking assertions everywhere. However, this does >> cause things to panic quite often during active development. >> >> This patch (against stable/9) makes the actual panic itself >> configurable. It still prints the message regardless. >> >> This has allowed me to sprinkle more locking assertions everywhere to >> investigate whether particular paths have been hit or not. I don't >> necessarily want those to panic the kernel. >> >> I'd like everyone to consider this for FreeBSD-HEAD. >> >> Thanks! > > I strongly support this, because I'm tired of having to hack it in by > hand every time I need it. > > You can't boot an arm platform right now (on freebsd 8, 9, or 10) > without a LOR very early in the boot. Once you get past that, 2 or 3 > device drivers I use panic way before we even get to mounting root. > Those panics can clearly be ignored, because we've been shipping > products for years based on this code. (It's on my to-do list to fix > them, but more pressing problems are higher on the list.) This is a ridicolous motivation. What are the panics in question? Why they are not fixed yet? Without WITNESS_KDB you should not panic even in cases where WITNESS yells. So if you do, it means there is a more subdole breakage going on here. Do you really think that an abusable mechanism will help here rather than fixing the actual problems? > When a new problem crops up that isn't harmless, it totally sucks that I > can't just turn on witness without first hacking the code to make the > known problems non-panicky. I really don't understand what are these "harmless problems" here. I just know one and it is between the dirhash lock and the bufwait lock for UFS, which is carefully documented in the code comments. All the others cases haven't been analyzed deeply enough to quantify them as "harmless". Can you please make real examples? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 17:56:24 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3CBF29D for ; Thu, 15 Nov 2012 17:56:23 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id A537B8FC14 for ; Thu, 15 Nov 2012 17:56:23 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so2409833oag.13 for ; Thu, 15 Nov 2012 09:56:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=Q8SFrS7WLIfT9llpZ/gg0GR2wFSWpUMEED98gONNncI=; b=L4oHlgxKV/uYmCGap7vFNxxc9yj8pf1wPMQ/E0rFSoRPkAlCpEdjYDnGRjSqucEoFr OgwrlB9HXn33zD+MgtvJsuI677U+uKobP2tUBRFI3x3EwUf3jJmbEpl8TYQPJjN5PyBr P0M8vt1Uh+eCa3sZ9BIpumOictAkpy2Q6W0mig1f32IzN48xguZeEnMmvlNyw6zeOA0O JZJnyELCb1zG3ODmzOiLHAWbrxXYeYFWlwAJfXQ3auwSB1NmnlabHofQxk8H1gbsSxes OCJIKNa+UIvG8a/M9dKJW6WtVDt1oMz/hwu34HS75q98M7yd6b5b0RI92kQBXwgNd4Gh 1hvQ== Received: by 10.60.10.133 with SMTP id i5mr1574894oeb.11.1353002182724; Thu, 15 Nov 2012 09:56:22 -0800 (PST) Received: from [10.30.101.53] ([209.117.142.2]) by mx.google.com with ESMTPS id m8sm12902611oeb.3.2012.11.15.09.56.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 15 Nov 2012 09:56:21 -0800 (PST) Sender: Warner Losh Subject: Re: [RFQ] make witness panic an option Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: Date: Thu, 15 Nov 2012 10:56:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> References: <1353001175.1217.153.camel@revolution.hippie.lan> To: attilio@FreeBSD.org X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQmSwLPuMypES8ja2cHJ1nzIsffgVbdDtBnp+r8cH7mCpLt82C6AKIRmmKwU8cbD7QZF/Rnh Cc: Ian Lepore , Adrian Chadd , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:56:24 -0000 On Nov 15, 2012, at 10:47 AM, Attilio Rao wrote: > On 11/15/12, Ian Lepore wrote: >> On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: >>> Hi all, >>>=20 >>> When debugging and writing wireless drivers/stack code, I like to >>> sprinkle lots of locking assertions everywhere. However, this does >>> cause things to panic quite often during active development. >>>=20 >>> This patch (against stable/9) makes the actual panic itself >>> configurable. It still prints the message regardless. >>>=20 >>> This has allowed me to sprinkle more locking assertions everywhere = to >>> investigate whether particular paths have been hit or not. I don't >>> necessarily want those to panic the kernel. >>>=20 >>> I'd like everyone to consider this for FreeBSD-HEAD. >>>=20 >>> Thanks! >>=20 >> I strongly support this, because I'm tired of having to hack it in by >> hand every time I need it. >>=20 >> You can't boot an arm platform right now (on freebsd 8, 9, or 10) >> without a LOR very early in the boot. Once you get past that, 2 or 3 >> device drivers I use panic way before we even get to mounting root. >> Those panics can clearly be ignored, because we've been shipping >> products for years based on this code. (It's on my to-do list to fix >> them, but more pressing problems are higher on the list.) >=20 > This is a ridicolous motivation. > What are the panics in question? Why they are not fixed yet? > Without WITNESS_KDB you should not panic even in cases where WITNESS > yells. So if you do, it means there is a more subdole breakage going > on here. >=20 > Do you really think that an abusable mechanism will help here rather > than fixing the actual problems? >=20 >> When a new problem crops up that isn't harmless, it totally sucks = that I >> can't just turn on witness without first hacking the code to make the >> known problems non-panicky. >=20 > I really don't understand what are these "harmless problems" here. > I just know one and it is between the dirhash lock and the bufwait > lock for UFS, which is carefully documented in the code comments. All > the others cases haven't been analyzed deeply enough to quantify them > as "harmless". >=20 > Can you please make real examples? It sounds like he's more worried about introducing LoRs into his = wireless code. They are harmless, for him, and he can fix them by = reloading the driver. They are only harmful if he loses a race. Warner= From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 17:58:30 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 410E643E; Thu, 15 Nov 2012 17:58:30 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 447438FC0C; Thu, 15 Nov 2012 17:58:28 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so1891590lbb.13 for ; Thu, 15 Nov 2012 09:58:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=/784YJ7P0phbTjZnjIudSY1gbTQjewTS+Tc82oaldHY=; b=ZYIXLC5POxipwbcNZys+dSrFMEwu1MeF4EZneJo3NuD+9wESecjwsP2rc9aWUgWuDm gER40RsNvquk67EU377fzkbwhp4S9DXY3MktXfH5vAxJASmFII3gPGp9/aKf+cW3DkuN 5rkIwRHJN+Be777VrgVd/9J0/a3YP84khxxUfzE4cDQ+VC5kKUrQRsTvdEmflQF+rS2F jh//SWHM/2Gwr77bnHR3osvT5nhaCp6VTKdJOmcBNcw6oUbZkDVrNI3HJt+bdFz95nmB ezUHQMk0gYbefFP5Jj1Hc9J9wbfR4szsqpPbdd73XuKsVZC2LVhQMsOP8gcMKfMC0WfR RzfQ== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr1866385lab.15.1353002307844; Thu, 15 Nov 2012 09:58:27 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 09:58:27 -0800 (PST) In-Reply-To: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 17:58:27 +0000 X-Google-Sender-Auth: jS2zDfgxw6VU2nTA6v7jwLNjc20 Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Warner Losh Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , Adrian Chadd , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:58:30 -0000 On 11/15/12, Warner Losh wrote: > > On Nov 15, 2012, at 10:47 AM, Attilio Rao wrote: > >> On 11/15/12, Ian Lepore wrote: >>> On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: >>>> Hi all, >>>> >>>> When debugging and writing wireless drivers/stack code, I like to >>>> sprinkle lots of locking assertions everywhere. However, this does >>>> cause things to panic quite often during active development. >>>> >>>> This patch (against stable/9) makes the actual panic itself >>>> configurable. It still prints the message regardless. >>>> >>>> This has allowed me to sprinkle more locking assertions everywhere to >>>> investigate whether particular paths have been hit or not. I don't >>>> necessarily want those to panic the kernel. >>>> >>>> I'd like everyone to consider this for FreeBSD-HEAD. >>>> >>>> Thanks! >>> >>> I strongly support this, because I'm tired of having to hack it in by >>> hand every time I need it. >>> >>> You can't boot an arm platform right now (on freebsd 8, 9, or 10) >>> without a LOR very early in the boot. Once you get past that, 2 or 3 >>> device drivers I use panic way before we even get to mounting root. >>> Those panics can clearly be ignored, because we've been shipping >>> products for years based on this code. (It's on my to-do list to fix >>> them, but more pressing problems are higher on the list.) >> >> This is a ridicolous motivation. >> What are the panics in question? Why they are not fixed yet? >> Without WITNESS_KDB you should not panic even in cases where WITNESS >> yells. So if you do, it means there is a more subdole breakage going >> on here. >> >> Do you really think that an abusable mechanism will help here rather >> than fixing the actual problems? >> >>> When a new problem crops up that isn't harmless, it totally sucks that I >>> can't just turn on witness without first hacking the code to make the >>> known problems non-panicky. >> >> I really don't understand what are these "harmless problems" here. >> I just know one and it is between the dirhash lock and the bufwait >> lock for UFS, which is carefully documented in the code comments. All >> the others cases haven't been analyzed deeply enough to quantify them >> as "harmless". >> >> Can you please make real examples? > > It sounds like he's more worried about introducing LoRs into his wireless > code. They are harmless, for him, and he can fix them by reloading the > driver. They are only harmful if he loses a race. Without WITNESS_KDB the kernel won't panic if this is really the case, if it is only about LOR yelling. Otherwise the breakage is more serious and I would like to see a real case example. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 17:59:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 930BB5D5; Thu, 15 Nov 2012 17:59:14 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 52DCD8FC08; Thu, 15 Nov 2012 17:59:14 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so827459dad.13 for ; Thu, 15 Nov 2012 09:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lsTSqNwiglElUieJ8bqooKQr4sX4OF18lf04F75MTy8=; b=S8mPUyxGDmIVc8HeV1VfUdXHyup/tYBUkHsd3yqpmnN7IZPruYAPeG4wDDEG/+VytK 0LbCnfDICDl3dBD9K+4cgOMIhygxEc5BtYssIzW8xRC44egjO4HNM65b5tU9D3ME9pSZ eHPCfbq/IXmsRPLBnUcGx43QUzRvv5IKebGokwaSrfYjIWAXOsvu/CWtypTueDHr/RBs EfK8a7NOb6bEdfWzHj51MczjofdPEgNLG/m852o0Xx5w5pQZjD5WOwHoEyk5l6zX6bn+ TPHGsPqULygUHSaRs6UAsDvPKP+juAJF0+zaKPKv4PVH3uOBFUUkcoPMBPNBkPFKVAxO iokg== MIME-Version: 1.0 Received: by 10.68.247.134 with SMTP id ye6mr1210085pbc.69.1353002348592; Thu, 15 Nov 2012 09:59:08 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 15 Nov 2012 09:59:08 -0800 (PST) In-Reply-To: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 09:59:08 -0800 X-Google-Sender-Auth: od1Pefj0sjviGAww4NVES9DFaL4 Message-ID: Subject: Re: [RFQ] make witness panic an option From: Adrian Chadd To: Warner Losh Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, Ian Lepore , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 17:59:14 -0000 On 15 November 2012 09:56, Warner Losh wrote: >> Do you really think that an abusable mechanism will help here rather > It sounds like he's more worried about introducing LoRs into his wireless code. They are harmless, for him, and he can fix them by reloading the driver. They are only harmful if he loses a race. LOR's and lock assertions. Ie, I want to find out at run time that a lock wasnt' held at a certain position but continue soldiering on. That's how I've been finding out all of the races in net80211/ath, as there wasn't locking where there needed to be. Adrian From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 18:01:19 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E347678E; Thu, 15 Nov 2012 18:01:19 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id E8C6E8FC0C; Thu, 15 Nov 2012 18:01:17 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so1894894lbb.13 for ; Thu, 15 Nov 2012 10:01:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=47n18/O51NP7s5CydvLVUh0eppMNfXXPtS1svfyXOOg=; b=tB/cY1xKjHlShukor721m4HLSpkLxrNFUaOLsNOJDWZb5xZd0vM/sZ7dByyd4rur/B B29ORtErxXYPAVEge6mgvag4/IQ4PuWoQBHENjcS2BtGNGyWiEqLQZ8vIzib9QksD89j 1mdRhl3KksKXKvaTJC8W47oKCVXh3BqprvENuRn2cuCmdAIJC5F61EcUX48S4OYahnEM HOViSfVAvJDkL/o5le6/rE8zInKBnIY6aGzYmAEGoI4BpakMNwqtoZMXNE2RwiKetUx/ 9s04vLB6IwQfs/XB5rZ3GQ1duclDsbF1FclbM6+Wj0W1NYsnIoQ9u8nCx9B+0zc5Cpba 258g== MIME-Version: 1.0 Received: by 10.112.47.129 with SMTP id d1mr906520lbn.115.1353002476703; Thu, 15 Nov 2012 10:01:16 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 10:01:16 -0800 (PST) In-Reply-To: References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 18:01:16 +0000 X-Google-Sender-Auth: ffz8GaTNpAB9qgttem20d2ZLAM0 Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:01:20 -0000 On 11/15/12, Adrian Chadd wrote: > On 15 November 2012 09:56, Warner Losh wrote: > >>> Do you really think that an abusable mechanism will help here rather > >> It sounds like he's more worried about introducing LoRs into his wireless >> code. They are harmless, for him, and he can fix them by reloading the >> driver. They are only harmful if he loses a race. > > LOR's and lock assertions. Ie, I want to find out at run time that a > lock wasnt' held at a certain position but continue soldiering on. > That's how I've been finding out all of the races in net80211/ath, as > there wasn't locking where there needed to be. I think that your worries are focused more around the latter than the former, which can be easilly shut down already today. And frankly I will never be in favor of a patch that automatically shutdowns lock assertion. Please patch your local code to do so but don't add any generic/upstream/all-around mechanism for that. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 18:05:39 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C804AA93; Thu, 15 Nov 2012 18:05:39 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 861758FC19; Thu, 15 Nov 2012 18:05:39 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so1343688pab.13 for ; Thu, 15 Nov 2012 10:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=5KiudfFWpVUT8SO8AmCj9ZeGusK0Nw9XGqKBQy9KIZ0=; b=Dqeh9DiGVXhCRc3MIvG5i6b4OMDmILGrom9UMGYuZDxxD7PMUtns+pDmSQDeEif49S 7Sy439g9aaGwsmO48Xox3h5ncsPgnGtJQGIMmYtGbR5HMznGKjRi37yb1zHNfQgozL6i 7k3LzzUJeXyp0mIM4pL6Zeccfbof70PC0gKTJ/FDAl0XJDs3GOfWaciTQ2zuXkw4vORX xWu9Q2glY7pgSlV1w1j7M1PdUTJcCOwPwWk1EmrXMTimOWjqn0Pcr/rXGLUYj2bThcla NrujuhQfysOFfWoQrD3Vfmh/fLy1dwfzDcgy9dbHWLyNz8s31Yo6vC7fNRitkqk8Y05r HL+A== MIME-Version: 1.0 Received: by 10.68.238.199 with SMTP id vm7mr6959752pbc.105.1353002739276; Thu, 15 Nov 2012 10:05:39 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 15 Nov 2012 10:05:39 -0800 (PST) In-Reply-To: References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 10:05:39 -0800 X-Google-Sender-Auth: eeSF1SKe-_FUXeAsxEMyAhRsFpA Message-ID: Subject: Re: [RFQ] make witness panic an option From: Adrian Chadd To: attilio@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Ian Lepore , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:05:39 -0000 On 15 November 2012 10:01, Attilio Rao wrote: > I think that your worries are focused more around the latter than the > former, which can be easilly shut down already today. > > And frankly I will never be in favor of a patch that automatically > shutdowns lock assertion. Please patch your local code to do so but > don't add any generic/upstream/all-around mechanism for that. Would a comprimise be ok? Ie, if I pushed everything but the sysctl upstream, and just defaulted it to always panic? That way my diff wouldn't have to be a big thing; I'd just add the sysctl. adrian From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 18:10:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E9147196; Thu, 15 Nov 2012 18:10:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id F2F138FC20; Thu, 15 Nov 2012 18:10:51 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1827087lah.13 for ; Thu, 15 Nov 2012 10:10:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LEWTr6tRSOnHjaTKdYVhTzng2rbGRQeojE+a+UG+OjE=; b=EikVC4ZmvKF47uo6JHKwdrpbgmn/pyHX4WWZ6K3niB07mVxoJv3/iy7IITGE4RCtqx QxsPJ1je/VXFOr2fkFDYE8bUJ4JTyM5VLtAztIYTCaM4QZBID50ANdH0W9sA7OopnBgs WzajBSb2DQdQULYNr2waFyqvCr3ZCExrpDKvrXUVCh2wi2mNv5X6biBRqaW/Ye0aSt5/ Y+yemPOGJCLxW7IkXbuZukfjd//nPk3n8UEGO3FbgsFhllPnPjLCxiNDceds5YgL/IZU gvZc8AOj8EOqS+DSs1PMrLv6p2FYJLai+SOSYpIasjrH9J10pUx4tL1ronP2uS/wZUVE zWEQ== MIME-Version: 1.0 Received: by 10.112.36.200 with SMTP id s8mr947677lbj.92.1353003050811; Thu, 15 Nov 2012 10:10:50 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 10:10:50 -0800 (PST) In-Reply-To: References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> Date: Thu, 15 Nov 2012 18:10:50 +0000 X-Google-Sender-Auth: TBPzVA_QUUO44JqNNX09ms-iIoE Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:10:53 -0000 On 11/15/12, Adrian Chadd wrote: > On 15 November 2012 10:01, Attilio Rao wrote: >> I think that your worries are focused more around the latter than the >> former, which can be easilly shut down already today. >> >> And frankly I will never be in favor of a patch that automatically >> shutdowns lock assertion. Please patch your local code to do so but >> don't add any generic/upstream/all-around mechanism for that. > > Would a comprimise be ok? Ie, if I pushed everything but the sysctl > upstream, and just defaulted it to always panic? > > That way my diff wouldn't have to be a big thing; I'd just add the sysctl. I cannot forbid you from doing anything, I'm just giving you my opinion as the person who co-authored current WITNESS and locking primitives code. I think what you want to do is dangerous and highly abusable, so I'm not in favor of it at all, in whatever form it is. I understand you want to minimize your development patchset with upstream, but I think this is certainly not the way to go. That's also why I never formalized the BLESSING mechanism in WITNESS, for example. I already see WITNESS_KDB as an abuse, but at least until we have a way to make specific LOR (based on file/line, unfortunately) to be marked as "harmless" there is no way we can get rid of WITNESS_KDB. Said all that, you are free to do what you want, but if you commit anything in this area make sure your patch is reviewed by someone else and to state my firm disagreement with this approach in the commit message. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 18:22:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 153AC9DF; Thu, 15 Nov 2012 18:22:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 5E3CB8FC15; Thu, 15 Nov 2012 18:22:01 +0000 (UTC) Received: from tom.home (localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qAFILr7Q071890; Thu, 15 Nov 2012 20:21:53 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.1 kib.kiev.ua qAFILr7Q071890 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qAFILrQ5071889; Thu, 15 Nov 2012 20:21:53 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 15 Nov 2012 20:21:53 +0200 From: Konstantin Belousov To: Alan Cox Subject: Re: Memory reserves or lack thereof Message-ID: <20121115182153.GF73505@kib.kiev.ua> References: <20121112133638.GZ73505@kib.kiev.ua> <1352755682.93266.YahooMailClassic@web181701.mail.ne1.yahoo.com> <20121112214808.GH73505@kib.kiev.ua> <50A181C9.7030209@rice.edu> <20121113115445.GK73505@kib.kiev.ua> <50A52722.7050100@rice.edu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SYqiNNNZhxFUWlBJ" Content-Disposition: inline In-Reply-To: <50A52722.7050100@rice.edu> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: alc@freebsd.org, pho@freebsd.org, Sushanth Rai , StevenSears , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:22:02 -0000 --SYqiNNNZhxFUWlBJ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 15, 2012 at 11:32:18AM -0600, Alan Cox wrote: > On 11/13/2012 05:54, Konstantin Belousov wrote: > > On Mon, Nov 12, 2012 at 05:10:01PM -0600, Alan Cox wrote: > >> On 11/12/2012 3:48 PM, Konstantin Belousov wrote: > >>> On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote: > >>>> This patch still doesn't address the issue of M_NOWAIT calls driving > >>>> the memory the all the way down to 2 pages, right ? It would be nice= to > >>>> have M_NOWAIT just do non-sleep version of M_WAITOK and M_USE_RESERVE > >>>> flag to dig deep. > >>> This is out of scope of the change. But it is required for any further > >>> adjustements. > >> I would suggest a somewhat different response: > >> > >> The patch does make M_NOWAIT into a "non-sleep version of M_WAITOK" an= d=20 > >> does reintroduce M_USE_RESERVE as a way to specify "dig deep". > >> > >> Currently, both M_NOWAIT and M_WAITOK can drive the cache/free memory= =20 > >> down to two pages. The effect of the patch is to stop M_NOWAIT at two= =20 > >> pages rather than allowing it to continue to zero pages. > >> > >> When you say, "This is out of scope ...", I believe that you are=20 > >> referring to changing two pages into something larger. I agree that= =20 > >> this is out of scope for the current change. > > I referred exactly to the difference between M_USE_RESERVE set or not. > > IMO this is what was asked by the question author. So yes, my mean of > > the 'out of scope' is about tweaking the 'two pages reserve' in some > > way. >=20 > Since M_USE_RESERVE is no longer deprecated in HEAD, here is my proposed > man page update to malloc(9): >=20 > Index: share/man/man9/malloc.9 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- share/man/man9/malloc.9 (revision 243091) > +++ share/man/man9/malloc.9 (working copy) > @@ -29,7 +29,7 @@ > .\" $NetBSD: malloc.9,v 1.3 1996/11/11 00:05:11 lukem Exp $ > .\" $FreeBSD$ > .\" > -.Dd January 28, 2012 > +.Dd November 15, 2012 > .Dt MALLOC 9 > .Os > .Sh NAME > @@ -153,13 +153,12 @@ if > .Dv M_WAITOK > is specified. > .It Dv M_USE_RESERVE > -Indicates that the system can dig into its reserve in order to obtain the > -requested memory. > -This option used to be called > -.Dv M_KERNEL > -but has been renamed to something more obvious. > -This option has been deprecated and is slowly being removed from the > kernel, > -and so should not be used with any new programming. > +Indicates that the system can use its reserve of memory to satisfy the > +request. > +This option should only be used in combination with > +.Dv M_NOWAIT > +when an allocation failure cannot be tolerated by the caller without > +catastrophic effects on the system. > .El > .Pp > Exactly one of either The text looks fine. Shouldn't the requirement for M_USE_RESERVE be also expressed in KASSERT, like this: diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h index d9e4692..f8a4f70 100644 --- a/sys/vm/vm_page.h +++ b/sys/vm/vm_page.h @@ -353,6 +351,9 @@ malloc2vm_flags(int malloc_flags) { int pflags; =20 + KASSERT((malloc_flags & M_USE_RESERVE) =3D=3D 0 || + (malloc_flags & M_NOWAIT) !=3D 0, + ("M_USE_RESERVE requires M_NOWAIT")); pflags =3D (malloc_flags & M_USE_RESERVE) !=3D 0 ? VM_ALLOC_INTERRUPT : VM_ALLOC_SYSTEM; if ((malloc_flags & M_ZERO) !=3D 0) I understand that this could be added to places of the allocator's entries, but I think that the page allocations are fine too. --SYqiNNNZhxFUWlBJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlClMsEACgkQC3+MBN1Mb4j0IgCg13XFT6XbCsDMN5WoBBDH9PqB ryAAnRYQkuydqqqPVjv2NnCGa+i/QIKQ =iLp8 -----END PGP SIGNATURE----- --SYqiNNNZhxFUWlBJ-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 18:32:03 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BCA60D51; Thu, 15 Nov 2012 18:32:03 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh11.mail.rice.edu (mh11.mail.rice.edu [128.42.199.30]) by mx1.freebsd.org (Postfix) with ESMTP id 86D148FC15; Thu, 15 Nov 2012 18:32:03 +0000 (UTC) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id D73684C04EC; Thu, 15 Nov 2012 12:31:56 -0600 (CST) Received: from mh11.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh11.mail.rice.edu (Postfix) with ESMTP id D56514C04D3; Thu, 15 Nov 2012 12:31:56 -0600 (CST) X-Virus-Scanned: by amavis-2.7.0 at mh11.mail.rice.edu, auth channel Received: from mh11.mail.rice.edu ([127.0.0.1]) by mh11.mail.rice.edu (mh11.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id TfXv_PcrEhDC; Thu, 15 Nov 2012 12:31:56 -0600 (CST) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh11.mail.rice.edu (Postfix) with ESMTPSA id 37F3E4C04DB; Thu, 15 Nov 2012 12:31:56 -0600 (CST) Message-ID: <50A5351B.3030108@rice.edu> Date: Thu, 15 Nov 2012 12:31:55 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:16.0) Gecko/20121111 Thunderbird/16.0.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Memory reserves or lack thereof References: <20121112133638.GZ73505@kib.kiev.ua> <1352755682.93266.YahooMailClassic@web181701.mail.ne1.yahoo.com> <20121112214808.GH73505@kib.kiev.ua> <50A181C9.7030209@rice.edu> <20121113115445.GK73505@kib.kiev.ua> <50A52722.7050100@rice.edu> <20121115182153.GF73505@kib.kiev.ua> In-Reply-To: <20121115182153.GF73505@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, pho@freebsd.org, Sushanth Rai , StevenSears , "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:32:03 -0000 On 11/15/2012 12:21, Konstantin Belousov wrote: > On Thu, Nov 15, 2012 at 11:32:18AM -0600, Alan Cox wrote: >> On 11/13/2012 05:54, Konstantin Belousov wrote: >>> On Mon, Nov 12, 2012 at 05:10:01PM -0600, Alan Cox wrote: >>>> On 11/12/2012 3:48 PM, Konstantin Belousov wrote: >>>>> On Mon, Nov 12, 2012 at 01:28:02PM -0800, Sushanth Rai wrote: >>>>>> This patch still doesn't address the issue of M_NOWAIT calls driving >>>>>> the memory the all the way down to 2 pages, right ? It would be nice to >>>>>> have M_NOWAIT just do non-sleep version of M_WAITOK and M_USE_RESERVE >>>>>> flag to dig deep. >>>>> This is out of scope of the change. But it is required for any further >>>>> adjustements. >>>> I would suggest a somewhat different response: >>>> >>>> The patch does make M_NOWAIT into a "non-sleep version of M_WAITOK" and >>>> does reintroduce M_USE_RESERVE as a way to specify "dig deep". >>>> >>>> Currently, both M_NOWAIT and M_WAITOK can drive the cache/free memory >>>> down to two pages. The effect of the patch is to stop M_NOWAIT at two >>>> pages rather than allowing it to continue to zero pages. >>>> >>>> When you say, "This is out of scope ...", I believe that you are >>>> referring to changing two pages into something larger. I agree that >>>> this is out of scope for the current change. >>> I referred exactly to the difference between M_USE_RESERVE set or not. >>> IMO this is what was asked by the question author. So yes, my mean of >>> the 'out of scope' is about tweaking the 'two pages reserve' in some >>> way. >> Since M_USE_RESERVE is no longer deprecated in HEAD, here is my proposed >> man page update to malloc(9): >> >> Index: share/man/man9/malloc.9 >> =================================================================== >> --- share/man/man9/malloc.9 (revision 243091) >> +++ share/man/man9/malloc.9 (working copy) >> @@ -29,7 +29,7 @@ >> .\" $NetBSD: malloc.9,v 1.3 1996/11/11 00:05:11 lukem Exp $ >> .\" $FreeBSD$ >> .\" >> -.Dd January 28, 2012 >> +.Dd November 15, 2012 >> .Dt MALLOC 9 >> .Os >> .Sh NAME >> @@ -153,13 +153,12 @@ if >> .Dv M_WAITOK >> is specified. >> .It Dv M_USE_RESERVE >> -Indicates that the system can dig into its reserve in order to obtain the >> -requested memory. >> -This option used to be called >> -.Dv M_KERNEL >> -but has been renamed to something more obvious. >> -This option has been deprecated and is slowly being removed from the >> kernel, >> -and so should not be used with any new programming. >> +Indicates that the system can use its reserve of memory to satisfy the >> +request. >> +This option should only be used in combination with >> +.Dv M_NOWAIT >> +when an allocation failure cannot be tolerated by the caller without >> +catastrophic effects on the system. >> .El >> .Pp >> Exactly one of either > The text looks fine. Shouldn't the requirement for M_USE_RESERVE be also > expressed in KASSERT, like this: > > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > index d9e4692..f8a4f70 100644 > --- a/sys/vm/vm_page.h > +++ b/sys/vm/vm_page.h > @@ -353,6 +351,9 @@ malloc2vm_flags(int malloc_flags) > { > int pflags; > > + KASSERT((malloc_flags & M_USE_RESERVE) == 0 || > + (malloc_flags & M_NOWAIT) != 0, > + ("M_USE_RESERVE requires M_NOWAIT")); > pflags = (malloc_flags & M_USE_RESERVE) != 0 ? VM_ALLOC_INTERRUPT : > VM_ALLOC_SYSTEM; > if ((malloc_flags & M_ZERO) != 0) > > I understand that this could be added to places of the allocator's entries, > but I think that the page allocations are fine too. Yes, please do that. Alan From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 18:32:11 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2CCCD54 for ; Thu, 15 Nov 2012 18:32:10 +0000 (UTC) (envelope-from postmaster@mailpod.hostingplatform.com) Received: from atl4mhob11.myregisteredsite.com (atl4mhob11.myregisteredsite.com [209.17.115.49]) by mx1.freebsd.org (Postfix) with ESMTP id 9F0688FC13 for ; Thu, 15 Nov 2012 18:32:10 +0000 (UTC) Received: from mailpod1.hostingplatform.com (mailpod1.networksolutionsemail.com [206.188.198.65]) by atl4mhob11.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAFIW9gE007307 for ; Thu, 15 Nov 2012 13:32:09 -0500 Received: (qmail 20751 invoked by uid 0); 15 Nov 2012 16:06:01 -0000 Received: (qmail 31192 invoked by uid 0); 15 Nov 2012 14:59:01 -0000 Received: (qmail 1296 invoked by uid 0); 15 Nov 2012 13:06:34 -0000 Received: from unknown (HELO atl4mhib28.myregisteredsite.com) (209) by 0 with SMTP; 15 Nov 2012 13:06:34 -0000 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by atl4mhib28.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAFD6XM4012868 for ; Thu, 15 Nov 2012 08:06:33 -0500 Received: from hub.freebsd.org (hub.FreeBSD.org [8.8.178.136]) by mx2.freebsd.org (Postfix) with ESMTP id AC21D3B6B87; Thu, 15 Nov 2012 13:06:21 +0000 (UTC) Received: from hub.FreeBSD.org (hub.FreeBSD.org [8.8.178.136]) by hub.freebsd.org (Postfix) with ESMTP id 0ACFB1AF; Thu, 15 Nov 2012 13:06:21 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F3E09FA5; Thu, 15 Nov 2012 13:06:11 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 084FE8FC12; Thu, 15 Nov 2012 13:06:10 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA02734; Thu, 15 Nov 2012 15:06:09 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TYz8z-000Nc0-7A; Thu, 15 Nov 2012 15:06:09 +0200 Message-ID: <50A4E8C0.5030608@FreeBSD.org> Date: Thu, 15 Nov 2012 15:06:08 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org Subject: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page X-Enigmail-Version: 1.4.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Content-Type: multipart/mixed; boundary="===============4775165132330987913==" Errors-To: owner-freebsd-current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-SpamScore: 0 X-MailHub-Apparently-To: mjm@michaelmeltzer.com X-MailHub-Forwarded: Yes X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:32:11 -0000 --===============4775165132330987913== Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit To people knowing the code, do the following documentation changes look correct? --- a/share/man/man9/lock.9 +++ b/share/man/man9/lock.9 @@ -148,7 +148,9 @@ Flags indicating what action is to be taken. .Bl -tag -width ".Dv LK_CANRECURSE" .It Dv LK_SHARED Acquire a shared lock. -If an exclusive lock is currently held, it will be downgraded. +If an exclusive lock is currently held, +.Dv EDEADLK +will be returned. .It Dv LK_EXCLUSIVE Acquire an exclusive lock. If an exclusive lock is already held, and @@ -158,7 +160,8 @@ is not set, the system will .It Dv LK_DOWNGRADE Downgrade exclusive lock to a shared lock. Downgrading a shared lock is not permitted. -If an exclusive lock has been recursed, all references will be downgraded. +If an exclusive lock has been recursed, the system will +.Xr panic 9 . .It Dv LK_UPGRADE Upgrade a shared lock to an exclusive lock. If this call fails, the shared lock is lost. -- Andriy Gapon --===============4775165132330987913== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" --===============4775165132330987913==-- From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 18:38:22 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6933EF85; Thu, 15 Nov 2012 18:38:22 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id CF7108FC12; Thu, 15 Nov 2012 18:38:20 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA05460; Thu, 15 Nov 2012 20:38:17 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50A53699.30703@FreeBSD.org> Date: Thu, 15 Nov 2012 20:38:17 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Warner Losh Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> In-Reply-To: <47374EC3-5022-49AC-A17E-7F234A88B5C6@bsdimp.com> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, Ian Lepore , Adrian Chadd , freebsd-hackers@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:38:22 -0000 on 15/11/2012 19:56 Warner Losh said the following: > It sounds like he's more worried about introducing LoRs into his wireless code. "Mere" LORs do not result in panic, by default. Only more serious lock-related issues lead to panics. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 18:46:58 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C073246; Thu, 15 Nov 2012 18:46:58 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 355528FC0C; Thu, 15 Nov 2012 18:46:56 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so1864840lah.13 for ; Thu, 15 Nov 2012 10:46:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QmVBcnp7QxKg2G52n36uYrO8ekdeaKsqqSKFap8YT9A=; b=v5+Wt9pKENbAid7zWt5/WTbXVyXEMc/vcjzzOQ9x70RoYnM+QVOiIrKm4OcOhm+U79 HBg2t2n4zs5hokeeq/e6CsWnMe5AHF3azfbnieOhWBdOUoPZNaBEw6J+M/qk+J4R1Bg7 HVDU101Dtz1+PWFLSdeoZ8UwJKoskRmwj/tabAIS2BRoHHYj84acp1p1SlDyyN+2W04P ECuw31rjfep60wjPS/gF53MAQBlIoAqhGd7HZmHOw8ZwvWklgKC2biI23o9adHQO7uhu T/XgnZ6gtVaE+E7A5c+RdJ04uH+y/RZZSQBfqtNHht4fxAdJrBso+C4tGX1pUMQl94kE t+Hw== MIME-Version: 1.0 Received: by 10.152.104.50 with SMTP id gb18mr2032232lab.9.1353005215940; Thu, 15 Nov 2012 10:46:55 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 10:46:55 -0800 (PST) In-Reply-To: <50A4E8C0.5030608@FreeBSD.org> References: <50A4E8C0.5030608@FreeBSD.org> Date: Thu, 15 Nov 2012 18:46:55 +0000 X-Google-Sender-Auth: t93cp-UE9SzJgNev7ybwPsBfpUg Message-ID: Subject: Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:46:58 -0000 On 11/15/12, Andriy Gapon wrote: > > To people knowing the code, > > do the following documentation changes look correct? The latter chunk is not correct. It will panic only if assertions are on. I was thinking that however it would be good idea to patch lockmgr to panic also in non-debugging kernel situation. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 19:16:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1ABCF7F; Thu, 15 Nov 2012 19:16:12 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 91D4F8FC0C; Thu, 15 Nov 2012 19:16:12 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so1394560pab.13 for ; Thu, 15 Nov 2012 11:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=LzMa1B6/y8A8sezs+XidoLqSDprcGpzwIZPFFeIXyRg=; b=l16sRC/OV4FsCFGcaU0H0Li5U6jUZIxA7OSxi7Fd49/PYRL2Pb9hCx87z1kMwg4/Zg qv4FEtnTMpq0tS7wzy5AiN1H26Yu3CBjdXqLQ6ZHy99LT4onqmgMr+XXAexW0jNX4kwY Fm+x3CssdII0RONHk7FhXn2h+VrivL3C5Ra3wmCzKaxirI/s9K3vMqoRUx7eGncWe7pg jSzJX1rUMc4+HZEAmq8rO5C7q2Mpq+ytUQaaiWFhVPUiyL9/qc1yne9FzffiVRSRJmnt e9BuYbb5nfEorjSJGvl/zvPZ/KbR0zXKM8lzDq2G7mLtmUOuZkDs/zdWXPYRNPrRJWJ8 89CQ== MIME-Version: 1.0 Received: by 10.68.209.166 with SMTP id mn6mr1878624pbc.95.1353006972359; Thu, 15 Nov 2012 11:16:12 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 15 Nov 2012 11:16:12 -0800 (PST) In-Reply-To: <201211151836.04709.zec@fer.hr> References: <201210291115.23845.zec@fer.hr> <201211151836.04709.zec@fer.hr> Date: Thu, 15 Nov 2012 11:16:12 -0800 X-Google-Sender-Auth: BzHBpD3CrgErucYcfhLLRpVLBUI Message-ID: Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices From: Adrian Chadd To: Marko Zec Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, Hans Petter Selasky , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:16:12 -0000 Hans brings up a very good point for USB - they split if_alloc and if_attach across two different threads. So this works for non-USB devices, but not for USB devices. Hans, does each device implement its own workqueue for this kind of delayed action, or is there some generic work queue that is doing this work? Adrian On 15 November 2012 09:36, Marko Zec wrote: > On Thursday 15 November 2012 07:18:31 Adrian Chadd wrote: >> Hi, >> >> Here's what I have thus far. Please ignore the device_printf() change. >> >> This works for me, both for hotplug cardbus wireless devices as well >> as (inadvertently!) a USB bluetooth device. >> >> What do you think? > > It looks that you've hit the right spot to set curvnet context in > device_probe_and_attach(). > > Could you try out a slightly revised verstion (attached) - this one also > removes now redundant curvnet setting from linker routines (kldload / > kldunload), and adds a few extra bits which might be necessary for a > broader range of drivers to work. > > Note that I haven't tested this myself as I don't have a -CURRENT machine > ATM, but a similar patch for 8.3 apparently works fine, though I don't have > hotplugabble network cards to play with (neither cardbus nor USB)... > > Cheers, > > Marko From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 19:35:36 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9876A990; Thu, 15 Nov 2012 19:35:36 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe07.c2i.net [212.247.154.194]) by mx1.freebsd.org (Postfix) with ESMTP id AA4548FC16; Thu, 15 Nov 2012 19:35:35 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe07.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 344145324; Thu, 15 Nov 2012 20:30:26 +0100 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Thu, 15 Nov 2012 20:32:06 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-PRERELEASE; KDE/4.8.4; amd64; ; ) References: <201211151836.04709.zec@fer.hr> In-Reply-To: X-Face: 'mmZ:T{)),Oru^0c+/}w'`gU1$ubmG?lp!=R4Wy\ELYo2)@'UZ24N@ =?iso-8859-1?q?d2+AyewRX=7DmAm=3BYp=0A=09=7CU=5B?=@, _z/([?1bCfM{_"B<.J>mICJCHAzzGHI{y7{%JVz%R~yJHIji`y> =?iso-8859-1?q?Y=7Dk1C4TfysrsUI=0A=09-=25GU9V5=5DiUZF=26nRn9mJ=27=3F=26?=>O MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201211152032.06181.hselasky@c2i.net> Cc: freebsd-net@freebsd.org, Adrian Chadd , Marko Zec X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:35:36 -0000 On Thursday 15 November 2012 20:16:12 Adrian Chadd wrote: > Hans brings up a very good point for USB - they split if_alloc and > if_attach across two different threads. > > So this works for non-USB devices, but not for USB devices. > > Hans, does each device implement its own workqueue for this kind of > delayed action, or is there some generic work queue that is doing this > work? > > Hi, I think a new thread is created for this stuff. It is inside the USB subsystem, but would consider this a big *hack* to add VNET specific stuff in there. Isn't it possible to have curvnet return "vnet0" when nothing else is set? --HPS From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 19:55:14 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2616D6C; Thu, 15 Nov 2012 19:55:14 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from duck.symmetricom.us (duck.symmetricom.us [206.168.13.214]) by mx1.freebsd.org (Postfix) with ESMTP id 8142E8FC0C; Thu, 15 Nov 2012 19:55:14 +0000 (UTC) Received: from damnhippie.dyndns.org (daffy.symmetricom.us [206.168.13.218]) by duck.symmetricom.us (8.14.5/8.14.5) with ESMTP id qAFJtCta042825; Thu, 15 Nov 2012 12:55:13 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id qAFJtAMF025220; Thu, 15 Nov 2012 12:55:10 -0700 (MST) (envelope-from freebsd@damnhippie.dyndns.org) Subject: Re: [RFQ] make witness panic an option From: Ian Lepore To: attilio@FreeBSD.org In-Reply-To: References: <1353001175.1217.153.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Nov 2012 12:55:10 -0700 Message-ID: <1353009310.1217.172.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Adrian Chadd , freebsd-arch@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:55:15 -0000 On Thu, 2012-11-15 at 17:47 +0000, Attilio Rao wrote: > On 11/15/12, Ian Lepore wrote: > > On Wed, 2012-11-14 at 22:15 -0800, Adrian Chadd wrote: > >> Hi all, > >> > >> When debugging and writing wireless drivers/stack code, I like to > >> sprinkle lots of locking assertions everywhere. However, this does > >> cause things to panic quite often during active development. > >> > >> This patch (against stable/9) makes the actual panic itself > >> configurable. It still prints the message regardless. > >> > >> This has allowed me to sprinkle more locking assertions everywhere to > >> investigate whether particular paths have been hit or not. I don't > >> necessarily want those to panic the kernel. > >> > >> I'd like everyone to consider this for FreeBSD-HEAD. > >> > >> Thanks! > > > > I strongly support this, because I'm tired of having to hack it in by > > hand every time I need it. > > > > You can't boot an arm platform right now (on freebsd 8, 9, or 10) > > without a LOR very early in the boot. Once you get past that, 2 or 3 > > device drivers I use panic way before we even get to mounting root. > > Those panics can clearly be ignored, because we've been shipping > > products for years based on this code. (It's on my to-do list to fix > > them, but more pressing problems are higher on the list.) > > This is a ridicolous motivation. > What are the panics in question? Why they are not fixed yet? > Without WITNESS_KDB you should not panic even in cases where WITNESS > yells. So if you do, it means there is a more subdole breakage going > on here. > > Do you really think that an abusable mechanism will help here rather > than fixing the actual problems? > > > When a new problem crops up that isn't harmless, it totally sucks that I > > can't just turn on witness without first hacking the code to make the > > known problems non-panicky. > > I really don't understand what are these "harmless problems" here. > I just know one and it is between the dirhash lock and the bufwait > lock for UFS, which is carefully documented in the code comments. All > the others cases haven't been analyzed deeply enough to quantify them > as "harmless". > > Can you please make real examples? > No. Since you've made it abundantly clear in this thread that you are not open to anyone else's opinion and won't change your mind, I'm not going to waste even 10 seconds explaining my perfectly valid needs. I'll just keep hacking the code up to not panic when I need to. -- Ian From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 20:00:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A9CE916C; Thu, 15 Nov 2012 20:00:51 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 642C08FC08; Thu, 15 Nov 2012 20:00:51 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so1425293pab.13 for ; Thu, 15 Nov 2012 12:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pFKWZYoG4p30Vf0Gsb0S0WV/+8kDLrdtb1B53AxVM04=; b=Ak4uyRK+vc0ABwP7IEEqun3qB5953yIMV6PtuCQ0iNpiS3g/MuMRft4t60mD4YbzZh x8yQZ3VHS6D39NCdMLYLBTY6r7fSuT7yKYJ8iuzdbyGeCu1mUg0XlP0v0zpzrOTqmiPS lHMIUpfoPeUMXdOV+4d0n4vOP+FSCJak4yIzokXnCiuXjHF6StvRGFzu6+ZLwOqBE6ex IIw4j5I7pWx3LoBeEV/rkcN0ofdp5zcbBS3HUiG+kQ1r9JewroMW8Y+IvBlclse7RLsp JmtQAc1kwcjhE6V/iZjC5PIJOXz2JLPlNO9PqqXizCcpFaAmlvpV4wQINC/jk7i5eQRq bEpA== MIME-Version: 1.0 Received: by 10.68.209.166 with SMTP id mn6mr2239018pbc.95.1353009651011; Thu, 15 Nov 2012 12:00:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Thu, 15 Nov 2012 12:00:50 -0800 (PST) In-Reply-To: <1353009310.1217.172.camel@revolution.hippie.lan> References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> Date: Thu, 15 Nov 2012 12:00:50 -0800 X-Google-Sender-Auth: RF_RGCRWPC2aiz4sv-W4m-smavM Message-ID: Subject: Re: [RFQ] make witness panic an option From: Adrian Chadd To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:00:52 -0000 On 15 November 2012 11:55, Ian Lepore wrote: > Since you've made it abundantly clear in this thread that you are not > open to anyone else's opinion and won't change your mind, I'm not going > to waste even 10 seconds explaining my perfectly valid needs. > > I'll just keep hacking the code up to not panic when I need to. I agree with Attilio - any driver or subsystem that's causing witness panics need to be fixed. But I think my change is invaluable for development, where you want to improve and debug the locking and lock interactions of a subsystem. adrian From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 20:38:35 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E976CA1; Thu, 15 Nov 2012 20:38:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 193058FC08; Thu, 15 Nov 2012 20:38:33 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA06227; Thu, 15 Nov 2012 22:38:32 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZ6Cl-000Nz0-Ri; Thu, 15 Nov 2012 22:38:31 +0200 Message-ID: <50A552C5.5060703@FreeBSD.org> Date: Thu, 15 Nov 2012 22:38:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page References: <50A4E8C0.5030608@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:38:35 -0000 on 15/11/2012 20:46 Attilio Rao said the following: > On 11/15/12, Andriy Gapon wrote: >> >> To people knowing the code, >> >> do the following documentation changes look correct? > > The latter chunk is not correct. > It will panic only if assertions are on. But the current content is not correct too? > I was thinking that however > it would be good idea to patch lockmgr to panic also in non-debugging > kernel situation. It would make sense indeed, IMO. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 20:51:14 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C80914AD; Thu, 15 Nov 2012 20:51:14 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 63A6F8FC19; Thu, 15 Nov 2012 20:51:13 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA06347; Thu, 15 Nov 2012 22:51:11 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZ6P0-000Nza-LF; Thu, 15 Nov 2012 22:51:10 +0200 Message-ID: <50A555BD.1010105@FreeBSD.org> Date: Thu, 15 Nov 2012 22:51:09 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, Ian Lepore , freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 20:51:14 -0000 on 15/11/2012 22:00 Adrian Chadd said the following: > But I think my change is invaluable for development, where you want to > improve and debug the locking and lock interactions of a subsystem. My practical experience was that if you mess up one lock in one place, then it is a total mess further on. but apparently you've got a different practical experience :-) What would indeed be invaluable to _me_ - if the LOR messages also produced the stack(s) where a supposedly correct lock order was learned. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 21:44:46 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 60DE1429; Thu, 15 Nov 2012 21:44:46 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 76E288FC0C; Thu, 15 Nov 2012 21:44:45 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2108131lbb.13 for ; Thu, 15 Nov 2012 13:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FntpHllDouwqnrIGT0VbU6fCPv4Hg85yZMJs+WRa6DY=; b=dTnxR/gqiWEeKDXacNdtjBTR0RYzqscOcT9fu99pIa6QAXOtWmxV0MIhJP/fdoefzi QBXgp3wvywOYXYZDWQS9aRCvwVXGjH+aKazJYQhbL7jIzGXVovPwqeVnncr8dlOhwA9g L9jOP1FQJYv8xTskXOQxttsDPvJVSEkh4J0RKyxLJzyqv120Dyeu7iiKRa6BNPEOoIZY neOxOVKL57pbrwVXPSkWKbqZqjOjn1+6ld8I0qaItEiBrVingLFWjaWBKH9yPnjL80Ap 1BrbogWVRK7VLuPxuZ1fGO8pFtrrxn+uSSMytRaACtNtZH/PoRIXfy0s6nMpTqwP6hhK Nofw== MIME-Version: 1.0 Received: by 10.152.123.103 with SMTP id lz7mr2378431lab.21.1353015884248; Thu, 15 Nov 2012 13:44:44 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 13:44:44 -0800 (PST) In-Reply-To: <50A552C5.5060703@FreeBSD.org> References: <50A4E8C0.5030608@FreeBSD.org> <50A552C5.5060703@FreeBSD.org> Date: Thu, 15 Nov 2012 21:44:44 +0000 X-Google-Sender-Auth: dTPUs2IPiyxLhF5FOAaNrillnpQ Message-ID: Subject: Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:44:46 -0000 On Thu, Nov 15, 2012 at 8:38 PM, Andriy Gapon wrote: > on 15/11/2012 20:46 Attilio Rao said the following: >> On 11/15/12, Andriy Gapon wrote: >>> >>> To people knowing the code, >>> >>> do the following documentation changes look correct? >> >> The latter chunk is not correct. >> It will panic only if assertions are on. > > But the current content is not correct too? Indeed, current content is crappy. >> I was thinking that however >> it would be good idea to patch lockmgr to panic also in non-debugging >> kernel situation. > > It would make sense indeed, IMO. Do you think you can test this patch?: http://www.freebsd.org/~attilio/lockmgr_forcerec.patch I think the LK_NOSHARE case is still fine with just asserts. Once this patch goes in, you are free to commit your documentation one. Thanks for fixing doc. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 21:49:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 07013725; Thu, 15 Nov 2012 21:49:49 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (mail.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 773698FC16; Thu, 15 Nov 2012 21:49:48 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.318.4; Thu, 15 Nov 2012 22:49:45 +0100 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Nov 2012 22:49:41 +0100 Received: from localhost ([161.53.19.8]) by sluga.fer.hr over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Nov 2012 22:49:41 +0100 From: Marko Zec To: Hans Petter Selasky , Adrian Chadd Subject: Re: VIMAGE crashes on 9.x with hotplug net80211 devices Date: Thu, 15 Nov 2012 22:49:35 +0100 User-Agent: KMail/1.9.10 References: <201211152032.06181.hselasky@c2i.net> In-Reply-To: <201211152032.06181.hselasky@c2i.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201211152249.36161.zec@fer.hr> X-OriginalArrivalTime: 15 Nov 2012 21:49:41.0438 (UTC) FILETIME=[1DF19DE0:01CDC37B] Cc: freebsd-hackers@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 21:49:49 -0000 On Thursday 15 November 2012 20:32:06 Hans Petter Selasky wrote: > On Thursday 15 November 2012 20:16:12 Adrian Chadd wrote: > > Hans brings up a very good point for USB - they split if_alloc and > > if_attach across two different threads. Fine, so maybe one of the following options could work: 1) pass the vnet context embedded in some other already available struct when forwarding request from 1st to 2nd thread; or 2) if we can safely assume that device attach events can only occur in context of vnet0 (and I think we can), place a few CURVNET_SET(vnet0) macros wherever necessary in 2nd USB "attach" thread. > > So this works for non-USB devices, but not for USB devices. Could you post a sample backtrace for me to look at? > > Hans, does each device implement its own workqueue for this kind of > > delayed action, or is there some generic work queue that is doing this > > work? > > Hi, > > I think a new thread is created for this stuff. It is inside the USB > subsystem, but would consider this a big *hack* to add VNET specific > stuff in there. > > Isn't it possible to have curvnet return "vnet0" when nothing else is > set? No! This was discussed already at several ocassions, including earlier in this thread: with curvnet pointing by default to vnet0, it would be essentially impossible to detect, trace and debug leakages between vnets. Marko From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 22:58:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 59715D0 for ; Thu, 15 Nov 2012 22:58:26 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 0C9A68FC08 for ; Thu, 15 Nov 2012 22:58:25 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo13so2961299vcb.13 for ; Thu, 15 Nov 2012 14:58:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=BTfkGZQUJ3lIp8hBJxvqxeqRbUVrB+EtwxPdt7aJL4c=; b=RqOVme++W2hOmM00mYBBXMtuRU0bMC6SGRNS3cXw21O4L6PodbbgBBHiQdf4sofQBM WpPHeei/rfOyDbx6zImjf505jkq3cWVIocpOqp94oPo2Xu+cgw1XBdLINAakWgIFK1gq G8SiwoniiYj8+EDLsNRDy2Vg5eAKV2x5v0XSGtFF4xK6zblqtx38T+4rh8G+2Y5esQCP lEmpmDwyq9YgpC74PjUQAgm9L8EAT3EUuhaQ/kjj7RzP5DYMu9ZZFY7N7/0Dci/E70W2 4/HY3FfOHjMRIGrf9NNaUhq2LX35D1a6EyVeq+DWsrRqpBxvZyZQOjrXAbMHNYKimEAO SXQA== MIME-Version: 1.0 Received: by 10.58.39.42 with SMTP id m10mr3810842vek.21.1353020305377; Thu, 15 Nov 2012 14:58:25 -0800 (PST) Received: by 10.58.207.114 with HTTP; Thu, 15 Nov 2012 14:58:25 -0800 (PST) Date: Thu, 15 Nov 2012 17:58:25 -0500 Message-ID: Subject: stop_cpus_hard when multiple CPUs are panicking from an NMI From: Ryan Stone To: "freebsd-hackers@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:58:26 -0000 At work we have some custom watchdog hardware that sends an NMI upon expiry. We've modified the kernel to panic when it receives the watchdog NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've discovered that when my watchdog expires, the system gets completely wedged. After some digging, I've discovered is that I have multiple CPUs getting the watchdog NMI and trying to panic concurrently. One of the CPUs wins, and the rest spin forever in this code: /* * We don't want multiple CPU's to panic at the same time, so we * use panic_cpu as a simple spinlock. We have to keep checking * panic_cpu if we are spinning in case the panic on the first * CPU is canceled. */ if (panic_cpu != PCPU_GET(cpuid)) while (atomic_cmpset_int(&panic_cpu, NOCPU, PCPU_GET(cpuid)) == 0) while (panic_cpu != NOCPU) ; /* nothing */ The system wedges when stop_cpus_hard() is called, which sends NMIs to all of the other CPUs and waits for them to acknowledge that they are stopped before returning. However the CPU will not deliver an NMI to a CPU that is already handling an NMI, so the other CPUs that got a watchdog NMI and are spinning will never go into the NMI handler and acknowledge that they are stopped. I've been able to work around this with the following hideous hack: --- kern_shutdown.c 2012-08-17 10:25:02.000000000 -0400 +++ kern_shutdown.c 2012-11-15 17:04:10.000000000 -0500 @@ -658,11 +658,15 @@ * panic_cpu if we are spinning in case the panic on the first * CPU is canceled. */ - if (panic_cpu != PCPU_GET(cpuid)) + if (panic_cpu != PCPU_GET(cpuid)) { while (atomic_cmpset_int(&panic_cpu, NOCPU, - PCPU_GET(cpuid)) == 0) + PCPU_GET(cpuid)) == 0) { + atomic_set_int(&stopped_cpus, PCPU_GET(cpumask)); while (panic_cpu != NOCPU) ; /* nothing */ + } + atomic_clear_int(&stopped_cpus, PCPU_GET(cpumask)); + } if (stop_scheduler_on_panic) { if (panicstr == NULL && !kdb_active) But I'm hoping that somebody has some ideas on a better way to fix this kind of problem. From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 23:17:10 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A74409BA; Thu, 15 Nov 2012 23:17:10 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 75A2C8FC08; Thu, 15 Nov 2012 23:17:10 +0000 (UTC) Received: from kruse-124.4.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) by elvis.mu.org (Postfix) with ESMTPSA id 4B4B61A3D8D; Thu, 15 Nov 2012 15:17:04 -0800 (PST) Message-ID: <50A57815.4060104@mu.org> Date: Thu, 15 Nov 2012 15:17:41 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFQ] make witness panic an option References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:17:10 -0000 On 11/14/12 10:15 PM, Adrian Chadd wrote: > Hi all, > > When debugging and writing wireless drivers/stack code, I like to > sprinkle lots of locking assertions everywhere. However, this does > cause things to panic quite often during active development. > > This patch (against stable/9) makes the actual panic itself > configurable. It still prints the message regardless. > > This has allowed me to sprinkle more locking assertions everywhere to > investigate whether particular paths have been hit or not. I don't > necessarily want those to panic the kernel. > > I'd like everyone to consider this for FreeBSD-HEAD. > > Thanks! Adrian, you seem be getting reluctance on your patch which is surprising since we have "witness_kdb" option which pretty much does exactly what you want... ...except where you need it to. That is unfortunate. Perhaps if you switched those panics to a WITNESS_WARN that would do what you need/want? You could pass a special flag into WITNESS_WARN that said "i'm going to pass you a NULL ptr for lock object... just behave as if there was an error". that should make things more concise. Will that be sufficient? -Alfred > > > > Adrian > > > _______________________________________________ > 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 Nov 15 23:19:29 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9ACB9C1F; Thu, 15 Nov 2012 23:19:29 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 77A638FC12; Thu, 15 Nov 2012 23:19:29 +0000 (UTC) Received: from kruse-124.4.ixsystems.com (drawbridge.ixsystems.com [206.40.55.65]) by elvis.mu.org (Postfix) with ESMTPSA id D8A771A3D8D; Thu, 15 Nov 2012 15:19:28 -0800 (PST) Message-ID: <50A578A6.1030005@mu.org> Date: Thu, 15 Nov 2012 15:20:06 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> In-Reply-To: <50A555BD.1010105@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, Ian Lepore , Adrian Chadd , freebsd-hackers@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:19:29 -0000 On 11/15/12 12:51 PM, Andriy Gapon wrote: > on 15/11/2012 22:00 Adrian Chadd said the following: >> But I think my change is invaluable for development, where you want to >> improve and debug the locking and lock interactions of a subsystem. > My practical experience was that if you mess up one lock in one place, then it > is a total mess further on. but apparently you've got a different practical > experience :-) > > What would indeed be invaluable to _me_ - if the LOR messages also produced the > stack(s) where a supposedly correct lock order was learned. > Adrian is right. In a large scale environment breakages will be introduced in places you do not have access to. We need to enable developers to skip these areas and test their own code. Without Adrian's concept then it forces someone who may have no idea about a subsystem to either be blocked, or to have to put his work aside to work on a problem that is someone else's responsibility. I locked down SMP at a large company in a FreeBSD code base and had this same problem. Adrian's patch would have helped all of us tremendously. Adrian, can you look at my suggestion to merge with witness_kdb and see if that will suffice? -Alfred From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 23:38:07 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6435D5BC; Thu, 15 Nov 2012 23:38:07 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 37F7C8FC13; Thu, 15 Nov 2012 23:38:06 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2182799lbb.13 for ; Thu, 15 Nov 2012 15:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=59fXcjSOGzjdxybEZJU5FyWyLXXjWnlX2A1ncV1wX3E=; b=uIBJqE7kZ+G5C/FIwnacIyHHnd6O17lx9oiOLjUpWEDFK55aOHEc6jSO9973QS0/hr qN3vDWMqe7NysB2fx5gdC/3DoIEpGiIYMO2bjoUK2XPSww0pc3HFFpyJ6nDWIpOWhiEN 7ZlVfdVsD8YKuwKokCOaxXo8UsKCS90i9fHsobmpuIvqcSTvxTtp3H8CcW3UF4DTbDUW NEjvaFRDq4akIRfrL+EwOlTKxbZW9cq2QrSxKQzfgEP7/ivTQtUipsUeZmWoLiEK9nY9 Ed2YX2vUXwE/DMGY1OwRWTTOB3RjpXjMU+zW4jRl7vQERkq7DN1WOx2J4SHwMldXP7kd 4oxQ== MIME-Version: 1.0 Received: by 10.112.36.200 with SMTP id s8mr1267148lbj.92.1353022684920; Thu, 15 Nov 2012 15:38:04 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 15:38:04 -0800 (PST) In-Reply-To: <50A555BD.1010105@FreeBSD.org> References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> Date: Thu, 15 Nov 2012 23:38:04 +0000 X-Google-Sender-Auth: O7HR17qiUsPNiPQPPnHwqI3xmLk Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , Adrian Chadd , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:38:07 -0000 On Thu, Nov 15, 2012 at 8:51 PM, Andriy Gapon wrote: > on 15/11/2012 22:00 Adrian Chadd said the following: >> But I think my change is invaluable for development, where you want to >> improve and debug the locking and lock interactions of a subsystem. > > My practical experience was that if you mess up one lock in one place, then it > is a total mess further on. but apparently you've got a different practical > experience :) > What would indeed be invaluable to _me_ - if the LOR messages also produced the > stack(s) where a supposedly correct lock order was learned. Please note that the "supposedly correct lock order", as for the definition that it is correct, can be used in several different stacks. I don't see the point of saving it somewhere. The only helpful case would be if the "wrong order" is catched first. If this is really the case, I suggest you to force the order you expect in the static table so that the first time the wrong order happens it yells. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 23:41:33 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E76DF773 for ; Thu, 15 Nov 2012 23:41:33 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5F4798FC0C for ; Thu, 15 Nov 2012 23:41:33 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2184583lbb.13 for ; Thu, 15 Nov 2012 15:41:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Zf9hzMcSg6P63ax02IyPM6xeiGJ3rJHJlrFRCPZUDnA=; b=hKYRss1A26vNDjyYk9mXf15MQsJx6QN8VUO43YZO8e4FNHWmAdydh0+qvZVh5uzS30 aLk/mVNZbQ03UP4BorhKgnoTXUCbOlKfw4Yn7QGM9HPA+3txzDp94Oeh9XKflU2eUQxW e4h39Y/Jfna1hx7xmrmaPNBTnoSSmQETwt4t/f0sw2vHnORC+3GuIvkfotX06C2mf1MU MOwrSXR+/Dr7u6/vcEFHbyMBSX0FZa4oybwSLQyoomg+S6DomvioeWUOw+omjJEL0zJH KGUI9zDXT3hA53dTWhhDaZNTgzTryaxHsO6nPdT2UECxiVxEMA0rM7W3RurGtM1/Kfun 6lYA== MIME-Version: 1.0 Received: by 10.152.123.103 with SMTP id lz7mr2599492lab.21.1353022891783; Thu, 15 Nov 2012 15:41:31 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 15:41:31 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 23:41:31 +0000 X-Google-Sender-Auth: W-cETsyUMi5rNuW8RlyAKUJ9B1o Message-ID: Subject: Re: stop_cpus_hard when multiple CPUs are panicking from an NMI From: Attilio Rao To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:41:34 -0000 On Thu, Nov 15, 2012 at 10:58 PM, Ryan Stone wrote: > At work we have some custom watchdog hardware that sends an NMI upon > expiry. We've modified the kernel to panic when it receives the watchdog > NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've > discovered that when my watchdog expires, the system gets completely > wedged. After some digging, I've discovered is that I have multiple CPUs > getting the watchdog NMI and trying to panic concurrently. One of the CPUs > wins, and the rest spin forever in this code: Quick question: can you control the way your watchdog sends the NMI? Like only to BSP rather than broadcast, etc. This is tied to the very unique situation that you cannot really deliver the (second) NMI. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Thu Nov 15 23:47:40 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C545892; Thu, 15 Nov 2012 23:47:40 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id AC5B58FC14; Thu, 15 Nov 2012 23:47:39 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so2908550vba.13 for ; Thu, 15 Nov 2012 15:47:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bbHSI7vrKbMR0tC1sinwWp4mTH7fBmL3oRsL0gMG/kA=; b=pl70uuQluEx1+G6lImBGIukhTDOGZn/uyRbq1NkSJw+mnisZaBv1Y82bBC+4DWIhmr qvH5/naGxvMOxIIpMo3ntx0gD56p8A+ZkZkEbAxbf8tXGSfgAJ+zmnSaLcw49iJztJJ/ a2hMtJayR6z/nZOtJd5bYqguj76ebo9UG12/RmVRSfH1v7HfMwhYvtwF8+zlr8VbJpwD ouNYOfcYRSrc2jQAXvkt5RqNp7NLx5oGcagUs+bWoJz6ivMvHEAzGhFCx2jhs5un81Bk HMFWTPmaAZAwwnW8djjT+z9ODEr32iO5brg+KNMEXgZXog2k1BuRBysFTNOXMtyWQG+d afIg== MIME-Version: 1.0 Received: by 10.52.100.230 with SMTP id fb6mr3332517vdb.91.1353023258579; Thu, 15 Nov 2012 15:47:38 -0800 (PST) Received: by 10.58.207.114 with HTTP; Thu, 15 Nov 2012 15:47:38 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 18:47:38 -0500 Message-ID: Subject: Re: stop_cpus_hard when multiple CPUs are panicking from an NMI From: Ryan Stone To: Attilio Rao Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:47:40 -0000 On Thu, Nov 15, 2012 at 6:41 PM, Attilio Rao wrote: > On Thu, Nov 15, 2012 at 10:58 PM, Ryan Stone wrote: > > At work we have some custom watchdog hardware that sends an NMI upon > > expiry. We've modified the kernel to panic when it receives the watchdog > > NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've > > discovered that when my watchdog expires, the system gets completely > > wedged. After some digging, I've discovered is that I have multiple CPUs > > getting the watchdog NMI and trying to panic concurrently. One of the > CPUs > > wins, and the rest spin forever in this code: > > Quick question: can you control the way your watchdog sends the NMI? > Like only to BSP rather than broadcast, etc. > This is tied to the very unique situation that you cannot really > deliver the (second) NMI. > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > I don't believe that I can, but I can check. In any case I can imagine other places where this could be an issue. hwpmc works with NMIs, right? So an hwpmc bug could trigger the same kind of issues if two CPUs that concurrently called pmc_intr both tripped over the sane bug. From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 00:16:51 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 93CDF212 for ; Fri, 16 Nov 2012 00:16:51 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1105D8FC12 for ; Fri, 16 Nov 2012 00:16:50 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so2118281lah.13 for ; Thu, 15 Nov 2012 16:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=bCnbZxqND4BjKr9hu2AODHA5N9Hcpr2vkMQiRNYMCxY=; b=j6sCZZYT0oYn/4WIQQn111BRNiy5A1CKgvxJxqjdhEVmpy1tmwMH4ASCaSxTn6ytL4 FaGRB6EQt83iYVvY6SmilO+ZRcLN8GQXJJ8MesuDE0Y1eQKHWYjvuXtevvyJ8WwCGBfk uEp6dFwU6RJ5niD8/WfEfiRWz7pYEjOwEe/2mql2N/BWxZXNdhAE5h8v4Hy5FxKo1uOZ /l7AOex5jNV1u+lOV+3k6T7KxMet5JJ1mISbCEQoXNUPYb9vvJ1KEddw+6jdgM/E5Pm7 roDZM1Hz6H+LQDWDWnMclDcN1HXrvhNwY6x/7Ul+fbhQRF/A8Q7l+ni1n93bX8raRJLH CkHg== MIME-Version: 1.0 Received: by 10.112.41.36 with SMTP id c4mr1223096lbl.75.1353025009797; Thu, 15 Nov 2012 16:16:49 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Thu, 15 Nov 2012 16:16:49 -0800 (PST) In-Reply-To: References: Date: Fri, 16 Nov 2012 00:16:49 +0000 X-Google-Sender-Auth: AQ0D6VyKFsB2h3CRKIOZwZo51sc Message-ID: Subject: Re: stop_cpus_hard when multiple CPUs are panicking from an NMI From: Attilio Rao To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 00:16:51 -0000 On Thu, Nov 15, 2012 at 11:47 PM, Ryan Stone wrote: > On Thu, Nov 15, 2012 at 6:41 PM, Attilio Rao wrote: >> >> On Thu, Nov 15, 2012 at 10:58 PM, Ryan Stone wrote: >> > At work we have some custom watchdog hardware that sends an NMI upon >> > expiry. We've modified the kernel to panic when it receives the >> > watchdog >> > NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've >> > discovered that when my watchdog expires, the system gets completely >> > wedged. After some digging, I've discovered is that I have multiple >> > CPUs >> > getting the watchdog NMI and trying to panic concurrently. One of the >> > CPUs >> > wins, and the rest spin forever in this code: >> >> Quick question: can you control the way your watchdog sends the NMI? >> Like only to BSP rather than broadcast, etc. >> This is tied to the very unique situation that you cannot really >> deliver the (second) NMI. >> >> Attilio >> >> >> -- >> Peace can only be achieved by understanding - A. Einstein > > > I don't believe that I can, but I can check. In any case I can imagine > other places where this could be an issue. hwpmc works with NMIs, right? > So an hwpmc bug could trigger the same kind of issues if two CPUs that > concurrently called pmc_intr both tripped over the sane bug. Frankly, I think that what you were trying to do is someway the right approach, modulo a clean interface. I don't understand why the "spinlock" does wants to spin forever as it can never recover. Stopping the cpus that gets into the "spinlock" is perfectly fine. There are only 2 things to consider: 1) I think we need a new KPI for that, a function in $arch/include/cpu.h that does take care to stop a CPU in MI way, so for example cpu_self_stop(). This needs to be implemented for all the architectures but it can be done easily because it will be what cpustop_handler() and similar functions do, basically. 2) The "fake spinlock" path will call such functions. The only thing to debeate IMHO is if we want to do that conditional to stop_scheduler_on_panic or not. If I have to be honest, stopping the CPU seems the best approach in any case to me, but I'm open to hear what you think. Comments? Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 02:09:58 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 47B86974 for ; Fri, 16 Nov 2012 02:09:58 +0000 (UTC) (envelope-from postmaster@mailpod.hostingplatform.com) Received: from atl4mhob06.myregisteredsite.com (atl4mhob06.myregisteredsite.com [209.17.115.44]) by mx1.freebsd.org (Postfix) with ESMTP id E947D8FC12 for ; Fri, 16 Nov 2012 02:09:57 +0000 (UTC) Received: from mailpod1.hostingplatform.com (mailpod1.networksolutionsemail.com [206.188.198.65]) by atl4mhob06.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAG29ujc008624 for ; Thu, 15 Nov 2012 21:09:56 -0500 Received: (qmail 27871 invoked by uid 0); 16 Nov 2012 02:09:56 -0000 Received: (qmail 1516 invoked by uid 0); 15 Nov 2012 20:39:01 -0000 Received: from unknown (HELO atl4mhib12.myregisteredsite.com) (209) by 0 with SMTP; 15 Nov 2012 20:39:01 -0000 Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by atl4mhib12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id qAFKd0NL021406 for ; Thu, 15 Nov 2012 15:39:00 -0500 Received: from hub.freebsd.org (hub.FreeBSD.org [8.8.178.136]) by mx2.freebsd.org (Postfix) with ESMTP id 599503B62FB; Thu, 15 Nov 2012 20:38:46 +0000 (UTC) Received: from hub.FreeBSD.org (hub.FreeBSD.org [8.8.178.136]) by hub.freebsd.org (Postfix) with ESMTP id 079BDE35; Thu, 15 Nov 2012 20:38:44 +0000 (UTC) (envelope-from owner-freebsd-current@freebsd.org) Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4E976CA1; Thu, 15 Nov 2012 20:38:35 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 193058FC08; Thu, 15 Nov 2012 20:38:33 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA06227; Thu, 15 Nov 2012 22:38:32 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZ6Cl-000Nz0-Ri; Thu, 15 Nov 2012 22:38:31 +0200 Message-ID: <50A552C5.5060703@FreeBSD.org> Date: Thu, 15 Nov 2012 22:38:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page References: <50A4E8C0.5030608@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-current@freebsd.org Sender: owner-freebsd-current@freebsd.org X-SpamScore: 0 X-MailHub-Apparently-To: mjm@michaelmeltzer.com X-MailHub-Forwarded: Yes Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 02:09:58 -0000 on 15/11/2012 20:46 Attilio Rao said the following: > On 11/15/12, Andriy Gapon wrote: >> >> To people knowing the code, >> >> do the following documentation changes look correct? > > The latter chunk is not correct. > It will panic only if assertions are on. But the current content is not correct too? > I was thinking that however > it would be good idea to patch lockmgr to panic also in non-debugging > kernel situation. It would make sense indeed, IMO. -- Andriy Gapon _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 02:49:12 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E3591466; Fri, 16 Nov 2012 02:49:12 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-ia0-f182.google.com (mail-ia0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 97B7C8FC08; Fri, 16 Nov 2012 02:49:12 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id x2so1784653iad.13 for ; Thu, 15 Nov 2012 18:49:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SwepmvNJ98/muRJDjY1vrFbInlz1HiPkvEU/7uybzNY=; b=Gx+tGlsZKA2oHzJqnItlZWhnSWBkZFQVrxNIT4RPTC6t3A2Cmu3K260cAcg7C62C8B LbNrQwsKP0BuXgt+lR5SI4oadVZYGuf7aM4ssBV1qdSS0aEnoHnI33SF3OW4xm0ESJ2p jtBkHirCewxopoCFfR89Hbly9+Mp7PLAhcqCQfJDjeib8SkzLYKCRDBFxMdnSMCjh6G7 zk56bUoi/VENRkTzQTFCK9V28zCeR8aw8rPXfSko7H15OIgjclzmqvr17GCRMofeQ+GW m+mli3pBzm8WvyvVsH7aQgkLkqPDF18aK44CFuaX6GtPFQlOBPsWRJkCvCiHUspQwiyr P7Qg== MIME-Version: 1.0 Received: by 10.50.33.169 with SMTP id s9mr1875283igi.19.1353034151086; Thu, 15 Nov 2012 18:49:11 -0800 (PST) Received: by 10.64.49.44 with HTTP; Thu, 15 Nov 2012 18:49:10 -0800 (PST) In-Reply-To: References: Date: Thu, 15 Nov 2012 18:49:10 -0800 Message-ID: Subject: Re: stop_cpus_hard when multiple CPUs are panicking from an NMI From: Neel Natu To: attilio@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-hackers@freebsd.org" , Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 02:49:13 -0000 Hi, On Thu, Nov 15, 2012 at 3:41 PM, Attilio Rao wrote: > On Thu, Nov 15, 2012 at 10:58 PM, Ryan Stone wrote: >> At work we have some custom watchdog hardware that sends an NMI upon >> expiry. We've modified the kernel to panic when it receives the watchdog >> NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've >> discovered that when my watchdog expires, the system gets completely >> wedged. After some digging, I've discovered is that I have multiple CPUs >> getting the watchdog NMI and trying to panic concurrently. One of the CPUs >> wins, and the rest spin forever in this code: > > Quick question: can you control the way your watchdog sends the NMI? > Like only to BSP rather than broadcast, etc. It can be done but you really want the NMI to be broadcast since the watchdog is firing because some cpu is "hung" and you don't know which one it is. best Neel > This is tied to the very unique situation that you cannot really > deliver the (second) NMI. > > Attilio > > > -- > Peace can only be achieved by understanding - A. Einstein > _______________________________________________ > 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 Nov 16 07:19:38 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6ADE5E51; Fri, 16 Nov 2012 07:19:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ED4F78FC0C; Fri, 16 Nov 2012 07:19:36 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA12480; Fri, 16 Nov 2012 09:19:34 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZGD8-000135-3s; Fri, 16 Nov 2012 09:19:34 +0200 Message-ID: <50A5E904.9040808@FreeBSD.org> Date: Fri, 16 Nov 2012 09:19:32 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Ian Lepore , Adrian Chadd , freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 07:19:38 -0000 on 16/11/2012 01:38 Attilio Rao said the following: > On Thu, Nov 15, 2012 at 8:51 PM, Andriy Gapon wrote: >> on 15/11/2012 22:00 Adrian Chadd said the following: >>> But I think my change is invaluable for development, where you want to >>> improve and debug the locking and lock interactions of a subsystem. >> >> My practical experience was that if you mess up one lock in one place, then it >> is a total mess further on. but apparently you've got a different practical >> experience :) >> What would indeed be invaluable to _me_ - if the LOR messages also produced the >> stack(s) where a supposedly correct lock order was learned. > > Please note that the "supposedly correct lock order", as for the > definition that it is correct, can be used in several different > stacks. I don't see the point of saving it somewhere. > The only helpful case would be if the "wrong order" is catched first. > If this is really the case, I suggest you to force the order you > expect in the static table so that the first time the wrong order > happens it yells. Exactly my point - if I am a user of some code, not its developer, and I don't know which one is the correct order I would have had the complete information from the very start instead of having to jump through the hoops. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 07:22:36 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 54E6AFEE; Fri, 16 Nov 2012 07:22:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EFA858FC08; Fri, 16 Nov 2012 07:22:33 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA12528; Fri, 16 Nov 2012 09:22:29 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZGFw-00013D-SJ; Fri, 16 Nov 2012 09:22:28 +0200 Message-ID: <50A5E9B4.5040807@FreeBSD.org> Date: Fri, 16 Nov 2012 09:22:28 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> <50A578A6.1030005@mu.org> In-Reply-To: <50A578A6.1030005@mu.org> X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, Ian Lepore , Adrian Chadd , freebsd-hackers@FreeBSD.org, freebsd-arch@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 07:22:36 -0000 on 16/11/2012 01:20 Alfred Perlstein said the following: > We need to enable developers to skip these areas and test their own code. I wish that there was a magic knob to ignore build breakages, so that the developers could test how their own code compiles :-) On a serious note, why stop here? E.g. Solaris seems to have knob to ignore all asserts (just to print a message, but not panic). -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 07:54:24 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCA7A971 for ; Fri, 16 Nov 2012 07:54:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 02F468FC12 for ; Fri, 16 Nov 2012 07:54:23 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA12848; Fri, 16 Nov 2012 09:54:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TZGkn-00014Z-1O; Fri, 16 Nov 2012 09:54:21 +0200 Message-ID: <50A5F12C.1050902@FreeBSD.org> Date: Fri, 16 Nov 2012 09:54:20 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121030 Thunderbird/16.0.2 MIME-Version: 1.0 To: Ryan Stone Subject: Re: stop_cpus_hard when multiple CPUs are panicking from an NMI References: In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 07:54:25 -0000 on 16/11/2012 00:58 Ryan Stone said the following: > At work we have some custom watchdog hardware that sends an NMI upon > expiry. We've modified the kernel to panic when it receives the watchdog > NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've > discovered that when my watchdog expires, the system gets completely > wedged. After some digging, I've discovered is that I have multiple CPUs > getting the watchdog NMI and trying to panic concurrently. One of the CPUs > wins, and the rest spin forever in this code: > > /* > * We don't want multiple CPU's to panic at the same time, so we > * use panic_cpu as a simple spinlock. We have to keep checking > * panic_cpu if we are spinning in case the panic on the first > * CPU is canceled. > */ > if (panic_cpu != PCPU_GET(cpuid)) > while (atomic_cmpset_int(&panic_cpu, NOCPU, > PCPU_GET(cpuid)) == 0) > while (panic_cpu != NOCPU) > ; /* nothing */ > > The system wedges when stop_cpus_hard() is called, which sends NMIs to all > of the other CPUs and waits for them to acknowledge that they are stopped > before returning. However the CPU will not deliver an NMI to a CPU that is > already handling an NMI, so the other CPUs that got a watchdog NMI and are > spinning will never go into the NMI handler and acknowledge that they are > stopped. I thought about this issue and fixed (in my tree) in a different way: http://people.freebsd.org/~avg/cpu_stop-race.diff The need for spinlock_enter in the patch in not entirely clear. The main idea is that a CPU which calls cpu_stop and loses a race should voluntary enter cpustop_handler. I am also not sure about MI-cleanness of this patch. P.S. I also have the hard stop and the "soft" stop separate in my tree. Just in case there is a "simultaneous" occurrence of the soft stop happening for whatever reason and the hard stop for panic or kdb entry, I always want the hard stop to override the soft stop. > I've been able to work around this with the following hideous hack: > > --- kern_shutdown.c 2012-08-17 10:25:02.000000000 -0400 > +++ kern_shutdown.c 2012-11-15 17:04:10.000000000 -0500 > @@ -658,11 +658,15 @@ > * panic_cpu if we are spinning in case the panic on the first > * CPU is canceled. > */ > - if (panic_cpu != PCPU_GET(cpuid)) > + if (panic_cpu != PCPU_GET(cpuid)) { > while (atomic_cmpset_int(&panic_cpu, NOCPU, > - PCPU_GET(cpuid)) == 0) > + PCPU_GET(cpuid)) == 0) { > + atomic_set_int(&stopped_cpus, PCPU_GET(cpumask)); > while (panic_cpu != NOCPU) > ; /* nothing */ > + } > + atomic_clear_int(&stopped_cpus, PCPU_GET(cpumask)); > + } > > if (stop_scheduler_on_panic) { > if (panicstr == NULL && !kdb_active) > > > But I'm hoping that somebody has some ideas on a better way to fix this > kind of problem. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 08:26:43 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 00161BA; Fri, 16 Nov 2012 08:26:42 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CAB2D8FC08; Fri, 16 Nov 2012 08:26:42 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id 5A55C1A3D93; Fri, 16 Nov 2012 00:26:41 -0800 (PST) Message-ID: <50A5F8C1.6010700@mu.org> Date: Fri, 16 Nov 2012 00:26:41 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> <50A578A6.1030005@mu.org> <50A5E9B4.5040807@FreeBSD.org> In-Reply-To: <50A5E9B4.5040807@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@FreeBSD.org, Ian Lepore , Adrian Chadd , freebsd-arch@FreeBSD.org, freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 08:26:43 -0000 On 11/15/12 11:22 PM, Andriy Gapon wrote: > on 16/11/2012 01:20 Alfred Perlstein said the following: >> We need to enable developers to skip these areas and test their own code. > I wish that there was a magic knob to ignore build breakages, so that the > developers could test how their own code compiles :-) There is, it's called updating to known good tinderbox build and basing changes off of that. > > On a serious note, why stop here? E.g. Solaris seems to have knob to ignore all > asserts (just to print a message, but not panic). > There is no reason why not to add such a thing, in fact it would be really handy for some of our users who need asserts, but sometimes can't clean up the entire code base. Adding another option to tag asserts so that it was sort of like: KASSERT((cond, section, "string")); would be interesting, then you could turn KASSERTS on based on "vfs" or possibly file by file. -Alfred From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 08:59:27 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D1E5A88A for ; Fri, 16 Nov 2012 08:59:27 +0000 (UTC) (envelope-from white.heron@yahoo.com) Received: from nm11-vm0.bullet.mail.ne1.yahoo.com (nm11-vm0.bullet.mail.ne1.yahoo.com [98.138.90.58]) by mx1.freebsd.org (Postfix) with ESMTP id 7D7CA8FC08 for ; Fri, 16 Nov 2012 08:59:27 +0000 (UTC) Received: from [98.138.90.57] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 16 Nov 2012 08:56:29 -0000 Received: from [98.138.88.237] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 16 Nov 2012 08:56:29 -0000 Received: from [127.0.0.1] by omp1037.mail.ne1.yahoo.com with NNFMP; 16 Nov 2012 08:56:29 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 632808.51897.bm@omp1037.mail.ne1.yahoo.com Received: (qmail 24720 invoked by uid 60001); 16 Nov 2012 08:56:28 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353056188; bh=e8rmlm4XIU2vji5IgSEc+ggX5WjJt3UXGj5dxzcAOzw=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=bWqrqx7etfYY6KOBlYQJP251nZoIc7/k7joGeQMEgF6pc14cHWlttkcRNyxTgtkXJuqXMMGV+qpDpMU1KN7yM1nNC2j9bewk2p+1JgubhgXALq1AQOv9hdrUhLwRQsQpZ2zSyiYfW1/nXYWHVgvh8KvKJFdHPql8nqmLh4Y9p/Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=KM7eVZxO3Fh91TuBLFwTvApjJO+bD93Psx0kcDDstAbes5l47RE+ZeYMBnJRdEaxfHzc3L/YZysnwaKQA02PYlYJu3E5jf/1u0LWfWF3nbWRBWq5USRqf8nMq8ujZhvoW5MstG0ZBghK3IQ7oK7d0vvq32SHmYMB8ByxUivinKc=; X-YMail-OSG: OefXnGIVM1k_VdcP2eOD_DN8QT1YskR8awfSsmBHoz4zX4k P3ZNuekh.625k1srp5.eHXWYZaaETYAe0rLh2bA6Sn.TaedyRa1BYYC.ehs2 93c5YJcLLWC_jo1j2Uw6.Uc81kVWC.OhxpwmD.PNL_fFnN9Nlwsq6C6urEmL UAkcSnVRuBW8oRZK6_aEKMkpcNzcmoFgftFjy.x3su8ohvYwZM3tTC_MpBKg pSc6_50VCA_9zOm.3M1npWfjHefqGS8I_A5yITgRjC5KU1tcvuupwkOjQ04G dJb2iFGv2YpK1KjLGNRVHtp3R7N5dt5o0AcjIa0ndJArrMl.BISI2FPVqZui 3bJtIWpfQaK7ZkNEfd7qOYp0s8sRD8MGELXlZwCDiOKwvcat4GbuTeuMoFOd KNGyUtTttA3ehuDbolK4Kio69K6aKSI2o39q8CQV32JXP5Mk0vz4vV1OlMji 8RTjlE4CT43yI_8L86syTi86NsMrRViOKJ7NcxUDCisDx7uhdng-- Received: from [42.152.12.185] by web110712.mail.gq1.yahoo.com via HTTP; Fri, 16 Nov 2012 00:56:28 PST X-Rocket-MIMEInfo: 001.001, RGVhciBBbGwsCgpJIGFtIGtlZW4gdG8ga25vdyBpZiB5b3UgaGF2ZSBhbnkgZ3VpZGVsaW5lIGZvciBCdWlsZCBhbmQgUmVsZWFzZSBBdXRvbWF0aW9uIHdpdGggUGVybCBMYW5ndWFnZS4KSSBhbSBpbnRlcmVzdGVkIHRvIGRyaWxsIGRvd24gZnVydGhlciB0byBleHBsb3JlIHRoaXMgZmllbGQuIEtpbmRseSBhZHZpc2VkLiBUaGFua3MuCsKgClJlZ2FyZHMsCgoKTVQgVEFKVURJTgEwAQEBAQ-- X-Mailer: YahooMailWebService/0.8.123.460 Message-ID: <1353056188.15906.YahooMailNeo@web110712.mail.gq1.yahoo.com> Date: Fri, 16 Nov 2012 00:56:28 -0800 (PST) From: "white.heron white" Subject: Build and Release automation with Perl. To: "freebsd-hackers@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "white.heron white" List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 08:59:28 -0000 Dear All,=0A=0AI am keen to know if you have any guideline for Build and Re= lease Automation with Perl Language.=0AI am interested to drill down furthe= r to explore this field. Kindly advised. Thanks.=0A=A0=0ARegards,=0A=0A=0AM= T TAJUDIN From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 12:30:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 32922614; Fri, 16 Nov 2012 12:30:15 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 70E5B8FC12; Fri, 16 Nov 2012 12:30:13 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2644434lbb.13 for ; Fri, 16 Nov 2012 04:30:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=x6pkarpIu2txHyeISNTYtEBC+DnhdRw5xk3vxEBjZxM=; b=RfIIjb5KwUdlvGlI3O55P7+AVJm9b10Lvx4OsPMORCkXhf9DZG1FnPFzK/XsxYfc/7 1HVtg/Zm6+dne31XPKhBptCtWJW7Ddt3luXnuFSVVJ6XN5fmKnBS4vH9jU3nvNrhJKTn BQDqSVn/vD6N/UkFaD5WcQs1tdvu1lqbsy/PR05/4MFlZr+M6JsIEv5hOCtaTeS7OvdA 89Gp5A/YjVWsN+1vhsMeEDvcB8MdDjwfyNGqsBDEn4pIgUC0oB9o9IyEcXxxAyX3F0Gh PSq/GT3mC29lUXQMcuK+JrUw/GdoKGOrZ3MAUQvnJghb7U1ez1x/SuFSdFXpgvzjM4uL d9/Q== MIME-Version: 1.0 Received: by 10.152.132.3 with SMTP id oq3mr4072246lab.18.1353069013097; Fri, 16 Nov 2012 04:30:13 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Fri, 16 Nov 2012 04:30:12 -0800 (PST) In-Reply-To: <50A5F12C.1050902@FreeBSD.org> References: <50A5F12C.1050902@FreeBSD.org> Date: Fri, 16 Nov 2012 12:30:12 +0000 X-Google-Sender-Auth: M9DuE0VU4l0D4k-H-XsHXG100Lo Message-ID: Subject: Re: stop_cpus_hard when multiple CPUs are panicking from an NMI From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 12:30:15 -0000 On Fri, Nov 16, 2012 at 7:54 AM, Andriy Gapon wrote: > on 16/11/2012 00:58 Ryan Stone said the following: >> At work we have some custom watchdog hardware that sends an NMI upon >> expiry. We've modified the kernel to panic when it receives the watchdog >> NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've >> discovered that when my watchdog expires, the system gets completely >> wedged. After some digging, I've discovered is that I have multiple CPUs >> getting the watchdog NMI and trying to panic concurrently. One of the CPUs >> wins, and the rest spin forever in this code: >> >> /* >> * We don't want multiple CPU's to panic at the same time, so we >> * use panic_cpu as a simple spinlock. We have to keep checking >> * panic_cpu if we are spinning in case the panic on the first >> * CPU is canceled. >> */ >> if (panic_cpu != PCPU_GET(cpuid)) >> while (atomic_cmpset_int(&panic_cpu, NOCPU, >> PCPU_GET(cpuid)) == 0) >> while (panic_cpu != NOCPU) >> ; /* nothing */ >> >> The system wedges when stop_cpus_hard() is called, which sends NMIs to all >> of the other CPUs and waits for them to acknowledge that they are stopped >> before returning. However the CPU will not deliver an NMI to a CPU that is >> already handling an NMI, so the other CPUs that got a watchdog NMI and are >> spinning will never go into the NMI handler and acknowledge that they are >> stopped. > > I thought about this issue and fixed (in my tree) in a different way: > http://people.freebsd.org/~avg/cpu_stop-race.diff > > The need for spinlock_enter in the patch in not entirely clear. > The main idea is that a CPU which calls cpu_stop and loses a race should > voluntary enter cpustop_handler. > I am also not sure about MI-cleanness of this patch. It is similar to what I propose but with some differences: - It is not clean from MI perspective - I don't think we need to treact it specially, I would just unconditionally stop all the CPUs entering in the "spinlock zone", making the patch simpler. So I guess you are really fine with the proposal I made? Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 12:34:52 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 08817902; Fri, 16 Nov 2012 12:34:52 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 16BD28FC13; Fri, 16 Nov 2012 12:34:49 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id gg13so2648482lbb.13 for ; Fri, 16 Nov 2012 04:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=h1VKn6jICIer4+luGNM9zcnP28FEZvV9ZvIyCumJXYk=; b=ZGONhXRn+YAOh6j3pMTFoerFG5ky186UaeeodpSdx4XU+7GltscoNT54SNxM/15LLL 2SV/JYPod6xtZ/XflHs3SUluy8d0dYyUCivMvtHkCKWHhqTXHffR/qaycZnU4G3q+4zo yMIkBxsrRR9Fr4dmzrpOlU04aaQIpXSpZlMrPF/zdMrG7R56hCpLoOSbFS+keeeMiyOS +LbLoDOBgrYDfOWHqYnf0yAZPtK/giVcXKpRn5P6OdEo1tiSJSiYL6Qd9ionNj+FtOXc tnUpmg+JtbUNhQxppCyqQDmBa8wQ0tW2X7QA3x8zK1GYkqJcMxudq0wy1CuHgnYpxTij euuA== MIME-Version: 1.0 Received: by 10.152.110.234 with SMTP id id10mr4158218lab.15.1353069288423; Fri, 16 Nov 2012 04:34:48 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Fri, 16 Nov 2012 04:34:48 -0800 (PST) In-Reply-To: <50A5E904.9040808@FreeBSD.org> References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> <50A5E904.9040808@FreeBSD.org> Date: Fri, 16 Nov 2012 12:34:48 +0000 X-Google-Sender-Auth: rUcjWfXHcYOS78nbvmgr34faToI Message-ID: Subject: Re: [RFQ] make witness panic an option From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: Ian Lepore , Adrian Chadd , freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 12:34:52 -0000 On Fri, Nov 16, 2012 at 7:19 AM, Andriy Gapon wrote: > on 16/11/2012 01:38 Attilio Rao said the following: >> On Thu, Nov 15, 2012 at 8:51 PM, Andriy Gapon wrote: >>> on 15/11/2012 22:00 Adrian Chadd said the following: >>>> But I think my change is invaluable for development, where you want to >>>> improve and debug the locking and lock interactions of a subsystem. >>> >>> My practical experience was that if you mess up one lock in one place, then it >>> is a total mess further on. but apparently you've got a different practical >>> experience :) >>> What would indeed be invaluable to _me_ - if the LOR messages also produced the >>> stack(s) where a supposedly correct lock order was learned. >> >> Please note that the "supposedly correct lock order", as for the >> definition that it is correct, can be used in several different >> stacks. I don't see the point of saving it somewhere. >> The only helpful case would be if the "wrong order" is catched first. >> If this is really the case, I suggest you to force the order you >> expect in the static table so that the first time the wrong order >> happens it yells. > > Exactly my point - if I am a user of some code, not its developer, and I don't > know which one is the correct order I would have had the complete information > from the very start instead of having to jump through the hoops. I don't agree -- such informations are only useful to developers and also what should we do, store all the valid stacktraces? I don't understand what are you expecting here honestly. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 13:18:24 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AB6E820D; Fri, 16 Nov 2012 13:18:24 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id ADBB28FC12; Fri, 16 Nov 2012 13:18:23 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA16173; Fri, 16 Nov 2012 15:18:21 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50A63D1D.9090500@FreeBSD.org> Date: Fri, 16 Nov 2012 15:18:21 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: stop_cpus_hard when multiple CPUs are panicking from an NMI References: <50A5F12C.1050902@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 13:18:24 -0000 on 16/11/2012 14:30 Attilio Rao said the following: > On Fri, Nov 16, 2012 at 7:54 AM, Andriy Gapon wrote: >> on 16/11/2012 00:58 Ryan Stone said the following: >>> At work we have some custom watchdog hardware that sends an NMI upon >>> expiry. We've modified the kernel to panic when it receives the watchdog >>> NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've >>> discovered that when my watchdog expires, the system gets completely >>> wedged. After some digging, I've discovered is that I have multiple CPUs >>> getting the watchdog NMI and trying to panic concurrently. One of the CPUs >>> wins, and the rest spin forever in this code: >>> >>> /* >>> * We don't want multiple CPU's to panic at the same time, so we >>> * use panic_cpu as a simple spinlock. We have to keep checking >>> * panic_cpu if we are spinning in case the panic on the first >>> * CPU is canceled. >>> */ >>> if (panic_cpu != PCPU_GET(cpuid)) >>> while (atomic_cmpset_int(&panic_cpu, NOCPU, >>> PCPU_GET(cpuid)) == 0) >>> while (panic_cpu != NOCPU) >>> ; /* nothing */ >>> >>> The system wedges when stop_cpus_hard() is called, which sends NMIs to all >>> of the other CPUs and waits for them to acknowledge that they are stopped >>> before returning. However the CPU will not deliver an NMI to a CPU that is >>> already handling an NMI, so the other CPUs that got a watchdog NMI and are >>> spinning will never go into the NMI handler and acknowledge that they are >>> stopped. >> >> I thought about this issue and fixed (in my tree) in a different way: >> http://people.freebsd.org/~avg/cpu_stop-race.diff >> >> The need for spinlock_enter in the patch in not entirely clear. >> The main idea is that a CPU which calls cpu_stop and loses a race should >> voluntary enter cpustop_handler. >> I am also not sure about MI-cleanness of this patch. > > It is similar to what I propose but with some differences: > - It is not clean from MI perspective OK. > - I don't think we need to treact it specially, I would just > unconditionally stop all the CPUs entering in the "spinlock zone", > making the patch simpler. I couldn't understand this part. > So I guess you are really fine with the proposal I made? I definitely agree with with the MI cpustop_handler part. I couldn't understand the rest of the proposal. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 14:41:55 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 464A7DA6; Fri, 16 Nov 2012 14:41:55 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 82A278FC08; Fri, 16 Nov 2012 14:41:53 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so84975lbb.13 for ; Fri, 16 Nov 2012 06:41:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=mMNOsan7hzUfDB0p3b3+z+HEMDsroJEiyFFD90gPlDI=; b=q+WZJA5m7tb8xKHVN4mZDYIr+TlC3zKUaXOXUnhZ0+O0KXu+l38C4VV0FEvhKaYKWz roGCb58uXa5VSjT8PskNow6qaU1jFRQqRQtWWcMtSXYPp14Ssco8NM2S4i0IQphnad+H JuMBeduTMxknryXbcAxp20Gyw3G9GrONALpfSXdb5YXHnMwJVrfLxmedysz6j2NjGmv/ m24pUD9cPtJdL2xNrWMjaW/Q+d4WzMlLxasqvltqMrpiq6l0NtLsRDlllwCXoc31tMfC kBSdnvjWRToz4ESFYDDIG1KSlEM4fNcauJE1rrOHI4o9PMlbXvH0LK6QizalU7l8yxDk 0qVg== MIME-Version: 1.0 Received: by 10.152.162.1 with SMTP id xw1mr4538329lab.3.1353076913094; Fri, 16 Nov 2012 06:41:53 -0800 (PST) Sender: asmrookie@gmail.com Received: by 10.112.134.5 with HTTP; Fri, 16 Nov 2012 06:41:52 -0800 (PST) In-Reply-To: <50A63D1D.9090500@FreeBSD.org> References: <50A5F12C.1050902@FreeBSD.org> <50A63D1D.9090500@FreeBSD.org> Date: Fri, 16 Nov 2012 14:41:52 +0000 X-Google-Sender-Auth: MhT3I1BWQSkQMehTXlTy32gWNNk Message-ID: Subject: Re: stop_cpus_hard when multiple CPUs are panicking from an NMI From: Attilio Rao To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 Cc: freebsd-hackers@freebsd.org, Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: attilio@FreeBSD.org List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 14:41:55 -0000 On Fri, Nov 16, 2012 at 1:18 PM, Andriy Gapon wrote: > on 16/11/2012 14:30 Attilio Rao said the following: >> On Fri, Nov 16, 2012 at 7:54 AM, Andriy Gapon wrote: >>> on 16/11/2012 00:58 Ryan Stone said the following: >>>> At work we have some custom watchdog hardware that sends an NMI upon >>>> expiry. We've modified the kernel to panic when it receives the watchdog >>>> NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've >>>> discovered that when my watchdog expires, the system gets completely >>>> wedged. After some digging, I've discovered is that I have multiple CPUs >>>> getting the watchdog NMI and trying to panic concurrently. One of the CPUs >>>> wins, and the rest spin forever in this code: >>>> >>>> /* >>>> * We don't want multiple CPU's to panic at the same time, so we >>>> * use panic_cpu as a simple spinlock. We have to keep checking >>>> * panic_cpu if we are spinning in case the panic on the first >>>> * CPU is canceled. >>>> */ >>>> if (panic_cpu != PCPU_GET(cpuid)) >>>> while (atomic_cmpset_int(&panic_cpu, NOCPU, >>>> PCPU_GET(cpuid)) == 0) >>>> while (panic_cpu != NOCPU) >>>> ; /* nothing */ >>>> >>>> The system wedges when stop_cpus_hard() is called, which sends NMIs to all >>>> of the other CPUs and waits for them to acknowledge that they are stopped >>>> before returning. However the CPU will not deliver an NMI to a CPU that is >>>> already handling an NMI, so the other CPUs that got a watchdog NMI and are >>>> spinning will never go into the NMI handler and acknowledge that they are >>>> stopped. >>> >>> I thought about this issue and fixed (in my tree) in a different way: >>> http://people.freebsd.org/~avg/cpu_stop-race.diff >>> >>> The need for spinlock_enter in the patch in not entirely clear. >>> The main idea is that a CPU which calls cpu_stop and loses a race should >>> voluntary enter cpustop_handler. >>> I am also not sure about MI-cleanness of this patch. >> >> It is similar to what I propose but with some differences: >> - It is not clean from MI perspective > > OK. > >> - I don't think we need to treact it specially, I would just >> unconditionally stop all the CPUs entering in the "spinlock zone", >> making the patch simpler. > > I couldn't understand this part. I'm sorry, I think I misread your patch. I was basically suggesting to fix Ryan case by calling cpustop_handler() (or the new MI interface) into the panic() function, in the case the CPU don't win the race for panic_cpu. Basically doing: Index: sys/kern/kern_shutdown.c =================================================================== --- sys/kern/kern_shutdown.c (revision 243154) +++ sys/kern/kern_shutdown.c (working copy) @@ -568,15 +568,11 @@ panic(const char *fmt, ...) #ifdef SMP /* * We don't want multiple CPU's to panic at the same time, so we - * use panic_cpu as a simple spinlock. We have to keep checking - * panic_cpu if we are spinning in case the panic on the first - * CPU is canceled. + * use panic_cpu as a simple lock. */ if (panic_cpu != PCPU_GET(cpuid)) - while (atomic_cmpset_int(&panic_cpu, NOCPU, - PCPU_GET(cpuid)) == 0) - while (panic_cpu != NOCPU) - ; /* nothing */ + if (atomic_cmpset_int(&panic_cpu, NOCPU, PCPU_GET(cpuid)) == 0) + cpustop_handler(); if (stop_scheduler_on_panic) { if (panicstr == NULL && !kdb_active) { Infact it seems to me that the comment is outdated and no longer represent truth. Attilio -- Peace can only be achieved by understanding - A. Einstein From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 14:47:39 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8733D1B8; Fri, 16 Nov 2012 14:47:39 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 969DF8FC14; Fri, 16 Nov 2012 14:47:38 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA17019; Fri, 16 Nov 2012 16:47:36 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50A65208.4050804@FreeBSD.org> Date: Fri, 16 Nov 2012 16:47:36 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: stop_cpus_hard when multiple CPUs are panicking from an NMI References: <50A5F12C.1050902@FreeBSD.org> <50A63D1D.9090500@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, Ryan Stone X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 14:47:39 -0000 on 16/11/2012 16:41 Attilio Rao said the following: > On Fri, Nov 16, 2012 at 1:18 PM, Andriy Gapon wrote: >> on 16/11/2012 14:30 Attilio Rao said the following: >>> On Fri, Nov 16, 2012 at 7:54 AM, Andriy Gapon wrote: >>>> on 16/11/2012 00:58 Ryan Stone said the following: >>>>> At work we have some custom watchdog hardware that sends an NMI upon >>>>> expiry. We've modified the kernel to panic when it receives the watchdog >>>>> NMI. I've been trying the "stop_scheduler_on_panic" mode, and I've >>>>> discovered that when my watchdog expires, the system gets completely >>>>> wedged. After some digging, I've discovered is that I have multiple CPUs >>>>> getting the watchdog NMI and trying to panic concurrently. One of the CPUs >>>>> wins, and the rest spin forever in this code: >>>>> >>>>> /* >>>>> * We don't want multiple CPU's to panic at the same time, so we >>>>> * use panic_cpu as a simple spinlock. We have to keep checking >>>>> * panic_cpu if we are spinning in case the panic on the first >>>>> * CPU is canceled. >>>>> */ >>>>> if (panic_cpu != PCPU_GET(cpuid)) >>>>> while (atomic_cmpset_int(&panic_cpu, NOCPU, >>>>> PCPU_GET(cpuid)) == 0) >>>>> while (panic_cpu != NOCPU) >>>>> ; /* nothing */ >>>>> >>>>> The system wedges when stop_cpus_hard() is called, which sends NMIs to all >>>>> of the other CPUs and waits for them to acknowledge that they are stopped >>>>> before returning. However the CPU will not deliver an NMI to a CPU that is >>>>> already handling an NMI, so the other CPUs that got a watchdog NMI and are >>>>> spinning will never go into the NMI handler and acknowledge that they are >>>>> stopped. >>>> >>>> I thought about this issue and fixed (in my tree) in a different way: >>>> http://people.freebsd.org/~avg/cpu_stop-race.diff >>>> >>>> The need for spinlock_enter in the patch in not entirely clear. >>>> The main idea is that a CPU which calls cpu_stop and loses a race should >>>> voluntary enter cpustop_handler. >>>> I am also not sure about MI-cleanness of this patch. >>> >>> It is similar to what I propose but with some differences: >>> - It is not clean from MI perspective >> >> OK. >> >>> - I don't think we need to treact it specially, I would just >>> unconditionally stop all the CPUs entering in the "spinlock zone", >>> making the patch simpler. >> >> I couldn't understand this part. > > I'm sorry, I think I misread your patch. > > I was basically suggesting to fix Ryan case by calling > cpustop_handler() (or the new MI interface) into the panic() function, > in the case the CPU don't win the race for panic_cpu. > Basically doing: > Index: sys/kern/kern_shutdown.c > =================================================================== > --- sys/kern/kern_shutdown.c (revision 243154) > +++ sys/kern/kern_shutdown.c (working copy) > @@ -568,15 +568,11 @@ panic(const char *fmt, ...) > #ifdef SMP > /* > * We don't want multiple CPU's to panic at the same time, so we > - * use panic_cpu as a simple spinlock. We have to keep checking > - * panic_cpu if we are spinning in case the panic on the first > - * CPU is canceled. > + * use panic_cpu as a simple lock. > */ > if (panic_cpu != PCPU_GET(cpuid)) > - while (atomic_cmpset_int(&panic_cpu, NOCPU, > - PCPU_GET(cpuid)) == 0) > - while (panic_cpu != NOCPU) > - ; /* nothing */ > + if (atomic_cmpset_int(&panic_cpu, NOCPU, PCPU_GET(cpuid)) == 0) > + cpustop_handler(); > > if (stop_scheduler_on_panic) { > if (panicstr == NULL && !kdb_active) { > > > Infact it seems to me that the comment is outdated and no longer > represent truth. Ah, I see. Thank you. My older plan was to get rid of stop_scheduler_on_panic, that is to make the behavior unconditional. And then to use stop_cpus_hard instead of the hand-rolled 'panic_cpu' spinlock. This way the whichever CPU wins stop_cpus_hard would be the only CPU to enter panic. Sorry, if I was not fully clear when I posted my patch. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 14:49:28 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6999B2D4; Fri, 16 Nov 2012 14:49:28 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1BBED8FC12; Fri, 16 Nov 2012 14:49:26 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id QAA16963; Fri, 16 Nov 2012 16:42:11 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <50A650C2.7060407@FreeBSD.org> Date: Fri, 16 Nov 2012 16:42:10 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: attilio@FreeBSD.org Subject: Re: LK_SHARED/LK_DOWNGRADE adjustments to lock.9 manual page References: <50A4E8C0.5030608@FreeBSD.org> <50A552C5.5060703@FreeBSD.org> In-Reply-To: X-Enigmail-Version: 1.4.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org, freebsd-current@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 14:49:28 -0000 on 15/11/2012 23:44 Attilio Rao said the following: > Do you think you can test this patch?: > http://www.freebsd.org/~attilio/lockmgr_forcerec.patch I will use this patch in my tree, but I think that it is effectively already quite well tested by using INVARIANTS+WITNESS. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 16:54:15 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 18B64C72 for ; Fri, 16 Nov 2012 16:54:15 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id B7BC08FC12 for ; Fri, 16 Nov 2012 16:54:12 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo13so4008575vcb.13 for ; Fri, 16 Nov 2012 08:54:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=yGoKVEDxOOCbHNQxq3VRSgFAjdMgA20xB/qSP2tuvM0=; b=Fak+HCdnUZnE04S6uJBsYYb/UKX70R6S2l1tlpRnEs8rf7CRm8QKuBvr3vI4CGDJNm GOgXepmQ4naJ8ulyBNZvgqtGwZDhNXrx4oP6K38LjW+aBj3AhjHMazJwHCylxbskb5vY oBBBFQLuJvO/te9pSpYgrjav8/T3I+an7D3wEGvtm/Az7Sm/+wzuWIntlkPo/tkDCx49 Ed4EyR3T5kWlpku5hEHUBANirkCpfEKs6bjs9kXywckkI2+xjITLWL/5e1q/9y40HOn8 rOCljeih6j+imbb1x6KdIuuAQwUNLPFflSiWblB1fnQqzaXHjg/B7lhp4RbySSQyEgRo CkDQ== MIME-Version: 1.0 Received: by 10.52.100.5 with SMTP id eu5mr6500531vdb.34.1353084851741; Fri, 16 Nov 2012 08:54:11 -0800 (PST) Received: by 10.58.220.202 with HTTP; Fri, 16 Nov 2012 08:54:11 -0800 (PST) X-Originating-IP: [209.66.78.50] Date: Fri, 16 Nov 2012 11:54:11 -0500 Message-ID: Subject: Using PC-Sysinstall for automated network installs of FreeBSD From: Mark Saad To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl6MLFioGHmPjIPOe6m0gvMVApE6bze2SUW6SEkaLhhTHAJ+DuTN3ViLj983c+QFmV374N3 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 16:54:15 -0000 All I wanted to share with you my method for network installs of FreeBSD 9.1-RCn . This does not use PC-BSD just stock FreeBSD. This should work on 9.0-RELEASE is known to work on 9.1-RC's and BETA. I decided to use pc-sysinstall in place of bsdinstall as pc-sysinstall supported using a config file that could be passed to the installer much like the old sysinstall way of doing things. Jumpstart host: -------------------------- Exported filesystems: /export/ Useful paths on /export, /export/install/freebsd/9.1/{i386,amd64} this is the contents of the install media rsync'd to a local filesystem TFTP configured to server from /tftpboot which is a symlink to /export/install/freebsd/9.1/{i386,amd64} DHCPD configured as follows subnet 10.1.5.0 netmask 255.255.255.0 { authoritative; option netbios-name-servers 10.1.5.252; option routers 10.1.5.1; option subnet-mask 255.255.255.0; option broadcast-address 10.1.5.255; option domain-name "ops.com"; option domain-name-servers 8.8.8.8, 10.1.5.101; next-server 10.1.5.28; option root-path "/tftpboot"; filename "/pxeboot"; default-lease-time 21600; max-lease-time 43200; } Changes to make the install media boot the way I want it. -------------------------------------- 1. I copied boot/pxeboot to /export/install/freebsd/9.1/{i386,amd64} thats a work symantic not required 2. I created a conf directory to store my pc-sysinatll configs 3. I added the following bits to rc.conf to make the nfs root happy sendmail_enable="NONE" hostid_enable="NO" update_motd="NO" hostid_enable="NO" varmfs="YES" hostname="jumpstart00.ops.com" 4. I modified the fstab file as follows #/dev/iso9660/FREEBSD_INSTALL / cd9660 ro 0 0 none /tmp tmpfs rw 0 0 5 I changed my rc.conf to start a simple shell script and not the bsdinstall bits export TERM=vt220 echo "o PC-SYSINSTALL " exec /conf/picker.sh 6. Here is /conf/picker.sh #!/bin/sh : ${DIALOG_OK=0} : ${DIALOG_CANCEL=1} : ${DIALOG_HELP=2} : ${DIALOG_EXTRA=3} : ${DIALOG_ITEM_HELP=4} : ${DIALOG_ESC=255} dialog --backtitle "FreeBSD Jumpstart" --title "Welcome" --no-label "Shell" --yes-label "Install" --yesno "Welcome to FreeBSD! Woul d you like to begin an installation or use the live filesystem?" 0 0 case $? in $DIALOG_OK) # Install exec /conf/disk.sh ;; $DIALOG_CANCEL) # Live CD ;; esac 7. Here is /conf/disk.sh #!/bin/sh : ${DIALOG_OK=0} : ${DIALOG_CANCEL=1} : ${DIALOG_HELP=2} : ${DIALOG_EXTRA=3} : ${DIALOG_ITEM_HELP=4} : ${DIALOG_ESC=255} dialog --backtitle "FreeBSD Jumpstart" --title "Select disk type" --no-label "SCSI/SAS da0" --yes-label "IDE/SATA ada0" --yesno "Se lect Your servers root disk type" 0 0 case $? in $DIALOG_OK) # Install IDE/SATA exec /usr/sbin/pc-sysinstall -c /conf/ada-install.cfg ;; $DIALOG_CANCEL) # Install SCSI/SAS exec /usr/sbin/pc-sysinstall -c /conf/da-install.cfg ;; esac exit 255 The install config ------------------------ I created /conf/ada-install.cfg and /conf/da-install.cfg the only difference here is the name of the disk as that is not auto discovered. Here is ada-install.cfg # User Generated pc-sysinstall configuration installInteractive=no installMode=fresh installType=FreeBSD installMedium=local localPath=/usr/freebsd-dist/ installFile=fbsd-release.txz packageType=tar hostname=nynewserver1.ops.com netDev=AUTO-DHCP # Disk Setup disk0=ada0 #Change me to suite your needs partition=ALL bootManager=bsd partscheme=GPT commitDiskPart # Partition Setup for da0(ALL) # All sizes are expressed in MB # Avail FS Types, UFS, UFS+S, UFS+SUJ, UFS+J, ZFS, SWAP # UFS.eli, UFS+S.eli, UFS+SUJ, UFS+J.eli, ZFS.eli, SWAP.eli disk0-part=UFS+SUJ 0 / disk0-part=SWAP 4096 none disk0-part=UFS+SUJ 10240 /var commitDiskLabel # Optional Components #installComponents=src # Root Password rootPass=iAmAwinner # Setup basic network runCommand=echo 'ifconfig_bge0="DHCP"' >>/etc/rc.conf runCommand=echo 'ifconfig_em0="DHCP"' >>/etc/rc.conf runCommand=echo 'ifconfig_igb0="DHCP"' >>/etc/rc.conf runCommand=echo 'ifconfig_bce0="DHCP"' >>/etc/rc.conf runCommand=echo 'ifconfig_nfe0="DHCP"' >>/etc/rc.conf runCommand=echo 'sshd_enable="YES"' >>/etc/rc.conf runCommand=echo 'ntpd_enable="YES"' >>/etc/rc.conf #Tweak the configs runExtCommand=/mnt/sbin/mount_nullfs /packages/ /mnt/mnt/ runExtCommand=mount -t devfs devfs ${FSMNT}/dev runCommand=echo "-D" > /boot.config runCommand=echo 'boot_multicons="YES"' > /boot/loader.conf runCommand=echo 'boot_serial="YES"' >> /boot/loader.conf runCommand=echo 'comconsole_speed="9600"' >> /boot/loader.conf runCommand=echo 'console="comconsole,vidconsole"' >> /boot/loader.conf runCommand=cp /mnt/sysctl.conf /etc runCommand=cp /mnt/motd /etc runCommand=cp /mnt/ttys /etc runCommand=cp /mnt/sshd_config /etc/ssh/ runCommand=mkdir -p /root/.ssh/ runCommand=chmod 700 /root/.ssh/ runCommand=cp /mnt/authorized_keys /root/.ssh/ runCommand=chmod 600 /root/.ssh/authorized_keys # Set up date/time runCommand=cp /usr/share/zoneinfo/UTC /etc/localtime runCommand=touch /etc/wall_cmos_clock runCommand=adjkerntz -a # Install packages runCommand=pkg_add /mnt/All/bash-4.2.37.tbz runCommand=pkg_add /mnt/All/vim-lite-7.3.632.tbz runCommand=pkg_add /mnt/All/rsync-3.0.9_1.tbz runCommand=pkg_add /mnt/All/perl-5.14.2_2.tbz runCommand=pkg_add /mnt/All/python27-2.7.3_3.tbz runCommand=pkg_add /mnt/All/ruby-1.8.7.370,1.tbz runCommand=pkg_add /mnt/All/lua-5.1.5_4.tbz runCommand=pkg_add /mnt/All/sudo-1.8.5.p3.tbz runCommand=pkg_add /mnt/All/portaudit-0.6.0.tbz runCommand=pkg_add /mnt/All/curl-7.24.0.tbz runCommand=pkg_add /mnt/All/openldap-client-2.4.32_1.tbz runCommand=pkg_add /mnt/All/pam_ldap-1.8.6_2.tbz runCommand=pkg_add /mnt/All/pam_mkhomedir-0.2.tbz runCommand=pkg_add /mnt/All/nss-3.13.6.tbz runCommand=pkg_add /mnt/All/portupgrade-2.4.9.9,2.tbz runCommand=pkg_add /mnt/All/unzip-6.0_1.tbz runCommand=pkg_add /mnt/All/syslog-ng-3.3.5_1.tbz runCommand=pkg_add /mnt/All/cciss_vol_status-1.10.tbz runCommand=pkg_add /mnt/All/compat6x-amd64-6.4.604000.200810_3.tbz runCommand=pkg_add /mnt/All/dmidecode-2.11.tbz runCommand=pkg_add /mnt/All/pcre-8.31.tbz runCommand=pkg_add /mnt/All/mcelog-1.0.p2.tbz runCommand=pkg_add /mnt/All/openjdk6-b25_1.tbz runCommand=pkg_add /mnt/All/net-snmp-5.7.1_7.tbz #Clean up and reboot runExtCommand=umount ${FSMNT}/mnt runExtCommand=umount ${FSMNT}/dev runCommand=shutdown -r now Notes 1. The package install its some hoop jumping but it works. I hope that Kriss More with add a macro to handle this in the future. I would like it use to PKG_PATH to make this simpler. 2. The installed FreeBSD originally came from the fbsd-release.txz on the pc-bsd mirrors however you can provide you own . Work is being done to make this macro use the FreeBSD tar balls provided on the install media . That may make it into 9.1-RELEASE but I doubt it. Thanks to Kriss More for all his help. -- mark saad | nonesuch@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 18:18:35 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0CB0D611; Fri, 16 Nov 2012 18:18:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id B7B558FC13; Fri, 16 Nov 2012 18:18:34 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so2176966pab.13 for ; Fri, 16 Nov 2012 10:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=nRysIY4X4RfararhPqj5VTqIbtfZCBOY1GFCTBbZ3Dw=; b=FcDn2FmlGFtb+K+5mZHGtACC7Ij9zrmR5cJ4epJc7ie3geFXj1gTQrctK6SZPRb7FB po358bqxbjrxOS+qD7DCVhAjq5bZrtVRfv92sz6SvS63i4A4sqPUaloUhQykQCVpyBOm gua5z3LBGVhntQU14c+AzEj3ia5dw5zLc67EXj6aiDZAbkjbKKUI2FMUZXUq9RooRlm4 tVtpNPqah7MFfS1vJuV4IPL2hZ/Ol/icdzbp8mjUGQVEgXZ8OoOG52aOG0CQpPKvMask B8JDeBNmL9FPFk1ST4USPevkxDcOnEGadl7ENKyJBM1Ykk9oJROJPtlzD1oG2NhKhVdo qdRg== MIME-Version: 1.0 Received: by 10.68.251.197 with SMTP id zm5mr17414616pbc.30.1353089914166; Fri, 16 Nov 2012 10:18:34 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.68.124.130 with HTTP; Fri, 16 Nov 2012 10:18:34 -0800 (PST) In-Reply-To: <50A5F8C1.6010700@mu.org> References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> <50A578A6.1030005@mu.org> <50A5E9B4.5040807@FreeBSD.org> <50A5F8C1.6010700@mu.org> Date: Fri, 16 Nov 2012 10:18:34 -0800 X-Google-Sender-Auth: 4fp_vWprDQa8_kIohSiLQx8kh2k Message-ID: Subject: Re: [RFQ] make witness panic an option From: Adrian Chadd To: Alfred Perlstein Content-Type: text/plain; charset=ISO-8859-1 Cc: attilio@freebsd.org, Ian Lepore , freebsd-arch@freebsd.org, Andriy Gapon , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:18:35 -0000 On 16 November 2012 00:26, Alfred Perlstein wrote: > Adding another option to tag asserts so that it was sort of like: > > KASSERT((cond, section, "string")); would be interesting, then you could > turn KASSERTS on based on "vfs" or possibly file by file. That's orthogonal to my developer-focused request. I'm also a big fan of correctly using asserts/panics - ie, asserts shouldn't replace correct error handling. (Yes, I'm guilty of this in ath(4), but I have plans soon to rectify this.) Adrian From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 18:36:08 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2633BAE4; Fri, 16 Nov 2012 18:36:08 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id F2FE28FC08; Fri, 16 Nov 2012 18:36:07 +0000 (UTC) Received: from Alfreds-MacBook-Pro-5.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id F05911A3DB3; Fri, 16 Nov 2012 10:36:06 -0800 (PST) Message-ID: <50A68796.60603@mu.org> Date: Fri, 16 Nov 2012 10:36:06 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [RFQ] make witness panic an option References: <1353001175.1217.153.camel@revolution.hippie.lan> <1353009310.1217.172.camel@revolution.hippie.lan> <50A555BD.1010105@FreeBSD.org> <50A578A6.1030005@mu.org> <50A5E9B4.5040807@FreeBSD.org> <50A5F8C1.6010700@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: attilio@freebsd.org, Ian Lepore , freebsd-arch@freebsd.org, Andriy Gapon , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 18:36:08 -0000 On 11/16/12 10:18 AM, Adrian Chadd wrote: > On 16 November 2012 00:26, Alfred Perlstein wrote: > >> Adding another option to tag asserts so that it was sort of like: >> >> KASSERT((cond, section, "string")); would be interesting, then you could >> turn KASSERTS on based on "vfs" or possibly file by file. > That's orthogonal to my developer-focused request. I'm also a big fan > of correctly using asserts/panics - ie, asserts shouldn't replace > correct error handling. > (Yes, I'm guilty of this in ath(4), but I have plans soon to rectify this.) > > > > Adrian I apologize if you took a wishlist item for me as a request for you to take on/augment your patch. It was not my intention. Back to your work, I like your patch quite a bit, I am wondering though if it can be worked into something under witness_kdb though. -Alfred From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 19:50:22 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D5640E3E for ; Fri, 16 Nov 2012 19:50:22 +0000 (UTC) (envelope-from sushanth_rai@yahoo.com) Received: from nm2-vm0.bullet.mail.sp2.yahoo.com (nm2-vm0.bullet.mail.sp2.yahoo.com [98.139.91.248]) by mx1.freebsd.org (Postfix) with ESMTP id A61238FC15 for ; Fri, 16 Nov 2012 19:50:22 +0000 (UTC) Received: from [98.139.91.69] by nm2.bullet.mail.sp2.yahoo.com with NNFMP; 16 Nov 2012 19:50:22 -0000 Received: from [98.139.44.81] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 16 Nov 2012 19:50:22 -0000 Received: from [127.0.0.1] by omp1018.access.mail.sp2.yahoo.com with NNFMP; 16 Nov 2012 19:50:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 207929.43072.bm@omp1018.access.mail.sp2.yahoo.com Received: (qmail 82678 invoked by uid 60001); 16 Nov 2012 19:50:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1353095421; bh=I1o1TUe/J81Vwi6egTbwQ9NRxCpzc9a8kq5QVV4xCWQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=c8AHOEmUmeQgm3b841meo6NoPmfnhC++C6LQ9a+82Fo+/A73Mv4xtokAhT83rw9UObq0RJIIsrbA9PKVos7M0Yv2Hl+SezM8KcFA1y6Lx/FfNAMIBuwc8eAKch4y1iMcf95Qp67ErHgOlaeD3zHSf9jQFXBR7YOAjVsX++/FMvU= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=GjimkpcVUFy9MEzdZOTc2kZkTlI2hadNfScB/djh7xP4I4QIJwNVrN4wOfDd8vbOI4GPwJPfClKDiyFCFW23E2zFvwTllYSHGwXagnA6rvNNvdMGMmvYM0cwuUZtH4C6olP2r4zt75s/18ttkU7XzgR9nrodsfW4qYQz+MzJ7eM=; X-YMail-OSG: 0DekDTYVM1k1uDy5kseOkVhhqGInUL3Rv38LTlMssKxK2.b xYG.JhaGALjB7P5BJYfmzcQvSiCbDqJJVOOQ5PLXM.V8GmGZ_jfCBVdjLrJI 7I.Wui8Ms_Vr5u4IJ7VzIYeebysAbo_409wCDEyt8nk.IFSRBk0AqWmxOkP3 gvrSYprV5l.n0Y8xRQNRXangqvrfysL.uH0DgdxgIlV6R._hj7ySVzE6K06F 3fPhc3Q7QHIuQkMncdQo8MWL.EC3.sthcvmQuO8SkppPm9jbfVFm86JG59mo LJw2DnXJlt71RRbExgz4hKjiOBB0D0jFNhTDpT6OhUjRF8IFQjKLkIEEBcwJ nIngxB8Y1XxXi2DOIa29m1eSMpQ6J6XzliJTpdcx_5vhZHPNAA2nWPxyZt0I ZcrT0dmBi.bx2Y3p6AYP9wXDL0qrUGXmkJ_VIqY2_RfPhQ1Jm_Pp.h7MVvpn Oy2wJBnovGxMecGiu_hzyYRsF1RlyOrdae.OVJ5s0NVdT3hRUeguy4NM- Received: from [209.119.38.67] by web181704.mail.ne1.yahoo.com via HTTP; Fri, 16 Nov 2012 11:50:21 PST X-Rocket-MIMEInfo: 001.001, SXMgdGhlcmUgYSBlcXVpdmFsZW50IG9mIExpbnV4ICJMZWFzZXMiIGZ1bmN0aW9uYWxpdHkgaW4gRnJlZUJTRCA_IElmIG5vdCwgYXJlIHRoZXJlIGFueSBwbGFucyBvZiBhZGRpbmcgaXQgaW4gdGhlIGZ1dHVyZSByZWxlYXNlPwoKVGhhbmtzLApTdXNoYW50aAEwAQEBAQ-- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.123.460 Message-ID: <1353095421.77036.YahooMailClassic@web181704.mail.ne1.yahoo.com> Date: Fri, 16 Nov 2012 11:50:21 -0800 (PST) From: Sushanth Rai Subject: Equivalent of linux F_SETLEASE/F_GETLEASE To: freebsd-hackers@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 19:50:22 -0000 Is there a equivalent of Linux "Leases" functionality in FreeBSD ? If not, are there any plans of adding it in the future release? Thanks, Sushanth From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 20:36:17 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B8BD1BF1 for ; Fri, 16 Nov 2012 20:36:17 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 873AC8FC13 for ; Fri, 16 Nov 2012 20:36:17 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so2331004pbc.13 for ; Fri, 16 Nov 2012 12:36:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=1GE5oOoZMxjcT5z93lOPhIS48BrZH/F7B/V6XmwjU+M=; b=me7mvzBciZI/WcOZmI/lV8EDpvjt77f7CVAwWD1bkvrUQtf9oEJfd8xWI8kQKygdiQ TOZfWl0mkEe98i6hkihJaWg//bNu4BXiPA6xqchxevrIWSxfmQgEvbd+DPzGn485vDuS o+IEQdQPwfCLzY5Y/3tVcS2O5Kr3AaxAJ2FyEbeb/7QMY0EntQ5hrGEz/qUV4ihjuGWS kwSUHMLkpXUvan/SRoDpsi+oCu2nqMYDH1LxTIgXhZWnAIVij6lUVqBA+gHHKQ1zWbyv YGqTofXYVxeJTNgWG0mqKjeFqhCfqaDbCG5TAypwsgu+X0pspDUVMdGfha5+xhGojSpJ J2vw== Received: by 10.68.254.8 with SMTP id ae8mr18610889pbd.46.1353098176776; Fri, 16 Nov 2012 12:36:16 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id sw1sm1713158pbc.75.2012.11.16.12.36.14 (version=SSLv3 cipher=OTHER); Fri, 16 Nov 2012 12:36:15 -0800 (PST) Message-ID: <50A6A3BD.5000901@gmail.com> Date: Fri, 16 Nov 2012 12:36:13 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121114 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: clang mangling some static struct names? Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 20:36:17 -0000 On a very recent clang-built HEAD, I see that some static structures have a ".n" appended to their name. For example, this declaration in the cxgbe driver now results in a t4_list.0 symbol in the KLD: static SLIST_HEAD(, adapter) t4_list; # nm if_cxgbe.ko | grep t4_list 0000000000000020 b t4_list.0 gcc used to leave it as t4_list. One problem is that kgdb can't display such an item (it interprets the dot as a delimiter between a structure and its element). Some of the structures listed at the end look strange for other reasons too -- for example, why should there be multiple scsi_low_statics.n symbols when there's only one such structure in scsi_low.c? Regards, Navdeep full list of affected structures (and some false positives?): # nm kernel *.ko | grep '\.[0-9]$' ffffffff814802d0 b accept_filtlsthd.0 ffffffff8125ca88 b acpi_intr_list.0 ffffffff81292278 b cdevsw_gt_post_list.0 ffffffff812defc8 b clock_adj.0 ffffffff812defd0 b clock_adj.1 ffffffff814d7ac0 b enumerators.0 ffffffff81292460 b eventtimers.0 ffffffff81279680 b feedertab.0 ffffffff81248470 d intr_cpus.0.0 ffffffff814a0378 b keyboard_drivers.0 ffffffff81481c60 b lltables.0 ffffffff814a17a8 b profperiod.1 ffffffff81482280 b route_cb.0 ffffffff81482284 b route_cb.1 ffffffff81482288 b route_cb.2 ffffffff8148228c b route_cb.3 ffffffff812796d0 b sndstat_devlist.0 ffffffff814a17a0 b statperiod.1 ffffffff812925a4 b tstate.0 ffffffff812925a8 b tstate.1 ffffffff8128ab30 b twe_check_bits.lastwarn.0 ffffffff8128ab38 b twe_check_bits.lastwarn.1 ffffffff814804d8 b unp_defers.0 ffffffff81488760 b vm_phys_lookup_lists.0 ffffffff813e7900 b w_hash.0 ffffffff813e80dc b w_hash.2 ffffffff813e58f0 b w_lohash.0 ffffffff813e78dc b w_lohash.2 0000000000000318 d proto_reg.0 000000000000031c d proto_reg.1 00000000000000c0 b fasttrap_procs.0 00000000000000c8 b fasttrap_procs.1 00000000000000d0 b fasttrap_procs.2 0000000000000080 b fasttrap_provs.0 0000000000000088 b fasttrap_provs.1 0000000000000090 b fasttrap_provs.2 0000000000000028 b t3_list.0 0000000000000050 b t3_uld_list.0 0000000000000020 b t4_list.0 0000000000000048 b t4_uld_list.0 0000000000000000 b efdev.0 0000000000000190 b Counter.0 0000000000000194 b Counter.1 0000000000000198 b Counter.2 000000000000019c b Counter.3 0000000000000028 b taphead.0 0000000000001190 b svc_rpc_gss_callbacks.0 0000000000001198 b svc_rpc_gss_svc_names.0 0000000000000038 b scsi_low_statics.0 000000000000003c b scsi_low_statics.1 0000000000000040 b scsi_low_statics.2 0000000000000044 b scsi_low_statics.3 0000000000000048 b scsi_low_statics.4 0000000000000008 b feedertab.0 0000000000000098 b sndstat_devlist.0 0000000000000008 b pcx_info.0 000000000000000c b pcx_info.1 0000000000000010 b pcx_info.2 0000000000000014 b pcx_info.3 0000000000000018 b pcx_info.4 000000000000001c b pcx_info.5 0000000000000020 b pcx_info.6 0000000000000028 b pcx_info.7 0000000000000000 b twe_check_bits.lastwarn.0 0000000000000008 b twe_check_bits.lastwarn.1 From owner-freebsd-hackers@FreeBSD.ORG Fri Nov 16 21:49:21 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ED69E8FC for ; Fri, 16 Nov 2012 21:49:20 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [178.238.39.38]) by mx1.freebsd.org (Postfix) with ESMTP id 71D658FC12 for ; Fri, 16 Nov 2012 21:49:20 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id 9D2F31CC5660; Fri, 16 Nov 2012 22:49:19 +0100 (CET) Date: Fri, 16 Nov 2012 22:49:19 +0100 From: Roman Divacky To: Navdeep Parhar Subject: Re: clang mangling some static struct names? Message-ID: <20121116214919.GA41725@freebsd.org> References: <50A6A3BD.5000901@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50A6A3BD.5000901@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 21:49:21 -0000 Yes, it does that. iirc so that you can have things like void foo(int cond) { if (cond) { static int i = 7; } else { static int i = 8; } } working correctly. I dont know why scsi_low_statics is there multiple times. On Fri, Nov 16, 2012 at 12:36:13PM -0800, Navdeep Parhar wrote: > On a very recent clang-built HEAD, I see that some static structures > have a ".n" appended to their name. For example, this declaration in > the cxgbe driver now results in a t4_list.0 symbol in the KLD: > > static SLIST_HEAD(, adapter) t4_list; > > # nm if_cxgbe.ko | grep t4_list > 0000000000000020 b t4_list.0 > > gcc used to leave it as t4_list. One problem is that kgdb can't display > such an item (it interprets the dot as a delimiter between a structure > and its element). Some of the structures listed at the end look strange > for other reasons too -- for example, why should there be multiple > scsi_low_statics.n symbols when there's only one such structure in > scsi_low.c? > > Regards, > Navdeep > > > full list of affected structures (and some false positives?): > # nm kernel *.ko | grep '\.[0-9]$' > ffffffff814802d0 b accept_filtlsthd.0 > ffffffff8125ca88 b acpi_intr_list.0 > ffffffff81292278 b cdevsw_gt_post_list.0 > ffffffff812defc8 b clock_adj.0 > ffffffff812defd0 b clock_adj.1 > ffffffff814d7ac0 b enumerators.0 > ffffffff81292460 b eventtimers.0 > ffffffff81279680 b feedertab.0 > ffffffff81248470 d intr_cpus.0.0 > ffffffff814a0378 b keyboard_drivers.0 > ffffffff81481c60 b lltables.0 > ffffffff814a17a8 b profperiod.1 > ffffffff81482280 b route_cb.0 > ffffffff81482284 b route_cb.1 > ffffffff81482288 b route_cb.2 > ffffffff8148228c b route_cb.3 > ffffffff812796d0 b sndstat_devlist.0 > ffffffff814a17a0 b statperiod.1 > ffffffff812925a4 b tstate.0 > ffffffff812925a8 b tstate.1 > ffffffff8128ab30 b twe_check_bits.lastwarn.0 > ffffffff8128ab38 b twe_check_bits.lastwarn.1 > ffffffff814804d8 b unp_defers.0 > ffffffff81488760 b vm_phys_lookup_lists.0 > ffffffff813e7900 b w_hash.0 > ffffffff813e80dc b w_hash.2 > ffffffff813e58f0 b w_lohash.0 > ffffffff813e78dc b w_lohash.2 > 0000000000000318 d proto_reg.0 > 000000000000031c d proto_reg.1 > 00000000000000c0 b fasttrap_procs.0 > 00000000000000c8 b fasttrap_procs.1 > 00000000000000d0 b fasttrap_procs.2 > 0000000000000080 b fasttrap_provs.0 > 0000000000000088 b fasttrap_provs.1 > 0000000000000090 b fasttrap_provs.2 > 0000000000000028 b t3_list.0 > 0000000000000050 b t3_uld_list.0 > 0000000000000020 b t4_list.0 > 0000000000000048 b t4_uld_list.0 > 0000000000000000 b efdev.0 > 0000000000000190 b Counter.0 > 0000000000000194 b Counter.1 > 0000000000000198 b Counter.2 > 000000000000019c b Counter.3 > 0000000000000028 b taphead.0 > 0000000000001190 b svc_rpc_gss_callbacks.0 > 0000000000001198 b svc_rpc_gss_svc_names.0 > 0000000000000038 b scsi_low_statics.0 > 000000000000003c b scsi_low_statics.1 > 0000000000000040 b scsi_low_statics.2 > 0000000000000044 b scsi_low_statics.3 > 0000000000000048 b scsi_low_statics.4 > 0000000000000008 b feedertab.0 > 0000000000000098 b sndstat_devlist.0 > 0000000000000008 b pcx_info.0 > 000000000000000c b pcx_info.1 > 0000000000000010 b pcx_info.2 > 0000000000000014 b pcx_info.3 > 0000000000000018 b pcx_info.4 > 000000000000001c b pcx_info.5 > 0000000000000020 b pcx_info.6 > 0000000000000028 b pcx_info.7 > 0000000000000000 b twe_check_bits.lastwarn.0 > 0000000000000008 b twe_check_bits.lastwarn.1 > _______________________________________________ > 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 Nov 16 22:04:18 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C73C2D3C; Fri, 16 Nov 2012 22:04:18 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 88D5A8FC0C; Fri, 16 Nov 2012 22:04:18 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id kp6so2297470pab.13 for ; Fri, 16 Nov 2012 14:04:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=gl0mnDsTONCdGDgTdmso0z18KRQaWeo176IfW6l3Bv8=; b=OvrQUCHlLkwi8Ozwa6P+ECC/fcWdALOJAs/T4fOugMDz2yuchKK4xm0MBLyoKZqgP+ MvI/DqA0FNBRRzgEeHvPV9G7aEPWl0xpqOrDnlflObImWEjn00xDSwA80OE9cr4v/Jaw ulm2DQl1I7pbp0UvZmP8xNCVoybCTXjw6SfmJBX0NuCcsCISqVwLxvPfCp7q1SSxFDMW na0sA20RgHOTh2pagIvqgn2hm8+6efuYg9VKD+kJLOzVGwXWq5iiGU4UwuL0C4h/w/0I t5g4JeP+RlXTlIBFDKMs/R0DTFPM4pzqtNZQ5jERYeb9tb6PwYIjL1CW+fnSovQV20gV UdmA== Received: by 10.68.234.36 with SMTP id ub4mr19240648pbc.68.1353103458286; Fri, 16 Nov 2012 14:04:18 -0800 (PST) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPS id c1sm1675670pav.23.2012.11.16.14.04.16 (version=SSLv3 cipher=OTHER); Fri, 16 Nov 2012 14:04:17 -0800 (PST) Message-ID: <50A6B85F.6090707@gmail.com> Date: Fri, 16 Nov 2012 14:04:15 -0800 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121114 Thunderbird/16.0.2 MIME-Version: 1.0 To: Roman Divacky Subject: Re: clang mangling some static struct names? References: <50A6A3BD.5000901@gmail.com> <20121116214919.GA41725@freebsd.org> In-Reply-To: <20121116214919.GA41725@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 22:04:19 -0000 On 11/16/12 13:49, Roman Divacky wrote: > Yes, it does that. iirc so that you can have things like > > void foo(int cond) { > if (cond) { > static int i = 7; > } else { > static int i = 8; > } > } > > working correctly. It's not appending the .n everywhere. And when it does, I don't see any potential collision that it prevented by doing so. Instead, it looks like the .n symbol corresponds to the nth element in the structure (so this is not name mangling in the true sense). I just don't see the point in doing things this way. It is only making things harder for debuggers. Regards, Navdeep > > I dont know why scsi_low_statics is there multiple times. > > On Fri, Nov 16, 2012 at 12:36:13PM -0800, Navdeep Parhar wrote: >> On a very recent clang-built HEAD, I see that some static structures >> have a ".n" appended to their name. For example, this declaration in >> the cxgbe driver now results in a t4_list.0 symbol in the KLD: >> >> static SLIST_HEAD(, adapter) t4_list; >> >> # nm if_cxgbe.ko | grep t4_list >> 0000000000000020 b t4_list.0 >> >> gcc used to leave it as t4_list. One problem is that kgdb can't display >> such an item (it interprets the dot as a delimiter between a structure >> and its element). Some of the structures listed at the end look strange >> for other reasons too -- for example, why should there be multiple >> scsi_low_statics.n symbols when there's only one such structure in >> scsi_low.c? >> >> Regards, >> Navdeep >> >> >> full list of affected structures (and some false positives?): >> # nm kernel *.ko | grep '\.[0-9]$' >> ffffffff814802d0 b accept_filtlsthd.0 >> ffffffff8125ca88 b acpi_intr_list.0 >> ffffffff81292278 b cdevsw_gt_post_list.0 >> ffffffff812defc8 b clock_adj.0 >> ffffffff812defd0 b clock_adj.1 >> ffffffff814d7ac0 b enumerators.0 >> ffffffff81292460 b eventtimers.0 >> ffffffff81279680 b feedertab.0 >> ffffffff81248470 d intr_cpus.0.0 >> ffffffff814a0378 b keyboard_drivers.0 >> ffffffff81481c60 b lltables.0 >> ffffffff814a17a8 b profperiod.1 >> ffffffff81482280 b route_cb.0 >> ffffffff81482284 b route_cb.1 >> ffffffff81482288 b route_cb.2 >> ffffffff8148228c b route_cb.3 >> ffffffff812796d0 b sndstat_devlist.0 >> ffffffff814a17a0 b statperiod.1 >> ffffffff812925a4 b tstate.0 >> ffffffff812925a8 b tstate.1 >> ffffffff8128ab30 b twe_check_bits.lastwarn.0 >> ffffffff8128ab38 b twe_check_bits.lastwarn.1 >> ffffffff814804d8 b unp_defers.0 >> ffffffff81488760 b vm_phys_lookup_lists.0 >> ffffffff813e7900 b w_hash.0 >> ffffffff813e80dc b w_hash.2 >> ffffffff813e58f0 b w_lohash.0 >> ffffffff813e78dc b w_lohash.2 >> 0000000000000318 d proto_reg.0 >> 000000000000031c d proto_reg.1 >> 00000000000000c0 b fasttrap_procs.0 >> 00000000000000c8 b fasttrap_procs.1 >> 00000000000000d0 b fasttrap_procs.2 >> 0000000000000080 b fasttrap_provs.0 >> 0000000000000088 b fasttrap_provs.1 >> 0000000000000090 b fasttrap_provs.2 >> 0000000000000028 b t3_list.0 >> 0000000000000050 b t3_uld_list.0 >> 0000000000000020 b t4_list.0 >> 0000000000000048 b t4_uld_list.0 >> 0000000000000000 b efdev.0 >> 0000000000000190 b Counter.0 >> 0000000000000194 b Counter.1 >> 0000000000000198 b Counter.2 >> 000000000000019c b Counter.3 >> 0000000000000028 b taphead.0 >> 0000000000001190 b svc_rpc_gss_callbacks.0 >> 0000000000001198 b svc_rpc_gss_svc_names.0 >> 0000000000000038 b scsi_low_statics.0 >> 000000000000003c b scsi_low_statics.1 >> 0000000000000040 b scsi_low_statics.2 >> 0000000000000044 b scsi_low_statics.3 >> 0000000000000048 b scsi_low_statics.4 >> 0000000000000008 b feedertab.0 >> 0000000000000098 b sndstat_devlist.0 >> 0000000000000008 b pcx_info.0 >> 000000000000000c b pcx_info.1 >> 0000000000000010 b pcx_info.2 >> 0000000000000014 b pcx_info.3 >> 0000000000000018 b pcx_info.4 >> 000000000000001c b pcx_info.5 >> 0000000000000020 b pcx_info.6 >> 0000000000000028 b pcx_info.7 >> 0000000000000000 b twe_check_bits.lastwarn.0 >> 0000000000000008 b twe_check_bits.lastwarn.1 >> _______________________________________________ >> 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 Nov 16 22:40:02 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7EE6269 for ; Fri, 16 Nov 2012 22:40:02 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 9180E8FC12 for ; Fri, 16 Nov 2012 22:40:02 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id qAGMe1T9078491; Fri, 16 Nov 2012 15:40:01 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id qAGMe1Fu078488; Fri, 16 Nov 2012 15:40:01 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 16 Nov 2012 15:40:01 -0700 (MST) From: Warren Block To: Mark Saad Subject: Re: Using PC-Sysinstall for automated network installs of FreeBSD In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 16 Nov 2012 15:40:01 -0700 (MST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 22:40:02 -0000 On Fri, 16 Nov 2012, Mark Saad wrote: > All > I wanted to share with you my method for network installs of FreeBSD > 9.1-RCn . This does not use PC-BSD just stock FreeBSD. This should > work on 9.0-RELEASE is known to work on 9.1-RC's and BETA. > > I decided to use pc-sysinstall in place of bsdinstall as pc-sysinstall > supported using a config file that could be passed to the installer > much like the old sysinstall way of doing things. This is really nice--thank you! From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 17 01:35:20 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FEBFD23 for ; Sat, 17 Nov 2012 01:35:20 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id F36048FC08 for ; Sat, 17 Nov 2012 01:35:19 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id qAH1ZHoJ001910; Fri, 16 Nov 2012 18:35:17 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id qAH1ZHex001907; Fri, 16 Nov 2012 18:35:17 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 16 Nov 2012 18:35:17 -0700 (MST) From: Warren Block To: Mark Saad Subject: Re: Using PC-Sysinstall for automated network installs of FreeBSD In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 16 Nov 2012 18:35:17 -0700 (MST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 01:35:20 -0000 On Fri, 16 Nov 2012, Mark Saad wrote: > Useful paths on /export, /export/install/freebsd/9.1/{i386,amd64} > this is the contents of the install media rsync'd to a local filesystem Do you have a way to choose either i386 or amd64 installs? > 5 I changed my rc.conf to start a simple shell script and not the > bsdinstall bits Maybe you mean "/etc/rc.local" there? > export TERM=vt220 > > echo "o PC-SYSINSTALL " > exec /conf/picker.sh Trying to start this from SYSLINUX almost works. My menu config just does menu label FreeBSD 9 Install pxe {serverip}:/usr/tftpboot/images/fbsd9ins/boot/pxeboot The kernel boots, it gets to Trying to mount root from nfs: []... NFS ROOT: {serverip}:/usr/tftpboot/images/fbsd9ins and then it stops and just sits. NFS mount of that directory works on another system. Anything obvious I should check? I know pxeboot needs to be recompiled for some things, but can't recall the details. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 17 01:44:37 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A9F2E30 for ; Sat, 17 Nov 2012 01:44:37 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id A66438FC08 for ; Sat, 17 Nov 2012 01:44:36 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id qAH1iavS002047; Fri, 16 Nov 2012 18:44:36 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id qAH1iaBu002044; Fri, 16 Nov 2012 18:44:36 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 16 Nov 2012 18:44:36 -0700 (MST) From: Warren Block To: Mark Saad Subject: Re: Using PC-Sysinstall for automated network installs of FreeBSD In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 16 Nov 2012 18:44:36 -0700 (MST) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 01:44:37 -0000 On Fri, 16 Nov 2012, Warren Block wrote: > Trying to start this from SYSLINUX almost works. My menu config just does Actually, it does work on a real machine. It stalls on a VirtualBox VM during or after the NFS root mount. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 17 03:51:13 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CD256CDC for ; Sat, 17 Nov 2012 03:51:13 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id 73B6A8FC14 for ; Sat, 17 Nov 2012 03:51:12 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id t11so5487761qaa.13 for ; Fri, 16 Nov 2012 19:51:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:references:from:content-type:x-mailer:in-reply-to :message-id:date:to:content-transfer-encoding:mime-version :x-gm-message-state; bh=VapV3yx5C9FVnRuzwNGfZ5hS1sTJ7XympyH6iOcZJ1Y=; b=EQn7MCy+FDxTbMjZxL+OGS9+CVu0iElDoq6NOn8CuuFBCyvyvGranH5No9QtxEIG1j 4DzG2XLWlajt68NfiFafsvmye8ob5t152FKQbJBA8yqVMyU7TPG5uDJzd6OYGXG5T5VK n7g7jAounBlx+PRv1Xw6615LvhOLXCBNdgQBxE9+txRtd1I5qngl5T4Jnab6UdqzmFcj wFUxuG3leJ1IZIUOulUoYiKI6+5lySKRKXwio+L20447X9imtx3Goy2QwRVr3bpxla2G vS45mf9GqoXv2Qkmvg93ljqTf73s1cV3THzu4dRf5+2yGC+1mfpwmX+cSSerDZIs3kA6 P3dQ== Received: by 10.224.17.68 with SMTP id r4mr6288833qaa.21.1353124270737; Fri, 16 Nov 2012 19:51:10 -0800 (PST) Received: from [192.168.11.110] (ool-4a58bea2.dyn.optonline.net. [74.88.190.162]) by mx.google.com with ESMTPS id em3sm2378560qab.12.2012.11.16.19.51.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Nov 2012 19:51:10 -0800 (PST) Subject: Re: Using PC-Sysinstall for automated network installs of FreeBSD References: From: Mark Saad Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9B206) In-Reply-To: Message-Id: <6AE3D893-A88C-47FA-9DEE-8C0837124481@longcount.org> Date: Fri, 16 Nov 2012 22:51:08 -0500 To: "freebsd-hackers@freebsd.org" Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQnHUz6VWhcZQQR69mpUKmTTWl9T2POo+ODxmuTepugn61TreRgGazSm4GLmGHeEmiBT6+4S X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 03:51:14 -0000 On Nov 16, 2012, at 8:44 PM, Warren Block wrote: > On Fri, 16 Nov 2012, Warren Block wrote: >=20 >> Trying to start this from SYSLINUX almost works. My menu config just doe= s >=20 > Actually, it does work on a real machine. It stalls on a VirtualBox VM du= ring or after the NFS root mount. Strange , I will test it on virtualbox when I get some time next week . I di= d a lot of the testing initially on VMware esxi 4.0 and I did not have any i= ssues related to VM stuff . What version of vbox did you use ? What network i= nterface choice did you use in vbox ?=20 --- Mark saad | mark.saad@longcount.org From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 17 04:23:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CCD22B4F for ; Sat, 17 Nov 2012 04:23:49 +0000 (UTC) (envelope-from nonesuch@longcount.org) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6D6EA8FC08 for ; Sat, 17 Nov 2012 04:23:49 +0000 (UTC) Received: by mail-qc0-f182.google.com with SMTP id k19so2820296qcs.13 for ; Fri, 16 Nov 2012 20:23:43 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:references:from:content-type:x-mailer:message-id:date:to :content-transfer-encoding:mime-version:x-gm-message-state; bh=okWZTTaB5ooUo8+G/PL1ZLgIyDUHPpKTNn+uLyMfiJE=; b=GmDrovszQMjfXprm3RkZ3RZKgZyjlpqt8McBJDjhNqMkRKreNtGNfFkT87NAlm+s2A XDGP2+HOxe2AMU42yA8gNPfxO62ZiTfZ78TsqqBk+NTYJ1qO7Xp0wx1Yen26UlLRPY1m C70ESfMtrFG/hVPokNIxnNAnaFTVvVwJL2MAUaQddwJxzz6TVE1Qw6wM/t/5UaSjrBIU 72L7bQyFjPhxKMmYxbxysLIrky0J1aRlhaBAoQv05g/sJ01w/jhBheeknk/6STIQNjaO 8knHTd26ZW7PA0VgU3qsRE3ivaKhWzGoq+LdUWppLcE6Wyg1ZOdCfUuz4fHO2NQWURw4 CjxQ== Received: by 10.224.42.136 with SMTP id s8mr6416090qae.82.1353126223605; Fri, 16 Nov 2012 20:23:43 -0800 (PST) Received: from [192.168.11.110] (ool-4a58bea2.dyn.optonline.net. [74.88.190.162]) by mx.google.com with ESMTPS id f12sm2016129qey.5.2012.11.16.20.23.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 16 Nov 2012 20:23:42 -0800 (PST) Subject: Fwd: Using PC-Sysinstall for automated network installs of FreeBSD References: <5A809BE8-B436-4C9C-8902-FA138EF709AF@longcount.org> From: Mark Saad Content-Type: text/plain; charset=us-ascii X-Mailer: iPhone Mail (9B206) Message-Id: Date: Fri, 16 Nov 2012 23:23:40 -0500 To: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) X-Gm-Message-State: ALoCoQn0Zg5OUvr+p5546slBdW/wOahL20BqBxynqol/enSunWh8dlccVhMLtvq4aGJy0PQsStHB X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 04:23:49 -0000 >=20 > On Nov 16, 2012, at 8:35 PM, Warren Block wrote: >=20 >> On Fri, 16 Nov 2012, Mark Saad wrote: >>=20 >>> Useful paths on /export, /export/install/freebsd/9.1/{i386,amd64} >>> this is the contents of the install media rsync'd to a local filesystem >>=20 >> Do you have a way to choose either i386 or amd64 installs? >=20 > For my setup no , I just manually change the symlinks .=20 >=20 >>=20 >>> 5 I changed my rc.conf to start a simple shell script and not the >>> bsdinstall bits >>=20 >> Maybe you mean "/etc/rc.local" there? >>=20 > Yes that was a typo rc.local=20 >=20 >>> export TERM=3Dvt220 >>>=20 >>> echo "o PC-SYSINSTALL " >>> exec /conf/picker.sh >>=20 >>=20 >> Trying to start this from SYSLINUX almost works. My menu config just doe= s >>=20 >> menu label FreeBSD 9 Install >> pxe {serverip}:/usr/tftpboot/images/fbsd9ins/boot/pxeboot >>=20 >> The kernel boots, it gets to >>=20 >> Trying to mount root from nfs: []... >> NFS ROOT: {serverip}:/usr/tftpboot/images/fbsd9ins >>=20 >> and then it stops and just sits. NFS mount of that directory works on an= other system. Anything obvious I should check? I know pxeboot needs to be r= ecompiled for some things, but can't recall the details. >=20 > Well I would check to see if your have a default loader build , if your l= oader was rebuilt with HAS_TFTPSUPPORT or something like that , it will not w= ork . =20 >=20 > What's in your exports file ? Also what's in your dhcpd config ?=20 >=20 > --- > Mark saad | mark.saad@longcount.org >=20 From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 17 05:19:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16340F40 for ; Sat, 17 Nov 2012 05:19:26 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id BDFEC8FC12 for ; Sat, 17 Nov 2012 05:19:25 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.5/8.14.5) with ESMTP id qAH5JOs9003130; Fri, 16 Nov 2012 22:19:24 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.5/8.14.5/Submit) with ESMTP id qAH5JNgu003127; Fri, 16 Nov 2012 22:19:23 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Fri, 16 Nov 2012 22:19:23 -0700 (MST) From: Warren Block To: Mark Saad Subject: Re: Using PC-Sysinstall for automated network installs of FreeBSD In-Reply-To: <6AE3D893-A88C-47FA-9DEE-8C0837124481@longcount.org> Message-ID: References: <6AE3D893-A88C-47FA-9DEE-8C0837124481@longcount.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Fri, 16 Nov 2012 22:19:24 -0700 (MST) Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 05:19:26 -0000 On Fri, 16 Nov 2012, Mark Saad wrote: > On Nov 16, 2012, at 8:44 PM, Warren Block wrote: > >> On Fri, 16 Nov 2012, Warren Block wrote: >> >>> Trying to start this from SYSLINUX almost works. My menu config just does >> >> Actually, it does work on a real machine. It stalls on a VirtualBox VM during or after the NFS root mount. > > Strange , I will test it on virtualbox when I get some time next week . I did a lot of the testing initially on VMware esxi 4.0 and I did not have any issues related to VM stuff . What version of vbox did you use ? What network interface choice did you use in vbox ? VirtualBox 4.1.22, FreeBSD 9-stable amd64 host. Only the "PCnet-FAST III (Am79C973)" can pxe-boot, and only in bridged mode. From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 17 06:41:34 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 79022845; Sat, 17 Nov 2012 06:41:34 +0000 (UTC) (envelope-from wkoszek@freebsd.czest.pl) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by mx1.freebsd.org (Postfix) with ESMTP id ECE108FC08; Sat, 17 Nov 2012 06:41:33 +0000 (UTC) Received: from freebsd.czest.pl (freebsd.czest.pl [212.87.224.105]) by freebsd.czest.pl (8.14.5/8.14.5) with ESMTP id qAH6Uku7043511; Sat, 17 Nov 2012 06:30:46 GMT (envelope-from wkoszek@freebsd.czest.pl) Received: (from wkoszek@localhost) by freebsd.czest.pl (8.14.5/8.14.5/Submit) id qAH6Ukrs043510; Sat, 17 Nov 2012 06:30:46 GMT (envelope-from wkoszek) Date: Sat, 17 Nov 2012 06:30:46 +0000 From: "Wojciech A. Koszek" To: freebsd-current@freebsd.org, freebsd-stable@freebsd.org, freebsd-hackers@freebsd.org Subject: [Not this year] Re: FreeBSD in Google Code-In 2012? You can help too! Message-ID: <20121117063046.GN59689@FreeBSD.org> References: <20121016101957.GB53800@FreeBSD.org> <20121102201318.GI59689@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline In-Reply-To: <20121102201318.GI59689@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (freebsd.czest.pl [212.87.224.105]); Sat, 17 Nov 2012 06:30:46 +0000 (UTC) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 06:41:34 -0000 On Fri, Nov 02, 2012 at 08:13:18PM +0000, Wojciech A. Koszek wrote: > On Tue, Oct 16, 2012 at 10:19:57AM +0000, Wojciech A. Koszek wrote: > > (cross-posted message; please keep discussion on freebsd-hackers@) > > > > Hello, > > > > Last year FreeBSD qualified for Google Code-In 2011 event--contest for > > youngest open-source hackers in 13-17yr age range: > > > > http://www.google-melange.com/gci/homepage/google/gci2012 > > > > It was successful. We gained one more FreeBSD developer thanks to that > > (Isabell Long) We're pondering participating in the contest this year as > > well. > > > > For now we only have 25 ideas. We need at least 100. > > > > I felt all members of the FreeBSD community should help, so please submit > > your own Google Code-In 2012 ideas here: > > > > http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 > > > > Examples of previously completed tasks: > > > > http://wiki.freebsd.org/GoogleCodeIn/2011Tasks > > > > Those of you who have Wiki access, please spent 2 more minutes and submit > > straight to Wiki: > > > > http://wiki.freebsd.org/GoogleCodeIn/2012Tasks > > > > I plan to send out next e-mail if there's any progress on this project. > > > > Help will be appreciated. > > Hello, > > This is last call for action. > > As for now, we won't qualify. I suggest doc@ and ports@ and www@ and src@ > teams to try to come up with some ideas and add them to Wiki. Most of the > ideas which we have so far are more GSOC-alike. > > Unless we have at least 80 tasks of the "easy"/"medium" type, we'll have to > postpone participating in Code-In for next year. > > Thanks, Hello, We didn't make it this year. I want to thank all the people who submitted (and keep submitting) ideas for our Google Code-In wiki page: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks In total I got 61 ideas over e-mail from the web form (lessons learnt: for GSOC, we should also have a web form) All of them should be on the Wiki now. I suggest we keep collecting good ideas and try to make sure this years GSOC will be successful. On the other note--NetBSD guys are in Google Code-In.. Thanks, -- Wojciech A. Koszek wkoszek@FreeBSD.czest.pl http://FreeBSD.czest.pl/~wkoszek/ From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 17 13:01:06 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 56B7CAB6 for ; Sat, 17 Nov 2012 13:01:06 +0000 (UTC) (envelope-from se@freebsd.org) Received: from nm8.bullet.mail.ird.yahoo.com (nm8.bullet.mail.ird.yahoo.com [77.238.189.23]) by mx1.freebsd.org (Postfix) with ESMTP id 9DB008FC0C for ; Sat, 17 Nov 2012 13:01:05 +0000 (UTC) Received: from [77.238.189.50] by nm8.bullet.mail.ird.yahoo.com with NNFMP; 17 Nov 2012 13:00:59 -0000 Received: from [217.146.188.63] by tm3.bullet.mail.ird.yahoo.com with NNFMP; 17 Nov 2012 13:00:59 -0000 Received: from [127.0.0.1] by smtp105.mail.ird.yahoo.com with NNFMP; 17 Nov 2012 13:00:59 -0000 X-Yahoo-Newman-Id: 690239.93634.bm@smtp105.mail.ird.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: xsUEY_MVM1m43ZWHWEijS2aSoOY5qCMy9TgVfEHo8nehCiJ JCQfVxKwrKkwfBdoXYa6DdEuDgraFFau5C2Hf7HfWQqGlhwggktM_A_Nfkbi ado0B7E9ZBvOHHC19tw9y11zjBn2Jfq2GZyu0wSAeJPn.1nVs_4bDrRSEoXL q5OnpxI0DFcilt_Kc2aPk53ZlY80aZRYtRDG7vUAPDtJepXRVsj_im4ELlD9 DkaMen8mTiH.Kf1ScXY4CLIZ3o6tyPXL8Wf2uYUlfwaL.f_xU_2EZSRy0ivm G4GZO.biAVM5obysi7wztXbawUt39CSwr59iO8F3aSRCU79U00dNxxqdUkOa m3dnVMB1kRpxJMPfw1Sg6dZawhyRAOzpKyF3qqD6vsn8X4b8Bq2ZrKFEBzZK XBMUo4vUft7ejc5Chax_vtwiqYvxJU6pc0wSk0b9YK7xQ X-Yahoo-SMTP: iDf2N9.swBDAhYEh7VHfpgq0lnq. Received: from [192.168.119.18] (se@87.153.48.185 with plain) by smtp105.mail.ird.yahoo.com with SMTP; 17 Nov 2012 05:00:59 -0800 PST Message-ID: <50A78A84.5030408@freebsd.org> Date: Sat, 17 Nov 2012 14:00:52 +0100 From: Stefan Esser User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: CVS commit logs removed by CVS update X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 13:01:06 -0000 To my big surprise I found that "cvs update" removed all the CVS logs from "/usr/cvs/CVSROOT-*/commitlogs/*" (collection cvsroot-all). While I do use SVN to keep source and ports updated on my system, I was used to scan the CVS log files for commit messages of interest, to locate commit messages where I did not remember the affected files, and to have much faster access to recent commit messages than via "svn log" (or when off-line ...). Now I'd like to know, whether the log files have been removed as a side effect of cleaning up after the security incident, or whether they were deemed unnecessary remains from ancient CVS times? Best regards, STefan PS: I do have backups of the log files, but I'm really annoyed by these files being deleted on my system when I wanted to check for new information that might have been added to them ... From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 17 20:42:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D7EAD5A4; Sat, 17 Nov 2012 20:42:14 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from fsm2.ukr.net (fsm2.ukr.net [195.214.192.121]) by mx1.freebsd.org (Postfix) with ESMTP id 64F188FC14; Sat, 17 Nov 2012 20:42:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=fsm; h=Content-Transfer-Encoding:Content-Type:Mime-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=KkVc4Kfh0xFnqQkT+o5OWwY4+X3OcSmK7ZyH2sXT6s0=; b=Ye1wH+yTCZdZfb3s8jgwrkOGF/I+hXNiD2eA1IiusepDJ9zqGUKVnR5njMVhKSggARZ8mLbUrnc03mIPVeJW5JmJ46NxCYgzGfem1a/XGLoS4mQNHM8SO7G+Igzsir2C9A8SE+iZnhJ+mwuMFmaOxB7QlO/ss4/fCEPsJl4CSzI=; Received: from [178.137.138.140] (helo=nonamehost) by fsm2.ukr.net with esmtpsa ID 1TZojz-000FQR-Sl ; Sat, 17 Nov 2012 22:11:48 +0200 Date: Sat, 17 Nov 2012 22:11:43 +0200 From: Ivan Klymenko To: grarpamp Subject: Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident] Message-ID: <20121117221143.41c29ba2@nonamehost> In-Reply-To: References: X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAFVBMVEWpqak/Pz/i4uIfHx8GBwZwcHAQEBA6o92AAAACHElEQVQ4jWWUTY7bMAyF6QzUPSEoa8PFHEBgqwuM4bVVg7MvZOj+R+ijpMTpjIwgkT7z75EKrdfattpXERG6zqvUOtAr2LCRYfEKcB4l/Q+2cc6XjQH7hv+2YZYreIk5nevZEPvuzUzptizHLzgDMnC5Wpbl7ewJlOEqlQF+DlCjgVLki0WV6FMDMsBxjlJiQulIznwZ+DxHiQyDyIg0wN3Oo6o6ZQ5s5AIfar+W2Wlmz+kCcb8tg6j3voMEwNrBQk69dDBDqw/urpqJH+m+Q6u/4QnoAeYpnUXC/s1iup9rhCd6xMgAqdDyAyFegbKkVAHeLCcOulPLawaoUIDos4M88iLNrVkU7uu5ccTDO6naJzWLum51C6Yb7y4HKKbdArLWir0PBiS8glJRBZHeyHl7J9lENpAC6qT9NlNG4u5hsVYDyJP6mlJJtY3oVju4WSUzHal1sDU17NASoBWSk40J2eBLBJhYrVmzC5gVALGpNIAiQgN6eGstOp9Oa6zFbbLTISYi28BGZDRUJKWeroECkCEkzXjUtbmmaKMfAx2RfbT69/cO+tgHcmx6AfyZOmj3NDIah0F0GB66d4CrdIoplNFFGHSpSheRxbo0W4S8azNItEoMWbw3uXAeJgCrmX5joz7CGXqSg6PcryEhnFr/C1C2ntPxBOYbdwY+8dO3+wZJyFlbMX9s8zNnvp/tLwAv03NB4j3HVpn8Awwm+GrlP6MVAAAAAElFTkSuQmCC Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-hubs@freebsd.org, freebsd-questions@freebsd.org, freebsd-security@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 20:42:15 -0000 =D0=92 Sat, 17 Nov 2012 15:00:06 -0500 grarpamp =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > http://www.freebsd.org/news/2012-compromise.html > http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-se= curity-breach-via-stolen-ssh-key >=20 > This is not about this incident, but about why major opensource > projects need to be using a repository that has traceable, verifiable, > built-in cryptographic authentication. >=20 > Any of hundreds of committer and admin accounts could be compromised > with the attacker silently editing the repo. The same applies to > any of those accounts going rogue. Backtrack diffing from a breach > to 'see what changed' is not the ideal option. You really need to > be using a strong repo so that any attack on it is null from the > start. Another problem is bit rot wherever it may occur... disk, > hardware, the wire, EMP and other systems. >=20 > As it is now, we have no way to verify that what we get on pressed > CD's, ISO's, FTP sites, torrents, etc is strongly linked back to > the original repo. Signing over a hash of the ISO is *not* the same > as including the strong repo hash (commit) that was used to build > the release and then signing over that and the ISO. We can't know > that our local repository updates match the master. ports.tar.gz > has no authentication either. Nor does anything in the entire project > that originates from the current SVN/CVS repo... webpages, docs, > tools, source tarballs, etc. The FTP packages aren't signed, and > there are weak MD5's used in various parts of the install/package > tools, mirrors, etc. We can't trade hashes amongst people. It's all > just a bunch of random bits that someone may or may not have signed > over. And even if signed they still wouldn't be strongly linked > back to the master repo. Having such a disconnect at the root of > everything you do is simply not good practice these days. >=20 > And these days, Git is what people and projects are moving to, and > its rate of adoption and prevalence have essentially won out over > all the rest in the new 'revision control 2.0 world'. And knowing > Git is now more or less essential if you want to participate in a > wide variety of community development, ref: github, etc. >=20 > The FreeBSD project needs to be providing both itself, and its users > and benefactors with verifiable assurance that its repository, and > any copies and derived products, are authentic and intact. >=20 > Don't argue against such a repository feature, or the cost to move, > or bury your head in the sand by saying it could never happen to us... >=20 > Take this as a real opportunity to lead amongst the major opensource > projects like Linux, and among the BSD's (like DragonFly has), and > move to Git. >=20 > Once the root is fixed, you can push out secure distribution and > update models from there. It all starts at the root and can't be > done without it. >=20 > https://www.kernel.org/pub/software/scm/git/docs/git-fsck.html > Verifies the connectivity and validity of the objects in the database >=20 > http://git-scm.com/about/info-assurance > The data model that Git uses ensures the cryptographic integrity > of every bit of your project. Every file and commit is checksummed > and retrieved by its checksum when checked back out. It's impossible > to get anything out of Git other than the exact bits you put in. > It is also impossible to change any file, date, commit message, > or any other data in a Git repository without changing the IDs of > everything after it. This means that if you have a commit ID, you > can be assured not only that your project is exactly the same as > when it was committed, but that nothing in its history was changed. >=20 > https://en.wikipedia.org/wiki/Git_(software) > The Git history is stored in such a way that the id of a particular > revision (a "commit" in Git terms) depends upon the complete > development history leading up to that commit. Once it is published, > it is not possible to change the old versions without it being > noticed. The structure is similar to a hash tree, but with additional > data at the nodes as well as the leaves. >=20 > Some references... > http://git-scm.com/ > https://github.com/ > http://gitweb.dragonflybsd.org/dragonfly.git > https://git.kernel.org/?p=3Dlinux/kernel/git/stable/linux-stable.git LOL And how will this help Linux? http://lwn.net/Articles/457142/ From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 17 20:59:47 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 477FFBCB; Sat, 17 Nov 2012 20:59:47 +0000 (UTC) (envelope-from gmx@ross.cx) Received: from www81.your-server.de (www81.your-server.de [213.133.104.81]) by mx1.freebsd.org (Postfix) with ESMTP id EC68E8FC08; Sat, 17 Nov 2012 20:59:46 +0000 (UTC) Received: from [92.76.78.204] (helo=michael-think) by www81.your-server.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.74) (envelope-from ) id 1TZpUI-0001f1-Of; Sat, 17 Nov 2012 21:59:38 +0100 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: grarpamp , "Ivan Klymenko" Subject: Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident] References: <20121117221143.41c29ba2@nonamehost> Date: Sat, 17 Nov 2012 21:59:28 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Michael Ross" Message-ID: In-Reply-To: <20121117221143.41c29ba2@nonamehost> User-Agent: Opera Mail/12.10 (Win32) X-Authenticated-Sender: gmx@ross.cx X-Virus-Scanned: Clear (ClamAV 0.97.5/15583/Thu Nov 15 22:54:47 2012) Cc: freebsd-hackers@freebsd.org, freebsd-hubs@freebsd.org, freebsd-questions@freebsd.org, freebsd-security@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 20:59:47 -0000 On Sat, 17 Nov 2012 21:11:43 +0100, Ivan Klymenko wrote:= > =D0=92 Sat, 17 Nov 2012 15:00:06 -0500 > grarpamp =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > >> http://www.freebsd.org/news/2012-compromise.html >> http://it.slashdot.org/story/12/11/17/143219/freebsd-project-disclose= s-security-breach-via-stolen-ssh-key >> >> This is not about this incident, but about why major opensource >> projects need to be using a repository that has traceable, verifiable= , >> built-in cryptographic authentication. >> > LOL And how will this help Linux? > http://lwn.net/Articles/457142/ In the first comment on the article you link to, you find this: http://www.linux.com/news/featured-blogs/171-jonathan-corbet/491001-the-= cracking-of-kernelorg where the OPs view is susbstantiated. > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to = > "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 17 21:48:14 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F530833; Sat, 17 Nov 2012 21:48:14 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9A2A58FC13; Sat, 17 Nov 2012 21:48:13 +0000 (UTC) Received: by mail-bk0-f54.google.com with SMTP id je9so746518bkc.13 for ; Sat, 17 Nov 2012 13:48:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zVm6H1t6+8pxu6Rn839ytG3Zuz6aGPPx7U0hDdKh1L8=; b=MEIITNZTx9aiexLQ4ng+Kg0bVo+CBtW+dyZfHsRcqpwa603nJeifjbhlS2drIjqmLi lmj4HClW1NRj8ho0nZhW9NI/NJvsJB0+s8F5e0jhtTd03lQ7HSfadxglTJLf4QZq4MB9 t7kx+0Tu5khdzfoBYNaGzz5cayJ5yEFVlbkFfAa3KRAtaW8uVPsCEWN7mW8mZi+ATFAW mX46qmoQ8cfwPiqrrBgZ8c/BTuENZTuL/bT7vlluIIhhqnKbxrP+TrIL5BnjVsmBr5YO KNcqn41BzS4ULkQApvjNEYs59qdUWs18/RV8H+s9eRTQtRaVQp/m7UfkuLiEzJB50Kil 3jTA== MIME-Version: 1.0 Received: by 10.204.147.212 with SMTP id m20mr3357386bkv.103.1353188891384; Sat, 17 Nov 2012 13:48:11 -0800 (PST) Received: by 10.204.50.197 with HTTP; Sat, 17 Nov 2012 13:48:11 -0800 (PST) Received: by 10.204.50.197 with HTTP; Sat, 17 Nov 2012 13:48:11 -0800 (PST) In-Reply-To: References: <20121117221143.41c29ba2@nonamehost> Date: Sat, 17 Nov 2012 21:48:11 +0000 Message-ID: Subject: Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident] From: Chris Rees To: Michael Ross Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Ivan Klymenko , freebsd-hackers@freebsd.org, freebsd-hubs@freebsd.org, freebsd-questions@freebsd.org, freebsd-security@freebsd.org, grarpamp X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 21:48:15 -0000 On 17 Nov 2012 21:00, "Michael Ross" wrote: > > On Sat, 17 Nov 2012 21:11:43 +0100, Ivan Klymenko wrote: > >> =D0=92 Sat, 17 Nov 2012 15:00:06 -0500 >> grarpamp =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> >>> http://www.freebsd.org/news/2012-compromise.html >>> http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-secu= rity-breach-via-stolen-ssh-key >>> >>> This is not about this incident, but about why major opensource >>> projects need to be using a repository that has traceable, verifiable, >>> built-in cryptographic authentication. >>> > >> LOL And how will this help Linux? >> http://lwn.net/Articles/457142/ > > > In the first comment on the article you link to, you find this: > > http://www.linux.com/news/featured-blogs/171-jonathan-corbet/491001-the-cra= cking-of-kernelorg > > where the OPs view is susbstantiated. Yes, but git doesn't work with our workflow. It's been discussed several times, and changing to a tool that doesn't work for us (and is GPL btw) is no good at all. Chris From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 17 22:32:49 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 465797B9; Sat, 17 Nov 2012 22:32:49 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 534648FC08; Sat, 17 Nov 2012 22:32:48 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so1015089lbb.13 for ; Sat, 17 Nov 2012 14:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=1U7bqcNKpRacRZNLh2nUOIrmeOQ4DEB+vByKc0f41Do=; b=DKFPjdAhc1Ft9KJIe/LyXjAciPcSLu2VAu84KJAaytQyEmQPPajagbr3LyU1/xE2kd TReXE5FZhPfDJDGjdX1ujaNLagYPjdBNOmVb9UGLh6F5QL36Vdhhmn5lCaOUII5/5PDv qdNg2tDXSbu+/+H4Yv6/C7A6eLGSBZynPCirOIe0cDniBDVQyqoRCo5tO/TCU8WdZsDR 2nxHW7/pKXjxHgl45Bq7Cp8V5km/eH6n5RfNANcWNHvIFmNgIz5C/eiC3SEhsQJHjD83 OiO5aBch75wVGH3BLM2SWfk2WaefF6C6zuJUwWHINk5PmIsdhZS3cHRaK/eDcnRhBj4r JmmA== MIME-Version: 1.0 Received: by 10.112.30.195 with SMTP id u3mr3328589lbh.37.1353191567036; Sat, 17 Nov 2012 14:32:47 -0800 (PST) Received: by 10.112.49.138 with HTTP; Sat, 17 Nov 2012 14:32:46 -0800 (PST) Date: Sat, 17 Nov 2012 17:32:46 -0500 Message-ID: Subject: Jumbo Packet fail. From: Zaphod Beeblebrox To: freebsd-hackers@freebsd.org, freebsd-fs , FreeBSD Mailing Lists Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Nov 2012 22:32:49 -0000 I recently started using an iSCSI disk on my ZFS array seriously from a windows 7 host on the network. The performance is acceptable, but I was led to believe that using Jumbo packets is a win here. My win7 motherboard adapter did not support jumbo frames, so I got one that did... configured it, etc. Just in case anyone cares, the motherboard had an 82567V-2 (does not support jumbo frames) and I added in an intel 82574L based card. Similarly, I configured em0 on my FreeBSD host to have an MTU of 9014 bytes (I also tried 9000). The hardware on the FreeBSD 9.1RC2 side is: em0: port 0xdc00-0xdc1f mem 0xfcfe0000-0xfcffffff,0xfcfc0000-0xfcfdffff irq 16 at device 0.0 on pci3 pciconf -lv identifies the chipset as 82572EI Now... my problem is that the windows machine correctly advertises an MSS of 8960 bytes in it's SYN packet while FreeBSD advertises 1460 in the syn-ack. [1:42:342]root@vr:/usr/local/etc/istgt> ifconfig em0 em0: flags=8843 metric 0 mtu 9014 options=4019b ether 00:15:17:0d:04:a8 inet 66.96.20.52 netmask 0xffffffe0 broadcast 66.96.20.63 inet6 fe80::215:17ff:fe0d:4a8%em0 prefixlen 64 scopeid 0x5 inet6 2001:1928:1::52 prefixlen 64 inet 192.168.221.2 netmask 0xffffff00 broadcast 192.168.221.255 nd6 options=21 media: Ethernet autoselect (1000baseT ) status: active I have tested this with both ipv4 and ipv6 connections between the win7 host and the FreeBSD server. win7 always requests the larger mss, and FreeBSD the smaller.