From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 01:39:38 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2B3C6C8; Sun, 7 Jun 2015 01:39:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ACE92182D; Sun, 7 Jun 2015 01:39:37 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by wgme6 with SMTP id e6so79328901wgm.2; Sat, 06 Jun 2015 18:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=KRjVQh4jIuZpxziV/mYVyC5udTp3d7Xp/x59TzSB4AE=; b=YaR0J7OJftBNaJFDeDr/GP+XsvQIF2QmNfLOUItUmrdZWM1a0XDUH4jnRVkTlxA+9q JRmC2pAhQH7OEC71LmP0wS0n5EL+JHz41c/X0ZTEaW1IUOC5A4hy9ZXStbe+Cvc3MK5k fmv1ycMnTfkltCHURNEViwjUg9WOiofWhjvQ9xNYG5GuJpnuk9iO/Jta203MWqoOEubU Ovf6wDDVtbka2HIpRw8k+77XBEMOwajVBqh9LqwH/ZbBWtCn2v3/hTFyLAxK62lLXjme uHhdQCecgn/y+0RoCUyxsflP7v3a6ZFjq2UgFlLrhGyGEq2Osnkl8v23HcjO8Rj7n+as h8KQ== X-Received: by 10.195.13.1 with SMTP id eu1mr19405799wjd.131.1433641174551; Sat, 06 Jun 2015 18:39:34 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id u7sm4758833wif.3.2015.06.06.18.39.32 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 06 Jun 2015 18:39:32 -0700 (PDT) Date: Sun, 7 Jun 2015 03:39:30 +0200 From: Mateusz Guzik To: kikuchan Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [patch] separate SysV IPC namespace for jail Message-ID: <20150607013929.GA9182@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 01:39:38 -0000 On Sun, Jun 07, 2015 at 12:04:17AM +0900, kikuchan wrote: > Sorry for cross-post to freebsd-stable, but I want to get more > feedback for my patch. > (The patch is; http://lists.freebsd.org/pipermail/freebsd-jail/attachments/20150606/7736309b/attachment.bin) > > > I believe this patch FIXES current SysV IPC for jail WITHOUT changing > current kernel architecture. > (so I hope it will be merged into stable/10) > > Let me explain what happens currently, with and without my patch, > since it's little confusing. > > > I use SysV IPC shared memory (SYSVSHM) as an example here, because > it's easy to understand. > Remember shmget / shmat / shmdt / shmctl, are syscalls of SYSVSHM. > > All normal processes have its own virtual memory space, it is done by kernel. > A backend component of virtual memory is a page, is on real memory or > on swap devices. > > SYSVSHM provides a way to share memory segments on the page between > processes on userland. > A process can load the page into its own virtual memory space with > shmat syscall. > Once the page is loaded into the virtual memory space, the page is > accessible until further shmdt syscall or exit of process. > > Another process can obtain the exact same page, by calling shmat syscall. > So, permission of shmat syscall is very important. > > > > Address space can be shared between multiple jails > This was a typo. Let me quote fixed version: "Address space can be shared between multiple PROCESSES, what happens if such a pair ends up in different jails? Preferably such a scenario would be prohibited to avoid future accidents." However, sysvipc namespace sharing is an ok feature esp. with multi-level jails. In the simplest scenario upon jail creation you decide whether it gets its own namespace or inherits it. > > What about existing sysvshm mappings when jailing? > > Real (not jailed) environment is treated as a jail with jid=0 in kernel. > If you create sysvshm memory segment before entering a jail, the > segment simply owned by jid=0. > The point is you get a process with sysvshm segments from 2 different jails. Looks like solid trouble protential. > > > Extending struct prison with relevant pointers and updating the code to > > You don't need to extend the struct to separate IPC namespaces. > The word "namespaces" means a key (key_t) of IPC syscall, here. > > Whether the struct should be extended or not, depends on how we want > to control IPC resources for each jail. > If you want to control SysV IPC resources by changing sysctl > parameters from inside of jail for each jail, > then it might be yes. > But I think per-jail resource control should be done with RACCT, and > it might be applied to my implementation too. > > > The one missing feature is how to export information to userland. > This should be discuss separately, even if my patch is rejected. > (If visibility control is needed for ipcs, maybe it should use similar > technique to ps or netstat?) > > > Conclusion; > I think my patch is better than broken. (SysV IPC + jail is buggy over > 10 years!) > The feature in question is definitely desirable, but your patch is hack, with the "hack" part visible to userspace. As mentioned earlier there are some things to do before any kind of jail-aware ipcs land in the tree. As a minimum this is singlethreading when jailing, prevention of jailing processes with shared virtual address spaces and ones with existing sysvshm mappings. All this is to reduce amount of bugs one would have to deal with. After the work is completed there is no problem whatsoever with providing per-jail sysvipcs. This avoids information leaks (no id list to look at) and conflicts. Exporting is not a problem either - a dedicated sysctl grabs JID and dumps its ipcs. It also gets a 'recursive' flag to know whether ipcs for its own jails should be dumped as well (if different). -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 07:43:21 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3F1A5E6; Sun, 7 Jun 2015 07:43:21 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from smtp01.cm.dti.ne.jp (smtp.ipv6.cm.dream.jp [IPv6:2001:2e8:702::236:70:47]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8995A1B88; Sun, 7 Jun 2015 07:43:21 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by smtp01.cm.dti.ne.jp (3.11s) with ESMTP AUTH id t577hHVg015639; Sun, 7 Jun 2015 16:43:17 +0900 (JST) Received: by ykfl8 with SMTP id l8so40446140ykf.1; Sun, 07 Jun 2015 00:43:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.113.132 with SMTP id m126mr9933741ywc.12.1433662996511; Sun, 07 Jun 2015 00:43:16 -0700 (PDT) Received: by 10.13.227.196 with HTTP; Sun, 7 Jun 2015 00:43:16 -0700 (PDT) In-Reply-To: <20150607013929.GA9182@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> <20150607013929.GA9182@dft-labs.eu> Date: Sun, 7 Jun 2015 16:43:16 +0900 Message-ID: Subject: Re: [patch] separate SysV IPC namespace for jail From: kikuchan To: Mateusz Guzik Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 07:43:21 -0000 Hi Mateusz, Thanks for your reply! First of all, I intend to *jail* SysV IPC user completely. (unless user really want to interact with each other between jails) I think SysV IPC is simple but obsolete, so you can design whatever you want for jail system. Also, I want keep everything simple. My design (to be sure): - Each entry of the list (shown in ipcs) belongs to a jail. - Any operation to SHM/SEM/MSG attempted from another jail, will just fail with EACCES. > "Address space can be shared between multiple PROCESSES, what happens if > such a pair ends up in different jails? Preferably such a scenario would > be prohibited to avoid future accidents." > > However, sysvipc namespace sharing is an ok feature esp. with > multi-level jails. In the simplest scenario upon jail creation you > decide whether it gets its own namespace or inherits it. > > > > What about existing sysvshm mappings when jailing? > > > > Real (not jailed) environment is treated as a jail with jid=0 in kernel. > > If you create sysvshm memory segment before entering a jail, the > > segment simply owned by jid=0. > > > > The point is you get a process with sysvshm segments from 2 different > jails. Looks like solid trouble protential. Ok, I think I've got what you'd concerned. In my design, setting up such processes would be difficult. This wouldn't be happend normally, because shared memory segments should be obtained BEFORE entering a jail; 1. Create a segment on jid=0 with shmget() 2. shmat() to attach (get void *ptr) 3. fork() 4. A child process entering to jid=1 with jail_attach() 5. The child process and the parent process can share the address space (via *ptr). 6. If the child process do shmat() on the same ID again, it simply failed with EACCES. It means, there is NO way to obtain a segment created in other jail AFTER jailed (even if you're root or obtaining the segment created on jid=0). This looks like file descriptors. It's also a fool-proof design, because most applications don't use FreeBSD's unique and special jail system directly. At this point, the patch breaks backward-compatibility, so we might need an option in kernel configuration. It's enough by configuration, because I think the current FreeBSD's SysV IPC behavior of jail is a BUG, not a feature. # Who using jail wants this dangerous behavior?! > The feature in question is definitely desirable, but your patch is hack, > with the "hack" part visible to userspace. > As mentioned earlier there are some things to do before any kind of > jail-aware ipcs land in the tree. Thanks. These should be solved. > As a minimum this is singlethreading > when jailing, prevention of jailing processes with shared virtual address > spaces and ones with existing sysvshm mappings. All this is to reduce > amount of bugs one would have to deal with. Virtual memory allocation and related stuff are protected and done by kernel already, because it's an IPC (Inter Process Communication). Moreover, you cannot change an owner of the IPC entry after creation, so we don't need an additional protection in kernel. Regards, Kikuchan On Sun, Jun 7, 2015 at 10:39 AM, Mateusz Guzik wrote: > On Sun, Jun 07, 2015 at 12:04:17AM +0900, kikuchan wrote: >> Sorry for cross-post to freebsd-stable, but I want to get more >> feedback for my patch. >> (The patch is; http://lists.freebsd.org/pipermail/freebsd-jail/attachments/20150606/7736309b/attachment.bin) >> >> >> I believe this patch FIXES current SysV IPC for jail WITHOUT changing >> current kernel architecture. >> (so I hope it will be merged into stable/10) >> >> Let me explain what happens currently, with and without my patch, >> since it's little confusing. >> >> >> I use SysV IPC shared memory (SYSVSHM) as an example here, because >> it's easy to understand. >> Remember shmget / shmat / shmdt / shmctl, are syscalls of SYSVSHM. >> >> All normal processes have its own virtual memory space, it is done by kernel. >> A backend component of virtual memory is a page, is on real memory or >> on swap devices. >> >> SYSVSHM provides a way to share memory segments on the page between >> processes on userland. >> A process can load the page into its own virtual memory space with >> shmat syscall. >> Once the page is loaded into the virtual memory space, the page is >> accessible until further shmdt syscall or exit of process. >> >> Another process can obtain the exact same page, by calling shmat syscall. >> So, permission of shmat syscall is very important. >> >> >> > Address space can be shared between multiple jails >> > > This was a typo. Let me quote fixed version: > > "Address space can be shared between multiple PROCESSES, what happens if > such a pair ends up in different jails? Preferably such a scenario would > be prohibited to avoid future accidents." > > However, sysvipc namespace sharing is an ok feature esp. with > multi-level jails. In the simplest scenario upon jail creation you > decide whether it gets its own namespace or inherits it. > >> > What about existing sysvshm mappings when jailing? >> >> Real (not jailed) environment is treated as a jail with jid=0 in kernel. >> If you create sysvshm memory segment before entering a jail, the >> segment simply owned by jid=0. >> > > The point is you get a process with sysvshm segments from 2 different > jails. Looks like solid trouble protential. > >> >> > Extending struct prison with relevant pointers and updating the code to >> >> You don't need to extend the struct to separate IPC namespaces. >> The word "namespaces" means a key (key_t) of IPC syscall, here. >> >> Whether the struct should be extended or not, depends on how we want >> to control IPC resources for each jail. >> If you want to control SysV IPC resources by changing sysctl >> parameters from inside of jail for each jail, >> then it might be yes. >> But I think per-jail resource control should be done with RACCT, and >> it might be applied to my implementation too. >> >> >> The one missing feature is how to export information to userland. >> This should be discuss separately, even if my patch is rejected. >> (If visibility control is needed for ipcs, maybe it should use similar >> technique to ps or netstat?) >> >> >> Conclusion; >> I think my patch is better than broken. (SysV IPC + jail is buggy over >> 10 years!) >> > > The feature in question is definitely desirable, but your patch is hack, > with the "hack" part visible to userspace. > > As mentioned earlier there are some things to do before any kind of > jail-aware ipcs land in the tree. As a minimum this is singlethreading > when jailing, prevention of jailing processes with shared virtual address > spaces and ones with existing sysvshm mappings. All this is to reduce > amount of bugs one would have to deal with. > > After the work is completed there is no problem whatsoever with > providing per-jail sysvipcs. This avoids information leaks (no id list > to look at) and conflicts. > > Exporting is not a problem either - a dedicated sysctl grabs JID and > dumps its ipcs. It also gets a 'recursive' flag to know whether ipcs > for its own jails should be dumped as well (if different). > > -- > Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 08:37:40 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6BC7B0E; Sun, 7 Jun 2015 08:37:40 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5B8B816ED; Sun, 7 Jun 2015 08:37:40 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by wiwd19 with SMTP id d19so56885546wiw.0; Sun, 07 Jun 2015 01:37:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QB0merXAn2Dx6KcaOqabWMD9r1JS4bxd/YvsvFw7UJ8=; b=F1BZ/+rIXdL5j2hYBg9anIZEi2mwsoAawxYAsMWIx2hHP8KxQtHWTCJ9YIqkdcm2aA P4rbUC93WToyzDEDYtCk8wLla9Sn0CDG5MkkDXYryI2y8757Pa2DeqKSGuAhM1zrHM4f bdk1IgWgv1KAhhsHXwveXHziVVzaLjE/h6ijj26ixOIOUrHlj7u47S+x/GV1nkl78M+g 1eUGqVWJd6Xmup+Zg54fCpkuP4NBx1ujjcVUAy22akB2ExmlWqZlJDqetVUMKxw11Ulj jZUGsCrkEz67y0Pw8Lk5SL2pfy7WnZpWphwK2nD+DX2I+3z5BxRl2tUtRXUO5XJVUSYf 5uyg== X-Received: by 10.180.74.132 with SMTP id t4mr11922677wiv.55.1433666258277; Sun, 07 Jun 2015 01:37:38 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id ch2sm2680033wib.18.2015.06.07.01.37.36 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 07 Jun 2015 01:37:36 -0700 (PDT) Date: Sun, 7 Jun 2015 10:37:34 +0200 From: Mateusz Guzik To: kikuchan Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [patch] separate SysV IPC namespace for jail Message-ID: <20150607083734.GB9182@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> <20150607013929.GA9182@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 08:37:40 -0000 On Sun, Jun 07, 2015 at 04:43:16PM +0900, kikuchan wrote: > Hi Mateusz, > > Thanks for your reply! > > First of all, I intend to *jail* SysV IPC user completely. > (unless user really want to interact with each other between jails) > > I think SysV IPC is simple but obsolete, so you can design whatever > you want for jail system. > Also, I want keep everything simple. > > My design (to be sure): > - Each entry of the list (shown in ipcs) belongs to a jail. > - Any operation to SHM/SEM/MSG attempted from another jail, will just > fail with EACCES. > But why? See below. > > > "Address space can be shared between multiple PROCESSES, what happens if > > such a pair ends up in different jails? Preferably such a scenario would > > be prohibited to avoid future accidents." > > > > However, sysvipc namespace sharing is an ok feature esp. with > > multi-level jails. In the simplest scenario upon jail creation you > > decide whether it gets its own namespace or inherits it. > > > > > > What about existing sysvshm mappings when jailing? > > > > > > Real (not jailed) environment is treated as a jail with jid=0 in kernel. > > > If you create sysvshm memory segment before entering a jail, the > > > segment simply owned by jid=0. > > > > > > > The point is you get a process with sysvshm segments from 2 different > > jails. Looks like solid trouble protential. > > Ok, I think I've got what you'd concerned. > > In my design, setting up such processes would be difficult. > This wouldn't be happend normally, because shared memory segments > should be obtained BEFORE entering a jail; > > 1. Create a segment on jid=0 with shmget() > 2. shmat() to attach (get void *ptr) > 3. fork() > 4. A child process entering to jid=1 with jail_attach() > 5. The child process and the parent process can share the address > space (via *ptr). > 6. If the child process do shmat() on the same ID again, it simply > failed with EACCES. > > It means, there is NO way to obtain a segment created in other jail > AFTER jailed (even if you're root or obtaining the segment created on > jid=0). This is sharing a page, not an address space (see below). This poses serious problems if actual separate namespaces are implemented, otherwise it only leaves a potential for bugs for no real gain. > > As a minimum this is singlethreading > > when jailing, prevention of jailing processes with shared virtual address > > spaces and ones with existing sysvshm mappings. All this is to reduce > > amount of bugs one would have to deal with. > > Virtual memory allocation and related stuff are protected and done by > kernel already, because it's an IPC (Inter Process Communication). > Moreover, you cannot change an owner of the IPC entry after creation, > so we don't need an additional protection in kernel. > Here is an example race: on fork memory mappings are copied first, sysvshm data is updated /later/. What happens if one of the calling threads enters a jail while some other thread is forking? This may be buggy as it is already, but that's roughly the scheme. It looks like we have some weird miscommunication here, so let me restate. I do see great benefit in having jail-aware ipcs. I do not believe the way to achieve it is to add jail-aware permission checks. Support in question should provide support for separate namespaces. The are several upsides, including lack of conflict between jails and plugged infoleaks. In general I don't understand why you insist on your approach, I does not have any advantage over separate namespaces that I could see. -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 10:33:19 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A5C66C1E for ; Sun, 7 Jun 2015 10:33:19 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7030911AB for ; Sun, 7 Jun 2015 10:33:19 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Z1XtD-000JWc-AQ for freebsd-stable@freebsd.org; Sun, 07 Jun 2015 10:33:15 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1Z1XtD-00050x-80 for freebsd-stable@freebsd.org; Sun, 07 Jun 2015 11:33:15 +0100 To: freebsd-stable@freebsd.org Subject: CARp comatibility between 9 and 10 Message-Id: From: Pete French Date: Sun, 07 Jun 2015 11:33:15 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 10:33:19 -0000 I have a pair of firewalls running FreeBSD 9 to upgrade to 10 next week. I know CARp was rewritten, but I was wndering a few things before I started. Mainly is it possible to have one machine running 9 and one running 10 with the failover working between themproperly. The reason I am wondering s that on 10 it appears you set a VHID per IP address, whereas on 9 it is per interface. I have multiple IP addresses on the carp interfces on 9, so on 10 can I simply set them up all with the same VHID, or is that not supported ? Thanks for any avice which might make Monday morning back in the office go a bit easier :) -pete. From owner-freebsd-stable@FreeBSD.ORG Sun Jun 7 13:25:04 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5C9334D9 for ; Sun, 7 Jun 2015 13:25:04 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: from mail.ultra-secure.de (mail.ultra-secure.de [88.198.178.88]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A3015186F for ; Sun, 7 Jun 2015 13:25:03 +0000 (UTC) (envelope-from rainer@ultra-secure.de) Received: (qmail 33684 invoked by uid 89); 7 Jun 2015 13:20:48 -0000 Received: from unknown (HELO ?192.168.1.200?) (rainer@ultra-secure.de@217.71.83.52) by mail.ultra-secure.de with ESMTPA; 7 Jun 2015 13:20:48 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: CARp comatibility between 9 and 10 From: Rainer Duffner In-Reply-To: Date: Sun, 7 Jun 2015 15:20:45 +0200 Cc: freebsd-stable@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: To: Pete French X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Jun 2015 13:25:04 -0000 > Am 07.06.2015 um 12:33 schrieb Pete French : > > I have a pair of firewalls running FreeBSD 9 to upgrade > to 10 next week. I know CARp was rewritten, but I was wndering a few > things before I started. Mainly is it possible to have one > machine running 9 and one running 10 with the failover working > between themproperly. The reason I am wondering s that on 10 it appears > you set a VHID per IP address, whereas on 9 it is per interface. I have > multiple IP addresses on the carp interfces on 9, so on 10 can I simply > set them up all with the same VHID, or is that not supported ? > > Thanks for any avice which might make Monday morning back in the office > go a bit easier :) > I did this a while ago - and it actually worked. (CARP between 9 and 10). I think I have each IP assigned its own VHID, though. From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 10:14:03 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C63E84FD for ; Mon, 8 Jun 2015 10:14:03 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from constantine.ingresso.co.uk (constantine.ingresso.co.uk [IPv6:2a02:b90:3002:e550::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8F9091DCC for ; Mon, 8 Jun 2015 10:14:03 +0000 (UTC) (envelope-from petefrench@ingresso.co.uk) Received: from dilbert.london-internal.ingresso.co.uk ([10.64.50.6] helo=dilbert.ingresso.co.uk) by constantine.ingresso.co.uk with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.84 (FreeBSD)) (envelope-from ) id 1Z1u47-000394-6z; Mon, 08 Jun 2015 10:13:59 +0000 Received: from petefrench by dilbert.ingresso.co.uk with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1Z1u47-000Js8-4p; Mon, 08 Jun 2015 11:13:59 +0100 To: petefrench@ingresso.co.uk, rainer@ultra-secure.de Subject: Re: CARp comatibility between 9 and 10 Cc: freebsd-stable@freebsd.org In-Reply-To: Message-Id: From: Pete French Date: Mon, 08 Jun 2015 11:13:59 +0100 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 10:14:03 -0000 > I did this a while ago - and it actually worked. > (CARP between 9 and 10). > > I think I have each IP assigned its own VHID, though. Thanks for this, someone else has confimred that 10 orks with multiple IP's per VHID, so I am good to go. Do I still need to compile a separate kernel with pfsync and carp in it, or can these now be loaded as modules ? I cant remember when I started doing that, but I suspect it may no longer be necessary. -pete. From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 10:31:53 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7C2D57CE for ; Mon, 8 Jun 2015 10:31:53 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 118161238 for ; Mon, 8 Jun 2015 10:31:53 +0000 (UTC) (envelope-from claudiu.vasadi@gmail.com) Received: by wibut5 with SMTP id ut5so81200699wib.1 for ; Mon, 08 Jun 2015 03:31:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2G20gHQ4SAgJQXEWtSx355OAF/JMzFco4bATJnx2rr4=; b=YukX2Ng0wHhr+1qfmjj3PLns7VrMzYrztVe72F43B8cpSTex+WdyNzgwbONjT8UHFy Oe2u3Kqm6hHFnEG82ckj0L2//p0U6hAoTfCm21wCDqCzLDSSFe1wIRmwPsYluMBQUC2L ZJnMzyDli0AaDG6TjaCTVBrP2HjKLBO2B62us5PMoU8OF7yg+JXTpTyiLo+vLP03xe5a PAcY/HmL4ApWPXDLx8E0ecUmWZeTfLFNsJ68GFUuT71GzPIEwyD1QWNzeTMDvt7lZC00 /5BitxaDpusLCS71glANRfAED+rUCqILVkuufA61I3nrBmFg6TTijiMk3EUFnpLzjo+6 G56A== MIME-Version: 1.0 X-Received: by 10.180.189.10 with SMTP id ge10mr20974083wic.85.1433759510691; Mon, 08 Jun 2015 03:31:50 -0700 (PDT) Received: by 10.28.169.196 with HTTP; Mon, 8 Jun 2015 03:31:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 8 Jun 2015 12:31:50 +0200 Message-ID: Subject: Re: CARp comatibility between 9 and 10 From: claudiu vasadi To: Pete French Cc: rainer@ultra-secure.de, freebsd-stable stable Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 10:31:53 -0000 You can use modules. On Mon, Jun 8, 2015 at 12:13 PM, Pete French wrote: > > I did this a while ago - and it actually worked. > > (CARP between 9 and 10). > > > > I think I have each IP assigned its own VHID, though. > > Thanks for this, someone else has confimred that 10 orks with multiple IP's > per VHID, so I am good to go. > > Do I still need to compile a separate kernel with pfsync and carp in > it, or can these now be loaded as modules ? I cant remember when I started > doing that, but I suspect it may no longer be necessary. > > -pete. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > -- Best regards, Claudiu Vasadi From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 16:55:40 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43A8C2C3 for ; Mon, 8 Jun 2015 16:55:40 +0000 (UTC) (envelope-from joji@eskimo.com) Received: from mail.eskimo.com (mail.eskimo.com [204.122.16.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CAE113A4 for ; Mon, 8 Jun 2015 16:55:39 +0000 (UTC) (envelope-from joji@eskimo.com) Received: from shellx.eskimo.com (shellx.eskimo.com [204.122.16.2]) by mail.eskimo.com (Postfix) with ESMTP id 5B886A8E for ; Mon, 8 Jun 2015 09:51:39 -0700 (PDT) Received: by shellx.eskimo.com (Postfix, from userid 51518) id 4C0ACCEE; Mon, 8 Jun 2015 09:51:38 -0700 (PDT) Date: Mon, 8 Jun 2015 09:51:38 -0700 From: Joseph Olatt To: freebsd-stable@freebsd.org Subject: intel(0): Detected a hung GPU, disabling acceleration Message-ID: <20150608165138.GA24840@eskimo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.98.7 at mail.eskimo.com X-Virus-Status: Clean X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 16:55:40 -0000 mplayer and vlc stopped showing video while trying watch .flv, .mp4, etc. on my FreeBSD laptop running: FreeBSD peace 10.1-STABLE FreeBSD 10.1-STABLE #7 r284146: Mon Jun 8 05:10:48 CDT 2015 root@peace:/usr/obj/usr/src/sys/PEACE i386 I get a black screen. However, audio works fine. I used to be able to be able to do this before. Looking at Xorg.0.log, I see: [ 35.523] (EE) intel(0): Detected a hung GPU, disabling acceleration. dmesg shows: info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 error: [drm:pid12:i915_hangcheck_hung] *ERROR* Hangcheck timer elapsed... GPU hung I have the following graphics chip: vgapci1@pci0:0:2:1: class=0x038000 card=0x201a17aa chip=0x27a68086 rev=0x03 hdr=0x00 vendor = 'Intel Corporation' device = 'Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller' class = display Using the x11 driver works, but can't scale to fullscreen. Xorg.0.log, dmesg and i915_error_state is at: http://www.eskimo.com/~joji/FreeBSD/Xorg.0.log http://www.eskimo.com/~joji/FreeBSD/dmesg.txt http://www.eskimo.com/~joji/FreeBSD/i915_error_state.txt Anybody else having similar issues? Any ideas/suggestions will be greatly appreciated. From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 17:17:09 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4151F8B5; Mon, 8 Jun 2015 17:17:09 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAE4619BE; Mon, 8 Jun 2015 17:17:08 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by wgez8 with SMTP id z8so108624513wge.0; Mon, 08 Jun 2015 10:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=cM+WLLwDU4aST7D1BjBpR631KfxU8jZom4piDveOD5Y=; b=SZd+Y0jzH12/O7REeN+r+vufC6lSVoBtirwx9BAOXVqe8gLjPd0KejJpOuBUBxYhwl 61fRgQLtPP1LkrjrJCSw1EElZfqjVDeYvVU5HCKaKWR5DnAu407phqejBWn6gUVJsTXG J0B+Mtr6cSI81RrWD/PYU5lsDocv61fp6P1wtZuoI7PgwFjMEoae/ZSlo0Y1T6bpS8Rl EGhPhMTix2cXxFMo8Aj8WCWccozXeb2unGJIaaF1gKVwSVxqWq/9Yu5P1LG3R4mkwwWB eth/a324Q8Elw1V6VmtGqu3eVK2XHa/eAJj5B6/laB60zN55IsOZRO6KYI29n8h/nXqg bVXg== X-Received: by 10.180.77.102 with SMTP id r6mr82167wiw.87.1433783827306; Mon, 08 Jun 2015 10:17:07 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id gw7sm2032939wib.15.2015.06.08.10.17.05 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 08 Jun 2015 10:17:05 -0700 (PDT) Date: Mon, 8 Jun 2015 19:17:03 +0200 From: Mateusz Guzik To: kikuchan Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [patch] separate SysV IPC namespace for jail Message-ID: <20150608171702.GA15516@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> <20150607013929.GA9182@dft-labs.eu> <20150607083734.GB9182@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 17:17:09 -0000 On Mon, Jun 08, 2015 at 01:42:21AM +0900, kikuchan wrote: > From my curiosity, is my patch a technically bad? > Is there race condition in it? Or, enabling key_t separation for jail > could trigger race condition, perhaps? > I only briefly looked at the patch. The fact that you perform outside of ipcperm looks suspicious but may be harmless, so at best it's a bad style. If you need ipc mechanism-specifc functions, make them call ipcperm instead. The jail check is too simplistic. Jails higher in the hierarchy should be able to access whatever lower jails produced. > > > I do see great benefit in having jail-aware ipcs. > > > > I do not believe the way to achieve it is to add jail-aware permission > > checks. Support in question should provide support for separate > > namespaces. The are several upsides, including lack of conflict between > > jails and plugged infoleaks. > > Sorry but I might misunderstand what your "separate namespaces" means. > What namespace are you going to separate? key_t, shmid, kernel > structure of shm, or others? > What features do your "jail-aware ipcs" provide? > Well, as I said in my first mail the idea is to make ipc code look at structures assigned to given jail, so that we can have multiple jails with only their own objects. No "well, this id is used by other jail", unless the namespace is explicitly shared. I did have a patch with a meh implementation doing this, but I lost it along the way. It is easy to implement it for "private purposes" (i.e. disregarding possible attacks with jailing processes). The real work is making the whole business safe. For instance back then I could not find any reliable mechanism to tell me whether given process has a shared address space. There is only a vm_refcnt counter in vmspace which is modified on various occasions, thus is not suitable. Adding a separate counter sucks and adding a "once set, never cleared flag" sucks as well. Maybe there is a good method. -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Mon Jun 8 17:59:34 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DB8458B for ; Mon, 8 Jun 2015 17:59:34 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from frv25.fwdcdn.com (frv25.fwdcdn.com [212.42.77.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4FD8B13CB for ; Mon, 8 Jun 2015 17:59:33 +0000 (UTC) (envelope-from fidaj@ukr.net) Received: from [10.10.14.27] (helo=frv158.fwdcdn.com) by frv25.fwdcdn.com QID:1Z20yF-000Aed-8H/RC:1; Mon, 08 Jun 2015 20:36:23 +0300 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=Yz12g2xyzOVwVc3F8RkF/Rt7UYWu3bQGjE94imOWHT0=; b=kbzOm1LWVHM4YlHpxZNrv1TYzwGGpdmVxQe0vjFGOyGhOMqWNSjrdbJAH0drvhIMsuKYpKQIMgwXK5dqtfviBWWc5dwB3nLBcTu5J7zwfypyBUEZ+1kRe4C2WhXy/bBJRnQSgUgniV8AlvAv0XEPhAikWsmP7FVRuKkeqzBL50Q=; Received: from [134.249.91.180] (helo=nonamehost.local) by frv158.fwdcdn.com with esmtpsa ID 1Z20i3-000Pql-Ho ; Mon, 08 Jun 2015 20:19:39 +0300 Date: Mon, 8 Jun 2015 20:19:38 +0300 From: Ivan Klymenko To: Joseph Olatt Cc: freebsd-stable@freebsd.org Subject: Re: intel(0): Detected a hung GPU, disabling acceleration Message-ID: <20150608201938.1f42caef@nonamehost.local> In-Reply-To: <20150608165138.GA24840@eskimo.com> References: <20150608165138.GA24840@eskimo.com> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.27; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Authentication-Result: IP=134.249.91.180; mail.from=fidaj@ukr.net; dkim=pass; header.d=ukr.net X-Ukrnet-Yellow: 0 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2015 17:59:34 -0000 Mon, 8 Jun 2015 09:51:38 -0700 Joseph Olatt =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=B2: > mplayer and vlc stopped showing video while trying watch .flv, .mp4, > etc. on my FreeBSD laptop running: >=20 > FreeBSD peace 10.1-STABLE FreeBSD 10.1-STABLE #7 r284146: Mon=20 > Jun 8 05:10:48 CDT 2015 root@peace:/usr/obj/usr/src/sys/PEACE =20 > i386 >=20 > I get a black screen. However, audio works fine. I used to be able to=20 > be able to do this before. Looking at Xorg.0.log, I see: >=20 > [ 35.523] (EE) intel(0): Detected a hung GPU, disabling > acceleration. >=20 >=20 > dmesg shows: >=20 > info: [drm] Initialized i915 1.6.0 20080730 for drmn0 on minor 0 > error: [drm:pid12:i915_hangcheck_hung] *ERROR* Hangcheck timer > elapsed... GPU hung >=20 >=20 > I have the following graphics chip: >=20 > vgapci1@pci0:0:2:1: class=3D0x038000 card=3D0x201a17aa > chip=3D0x27a68086 rev=3D0x03 hdr=3D0x00 vendor =3D 'Intel Corporation' > device =3D 'Mobile 945GM/GMS/GME, 943/940GML Express Integrated > Graphics Controller' class =3D display >=20 >=20 > Using the x11 driver works, but can't scale to fullscreen. >=20 > Xorg.0.log, dmesg and i915_error_state is at: >=20 > http://www.eskimo.com/~joji/FreeBSD/Xorg.0.log > http://www.eskimo.com/~joji/FreeBSD/dmesg.txt > http://www.eskimo.com/~joji/FreeBSD/i915_error_state.txt >=20 >=20 > Anybody else having similar issues? Any ideas/suggestions will be > greatly appreciated. >=20 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194766 From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 11:10:37 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9D9D2133 for ; Tue, 9 Jun 2015 11:10:37 +0000 (UTC) (envelope-from lubov9yhgx@yahoo.com) Received: from nm35-vm8.bullet.mail.ne1.yahoo.com (nm35-vm8.bullet.mail.ne1.yahoo.com [98.138.229.104]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B3A71C07 for ; Tue, 9 Jun 2015 11:10:37 +0000 (UTC) (envelope-from lubov9yhgx@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1433846184; bh=YTdW2N4Oxt4FEdu+kfSK24XDmVqVURtxWynt5dVFGmw=; h=Date:From:Reply-To:To:Subject:From:Subject; b=nPXtZ7/dRXyYJQUce5ydJg7KqughNBLDXLjauGEdCC+aC1rWltUdnGAyJOXWSqZ+vVacXb97anQfEcik41sI5n5K1GbxMI/0uQb+kzbxGtdNGFEqwVWg9fW/xgCdK+hsIXPFd+OsgJG0N9Dqu4qQoqnXdRv8/BntGwNSvgKGaCMkQRuITsKlEgrtCOCr8I1miH7UOuYU0P8Tkyi4S7kn65u+S7WUv8HQmOPYMV777c7uZ17oxkTEPXvw2iNWh2avEBsg/qIKa0WnoQ3o+sIV7e9gnoT+yBd2jnBgUcl9I2Jh1VW3v1TpOJT3ZKUI2deJsXVfJiLcbgrnc2FkrJZZeg== Received: from [127.0.0.1] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 09 Jun 2015 10:36:24 -0000 Received: from [98.138.101.129] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 09 Jun 2015 10:33:41 -0000 Received: from [98.138.88.232] by tm17.bullet.mail.ne1.yahoo.com with NNFMP; 09 Jun 2015 10:33:41 -0000 Received: from [127.0.0.1] by omp1032.mail.ne1.yahoo.com with NNFMP; 09 Jun 2015 10:33:41 -0000 X-Yahoo-Newman-Property: ymail-4 X-Yahoo-Newman-Id: 850157.81604.bm@omp1032.mail.ne1.yahoo.com X-YMail-OSG: H2cNlOYVM1ktOJ8m18LU1hDBKV4PTduMzN5Eq092QCKp33qgq5UNk6R4isBQank Sw9MkW2AK7KLaCVUA6l9xQWTWODAjzlHPeJzoCflNS2fAzZ6TEyhaL1iq5vZsGmrq4FZD5joG3VE i19GHJVOOqZd_DyhUpRmQeqPtCSKtmIW4Aor9GkV6qn8bU9nvpX9CTqqe384QT4oisp5BCpYNgZB h7vxxPC6AvBQLzMiDq7ZqZgh.jLWLF9n6VhkMOIhokv2gROOtHi58iPmfX3j3iEhT9rSb6bF9y7x 8iFRAu0pqyszygCaS1jrMA4vV4Izc_IjsMGsKtzskCyPwH3Y2RCF5OfrxihOro4a6CY.l1rG9UJ7 qWcdE6sW7K.rNDRstBX0qqBwDf0y6wlFI1dHru1eWoPGYvrgY5yt.9bzBWUSWjIOYEL2hGcAapj2 dI7YPrGjrt4F7l4Spx9QBb01aX30.5I0Muz2JIKQrktl24BUy.KVqr3Pbg8Sjk8AsRtP62LC74s. tc3NLYuc- Received: by 98.138.105.220; Tue, 09 Jun 2015 10:33:41 +0000 Date: Tue, 9 Jun 2015 10:33:40 +0000 (UTC) From: Reply-To: To: "freebsd-stable@freebsd.org" Message-ID: <1017835670.7854349.1433846020923.JavaMail.yahoo@mail.yahoo.com> Subject: =?UTF-8?B?0J/QvtC70YPRh9C40YLQtSDQvdCw0LTQtdC20L3QvtCz0L4g0L/QvtC80L4=?= =?UTF-8?B?0YnQvdC40LrQsCDQtNC70Y8g0JLQsNGI0LXQs9C+INCx0LjQt9C90LXRgdCw?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 11:10:37 -0000 CtCd0YPQttC10L0g0L/QtdGA0LXQstC+0LQg0YXQvtGA0L7RiNC10LPQviDQutCw0YfQtdGB0YLQ stCwPyDQltC00LXQvCDQktCw0YjQtdCz0L4g0LfQstC+0L3QutCwIQoK0JLQvtGCINGD0LbQtSDQ sdC+0LvRjNGI0LUgNiDQu9C10YIg0L/QtdGA0LXQstC+0LTRh9C10YHQutC+0LUg0LDQs9C10L3R gtGB0YLQstC+INCT0LXQu9GM0LLQtdGG0LjRjyDQv9GA0LXQtNC70LDQs9Cw0LXRgiDRg9GB0LvR g9Cz0Lgg0Y7RgNC40LTQuNGH0LXRgdC60LjQvCDQuCDRhNC40LfQuNGH0LXRgdC60LjQvCDQu9C4 0YbQsNC8OiDQv9C40YHRjNC80LXQvdC90YvQtSwg0YPRgdGC0L3Ri9C1INC/0LXRgNC10LLQvtC0 0YssINCwINGC0LDQutC20LUg0YHQuNC90YXRgNC+0L0uCtCX0LAg0LTQsNC90L3Ri9C5INC/0LXR gNC40L7QtCDRg9GB0L/QtdGI0L3QviDRgNC10LDQu9C40LfQvtCy0LDQu9C4INCx0L7Qu9C10LUg NTAwMCDQv9GA0L7QtdC60YLQvtCyLCDQsCDQsNCz0LXQvdGC0YHRgtCy0L4g0L7QsdGK0LXQtNC4 0L3QuNC70L4g0LHQvtC70LXQtSAyMDAwINC/0YDQvtGE0LXRgdGB0LjQvtC90LDQu9GM0L3Ri9GF ICDQv9C10YDQtdCy0L7QtNGH0LjQutC+0LIuCgrQmtCw0LbQtNGL0Lkg0LPQvtC0INC90LDRiNCw INC60L7QvNC/0LDQvdC40Y8g0LjQvNC10LXRgiDQstC+0LfQvNC+0LbQvdC+0YHRgtGMINC/0L7Q tNGC0LLQtdGA0LTQuNGC0Ywg0LvQuNC00LXRgNGB0LrQuNC1INC/0L7Qt9C40YbQuNC4INCyINC+ 0LHQu9Cw0YHRgtC4INC/0LXRgNC10LLQvtC00YfQtdGB0LrQuNGFINGD0YHQu9GD0LMg0LLRi9GB 0L7QutC+0L/RgNC10YHRgtC40LbQvdGL0LzQuCDQv9GA0LXQvNC40Y/QvNC4INC4INGB0LXRgNGC 0LjRhNC40LrQsNGC0LDQvNC4LiAKCtCf0L7Qu9GD0YfQuNGC0LUg0YPQtNC+0LLQvtC70YzRgdGC 0LLQuNC1IC0g0L7RhtC10L3QuNGC0LUg0L/RgNC10LjQvNGD0YnQtdGB0YLQstCwINC+0YfQtdC9 0Ywg0L/RgNC+0YHRgtC+0Lkg0Lgg0LLRi9Cz0L7QtNC90L7QuSDRgdGF0LXQvNGLINGA0LDQsdC+ 0YLRizoKCi0g0LHQtdGB0L/Qu9Cw0YLQvdC+0LUg0LrQvtC90YHRg9C70YzRgtC40YDQvtCy0LDQ vdC40LUg0Lgg0L/QvtC00YLQstC10YDQttC00LXQvdC40LUg0LfQsNC60LDQt9CwINC90LDQuNCx 0L7Qu9C10LUg0YPQtNC+0LHQvdGL0Lwg0LTQu9GPINCS0LDRgSDRgdC/0L7RgdC+0LHQvtC8IC0g 0LIg0L7RhNC40YHQtSwg0L/QvtGB0YDQtdC00YHRgtCy0L7QvCDQt9Cy0L7QvdC60LAsINC/0L4g ZS1tYWlsOwotINCy0L3QtdGB0LXQvdC40LUg0L/RgNC10LTQvtC/0LvQsNGC0Ysg0Lgg0LjRgdC/ 0L7Qu9C90LXQvdC40LUg0LfQsNC60LDQt9CwOwotINC/0LXRgNC10LTQsNGH0LAg0LPQvtGC0L7Q stC+0LPQviDQv9C10YDQtdCy0L7QtNCwINC4INC00L7Qv9C70LDRgtCwINCy0YLQvtGA0L7QuSDR h9Cw0YHRgtC4INC+0YIg0YHRg9C80LzRiyDQtNC+0LPQvtCy0L7RgNCwLgoK0J3QsNGI0Lgg0LfQ sNC60LDQt9GH0LjQutC4INGA0LDQtNGLINGA0LXQutC+0LzQtdC90LTQvtCy0LDRgtGMINC90LDR iNC1INCw0LPQtdC90YLRgdGC0LLQviDQt9CwOgoK4oCi0YfQsNGB0YLRi9C1INGA0L7Qt9GL0LPR gNGL0YjQuCDQtNC+0YDQvtCz0LjRhSDQv9C+0LTQsNGA0LrQvtCyOiDRgtGD0YDRiyDQsiDRjdC6 0LfQvtGC0LjRh9C10YHQutC40LUg0YHRgtGA0LDQvdGLLCDRgdC10YDRgtC40YTQuNC60LDRgtGL INCh0J/QkC3RgdCw0LvQvtC90LAsIGlQYWQsINC00YDRg9Cz0LjQtSDQs9Cw0LTQttC10YLRiy4K CuKAotCy0L7Qt9C80L7QttC90L7RgdGC0Ywg0L7Qv9C70LDRgtGLINC30LAg0L/QtdGA0LXQstC+ 0LQgb25saW5lIOKAkyDQv9C+0YHRgNC10LTRgdGC0LLQvtC8INC60L7RiNC10LvRjNC60LAgS0lX SSwg0JLQsNC8INC90LUg0L3Rg9C20L3QviDQuNC00YLQuCDQsiDQvtGC0LTQtdC70LXQvdC40LUg 0LHQsNC90LrQsDsKCuKAotCy0L7Qt9C80L7QttC90L7RgdGC0Ywg0LLRi9GH0LjRgtGL0LLQsNC9 0LjRjyDQstCw0LbQvdGL0YUg0LTQvtC60YPQvNC10L3RgtC+0LIg0L3QvtGB0LjRgtC10LvQtdC8 INGP0LfRi9C60LA7CgrigKLQv9GA0LjRj9GC0L3Ri9C1INCx0L7QvdGD0YHRiyDQsiDRgtC10YfQ tdC90LjQtSDQv9C10YDQstGL0YUgMyDQvNC10YHRj9GG0LXQsiDQvtCx0YDQsNGJ0LXQvdC40Lkg 4oCTINGG0LXQu9GL0Lkg0L/QsNC60LXRgiDQv9GA0LjQstC40LvQtdCz0LjQuSDQuCDRgdC60LjQ tNC+0Log0L3QsCDRg9GB0LvRg9Cz0Lgg0L3QsNGI0LXQs9C+INCw0LPQtdC90YLRgdGC0LLQsDsK CuKAotCR0JXQodCf0JvQkNCi0J3QntCVINC/0YDQvtCx0L3QvtC1INC40YHQv9C+0LvQvdC10L3Q uNC1OiDQktGLINC90LjRgdC60L7Qu9GM0LrQviDQvdC1INGC0LXRgNGP0LXRgtC1OwoK4oCi0LLQ vtC30LzQvtC20L3QvtGB0YLRjCDQuNGB0L/QvtC70L3QtdC90LjRjyDRgdGA0L7Rh9C90L7Qs9C+ INC/0LXRgNC10LLQvtC00LAg0LvRjtCx0L7Qs9C+INC+0LHRitC10LzQsDsgCgrigKLQs9C+0YLQ vtCy0L3QvtGB0YLRjCDQvtCx0YHQu9GD0LbQuNCy0LDRgtGMINC/0L7RgdGC0L7Rj9C90L3Ri9GF INC30LDQutCw0LfRh9C40LrQvtCyINC/0L4g0YPQtNC+0LHQvdC+0Lkg0YHRhdC10LzQtSDQsdC1 0Lcg0L/RgNC10LTQstCw0YDQuNGC0LXQu9GM0L3QvtC5INC+0L/Qu9Cw0YLRizsKCuKAotCy0YvR gdC+0LrQvtC1INC60LDRh9C10YHRgtCy0L4g0LLRi9C/0L7Qu9C90LXQvdC40Y8g0LrQsNC20LTQ vtCz0L4g0LfQsNC60LDQt9CwIOKAkyDQvtGCINC90LXQsdC+0LvRjNGI0L7Qs9C+INC00L4g0LrR gNGD0L/QvdC+0LPQvjsKCuKAotC+0YfQtdC90Ywg0YjQuNGA0L7QutC40Lkg0YDRj9C0INGP0LfR i9C60L7QstGL0YUg0LLQvtC30LzQvtC20L3QvtGB0YLQtdC5OiDQv9C10YDQtdCy0L7QtNGLINC9 0LAv0YEgNTcg0Y/Qt9GL0LrQvtCyOwoK4oCi0L3QvtGC0LDRgNC40LDQu9GM0L3QvtC1INC30LDQ stC10YDQtdC90LjQtSDQv9C10YDQtdCy0LXQtNC10L3QvdC+0Lkg0LTQvtC60YPQvNC10L3RgtCw 0YbQuNC4OwoKCtCc0Ysg0L3QuNC60L7Qs9C00LAg0L3QtSDQtNC10LvQuNC70Lgg0YHQstC+0LjR hSDQutC70LjQtdC90YLQvtCyINC90LAg0YLQtdGFLCDQutGC0L4g0LfQsNC60LDQt9GL0LLQsNC1 0YIg0LHQvtC70YzRiNC40LUg0L7QsdGK0LXQvNGLLCDQuCDQstGB0LXRhSDQtNGA0YPQs9C40YUu IArQnNGLINGC0L7Qu9GM0LrQviDQv9C10YDQtdCy0L7QtNC40LwuINCYINGG0LXQvdC40Lwg0LrQ sNC20LTQvtCz0L4g0LrQu9C40LXQvdGC0LAhIArQn9GA0L7RhNC10YHRgdC40L7QvdCw0LvQuNC3 0Lwg0Lgg0L7Qv9GL0YIg0L3QsNGI0LjRhSDQv9C10YDQtdCy0L7QtNGH0LjQutC+0LIsINGB0YDQ tdC00Lgg0LrQvtGC0L7RgNGL0YUg0L7Qs9GA0L7QvNC90L7QtSDQutC+0LvQuNGH0LXRgdGC0LLQ viDRj9C30YvQutC+0LLRi9GFINC90L7RgdC40YLQtdC70LXQuSwg0L/QvtC30LLQvtC70Y/RjtGC INC90LDQvCDQtNC10LvQsNGC0Ywg0L/QtdGA0LXQstC+0LTRiyDQu9GO0LHQvtCz0L4g0YPRgNC+ 0LLQvdGPINGB0LvQvtC20L3QvtGB0YLQuCDQsiDRgdCw0LzQvtC8INCy0YvRgdC+0LrQvtC8INC6 0LDRh9C10YHRgtCy0LUuIAoK0JbQtNC10Lwg0JLQsNGI0LXQuSDQt9Cw0Y/QstC60Lgg0L/QviDR gtC10Lst0L3RgzogKzcgLzcwNS8gODczNzExMgoKCgoKCg== From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 16:56:05 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C14AE93B; Tue, 9 Jun 2015 16:56:05 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from vsmtp06.dti.ne.jp (vsmtp06.dti.ne.jp [202.216.231.141]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF921444; Tue, 9 Jun 2015 16:56:04 +0000 (UTC) (envelope-from kikuchan@uranus.dti.ne.jp) Received: from mail.dream.jp (webmail02.ga.dti.ne.jp [202.216.229.153]) by vsmtp06.dti.ne.jp (3.11v) with ESMTP AUTH id t59GhxZq026990; Wed, 10 Jun 2015 01:43:59 +0900 (JST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Date: Wed, 10 Jun 2015 01:43:59 +0900 From: To: Mateusz Guzik Cc: , Subject: Re: [patch] separate SysV IPC namespace for jail In-Reply-To: <20150608171702.GA15516@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> <20150607013929.GA9182@dft-labs.eu> <20150607083734.GB9182@dft-labs.eu> <20150608171702.GA15516@dft-labs.eu> Message-ID: X-Sender: kikuchan@uranus.dti.ne.jp User-Agent: DTI MyMail/0.3-trunk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 16:56:05 -0000 Hi Mateusz, Thank you for your reply. (and sorry about my ISP mail service jammed...) I still want to resolve sysv ipc confilicts between jails somehow. (It's welcome if someone else do, but I couldn't find any working example yet...) > I only briefly looked at the patch. The fact that you perform outside of > ipcperm looks suspicious but may be harmless, so at best it's a bad > style. If you need ipc mechanism-specifc functions, make them call > ipcperm instead. Sorry, I guess EACCES misled you. I should have chosen other value and/or concealed information for each jail completely. I intended to demonstrate it's enought to achieve IPC key_t space separation (to PostgreSQL work) for each jails without having shmid_kernel struct for each jails. > The jail check is too simplistic. Jails higher in the hierarchy should be > able to access whatever lower jails produced. Yes I thought so, however, I realized that a single key_t space per jail is enough, otherwise user get confused. Hmm, but yes, probably you're right. I can't find any technical reason to forbid the behavior you mentioned. (I think it needs to modify ipcs(1) so that can display JID to avoid confusing) > Well, as I said in my first mail the idea is to make ipc code look at > structures assigned to given jail, so that we can have multiple jails > with only their own objects. No "well, this id is used by other jail", > unless the namespace is explicitly shared. Ok, now I've understood what the idea is, and maybe it's done by Nick once before on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 I'm reading the code (shm so far) and kernel deeply now, and I'm so sorry about confusing you due to less knowledge of kernel code. There are two identifier, ID and KEY (shmid and shmkey for SHM) on SysV IPC object. The KEY space must be separated for each jails I think, but about the ID, is determined by kernel and userland users don't care its value, do you really think it should be managed separately in kernel? I agree that "multiple jails with only their own objects" is good design basically, but especially, if you want to support hierarchical jails, the objects will be referenced by multiple jails. If ID space separation is not so important, separating internal namespace for each jail is too complicate for simple KEY space separation, I think. I really should have implemented to conceal information instead of returning EACCES, sorry. ;/ Before jumping to the conclusion, I want to know that *current* code relative to SHM whether have any problems on sharing underlaying vm page between processes that jailed to different jails each other, especially on fork and jail_attach. multithreaded process perhaps? I'm also trying to port Nick's code to 10/stable, then I've found potentially dangerous behavior happens if a process do jail_attach to other jail, due to the separate namespaces have separate ID space for each jail. I guess it was not happned on 4.8 because lack of jail_attach. For example, a process attached to shmid = 65535 on jid=1, then the process changes its jail to jid=2, and if shmid = 65535 exists on jid=2, the process refers wrong vm mapping unless maintain shmmap_state data for the process every jail_attach. Maybe this behavior is something relative to the race that you mentioned before? > For instance back then I could not find any reliable mechanism to tell > me whether given process has a shared address space. There is only a > vm_refcnt counter in vmspace which is modified on various occasions, Hmm, sorry I can't understand what the problem is here... I'm not good at kernel internals yet, so I don't know details of when the processes share the address space, and I have no idea why you want to know whether the process has a shared address space or not... > It is easy to implement it for "private purposes" (i.e. > disregarding possible attacks with jailing processes). The real work is > making the whole business safe. I agree. Is there any project ongoing for this sysvipc issue? If any, what is needed to be done? P.S. I'm really sorry if you feel bad, due to my bad English skill... Regards, Kikuchan On Mon, 8 Jun 2015 19:17:03 +0200, Mateusz Guzik wrote: > On Mon, Jun 08, 2015 at 01:42:21AM +0900, kikuchan wrote: >> From my curiosity, is my patch a technically bad? >> Is there race condition in it? Or, enabling key_t separation for jail >> could trigger race condition, perhaps? >> > > I only briefly looked at the patch. The fact that you perform outside of > ipcperm looks suspicious but may be harmless, so at best it's a bad > style. If you need ipc mechanism-specifc functions, make them call > ipcperm instead. > > The jail check is too simplistic. Jails higher in the hierarchy should be > able to access whatever lower jails produced. > >> >> > I do see great benefit in having jail-aware ipcs. >> > >> > I do not believe the way to achieve it is to add jail-aware permission >> > checks. Support in question should provide support for separate >> > namespaces. The are several upsides, including lack of conflict between >> > jails and plugged infoleaks. >> >> Sorry but I might misunderstand what your "separate namespaces" means. >> What namespace are you going to separate? key_t, shmid, kernel >> structure of shm, or others? >> What features do your "jail-aware ipcs" provide? >> > > Well, as I said in my first mail the idea is to make ipc code look at > structures assigned to given jail, so that we can have multiple jails > with only their own objects. No "well, this id is used by other jail", > unless the namespace is explicitly shared. > > I did have a patch with a meh implementation doing this, but I lost it > along the way. It is easy to implement it for "private purposes" (i.e. > disregarding possible attacks with jailing processes). The real work is > making the whole business safe. > > For instance back then I could not find any reliable mechanism to tell > me whether given process has a shared address space. There is only a > vm_refcnt counter in vmspace which is modified on various occasions, > thus is not suitable. Adding a separate counter sucks and adding a "once > set, never cleared flag" sucks as well. Maybe there is a good method. From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 19:26:54 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 86F90B42; Tue, 9 Jun 2015 19:26:54 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-lb0-x241.google.com (mail-lb0-x241.google.com [IPv6:2a00:1450:4010:c04::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 071AE1983; Tue, 9 Jun 2015 19:26:54 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by lbdu14 with SMTP id u14so3041481lbd.2; Tue, 09 Jun 2015 12:26:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=a6M9ARDFBs8d3QwPtxVcBi575CaQasE5WZml6rNeQls=; b=RY9EubFcQIXM4aijfYfELaJrB5KM3V9/ZJKoXJYFgWddHOaVYJlxZ+mmqMwAEjxVa+ ft7o5T1fwNpLzqmXXxeVTx9jqjr1b5tg1TmspSVrdU7FcxozqvRuswvVYC55QgyjqdMr igSgkcbIhjaGjDg8yiEBD7LlP3LNaeRmjE1GxnwiuMJGqf9A6Lz64ZAws8AZz6CUbDgy FYaA+TCc/Yj0RJuq6NlbClFUZnc81XRD1J7RYi920/Wyn/VF0KeycJwKcMEvKZWNbWWm oTx7r31WoI9np45iJc9+3hKlDTHf2YqC8rcXcj2M/HfEX92zPustU+GxsGLqUTF7caY1 8LCw== X-Received: by 10.180.95.10 with SMTP id dg10mr707492wib.41.1433878011472; Tue, 09 Jun 2015 12:26:51 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPSA id hm8sm10878031wjc.28.2015.06.09.12.26.48 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 09 Jun 2015 12:26:49 -0700 (PDT) Date: Tue, 9 Jun 2015 21:26:46 +0200 From: Mateusz Guzik To: kikuchan@uranus.dti.ne.jp Cc: freebsd-jail@freebsd.org, freebsd-stable@freebsd.org Subject: Re: [patch] separate SysV IPC namespace for jail Message-ID: <20150609192646.GC2039@dft-labs.eu> References: <20150605235348.GA9965@dft-labs.eu> <20150607013929.GA9182@dft-labs.eu> <20150607083734.GB9182@dft-labs.eu> <20150608171702.GA15516@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 19:26:54 -0000 On Wed, Jun 10, 2015 at 01:43:59AM +0900, kikuchan@uranus.dti.ne.jp wrote: > > I only briefly looked at the patch. The fact that you perform outside of > > ipcperm looks suspicious but may be harmless, so at best it's a bad > > style. If you need ipc mechanism-specifc functions, make them call > > ipcperm instead. > > Sorry, I guess EACCES misled you. > I should have chosen other value and/or concealed information for each jail completely. > > I intended to demonstrate it's enought to achieve IPC key_t space separation (to PostgreSQL work) for each jails without having shmid_kernel struct for each jails. > There is no technical problem with providing entirely separate ipcs which would not have to be solved with this approach. This approach is actually harder to get right and has no benefit that I would see. One example downside is resource limiting - implementing per-namespace limits is a non-problem. > > Well, as I said in my first mail the idea is to make ipc code look at > > structures assigned to given jail, so that we can have multiple jails > > with only their own objects. No "well, this id is used by other jail", > > unless the namespace is explicitly shared. > > Ok, now I've understood what the idea is, and maybe it's done by Nick once before on https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=48471 > > There are two identifier, ID and KEY (shmid and shmkey for SHM) on SysV IPC object. > The KEY space must be separated for each jails I think, but about the ID, is determined by kernel and userland users don't care its value, do you really think it should be managed separately in kernel? > I agree that "multiple jails with only their own objects" is good design basically, but especially, if you want to support hierarchical jails, the objects will be referenced by multiple jails. > If ID space separation is not so important, separating internal namespace for each jail is too complicate for simple KEY space separation, I think. > Not separating stuff is more complicated. > I really should have implemented to conceal information instead of returning EACCES, sorry. ;/ > > Before jumping to the conclusion, I want to know that *current* code relative to SHM whether have any problems on sharing underlaying vm page between processes that jailed to different jails each other, especially on fork and jail_attach. multithreaded process perhaps? > There is definitely no problem sharing /a page/. There may be a problem sharing a page which was obtained from syvshm. > I'm also trying to port Nick's code to 10/stable This patch is old and deals with the mostly mechanical part of the work. In particular, it DOES NOT deal with any concerns I already expressed. This is understanadble to some extent since there were no multilevel jails at the time and some people may have felt securing against host root is not necessary. The patch will likely have a lot of conflicts and it will be way faster to write from scratch. > I guess it was not happned on 4.8 because lack of jail_attach. > For example, a process attached to shmid = 65535 on jid=1, then the process changes its jail to jid=2, and if shmid = 65535 exists on jid=2, the process refers wrong vm mapping unless maintain shmmap_state data for the process every jail_attach. This is an example problem. > Maybe this behavior is something relative to the race that you mentioned before? It is not. > > > > For instance back then I could not find any reliable mechanism to tell > > me whether given process has a shared address space. There is only a > > vm_refcnt counter in vmspace which is modified on various occasions, > > Hmm, sorry I can't understand what the problem is here... > I'm not good at kernel internals yet, so I don't know details of when the processes share the address space, and I have no idea why you want to know whether the process has a shared address space or not... > rfork has a flag which makes the new process share the address space with the parent. So when one of these processes jails somewhere, we can end up with mappings from separate namespaces. > > > It is easy to implement it for "private purposes" (i.e. > > disregarding possible attacks with jailing processes). The real work is > > making the whole business safe. > > I agree. > > Is there any project ongoing for this sysvipc issue? > If any, what is needed to be done? > I am unaware of any work being done in the area. I stated what needs to be done in my first e-mail. -- Mateusz Guzik From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 23:34:22 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24F123E4 for ; Tue, 9 Jun 2015 23:34:22 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 053D318AD for ; Tue, 9 Jun 2015 23:34:22 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z2T2B-0001fS-TB for freebsd-stable@freebsd.org; Tue, 09 Jun 2015 23:34:20 +0000 Date: Tue, 09 Jun 2015 16:34:18 -0700 Message-ID: From: Randy Bush To: FreeBSD Stable Subject: ssh install with freebsd-update User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 23:34:22 -0000 # uname -a FreeBSD foux.psg.com 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Tue May 12 19:33:13 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC i386 it's really p11 now if i run freebsd-update install of p11. all looks well until the reboot, when i get Performing sanity check on sshd configuration. Shared object "libgssapi_krb5.so.10" not found, required by "sshd" /etc/rc: WARNING: failed precmd routine for sshd i have to go through the following cd /usr/src/secure/lib/libssh make install cd /usr/src/secure/usr.sbin/sshd make install cd /usr/src/lib/libgssapi make make install service sshd restart and ssh works this occurs on many systems randy From owner-freebsd-stable@FreeBSD.ORG Tue Jun 9 23:48:30 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C3038E4 for ; Tue, 9 Jun 2015 23:48:30 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 04D301B03 for ; Tue, 9 Jun 2015 23:48:30 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id A0BE218F2C; Tue, 9 Jun 2015 16:48:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1433893709; x=1433908109; bh=kacGwW55zYT0yTdiWb/0YxoI/xsUjW9qizSXMhmFT/Q=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=cfmVxecPLmrlHcQVGQ/biRvYz0/januCAwRiHNutWncyGrSwbl6eKnt2XkumFHafS a2r4SqY/qSnAEpX/1WZD7aSFU5m04lUhdGPqc01vgQ4dabh4GJEwbUXpBSWk1ED2ye FLHgPAra+IGxvcJU/NnCibW+hVI04C+z8dr+KFOg= Message-ID: <55777B4D.7040706@delphij.net> Date: Tue, 09 Jun 2015 16:48:29 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Randy Bush , FreeBSD Stable CC: Allan Jude Subject: Re: ssh install with freebsd-update References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2015 23:48:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, Randy, On 06/09/15 16:34, Randy Bush wrote: > # uname -a FreeBSD foux.psg.com 10.1-RELEASE-p10 FreeBSD > 10.1-RELEASE-p10 #0: Tue May 12 19:33:13 UTC 2015 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > i386 > > it's really p11 now > > if i run freebsd-update install of p11. all looks well until the > reboot, when i get > > Performing sanity check on sshd configuration. Shared object > "libgssapi_krb5.so.10" not found, required by "sshd" /etc/rc: > WARNING: failed precmd routine for sshd This is VERY strange! Did you ever have an incomplete upgrade from older FreeBSD releases (9.x) on the affected systems? What was the version before you update/upgrade to the latest one? Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.4 (FreeBSD) iQIcBAEBCgAGBQJVd3tNAAoJEJW2GBstM+ns3JMP/2KdCIqb27+pSNeiWd4P74ip vZkvMYGMS9+7yjqe3IfA+p+gYmHVHE0/Wo1dhQmDP3YpTsAwTUqnXk45iNnqAU4r Xk8bYqwZ0dOQO3zsokJ4L0PIFriGtOJCTXHAlMbfywfqDFstrY/rau6wryc+9pvZ mgLsTps4rtKZ9vUVw0i/sksr6bv9gE5T88W7wdO9MxKDDMj9v8V/PXOEj589BNec XjlTo4f3dXBGIaBOmoWPbYzTcM35oMnHzIAiDdGliwa3MoP05MUMyYueXHpSgCP6 F3Ev1PwNyYWrnau9oLNEClb0lEddVFiGB9dabtUyQA8X9g8nP/kzPDn7fouJrxMK Ak9DtLAeBY771YQzNFfRRW9zRKUOPJx/Ip8gSzFUdujnzhmtdPdSL0qBTOR0tjSS gi3zrAPH0IfkI/r1RCKjbkZHc45lqMH79MprvjjRqHnUe4yUfbDyUtjFcAnP13HH u9ytuMYyRzcRQulaukTMq2FgiOFtoag3g23gM1sfGSz7cd5qPGINAO4pZzWgSRhs z9rVLUVS2pKkxxhVKOzv74dFjmIkYJxhkY/+sa3hzRxzx4lSzBTEk42WXuWcjO/J OBuRpU9cyRrBrG7m+gg5pYaJjCGMrOQnihfa7MsllvhrXSYc7DGOFaNRKYRivHN9 wfqonQTEsja03Bb7Utme =SqCG -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 00:21:50 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50222E82 for ; Wed, 10 Jun 2015 00:21:50 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 309D713C9 for ; Wed, 10 Jun 2015 00:21:50 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z2Tm5-0001qx-AT; Wed, 10 Jun 2015 00:21:45 +0000 Date: Tue, 09 Jun 2015 17:21:43 -0700 Message-ID: From: Randy Bush To: Xin Li Cc: FreeBSD Stable , Allan Jude Subject: Re: ssh install with freebsd-update In-Reply-To: <55777B4D.7040706@delphij.net> References: <55777B4D.7040706@delphij.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 00:21:50 -0000 >> # uname -a FreeBSD foux.psg.com 10.1-RELEASE-p10 FreeBSD >> 10.1-RELEASE-p10 #0: Tue May 12 19:33:13 UTC 2015 >> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC >> i386 >> >> it's really p11 now >> >> if i run freebsd-update install of p11. all looks well until the >> reboot, when i get >> >> Performing sanity check on sshd configuration. Shared object >> "libgssapi_krb5.so.10" not found, required by "sshd" /etc/rc: >> WARNING: failed precmd routine for sshd > > This is VERY strange! Did you ever have an incomplete upgrade from > older FreeBSD releases (9.x) on the affected systems? What was the > version before you update/upgrade to the latest one? this is one of a dozen systems upgraded fom 9.3-stable to 10.1-release p10 using a recipe in https://wiki.rg.net/wiki/FreeBSD9to10. they all show the same symptom. it was consistent for all of them. i was waiting for p11 to see if it would fix it. it did not, at least for this first system i tried. randy From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 00:33:46 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A39099A for ; Wed, 10 Jun 2015 00:33:46 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8CA03169B for ; Wed, 10 Jun 2015 00:33:46 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id BF265180B9; Tue, 9 Jun 2015 17:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1433896425; x=1433910825; bh=op5ZA7Oup6EJ0S/j1s0wvtPrysgygzzsKdT2hrfkS+4=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=a10MkR/UqfYb+pUa3BeZCXjdWJ3gcHyT2l00h9rhyOU2N/0gDoGfFhkFA0UsiOi5F ar3AlPI9KIlSkmVJw+yDtEJuxNMvtFM2XAVGMfhrOXRfKW8Wos/Lyu/Fzx7v1J6fX5 lkFBUxCU+uzNzlcbCh1jfY+T6vnhUCFSvpR51nU4= Message-ID: <557785E9.6010705@delphij.net> Date: Tue, 09 Jun 2015 17:33:45 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Randy Bush CC: FreeBSD Stable , Allan Jude Subject: Re: ssh install with freebsd-update References: <55777B4D.7040706@delphij.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 00:33:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/09/15 17:21, Randy Bush wrote: >>> # uname -a FreeBSD foux.psg.com 10.1-RELEASE-p10 FreeBSD >>> 10.1-RELEASE-p10 #0: Tue May 12 19:33:13 UTC 2015 >>> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC >>> >>> i386 >>> >>> it's really p11 now >>> >>> if i run freebsd-update install of p11. all looks well until >>> the reboot, when i get >>> >>> Performing sanity check on sshd configuration. Shared object >>> "libgssapi_krb5.so.10" not found, required by "sshd" /etc/rc: >>> WARNING: failed precmd routine for sshd >> >> This is VERY strange! Did you ever have an incomplete upgrade >> from older FreeBSD releases (9.x) on the affected systems? What >> was the version before you update/upgrade to the latest one? > > this is one of a dozen systems upgraded fom 9.3-stable to > 10.1-release p10 using a recipe in > https://wiki.rg.net/wiki/FreeBSD9to10. they all show the same > symptom. My guess is that there was some fetched 'freebsd-update' upgrade data that was not applied, and the freebsd-update install have somehow confused by that. BTW. the supported errata branch is releng/10.1, not release/10.1, which is probably why the svn co failed in step 1. Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.4 (FreeBSD) iQIcBAEBCgAGBQJVd4XpAAoJEJW2GBstM+ns1PkQAICofy0/pvNXSEVnYsHh4pdM PP1XKj4PwzORlujwM1T3pjuyjxDgro7H1Hy+OTl2oU5da2c2pu3AoGGxIN9dkQii 0C4mvTQEv87Z5+AI2sGY3dTchk8QRB9EkUAp1wkENiu2Th/cM7Kgt0MA66UfAd6U Gc4QxSFEu681gPBUQeTapUR4bC6NG4++0yBrFOtGZBiLA8IeSL+Y1uCcpupjMZJ5 qzYQsChFw0f47/WC05ZjfBbwB3ckuDJnN6G+GKRz7tWuQCRSRqGWqEMzrHTiOcvH +dXW++4h8rb6nQFzPPCTaAJP9YvlvyHMumUDN52Lm4lNxMWFklHYe8AfF4f8kbU/ r7yZgmEjwBo2dN1hQnylvn9cwEaRpn/mNYYwjW3ih90HrINmMFXfrcQyD3I2WfLe evLZoMdoJ1dJrq/9h3B0Ak7NAfoInXKVfEVHZ1arOGFmXhqbfIlVbzxrlfe5rxaT 3Vi5jL+3n4EgO/X3Fn3dWAH6Y4jf4a3OopA1h+peBEuCJWVFkR+loYsCr9g27s+R PQBjrpiUnGYSa8WkFnK5XYTUcTVVdKJ+0XevTKnjZ44LaPJkj599fo92E5gqWUfe eoqTaxPly/VTFqInpiR3ARG4Mmfot7UxdQv/rG6E4c3boWIV9P06JdQKocUnT2vO gzSOOPm/aCsvq6TZju0q =dsJf -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 00:45:05 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9ED1F4E8 for ; Wed, 10 Jun 2015 00:45:05 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D66F1910 for ; Wed, 10 Jun 2015 00:45:05 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z2U8b-0001xe-Kw; Wed, 10 Jun 2015 00:45:02 +0000 Date: Tue, 09 Jun 2015 17:44:59 -0700 Message-ID: From: Randy Bush To: Xin Li Cc: FreeBSD Stable , Allan Jude Subject: Re: ssh install with freebsd-update In-Reply-To: <557785E9.6010705@delphij.net> References: <55777B4D.7040706@delphij.net> <557785E9.6010705@delphij.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 00:45:05 -0000 > My guess is that there was some fetched 'freebsd-update' upgrade data > that was not applied, and the freebsd-update install have somehow > confused by that. any idea on how i can make it fresh? our suspicion is that we caught the frebsd-update repo on a bad day and poisoned all the systems. > BTW. the supported errata branch is releng/10.1, not release/10.1, > which is probably why the svn co failed in step 1. sorry /usr/src# svn info Path: . Working Copy Root Path: /usr/src URL: https://svn0.us-west.freebsd.org/base/releng/10.1 Relative URL: ^/releng/10.1 Repository Root: https://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 284195 Node Kind: directory Schedule: normal Last Changed Author: delphij Last Changed Rev: 284193 Last Changed Date: 2015-06-09 22:13:25 +0000 (Tue, 09 Jun 2015) randy From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 01:00:36 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDED087A for ; Wed, 10 Jun 2015 01:00:36 +0000 (UTC) (envelope-from nick.frampton@akips.com) Received: from mail.akips.com (mail.akips.com [65.19.130.19]) by mx1.freebsd.org (Postfix) with ESMTP id CB3C11BCF for ; Wed, 10 Jun 2015 01:00:36 +0000 (UTC) (envelope-from nick.frampton@akips.com) Received: from [10.1.8.7] (CPE-120-146-191-2.static.qld.bigpond.net.au [120.146.191.2]) by mail.akips.com (Postfix) with ESMTPSA id 45ECF13D71 for ; Wed, 10 Jun 2015 10:55:18 +1000 (EST) Message-ID: <55778AF4.3030701@akips.com> Date: Wed, 10 Jun 2015 10:55:16 +1000 From: Nick Frampton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: FreeBSD Errata Notice FreeBSD-EN-15:06.file References: <201506092239.t59MdaKR011836@freefall.freebsd.org> In-Reply-To: <201506092239.t59MdaKR011836@freefall.freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on host1.akips.com X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 01:00:37 -0000 Pardon my ignorance, but why was this posted as an EN instead of a SA if it corrects security vulnerabilities? -Nick On 10/06/15 08:39, FreeBSD Errata Notices wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > ============================================================================= > FreeBSD-EN-15:06.file Errata Notice > The FreeBSD Project > > Topic: Version and security update of file(1) and libmagic(3) > > Category: contrib > Module: file > Announced: 2015-06-09 > Affects: All supported versions of FreeBSD. > Corrected: 2015-01-23 18:48:59 UTC (stable/10, 10.1-STABLE) > 2015-06-09 22:13:25 UTC (releng/10.1, 10.1-RELEASE-p11) > 2015-01-23 18:50:36 UTC (stable/9, 9.3-STABLE) > 2015-06-09 22:13:53 UTC (releng/9.3, 9.3-RELEASE-p15) > 2015-05-09 23:53:25 UTC (stable/8, 8.4-STABLE) > 2015-06-09 22:13:53 UTC (releng/8.4, 8.4-RELEASE-p29) > CVE Name: CVE-2014-0207, CVE-2014-3478, CVE-2014-3479, CVE-2014-3480, > CVE-2014-3487, CVE-2014-3538, CVE-2014-3587, CVE-2014-9620, > CVE-2014-9621, CVE-2014-9653 > > For general information regarding FreeBSD Errata Notices and Security > Advisories, including descriptions of the fields above, security > branches, and the following sections, please visit > . > > I. Background > > The file(1) utility attempts to classify file system objects based on > filesystem, magic number and language tests. > > The libmagic(3) library provides most of the functionality of file(1) > and may be used by other applications. > > II. Problem Description > > There are a number of denial of service issues when handling complex > files, for instance Portable Executable (PE) files and ELF files parsing > code with libmagic(3) and in turn file(1). > > III. Impact > > An attacker who can cause file(1) or any other applications using the > libmagic(3) library to be run on a maliciously constructed input can > cause the application to crash or consume excessive CPU resources, > resulting in a denial-of-service. > > IV. Workaround > > System administrators who run file(1) and libmagic(3) against untrusted > files, for instance when running with a mail server's mail scanner, are > advised to configure the scanner in a way so that they do not call file(1) > or libmagic(3) to conduct deep inspection of input files. Most of these > scanners does not really need the in-depth analysis and the file type > determined by libmagic is already sufficient. > > V. Solution > > This errata replaces the base system file(1) and libmagic(3) with the > version 5.22. > > Perform one of the following: > > 1) Upgrade your system to a supported FreeBSD stable or release / security > branch (releng) dated after the correction date. > > 2) To update your present system via a binary patch: > > Systems running a RELEASE version of FreeBSD on the i386 or amd64 > platforms can be updated via the freebsd-update(8) utility: > > # freebsd-update fetch > # freebsd-update install > > 3) To update your present system via a source code patch: > > The following patches have been verified to apply to the applicable > FreeBSD release branches. > > a) Download the relevant patch from the location below, and verify the > detached PGP signature using your PGP utility. > > [FreeBSD 10.1] > # fetch https://security.FreeBSD.org/patches/EN-15:06/file-10.1.patch > # fetch https://security.FreeBSD.org/patches/EN-15:06/file-10.1.patch.asc > # gpg --verify file-10.1.patch.asc > > [FreeBSD 9.3] > # fetch https://security.FreeBSD.org/patches/EN-15:06/file-9.3.patch > # fetch https://security.FreeBSD.org/patches/EN-15:06/file-9.3.patch.asc > # gpg --verify file-9.3.patch.asc > > [FreeBSD 8.4] > # fetch https://security.FreeBSD.org/patches/EN-15:06/file-8.4.patch > # fetch https://security.FreeBSD.org/patches/EN-15:06/file-8.4.patch.asc > # gpg --verify file-8.4.patch.asc > > b) Apply the patch. Execute the following commands as root: > > # cd /usr/src > # patch < /path/to/patch > > c) Recompile the operating system using buildworld and installworld as > described in . > > Restart all deamons using the library, or reboot the system. > > VI. Correction details > > The following list contains the correction revision numbers for each > affected branch. > > Branch/path Revision > - ------------------------------------------------------------------------- > stable/8/ r283135 > releng/8.4/ r284194 > stable/9/ r277593 > releng/9.3/ r284194 > stable/10/ r277592 > releng/10.1/ r284193 > - ------------------------------------------------------------------------- > > To see which files were modified by a particular revision, run the > following command, replacing NNNNNN with the revision number, on a > machine with Subversion installed: > > # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base > > Or visit the following URL, replacing NNNNNN with the revision number: > > > > VII. References > > > > > > > > > > > > > > > > > > > > > > The latest revision of this Errata Notice is available at > https://security.FreeBSD.org/advisories/FreeBSD-EN-15:06.file.asc > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.1.4 (FreeBSD) > > iQIcBAEBCgAGBQJVd2aEAAoJEO1n7NZdz2rnEVQP/2OPfepmvG2/vYrH3bKDHPRi > 12QFfE3Ylr8ctoDQRCBazdxhzLEMxdP3g9icJ0ZbnDWVmFtM9BwDfCrkcYmI6uCt > 0E1usrqHs6qthm4i1UAwRu4v71LM2yllHCaLt/XWxWDXsbI/vA5wkZgfgZK8kZWW > PAiBUuI1bM4pegi+yymgMRoHquoyB0x2jNBKywnb9KT7m8Br9uYnJrCajI6G9HUy > /eQKtefOVQat0trIoOwXS7cIZhLWJlVAKUinBjb2IGHxkWOrUhgXlPCpB4efS0pG > IqEv2gvHpxllgmf+4leqNXYT8R1EUu+3OE6SbN7jV+RwgPc0TNUxC4Bkb6r1LoSH > BRf5FMuVDYAlDKDz4j8NY0v84PpD9d37w7SSBZPiR+Fwn5xs0F4PjsU2c+tPEnVD > Sn1vYkafvC+KXsuJtmd4sqb1zLRdpOGDxruA0VtOKATA1sDa1QZIBTB7w7iZ03f5 > umCpU8p5mo7a9AroavUEZkcpu4w5BptAsgYoBdOeKHhStBtPlXiGpML8zLhj1qnL > hGF6RY2QrhD35C7OIer1ji0F2pEKkFfaeAqkvIXmYJaH+KQeIrEdt+ki2GStW1m9 > OdL79RMreVGE1DuX/2puBxKcMsQR+fas4L4uGi46MDXXMeV0LKJHiAT2twJlDOL/ > mc3UcOeMcAfOkINcpGuD > =8/lF > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-announce@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-announce > To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org" > -- Founder, CTO www.akips.com From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 01:55:30 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 50442403 for ; Wed, 10 Jun 2015 01:55:30 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 39F201918 for ; Wed, 10 Jun 2015 01:55:29 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id A33361844A; Tue, 9 Jun 2015 18:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1433901329; x=1433915729; bh=NGc0YeAq8RkQIyePMuiOQvIUx2jaoGr41NCLr3uAU4o=; h=Date:From:Reply-To:To:Subject:References:In-Reply-To; b=2DoVAtZtUU+xlhQdHoGuSkGzIWp6xxGSnkZu9X4ZbxhvZG4+ENF/lqWByHcboR893 h83XkDWMDd/dFhTqlS1P8hTXYbcvuc047rA15KVAvY+6xJqs2OpLBYELh3ov6d9PTZ eSW8Czaa1fLTdD/iqNrMPEaSRBg4ScPH6mNNNJHw= Message-ID: <55779911.6070304@delphij.net> Date: Tue, 09 Jun 2015 18:55:29 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Nick Frampton , freebsd-stable@freebsd.org Subject: Re: FreeBSD Errata Notice FreeBSD-EN-15:06.file References: <201506092239.t59MdaKR011836@freefall.freebsd.org> <55778AF4.3030701@akips.com> In-Reply-To: <55778AF4.3030701@akips.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 01:55:30 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/09/15 17:55, Nick Frampton wrote: > Pardon my ignorance, but why was this posted as an EN instead of a > SA if it corrects security vulnerabilities? We do not generally issue SA's for local DoS issues (historically there were some, but in principal we don't do that). Cheers, - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.4 (FreeBSD) iQIcBAEBCgAGBQJVd5kRAAoJEJW2GBstM+ns//AP/2FjI1k6NnFuRWLkdRQLQPvK gQr0ZwEZDnm/78gL/Sm3dR1bVt8VWmGHJyCfQrGEVISy7uvETaaodOoRNE4ZjAg+ RHoszk6s6ufXkjr2qwXI4VDUHvjZeru7WfguqKfGn2499WJOzRBbzWnTe/e59SFb +K99Smci0cXCzehahO/WstM1McPg1LDsEo3/AVAZWrV56Xb/F7DOz1uxIiESprlp xUoaeX5KhUKoME0m0RN48IpOW3tbWjyO6go5sX3PpTZg/CjFxktIN00vTKFOLs7z MhogJD+mI8K4t8Pw5kcfTeAmcCtc77EMi/YtzpCKwzYhltGIsCQDZ2rLig4yDvOv EAw/mwYh0NVXOQj/tUg9Uf0EwhxQ13jAfkhfOcNVGl+Qt3tbbH0QDXiMEOtLadZC PRqb/IdwEyBQKxKrg82mqZmJ67ZWC22EbqcrW6Czie4q6lWk3qF4CeuBp4D1tIuJ RDMO4A4iXAhM1A7h9zVn07SUC3Qv9b1JrcGUN1Pv8O0jn2KIALpF+fLqVBEtYEoX //IUbQ1BYyfIO33SiqVPaB6hsKLvr5zdmKHdYwr2FHr6e03L66Z+GxIjn6OnIT1e nMPDmphl27/St16c6PouuzS+WQbyDlVZrNogVzslGGSyNBwMFJjALrNjKfZTkSLD slx1EYwywyX2omdCn89R =ffrR -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 07:18:27 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DEF1BC6 for ; Wed, 10 Jun 2015 07:18:27 +0000 (UTC) (envelope-from rt-bounces@openit.de) Received: from smtp.openit.de (smtp.openit.de [IPv6:2001:aa8:fffd:2::179]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "smtp.openit.de", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A6EA91390 for ; Wed, 10 Jun 2015 07:18:26 +0000 (UTC) (envelope-from rt-bounces@openit.de) Received: from localhost (localhost [127.0.0.1]) by smtp.openit.de (Postfix) with ESMTP id 35D801FCC04 for ; Wed, 10 Jun 2015 09:18:22 +0200 (CEST) X-Virus-Scanned: Scanned by OpenIT: amavisd-new at mail-smtp01.openit.de Received: from smtp.openit.de ([127.0.0.1]) by localhost (mail-smtp01.openit.de [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DyIrpkMqUFjs for ; Wed, 10 Jun 2015 09:18:21 +0200 (CEST) Received: from rt.openit.de (rt.pub.openit.de [217.69.65.47]) by smtp.openit.de (Postfix) with ESMTP id 7E3A01FCC0F for ; Wed, 10 Jun 2015 09:18:21 +0200 (CEST) Received: by rt.openit.de (Postfix, from userid 500) id 7E82F45D24; Wed, 10 Jun 2015 09:18:21 +0200 (CEST) Subject: [OpenIT #136287] [FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-15:07.zfs From: "OpenIT Customer Support (ISP) via RT" Reply-To: support@openit.de In-Reply-To: <201506092239.t59MddQF011849@freefall.freebsd.org> References: <201506092239.t59MddQF011849@freefall.freebsd.org> Message-ID: X-RT-Loop-Prevention: OpenIT X-RT-Ticket: OpenIT #136287 X-Managed-BY: RT 4.2.10 (http://www.bestpractical.com/rt/) X-RT-Originator: freebsd-stable@freebsd.org Auto-Submitted: auto-replied To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Wed, 10 Jun 2015 09:18:21 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 07:18:27 -0000 Sehr geehrte Damen und Herren, diese Nachricht wurde als Antwort auf Ihre Support-Anfrage bezüglich "[FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-15:07.zfs" automatisch erstellt. Eine Antwort auf diese Nachricht ist nicht notwendig. Ihrer Support-Anfrage wurde die Bezeichnung [OpenIT #136287] zugeordnet. Wenn Sie zu dieser Support-Anfrage eine weitere E-Mail senden möchten, sollte der Betreff den Text [OpenIT #136287] enthalten, damit Ihre Nachricht korrekt zugeordnet werden kann. Mit freundlichen Grüßen, Ihr OpenIT Support-Team ------------------------------------------------------------------------- Greetings, This message has been automatically generated in response to the creation of a trouble ticket regarding: "[FreeBSD-Announce] FreeBSD Errata Notice FreeBSD-EN-15:07.zfs", a summary of which appears below. There is no need to reply to this message right now. Your ticket has been assigned an ID of [OpenIT #136287]. Please include the string [OpenIT #136287] in the subject line of all future correspondence about this issue. To do so, you may reply to this message. Thank you, your OpenIT Support-Team ------------------------------------------------------------------------- -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 ============================================================================= FreeBSD-EN-15:07.zfs Errata Notice The FreeBSD Project Topic: ZFS Reliability Improvements Category: contrib Module: zfs Announced: 2015-06-09 Affects: FreeBSD 10.1 and later Corrected: 2014-12-05 00:32:33 UTC (stable/10, 10.1-STABLE) 2015-06-09 22:13:25 UTC (releng/10.1, 10.1-RELEASE-p11) For general information regarding FreeBSD Errata Notices and Security Advisories, including descriptions of the fields above, security branches, and the following sections, please visit . I. Background ZFS is one of several filesystems available on FreeBSD. ZFS on FreeBSD supports TRIM/UNMAP which helps flash based storage medium to maintain peek performance. ZFS uses different layers of disk cache to speed up read and write operations, and supports second level ARC (L2ARC) which can be used as a second layer cache, which provides storage for less frequently accessed data that would not fit into RAM but still accessed often, providing optimal cost for performance. ZFS supports compression in L2ARC data which optimizes its space efficiency. II. Problem Description When the ZFS filesystem on a file backed pool is used with TRIM support enabled, which is the default, ZIO_TYPE_FREE requests where incorrectly processed as a write request. When the ZFS filesystem is using L2ARC and when L2ARC compression is used, the compression buffer are not properly released sometimes. III. Impact The first problem will panic the system when it happens. The second problem will exhibit as a memory leak, which would lead to performance degradation and eventually a memory overflow, which would lead to a panic. IV. Workaround The first issue can be mitigated by disabling TRIM for ZFS using the loader option vfs.zfs.trim.enabled=0. The second issue can be mitigated by disabling L2ARC. V. Solution Perform one of the following: 1) Upgrade your system to a supported FreeBSD stable or release / security branch (releng) dated after the correction date. 2) To update your present system via a binary patch: Systems running a RELEASE version of FreeBSD on the i386 or amd64 platforms can be updated via the freebsd-update(8) utility: # freebsd-update fetch # freebsd-update install 3) To update your present system via a source code patch: The following patches have been verified to apply to the applicable FreeBSD release branches. a) Download the relevant patch from the location below, and verify the detached PGP signature using your PGP utility. # fetch https://security.FreeBSD.org/patches/EN-15:07/zfs.patch # fetch https://security.FreeBSD.org/patches/EN-15:07/zfs.patch.asc # gpg --verify zfs.patch.asc b) Apply the patch. Execute the following commands as root: # cd /usr/src # patch < /path/to/patch c) Recompile your kernel as described in and reboot the system. VI. Correction details The following list contains the correction revision numbers for each affected branch. Branch/path Revision - ------------------------------------------------------------------------- stable/10/ r275492 releng/10.1/ r284193 - ------------------------------------------------------------------------- To see which files were modified by a particular revision, run the following command, replacing NNNNNN with the revision number, on a machine with Subversion installed: # svn diff -cNNNNNN --summarize svn://svn.freebsd.org/base Or visit the following URL, replacing NNNNNN with the revision number: VII. References The latest revision of this Errata Notice is available at https://security.FreeBSD.org/advisories/FreeBSD-EN-15:07.zfs.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.4 (FreeBSD) iQIcBAEBCgAGBQJVd2mmAAoJEO1n7NZdz2rnNCQQAJzkz6y4TkdJ5Qn+cj5Z/VdV LTgFnETzhHTck4TwE6xw+iRRRkwFnIC6srCJZt+ueMp1DPILTOK0WivFn1HLsHlN nhnCjhhqpOsHyuYGPyH3ca0S5ObA9F+yE7uMtIbacYTgQHCx1lmjasNY6c1zc39v 6DkdP+qejMa4X2Fro7Glf6aHN+nV6hNTrXEbOlncf3sKqVdGoW6xZ0E+JCBELYnl ojVUTbnrNmdj/syIDoo2Wrl0h7xTaIc9rjAtDqKJ45F2z7E156PRYf3/0SaRJOdU w+NFr0YU87Ho5o+X5YkovpGi1Da+nTBSXkkkwGe+1eRrsbvFG5Imi0c100ZMxG9L TXq8Ny/fIb6IIJftrwIDlTqLiB2vmiZB4NNh9BrpxAvII3dON0uUexvpp4I6mABE s4VeSgYLGIOTq8wEVVtoPWNVfAEjMZfn7v9nkviItdY4sX8S+crxiHeFeVc8Uko5 bBH8ddXL6x55DG9qzWK/owaN7oSbbVSVPRAxghpdppAAeE8SUPANRn/RE0pZCx/a dquTVZlIR87BLFCK5KURi2B1PH7QmzZXzMFHDyOfKQtkOmnqeZqlYbaVM6zZ54ZP a11CmVKPu/pyviO49OBH/SFDkzVuwoqsqR7NfqZd4mj9kIbqxAxjxgxi3n3bA96l YNNoIXxML3p8aRyS3UOZ =7KJF -----END PGP SIGNATURE----- _______________________________________________ freebsd-announce@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-announce To unsubscribe, send any mail to "freebsd-announce-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 07:49:43 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 906D81EC for ; Wed, 10 Jun 2015 07:49:43 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4DD501B03 for ; Wed, 10 Jun 2015 07:49:42 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id 212082846E; Wed, 10 Jun 2015 09:49:34 +0200 (CEST) Received: from illbsd.quip.test (ip-89-177-50-74.net.upcbroadband.cz [89.177.50.74]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id CA64628428; Wed, 10 Jun 2015 09:49:32 +0200 (CEST) Message-ID: <5577EC0C.3060500@quip.cz> Date: Wed, 10 Jun 2015 09:49:32 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:35.0) Gecko/20100101 Firefox/35.0 SeaMonkey/2.32 MIME-Version: 1.0 To: d@delphij.net, freebsd-stable@freebsd.org Subject: Re: FreeBSD Errata Notice FreeBSD-EN-15:06.file References: <201506092239.t59MdaKR011836@freefall.freebsd.org> <55778AF4.3030701@akips.com> <55779911.6070304@delphij.net> In-Reply-To: <55779911.6070304@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 07:49:43 -0000 Xin Li wrote on 06/10/2015 03:55: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 06/09/15 17:55, Nick Frampton wrote: >> Pardon my ignorance, but why was this posted as an EN instead of a >> SA if it corrects security vulnerabilities? > > We do not generally issue SA's for local DoS issues (historically > there were some, but in principal we don't do that). FYI these two new EN are not listed on this page https://www.freebsd.org/security/notices.html (if this site is geo-mirrored, I am accessing it from central europe) Miroslav Lachman From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 09:20:14 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C93D4251; Wed, 10 Jun 2015 09:20:14 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from mail.pingpong.net (mail2.pingpong.net [79.136.116.202]) by mx1.freebsd.org (Postfix) with ESMTP id 5150C10C0; Wed, 10 Jun 2015 09:20:14 +0000 (UTC) (envelope-from girgen@FreeBSD.org) Received: from [10.0.0.158] (citron2.pingpong.net [195.178.173.68]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pingpong.net (Postfix) with ESMTPSA id 4D8249F22; Wed, 10 Jun 2015 11:20:13 +0200 (CEST) Subject: Re: wrong patch number in releng/10.1? Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_AE24063D-7866-4FCD-92BC-0CF429381FB1"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.5b6 From: Palle Girgensohn In-Reply-To: Date: Wed, 10 Jun 2015 11:20:12 +0200 Cc: freebsd-stable@FreeBSD.org Message-Id: <82E830BE-8B28-479A-8CBE-78D192592E26@FreeBSD.org> References: To: delphij@FreeBSD.org X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 09:20:15 -0000 --Apple-Mail=_AE24063D-7866-4FCD-92BC-0CF429381FB1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Also # uname -a FreeBSD pingpongdb 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May = 13 06:54:13 UTC 2015 = root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # uptime 2:18am up 36 mins, 4 users, load averages: 0,08 0,14 0,10 # ls -lrt /boot/kernel/kernel /boot/kernel/*zfs* -r-xr-xr-x 2 root wheel 21160449 10 Jun 01:36 /boot/kernel/kernel -r-xr-xr-x 2 root wheel 2320144 10 Jun 01:36 /boot/kernel/zfs.ko -r-xr-xr-x 1 root wheel 19103144 10 Jun 01:36 = /boot/kernel/zfs.ko.symbols # strings /boot/kernel/kernel|grep 10.1-RELEASE @(#)FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 10.1-RELEASE-p10 It seems to me the verions numbering is not correct, but the patch *is* = there, it should be 10.1-p11, right? > 10 jun 2015 kl. 11:01 skrev Palle Girgensohn : >=20 > Hi, >=20 > It seems the patch level in the UPDATING document is bad in = releng/10.1, it is p29 which is the patch level for 8.4? >=20 > Palle >=20 > = ------------------------------------------------------------------------ > r284193 | delphij | 2015-06-10 00:13:25 +0200 (Ons, 10 Jun 2015) | 8 = lines >=20 > Update base system file(1) to 5.22 to address multiple denial of > service issues. [EN-15:06] >=20 > Improve reliability of ZFS when TRIM/UNMAP and/or L2ARC is used. > [EN-15:07] >=20 > Approved by: so >=20 > = ------------------------------------------------------------------------ >=20 > But the UPDATING says: >=20 > 20150609: p29 FreeBSD-EN-15:06.file > FreeBSD-EN-15:07.zfs >=20 > Updated base system file(1) to 5.22 to address multiple denial > of service issues. [EN-15:06] >=20 > Improved reliability of ZFS when TRIM/UNMAP and/or L2ARC is = used. > [EN-15:07] >=20 > 20150513: p10 FreeBSD-EN-15:04.freebsd-update > FreeBSD-EN-15:05.ufs >=20 > Fix bug with freebsd-update(8) that does not ensure the = previous > upgrade was completed. [EN-15:04] >=20 > Fix deadlock on reboot with UFS tuned with SU+J. [EN-15:05] >=20 >=20 >=20 >=20 --Apple-Mail=_AE24063D-7866-4FCD-92BC-0CF429381FB1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJVeAFMAAoJEIhV+7FrxBJDAIcIAJNoVRmY/wHh0ZlGcL8/xY3R lOA2CKT7jqthP/rviXTIUaqF9dM/9NLoZp1v4X39ft2GXlIkkbPMagKs6gRKRdID UR4t6NLtbJvXNfEmyBS4PdGRCslrvyoDriHhGyke/wD13KxPL1biMxx8iH+spKoo 7cpEtRW8vSa3DjDa0ZgD4spV/Xxyl2jQaHxirNcgMacQmwk/DxXK5A7s0FjPoHeN VcklAguYLFZZpr5HYmiL0kEkwzyD/d25+XWqZ2poUHpAYUs1CX+W3lAn/VOW6PKQ 3JTvVtmUaD5la5/xY/lTYau+v+BfG827OvDNGA/1LHeLHgaEzXjwlCeTVBjeddA= =TFEf -----END PGP SIGNATURE----- --Apple-Mail=_AE24063D-7866-4FCD-92BC-0CF429381FB1-- From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 09:31:35 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 953638C6 for ; Wed, 10 Jun 2015 09:31:35 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EF4B15C1 for ; Wed, 10 Jun 2015 09:31:34 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by wifx6 with SMTP id x6so40928729wif.0 for ; Wed, 10 Jun 2015 02:31:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=M8y3AMoQmVyD4gi3zTWqcqIE5YohFVSH6mNp6xf5dHg=; b=XlhVDm+kd2ILGBfo/pMiw2dxbNT65dFWMAoOSBsVtt2sNf/twEVAjpEyJF/ycPtnn5 N21JgElpBRC7CU8C99bUxaWVJOd9eAIAkNlxBrPQ7VcogfU8x1s+tMtT6tLV4FldjqYE xOeubB3zMcKex9Q9RtE3y+xY9gOx7hu8XdWtzSPROWZ29GIDAyxVbICdSl6PNxqAHc5n 9DdInhAi/YcLcebgR2ryflrxLUD1jGAU7CKRGY7puztwiFpfHkpAo5aL3l9xgJr8WRTI 0ymYOLTsMEfzMysFsSQ9Sf2SpxYMdwtYEtrjoVA/+G2TOHG9y0FyhDOmqAiQsgc5Cgxz zvZg== X-Gm-Message-State: ALoCoQlLRLD7Fsg8mAEc6nEZ6HvB/9kOlccxMa5DGbZ7nqjb3wMAGfVJHwJhvLzSeJ9FsyDD82Q8 X-Received: by 10.194.237.34 with SMTP id uz2mr4499576wjc.155.1433928686888; Wed, 10 Jun 2015 02:31:26 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id m2sm6991854wiy.7.2015.06.10.02.31.25 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2015 02:31:25 -0700 (PDT) Message-ID: <55780401.7050205@multiplay.co.uk> Date: Wed, 10 Jun 2015 10:31:45 +0100 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: wrong patch number in releng/10.1? References: <82E830BE-8B28-479A-8CBE-78D192592E26@FreeBSD.org> In-Reply-To: <82E830BE-8B28-479A-8CBE-78D192592E26@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 09:31:35 -0000 What does the following say when run from your source directory: grep BRANCH sys/conf/newvers.sh Regards Steve On 10/06/2015 10:20, Palle Girgensohn wrote: > Also > > # uname -a > FreeBSD pingpongdb 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > # uptime > 2:18am up 36 mins, 4 users, load averages: 0,08 0,14 0,10 > # ls -lrt /boot/kernel/kernel /boot/kernel/*zfs* > -r-xr-xr-x 2 root wheel 21160449 10 Jun 01:36 /boot/kernel/kernel > -r-xr-xr-x 2 root wheel 2320144 10 Jun 01:36 /boot/kernel/zfs.ko > -r-xr-xr-x 1 root wheel 19103144 10 Jun 01:36 /boot/kernel/zfs.ko.symbols > # strings /boot/kernel/kernel|grep 10.1-RELEASE > @(#)FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 > FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 > 10.1-RELEASE-p10 > > It seems to me the verions numbering is not correct, but the patch *is* there, it should be 10.1-p11, right? > >> 10 jun 2015 kl. 11:01 skrev Palle Girgensohn : >> >> Hi, >> >> It seems the patch level in the UPDATING document is bad in releng/10.1, it is p29 which is the patch level for 8.4? >> >> Palle >> >> ------------------------------------------------------------------------ >> r284193 | delphij | 2015-06-10 00:13:25 +0200 (Ons, 10 Jun 2015) | 8 lines >> >> Update base system file(1) to 5.22 to address multiple denial of >> service issues. [EN-15:06] >> >> Improve reliability of ZFS when TRIM/UNMAP and/or L2ARC is used. >> [EN-15:07] >> >> Approved by: so >> >> ------------------------------------------------------------------------ >> >> But the UPDATING says: >> >> 20150609: p29 FreeBSD-EN-15:06.file >> FreeBSD-EN-15:07.zfs >> >> Updated base system file(1) to 5.22 to address multiple denial >> of service issues. [EN-15:06] >> >> Improved reliability of ZFS when TRIM/UNMAP and/or L2ARC is used. >> [EN-15:07] >> >> 20150513: p10 FreeBSD-EN-15:04.freebsd-update >> FreeBSD-EN-15:05.ufs >> >> Fix bug with freebsd-update(8) that does not ensure the previous >> upgrade was completed. [EN-15:04] >> >> Fix deadlock on reboot with UFS tuned with SU+J. [EN-15:05] >> >> >> >> From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 10:23:48 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D696D8D4 for ; Wed, 10 Jun 2015 10:23:48 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9195111DA for ; Wed, 10 Jun 2015 10:23:48 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1Z2dAf-000Ou2-M1; Wed, 10 Jun 2015 12:23:45 +0200 Date: Wed, 10 Jun 2015 12:23:45 +0200 From: Kurt Jaeger To: Steven Hartland Cc: freebsd-stable@freebsd.org Subject: Re: wrong patch number in releng/10.1? Message-ID: <20150610102345.GN49099@home.opsec.eu> References: <82E830BE-8B28-479A-8CBE-78D192592E26@FreeBSD.org> <55780401.7050205@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55780401.7050205@multiplay.co.uk> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 10:23:48 -0000 Hi! I see the same: uname says: 10.1p10 > What does the following say when run from your source directory: > > grep BRANCH sys/conf/newvers.sh BRANCH="RELEASE-p11" -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 10:28:00 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 67CC3AD9 for ; Wed, 10 Jun 2015 10:28:00 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 00D9A1206 for ; Wed, 10 Jun 2015 10:27:59 +0000 (UTC) (envelope-from killing@multiplay.co.uk) Received: by wgez8 with SMTP id z8so32176827wge.0 for ; Wed, 10 Jun 2015 03:27:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=0HYvLrSPOkGkYaES+eZjl0RA2SiEVpHZi6YjZXeWiuY=; b=ea1lw35NToB8h6Ura385tI0BYsP+YPxGLFtvvUtC/nQYyNy4nlFbmPzi+PEWHxXOFr YsAapKAfXaKuJhiXI/hhkdpZSFpi/L7AslWgXi4fvM8JlMtsoSP0ZbctzEzUz0T8F/Ye 6vJfpMidlCCApebs0o24xmj2sNRwetDJNoQ+FheMHel71tyT4MvKUHhj9H1Ffof7zmJN gALtHJiySRgW1ZChpeGCoDbeArPQR2q1jRE1P5NmEfF3veWzOKn26yeq50Dix/Rw4hg1 VUH+Ty5WeIWHXXfvzIMfWJQLz9q0zGOmt9CyfEgwZShGVNRzfzGWMALBIdOdMSbKdwLh l97A== X-Gm-Message-State: ALoCoQkmRi5XqhCo4EcMjdf1rdyqlTyZaIl9QIyDGFCxIzCtmYBI6RfY60SmoRCVsMMlAsX+U92F X-Received: by 10.194.179.200 with SMTP id di8mr5044276wjc.56.1433932072526; Wed, 10 Jun 2015 03:27:52 -0700 (PDT) Received: from [10.10.1.68] (82-69-141-170.dsl.in-addr.zen.co.uk. [82.69.141.170]) by mx.google.com with ESMTPSA id ei8sm13819557wjd.32.2015.06.10.03.27.51 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2015 03:27:51 -0700 (PDT) Message-ID: <55781141.2070005@multiplay.co.uk> Date: Wed, 10 Jun 2015 11:28:17 +0100 From: Steven Hartland User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kurt Jaeger CC: freebsd-stable@freebsd.org Subject: Re: wrong patch number in releng/10.1? References: <82E830BE-8B28-479A-8CBE-78D192592E26@FreeBSD.org> <55780401.7050205@multiplay.co.uk> <20150610102345.GN49099@home.opsec.eu> In-Reply-To: <20150610102345.GN49099@home.opsec.eu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 10:28:00 -0000 You kernel hasn't been rebuilt then. On 10/06/2015 11:23, Kurt Jaeger wrote: > Hi! > > I see the same: uname says: 10.1p10 > >> What does the following say when run from your source directory: >> >> grep BRANCH sys/conf/newvers.sh > BRANCH="RELEASE-p11" > From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 10:34:57 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2764D97 for ; Wed, 10 Jun 2015 10:34:57 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5BDC914AD for ; Wed, 10 Jun 2015 10:34:57 +0000 (UTC) (envelope-from lists@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.85 (FreeBSD)) (envelope-from ) id 1Z2dLU-000PJY-DX; Wed, 10 Jun 2015 12:34:56 +0200 Date: Wed, 10 Jun 2015 12:34:56 +0200 From: Kurt Jaeger To: Steven Hartland Cc: freebsd-stable@freebsd.org Subject: Re: wrong patch number in releng/10.1? Message-ID: <20150610103456.GO49099@home.opsec.eu> References: <82E830BE-8B28-479A-8CBE-78D192592E26@FreeBSD.org> <55780401.7050205@multiplay.co.uk> <20150610102345.GN49099@home.opsec.eu> <55781141.2070005@multiplay.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55781141.2070005@multiplay.co.uk> X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 10:34:57 -0000 Hi! > You kernel hasn't been rebuilt then. Yes, but normally, freebsd-update provides me with an updated kernel. The update provides (among other stuff): /boot/kernel/zfs.ko /boot/kernel/zfs.ko.symbols /lib/libzpool.so.2 so it does not touch the value uname reports until a new kernel is built. It's surprising, but I can live with that. -- pi@opsec.eu +49 171 3101372 5 years to go ! From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 10:43:12 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6DF21F66 for ; Wed, 10 Jun 2015 10:43:12 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25A1E16F8 for ; Wed, 10 Jun 2015 10:43:11 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3m64fM4W4CzblV; Wed, 10 Jun 2015 12:43:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1433932985; x=1435747386; bh=c6tYb9roWJkEjcoZELySG/7sWzvje6Fw93ISruYi8w4=; b= Q4e1I/nuc4bxH9RyMBeZ+0BJjuy4XLj7onel1BWL/pTErmJHmTt202qAt1m/zq9A K8aBrc+uHo8VoMaBWFPkH1/Z5yrDs9b1GhMg4QEouqzibAejIZjkpYfKlfkUx0+e LStDFRdOIURg9nrmDWjWQMs9IeW3sWKVXeD3wzkdkLw= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id XBsKJpUVub7K; Wed, 10 Jun 2015 12:43:05 +0200 (CEST) Received: from marvin.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Wed, 10 Jun 2015 12:43:05 +0200 (CEST) Message-ID: <557814B9.9010008@madpilot.net> Date: Wed, 10 Jun 2015 12:43:05 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kurt Jaeger , Steven Hartland CC: freebsd-stable@freebsd.org Subject: Re: wrong patch number in releng/10.1? References: <82E830BE-8B28-479A-8CBE-78D192592E26@FreeBSD.org> <55780401.7050205@multiplay.co.uk> <20150610102345.GN49099@home.opsec.eu> <55781141.2070005@multiplay.co.uk> <20150610103456.GO49099@home.opsec.eu> In-Reply-To: <20150610103456.GO49099@home.opsec.eu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 10:43:12 -0000 On 06/10/15 12:34, Kurt Jaeger wrote: > Hi! > >> You kernel hasn't been rebuilt then. > > Yes, but normally, freebsd-update provides me with an updated kernel. > > The update provides (among other stuff): > > /boot/kernel/zfs.ko > /boot/kernel/zfs.ko.symbols > /lib/libzpool.so.2 > > so it does not touch the value uname reports until a new kernel is built. > > It's surprising, but I can live with that. It's always been like this with binary updates AFAIK. The kernel binary gets updated only if needed. There is the freebsd-version(1) command to get information about the userland version, which should always be equal or bigger than the kernel version. -- Guido Falsi From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 12:33:03 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8BD3C9F for ; Wed, 10 Jun 2015 12:33:03 +0000 (UTC) (envelope-from shen.elf@gmail.com) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 80B581322 for ; Wed, 10 Jun 2015 12:33:03 +0000 (UTC) (envelope-from shen.elf@gmail.com) Received: by iebgx4 with SMTP id gx4so33170172ieb.0 for ; Wed, 10 Jun 2015 05:33:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=l9ajh13pF+WthHfPAENoF9siUggNzNU49S3N1ux7UXM=; b=BQ0fzIFBARPtMjyueptrL8juKEpDc9RY2DFFGYFr2KClLYgE+W4ZF7W3NCr3QbzyK8 Ykgw2jbZXwYe5QXn9tE/YLZEKt5vJCARGYXrPJq8sadZYm9s52z9zmjGnHNOyaeFr1Cn u8ys/bn3yf/rNC212AqkbnjxrjSAsckuRqlSOtmOo6PMJDPMr55EV7RsPDU+HZkfwrhc 4zbInxulaRbXK1OqjNfVm2r3WWckbKattMlmHKalo0NK075SIqhtJIbS5Knm5cZ+yXA7 mcX2BNM3gZ12DgH41Zs164UthTlpIdoDGpSFdGodGac79jTV5R1F8Ojgyj+Avdg1r6j5 2edg== MIME-Version: 1.0 X-Received: by 10.107.10.151 with SMTP id 23mr3790825iok.89.1433939582802; Wed, 10 Jun 2015 05:33:02 -0700 (PDT) Received: by 10.107.15.157 with HTTP; Wed, 10 Jun 2015 05:33:02 -0700 (PDT) Date: Wed, 10 Jun 2015 20:33:02 +0800 Message-ID: Subject: High Interrupt rate since r279961 on STABLE/10 branch From: Yanhui Shen To: henry.hu.sh@gmail.com Cc: freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 12:33:03 -0000 Hi, I noticed the interrupt rate of my FreeBSD system is very high (~35%) after upgrade from r279138 to r284205. To find out which revision cause this problem, I used a binary search manner and compiled the kernel 11 times. Finally I located to r279961, the interruption rate is abnormal since this revision. Do you have any idea about this issue? ( I'm temporarily using r279958 kernel with r284205 base system, everything is fine.) -------------------------------- Device: ThinkPad R400 (Product ID: 278225C) CPU: Intel Core 2 Duo processor T6570 (2.1 GHz) GPU: Intel Integrated Graphics 4500MHD Output of "vmstat -i" with r284205 kernel (abnormal): interrupt total rate irq1: atkbd0 1607 1 irq9: acpi0 131958 104 irq12: psm0 4281 3 irq16: uhci3 239899376 189643 irq20: hpet0 uhci0 1426118 1127 irq21: uhci1 40315 31 irq23: ehci0 33 0 irq256: vgapci0 6059 4 irq257: em0 49220 38 irq258: hdac0 62 0 irq260: ahci0:ch0 17217 13 irq261: ahci0:ch1 23 0 Total 241576269 190969 Output of "vmstat -i" with r279958 kernel (normal): interrupt total rate irq1: atkbd0 48155 3 irq9: acpi0 1581468 105 irq12: psm0 209484 13 irq19: ehci1 48099 3 irq20: hpet0 uhci0 17385585 1156 irq21: uhci1 680884 45 irq23: ehci0 31 0 irq256: vgapci0 2611430 173 irq257: em0 1342009 89 irq258: hdac0 602220 40 irq260: ahci0:ch0 236313 15 irq261: ahci0:ch1 27 0 Total 24745705 1646 The revision: https://svnweb.freebsd.org/base?view=revision&revision=279961 -------------------------------- Best regards, Yanhui Shen From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 16:24:27 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2073D25B for ; Wed, 10 Jun 2015 16:24:27 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id F38F71622 for ; Wed, 10 Jun 2015 16:24:26 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.65.209.146] (unknown [137.122.64.54]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 72B0399CE; Wed, 10 Jun 2015 16:24:20 +0000 (UTC) Message-ID: <557864B3.1090909@freebsd.org> Date: Wed, 10 Jun 2015 12:24:19 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: d@delphij.net, Randy Bush , FreeBSD Stable CC: Allan Jude Subject: Re: ssh install with freebsd-update References: <55777B4D.7040706@delphij.net> In-Reply-To: <55777B4D.7040706@delphij.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 16:24:27 -0000 On 06/09/2015 19:48, Xin Li wrote: > Hi, Randy, > > On 06/09/15 16:34, Randy Bush wrote: >> # uname -a FreeBSD foux.psg.com 10.1-RELEASE-p10 FreeBSD >> 10.1-RELEASE-p10 #0: Tue May 12 19:33:13 UTC 2015 >> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC >> i386 > >> it's really p11 now > >> if i run freebsd-update install of p11. all looks well until the >> reboot, when i get > >> Performing sanity check on sshd configuration. Shared object >> "libgssapi_krb5.so.10" not found, required by "sshd" /etc/rc: >> WARNING: failed precmd routine for sshd > > This is VERY strange! Did you ever have an incomplete upgrade from > older FreeBSD releases (9.x) on the affected systems? What was the > version before you update/upgrade to the latest one? > > Cheers, > What is the output of: uname -KU I am guessing your kernel is new, and your userland is old, as Xin Li said -- Allan Jude From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 16:38:20 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB51DA53 for ; Wed, 10 Jun 2015 16:38:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 74FA918E4 for ; Wed, 10 Jun 2015 16:38:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by igbsb11 with SMTP id sb11so37657564igb.0 for ; Wed, 10 Jun 2015 09:38:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=2dMg0YEH6w8O2RHVTkS9ncqj9qiSPt/vLv+R3tpAlbc=; b=1GN+Fj4M83KNDQaotx/a5Mb7vekBJCByOwf9t7pBx5kOBv65ZkfgqSISXgznyTfrmc O7IvR4fQIUryB+nAqy2eeHP6/n8ahMwElgo9DmK+PsgGxlEj4cxMMjFV75WrpvNw0UOb f+N6El5eDrga91heRvVMhn2lN13wVIHDx8opiAeZO/bnVaIN0FcCYsdSmvKVPWA+uZJr fY6kCgwXSEU3oT2PPC5OtuLIVOuC46bpmPLoM6MH2u5BKYMtaqPOW++QYtRMlWn8cHNk FyC7eyIgX2uophTmIzxkNr3kKDJll7B1aS0hE84n8Y6Z1/VJ0Qt3dGZ+Ru2hBN0rGElq Iuig== MIME-Version: 1.0 X-Received: by 10.107.5.210 with SMTP id 201mr5380992iof.88.1433954299830; Wed, 10 Jun 2015 09:38:19 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Wed, 10 Jun 2015 09:38:19 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Jun 2015 09:38:19 -0700 X-Google-Sender-Auth: sO-UMG0Njxa5Lf0DWjxpfv5OXac Message-ID: Subject: Re: High Interrupt rate since r279961 on STABLE/10 branch From: Adrian Chadd To: Yanhui Shen Cc: Henry Hu , FreeBSD Stable Mailing List Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 16:38:20 -0000 Hi, There was an update to freebsd-head a few days ago from hans - it disabled PCI interrupts for VGA until a driver claims it. See if that helps? -a b On 10 June 2015 at 05:33, Yanhui Shen wrote: > Hi, > > I noticed the interrupt rate of my FreeBSD system is very high (~35%) after > upgrade from r279138 to r284205. > > To find out which revision cause this problem, > I used a binary search manner and compiled the kernel 11 times. > Finally I located to r279961, the interruption rate is abnormal since this > revision. > > Do you have any idea about this issue? > > ( I'm temporarily using r279958 kernel with r284205 base system, everything > is fine.) > > -------------------------------- > > Device: ThinkPad R400 (Product ID: 278225C) > CPU: Intel Core 2 Duo processor T6570 (2.1 GHz) > GPU: Intel Integrated Graphics 4500MHD > > Output of "vmstat -i" with r284205 kernel (abnormal): > interrupt total rate > irq1: atkbd0 1607 1 > irq9: acpi0 131958 104 > irq12: psm0 4281 3 > irq16: uhci3 239899376 189643 > irq20: hpet0 uhci0 1426118 1127 > irq21: uhci1 40315 31 > irq23: ehci0 33 0 > irq256: vgapci0 6059 4 > irq257: em0 49220 38 > irq258: hdac0 62 0 > irq260: ahci0:ch0 17217 13 > irq261: ahci0:ch1 23 0 > Total 241576269 190969 > > Output of "vmstat -i" with r279958 kernel (normal): > interrupt total rate > irq1: atkbd0 48155 3 > irq9: acpi0 1581468 105 > irq12: psm0 209484 13 > irq19: ehci1 48099 3 > irq20: hpet0 uhci0 17385585 1156 > irq21: uhci1 680884 45 > irq23: ehci0 31 0 > irq256: vgapci0 2611430 173 > irq257: em0 1342009 89 > irq258: hdac0 602220 40 > irq260: ahci0:ch0 236313 15 > irq261: ahci0:ch1 27 0 > Total 24745705 1646 > > The revision: > https://svnweb.freebsd.org/base?view=revision&revision=279961 > > -------------------------------- > > Best regards, > Yanhui Shen > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 16:44:44 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6C644E3F; Wed, 10 Jun 2015 16:44:44 +0000 (UTC) (envelope-from randy@psg.com) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B4171B11; Wed, 10 Jun 2015 16:44:44 +0000 (UTC) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=ryuu.psg.com) by ran.psg.com with esmtp (Exim 4.82) (envelope-from ) id 1Z2j7G-0005R7-2K; Wed, 10 Jun 2015 16:44:41 +0000 Date: Wed, 10 Jun 2015 09:44:09 -0700 Message-ID: From: Randy Bush To: Allan Jude Cc: d@delphij.net, FreeBSD Stable , Allan Jude Subject: Re: ssh install with freebsd-update In-Reply-To: <557864B3.1090909@freebsd.org> References: <55777B4D.7040706@delphij.net> <557864B3.1090909@freebsd.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 16:44:44 -0000 > uname -KU > > I am guessing your kernel is new, and your userland is old, as Xin Li said # uname -KU 1001000 1001000 From owner-freebsd-stable@FreeBSD.ORG Wed Jun 10 18:41:58 2015 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8669F491; Wed, 10 Jun 2015 18:41:58 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "anubis.delphij.net", Issuer "StartCom Class 1 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 66D111BF3; Wed, 10 Jun 2015 18:41:58 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from zeta.ixsystems.com (unknown [12.229.62.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by anubis.delphij.net (Postfix) with ESMTPSA id 2392E183DB; Wed, 10 Jun 2015 11:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=anubis; t=1433961718; x=1433976118; bh=i/TTjt1R+/5Pm4WtzhhI2kGwigmj6SQzg2iBsQpqNCk=; h=Date:From:Reply-To:To:CC:Subject:References:In-Reply-To; b=vlkzQwegLhl0oVY9UB/hvpcKrE4TluYGetM6V7+jMsBgDCXempK43EZkKJyLpXp8x Ava+RQM69Uv8uRglqABT2HsmqZ10WTt+87Fp/dpnFWRYh6SyJfJsUWPRrJyWQMHLPA Ud3xi0285mBjXhIWAxfb4szDZQjs3k9Zv3aaeyps= Message-ID: <557884F5.7080301@delphij.net> Date: Wed, 10 Jun 2015 11:41:57 -0700 From: Xin Li Reply-To: d@delphij.net Organization: The FreeBSD Project MIME-Version: 1.0 To: Palle Girgensohn , delphij@FreeBSD.org CC: freebsd-stable@FreeBSD.org Subject: Re: wrong patch number in releng/10.1? References: <82E830BE-8B28-479A-8CBE-78D192592E26@FreeBSD.org> In-Reply-To: <82E830BE-8B28-479A-8CBE-78D192592E26@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2015 18:41:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 06/10/15 02:20, Palle Girgensohn wrote: > Also > > # uname -a FreeBSD pingpongdb 10.1-RELEASE-p10 FreeBSD > 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC > amd64 # uptime 2:18am up 36 mins, 4 users, load averages: 0,08 > 0,14 0,10 # ls -lrt /boot/kernel/kernel /boot/kernel/*zfs* > -r-xr-xr-x 2 root wheel 21160449 10 Jun 01:36 > /boot/kernel/kernel -r-xr-xr-x 2 root wheel 2320144 10 Jun > 01:36 /boot/kernel/zfs.ko -r-xr-xr-x 1 root wheel 19103144 10 > Jun 01:36 /boot/kernel/zfs.ko.symbols # strings > /boot/kernel/kernel|grep 10.1-RELEASE @(#)FreeBSD 10.1-RELEASE-p10 > #0: Wed May 13 06:54:13 UTC 2015 FreeBSD 10.1-RELEASE-p10 #0: Wed > May 13 06:54:13 UTC 2015 10.1-RELEASE-p10 > > It seems to me the verions numbering is not correct, but the patch > *is* there, it should be 10.1-p11, right? Assuming you are using freebsd-update, kernel version is only updated when there is actual change in the kernel *itself*. In this case we have made a few changes to ZFS but that only affected the module, so kernel version is not changed. This is expected behavior . The canonical way of determining system version is 'freebsd-version - -ku' for 10.0 onwards. Hope this helps. Cheers, >> 10 jun 2015 kl. 11:01 skrev Palle Girgensohn >> : >> >> Hi, >> >> It seems the patch level in the UPDATING document is bad in >> releng/10.1, it is p29 which is the patch level for 8.4? >> >> Palle >> >> --------------------------------------------------------------------- - --- >> >> r284193 | delphij | 2015-06-10 00:13:25 +0200 (Ons, 10 Jun 2015) | 8 lin es >> >> Update base system file(1) to 5.22 to address multiple denial of >> service issues. [EN-15:06] >> >> Improve reliability of ZFS when TRIM/UNMAP and/or L2ARC is used. >> [EN-15:07] >> >> Approved by: so >> >> --------------------------------------------------------------------- - --- >> >> >> But the UPDATING says: >> >> 20150609: p29 FreeBSD-EN-15:06.file >> FreeBSD-EN-15:07.zfs >> >> Updated base system file(1) to 5.22 to address multiple denial of >> service issues. [EN-15:06] >> >> Improved reliability of ZFS when TRIM/UNMAP and/or L2ARC is >> used. [EN-15:07] >> >> 20150513: p10 FreeBSD-EN-15:04.freebsd-update >> FreeBSD-EN-15:05.ufs >> >> Fix bug with freebsd-update(8) that does not ensure the previous >> upgrade was completed. [EN-15:04] >> >> Fix deadlock on reboot with UFS tuned with SU+J. [EN-15:05] >> >> >> >> > - -- Xin LI https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.1.4 (FreeBSD) iQIcBAEBCgAGBQJVeIT1AAoJEJW2GBstM+nswC0QAJM5I6A52Lp9vAbMJTwauHGn z8wKzR+P4CyNDgWCpBpyPO+CsRRZgpBEYVTIuj61cTgoK5r2PLoUIGpEwfGX+1L8 izTd25MitSi721+Toy5dFe/ndBb4D7dz8+naFp59TmJtO7ZuLNRCxYLPoou4bcOg ZeX4af7alcEl93ADBE0T8gNDkcFmwxSNcciYxtMiad33TjqWkekNRN78ndpRi/5h raAt9UD6//iT7V+/w7PcdwvXugUgoQMxdaivXA4SV1xXX2MlnaDAU67nrWlPhXDM YbhS11SP1gptNWDlIz016oOblu4AV3dUIbPVjWbJ6KnLEiHg0KVn/PlsBpJ0wIcl WseRSdCNeqMTE7ik1qjfiEzE/Y6A/BTVVQsL5jQ4idRPfRyKGtG9vHxtfyV8itls kKCibaWVaBtUidRQHIyxpSHvSRp614iK3SO0ZR+yecDN0lUZvxCraYXgEXo+Ov4O YQ3/nBTReBFYRtF7PEnk6qtcbJ3UL2EgwOFMkODbkvACdFK/XxByMW4f3H5A4TFm nzDKXb+fmrtmf5e0XE6kZgOEFKBFZmLt4QbnPrAoa7WO/Eu43HE7/skYWNpJVLoz 3lZ16XTK39UKUA+/sniiHRW8m9SFxXv1E9GsLl/xO1HQDXuhiYN1nPkEx/PXYUjp GRGXVDw84qS1kbYHifzu =DXmN -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 01:43:16 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59C67996; Thu, 11 Jun 2015 01:43:16 +0000 (UTC) (envelope-from shen.elf@gmail.com) Received: from mail-ie0-x241.google.com (mail-ie0-x241.google.com [IPv6:2607:f8b0:4001:c03::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 23A95176D; Thu, 11 Jun 2015 01:43:16 +0000 (UTC) (envelope-from shen.elf@gmail.com) Received: by iery20 with SMTP id y20so2686975ier.1; Wed, 10 Jun 2015 18:43:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=rA5p4AucG8k8i52P4LCsIzzkIjWiZuT6RnZDBH33DL0=; b=dKN2ur9+qKkoXh7ajyUjiYF+UZmjFAlCpZeGA94af/oQ1Nb8IDCmSG6S2rJmVR3E6T eOInEYf7Bm8hVfBakdSkUeX6SW6erdRfGQ4ylZ9fXnLQ5rjs+4fvLiRPF6NzWm1LatQG 0ciOLvPM6X6RrhlIPuB4ogj7fV66r9WUbMx5qRmHtoI23vZyxOzE+DNxgsvbCJEl7cqi IIW6vlQjD8mwoDLV0JrNwojv96LwQM4Zg0R9/rNPaQeHJP6EHKt/KexXe/yCxuDQyvTd jnWPdngyhplSDlQAEfwhKUOjDdUpJAsRxRNqBW+9fdlZtAObLrH+2UUETJ+mnYpvTqLG x97Q== MIME-Version: 1.0 X-Received: by 10.107.165.210 with SMTP id o201mr8312259ioe.2.1433986995520; Wed, 10 Jun 2015 18:43:15 -0700 (PDT) Received: by 10.107.15.157 with HTTP; Wed, 10 Jun 2015 18:43:15 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Jun 2015 09:43:15 +0800 Message-ID: Subject: Re: High Interrupt rate since r279961 on STABLE/10 branch From: Yanhui Shen To: Adrian Chadd , freebsd-stable@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 01:43:16 -0000 Hi, Thanks, it works! https://svnweb.freebsd.org/base/head/sys/dev/pci/vga_pci.c?r1=284012&r2=284011&pathrev=284012 2015-06-11 0:38 GMT+08:00 Adrian Chadd : > Hi, > > There was an update to freebsd-head a few days ago from hans - it > disabled PCI interrupts for VGA until a driver claims it. > > See if that helps? > > > -a > b > > On 10 June 2015 at 05:33, Yanhui Shen wrote: > > Hi, > > > > I noticed the interrupt rate of my FreeBSD system is very high (~35%) > after > > upgrade from r279138 to r284205. > > > > To find out which revision cause this problem, > > I used a binary search manner and compiled the kernel 11 times. > > Finally I located to r279961, the interruption rate is abnormal since > this > > revision. > > > > Do you have any idea about this issue? > > > > ( I'm temporarily using r279958 kernel with r284205 base system, > everything > > is fine.) > > > > -------------------------------- > > > > Device: ThinkPad R400 (Product ID: 278225C) > > CPU: Intel Core 2 Duo processor T6570 (2.1 GHz) > > GPU: Intel Integrated Graphics 4500MHD > > > > Output of "vmstat -i" with r284205 kernel (abnormal): > > interrupt total rate > > irq1: atkbd0 1607 1 > > irq9: acpi0 131958 104 > > irq12: psm0 4281 3 > > irq16: uhci3 239899376 189643 > > irq20: hpet0 uhci0 1426118 1127 > > irq21: uhci1 40315 31 > > irq23: ehci0 33 0 > > irq256: vgapci0 6059 4 > > irq257: em0 49220 38 > > irq258: hdac0 62 0 > > irq260: ahci0:ch0 17217 13 > > irq261: ahci0:ch1 23 0 > > Total 241576269 190969 > > > > Output of "vmstat -i" with r279958 kernel (normal): > > interrupt total rate > > irq1: atkbd0 48155 3 > > irq9: acpi0 1581468 105 > > irq12: psm0 209484 13 > > irq19: ehci1 48099 3 > > irq20: hpet0 uhci0 17385585 1156 > > irq21: uhci1 680884 45 > > irq23: ehci0 31 0 > > irq256: vgapci0 2611430 173 > > irq257: em0 1342009 89 > > irq258: hdac0 602220 40 > > irq260: ahci0:ch0 236313 15 > > irq261: ahci0:ch1 27 0 > > Total 24745705 1646 > > > > The revision: > > https://svnweb.freebsd.org/base?view=revision&revision=279961 > > > > -------------------------------- > > > > Best regards, > > Yanhui Shen > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org > " > -- Best regards, Yanhui Shen From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 06:20:10 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EA45FF1A; Thu, 11 Jun 2015 06:20:10 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 381031A5C; Thu, 11 Jun 2015 06:20:09 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t5B6Jxk1029757; Thu, 11 Jun 2015 16:19:59 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 11 Jun 2015 16:19:59 +1000 (EST) From: Ian Smith To: Yanhui Shen cc: Adrian Chadd , freebsd-stable@freebsd.org Subject: Re: High Interrupt rate since r279961 on STABLE/10 branch In-Reply-To: Message-ID: <20150611160835.K74737@sola.nimnet.asn.au> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 06:20:11 -0000 On Thu, 11 Jun 2015 09:43:15 +0800, Yanhui Shen wrote: > Hi, > > Thanks, it works! > > https://svnweb.freebsd.org/base/head/sys/dev/pci/vga_pci.c?r1=284012&r2=284011&pathrev=284012 > > > > 2015-06-11 0:38 GMT+08:00 Adrian Chadd : > > > Hi, > > > > There was an update to freebsd-head a few days ago from hans - it > > disabled PCI interrupts for VGA until a driver claims it. > > > > See if that helps? I'm glad it does, and can see the interrupt rate on vgapci0 was 173 when bad and 4 when good, but I'm completely at a loss to see how that might have affected the interrupt rate on uhci3, shown below as 189643 (!) when bad and, er, absent when good? cheers, Ian > > > Device: ThinkPad R400 (Product ID: 278225C) > > > CPU: Intel Core 2 Duo processor T6570 (2.1 GHz) > > > GPU: Intel Integrated Graphics 4500MHD > > > > > > Output of "vmstat -i" with r284205 kernel (abnormal): > > > interrupt total rate > > > irq1: atkbd0 1607 1 > > > irq9: acpi0 131958 104 > > > irq12: psm0 4281 3 > > > irq16: uhci3 239899376 189643 > > > irq20: hpet0 uhci0 1426118 1127 > > > irq21: uhci1 40315 31 > > > irq23: ehci0 33 0 > > > irq256: vgapci0 6059 4 > > > irq257: em0 49220 38 > > > irq258: hdac0 62 0 > > > irq260: ahci0:ch0 17217 13 > > > irq261: ahci0:ch1 23 0 > > > Total 241576269 190969 > > > > > > Output of "vmstat -i" with r279958 kernel (normal): > > > interrupt total rate > > > irq1: atkbd0 48155 3 > > > irq9: acpi0 1581468 105 > > > irq12: psm0 209484 13 > > > irq19: ehci1 48099 3 > > > irq20: hpet0 uhci0 17385585 1156 > > > irq21: uhci1 680884 45 > > > irq23: ehci0 31 0 > > > irq256: vgapci0 2611430 173 > > > irq257: em0 1342009 89 > > > irq258: hdac0 602220 40 > > > irq260: ahci0:ch0 236313 15 > > > irq261: ahci0:ch1 27 0 > > > Total 24745705 1646 From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 12:23:15 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A9E1522 for ; Thu, 11 Jun 2015 12:23:15 +0000 (UTC) (envelope-from unixro@gmail.com) Received: from mail-wg0-x243.google.com (mail-wg0-x243.google.com [IPv6:2a00:1450:400c:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6E351AD9 for ; Thu, 11 Jun 2015 12:23:14 +0000 (UTC) (envelope-from unixro@gmail.com) Received: by wggy19 with SMTP id y19so955922wgg.2 for ; Thu, 11 Jun 2015 05:23:13 -0700 (PDT) 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=A0OkrQ29TIPJpQf+50UiyD98+j5Qs7pjKgre+dLE7sY=; b=Buq4awoMZQZEUHwRrFTR+yQSxiO4T6jAPalb0yphuRkAaSQ1xFpt32oNFakraIgd6J u2d8jppgTzzx8jkn2lP5JZd8AxuPwBCsq8mARwjB6u9lQO3n/Z4sNthl92k1zjm5CaZx L/TnL8y/HeA2mr3u9iVY1BPVa/aOTuMeFkpxX90kffz5C0C+7Cy9P2x5p5/UC2Yx03cg BM28SYDFoUdIXpF41wGAZuz7BGA6DNV3yLVZmYyxJ7i9Vp7WBcYBzW2LtP1vpZT6v46D 6whb6/aobkt62VhOGnsb3MZfhI6bug2wIklDUScLvIBl1x4l7GrQFNvgzhjOtmExAaNP KclQ== X-Received: by 10.180.91.107 with SMTP id cd11mr18210936wib.51.1434025393254; Thu, 11 Jun 2015 05:23:13 -0700 (PDT) Received: from [192.168.3.105] ([193.148.0.35]) by mx.google.com with ESMTPSA id ej5sm851416wjd.22.2015.06.11.05.23.12 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2015 05:23:12 -0700 (PDT) Message-ID: <55797DAF.2020304@gmail.com> Date: Thu, 11 Jun 2015 15:23:11 +0300 From: Mihai Vintila User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Kernel Source - Noob question Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 12:23:15 -0000 Hi, I want to compile only mlx drivers since they don't seem available by default. But i'm having a hard time finding the source for FreeBSD 10.1 p10. Can you guys indicate what is the best way to do it without recompiling full kernel. Right now i've taken the src.tgz from ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/10.1-STABLE/ Compiled the modules but when i try to load them i end up with: KLD mlx4.ko: depends on kernel - not available or version mismatch linker_load_file: Unsupported file type Kernel i'm using is FreeBSD nvme 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 -- Best regards, Vintila Mihai Alexandru From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 12:39:28 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D1EF7AD for ; Thu, 11 Jun 2015 12:39:28 +0000 (UTC) (envelope-from unixro@gmail.com) Received: from mail-wi0-x242.google.com (mail-wi0-x242.google.com [IPv6:2a00:1450:400c:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D89A51D94 for ; Thu, 11 Jun 2015 12:39:27 +0000 (UTC) (envelope-from unixro@gmail.com) Received: by wivz2 with SMTP id z2so2225252wiv.0 for ; Thu, 11 Jun 2015 05:39:24 -0700 (PDT) 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:references :in-reply-to:content-type:content-transfer-encoding; bh=dFdLZVVnmMxfRCrerUBE0XgFWe/hZDFGQ1chUn7yME4=; b=f/hegsRcfuDVi8ALJ55vRho/3naRIZYa7JysMQPXSC194U2lon7/wyIIu6pyOjuMKr g+aNwQLorhYS3SSOYW2nqDWs2aZWYGOH0kFe7GyidA39wPXBecumKnR6aPdzgET7jue2 RwZVBpnv/QSZfCOBV04P/dGiF9AODfbSN4Y35AclJeF/DMfyBhlbOoUe+EQ0Pjzds4Nt DEVCL2/bn9EACwvcPCuzMWKqX74S/KBWGr2bSC7XVSzAGcUgJKnW8LICBgK66BNgQF1l 7Uz03ZKwp8sAUxje690kA48RSwf1joQDDQArvp2nVfiybHKpInn610+SRm06nYKNxSu9 Kz9Q== X-Received: by 10.181.11.137 with SMTP id ei9mr18520161wid.48.1434026363955; Thu, 11 Jun 2015 05:39:23 -0700 (PDT) Received: from [192.168.3.105] ([193.148.0.35]) by mx.google.com with ESMTPSA id l6sm12665424wib.18.2015.06.11.05.39.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jun 2015 05:39:23 -0700 (PDT) Message-ID: <55798177.4040409@gmail.com> Date: Thu, 11 Jun 2015 15:39:19 +0300 From: Mihai Vintila User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-stable@freebsd.org Subject: Re: Kernel Source - Noob question References: <55797DAF.2020304@gmail.com> In-Reply-To: <55797DAF.2020304@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 12:39:28 -0000 Seems that it's working with: svnlite checkout https://svn0.eu.freebsd.org/base/releng/10.1 /usr/src Best regards, Vintila Mihai Alexandru On 6/11/2015 3:23 PM, Mihai Vintila wrote: > Hi, > I want to compile only mlx drivers since they don't seem available by > default. But i'm having a hard time finding the source for FreeBSD > 10.1 p10. > Can you guys indicate what is the best way to do it without > recompiling full kernel. > Right now i've taken the src.tgz from > ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/10.1-STABLE/ > Compiled the modules but when i try to load them i end up with: > > KLD mlx4.ko: depends on kernel - not available or version mismatch > linker_load_file: Unsupported file type > > Kernel i'm using is FreeBSD nvme 10.1-RELEASE-p10 FreeBSD > 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 > root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 > > From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 14:42:02 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2BC24EB6 for ; Thu, 11 Jun 2015 14:42:02 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E3C7D1118 for ; Thu, 11 Jun 2015 14:42:01 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1Z33fw-0005x8-AJ for freebsd-stable@freebsd.org; Thu, 11 Jun 2015 16:41:53 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: freebsd-stable@freebsd.org Subject: Re: Kernel Source - Noob question References: <55797DAF.2020304@gmail.com> <55798177.4040409@gmail.com> Date: Thu, 11 Jun 2015 16:41:47 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <55798177.4040409@gmail.com> User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: -- X-Spam-Score: -2.9 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED, BAYES_00, URIBL_BLOCKED autolearn=disabled version=3.3.1 X-Scan-Signature: 8b3222cd26cce149ddb9ffa05c4da76e X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 14:42:02 -0000 On Thu, 11 Jun 2015 14:39:19 +0200, Mihai Vintila wrote: > Seems that it's working with: > svnlite checkout https://svn0.eu.freebsd.org/base/releng/10.1 /usr/src Well done! ;-) > > Best regards, > Vintila Mihai Alexandru > > On 6/11/2015 3:23 PM, Mihai Vintila wrote: >> Hi, >> I want to compile only mlx drivers since they don't seem available by >> default. But i'm having a hard time finding the source for FreeBSD 10.1 >> p10. >> Can you guys indicate what is the best way to do it without recompiling >> full kernel. >> Right now i've taken the src.tgz from >> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/10.1-STABLE/ >> Compiled the modules but when i try to load them i end up with: >> >> KLD mlx4.ko: depends on kernel - not available or version mismatch >> linker_load_file: Unsupported file type >> >> Kernel i'm using is FreeBSD nvme 10.1-RELEASE-p10 FreeBSD >> 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 >> root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 >> >> > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Jun 11 19:27:38 2015 Return-Path: Delivered-To: freebsd-stable@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0AB98841 for ; Thu, 11 Jun 2015 19:27:38 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C771719E4 for ; Thu, 11 Jun 2015 19:27:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by iebps5 with SMTP id ps5so11279813ieb.3 for ; Thu, 11 Jun 2015 12:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=gP1ylgIiodrdMSRCGq2g8U9eQrh9Nrtdrh/ZN6OCbFQ=; b=CbOOXHqKNJmjQG93aze2HXYqil9RqEpqyS6ElD56fiJsgF1DUsDhv2FDPtGv1v1Vyw l8Tbz2YPC2yJ4jBnMaRlszNftm3pM0mzOfjEkSrhszHYO/Xi35DJkQ081gsPwCqh++WA p6verpCJ6/S/dK8bz9bDz49zmXrqddINXvgPtH1TJX2OFpwX8hYjpAbviBKrVqvW8tMz VGvdHDPxEJo+3MTh+qMb4AoT6k5T6t9jqqezojeuZVqHcsVUavwjsXuyO7coEu3g4PSo CyFcsANrDdHexBMOlLjio1AMGeKon6Gln3PU8MIVRJd1633MK3024/JQUHbgy+X2EAhO M5Gw== MIME-Version: 1.0 X-Received: by 10.50.136.197 with SMTP id qc5mr14710179igb.6.1434049214754; Thu, 11 Jun 2015 12:00:14 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.38.133 with HTTP; Thu, 11 Jun 2015 12:00:14 -0700 (PDT) In-Reply-To: <20150611160835.K74737@sola.nimnet.asn.au> References: <20150611160835.K74737@sola.nimnet.asn.au> Date: Thu, 11 Jun 2015 12:00:14 -0700 X-Google-Sender-Auth: p706d_bwhn6_ZOUROUE_B80FdQU Message-ID: Subject: Re: High Interrupt rate since r279961 on STABLE/10 branch From: Adrian Chadd To: Ian Smith Cc: Yanhui Shen , FreeBSD Stable Mailing List Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2015 19:27:38 -0000 because they're shared. It just doesn't show up by default as nothing has really claimed the IRQ. try vmstat -ia .. -adrian On 10 June 2015 at 23:19, Ian Smith wrote: > On Thu, 11 Jun 2015 09:43:15 +0800, Yanhui Shen wrote: > > Hi, > > > > Thanks, it works! > > > > https://svnweb.freebsd.org/base/head/sys/dev/pci/vga_pci.c?r1=284012&r2=284011&pathrev=284012 > > > > > > > > 2015-06-11 0:38 GMT+08:00 Adrian Chadd : > > > > > Hi, > > > > > > There was an update to freebsd-head a few days ago from hans - it > > > disabled PCI interrupts for VGA until a driver claims it. > > > > > > See if that helps? > > I'm glad it does, and can see the interrupt rate on vgapci0 was 173 when > bad and 4 when good, but I'm completely at a loss to see how that might > have affected the interrupt rate on uhci3, shown below as 189643 (!) > when bad and, er, absent when good? > > cheers, Ian > > > > > Device: ThinkPad R400 (Product ID: 278225C) > > > > CPU: Intel Core 2 Duo processor T6570 (2.1 GHz) > > > > GPU: Intel Integrated Graphics 4500MHD > > > > > > > > Output of "vmstat -i" with r284205 kernel (abnormal): > > > > interrupt total rate > > > > irq1: atkbd0 1607 1 > > > > irq9: acpi0 131958 104 > > > > irq12: psm0 4281 3 > > > > irq16: uhci3 239899376 189643 > > > > irq20: hpet0 uhci0 1426118 1127 > > > > irq21: uhci1 40315 31 > > > > irq23: ehci0 33 0 > > > > irq256: vgapci0 6059 4 > > > > irq257: em0 49220 38 > > > > irq258: hdac0 62 0 > > > > irq260: ahci0:ch0 17217 13 > > > > irq261: ahci0:ch1 23 0 > > > > Total 241576269 190969 > > > > > > > > Output of "vmstat -i" with r279958 kernel (normal): > > > > interrupt total rate > > > > irq1: atkbd0 48155 3 > > > > irq9: acpi0 1581468 105 > > > > irq12: psm0 209484 13 > > > > irq19: ehci1 48099 3 > > > > irq20: hpet0 uhci0 17385585 1156 > > > > irq21: uhci1 680884 45 > > > > irq23: ehci0 31 0 > > > > irq256: vgapci0 2611430 173 > > > > irq257: em0 1342009 89 > > > > irq258: hdac0 602220 40 > > > > irq260: ahci0:ch0 236313 15 > > > > irq261: ahci0:ch1 27 0 > > > > Total 24745705 1646 From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 10:28:13 2015 Return-Path: Delivered-To: freebsd-stable@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18CCE3CF for ; Fri, 12 Jun 2015 10:28:13 +0000 (UTC) (envelope-from ortadur@web.de) Received: from mout.web.de (mout.web.de [212.227.17.11]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mout.web.de", Issuer "TeleSec ServerPass DE-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B509C13D9 for ; Fri, 12 Jun 2015 10:28:11 +0000 (UTC) (envelope-from ortadur@web.de) Received: from [131.169.71.114] by 3capp-webde-bs41.server.lan (via HTTP); Fri, 12 Jun 2015 12:03:16 +0200 MIME-Version: 1.0 Message-ID: From: "Andre Meiser" To: freebsd-stable@freebsd.org Subject: Aw: Re: Many core dumps in pthread_getspecific. Content-Type: text/plain; charset=UTF-8 Date: Fri, 12 Jun 2015 12:03:16 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <20150603145838.GX2499@kib.kiev.ua> References: , <20150603145838.GX2499@kib.kiev.ua> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:2LP0VysxKDH1g0OccoiTx8qTm40oFr4H5iLu6WPO9l3 aZ6QUulPyN9QxLUw6UhOAHATCmBm+fzREMlDKC46yt0udvltGs /+WwQ6jO1LH74bPNiELZ2TcgqjFthtPezd32OUSyShWU3dMw8g Ps6kksQtd5JPdpNy2uOJwrA8i+u642nUlv5SriGOL7xXMp6mSa 70rXv/K0wnUQkACaiXjC5/t1CPNTUxSgbGEM2n8mAs0vxvmit7 YjFS1qKXZ9ZKe8FY6xK35T1ZYHxyKcXG3T72lc6VsOYE0XbIuP DMOkbE= X-UI-Out-Filterresults: notjunk:1; X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 10:28:13 -0000 Hi, On Wed, Jun 03, 2015 at 16:58 +0200, Konstantin Belousov wrote: > You should recompile both libc and libthr with debugging symbols, like > cd /usr/src > (cd lib/libc && make all install DEBUG_FLAGS=-g) > (cd lib/libthr && make all install DEBUG_FLAGS=-g) > then obtain the core dump and post backtraces. still no new core dump from Xorg, but one from vim. As far as I recall, vim used to crash at pthread_getspecific, too, but this time it was different: Core was generated by `vim'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libncurses.so.8...(no debugging symbols found)...done. Loaded symbols for /lib/libncurses.so.8 Reading symbols from /usr/local/lib/libintl.so.8...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /usr/local/lib/libpython2.7.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libpython2.7.so.1 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libutil.so.9...done. Loaded symbols for /lib/libutil.so.9 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000000080149d6a2 in check_deferred_signal (curthread=0x802406400) at /usr/src/lib/libthr/thread/thr_sig.c:331 331 getcontext(uc); [New Thread 802406400 (LWP 101373/vim)] Current language: auto; currently minimal (gdb) bt #0 0x000000080149d6a2 in check_deferred_signal (curthread=0x802406400) at /usr/src/lib/libthr/thread/thr_sig.c:331 #1 0x000000080149d5ed in _thr_ast (curthread=0x802406400) at /usr/src/lib/libthr/thread/thr_sig.c:264 #2 0x00000008014a23c7 in _thr_rtld_lock_release (lock=) at /usr/src/lib/libthr/thread/thr_rtld.c:162 #3 0x000000080083c94d in _r_debug_postinit () from /libexec/ld-elf.so.1 #4 0x000000080083a15d in .text () from /libexec/ld-elf.so.1 #5 0x00000000004e3d83 in preserve_exit () #6 0x000000000051e808 in mch_libcall () #7 0x000000080149e47a in handle_signal (actp=, sig=, info=, ucp=) at /usr/src/lib/libthr/thread/thr_sig.c:240 #8 0x000000080149e062 in thr_sighandler (sig=, info=, _ucp=) at /usr/src/lib/libthr/thread/thr_sig.c:183 #9 #10 0x000000080149d6a2 in check_deferred_signal (curthread=0x802406400) at /usr/src/lib/libthr/thread/thr_sig.c:331 #11 0x000000080149d5ed in _thr_ast (curthread=0x802406400) at /usr/src/lib/libthr/thread/thr_sig.c:264 #12 0x00000008014a23c7 in _thr_rtld_lock_release (lock=) at /usr/src/lib/libthr/thread/thr_rtld.c:162 #13 0x000000080083c94d in _r_debug_postinit () from /libexec/ld-elf.so.1 #14 0x000000080083a15d in .text () from /libexec/ld-elf.so.1 #15 0x000000080149e4e2 in handle_signal (actp=, sig=, info=, ucp=) at /usr/src/lib/libthr/thread/thr_sig.c:256 #16 0x000000080149e062 in thr_sighandler (sig=, info=, _ucp=) at /usr/src/lib/libthr/thread/thr_sig.c:183 #17 #18 0x00000008017f9b7a in select () from /lib/libc.so.7 #19 0x000000080149bb32 in __select (numfds=1, readfds=0x7fffffffdfb0, writefds=0x0, exceptfds=0x7fffffffdf30, timeout=0x0) at /usr/src/lib/libthr/thread/thr_syscalls.c:561 #20 0x000000000051a33b in mch_write () #21 0x000000000051a5ac in mch_inchar () #22 0x00000000005b7a17 in ui_inchar () #23 0x00000000004ae86a in inchar () #24 0x00000000004b1cdb in vgetc () #25 0x00000000004b0bda in vgetc () #26 0x00000000004b2499 in safe_vgetc () #27 0x00000000004f560f in normal_cmd () #28 0x00000000005df297 in main_loop () #29 0x00000000005de908 in main () It's still a thread problem, but I've no idea if it's related with the former pthread_getspecific problem. Sincerely yours Andre. From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 16:57:26 2015 Return-Path: Delivered-To: freebsd-stable@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 02B8885B for ; Fri, 12 Jun 2015 16:57:26 +0000 (UTC) (envelope-from unixro@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8EE75374 for ; Fri, 12 Jun 2015 16:57:25 +0000 (UTC) (envelope-from unixro@gmail.com) Received: by wigg3 with SMTP id g3so22373841wig.1 for ; Fri, 12 Jun 2015 09:57:24 -0700 (PDT) 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=xE2zKP9PbM12Q2SoTcBxdu3ORCA1zSxrv/5IOYB1BQ8=; b=svtPcjg0O0bORA0+7WpBcQ9iZXz0B9P9n5PnKmDh5quYpN0oeHn3nimBw+Qy+mHc5m /qdp93vu6cJr7V98PzoNcbJXGKHL22skVn8M44w7kzIKnsPkamcB0cEMhpnxOKmwR0y2 glFKJF0gkfQJ+FxPNAAB8zAy2VUukDFPs94iPZPcfRb5pnSpiCvqt20Q2RAUJ2Ns1LYQ NyPMK8A/qZoy4qx9o4mX+fbuX4cO37Rwlh/UGK1N0C7CoZg3VbB+Fe39Dn0DZKhvFBeW 3Y+GBJxKl6U5/snUa+FoGkplMGAG237K9bGW29OKSO89QD+tIcIu+yOTiF+jD0sv0WX2 R6tg== X-Received: by 10.180.85.42 with SMTP id e10mr8556668wiz.17.1434128244067; Fri, 12 Jun 2015 09:57:24 -0700 (PDT) Received: from [192.168.3.105] ([193.148.0.35]) by mx.google.com with ESMTPSA id d3sm6650074wjs.21.2015.06.12.09.57.22 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 12 Jun 2015 09:57:23 -0700 (PDT) Message-ID: <557B0F72.8070403@gmail.com> Date: Fri, 12 Jun 2015 19:57:22 +0300 From: Mihai Vintila User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Subject: MLNX subnet manager issue on FBSD 10.1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 16:57:26 -0000 Hi, I'm having issues starting opensm under FBSD 10.1 . Used to work some time ago, but i had to rebuild the system: Any help to what i'm doing wrong would be appreciated. Drivers used are the ones from Mellanox (i've tried it with 2.1.5 and 2.1.6 as well), as the one from kernel are from 2008. opensm is built like this: svnlite checkout https://svn0.eu.freebsd.org/base/releng/10.1 /usr/src cd /usr/src/contrib/ofed && make includes cd /usr/src/contrib/ofed/usr.lib && make depend all install cd /usr/src/contrib/ofed/usr.bin && make depend all install mlx4_core0: mem 0xc7400000-0xc74fffff,0xc5000000-0xc57fffff irq 32 at device 0.0 on pci2 mlx4_core: Initializing mlx4_core: Mellanox ConnectX VPI driver v2.1.6 (Jun 12 2015) mlx4_core0: mlx4_ib_add: allocated counter index 1 for port 1 mlx4_en mlx4_core0: Activating port:1 mlxen0: Ethernet address: e4:1d:2d:0a:21:30 mlx4_en: mlx4_core0: Port 1: Using 12 TX rings mlxen0: link state changed to DOWN mlx4_en: mlx4_core0: Port 1: Using 8 RX rings mlx4_en: mlxen0: Using 12 TX rings mlx4_en: mlxen0: Using 8 RX rings mlx4_en: mlxen0: Initializing port root@nvme:~ # kldstat Id Refs Address Size Name 1 27 0xffffffff80200000 1756638 kernel 2 1 0xffffffff81957000 2681e8 zfs.ko 3 2 0xffffffff81bc0000 6780 opensolaris.ko 4 2 0xffffffff81bc7000 17d60 nvme.ko 5 1 0xffffffff81bdf000 4210 nvd.ko 6 1 0xffffffff81e11000 357f ums.ko 7 3 0xffffffff81e15000 37656 mlx4.ko 8 2 0xffffffff81e4d000 4e348 ibcore.ko 9 1 0xffffffff81e9c000 2f72 toecore.ko 10 1 0xffffffff81e9f000 238fa mlx4ib.ko 11 1 0xffffffff81ec3000 12482 mlxen.ko root@nvme:~ # uname -a FreeBSD nvme.intern.pch 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0: Wed May 13 06:54:13 UTC 2015 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 root@nvme:~ # opensm ------------------------------------------------- OpenSM 3.3.1 Reading Cached Option File: /etc/opensm/opensm.conf Command Line Arguments: Log File: /var/log/opensm.log ------------------------------------------------- OpenSM 3.3.1 Entering DISCOVERING state Using default GUID 0x0 Error from osm_opensm_bind (0x2A) Perhaps another instance of OpenSM is already running Exiting SM ibportstate -G 0xe61d2dfffe0a2130 1 enable ibpanic: [868] madrpc_init: can't open UMAD port ((null):0): (m) -- Best regards, Vintila Mihai Alexandru From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 19:42:45 2015 Return-Path: Delivered-To: freebsd-stable@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 803FF8F5 for ; Fri, 12 Jun 2015 19:42:45 +0000 (UTC) (envelope-from markoml@markoturk.info) Received: from vps.markoturk.info (vps.markoturk.info [95.154.208.14]) by mx1.freebsd.org (Postfix) with ESMTP id 1AA0CBE for ; Fri, 12 Jun 2015 19:42:44 +0000 (UTC) (envelope-from markoml@markoturk.info) Received: by vps.markoturk.info (Postfix, from userid 1001) id 95E632740C; Fri, 12 Jun 2015 21:35:29 +0200 (CEST) Date: Fri, 12 Jun 2015 21:35:29 +0200 From: Marko Turk To: freebsd-stable@freebsd.org Subject: Vbox kernel module panic on boot Message-ID: <20150612193529.GB9045@vps.markoturk.info> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="O5XBE6gyVG5Rl6Rj" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 19:42:45 -0000 --O5XBE6gyVG5Rl6Rj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, I'm running 10-STABLE and I have the following in my rc.conf: vboxdrv_load=3D"YES" vboxnet_enable=3D"YES" Today I upgraded to r284295 and I get a kernel panic on boot when the vbox module is loaded (panic: ncpus is 0 with non-zero map). Complete backtrace is at the end of the mail. Last time I upgraded was May 14 and then everything worked fine. Has anyone else seen this? Is this a bug in virtualbox module or in kernel? BR, Marko (kgdb) #0 doadump (textdump=3D) at pcpu.h:219 #1 0xffffffff80940ce2 in kern_reboot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:451 #2 0xffffffff80941128 in vpanic (fmt=3D,=20 ap=3D) at /usr/src/sys/kern/kern_shutdown.c:758 #3 0xffffffff80940f53 in panic (fmt=3D0x0) at /usr/src/sys/kern/kern_shutdown.c:687 #4 0xffffffff8098a494 in smp_rendezvous_cpus (map=3D,= =20 setup_func=3D, action_func=3D= ,=20 teardown_func=3D, arg=3D) at /usr/src/sys/kern/subr_smp.c:495 #5 0xffffffff82c77373 in RTMpOnSpecific () from /boot/modules/vboxdrv.ko #6 0xffffffff82c583bb in supdrvInitDevExt () from /boot/modules/vboxdrv.ko #7 0xffffffff82c63dfe in VBoxDrvFreeBSDModuleEvent () from /boot/modules/vboxdrv.ko #8 0xffffffff8092ac2b in module_register_init (arg=3D0xfffffe01abb6b000) at /usr/src/sys/kern/kern_module.c:123 #9 0xffffffff80920347 in linker_load_module (kldname=3D,=20 modname=3D0xffffffff82c4b5a3 "vboxdrv", parent=3D0xfffff8001d3d4200,=20 verinfo=3D0x19e65e03fb, lfpp=3D0x0) at /usr/src/sys/kern/kern_linker.c:= 225 #10 0xffffffff80922784 in linker_load_dependencies (lf=3D0xfffff8001d3d4200) at /usr/src/sys/kern/kern_linker.c:2088 #11 0xffffffff80e1db6b in link_elf_load_file (cls=3D,= =20 filename=3D, result=3D0xfffffe01af3b9a30) at /usr/src/sys/kern/link_elf_obj.c:849 #12 0xffffffff809200ed in linker_load_module (kldname=3D,=20 modname=3D0xfffff800091d1400 "vboxnetflt", parent=3D0x0, verinfo=3D0x0,= =20 lfpp=3D0xfffffe01af3b9a70) at linker_if.h:161 #13 0xffffffff80921793 in kern_kldload (td=3D,=20 file=3D, fileid=3D0xfffffe01af3b9ab4) at /usr/src/sys/kern/kern_linker.c:1030 #14 0xffffffff8092186b in sys_kldload (td=3D0xfffff8001d402940,=20 uap=3D) at /usr/src/sys/kern/kern_linker.c:1056 #15 0xffffffff80d35817 in amd64_syscall (td=3D0xfffff8001d402940, traced=3D= 0) at subr_syscall.c:134 #16 0xffffffff80d1a89b in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:396 #17 0x000000080088eb9a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb)=20 --O5XBE6gyVG5Rl6Rj Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVezSBAAoJEDcRe7P/w1sjT+cP/3ejabYsUeWC+CE98PpZ5Y1i Hht9ayEBZYvN2F/OgXGszJSk8XuHdj1i2TfFpzMljU6FOdZJsoDFCHnGyDmSpO24 u7h8zFtStby8Puxpq0Ox5g6McyOBN71OSfRoBs/eY8PfIf4Md+KLNMb7V6GY6qBb WWKaBB8IOzFPyxEAJFzuANRrqM2y9CreIiRluchiCLdGpU5+ZFxGP1nQs7ogDFDi F1gqzuBviIZ1Hm5Gs7ctoii8ukBqGVaAdCs2106D8itu+BOu1xtmN/tkp9PcyWMY QK7mSJHdBLauw2b2w2pslggSfpth4ADskbwDR4kYkEqnor00AnrDpbhpPbt9d9k+ ZekGczvdw5mxc4D9qnn84oJ8F1T7r2SMuIezIGTUPk41Q/4KOlEjGKcMxceRCeQE g9ezKdsIVuWVSW8sThaBQpDzkySe+/GizVTsCQME/7HNS1PlHFOmspl9k9wIKTTZ EI5oYev4+62WcJ9RAUlKVOd5tJQeTwMLTx+GMtjDXjQ868usx2hh8XPVF83RmDhG a0TFa7jGU1F9DXJBAMQWmf6DTtcyq7AZzZ0ubutZLxIVbVQJogg2lfGtTJ8TOMvc bOiCws2XhDJkVWHc7fFVeTkXtU7ueKxBAP54ETVnW5mxBGxESDiWv0iEt9YOZKTS vEcRWMt5nLFrf1GiSxQw =nFSR -----END PGP SIGNATURE----- --O5XBE6gyVG5Rl6Rj-- From owner-freebsd-stable@FreeBSD.ORG Fri Jun 12 19:54:31 2015 Return-Path: Delivered-To: freebsd-stable@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 68204EAB for ; Fri, 12 Jun 2015 19:54:31 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 42BEE321 for ; Fri, 12 Jun 2015 19:54:31 +0000 (UTC) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: by be-well.ilk.org (Postfix, from userid 1147) id E9D4133C48; Fri, 12 Jun 2015 15:54:23 -0400 (EDT) From: Lowell Gilbert To: Marko Turk Cc: freebsd-stable@freebsd.org Subject: Re: Vbox kernel module panic on boot References: <20150612193529.GB9045@vps.markoturk.info> Reply-To: freebsd-stable@freebsd.org Date: Fri, 12 Jun 2015 15:54:23 -0400 In-Reply-To: <20150612193529.GB9045@vps.markoturk.info> (Marko Turk's message of "Fri, 12 Jun 2015 21:35:29 +0200") Message-ID: <44y4jo8zyo.fsf@be-well.ilk.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 19:54:31 -0000 Marko Turk writes: > Today I upgraded to r284295 and I get a kernel panic on boot when the > vbox module is loaded (panic: ncpus is 0 with non-zero map). Complete > backtrace is at the end of the mail. You rebuilt the vbox module, yes?