From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 04:28:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53B95CDB for ; Sun, 5 Oct 2014 04:28:11 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 8268ED95 for ; Sun, 5 Oct 2014 04:28:09 +0000 (UTC) Received: from freebsd.my.domain (unknown [58.211.218.74]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygAXiT3OyDBUGOomAA--.5296S2; Sun, 05 Oct 2014 12:28:06 +0800 (CST) From: Tiwei Bie To: freebsd-hackers@freebsd.org Subject: [PATCH] hw.syscons.bell sysctl for vt (newcons) Date: Sun, 5 Oct 2014 12:27:53 +0800 Message-Id: <1412483273-36665-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.1.0 X-CM-TRANSID: LkAmygAXiT3OyDBUGOomAA--.5296S2 X-Coremail-Antispam: 1UD129KBjvJXoW7Ar17CFy3CF1kWFWUtw1fZwb_yoW8Gw1Dpa 1DArWjvrZ5trn5ur1fXrsYy3W3Aws7trWxGFyUA3y0yFZYyrs5W3W8tFWFqFZ8Xr4vka4a vrWrZ3s5W3yUJFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvC14x267AKxVWUJVW8JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84x0c7CEw4AK67xGY2AK02 1l84ACjcxK6xIIjxv20xvE14v26r4j6ryUM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j 6F4UM28EF7xvwVC2z280aVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Cr 1j6rxdM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVACY4xI64kE6c02F40Ex7xfMcIj 6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVW8JVWxJwAm72CE4IkC6x0Yz7v_Jr 0_Gr1lF7xvr2IYc2Ij64vIr41lF7I21c0EjII2zVCS5cI20VAGYxC7MxkIecxEwVAFwVW8 XwCF04k20xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwCFI7km07C267AKxVWUXV WUAwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF 1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6x IIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6rWUJVWrZr1UMIIF 0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2Kf nxnUUI43ZEXa7VUUhF4JUUUUU== X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQUHAVQhl8CP8QAHsZ Cc: Tiwei Bie X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 04:28:11 -0000 Hi All, I think the hw.syscons.bell sysctl provided by syscons is a very convenient method to disable the sound alert in FreeBSD. But I haven't found the similar interface in vt. So I have written a patch to implement the sysctl 'kern.vt.enable_bell' which is similar to 'hw.syscons.bell' for vt. --- sys/dev/vt/vt_core.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/sys/dev/vt/vt_core.c b/sys/dev/vt/vt_core.c index 2dd7e3f..a8cdedb 100644 --- a/sys/dev/vt/vt_core.c +++ b/sys/dev/vt/vt_core.c @@ -120,6 +120,7 @@ const struct terminal_class vt_termclass = { static SYSCTL_NODE(_kern, OID_AUTO, vt, CTLFLAG_RD, 0, "vt(9) parameters"); VT_SYSCTL_INT(enable_altgr, 1, "Enable AltGr key (Do not assume R.Alt as Alt)"); +VT_SYSCTL_INT(enable_bell, 1, "Enable bell"); VT_SYSCTL_INT(debug, 0, "vt(9) debug level"); VT_SYSCTL_INT(deadtimer, 15, "Time to wait busy process in VT_PROCESS mode"); VT_SYSCTL_INT(suspendswitch, 1, "Switch to VT0 before suspend"); @@ -904,6 +905,9 @@ vtterm_bell(struct terminal *tm) struct vt_window *vw = tm->tm_softc; struct vt_device *vd = vw->vw_device; + if (!vt_enable_bell) + return; + if (vd->vd_flags & VDF_QUIET_BELL) return; @@ -915,6 +919,9 @@ vtterm_beep(struct terminal *tm, u_int param) { u_int freq, period; + if (!vt_enable_bell) + return; + if ((param == 0) || ((param & 0xffff) == 0)) { vtterm_bell(tm); return; -- 2.1.0 From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 10:29:18 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34445E5; Sun, 5 Oct 2014 10:29:18 +0000 (UTC) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9DA58305; Sun, 5 Oct 2014 10:29:17 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id k14so3211209wgh.7 for ; Sun, 05 Oct 2014 03:29:16 -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:mail-followup-to:mime-version :content-type:content-disposition:user-agent; bh=lazS5fpj/Sgv5tEq7vZ4HkSvpw9wqQfXOUmKmCo1DhI=; b=aqF+nzscbe0nleFwrxBcAG09eWeMbjPeKhrSbtTglPednGzrjcH+6aW1rK2vMbWgWg o+JWUwZIgky1sQCBy1VoqWSTRTQqxViF5oowkYVldfxq6C5IWTGKdpU/euCN0qN/g6a/ JF4mkKLjF+WulI0XWKv9Oz5ryU+6KgKc66Ayblth4vAcECbum55U+0f70nS2Lf70gPGb 9v39gIsva357tNJpG5WLZrTZh8vwkJb8e0zvOUCcEtd8EHk2RIDtKvlYpubD6KyYCFtW yABaM/Ful4Yw/ee51rjYmmlHkb7pX7sOMnKTRihzy4wcQugyEjZ+WfKqp15oUOCnTEZg Fyjw== X-Received: by 10.180.39.44 with SMTP id m12mr11676084wik.25.1412504955927; Sun, 05 Oct 2014 03:29:15 -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 n5sm7581591wix.0.2014.10.05.03.29.14 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 05 Oct 2014 03:29:15 -0700 (PDT) Date: Sun, 5 Oct 2014 12:29:12 +0200 From: Mateusz Guzik To: freebsd-hackers@freebsd.org Subject: fork: hold newly created processes Message-ID: <20141005102912.GB9262@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , freebsd-hackers@freebsd.org, kib@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Cc: kib@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 10:29:18 -0000 fork: hold newly created processes Consumers of fork1 -> do_fork receive new proc pointer, but nothing guarnatees its stability at that time. New process could already exit and be waited for, in which case we get a use after free. This is a temporary fix. diff --git a/sys/compat/linux/linux_fork.c b/sys/compat/linux/linux_fork.c index 316cf2a..8ad33f8 100644 --- a/sys/compat/linux/linux_fork.c +++ b/sys/compat/linux/linux_fork.c @@ -95,6 +95,8 @@ linux_fork(struct thread *td, struct linux_fork_args *args) sched_add(td2, SRQ_BORING); thread_unlock(td2); + PRELE(p2); + return (0); } @@ -139,6 +141,7 @@ linux_vfork(struct thread *td, struct linux_vfork_args *args) PROC_LOCK(p2); while (p2->p_flag & P_PPWAIT) cv_wait(&p2->p_pwait, &p2->p_mtx); + _PRELE(p2); PROC_UNLOCK(p2); return (0); @@ -287,13 +290,14 @@ linux_clone(struct thread *td, struct linux_clone_args *args) td->td_retval[0] = p2->p_pid; td->td_retval[1] = 0; + PROC_LOCK(p2); if (args->flags & LINUX_CLONE_VFORK) { /* wait for the children to exit, ie. emulate vfork */ - PROC_LOCK(p2); while (p2->p_flag & P_PPWAIT) cv_wait(&p2->p_pwait, &p2->p_mtx); - PROC_UNLOCK(p2); } + _PRELE(p2); + PROC_UNLOCK(p2); return (0); } diff --git a/sys/kern/init_main.c b/sys/kern/init_main.c index 141d438..af905a5 100644 --- a/sys/kern/init_main.c +++ b/sys/kern/init_main.c @@ -832,6 +832,7 @@ create_init(const void *udata __unused) audit_cred_proc1(newcred); #endif initproc->p_ucred = newcred; + _PRELE(initproc); PROC_UNLOCK(initproc); crfree(oldcred); cred_update_thread(FIRST_THREAD_IN_PROC(initproc)); diff --git a/sys/kern/kern_fork.c b/sys/kern/kern_fork.c index 8135afb..596a28c 100644 --- a/sys/kern/kern_fork.c +++ b/sys/kern/kern_fork.c @@ -107,6 +107,7 @@ sys_fork(struct thread *td, struct fork_args *uap) if (error == 0) { td->td_retval[0] = p2->p_pid; td->td_retval[1] = 0; + PRELE(p2); } return (error); } @@ -130,6 +131,7 @@ sys_pdfork(td, uap) if (error == 0) { td->td_retval[0] = p2->p_pid; td->td_retval[1] = 0; + PRELE(p2); error = copyout(&fd, uap->fdp, sizeof(fd)); } return (error); @@ -147,6 +149,7 @@ sys_vfork(struct thread *td, struct vfork_args *uap) if (error == 0) { td->td_retval[0] = p2->p_pid; td->td_retval[1] = 0; + PRELE(p2); } return (error); } @@ -166,6 +169,8 @@ sys_rfork(struct thread *td, struct rfork_args *uap) if (error == 0) { td->td_retval[0] = p2 ? p2->p_pid : 0; td->td_retval[1] = 0; + if (p2 != NULL) + PRELE(p2); } return (error); } @@ -359,7 +364,7 @@ do_fork(struct thread *td, int flags, struct proc *p2, struct thread *td2, struct vmspace *vm2, int pdflags) { struct proc *p1, *pptr; - int p2_held, trypid; + int trypid; struct filedesc *fd; struct filedesc_to_leader *fdtol; struct sigacts *newsigacts; @@ -367,7 +372,6 @@ do_fork(struct thread *td, int flags, struct proc *p2, struct thread *td2, sx_assert(&proctree_lock, SX_SLOCKED); sx_assert(&allproc_lock, SX_XLOCKED); - p2_held = 0; p1 = td->td_proc; /* @@ -674,6 +678,12 @@ do_fork(struct thread *td, int flags, struct proc *p2, struct thread *td2, p2->p_state = PRS_NORMAL; PROC_SUNLOCK(p2); + /* + * We return p2 pointer to the caller. Hold it so that it is + * guaranteed to remain valid. + */ + _PHOLD(p2); + #ifdef KDTRACE_HOOKS /* * Tell the DTrace fasttrap provider about the new process so that any @@ -696,8 +706,6 @@ do_fork(struct thread *td, int flags, struct proc *p2, struct thread *td2, td->td_dbgflags |= TDB_FORK; td->td_dbg_forked = p2->p_pid; td2->td_dbgflags |= TDB_STOPATFORK; - _PHOLD(p2); - p2_held = 1; } if (flags & RFPPWAIT) { td->td_pflags |= TDP_RFPPWAIT; @@ -733,8 +741,6 @@ do_fork(struct thread *td, int flags, struct proc *p2, struct thread *td2, PROC_LOCK(p2); while ((td2->td_dbgflags & TDB_STOPATFORK) != 0) cv_wait(&p2->p_dbgwait, &p2->p_mtx); - if (p2_held) - _PRELE(p2); PROC_UNLOCK(p2); } diff --git a/sys/kern/kern_kthread.c b/sys/kern/kern_kthread.c index 969c513..bb0e232 100644 --- a/sys/kern/kern_kthread.c +++ b/sys/kern/kern_kthread.c @@ -134,6 +134,8 @@ kproc_create(void (*func)(void *), void *arg, sched_add(td, SRQ_BORING); thread_unlock(td); + PRELE(p2); + return 0; } From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 17:15:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E78F48E for ; Sun, 5 Oct 2014 17:15:03 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0AE89F77 for ; Sun, 5 Oct 2014 17:15:02 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s95HEwTT085635 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Oct 2014 20:14:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s95HEwTT085635 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s95HEwtq085634; Sun, 5 Oct 2014 20:14:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 5 Oct 2014 20:14:58 +0300 From: Konstantin Belousov To: Mateusz Guzik , freebsd-hackers@freebsd.org Subject: Re: fork: hold newly created processes Message-ID: <20141005171457.GA26076@kib.kiev.ua> References: <20141005102912.GB9262@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141005102912.GB9262@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 17:15:03 -0000 On Sun, Oct 05, 2014 at 12:29:12PM +0200, Mateusz Guzik wrote: > fork: hold newly created processes > > Consumers of fork1 -> do_fork receive new proc pointer, but nothing > guarnatees its stability at that time. > > New process could already exit and be waited for, in which case we get a > use after free. Since the new process is the child of the current process, it can happen only if the code is self-inflicting. I can imagine that the only way to achieve it, do wait() in other thread. That said, there is no harm for the kernel state, since struct proc is type-stable, so we do not dereference a random memory, do you agree ? We could return non-existing or reused pid, but this can occur with your patch as well, since the same exit/wait could be done while forking thread executes syscall return code. From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 18:05:23 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7286D124; Sun, 5 Oct 2014 18:05:23 +0000 (UTC) Received: from mail-gw12.york.ac.uk (mail-gw12.york.ac.uk [144.32.129.162]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 36BD7759; Sun, 5 Oct 2014 18:05:22 +0000 (UTC) Received: from ury.york.ac.uk ([144.32.64.162]:32602) by mail-gw12.york.ac.uk with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1Xaq56-0004yU-F4; Sun, 05 Oct 2014 18:58:52 +0100 Date: Sun, 5 Oct 2014 18:58:51 +0100 (BST) From: Gavin Atkinson X-X-Sender: gavin@ury.york.ac.uk To: Alexander Tarasikov Subject: Re: Android Emulator for FreeBSD + FreeBSD/ARM port In-Reply-To: Message-ID: References: User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , freebsd-emulation@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 18:05:23 -0000 On Sun, 7 Sep 2014, Alexander Tarasikov wrote: > During summer as part of GSoC program I was working on porting FreeBSD > to the Android Emulator. > Besides, I have ported Android Emulator to run natively on x86_64 as opposed to > using linuxulator for 32-bit support. > > As for the kernel side, I have implemented the support for the > following hardware: > *IRQ, Timer, UART > *MMC > *Ethernet > *Framebuffer (using NEWCONS) > > It allows to mount rootfs and boot up to login prompt with raspberry > pi sd card image. I'm now in a position where I'm starting to look at getting this in shape ready to push it into the main tree. > As for the emulator, it's a bit complicated. FreeBSD boots fine if you > launch the emulator on Linux or Mac OS X. I have fixed some parts of > the build system and headers to make it compile and pass the tests on > FreeBSD. Unfortunately, the GUI doesn't work right now and only > console output (virtual UART) works. Firstly, I'd like to get the emulator into the ports tree. I was originally planning on using the Linux binary (I've been doing all of my testing so far with the Linux binary) but if you have patches for FreeBSD I think that's likely the best way forward, or it may make sense to import both? Then, I'd like to get the Goldfish code into the main FreeBSD tree. It would be nice to get at least bidirectional UART working before we can do that, are there any issues with the emulator that would prevent this? I've also not managed to get ethernet or the framebuffer working, though I've not looked deep into this and especially for the network interface it may be related to how I'm running the emulator - I guess you have been passing through a device into the emulator? I think once we can get the bidirectional UART fully functional, we can push this into the tree. Also, goldfish_mmc.c is missing a copyright statement - can you add one please? Thanks, Gavin From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 18:46:26 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA546FC4 for ; Sun, 5 Oct 2014 18:46:26 +0000 (UTC) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F115B0E for ; Sun, 5 Oct 2014 18:46:26 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hi2so2733554wib.15 for ; Sun, 05 Oct 2014 11:46:24 -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:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Mxg0+r09NCWD/QiGv7cIUthtQR+4rVCeg9yuS5u9lqw=; b=ezr/HSfHqY0+mupAMR1Z13t1f9qsttHIaXjDOAguEf9jU6iA2xkpChwXkerdUrBT3s jtgWgxxTyw2uplCxW6SEfdnIcM3PiRbrvgHSoBbyGravB0v+38IlIHwBB7mo0PcnxFmw 9L6sDLNPZiFaH6T5AdKwZyl7K1pd5oQqMXhIqFS1TA7oCRvf8nGvg8z8l3rmvQAqpXiS X7vUgKOxto2ETqL64AneiVtWBNjHA/MCsrckMYnA8QzxmgL/xqwNT9jfO1HuV7IgDXtZ 0L0MGGCflu+8K87i7T/EQAVMYiv+e1WxOGI3RFx7VxVwmRfriHQ2yXWb1m6/Kgo+b9v2 vf3A== X-Received: by 10.194.3.42 with SMTP id 10mr24043860wjz.98.1412534784722; Sun, 05 Oct 2014 11:46:24 -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 i1sm14733608wjx.32.2014.10.05.11.46.23 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 05 Oct 2014 11:46:23 -0700 (PDT) Date: Sun, 5 Oct 2014 20:46:21 +0200 From: Mateusz Guzik To: Konstantin Belousov Subject: Re: fork: hold newly created processes Message-ID: <20141005184620.GC9262@dft-labs.eu> Mail-Followup-To: Mateusz Guzik , Konstantin Belousov , freebsd-hackers@freebsd.org References: <20141005102912.GB9262@dft-labs.eu> <20141005171457.GA26076@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20141005171457.GA26076@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 18:46:27 -0000 On Sun, Oct 05, 2014 at 08:14:58PM +0300, Konstantin Belousov wrote: > On Sun, Oct 05, 2014 at 12:29:12PM +0200, Mateusz Guzik wrote: > > fork: hold newly created processes > > > > Consumers of fork1 -> do_fork receive new proc pointer, but nothing > > guarnatees its stability at that time. > > > > New process could already exit and be waited for, in which case we get a > > use after free. > Since the new process is the child of the current process, it can happen > only if the code is self-inflicting. I can imagine that the only way > to achieve it, do wait() in other thread. > Yes, the patch in question is an anti local dos measure. > That said, there is no harm for the kernel state, since struct proc is > type-stable, so we do not dereference a random memory, do you agree ? > We could return non-existing or reused pid, but this can occur with > your patch as well, since the same exit/wait could be done while forking > thread executes syscall return code. Pinning the process with PHOLD means *fork will always return the right pid. Of course the child could be gone by the time fork returns, but this is not a problem. In fork1 you can find: do_fork(td, flags, newproc, td2, vm2, pdflags); /* * Return child proc pointer to parent. */ *procp = newproc; if (flags & RFPROCDESC) { procdesc_finit(newproc->p_procdesc, fp_procdesc); fdrop(fp_procdesc, td); } racct_proc_fork_done(newproc); return (0); Here nothing guarantees newproc is stable and I managed to provoke a crash with null pointer dereference in procdesc_finit since it got a now cleared up process. I think it is possible it will get a different process, provided someone managed to fork it in the meantime. Also, although I didn't try to provoke anything, linux emulation layer does a lot of work with newly returned proc pointer. -- Mateusz Guzik From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 5 19:17:55 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DD67969C for ; Sun, 5 Oct 2014 19:17:54 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7DF41D76 for ; Sun, 5 Oct 2014 19:17:54 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s95JHnRh031243 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 5 Oct 2014 22:17:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s95JHnRh031243 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s95JHnY2031242; Sun, 5 Oct 2014 22:17:49 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 5 Oct 2014 22:17:49 +0300 From: Konstantin Belousov To: Mateusz Guzik , freebsd-hackers@freebsd.org Subject: Re: fork: hold newly created processes Message-ID: <20141005191749.GC26076@kib.kiev.ua> References: <20141005102912.GB9262@dft-labs.eu> <20141005171457.GA26076@kib.kiev.ua> <20141005184620.GC9262@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141005184620.GC9262@dft-labs.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2014 19:17:55 -0000 On Sun, Oct 05, 2014 at 08:46:21PM +0200, Mateusz Guzik wrote: > On Sun, Oct 05, 2014 at 08:14:58PM +0300, Konstantin Belousov wrote: > > On Sun, Oct 05, 2014 at 12:29:12PM +0200, Mateusz Guzik wrote: > > > fork: hold newly created processes > > > > > > Consumers of fork1 -> do_fork receive new proc pointer, but nothing > > > guarnatees its stability at that time. > > > > > > New process could already exit and be waited for, in which case we get a > > > use after free. > > Since the new process is the child of the current process, it can happen > > only if the code is self-inflicting. I can imagine that the only way > > to achieve it, do wait() in other thread. > > > > Yes, the patch in question is an anti local dos measure. > > > That said, there is no harm for the kernel state, since struct proc is > > type-stable, so we do not dereference a random memory, do you agree ? > > We could return non-existing or reused pid, but this can occur with > > your patch as well, since the same exit/wait could be done while forking > > thread executes syscall return code. > > Pinning the process with PHOLD means *fork will always return the right > pid. No, because, as you noted, the process may be already consumed by wait. And pid theoretically can be reused. > > Of course the child could be gone by the time fork returns, but this is > not a problem. > > In fork1 you can find: > do_fork(td, flags, newproc, td2, vm2, pdflags); > > /* > * Return child proc pointer to parent. > */ > *procp = newproc; > if (flags & RFPROCDESC) { > procdesc_finit(newproc->p_procdesc, fp_procdesc); > fdrop(fp_procdesc, td); > } > racct_proc_fork_done(newproc); > return (0); > > Here nothing guarantees newproc is stable and I managed to provoke a crash > with null pointer dereference in procdesc_finit since it got a now > cleared up process. Why not just move the two statements above into some place in the do_fork() where the p2 is not yet put on the runqueue ? This would avoid the need of all callers of fork* to care about hold. The racct_proc_fork_done() could be significantly improved by requiring the locked child, instead of locking it itself. If the 'correct' (for very vague definition of correct) pid is considered critical, td_retval[0] should be set also there. > > I think it is possible it will get a different process, provided someone > managed to fork it in the meantime. > > Also, although I didn't try to provoke anything, linux emulation layer > does a lot of work with newly returned proc pointer. Linux emulation does not use FreeBSD threads, so the issue probably does not m From owner-freebsd-hackers@FreeBSD.ORG Mon Oct 6 14:20:48 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 546FBE25 for ; Mon, 6 Oct 2014 14:20:48 +0000 (UTC) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailuogwprd01.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 031B515A for ; Mon, 6 Oct 2014 14:20:47 +0000 (UTC) Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s96EKihK025602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 6 Oct 2014 10:20:45 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s96EKihK025602 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1412605245; bh=+a3lK4d5XFkEEHBy9xcIIvHv2ho=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=jb+I2UXWv4TARoQ0USe0EyeS7xFYt1lmQuc6T4s+G3nDA6bNKYFEN4w1Yqrp3SnfA +FhfPIX9WfWn2+5cDRWYCM/qYNxUp/VfNh+avF+JI6zRTd/OkCbny6HXx7r/IBqcU9 Qb2S0W3PkftYZfrdD60HJjHXK7XlV1EdGbuLWecs= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s96EKihK025602 Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd02.lss.emc.com (RSA Interceptor) for ; Mon, 6 Oct 2014 10:20:09 -0400 Received: from mxhub32.corp.emc.com (mxhub32.corp.emc.com [128.222.70.172]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s96EK420023433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 6 Oct 2014 10:20:29 -0400 Received: from MXHUB103.corp.emc.com (10.253.50.16) by mxhub32.corp.emc.com (128.222.70.172) with Microsoft SMTP Server (TLS) id 8.3.327.1; Mon, 6 Oct 2014 10:20:13 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.33]) by MXHUB103.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Mon, 6 Oct 2014 10:20:12 -0400 From: "Meyer, Conrad" To: "freebsd-hackers@freebsd.org" Subject: Seeking reviewers for patch; PR 193873 Thread-Topic: Seeking reviewers for patch; PR 193873 Thread-Index: Ac/hb8PEavcCoEK4Q7+AD0LgMnmE/Q== Date: Mon, 6 Oct 2014 14:20:12 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.44.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Oct 2014 14:20:48 -0000 Hi all,=0A= =0A= The patch[0] dedupes dumpsys() somewhat, leaving MD-specific support code f= or a few things (map/unmap a region, flush CPU writeback cache, iterate phy= smem segments).=0A= =0A= jhibbits@ is taking a look, but he'd like another pair of eyeballs. The mor= e, the merrier! If someone could throw the latest patch up in phabricator f= or discussion, that would be awesome.=0A= =0A= I'll also need someone willing to commit it, I'm not a committer.=0A= =0A= Questions/concerns/feedback?=0A= =0A= Thanks,=0A= Conrad=0A= =0A= [0]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193873=0A= From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 04:38:54 2014 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8C8AD1E1 for ; Tue, 7 Oct 2014 04:38:54 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FC38DD9 for ; Tue, 7 Oct 2014 04:38:54 +0000 (UTC) Received: from Julian-MBP3.local (50-196-156-133-static.hfc.comcastbusiness.net [50.196.156.133]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s974cgdM097245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 6 Oct 2014 21:38:46 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <54336E4A.1010208@freebsd.org> Date: Tue, 07 Oct 2014 12:38:34 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: hackers@FreeBSD.ORG Subject: exiting gdbserver quietly Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 04:38:54 -0000 Does anyone know how to exit a gdb/gdbserver combination session without killing the attached program? gdbserver --attach PID attaches to the process ok, but I can't find a way to exit the session and leave the program running as it was.. Julian From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 06:53:29 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DC98236C for ; Tue, 7 Oct 2014 06:53:29 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (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 93F51E99 for ; Tue, 7 Oct 2014 06:53:28 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1XbOVW-00075e-5r for hackers@freebsd.org; Tue, 07 Oct 2014 09:44:26 +0300 From: Daniel Braniss Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: tar and / Message-Id: Date: Tue, 7 Oct 2014 09:44:25 +0300 To: hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 06:53:29 -0000 hi, for security reasons tar removes the leading /, which is fine. so I can chadir to /var/tmp, and do an extract there. The problem arises = when there is a file that is linked to /=85 Is there some way to drop that leading =91/=91 too? cheers, From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 13:53:55 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 028FA892 for ; Tue, 7 Oct 2014 13:53:55 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (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 C9E2B266 for ; Tue, 7 Oct 2014 13:53:54 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XbVD7-0001lY-LK; Tue, 07 Oct 2014 13:53:53 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s97DrpdV030532; Tue, 7 Oct 2014 07:53:52 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18jQY4dV2DtmUsne74osNaL X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: tar and / From: Ian Lepore To: Daniel Braniss In-Reply-To: References: Content-Type: text/plain; charset="windows-1251" Date: Tue, 07 Oct 2014 07:53:51 -0600 Message-ID: <1412690031.12052.202.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s97DrpdV030532 Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 13:53:55 -0000 On Tue, 2014-10-07 at 09:44 +0300, Daniel Braniss wrote: > hi, > for security reasons tar removes the leading /, which is fine. > so I can chadir to /var/tmp, and do an extract there. The problem arise= s when there > is a file that is linked to /=85 > Is there some way to drop that leading =91/=91 too? >=20 > cheers, >=20 No, because the leading slash there is the data within the link file, not metadata describing the file which tar stores separately and can easily manipulate. The moral is to avoid rooted links, even though that can lead to things nearly as bad, such as links that begin with 8 levels of ../ -- Ian From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 14:35:30 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D167F4CA for ; Tue, 7 Oct 2014 14:35:30 +0000 (UTC) Received: from mail-ig0-x229.google.com (mail-ig0-x229.google.com [IPv6:2607:f8b0:4001:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96CB59AE for ; Tue, 7 Oct 2014 14:35:30 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id uq10so6658144igb.2 for ; Tue, 07 Oct 2014 07:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=gG3rCmbiQbF3ccl1O9cS+y0syRFYuIW+XHy+wdKiQlc=; b=AOgR+tvsC4WAovWnhrNpfXwdyzmUNKBzyLcBPuvkcPhBfneSDlSdgIdgdo+Y0yvtaD LYe343SWTEjD8IUzTdUlmpmziPnevtoQCqtg9refMZD3IOyWFbneseCY+qBfxR0bDcOz 7oMOIoSoShJcA3ovCfh0/rx2YkRDufYNueoso= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=gG3rCmbiQbF3ccl1O9cS+y0syRFYuIW+XHy+wdKiQlc=; b=BQkr/d+z0gz5R33YRgx7HZedtHezf1HhMw8IxaGTJuRVIjI52SL404DklUAFnI8aj4 XIKec2dxiA+SjM3fLOBLExCLgd4MJStk+TlkUaYpbGHywGHYWF0jNnpjAQPJaQadOAz9 /oL5MYYZAafjBlJauB+1KpYxrBcwoZPkNFyRnIUCPiAYYx/IkrS9850QkEls0emVLvTQ fmuPwBt7l3WjMTt85RpvLHBnx2Z1LX8ntMIXNSmlZoo8YdxwIyc/vgXOODyanwDw1zWk bGZCUm3NUxa+k2Uc8XLeSRO0dQbopQ+FX1rddxsZ0hqopg1w6qtZ+wb/YajrXEMYwDrW JNDg== X-Gm-Message-State: ALoCoQnVMl7fdxnnfQn7n6TqD3ZLyHoHtKH9rwjWmsEKJs/oPLFOuDStiDP44OZSDA+UUw7NflHv X-Received: by 10.42.233.75 with SMTP id jx11mr5301229icb.22.1412692529891; Tue, 07 Oct 2014 07:35:29 -0700 (PDT) Received: from [192.168.8.21] ([66.195.151.70]) by mx.google.com with ESMTPSA id m9sm12182402igd.14.2014.10.07.07.35.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 Oct 2014 07:35:29 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: tar and / From: Jason Hellenthal In-Reply-To: Date: Tue, 7 Oct 2014 09:35:29 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Daniel Braniss X-Mailer: Apple Mail (2.1878.6) Cc: hackers@freebsd.org, Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 14:35:30 -0000 =46rom tar(1) o Archive entries can exploit symbolic links to restore files = to other directories. An archive can restore a symbolic link to another = directory, then use that link to restore a file into that directory. To guard against this, = tar checks each extracted path for symlinks. If the final path element is = a symlink, it will be removed and replaced with the archive entry. If -U is = specified, any intermediate symlink will also be unconditionally removed. If neither = -U nor -P is specified, tar will refuse to extract the entry. With that stated you might want to roll through your filesystem with = symlinks(1) [sysutils/symlinks]. Use of this to shorten, remove dangling = etc.. DESCRIPTION symlinks is a useful utility for maintainers of FTP sites, = CDROMs, and Linux software distributions. It scans directories for symbolic = links and lists them on stdout, often revealing flaws in the filesystem = tree. Each link is output with a classification of relative, absolute, = dan- gling, messy, lengthy, or other_fs. relative links are those expressed as paths relative to the = directory in which the links reside, usually independent of the mount = point of the filesystem. absolute links are those given as an absolute path from the root = direc- tory as indicated by a leading slash (/). dangling links are those for which the target of the link does = not cur- rently exist. This commonly occurs for absolute links when a = filesys- tem is mounted at other than its customary mount point (such as = when the normal root filesystem is mounted at /mnt after booting from = alter- native media). messy links are links which contain unnecessary slashes or dots = in the path. These are cleaned up as well when -c is specified. lengthy links are links which use "../" more than necessary in = the path (eg. /bin/vi -> ../bin/vim) These are only detected when -s is = speci- fied, and are only cleaned up when -c is also specified. other_fs are those links whose target currently resides on a = different filesystem from where symlinks was run (most useful with -r ). Hope this helps. On Oct 7, 2014, at 1:44, Daniel Braniss wrote: > hi,Ian Lepore > for security reasons tar removes the leading /, which is fine. > so I can chadir to /var/tmp, and do an extract there. The problem = arises when there > is a file that is linked to /=85 > Is there some way to drop that leading =91/=91 too? >=20 > cheers, >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" --=20 Jason Hellenthal Mobile: +1 (616) 953-0176 jhellenthal@DataIX.net JJH48-ARIN From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 16:22:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 422467AE; Tue, 7 Oct 2014 16:22:32 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1BE5898D; Tue, 7 Oct 2014 16:22:32 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 13FB4B99A; Tue, 7 Oct 2014 12:22:31 -0400 (EDT) From: John Baldwin To: freebsd-hackers@freebsd.org Subject: Re: fork: hold newly created processes Date: Tue, 7 Oct 2014 11:24:50 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.4-CBSD-20140415; KDE/4.5.5; amd64; ; ) References: <20141005102912.GB9262@dft-labs.eu> In-Reply-To: <20141005102912.GB9262@dft-labs.eu> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201410071124.50230.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 07 Oct 2014 12:22:31 -0400 (EDT) Cc: Mateusz Guzik , kib@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 16:22:32 -0000 On Sunday, October 05, 2014 6:29:12 am Mateusz Guzik wrote: > fork: hold newly created processes > > Consumers of fork1 -> do_fork receive new proc pointer, but nothing > guarnatees its stability at that time. > > New process could already exit and be waited for, in which case we get a > use after free. > > This is a temporary fix. As Konstantin noted, this is just a bug in the callers. If they want to access the proc pointer after calling fork(), they should use RF_STOPPED and setrunqueue() the first thread after they are finished working with it. -- John Baldwin From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 18:50:19 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A06BEB8 for ; Tue, 7 Oct 2014 18:50:19 +0000 (UTC) Received: from mail-la0-f53.google.com (mail-la0-f53.google.com [209.85.215.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D7A0D7F for ; Tue, 7 Oct 2014 18:50:18 +0000 (UTC) Received: by mail-la0-f53.google.com with SMTP id gq15so6849664lab.40 for ; Tue, 07 Oct 2014 11:50:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-type:content-transfer-encoding; bh=1/sTW2uFViVO2LyHAWZvAoYb+YOApSZ5PrXSw+f7gu8=; b=R5brjnvdBoVHyriitup+b0N0Cr+ae4bYphO4sTJLmIWwfX5kgSD8nv1MEJrRb2cwIc /NPUjHhMmt8u/K6+m763jkOTiVT0YBZCqUdVYs1wZiFH7H7DAwBXvw/gePXR4ES3t6Q8 LJzugH/sVntg7Ze2DWZPI5xppeSRfU/SSZEMJWsMuy90T5j9Sf9eaDqhNpfHMMNHlxI5 PCbyEOR7g2ETTJ2qKG0tGal52Wxb05fYMsjC8giQyP+F6n2GVMSSwR4pVss2mBpO+UWj fPexSlhjgSHlD4HIucMvwgCIdKfRedRON4nJx9ArLIyz8cxqKfsqnk7pldo//n29KTjO 4Brw== X-Gm-Message-State: ALoCoQk+sB9QpCK0MJc4Qsx1VaDR87E2ZybqxgZis2Nk4FqN2fm25CaW8C9xzMEBPGproTkVplzL X-Received: by 10.112.201.72 with SMTP id jy8mr5906962lbc.78.1412707810903; Tue, 07 Oct 2014 11:50:10 -0700 (PDT) Received: from raynote.ddteam.net (11-170-133-95.pool.ukrtel.net. [95.133.170.11]) by mx.google.com with ESMTPSA id bc1sm6967441lab.40.2014.10.07.11.50.09 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Oct 2014 11:50:09 -0700 (PDT) Date: Tue, 7 Oct 2014 21:48:36 +0300 From: Aleksandr Rybalko To: Tiwei Bie Subject: Re: [PATCH] hw.syscons.bell sysctl for vt (newcons) Message-Id: <20141007214836.919265ce46a3178e8cc92b47@ddteam.net> In-Reply-To: <1412483273-36665-1-git-send-email-btw@mail.ustc.edu.cn> References: <1412483273-36665-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: Sylpheed 3.4.2 (GTK+ 2.24.22; amd64-portbld-freebsd11.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 18:50:19 -0000 On Sun, 5 Oct 2014 12:27:53 +0800 Tiwei Bie wrote: > Hi All, > > I think the hw.syscons.bell sysctl provided by syscons is a very convenient method > to disable the sound alert in FreeBSD. But I haven't found the similar interface > in vt. So I have written a patch to implement the sysctl 'kern.vt.enable_bell' > which is similar to 'hw.syscons.bell' for vt. Hello Tiwei! Commited in r272715. Thanks a lot! > > --- > sys/dev/vt/vt_core.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/sys/dev/vt/vt_core.c b/sys/dev/vt/vt_core.c > index 2dd7e3f..a8cdedb 100644 > --- a/sys/dev/vt/vt_core.c > +++ b/sys/dev/vt/vt_core.c > @@ -120,6 +120,7 @@ const struct terminal_class vt_termclass = { > > static SYSCTL_NODE(_kern, OID_AUTO, vt, CTLFLAG_RD, 0, "vt(9) parameters"); > VT_SYSCTL_INT(enable_altgr, 1, "Enable AltGr key (Do not assume R.Alt as Alt)"); > +VT_SYSCTL_INT(enable_bell, 1, "Enable bell"); > VT_SYSCTL_INT(debug, 0, "vt(9) debug level"); > VT_SYSCTL_INT(deadtimer, 15, "Time to wait busy process in VT_PROCESS mode"); > VT_SYSCTL_INT(suspendswitch, 1, "Switch to VT0 before suspend"); > @@ -904,6 +905,9 @@ vtterm_bell(struct terminal *tm) > struct vt_window *vw = tm->tm_softc; > struct vt_device *vd = vw->vw_device; > > + if (!vt_enable_bell) > + return; > + > if (vd->vd_flags & VDF_QUIET_BELL) > return; > > @@ -915,6 +919,9 @@ vtterm_beep(struct terminal *tm, u_int param) > { > u_int freq, period; > > + if (!vt_enable_bell) > + return; > + > if ((param == 0) || ((param & 0xffff) == 0)) { > vtterm_bell(tm); > return; > -- > 2.1.0 > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" -- Aleksandr Rybalko From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 7 19:32:26 2014 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EBA7AF6C; Tue, 7 Oct 2014 19:32:25 +0000 (UTC) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (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 6342E374; Tue, 7 Oct 2014 19:32:25 +0000 (UTC) X-AuditID: 12074423-f799d6d00000337c-7f-54343e959fc4 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 2E.FF.13180.59E34345; Tue, 7 Oct 2014 15:27:17 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s97JRGiC030012; Tue, 7 Oct 2014 15:27:16 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s97JRESJ020378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Oct 2014 15:27:15 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s97JREJS014454; Tue, 7 Oct 2014 15:27:14 -0400 (EDT) Date: Tue, 7 Oct 2014 15:27:13 -0400 (EDT) From: Benjamin Kaduk X-X-Sender: kaduk@multics.mit.edu To: FreeBSD Current , FreeBSD Hackers Subject: FreeBSD 2014Q3 status reports due today! Message-ID: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKIsWRmVeSWpSXmKPExsUixG6nrjvVziTEoPmUqMWua6fZLea8+cBk sX3zP0YHZo8Zn+azBDBGcdmkpOZklqUW6dslcGVs2jORveAOT8Wh8+/ZGhhPcHUxcnJICJhI zJu6mQnCFpO4cG89WxcjF4eQwGwmiR9Xf7JDOBsYJT5dWskE4Rxkkvh59ysrSIuQQL3E0gsT 2EFsFgEtiUUrj7OB2GwCahLrV1xjhhirKLH51CQwW0QgU+LPmo9g9cIChhJr3p4Fs3kFHCX6 u68zgtiiAjoSq/dPYYGIC0qcnPkEzGYGmr98+jaWCYz8s5CkZiFJLWBkWsUom5JbpZubmJlT nJqsW5ycmJeXWqRrppebWaKXmlK6iREcei7KOxj/HFQ6xCjAwajEw7tCyzhEiDWxrLgy9xCj JAeTkigvo7lJiBBfUn5KZUZicUZ8UWlOavEhRgkOZiUR3imSQDnelMTKqtSifJiUNAeLkjjv ph98IUIC6YklqdmpqQWpRTBZGQ4OJQleM1ugRsGi1PTUirTMnBKENBMHJ8hwHqDhtiA1vMUF ibnFmekQ+VOMilLivI9sgBICIImM0jy4XlhqeMUoDvSKMO9dkCoeYFqB634FNJgJaPCqfmOQ wSWJCCmpBsZzv8Mfvklec0X7+buAFAdXd6vM+8zHVvE+1JK/E63k+Sj73ZK0olymWRdWcanF Te25fr5c+Ffe7zvS9Wuv3pG5VuQnsobBMcqt/+576d//5Y7PbFy76N4JufPclSeW/1G/wx2k 2Hn0aqRS5YJZp/oSHBvs8/7efJ/ctaGg6Xh7MONmHpHwnGglluKMREMt5qLiRAAl82dM6AIA AA== X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Oct 2014 19:32:26 -0000 Dear FreeBSD Community, As previously announced, today is the deadline for submitting items for the next FreeBSD Quarterly Status Update, covering work done in July through September. If you still need some time to prepare a submission, please note that we will continue to accept submissions as we work on assembling the report, but cannot guarantee that anything received after October 10 will be included. Status report submissions do not have to be very long. They may be about anything happening in the FreeBSD project and community, and provide a great way to inform FreeBSD users and developers about what you're working on. Submission of reports is not restricted to committers. Anyone doing anything interesting and FreeBSD-related can -- and should -- write one! The preferred and easiest submission method is to use the XML generator [1] with the results emailed to the status report team at monthly@FreeBSD.org . There is also an XML template [2] which can be filled out manually and attached if preferred. For the expected content and style, please study our guidelines on how to write a good status report [3]. You can also review previous issues [4][5] for ideas on the style and format. We are looking forward to all of your 2014Q3 reports! Thanks, Ben (on behalf of monthly@) [1] http://www.freebsd.org/cgi/monthly.cgi [2] http://www.freebsd.org/news/status/report-sample.xml [3] http://www.freebsd.org/news/status/howto.html [4] http://www.freebsd.org/news/status/report-2014-01-2014-03.html [4] http://www.freebsd.org/news/status/report-2014-04-2014-06.html From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 02:44:06 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 24047F8D for ; Wed, 8 Oct 2014 02:44:06 +0000 (UTC) Received: from ustc.edu.cn (email6.ustc.edu.cn [IPv6:2001:da8:d800::8]) by mx1.freebsd.org (Postfix) with ESMTP id 528FF6D9 for ; Wed, 8 Oct 2014 02:44:04 +0000 (UTC) Received: from freebsd.my.domain (unknown [211.86.158.26]) by newmailweb.ustc.edu.cn (Coremail) with SMTP id LkAmygBXORbkpDRUoLAyAA--.6026S2; Wed, 08 Oct 2014 10:43:53 +0800 (CST) From: Tiwei Bie To: ray@ddteam.net Subject: Re: [PATCH] hw.syscons.bell sysctl for vt (newcons) Date: Wed, 8 Oct 2014 10:43:39 +0800 Message-Id: <1412736219-32730-1-git-send-email-btw@mail.ustc.edu.cn> X-Mailer: git-send-email 2.1.0 X-CM-TRANSID: LkAmygBXORbkpDRUoLAyAA--.6026S2 X-Coremail-Antispam: 1UD129KBjvJXoW7tFWfCFWDKw1xJFW3Ar1rXrb_yoW8KFy8pF yDAF4UCFWDJr1ruw1Iqw1FyF1UAw4xtrW8G345C3Wjva90yF18X3WFyr4Fgr4UZr4rCFyf ArWkC3s5WryDJFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUk2b7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48JMxkIecxEwVAFwVW8JwCF04k2 0xvY0x0EwIxGrwCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI 8I3I0E7480Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41l IxAIcVC0I7IYx2IY67AKxVWUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIx AIcVCF04k26cxKx2IYs7xG6rW3Jr0E3s1lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcVC2 z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUc1v3UUUUU X-CM-SenderInfo: xewzqzxdloh3xvwfhvlgxou0/1tbiAQULAVQhl8LLMwAAsW Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 02:44:06 -0000 On 2014-10-08 02:48:36 (Wednesday), Aleksandr Rybalko wrote: > On Sun, 5 Oct 2014 12:27:53 +0800 > Tiwei Bie wrote: > > > Hi All, > > > > I think the hw.syscons.bell sysctl provided by syscons is a very convenient method > > to disable the sound alert in FreeBSD. But I haven't found the similar interface > > in vt. So I have written a patch to implement the sysctl 'kern.vt.enable_bell' > > which is similar to 'hw.syscons.bell' for vt. > > Hello Tiwei! > > Commited in r272715. > > Thanks a lot! > It's my pleasure! ;-) Tiwei Bie > > > > --- > > sys/dev/vt/vt_core.c | 7 +++++++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/sys/dev/vt/vt_core.c b/sys/dev/vt/vt_core.c > > index 2dd7e3f..a8cdedb 100644 > > --- a/sys/dev/vt/vt_core.c > > +++ b/sys/dev/vt/vt_core.c > > @@ -120,6 +120,7 @@ const struct terminal_class vt_termclass = { > > > > static SYSCTL_NODE(_kern, OID_AUTO, vt, CTLFLAG_RD, 0, "vt(9) parameters"); > > VT_SYSCTL_INT(enable_altgr, 1, "Enable AltGr key (Do not assume R.Alt as Alt)"); > > +VT_SYSCTL_INT(enable_bell, 1, "Enable bell"); > > VT_SYSCTL_INT(debug, 0, "vt(9) debug level"); > > VT_SYSCTL_INT(deadtimer, 15, "Time to wait busy process in VT_PROCESS mode"); > > VT_SYSCTL_INT(suspendswitch, 1, "Switch to VT0 before suspend"); > > @@ -904,6 +905,9 @@ vtterm_bell(struct terminal *tm) > > struct vt_window *vw = tm->tm_softc; > > struct vt_device *vd = vw->vw_device; > > > > + if (!vt_enable_bell) > > + return; > > + > > if (vd->vd_flags & VDF_QUIET_BELL) > > return; > > > > @@ -915,6 +919,9 @@ vtterm_beep(struct terminal *tm, u_int param) > > { > > u_int freq, period; > > > > + if (!vt_enable_bell) > > + return; > > + > > if ((param == 0) || ((param & 0xffff) == 0)) { > > vtterm_bell(tm); > > return; > > -- > > 2.1.0 > > > > > > _______________________________________________ > > freebsd-hackers@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > > > -- > Aleksandr Rybalko > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 06:24:31 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 43A20FA5; Wed, 8 Oct 2014 06:24:31 +0000 (UTC) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.12]) (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 EB1C1D15; Wed, 8 Oct 2014 06:24:30 +0000 (UTC) Received: from th-04.cs.huji.ac.il ([132.65.80.125]) by kabab.cs.huji.ac.il with esmtp id 1Xbkfj-000PCp-TZ; Wed, 08 Oct 2014 09:24:27 +0300 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: tar and / From: Daniel Braniss In-Reply-To: Date: Wed, 8 Oct 2014 09:24:26 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Jason Hellenthal X-Mailer: Apple Mail (2.1878.6) Cc: hackers@freebsd.org, Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 06:24:31 -0000 A facts that I did not mention: the tar file is created by ports when requesting =91package=92, = it now adds /usr/local making extraction difficult for those that use nfs/amd for /usr/local (the solution is to extract the files in /var/tmp, and re-taring without = the /usr/local :-) to my surprise, even though tar complains that it can=92t do the link to = / it actually does the link!! notice that I mentioned =91link', not symlink! which of course brings = the question why some ports insist on link, and not symlink is beyond me. thanks danny On Oct 7, 2014, at 5:35 PM, Jason Hellenthal = wrote: > =46rom tar(1) >=20 > o Archive entries can exploit symbolic links to restore = files to other directories. > An archive can restore a symbolic link to another = directory, then use that link to > restore a file into that directory. To guard against = this, tar checks each > extracted path for symlinks. If the final path element is = a symlink, it will be > removed and replaced with the archive entry. If -U is = specified, any intermediate > symlink will also be unconditionally removed. If neither = -U nor -P is specified, > tar will refuse to extract the entry. >=20 > With that stated you might want to roll through your filesystem with = symlinks(1) [sysutils/symlinks]. Use of this to shorten, remove dangling = etc.. >=20 > DESCRIPTION > symlinks is a useful utility for maintainers of FTP sites, = CDROMs, and > Linux software distributions. It scans directories for symbolic = links > and lists them on stdout, often revealing flaws in the = filesystem tree. >=20 > Each link is output with a classification of relative, = absolute, dan- > gling, messy, lengthy, or other_fs. >=20 > relative links are those expressed as paths relative to the = directory > in which the links reside, usually independent of the mount = point of > the filesystem. >=20 > absolute links are those given as an absolute path from the root = direc- > tory as indicated by a leading slash (/). >=20 > dangling links are those for which the target of the link does = not cur- > rently exist. This commonly occurs for absolute links when a = filesys- > tem is mounted at other than its customary mount point (such = as when > the normal root filesystem is mounted at /mnt after booting from = alter- > native media). >=20 > messy links are links which contain unnecessary slashes or dots = in the > path. These are cleaned up as well when -c is specified. >=20 > lengthy links are links which use "../" more than necessary in = the path > (eg. /bin/vi -> ../bin/vim) These are only detected when -s is = speci- > fied, and are only cleaned up when -c is also specified. >=20 > other_fs are those links whose target currently resides on a = different > filesystem from where symlinks was run (most useful with -r ). >=20 > Hope this helps. >=20 > On Oct 7, 2014, at 1:44, Daniel Braniss wrote: >=20 >> hi,Ian Lepore >> for security reasons tar removes the leading /, which is fine. >> so I can chadir to /var/tmp, and do an extract there. The problem = arises when there >> is a file that is linked to /=85 >> Is there some way to drop that leading =91/=91 too? >>=20 >> cheers, >>=20 >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" >=20 > --=20 > Jason Hellenthal > Mobile: +1 (616) 953-0176 > jhellenthal@DataIX.net > JJH48-ARIN >=20 From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 12:29:07 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D674A6A9 for ; Wed, 8 Oct 2014 12:29:07 +0000 (UTC) Received: from puchar.net (puchar.net [188.252.31.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "puchar.net", Issuer "puchar.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4B6E48DD for ; Wed, 8 Oct 2014 12:29:06 +0000 (UTC) Received: Received: from 127.0.0.1 (localhost [127.0.0.1]) by puchar.net (8.14.9/8.14.9) with ESMTP id s98CNP7e089193 for ; Wed, 8 Oct 2014 14:23:25 +0200 (CEST) (envelope-from wojtek@puchar.net) X-Authentication-Warning: puchar.net: Host puchar-wojtek.intra [10.0.224.6] claimed to be [10.0.224.6] Date: Wed, 8 Oct 2014 14:23:28 +0200 (CEST) From: Wojciech Puchar X-X-Sender: wojtek@laptop To: freebsd-hackers@freebsd.org Subject: ppp and set dial Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (puchar.net [10.0.1.1]); Wed, 08 Oct 2014 14:23:26 +0200 (CEST) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 12:29:07 -0000 is there somewhere complete manual about set dial chatscript syntax i need to do AT wait for OK or ERROR (but one line answer) AT From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 14:42:32 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5916876F for ; Wed, 8 Oct 2014 14:42:32 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0091.outbound.protection.outlook.com [65.55.169.91]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 03CE19DC for ; Wed, 8 Oct 2014 14:42:30 +0000 (UTC) Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0943.namprd08.prod.outlook.com (25.160.131.26) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 8 Oct 2014 14:42:22 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.00.1039.011; Wed, 8 Oct 2014 14:42:22 +0000 From: "Pokala, Ravi" To: "freebsd-hackers@freebsd.org" Subject: Re: Seeking reviewers for patch; PR 193873 Thread-Topic: Seeking reviewers for patch; PR 193873 Thread-Index: AQHP4wYRwsbUBpMNTk6xd1JtizXBKg== Date: Wed, 8 Oct 2014 14:42:22 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [24.6.178.251] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0943; x-forefront-prvs: 0358535363 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(13464003)(52314003)(164054003)(53754006)(189002)(51704005)(199003)(87936001)(46102003)(19580405001)(97736003)(50986999)(2351001)(31966008)(110136001)(77096002)(2656002)(107886001)(19580395003)(99286002)(76482002)(106116001)(54356999)(80022003)(85852003)(15975445006)(95666004)(83506001)(85306004)(66066001)(512954002)(64706001)(21056001)(92726001)(4396001)(20776003)(120916001)(92566001)(99396003)(106356001)(107046002)(86362001)(101416001)(105586002)(122556002)(40100002)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0943; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: panasas.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 14:42:32 -0000 -----Original Message----- >Date: Mon, 6 Oct 2014 14:20:12 +0000 >From: "Meyer, Conrad" >To: "freebsd-hackers@freebsd.org" >Subject: Seeking reviewers for patch; PR 193873 >Message-ID: > >Content-Type: text/plain; charset=3D"us-ascii" > >Hi all, > >The patch[0] dedupes dumpsys() somewhat, leaving MD-specific support code >for a few things (map/unmap a region, flush CPU writeback cache, iterate >physmem segments). > >jhibbits@ is taking a look, but he'd like another pair of eyeballs. The >more, the merrier! If someone could throw the latest patch up in >phabricator for discussion, that would be awesome. > >I'll also need someone willing to commit it, I'm not a committer. > >Questions/concerns/feedback? Hi Conrad, As mentioned in another thread ([1], [2]), I'm looking at dumping on systems w/ AF-4Kn drives (on a fairly old version of FreeBSD). Unfortunately, I'm not at all familiar w/ the process. I'm going to pick at it a few more days, but will probably end up having to punt and dumpsys onto a 512n or AF-512e device. But, since you are refactoring all this code in -CURRENT anyway, I think it would be awesome if you could look to the future and make it work w/o assuming that dump device block size is DEV_BSIZE; it would be better to use the sector size, as returned (for example) by ioctl(DIOCGSECTORSIZE). That won't help me now, but hopefully it will help everyone in the future. Thanks, Ravi [1]:=20 https://lists.freebsd.org/pipermail/freebsd-hackers/2014-September/046164.h tml [2]:=20 https://lists.freebsd.org/pipermail/freebsd-hackers/2014-October/046181.htm l >Thanks, >Conrad > >[0]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193873 From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 15:14:51 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1FC7435 for ; Wed, 8 Oct 2014 15:14:51 +0000 (UTC) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 470B3D49 for ; Wed, 8 Oct 2014 15:14:51 +0000 (UTC) Received: by mail-lb0-f176.google.com with SMTP id p9so8449926lbv.35 for ; Wed, 08 Oct 2014 08:14:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=69CRMLQJpaxOozFXvDh1pKcyqZaQKHBTH4pCpRrw/bs=; b=hraSYFgCf7/qcoxW3Ftcrns6eNapgVSd7dq6jlTH3/fAJkm1Svc3rVcvmadxCJYu9G 5GpTOSLYq2m2tCT0mG0EV13wWna2GKgO8ibyzohoPX6kWd4kiuQEzj064k3+znSG0LKg WMOZ8HrfXxc8SrhNRY7BWL6O6opXvZE3eoKZ557t+jSGUV8KUXlX7xuIRV9CYP6MtNl0 Hti9p4D1fEAoewZ3Fa9ajcE5b0Y2UxlKHiikJ+13XzVrDaRGOJoD0vwco8U33s8B+jtZ ytWgdpBfDnidPG3nWHXQ5AbHbUak4J8mjFNS7ormPsqg9IVVHT7L9AV85++ZmKZLWsUW GXEg== X-Received: by 10.152.204.231 with SMTP id lb7mr12080406lac.44.1412781288835; Wed, 08 Oct 2014 08:14:48 -0700 (PDT) Received: from ?IPv6:2a02:6b8::408:2c61:a8e:6f08:d86a? ([2a02:6b8:0:408:2c61:a8e:6f08:d86a]) by mx.google.com with ESMTPSA id j1sm122968lag.7.2014.10.08.08.14.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 08:14:48 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: mmap() question From: Dmitry Sivachenko In-Reply-To: <20131012095919.GI41229@kib.kiev.ua> Date: Wed, 8 Oct 2014 19:14:45 +0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5C10922E-7030-4C89-9FD3-DA770E462067@gmail.com> References: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> <20131011051702.GE41229@kib.kiev.ua> <20131012095919.GI41229@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1878.6) Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 15:14:51 -0000 On 12 =D0=BE=D0=BA=D1=82. 2013 =D0=B3., at 13:59, Konstantin Belousov = wrote: >=20 > I was not able to reproduce the situation locally. I even tried to = start > a lot of threads accessing the mapped regions, to try to outrun the > pagedaemon. The user threads sleep on the disk read, while pagedaemon > has a lot of time to rebalance the queues. It might be a case when SSD > indeed makes a difference. >=20 > Still, I see how this situation could appear. The code, which triggers > OOM, never fires if there is a free space in the swapfile, so the > absense of swap is neccessary condition to trigger the bug. Next, OOM > calculation does not account for a possibility that almost all pages = on > the queues can be reused. It just fires if free pages depleted too = much > or free target cannot be reached. >=20 > IMO one of the possible solution is to account the queued pages in > addition to the swap space. This is not entirely accurate, since some > pages on the queues cannot be reused, at least transiently. Most = precise > algorithm would count the hold and busy pages globally, and substract > this count from queues length, but it is probably too costly. >=20 > Instead, I think we could rely on the numbers which are counted by > pagedaemon threads during the passes. Due to the transient nature of = the > pagedaemon failures, this should be fine. >=20 > Below is the prototype patch, against HEAD. It is not applicable to > stable, please use HEAD kernel for test. Hello, any chance to commit this patch? Thanks! >=20 > diff --git a/sys/sys/vmmeter.h b/sys/sys/vmmeter.h > index d2ad920..ee5159a 100644 > --- a/sys/sys/vmmeter.h > +++ b/sys/sys/vmmeter.h > @@ -93,9 +93,10 @@ struct vmmeter { > u_int v_free_min; /* (c) pages desired free */ > u_int v_free_count; /* (f) pages free */ > u_int v_wire_count; /* (a) pages wired down */ > - u_int v_active_count; /* (q) pages active */ > + u_int v_active_count; /* (a) pages active */ > u_int v_inactive_target; /* (c) pages desired inactive */ > - u_int v_inactive_count; /* (q) pages inactive */ > + u_int v_inactive_count; /* (a) pages inactive */ > + u_int v_queue_sticky; /* (a) pages on queues but cannot = process */ > u_int v_cache_count; /* (f) pages on cache queue */ > u_int v_cache_min; /* (c) min pages desired on cache queue = */ > u_int v_cache_max; /* (c) max pages in cached obj (unused) = */ > diff --git a/sys/vm/vm_meter.c b/sys/vm/vm_meter.c > index 713a2be..4bb1f1f 100644 > --- a/sys/vm/vm_meter.c > +++ b/sys/vm/vm_meter.c > @@ -316,6 +316,7 @@ VM_STATS_VM(v_active_count, "Active pages"); > VM_STATS_VM(v_inactive_target, "Desired inactive pages"); > VM_STATS_VM(v_inactive_count, "Inactive pages"); > VM_STATS_VM(v_cache_count, "Pages on cache queue"); > +VM_STATS_VM(v_queue_sticky, "Pages which cannot be moved from = queues"); > VM_STATS_VM(v_cache_min, "Min pages on cache queue"); > VM_STATS_VM(v_cache_max, "Max pages on cached queue"); > VM_STATS_VM(v_pageout_free_min, "Min pages reserved for kernel"); > diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h > index 7846702..6943a0e 100644 > --- a/sys/vm/vm_page.h > +++ b/sys/vm/vm_page.h > @@ -226,6 +226,7 @@ struct vm_domain { > long vmd_segs; /* bitmask of the segments */ > boolean_t vmd_oom; > int vmd_pass; /* local pagedaemon pass */ > + int vmd_queue_sticky; /* pages on queues which cannot be = processed */ > struct vm_page vmd_marker; /* marker for pagedaemon private use = */ > }; >=20 > diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c > index 5660b56..a62cf97 100644 > --- a/sys/vm/vm_pageout.c > +++ b/sys/vm/vm_pageout.c > @@ -896,7 +896,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) > { > vm_page_t m, next; > struct vm_pagequeue *pq; > - int page_shortage, maxscan, pcount; > + int failed_scan, page_shortage, maxscan, pcount; > int addl_page_shortage; > vm_object_t object; > int act_delta; > @@ -960,6 +960,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) > */ > pq =3D &vmd->vmd_pagequeues[PQ_INACTIVE]; > maxscan =3D pq->pq_cnt; > + failed_scan =3D 0; > vm_pagequeue_lock(pq); > queues_locked =3D TRUE; > for (m =3D TAILQ_FIRST(&pq->pq_pl); > @@ -1012,6 +1013,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) > vm_page_unlock(m); > VM_OBJECT_WUNLOCK(object); > addl_page_shortage++; > + failed_scan++; > continue; > } >=20 > @@ -1075,6 +1077,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) > * loop over the active queue below. > */ > addl_page_shortage++; > + failed_scan++; > goto relock_queues; > } >=20 > @@ -1229,6 +1232,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) > */ > if (vm_page_busied(m)) { > vm_page_unlock(m); > + failed_scan++; > goto unlock_and_continue; > } >=20 > @@ -1241,6 +1245,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) > vm_page_requeue_locked(m); > if (object->flags & = OBJ_MIGHTBEDIRTY) > vnodes_skipped++; > + failed_scan++; > goto unlock_and_continue; > } > vm_pagequeue_unlock(pq); > @@ -1386,6 +1391,11 @@ relock_queues: > m =3D next; > } > vm_pagequeue_unlock(pq); > + > + atomic_add_int(&cnt.v_queue_sticky, failed_scan - > + vmd->vmd_queue_sticky); > + vmd->vmd_queue_sticky =3D failed_scan; > + > #if !defined(NO_SWAPPING) > /* > * Idle process swapout -- run once per second. > @@ -1433,10 +1443,15 @@ static int vm_pageout_oom_vote; > static void > vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass) > { > + u_int queues_count; > int old_vote; >=20 > - if (pass <=3D 1 || !((swap_pager_avail < 64 && = vm_page_count_min()) || > - (swap_pager_full && vm_paging_target() > 0))) { > + queues_count =3D cnt.v_active_count + cnt.v_inactive_count - > + cnt.v_queue_sticky; > + if (pass <=3D 1 || !((swap_pager_avail < 64 && = vm_page_count_min() && > + queues_count <=3D cnt.v_free_min) || > + (swap_pager_full && vm_paging_target() > 0 && > + queues_count <=3D vm_paging_target()))) { > if (vmd->vmd_oom) { > vmd->vmd_oom =3D FALSE; > atomic_subtract_int(&vm_pageout_oom_vote, 1); From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 16:03:33 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF3AED2E for ; Wed, 8 Oct 2014 16:03:33 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:214:c2ff:fe64:b2d3]) (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 D019639F for ; Wed, 8 Oct 2014 16:03:33 +0000 (UTC) Received: from [IPv6:2001:470:1f07:93::2] (unknown [IPv6:2001:470:1f07:93::2]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: ryao) by smtp.gentoo.org (Postfix) with ESMTPSA id 220EE33FB12; Wed, 8 Oct 2014 16:03:31 +0000 (UTC) Message-ID: <54356049.9040009@gentoo.org> Date: Wed, 08 Oct 2014 12:03:21 -0400 From: Richard Yao User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dmitry Sivachenko , "hackers@freebsd.org" Subject: Re: mmap() question References: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> In-Reply-To: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qbfRIPaAgtlsTVMQ2WRRaraT7hWhDM8am" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 16:03:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qbfRIPaAgtlsTVMQ2WRRaraT7hWhDM8am Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It might be worthwhile to use madvise() in your code: http://man7.org/linux/man-pages/man2/madvise.2.html On 10/09/2013 07:42 AM, Dmitry Sivachenko wrote: > Hello! >=20 > I have a program which mmap()s a lot of large files (total size more th= at RAM and I have no swap), but it needs only small parts of that files a= t a time. >=20 > My understanding is that when using mmap when I access some memory regi= on OS reads the relevant portion of that file from disk and caches the re= sult in memory. If there is no free memory, OS will purge previously rea= d part of mmap'ed file to free memory for the new chunk. >=20 > But this is not the case. I use the following simple program which get= s list of files as command line arguments, mmap()s them all and then sele= cts random file and random 1K parts of that file and computes a XOR of by= tes from that region. > After some time the program dies: > pid 63251 (a.out), uid 1232, was killed: out of swap space >=20 > It seems I incorrectly understand how mmap() works, can you please clar= ify what's going wrong? >=20 > I expect that program to run indefinitely, purging some regions out of = RAM and reading the relevant parts of files. >=20 > Thanks! >=20 > #include > #include > #include > #include > #include > #include > #include > #include > #include >=20 > struct f_data { > char *beg; > off_t size; > }; >=20 > int > main(int argc, char* argv[]) { > if (argc < 2) { > fprintf(stderr, "Usage: %s ...\n", argv[0]); > exit(0); > } > int i, j, fd; > struct stat st; > struct f_data FILES[500]; > int NUM_FILES; > void *p; > NUM_FILES =3D argc - 1; > for (i=3D1; i < argc; i++) { > printf("%s... ", argv[i]); > if ((fd =3D open(argv[i], O_RDONLY)) < 0) > errx(1, "open"); > if (fstat(fd, &st) !=3D 0) > errx(1, "fstat"); > if ((p =3D mmap(NULL, st.st_size, PROT_READ, MAP_NOCORE, fd, 0)= ) =3D=3D MAP_FAILED) > errx(1, "mmap"); > FILES[i-1].beg =3D (char*)p; > FILES[i-1].size =3D st.st_size; > if (msync(p, st.st_size, MS_INVALIDATE) !=3D 0) > errx(1, "msync"); > printf("Ok.\n"); > } > char chk =3D 0; > while(1) { > int rf =3D floor((double)random() / 2147483647 * NUM_FILES); > off_t offs =3D floor((double)random() / 2147483647 * (FILES[rf]= =2Esize - 1024)); > for (j=3D0; j<1024; j++) > chk ^=3D *(FILES[rf].beg + offs + j); > } > return 0; > } >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.o= rg" >=20 --qbfRIPaAgtlsTVMQ2WRRaraT7hWhDM8am Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJUNWBOAAoJECDuEZm+6ExkNX0P/iyUJNHnAXcztp3DoMxlDkKX tatK+LBM+QL/+hFcIE4t4UDdSZ3g5+JN4lCCShuFZHH8UtJcU8BwLmAJhlsBlE2q d3o40SO96eNkelw1ymgBNdzFhb44/PjAy9DkWDMV1tlWX0oi2BTqmeEyf908rASJ odWh42+YwiLRPo+iTAqebIxix4jP9P9mXWEXjbHsNZhrpI6Oqu/povAUaxWMBpy+ EoXagg7trzJ3JCLU3rhamo/bOLivLmZsWZlAAYkAxiy6JArUs3wHtL43A0xsn6z8 xuY3dBcCyGXawWkz9nR8+Z1ydy7xoVH/S1UPsiZiHd8z/exGwQn6S7YGBuYTmf6u CJscCFEo9WV+U7f51FI71zeNEnNBxRoZBg+ePVDurhmdUge4/2k3gp2GKJ0SkHWf sMgQ2UNJ+fYfTDSDboIeMlwiuhuXaS3iYZkAu2SlBNdhczjSCj7IfhZHbPfaZt3C pr1uiBGF/txKWLC6YT6qNHv5oG+TtamJcs6DHPExXvCAx3vQN0C/yA9uVg75ZxCP Xo0HgJALAmzqzjJ4wsB+zWMLvU1dC3lfIf7uxEQvWamX0/wpQGH+DuTM5GLBq0Lg wUeXD4MxZT05EOyJMfFK/NR3lbaTTxmil9CQmu3VrkxNw+jEJboBdmfdigcLNC9B 6XG46PcYQsSWHn2cWWvA =cJ1L -----END PGP SIGNATURE----- --qbfRIPaAgtlsTVMQ2WRRaraT7hWhDM8am-- From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 16:55:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B58087C for ; Wed, 8 Oct 2014 16:55:01 +0000 (UTC) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailuogwprd01.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BCC28B16 for ; Wed, 8 Oct 2014 16:55:00 +0000 (UTC) Received: from maildlpprd01.lss.emc.com (maildlpprd01.lss.emc.com [10.253.24.33]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s98GsujS029704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2014 12:54:57 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s98GsujS029704 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=isilon.com; s=jan2013; t=1412787297; bh=iKJQAFUr/xCaK78oDRpXkBbcx20=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=m+5VfbUj+xtDdk8Bm0QkxHVaBcwNBln7AA6unHMvUqwA7VUvQC4EdC8ilH1wg3eL8 7BW4jIuNf4+IIhHKRz8JvfWOGyqBAN/S64/HEKkY5nCJwWohQEDsYMPVUuIrqd/5Hf nluVsjqoUoAjGzSGwrNulbGUN1OGoLn7y8mTXEZ8= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com s98GsujS029704 Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd01.lss.emc.com (RSA Interceptor); Wed, 8 Oct 2014 12:54:34 -0400 Received: from mxhub14.corp.emc.com (mxhub14.corp.emc.com [128.222.70.235]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s98GsSGU024102 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 Oct 2014 12:54:47 -0400 Received: from MXHUB102.corp.emc.com (10.253.58.15) by mxhub14.corp.emc.com (128.222.70.235) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 8 Oct 2014 12:54:46 -0400 Received: from MX103CL02.corp.emc.com ([169.254.6.33]) by MXHUB102.corp.emc.com ([::1]) with mapi id 14.03.0195.001; Wed, 8 Oct 2014 12:54:46 -0400 From: "Meyer, Conrad" To: "Pokala, Ravi" , "freebsd-hackers@freebsd.org" Subject: RE: Seeking reviewers for patch; PR 193873 Thread-Topic: Seeking reviewers for patch; PR 193873 Thread-Index: AQHP4wYRavcCoEK4Q7+AD0LgMnmE/ZwmapdB Date: Wed, 8 Oct 2014 16:54:45 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.13.44.225] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 16:55:01 -0000 (Apologies for the top-post.)=0A= =0A= Hi Ravi,=0A= =0A= Please file a bug in bugzilla and assign it to me.=0A= =0A= Thanks,=0A= Conrad=0A= =0A= ________________________________________=0A= From: owner-freebsd-hackers@freebsd.org [owner-freebsd-hackers@freebsd.org]= on behalf of Pokala, Ravi [rpokala@panasas.com]=0A= Sent: Wednesday, October 08, 2014 7:42 AM=0A= To: freebsd-hackers@freebsd.org=0A= Subject: Re: Seeking reviewers for patch; PR 193873=0A= =0A= Hi Conrad,=0A= =0A= As mentioned in another thread ([1], [2]), I'm looking at dumping on=0A= systems w/ AF-4Kn drives (on a fairly old version of FreeBSD).=0A= Unfortunately, I'm not at all familiar w/ the process. I'm going to pick=0A= at it a few more days, but will probably end up having to punt and dumpsys= =0A= onto a 512n or AF-512e device. But, since you are refactoring all this=0A= code in -CURRENT anyway, I think it would be awesome if you could look to= =0A= the future and make it work w/o assuming that dump device block size is=0A= DEV_BSIZE; it would be better to use the sector size, as returned (for=0A= example) by ioctl(DIOCGSECTORSIZE).=0A= =0A= That won't help me now, but hopefully it will help everyone in the future.= =0A= =0A= Thanks,=0A= =0A= Ravi=0A= =0A= [1]:=0A= https://lists.freebsd.org/pipermail/freebsd-hackers/2014-September/046164.h= tml=0A= [2]:=0A= https://lists.freebsd.org/pipermail/freebsd-hackers/2014-October/046181.htm= l=0A= From owner-freebsd-hackers@FreeBSD.ORG Wed Oct 8 17:01:59 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 377A0B8D for ; Wed, 8 Oct 2014 17:01:59 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B5100BFC for ; Wed, 8 Oct 2014 17:01:58 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s98H1q8h079827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 8 Oct 2014 20:01:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s98H1q8h079827 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s98H1qXZ079826; Wed, 8 Oct 2014 20:01:52 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 8 Oct 2014 20:01:52 +0300 From: Konstantin Belousov To: Dmitry Sivachenko Subject: Re: mmap() question Message-ID: <20141008170152.GG2153@kib.kiev.ua> References: <95E0B821-BF9B-4EBF-A1E5-1DDCBB1C3D1B@gmail.com> <20131011051702.GE41229@kib.kiev.ua> <20131012095919.GI41229@kib.kiev.ua> <5C10922E-7030-4C89-9FD3-DA770E462067@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5C10922E-7030-4C89-9FD3-DA770E462067@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: "hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Oct 2014 17:01:59 -0000 On Wed, Oct 08, 2014 at 07:14:45PM +0400, Dmitry Sivachenko wrote: > On 12 ÏËÔ. 2013 Ç., at 13:59, Konstantin Belousov wrote: > > > > I was not able to reproduce the situation locally. I even tried to start > > a lot of threads accessing the mapped regions, to try to outrun the > > pagedaemon. The user threads sleep on the disk read, while pagedaemon > > has a lot of time to rebalance the queues. It might be a case when SSD > > indeed makes a difference. > > > > Still, I see how this situation could appear. The code, which triggers > > OOM, never fires if there is a free space in the swapfile, so the > > absense of swap is neccessary condition to trigger the bug. Next, OOM > > calculation does not account for a possibility that almost all pages on > > the queues can be reused. It just fires if free pages depleted too much > > or free target cannot be reached. > > > > IMO one of the possible solution is to account the queued pages in > > addition to the swap space. This is not entirely accurate, since some > > pages on the queues cannot be reused, at least transiently. Most precise > > algorithm would count the hold and busy pages globally, and substract > > this count from queues length, but it is probably too costly. > > > > Instead, I think we could rely on the numbers which are counted by > > pagedaemon threads during the passes. Due to the transient nature of the > > pagedaemon failures, this should be fine. > > > > Below is the prototype patch, against HEAD. It is not applicable to > > stable, please use HEAD kernel for test. > > > > Hello, > > any chance to commit this patch? > I wrote something different after discussion with Alan, it instead measures the pagedaemon progress. Unfortunately, I have some issues with auto-tuning the detection. Could you try the patch below. Possibly, you would need to change vm.pageout_oom_miss (either lower or raise, depending on the load) to get the tuning. Bigger the value, more the time pagedaemon tries to make any progress before declaring OOM. diff --git a/sys/vm/vm_page.h b/sys/vm/vm_page.h index f12b76c..251cf7b 100644 --- a/sys/vm/vm_page.h +++ b/sys/vm/vm_page.h @@ -227,6 +227,7 @@ struct vm_domain { long vmd_segs; /* bitmask of the segments */ boolean_t vmd_oom; int vmd_pass; /* local pagedaemon pass */ + int vmd_oom_seq; struct vm_page vmd_marker; /* marker for pagedaemon private use */ }; diff --git a/sys/vm/vm_pageout.c b/sys/vm/vm_pageout.c index ca9d7f9..aa23eb8 100644 --- a/sys/vm/vm_pageout.c +++ b/sys/vm/vm_pageout.c @@ -120,7 +120,8 @@ static void vm_pageout(void); static void vm_pageout_init(void); static int vm_pageout_clean(vm_page_t); static void vm_pageout_scan(struct vm_domain *vmd, int pass); -static void vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass); +static void vm_pageout_mightbe_oom(struct vm_domain *vmd, int page_shortage, + int starting_page_shortage); SYSINIT(pagedaemon_init, SI_SUB_KTHREAD_PAGE, SI_ORDER_FIRST, vm_pageout_init, NULL); @@ -157,6 +158,7 @@ int vm_pages_needed; /* Event on which pageout daemon sleeps */ int vm_pageout_deficit; /* Estimated number of pages deficit */ int vm_pageout_pages_needed; /* flag saying that the pageout daemon needs pages */ int vm_pageout_wakeup_thresh; +static int vm_pageout_oom_seq = 24; #if !defined(NO_SWAPPING) static int vm_pageout_req_swapout; /* XXX */ @@ -216,6 +218,10 @@ static int pageout_lock_miss; SYSCTL_INT(_vm, OID_AUTO, pageout_lock_miss, CTLFLAG_RD, &pageout_lock_miss, 0, "vget() lock misses during pageout"); +SYSCTL_INT(_vm, OID_AUTO, pageout_oom_seq, + CTLFLAG_RW, &vm_pageout_oom_seq, 0, + "side-to-side calls to oom detector to start OOM"); + #define VM_PAGEOUT_PAGE_COUNT 16 int vm_pageout_page_count = VM_PAGEOUT_PAGE_COUNT; @@ -912,7 +918,8 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) vm_page_t m, next; struct vm_pagequeue *pq; vm_object_t object; - int act_delta, addl_page_shortage, deficit, maxscan, page_shortage; + int act_delta, addl_page_shortage, deficit, maxscan; + int page_shortage, starting_page_shortage; int vnodes_skipped = 0; int maxlaunder; int lockmode; @@ -954,6 +961,7 @@ vm_pageout_scan(struct vm_domain *vmd, int pass) page_shortage = vm_paging_target() + deficit; } else page_shortage = deficit = 0; + starting_page_shortage = page_shortage; /* * maxlaunder limits the number of dirty pages we flush per scan. @@ -1329,6 +1337,15 @@ relock_queues: (void)speedup_syncer(); /* + * If we are critically low on one of RAM or swap and low on + * the other, kill the largest process. However, we avoid + * doing this on the first pass in order to give ourselves a + * chance to flush out dirty vnode-backed pages and to allow + * active pages to be moved to the inactive queue and reclaimed. + */ + vm_pageout_mightbe_oom(vmd, page_shortage, starting_page_shortage); + + /* * Compute the number of pages we want to try to move from the * active queue to the inactive queue. */ @@ -1437,15 +1454,6 @@ relock_queues: } } #endif - - /* - * If we are critically low on one of RAM or swap and low on - * the other, kill the largest process. However, we avoid - * doing this on the first pass in order to give ourselves a - * chance to flush out dirty vnode-backed pages and to allow - * active pages to be moved to the inactive queue and reclaimed. - */ - vm_pageout_mightbe_oom(vmd, pass); } static int vm_pageout_oom_vote; @@ -1456,18 +1464,36 @@ static int vm_pageout_oom_vote; * failed to reach free target is premature. */ static void -vm_pageout_mightbe_oom(struct vm_domain *vmd, int pass) +vm_pageout_mightbe_oom(struct vm_domain *vmd, int page_shortage, + int starting_page_shortage) { int old_vote; - if (pass <= 1 || !((swap_pager_avail < 64 && vm_page_count_min()) || - (swap_pager_full && vm_paging_target() > 0))) { + if (starting_page_shortage <= 0 || starting_page_shortage != + page_shortage) { +#if 0 + if (vmd->vmd_oom_seq != 0) + printf("CLR oom_seq %d ps %d sps %d\n", vmd->vmd_oom_seq, page_shortage, starting_page_shortage); +#endif + vmd->vmd_oom_seq = 0; + } else + vmd->vmd_oom_seq++; + if (vmd->vmd_oom_seq < vm_pageout_oom_seq) { if (vmd->vmd_oom) { vmd->vmd_oom = FALSE; atomic_subtract_int(&vm_pageout_oom_vote, 1); } return; } +#if 0 +printf("OOM oom_seq %d ps %d sps %d\n", vmd->vmd_oom_seq, page_shortage, starting_page_shortage); +#endif + + /* + * Do not follow the call sequence until OOM condition is + * cleared. + */ + vmd->vmd_oom_seq = 0; if (vmd->vmd_oom) return; From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 00:48:57 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64DBB95D for ; Thu, 9 Oct 2014 00:48:57 +0000 (UTC) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26A6A7FA for ; Thu, 9 Oct 2014 00:48:56 +0000 (UTC) Received: by mail-ig0-f179.google.com with SMTP id h18so1158821igc.0 for ; Wed, 08 Oct 2014 17:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=goK1vjay1Ql22gSeBvvsTvAKRGtWQhLDrVxRxoDBPjQ=; b=MPYQeHJyGqJigWIHfyJc0+TQopSsE0Acw5zmrK0XCuWhatdnfkEPNrFytZeBisTzSY 5216+08yyLK9yLXKTr4/eO+iJ0W6FMEJbEwCwzLTA7ionCgnrNSuH1XxkieXfsDrmLm+ LDcp3OJN8C7qOBLCu/cNT0qdGcXR82wekgPY4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=goK1vjay1Ql22gSeBvvsTvAKRGtWQhLDrVxRxoDBPjQ=; b=cw+b4oB/SQ207zSPWpihluzevAfmabY9vezoaTIQPztl/XGxiAguEUJY+vrI7uKBbv tuNAaTj5EvOFgvqSWjT04dwDwCzc06TtfF3SbPYKvh4/0y6brQ0iIchPLubaUghy7cVE Gr0SWTEiwqdShNTDeyOPu8KNKpaYhn9m/D19QHfB6+IMxezIbSdf2QgFwDHtqBHlTcqr 7mq70EvDGhjbfbTyruhwI7I+EvuEHUItRg1FyWl9UfHUlGCY6eQir8w6vUiEJ6Q5N/CA Nid8w1zoiZylJfs6bFsmKBMyoZXaXfFAFgGzIa1+QKVwHmfQjyhhKQTtmel8KrRyDIyf yUFg== X-Gm-Message-State: ALoCoQkLDZICWm1JKHGkv69QE5E0NZttvS9WlgR82MVedMEFLM5+Nhy+3FpWpILLHZZseFUn8D/X X-Received: by 10.50.61.99 with SMTP id o3mr2534156igr.30.1412815735929; Wed, 08 Oct 2014 17:48:55 -0700 (PDT) Received: from ?IPv6:2600:1008:b101:c87a:9068:545b:6c4b:7b29? ([2600:1008:b101:c87a:9068:545b:6c4b:7b29]) by mx.google.com with ESMTPSA id ky8sm3189311igb.16.2014.10.08.17.48.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Oct 2014 17:48:55 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: tar and / From: Jason Hellenthal X-Mailer: iPhone Mail (12A405) In-Reply-To: Date: Wed, 8 Oct 2014 19:48:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <221B7CFC-4AE2-4DAF-9E6E-565715B87172@dataix.net> References: To: Daniel Braniss Cc: "hackers@freebsd.org" , Ian Lepore X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 00:48:57 -0000 Damn! I thought we were past this issue long ago using relative paths instea= d absolute paths. Wonder what ever happened to that standard of safety. Unle= ss I am mistaking one thing for another. Symbolic links obviously should not be starting with "/".=20 Hard links on the other hand should be broken once inside a tar file and no l= onger referencing a previous inode. So if I understand this correctly this i= s what you are seeing ? On another note from this ... I was by aware hard links could be created to a= nything but files ... ? So I'm confused here ? --=20 Jason Hellenthal Mobile: +1 (616) 953-0176 jhellenthal@DataIX.net JJH48-ARIN On Oct 8, 2014, at 01:24, Daniel Braniss wrote: A facts that I did not mention: the tar file is created by ports when requesting =E2=80=98package=E2=80=99= , it now adds /usr/local making extraction difficult for those that use nfs/amd for /usr/local (the solution is to extract the files in /var/tmp, and re-taring without the= /usr/local :-) to my surprise, even though tar complains that it can=E2=80=99t do the link t= o / it actually does the link!! notice that I mentioned =E2=80=98link', not symlink! which of course brings t= he question why some ports insist on link, and not symlink is beyond me. thanks danny > On Oct 7, 2014, at 5:35 PM, Jason Hellenthal wrot= e: >=20 > =46rom tar(1) >=20 > o Archive entries can exploit symbolic links to restore files to o= ther directories. > An archive can restore a symbolic link to another directory, th= en use that link to > restore a file into that directory. To guard against this, tar= checks each > extracted path for symlinks. If the final path element is a sy= mlink, it will be > removed and replaced with the archive entry. If -U is specifie= d, any intermediate > symlink will also be unconditionally removed. If neither -U no= r -P is specified, > tar will refuse to extract the entry. >=20 > With that stated you might want to roll through your filesystem with symli= nks(1) [sysutils/symlinks]. Use of this to shorten, remove dangling etc.. >=20 > DESCRIPTION > symlinks is a useful utility for maintainers of FTP sites, CDROMs, a= nd > Linux software distributions. It scans directories for symbolic lin= ks > and lists them on stdout, often revealing flaws in the filesystem tre= e. >=20 > Each link is output with a classification of relative, absolute, da= n- > gling, messy, lengthy, or other_fs. >=20 > relative links are those expressed as paths relative to the directo= ry > in which the links reside, usually independent of the mount point o= f > the filesystem. >=20 > absolute links are those given as an absolute path from the root dire= c- > tory as indicated by a leading slash (/). >=20 > dangling links are those for which the target of the link does not cu= r- > rently exist. This commonly occurs for absolute links when a filesy= s- > tem is mounted at other than its customary mount point (such as wh= en > the normal root filesystem is mounted at /mnt after booting from alte= r- > native media). >=20 > messy links are links which contain unnecessary slashes or dots in t= he > path. These are cleaned up as well when -c is specified. >=20 > lengthy links are links which use "../" more than necessary in the pa= th > (eg. /bin/vi -> ../bin/vim) These are only detected when -s is spec= i- > fied, and are only cleaned up when -c is also specified. >=20 > other_fs are those links whose target currently resides on a differe= nt > filesystem from where symlinks was run (most useful with -r ). >=20 > Hope this helps. >=20 >> On Oct 7, 2014, at 1:44, Daniel Braniss wrote: >>=20 >> hi,Ian Lepore >> for security reasons tar removes the leading /, which is fine. >> so I can chadir to /var/tmp, and do an extract there. The problem arises w= hen there >> is a file that is linked to /=E2=80=A6 >> Is there some way to drop that leading =E2=80=98/=E2=80=98 too? >>=20 >> cheers, >>=20 >> _______________________________________________ >> freebsd-hackers@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " >=20 > --=20 > Jason Hellenthal > Mobile: +1 (616) 953-0176 > jhellenthal@DataIX.net > JJH48-ARIN From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 07:11:11 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19DDF70D for ; Thu, 9 Oct 2014 07:11:11 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C9F05EF0 for ; Thu, 9 Oct 2014 07:11:10 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Xc7sH-00031Z-37 for freebsd-hackers@freebsd.org; Thu, 09 Oct 2014 09:10:57 +0200 Received: from tempe0.bbox.io ([24.249.180.233]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Oct 2014 09:10:57 +0200 Received: from kevin.bowling by tempe0.bbox.io with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 09 Oct 2014 09:10:57 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Kevin Bowling Subject: Re: freebsd 10 kqueue timer regression Date: Thu, 09 Oct 2014 00:10:46 -0700 Lines: 18 Message-ID: References: <8ABC0977-FB8F-45E7-ACCC-BFA92EE22E1C@glccom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tempe0.bbox.io User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Thunderbird/33.0 In-Reply-To: <8ABC0977-FB8F-45E7-ACCC-BFA92EE22E1C@glccom.com> X-Mailman-Approved-At: Thu, 09 Oct 2014 11:24:15 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 07:11:11 -0000 On 10/2/2014 8:07 AM, Paul Albrecht wrote: > > Hi, > > What’s up with freebsd 10? I’m testing some code that uses the kqueue timer for timing and it doesn’t work because the precision of the timer is off. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > Saw something that might have been a symptom: https://github.com/facebook/libphenom/issues/48 I will try with your patch to -current and see if it's any better. Regards, Kevin From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 13:03:27 2014 Return-Path: Delivered-To: hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D4A89A82; Thu, 9 Oct 2014 13:03:27 +0000 (UTC) Received: from mailuogwhop.emc.com (mailuogwhop.emc.com [168.159.213.141]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mailuogwprd01.lss.emc.com", Issuer "RSA Corporate Server CA v2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 87986AD0; Thu, 9 Oct 2014 13:03:27 +0000 (UTC) Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s99D3O0w014971 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Oct 2014 09:03:25 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s99D3O0w014971 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1412859805; bh=9/WhAUYU6w0PrxWreUdAscE+uVs=; h=From:To:CC:Date:Subject:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=NeSHma1eXTzsFPDHEYyZbUiLtZBHDH7+nxofIx0TzxpbrmRiYhVDOLxCB1WqeigiD VCBPvrpH5NoYutvQ0JW2klEylwfFxjGR3T+NkDT/BoADZ1S3Dx7wMpTlurp97e4eU9 qZb5dw9nw1i+jIViQx2D4peBCwIr0FfRh20lrmCM= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com s99D3O0w014971 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd04.lss.emc.com (RSA Interceptor); Thu, 9 Oct 2014 09:03:01 -0400 Received: from mxhub08.corp.emc.com (mxhub08.corp.emc.com [128.222.70.205]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.0/Sentrion-MTA-4.3.0) with ESMTP id s99D397k014519 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Oct 2014 09:03:09 -0400 Received: from mx34a.corp.emc.com ([169.254.1.46]) by mxhub08.corp.emc.com ([128.222.70.205]) with mapi; Thu, 9 Oct 2014 09:03:09 -0400 From: "O'Connor, Daniel" To: Julian Elischer Date: Thu, 9 Oct 2014 09:03:05 -0400 Subject: Re: exiting gdbserver quietly Thread-Topic: exiting gdbserver quietly Thread-Index: Ac/jwV8wRPMGz3++Sb66plpsV76mjA== Message-ID: <0ED80BA6-5857-42CC-90A7-C9F1C6E17D33@emc.com> References: <54336E4A.1010208@freebsd.org> In-Reply-To: <54336E4A.1010208@freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public X-Mailman-Approved-At: Thu, 09 Oct 2014 13:39:49 +0000 Cc: "hackers@FreeBSD.ORG" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 13:03:27 -0000 On 7 Oct 2014, at 15:08, Julian Elischer wrote: > Does anyone know how to exit a gdb/gdbserver combination session=20 > without killing the attached program? >=20 > gdbserver --attach PID attaches to the process ok, but I can't find a=20 > way to exit the session and leave the program running as it was.. I did a quick test and =91detach=92 works for me. Regards, Daniel O=92Connor Senior Software Engineer Isilon Platforms Team From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 21:29:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 097A8C85 for ; Thu, 9 Oct 2014 21:29:01 +0000 (UTC) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0063.outbound.protection.outlook.com [65.55.169.63]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A36C6DD7 for ; Thu, 9 Oct 2014 21:29:00 +0000 (UTC) Received: from DM2PR0801MB0942.namprd08.prod.outlook.com (25.160.131.25) by DM2PR0801MB0732.namprd08.prod.outlook.com (10.242.174.18) with Microsoft SMTP Server (TLS) id 15.0.1044.10; Thu, 9 Oct 2014 21:28:50 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com (25.160.131.27) by DM2PR0801MB0942.namprd08.prod.outlook.com (25.160.131.25) with Microsoft SMTP Server (TLS) id 15.0.1049.19; Thu, 9 Oct 2014 21:28:49 +0000 Received: from DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) by DM2PR0801MB0944.namprd08.prod.outlook.com ([25.160.131.27]) with mapi id 15.00.1049.012; Thu, 9 Oct 2014 21:28:49 +0000 From: "Pokala, Ravi" To: "Meyer, Conrad" , "freebsd-hackers@freebsd.org" Subject: Re: Seeking reviewers for patch; PR 193873 Thread-Topic: Seeking reviewers for patch; PR 193873 Thread-Index: AQHP4wYRwsbUBpMNTk6xd1JtizXBKpwmaxOAgAFpiwA= Date: Thu, 9 Oct 2014 21:28:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [64.80.217.3] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0942;UriScan:; x-exchange-antispam-report-test: UriScan:; x-forefront-prvs: 0359162B6D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(189002)(52314003)(377454003)(164054003)(51704005)(199003)(13464003)(95666004)(99286002)(87936001)(2656002)(92726001)(92566001)(64706001)(99396003)(106116001)(50986999)(66066001)(54356999)(106356001)(76176999)(105586002)(86362001)(80022003)(46102003)(36756003)(120916001)(85852003)(107886001)(97736003)(107046002)(31966008)(40100002)(4396001)(101416001)(122556002)(19580405001)(76482002)(21056001)(77096002)(20776003)(85306004)(15975445006)(83506001)(19580395003)(7059026); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR0801MB0942; H:DM2PR0801MB0944.namprd08.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <118722495D9CAA46B4D885628E1F8973@namprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:DM2PR0801MB0732; X-OriginatorOrg: panasas.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 21:29:01 -0000 -----Original Message----- From: , Conrad Date: Wednesday, October 8, 2014 at 9:54 AM To: Ravi Pokala , "freebsd-hackers@freebsd.org" Subject: RE: Seeking reviewers for patch; PR 193873 >(Apologies for the top-post.) > >Hi Ravi, > >Please file a bug in bugzilla and assign it to me. Filed: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D194279 However, I wasn't able to assign it to you; it's still assigned to freebsd-bugs. Thanks, Ravi >Thanks, >Conrad > >________________________________________ >From: owner-freebsd-hackers@freebsd.org >[owner-freebsd-hackers@freebsd.org] on behalf of Pokala, Ravi >[rpokala@panasas.com] >Sent: Wednesday, October 08, 2014 7:42 AM >To: freebsd-hackers@freebsd.org >Subject: Re: Seeking reviewers for patch; PR 193873 > >Hi Conrad, > >As mentioned in another thread ([1], [2]), I'm looking at dumping on >systems w/ AF-4Kn drives (on a fairly old version of FreeBSD). >Unfortunately, I'm not at all familiar w/ the process. I'm going to pick >at it a few more days, but will probably end up having to punt and dumpsys >onto a 512n or AF-512e device. But, since you are refactoring all this >code in -CURRENT anyway, I think it would be awesome if you could look to >the future and make it work w/o assuming that dump device block size is >DEV_BSIZE; it would be better to use the sector size, as returned (for >example) by ioctl(DIOCGSECTORSIZE). > >That won't help me now, but hopefully it will help everyone in the future. > >Thanks, > >Ravi > >[1]: >https://lists.freebsd.org/pipermail/freebsd-hackers/2014-September/046164. >html >[2]: >https://lists.freebsd.org/pipermail/freebsd-hackers/2014-October/046181.ht >ml From owner-freebsd-hackers@FreeBSD.ORG Thu Oct 9 23:37:08 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 836A85E5 for ; Thu, 9 Oct 2014 23:37:08 +0000 (UTC) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 43800D26 for ; Thu, 9 Oct 2014 23:37:08 +0000 (UTC) Received: by mail-qg0-f54.google.com with SMTP id z107so3154440qgd.13 for ; Thu, 09 Oct 2014 16:37:07 -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=5zEgyfaeloU9NrxoLI2do7Gw9QBTImdkWNtrv5z7T5A=; b=F63y//LYItjYoNKiDXYoiabLOvaX7Rv0ZrRICztvfOldTkwneahZoh6GCHs2LpRlow tpaOUqC7K5C2meo4/vpp4DtDri5WfzSlQY0JCYsqpDZA6QQlPblVv6Mn4R94D8oklzpP yk4DmKME8JvdKR8BHCgc89v1MnUa48rO6nB51XtfsouL83o/WZLBBMkpI1tFDi4fKioc eUSbmiON0sigiQb+bzWFN2AzuTXmaPIBzz/eWlMacvy++XaRrhuBwnuBF0FA+/e8Z2Fu n0Ur5ZHg6eNBwQs9vn96ftACIQxEEtgOQGHPe8/2pD4JgmocvQvH+GnusMSRewRP2ssk P34Q== X-Received: by 10.140.89.80 with SMTP id u74mr2367068qgd.74.1412897827103; Thu, 09 Oct 2014 16:37:07 -0700 (PDT) Received: from [10.68.80.136] (cdm-75-109-148-146.asbnva.dh.suddenlink.net. [75.109.148.146]) by mx.google.com with ESMTPSA id x1sm3664686qax.17.2014.10.09.16.37.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Oct 2014 16:37:06 -0700 (PDT) Message-ID: <54371C20.6090904@gmail.com> Date: Thu, 09 Oct 2014 19:37:04 -0400 From: netmantej User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: wojtek@puchar.net, freebsd-hackers@freebsd.org Subject: RE: ppp and set dial Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 23:37:08 -0000 Message: 1 Date: Wed, 8 Oct 2014 14:23:28 +0200 (CEST) From: Wojciech Puchar To: freebsd-hackers@freebsd.org Subject: ppp and set dial Message-ID: Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII is there somewhere complete manual about set dial chatscript syntax i need to do AT wait for OK or ERROR (but one line answer) AT --------------------------------------------------------- When I learned it the definitive source was "Dvorak's Guide to Modem Communications". Now it is " Dvorak's Guide to PC Telecommunications: Second Edition ". ISBN-13: 9780078817878 You might find " Official Hayes Modem Companion " useful as well. SBN13: 978-1568840727 ISBN10: 1568840721 Enjoy. That book is what lit my passion for Network Analysis. -- Tim Jacques netmantej@gmail.com ------------------------------ -- -- Tim From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 21:08:17 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6026A410 for ; Fri, 10 Oct 2014 21:08:17 +0000 (UTC) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 36BA124D for ; Fri, 10 Oct 2014 21:08:17 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id fa1so2396011pad.19 for ; Fri, 10 Oct 2014 14:08:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=gXc6VPPZcOvCyUatnpLwuY2m2hKMe9hJBUnnD6+O5JM=; b=YS62/DNvPIuLEDvBB69fyhCW8MlEC7trdUUDfZEGx58ym4t6AANIChb3edTMrOYLMH jizC/ZHaMpM2+p0ZKMobpiB+SJRikWLRq2oRyj5+XGmgHR7DHcKTbWB1rP74ml58ESmI 2wCIGbBo3aaah0d7giZ2U/FyuWiYjZcmhECOWzvnMzgfSTVgI21PaRqK2a4GtRB9n9Aq l/bnKTwzp/10LYgVsAJhsA7fot3b7JYGYGtwFRhD9kWGwIMyun9JD9deMeZvr7SjUq0T bTD+fbcTGeG2Gk1njXytsE3vWnMmY2ZLSoSFdXbhijh//WIehdVGxS5pr9oMAmQKzc2G vlDQ== X-Received: by 10.66.141.165 with SMTP id rp5mr7714220pab.115.1412975296764; Fri, 10 Oct 2014 14:08:16 -0700 (PDT) Received: from [10.192.166.0] (stargate.chelsio.com. [67.207.112.58]) by mx.google.com with ESMTPSA id y1sm4342725pdg.47.2014.10.10.14.08.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Oct 2014 14:08:15 -0700 (PDT) Sender: Navdeep Parhar Message-ID: <54384ABD.5080806@FreeBSD.org> Date: Fri, 10 Oct 2014 14:08:13 -0700 From: Navdeep Parhar User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "freebsd-hackers@freebsd.org" Subject: panic in ivy_rng_store() when compiled with -O0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 21:08:17 -0000 I built my kernel + modules (head as of today) with -O0 and now it panics during boot. I did bump up KSTACK_PAGES significantly so that's not the problem. I'm going to take out the RNG device next and see if I can get past this. Regards, Navdeep Fatal trap 9: general protection fault while in kernel mode cpuid = 0; apic id = 00 instruction pointer = 0x20:0xffffffff814ac661 stack pointer = 0x28:0xfffffe01ed6c6930 frame pointer = 0x28:0xfffffe01ed6c6960 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 14 (rand_harvestq) [ thread pid 14 tid 100017 ] Stopped at ivy_rng_store+0x31: movq %rdi,(%rdi) db> bt Tracing pid 14 tid 100017 td 0xfffff800042c84c0 ivy_rng_store() at ivy_rng_store+0x31/frame 0xfffffe01ed6c6960 random_ivy_read() at random_ivy_read+0x78/frame 0xfffffe01ed6c6990 live_entropy_sources_feed() at live_entropy_sources_feed+0x73/frame 0xfffffe01ed6c69d0 random_kthread() at random_kthread+0x224/frame 0xfffffe01ed6c6a30 fork_exit() at fork_exit+0x14a/frame 0xfffffe01ed6c6ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe01ed6c6ab0 --- trap 0, rip = 0, rsp = 0xfffffe01ed6c6b70, rbp = 0 --- From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 10 21:58:56 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A5B9783 for ; Fri, 10 Oct 2014 21:58:56 +0000 (UTC) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [108.61.84.26]) (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 1FBA798E for ; Fri, 10 Oct 2014 21:58:55 +0000 (UTC) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.14.7/8.14.7) with ESMTP id s9ALwhmh006744 for ; Fri, 10 Oct 2014 17:58:43 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.14.7/8.14.7/Submit) id s9ALwhAb006743 for hackers@freebsd.org; Fri, 10 Oct 2014 17:58:43 -0400 (EDT) (envelope-from mwlucas) Date: Fri, 10 Oct 2014 17:58:42 -0400 From: "Michael W. Lucas" To: hackers@freebsd.org Subject: GBDE not protecting the user Message-ID: <20141010215842.GA6717@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.michaelwlucas.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2014 21:58:56 -0000 [Tried questions@, no answer, and the code contains things I just cannot trigger.] Hi, Been playing with GBDE a while, trying to make it protect me. One of the features of GBDE is that it should "provide tangible feedback" that the data has been destroyed. (See PHK's paper at http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf, section 4.1.) The man page doesn't mention how to make GBDE whine, so what the heck, let's make it tell me the keys are destroyed. Creating GBDE devices is very simple. # gbde init /dev/gpt/encrypted -L /etc/encrypted.lock I created a filesystem, mounted it, put files on it, unmounted. There's two operations to wipe out a GBDE: nuke and destroy. Nuke looks like the right thing. I nuke all the keys: # gbde nuke gpt/encrypted -l /etc/encrypted.lock -n -1 Enter passphrase: Opened with key 0 Nuked key 0 Nuked key 1 Nuked key 2 Nuked key 3 # gbde attach gpt/encrypted -l /etc/encrypted.lock Enter passphrase: # The .bde device isn't there, and my filesystem is gone. But I received no confirmation that the keys were destroyed. I also didn't get a message that the device couldn't be attached, although it clearly isn't. Fine. Let's try 'gbde destroy'. # gbde init /dev/gpt/encrypted -L /etc/encrypted.lock Enter new passphrase: Reenter new passphrase: # gbde destroy gpt/encrypted -l /etc/encrypted.lock Enter passphrase: Opened with key 0 # gbde attach gpt/encrypted -l /etc/encrypted.lock Enter passphrase: # The device isn't attached, it just fails silently. And failing with a specific complaint is the whole point of GBDE. Did I misunderstand the GBDE functionality? Am I missing something daft? Has this code just decayed with GELI's arrival? Thanks, ==ml -- Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 03:30:22 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 32F66186 for ; Sat, 11 Oct 2014 03:30:22 +0000 (UTC) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0BEE7BA7 for ; Sat, 11 Oct 2014 03:30:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=XB3kf0bi8BIPawfjMJjkzPxdjFsAkWTnn/AGhQa9MuI=; b=orx8m30Ij9XtC6ji0tt82p2W+ubAsCIZldwuKzuCHi8GXzM4zauropIvXItg7qMNeJtRPceuBZPviyoGRX4xQKD7gOchDwZHX8phzHfxeygof6UpALI3DOInsfglc2B10FpdOKHH4EpM1XVBiV/M6y5zZsygigganQB/rJBaB40=; Received: from [182.4.89.165] (port=11393 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XcnNl-0017aH-FS; Fri, 10 Oct 2014 21:30:14 -0600 Date: Sat, 11 Oct 2014 11:30:08 +0800 From: Erich Dollansky To: "Michael W. Lucas" Subject: Re: GBDE not protecting the user Message-ID: <20141011113008.705ba16d@X220.alogt.com> In-Reply-To: <20141010215842.GA6717@mail.michaelwlucas.com> References: <20141010215842.GA6717@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 03:30:22 -0000 Hi, On Fri, 10 Oct 2014 17:58:42 -0400 "Michael W. Lucas" wrote: > [Tried questions@, no answer, and the code contains things I just > cannot trigger.] > just try geli. It works for me. What I like most is that you can have key and password on external media. No external media - no decyphering. I also see the destruction possible but I do not use this feature. Erich > Hi, > > Been playing with GBDE a while, trying to make it protect me. > > One of the features of GBDE is that it should "provide tangible > feedback" that the data has been destroyed. (See PHK's paper at > http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf, section 4.1.) > > The man page doesn't mention how to make GBDE whine, so what the heck, > let's make it tell me the keys are destroyed. > > Creating GBDE devices is very simple. > > # gbde init /dev/gpt/encrypted -L /etc/encrypted.lock > > I created a filesystem, mounted it, put files on it, unmounted. > > There's two operations to wipe out a GBDE: nuke and destroy. Nuke > looks like the right thing. I nuke all the keys: > > # gbde nuke gpt/encrypted -l /etc/encrypted.lock -n -1 > Enter passphrase: > Opened with key 0 > Nuked key 0 > Nuked key 1 > Nuked key 2 > Nuked key 3 > # gbde attach gpt/encrypted -l /etc/encrypted.lock > Enter passphrase: > # > > The .bde device isn't there, and my filesystem is gone. But I received > no confirmation that the keys were destroyed. > > I also didn't get a message that the device couldn't be attached, > although it clearly isn't. > > Fine. Let's try 'gbde destroy'. > > # gbde init /dev/gpt/encrypted -L /etc/encrypted.lock > Enter new passphrase: > Reenter new passphrase: > # gbde destroy gpt/encrypted -l /etc/encrypted.lock > Enter passphrase: > Opened with key 0 > # gbde attach gpt/encrypted -l /etc/encrypted.lock > Enter passphrase: > # > > The device isn't attached, it just fails silently. And failing with a > specific complaint is the whole point of GBDE. > > Did I misunderstand the GBDE functionality? Am I missing something > daft? Has this code just decayed with GELI's arrival? > > Thanks, > ==ml > > From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 07:44:23 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8698B6E6 for ; Sat, 11 Oct 2014 07:44:23 +0000 (UTC) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [108.61.84.26]) (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 4686435B for ; Sat, 11 Oct 2014 07:44:23 +0000 (UTC) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.14.7/8.14.7) with ESMTP id s9B7iDw2009454; Sat, 11 Oct 2014 03:44:13 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.14.7/8.14.7/Submit) id s9B7iD5t009453; Sat, 11 Oct 2014 03:44:13 -0400 (EDT) (envelope-from mwlucas) Date: Sat, 11 Oct 2014 03:44:12 -0400 From: "Michael W. Lucas" To: Erich Dollansky Subject: Re: GBDE not protecting the user Message-ID: <20141011074412.GA9432@mail.michaelwlucas.com> References: <20141010215842.GA6717@mail.michaelwlucas.com> <20141011113008.705ba16d@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141011113008.705ba16d@X220.alogt.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.michaelwlucas.com Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 07:44:23 -0000 On Sat, Oct 11, 2014 at 11:30:08AM +0800, Erich Dollansky wrote: > Hi, > > On Fri, 10 Oct 2014 17:58:42 -0400 > "Michael W. Lucas" wrote: > > > [Tried questions@, no answer, and the code contains things I just > > cannot trigger.] > > > just try geli. It works for me. What I like most is that you can have > key and password on external media. No external media - no decyphering. GELI does not verify key destruction when the correct passphrase is used. There are use cases where this is very important--e.g., finance. I'd really like to include GBDE in my FreeBSD storage book, but it seems that it doesn't actually work. ==ml -- Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/ From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 08:38:03 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C0BA7BE for ; Sat, 11 Oct 2014 08:38:03 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 593739B4 for ; Sat, 11 Oct 2014 08:38:03 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id y10so5479240wgg.27 for ; Sat, 11 Oct 2014 01:38:01 -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:in-reply-to:references:reply-to :mime-version:content-type:content-transfer-encoding; bh=OPs7SyNrt8I1/DZjDMevACny2kxXgmD4+Rn/FrKwHq0=; b=x9EaEhZ/92QFQZh+kxqQxzNfYMIvvl5f87XEzhdZqeot0h+jmJ04OxlJp2OqQITmqh oF5dRSHt4w4T5nonh7cFvulz+X5hTYFebE2pEHxcZVTW8iSrKVbkmTPcGtl5rLdZXoc1 bui7i4KOpQG/uzKWY4YOGqr2TA+B1EBn66zP+NEWpZNDCDjK4XCuYfq0L1zD7XzV3AQa U2cA75S5YSRN0CrJ1qjaBBVoXWh/+aOo36WINu3oNGqcXEo6e3pz7r0YfvK2w1vGM0lR FBp3CAFFGp98Jz8TXz8I00BPt1YmTqUGWMwGR70F4EN1r/EGWY+QVeKqmnmDjm/WRpps Rzhg== X-Received: by 10.194.179.73 with SMTP id de9mr1216418wjc.87.1413016681505; Sat, 11 Oct 2014 01:38:01 -0700 (PDT) Received: from ernst.home (p578E2606.dip0.t-ipconnect.de. [87.142.38.6]) by mx.google.com with ESMTPSA id bi7sm5026310wib.17.2014.10.11.01.37.59 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sat, 11 Oct 2014 01:38:00 -0700 (PDT) Date: Sat, 11 Oct 2014 10:37:58 +0200 From: Gary Jennejohn To: netmantej Subject: Re: ppp and set dial Message-ID: <20141011103758.05252cd4@ernst.home> In-Reply-To: <54371C20.6090904@gmail.com> References: <54371C20.6090904@gmail.com> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.17; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org, wojtek@puchar.net X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 08:38:03 -0000 On Thu, 09 Oct 2014 19:37:04 -0400 netmantej wrote: > Message: 1 > Date: Wed, 8 Oct 2014 14:23:28 +0200 (CEST) > From: Wojciech Puchar > To: freebsd-hackers@freebsd.org > Subject: ppp and set dial > Message-ID: > Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII > > is there somewhere complete manual about set dial chatscript syntax > i need to do > > AT > wait for OK or ERROR (but one line answer) > AT > > --------------------------------------------------------- > > When I learned it the definitive source was "Dvorak's Guide to Modem > Communications". > > Now it is " Dvorak's Guide to PC Telecommunications: Second Edition ". > ISBN-13: 9780078817878 > > You might find " Official Hayes Modem Companion " useful as well. > SBN13: 978-1568840727 > ISBN10: 1568840721 > > Enjoy. > > That book is what lit my passion for Network Analysis. > > -- Tim Jacques > netmantej@gmail.com > > > ------------------------------ > Also look at the examples under /usr/share/examples/ppp. Should be obvious how it works. -- Gary Jennejohn From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 08:10:31 2014 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4295DD90 for ; Sat, 11 Oct 2014 08:10:31 +0000 (UTC) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 089227FB for ; Sat, 11 Oct 2014 08:10:30 +0000 (UTC) Received: from critter.freebsd.dk (unknown [192.168.60.3]) by phk.freebsd.dk (Postfix) with ESMTP id 19A031598; Sat, 11 Oct 2014 08:10:29 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.9/8.14.9) with ESMTP id s9B8AQmB066909; Sat, 11 Oct 2014 08:10:27 GMT (envelope-from phk@phk.freebsd.dk) To: "Michael W. Lucas" Subject: Re: GBDE not protecting the user In-reply-to: <20141011074412.GA9432@mail.michaelwlucas.com> From: "Poul-Henning Kamp" References: <20141010215842.GA6717@mail.michaelwlucas.com> <20141011113008.705ba16d@X220.alogt.com> <20141011074412.GA9432@mail.michaelwlucas.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <66907.1413015026.1@critter.freebsd.dk> Content-Transfer-Encoding: quoted-printable Date: Sat, 11 Oct 2014 08:10:26 +0000 Message-ID: <66908.1413015026@critter.freebsd.dk> X-Mailman-Approved-At: Sat, 11 Oct 2014 11:08:06 +0000 Cc: Erich Dollansky , hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 08:10:31 -0000 -------- In message <20141011074412.GA9432@mail.michaelwlucas.com>, "Michael W. Luc= as" w rites: >On Sat, Oct 11, 2014 at 11:30:08AM +0800, Erich Dollansky wrote: >I'd really like to include GBDE in my FreeBSD storage book, but it >seems that it doesn't actually work. I think some change somewhere must have broken the key reporting. I'm running GBDE just now and it works fine, but I don't destroy my keys on a regular basis. Maybe I should... -- = Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe = Never attribute to malice what can adequately be explained by incompetence= . From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 15:17:01 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 793C7BC2 for ; Sat, 11 Oct 2014 15:17:01 +0000 (UTC) Received: from mx1.scaleengine.net (beauharnois2.bhs1.scaleengine.net [142.4.218.15]) by mx1.freebsd.org (Postfix) with ESMTP id 51FAF25F for ; Sat, 11 Oct 2014 15:17:00 +0000 (UTC) Received: from [192.168.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 65E185E36E for ; Sat, 11 Oct 2014 15:16:54 +0000 (UTC) Message-ID: <54394A03.6060403@freebsd.org> Date: Sat, 11 Oct 2014 11:17:23 -0400 From: Allan Jude User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Re: GBDE not protecting the user References: <20141010215842.GA6717@mail.michaelwlucas.com> <20141011113008.705ba16d@X220.alogt.com> <20141011074412.GA9432@mail.michaelwlucas.com> In-Reply-To: <20141011074412.GA9432@mail.michaelwlucas.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="HjGBfvfG9MVre72rALS9kjXxxwCw8wnHw" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 15:17:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HjGBfvfG9MVre72rALS9kjXxxwCw8wnHw Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 2014-10-11 03:44, Michael W. Lucas wrote: > On Sat, Oct 11, 2014 at 11:30:08AM +0800, Erich Dollansky wrote: >> Hi, >> >> On Fri, 10 Oct 2014 17:58:42 -0400 >> "Michael W. Lucas" wrote: >> >>> [Tried questions@, no answer, and the code contains things I just >>> cannot trigger.] >>> >> just try geli. It works for me. What I like most is that you can have >> key and password on external media. No external media - no decyphering= =2E >=20 > GELI does not verify key destruction when the correct passphrase is > used. There are use cases where this is very important--e.g., finance. >=20 > I'd really like to include GBDE in my FreeBSD storage book, but it > seems that it doesn't actually work. >=20 > =3D=3Dml >=20 Michael: please file a PR on this now that it is confirmed, and together we can nag someone to fix it. --=20 Allan Jude --HjGBfvfG9MVre72rALS9kjXxxwCw8wnHw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJUOUoGAAoJEJrBFpNRJZKfZm4P/iVvceVS1HWmIFyHUFo1kuLp CEo8Z7UpUFWnH89RuVaYlaNTjwDzMMzbmob8di+cFgbdV1HvhuHb8UAvCxvg1jkt cggDDrL9PbNW3poPa33IJZcJ/wOBTBuOg2NdfIkxz2BS6SrMuUlWuAIKxk8TSuoP MHrpKGa6xLb4o410N1ZRfCoNMY31FuAyUlWx/OYQLnVYMfLIUQ7RuzVsk4cCxirr KPFbGXC8l7pGgzr4K5h6MAXq3PurQp1Qlie0VjOkwjS85JXlaMBkzRZFTBGuG05J 2toY8N+F926j8Hnlr8a2H6ThjlqlGMrg/SDyoJebEiHF0p/KWDVhlmFl4jExes9f B6Upw6Rc8qCxAH7CvssvwJyb3JQokFH7+e/Ai+HwLTRmkFvTd590JEtdYX9xS5dJ 0uyOMTLvi0IPudOEfWRmJ2qDe6oXYEsyIInoyy4fhFCUV2npLjEs9ril8v+8UyVK Aj8XB8YZfHKK2Zy2psELi2Y2Ho7leTZUUgpEtMR7lUkdyqqWwlhfkv4Ob5njgkG0 Pne8fadVbfx6YSD8rmvVfgEhqubzWbH5I4nxHGTVf5SJ/MnGjkM+5hy3BtTVHW2+ REZRBkGP/rUOpdu1VEVvYea2oR90sXfG64MIlvaso129bQShxu79/wh07sZnol9x ZX2c7joJWNziMxUzutJ8 =nfcO -----END PGP SIGNATURE----- --HjGBfvfG9MVre72rALS9kjXxxwCw8wnHw-- From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 11 17:59:53 2014 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CB8E8F0 for ; Sat, 11 Oct 2014 17:59:53 +0000 (UTC) Received: from mail.michaelwlucas.com (mail.michaelwlucas.com [108.61.84.26]) (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 B65E1357 for ; Sat, 11 Oct 2014 17:59:52 +0000 (UTC) Received: from mail.michaelwlucas.com (localhost [127.0.0.1]) by mail.michaelwlucas.com (8.14.7/8.14.7) with ESMTP id s9BHxjOi011162 for ; Sat, 11 Oct 2014 13:59:45 -0400 (EDT) (envelope-from mwlucas@mail.michaelwlucas.com) Received: (from mwlucas@localhost) by mail.michaelwlucas.com (8.14.7/8.14.7/Submit) id s9BHxjFf011161 for freebsd-hackers@freebsd.org; Sat, 11 Oct 2014 13:59:45 -0400 (EDT) (envelope-from mwlucas) Date: Sat, 11 Oct 2014 13:59:44 -0400 From: "Michael W. Lucas" To: freebsd-hackers@freebsd.org Subject: Re: GBDE not protecting the user Message-ID: <20141011175944.GA11131@mail.michaelwlucas.com> References: <20141010215842.GA6717@mail.michaelwlucas.com> <20141011113008.705ba16d@X220.alogt.com> <20141011074412.GA9432@mail.michaelwlucas.com> <54394A03.6060403@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54394A03.6060403@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.michaelwlucas.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Oct 2014 17:59:53 -0000 On Sat, Oct 11, 2014 at 11:17:23AM -0400, Allan Jude wrote: > Michael: please file a PR on this now that it is confirmed, and together > we can nag someone to fix it. Fair enough. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194304 ==ml -- Michael W. Lucas - mwlucas@michaelwlucas.com, Twitter @mwlauthor http://www.MichaelWLucas.com/, http://blather.MichaelWLucas.com/