From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 24 15:54:35 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ABD76365; Sun, 24 Mar 2013 15:54:35 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id 9DAB7178; Sun, 24 Mar 2013 15:54:34 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id c1so517563eek.0 for ; Sun, 24 Mar 2013 08:54:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=Emtae1618muquy32s6nL0JJctWCBSIJDbLuTjfio9FE=; b=Qx002wwl+f5vgomlrFhu7LITYBSE5e8UEFGES1uxNrNuLzzIgL3ZkBaH08ILqb+VZI J1O3j6OMQsk2zQvLR0U+2yi05XFLrNslnp/NouxbPWiDxU76oXXXBIjRYmMRthHLgviB Gtv3u0uHy1sy7a/dnhkTs2+TZeMkLQkgCEKaGXgapJK6u62fsIJuVqQ3d7FkLYWqigtn wsd/mm2FHT8frBYux6OOTI9UcbnA5us1KLJHPIl98HEk3WlZfj4lvevTTRtLWOLs6Bnw e3loSDFHpmouXhaZTwe8UcSXpR62TCpthBEG0LZNSvXXokCbUEglzqfmidz2hu8ZB/kf x5VQ== X-Received: by 10.14.210.132 with SMTP id u4mr24880208eeo.19.1364140473293; Sun, 24 Mar 2013 08:54:33 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id 46sm14065040eea.3.2013.03.24.08.54.30 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 24 Mar 2013 08:54:32 -0700 (PDT) Sender: Mikolaj Golub Date: Sun, 24 Mar 2013 17:54:28 +0200 From: Mikolaj Golub To: Konstantin Belousov Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130324155426.GA87022@gmail.com> References: <20130119151253.GB88025@gmail.com> <201301251531.43540.jhb@freebsd.org> <20130212215054.GA9839@gmail.com> <201302200904.15324.jhb@freebsd.org> <20130220195801.GA8679@gmail.com> <20130316180915.GA91146@gmail.com> <20130316191605.GJ3794@kib.kiev.ua> <20130316223339.GA3534@gmail.com> <20130317063033.GL3794@kib.kiev.ua> <20130317091930.GA2833@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130317091930.GA2833@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov , Attilio Rao , "Robert N. M. Watson" , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 15:54:35 -0000 Here is an updated patch set, which I think includes all kib's suggestions. It also introduces procstat groups, umask, rlimit, and osrel notes. http://people.freebsd.org/~trociny/procstat_core.3.patch Sbuf section interface looks like below: /* start a section */ sbuf_start_section(sb, NULL); /* write something to sbuf */ ... /* start a subsection (need to save the current section length) */ sbuf_start_section(sb, &old_len); /* write something to sbuf */ ... /* end a subsection padding to 4 bytes with '\0' bytes (need to provide the previously saved section length) */ sbuf_end_section(sb, old_len, 4, 0); ... /* aling the whole section to page size */ sbuf_end_section(sb, -1, PAGE_SIZE, 0); Open issues/questions: 1) I would also like to make libprocstat(3) extract environment, args, and auxv from the core. It looks like I don't need to store envv and argv in notes, as it is already present in the core. But I think I need to know psstrings to find them. Would it be ok, if I add auxv and psstrings notes, and extract envv and agrv from a program section in the core? 2) I started NT_PROCSTAT constants from the first not used number in elf_common.h, i.e. 8. But in this case they conflict with those available on other systems: contrib/binutils/include/elf/common.h: #define NT_PSTATUS 10 /* Has a struct pstatus */ #define NT_FPREGS 12 /* Has a struct fpregset */ #define NT_PSINFO 13 /* Has a struct psinfo */ #define NT_LWPSTATUS 16 /* Has a struct lwpstatus_t */ #define NT_LWPSINFO 17 /* Has a struct lwpsinfo_t */ #define NT_WIN32PSTATUS 18 /* Has a struct win32_pstatus */ Although note name = "FreeBSD" should have disambiguated this, readelf looks like ignores this and its output for my core on i386 looks confusing: Owner Data size Description FreeBSD 0x0000006c NT_PRPSINFO (prpsinfo structure) FreeBSD 0x00000068 NT_PRSTATUS (prstatus structure) FreeBSD 0x000000b0 NT_FPREGSET (floating point registers) FreeBSD 0x00000018 NT_THRMISC (thrmisc structure) FreeBSD 0x00000304 Unknown note type: (0x00000008) FreeBSD 0x00000a6c Unknown note type: (0x00000009) FreeBSD 0x000008d4 NT_PSTATUS (pstatus structure) FreeBSD 0x0000000c Unknown note type: (0x0000000b) FreeBSD 0x00000006 NT_FPREGS (floating point registers) FreeBSD 0x000000d4 NT_PSINFO (psinfo structure) FreeBSD 0x00000008 Unknown note type: (0x0000000e) Should I use some other range for NT_PROCSTAT notes? 3) Following our current code I align notes to sizeof(Elf_Size), which is 4 on i386 and 8 on amd64. But I have an issue reading the notes by readelf on amd64, which alway uses 4 byte alignment: contrib/binutils/binutils/readelf.c: next = (Elf_External_Note *)(inote.descdata + align_power (inote.descsz, 2)); where #define align_power(addr, align) \ (((addr) + ((bfd_vma) 1 << (align)) - 1) & ((bfd_vma) -1 << (align))) Should I change alignment to 4 bytes? 4) In libprocstat I added new functions and placed them under already existent FBSD_1.3 version section in Symbol.map. Shouldn't I bump the version? Won't I need any additional care if I want to MFC the code to stable/9 and may be 8? -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 24 17:23:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EBECAA50 for ; Sun, 24 Mar 2013 17:23:16 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ia0-x235.google.com (mail-ia0-x235.google.com [IPv6:2607:f8b0:4001:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id C299D7E5 for ; Sun, 24 Mar 2013 17:23:16 +0000 (UTC) Received: by mail-ia0-f181.google.com with SMTP id o25so4906539iad.12 for ; Sun, 24 Mar 2013 10:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=B6VK3aqkQyIYzFJdlNv6pveAQ1rsrsuZ8oBW6NodRTA=; b=QE0PQgHkKjKsD0xqFHOe8WM3UYlDGFwznPzgS5lEb9owNz5ETt9DZssGWyA2b3ZR8V mSSn0hAaVaCx7w/aGNO3A8mSJOZOf1I7K6VsyWRG7Vl2spAscUVtZYWr+X1nJDORcT1b DwxnWMKSHDnP59KQ6nQcHnsWlKGzGkU0qZTjwJhWdDOubzJy7iIJba2fHtjhGuLv5jLX /X+9rbpMomWrGLDJ67sPVrQ23zOR/NUzC0CjtRr/Iq8c5Jr5mDXXDd8xdup5Tf1fM4H3 /qbvW0CiDjwR7Ib8DBgXkmkeNyqG3SAOqp+VfZOsEptvQ6X+CRJLBv1h7PcSazYN0SU5 u76A== X-Received: by 10.42.122.66 with SMTP id m2mr5044155icr.15.1364145795802; Sun, 24 Mar 2013 10:23:15 -0700 (PDT) Received: from [192.168.1.44] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id px9sm19366266igc.0.2013.03.24.10.23.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Mar 2013 10:23:14 -0700 (PDT) Message-ID: <514F367E.8000908@gmail.com> Date: Sun, 24 Mar 2013 12:23:10 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Debugging kernel cores without a stack 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.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 17:23:17 -0000 I have several core dumps that need debugged. All are the same problem. The debugging problem is when I fire up kgdb, I have to backtrace even though the kernel message buffer contains a back trace. If I try to set the frame with "frame 0xffffff8020bddb30" I get an error "Cannot access memory at address 0x0". All I have to debug with are these two pieces of information. How do I get more information? > jri.homeunix.com dumped core - see /var/crash/vmcore.29 > > Sun Mar 24 10:49:52 CDT 2013 > > FreeBSD jri.homeunix.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248680M: Sun Mar 24 07:13:16 CDT 2013 r > > panic: kdb_switch: did not reenter debugger > > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "amd64-marcel-freebsd"... > > Unread portion of the kernel message buffer: > witness_warn() at witness_warn+0x4a8/frame 0xffffff8020bdd690 > trap_pfault() at trap_pfault+0x5a/frame 0xffffff8020bdd740 > trap() at trap+0x659/frame 0xffffff8020bdd950 > calltrap() at calltrap+0x8/frame 0xffffff8020bdd950 > --- trap 0xc, rip = 0xffffffff8133519e, rsp = 0xffffff8020bdda10, rbp = 0xffffff8020bddb30 --- > ath_edma_tx_processq() at ath_edma_tx_processq+0x18e/frame 0xffffff8020bddb30 > taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xffffff8020bddb80 > taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame 0xffffff8020bddbb0 > fork_exit() at fork_exit+0x84/frame 0xffffff8020bddbf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8020bddbf0 > --- trap 0, rip = 0, rsp = 0xffffff8020bddcb0, rbp = 0 --- > > > Fatal trap 12: page fault while in kernel mode > cpuid = 0; apic id = 00 > fault virtual address = 0x0 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff8133519e > stack pointer = 0x28:0xffffff8020bdda10 > frame pointer = 0x28:0xffffff8020bddb30 > 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 = 0 (ath0 taskq) > Uptime: 2m19s > Dumping 261 out of 1771 MB:..7%..13%..25%..31%..43%..56%..62%..74%..86%..92% > (kgdb) list *(0xffffffff8133519e) > 0xffffffff8133519e is in ath_edma_tx_processq (/root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c:552). > 547 bf->bf_descid); > 548 } > 549 #endif > 550 > 551 /* This removes the buffer and decrements the queue depth */ > 552 ATH_TXQ_REMOVE(txq, bf, bf_list); > 553 if (bf->bf_state.bfs_aggr) > 554 txq->axq_aggr_depth--; > 555 txq->axq_fifo_depth --; > 556 /* XXX assert FIFO depth >= 0 */ From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 24 17:44:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E1831A4D for ; Sun, 24 Mar 2013 17:44:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id 852CA90A for ; Sun, 24 Mar 2013 17:44:55 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id r5so1913634wey.25 for ; Sun, 24 Mar 2013 10:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=quO3C0K7bTCKK5VQaezi4SHBP/ZsnoAeNPLX6d+I/hc=; b=JT8XaRauS+wmVYTTXC5IT4ZaPRPAWK7odJrpg1v667r+C8RUErV2+ORmI2FrkNZEBJ QuSDI4q6HJYH8LqlHw4M9sdmdHnP1P9ES8kPCa8ytUZLHQCy0eQXlh0ccVti4Fm4nd/N W1Es7UbyQkHPfMF09Vhzfmr0Td9I3y0yGg/tmwPrX0RMkcWLvqm63OQK+sdY2vgK7KC2 eZkPKYNlSS2HJw20/yZSXIJtD8a6KZN2A26GBgE4IkCRtYWRbwl3hm/hP+Lq3uJxV8Tv pMLFWgtHLpNwTUJpu3DlOXnFQIwfrdPwahrxftzuAJf4lFQ7aBfyJrAOEL/LOSIcS7ii Q3sQ== MIME-Version: 1.0 X-Received: by 10.180.81.232 with SMTP id d8mr12342857wiy.25.1364147087627; Sun, 24 Mar 2013 10:44:47 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Sun, 24 Mar 2013 10:44:47 -0700 (PDT) In-Reply-To: <514F367E.8000908@gmail.com> References: <514F367E.8000908@gmail.com> Date: Sun, 24 Mar 2013 10:44:47 -0700 X-Google-Sender-Auth: wHLnwdJl54aVlimXlfe7fQ3VnYQ Message-ID: Subject: Re: Debugging kernel cores without a stack From: Adrian Chadd To: Joshua Isom Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 17:44:55 -0000 You need to use 'bt' to see the stack trace, then 'frame X' to go into that frame. Post 'bt' output and I'll show you what you're looking for. Adrian On 24 March 2013 10:23, Joshua Isom wrote: > I have several core dumps that need debugged. All are the same problem. > The debugging problem is when I fire up kgdb, I have to backtrace even > though the kernel message buffer contains a back trace. If I try to set the > frame with "frame 0xffffff8020bddb30" I get an error "Cannot access memory > at address 0x0". All I have to debug with are these two pieces of > information. How do I get more information? > >> jri.homeunix.com dumped core - see /var/crash/vmcore.29 >> >> Sun Mar 24 10:49:52 CDT 2013 >> >> FreeBSD jri.homeunix.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248680M: >> Sun Mar 24 07:13:16 CDT 2013 r >> >> panic: kdb_switch: did not reenter debugger >> >> GNU gdb 6.1.1 [FreeBSD] >> Copyright 2004 Free Software Foundation, Inc. >> GDB is free software, covered by the GNU General Public License, and you >> are >> welcome to change it and/or distribute copies of it under certain >> conditions. >> Type "show copying" to see the conditions. >> There is absolutely no warranty for GDB. Type "show warranty" for >> details. >> This GDB was configured as "amd64-marcel-freebsd"... >> >> Unread portion of the kernel message buffer: >> witness_warn() at witness_warn+0x4a8/frame 0xffffff8020bdd690 >> trap_pfault() at trap_pfault+0x5a/frame 0xffffff8020bdd740 >> trap() at trap+0x659/frame 0xffffff8020bdd950 >> calltrap() at calltrap+0x8/frame 0xffffff8020bdd950 >> --- trap 0xc, rip = 0xffffffff8133519e, rsp = 0xffffff8020bdda10, rbp = >> 0xffffff8020bddb30 --- >> ath_edma_tx_processq() at ath_edma_tx_processq+0x18e/frame >> 0xffffff8020bddb30 >> taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame >> 0xffffff8020bddb80 >> taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame >> 0xffffff8020bddbb0 >> fork_exit() at fork_exit+0x84/frame 0xffffff8020bddbf0 >> fork_trampoline() at fork_trampoline+0xe/frame 0xffffff8020bddbf0 >> --- trap 0, rip = 0, rsp = 0xffffff8020bddcb0, rbp = 0 --- >> >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 0; apic id = 00 >> fault virtual address = 0x0 >> fault code = supervisor read data, page not present >> instruction pointer = 0x20:0xffffffff8133519e >> stack pointer = 0x28:0xffffff8020bdda10 >> frame pointer = 0x28:0xffffff8020bddb30 >> 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 = 0 (ath0 taskq) >> Uptime: 2m19s >> Dumping 261 out of 1771 >> MB:..7%..13%..25%..31%..43%..56%..62%..74%..86%..92% > > >> (kgdb) list *(0xffffffff8133519e) >> 0xffffffff8133519e is in ath_edma_tx_processq >> (/root/ATH/head/sys/modules/ath/../../dev/ath/if_ath_tx_edma.c:552). >> 547 bf->bf_descid); >> 548 } >> 549 #endif >> 550 >> 551 /* This removes the buffer and decrements the >> queue depth */ >> 552 ATH_TXQ_REMOVE(txq, bf, bf_list); >> 553 if (bf->bf_state.bfs_aggr) >> 554 txq->axq_aggr_depth--; >> 555 txq->axq_fifo_depth --; >> 556 /* XXX assert FIFO depth >= 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" From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 24 20:32:48 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 530E19ED; Sun, 24 Mar 2013 20:32:48 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ia0-x234.google.com (mail-ia0-x234.google.com [IPv6:2607:f8b0:4001:c02::234]) by mx1.freebsd.org (Postfix) with ESMTP id 1DDA42F1; Sun, 24 Mar 2013 20:32:48 +0000 (UTC) Received: by mail-ia0-f180.google.com with SMTP id f27so4880725iae.25 for ; Sun, 24 Mar 2013 13:32:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=q8zvWyPqjcQGDcVG10bV1atJyZ7tq1PSagFI/6X0DhM=; b=KL1PzS0CNbmdI7zoUTdo7a30/XzdXYX6EBxgXsPlPrwZy3o1yxWSGcCPbEr+JN0Z/v loivcpRQmriBs0miDgl0RLVPFFIjk8WdTCRkbrRU5pELGRM2vGN7wLqeabZ9pGfBeFsE MdspCNswRnrU9l3GtMHrZQ8IHPCXGUj/kGfxHpW8a7ZDJ3hAfVnEQzAsvUvk2mKq51U2 6Sl+QkZpOoOlh7B45SNDCfopD4IXWkdSMwKej2l1oQ4zrg+PQ4wMro0q3MJD5eZGEjsE FBxI/coDqZh9z8QAJCLD91pTMpEGfQnqzZz+9WR8DH55Gf5SWJNN9gbY6OncyH7ANtJB xvPw== X-Received: by 10.42.58.67 with SMTP id g3mr5291259ich.56.1364157167583; Sun, 24 Mar 2013 13:32:47 -0700 (PDT) Received: from [192.168.1.44] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id wn10sm17019639igb.2.2013.03.24.13.32.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Mar 2013 13:32:46 -0700 (PDT) Message-ID: <514F62E9.8020100@gmail.com> Date: Sun, 24 Mar 2013 15:32:41 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Debugging kernel cores without a stack References: <514F367E.8000908@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 20:32:48 -0000 Backtrace gives me an error. The only backtrace I'm given is from the kernel message while it's crashing. After it's crashed I'm getting nothing. [jri:~] root# kgdb -q /boot/kernel/kernel /var/crash/vmcore.30 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/geom_mirror.ko...Reading symbols from /boot/kernel/geom_mirror.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_mirror.ko Reading symbols from /boot/kernel/if_ath.ko...Reading symbols from /boot/kernel/if_ath.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_ath.ko Reading symbols from /boot/kernel/amdtemp.ko...Reading symbols from /boot/kernel/amdtemp.ko.symbols...done. done. Loaded symbols for /boot/kernel/amdtemp.ko Reading symbols from /boot/kernel/if_ath_pci.ko...Reading symbols from /boot/kernel/if_ath_pci.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_ath_pci.ko Reading symbols from /boot/kernel/ums.ko...Reading symbols from /boot/kernel/ums.ko.symbols...done. done. Loaded symbols for /boot/kernel/ums.ko Reading symbols from /boot/kernel/ulpt.ko...Reading symbols from /boot/kernel/ulpt.ko.symbols...done. done. Loaded symbols for /boot/kernel/ulpt.ko Reading symbols from /boot/kernel/uhid.ko...Reading symbols from /boot/kernel/uhid.ko.symbols...done. done. Loaded symbols for /boot/kernel/uhid.ko Reading symbols from /boot/kernel/ipfw.ko...Reading symbols from /boot/kernel/ipfw.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipfw.ko Reading symbols from /boot/kernel/nullfs.ko...Reading symbols from /boot/kernel/nullfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/nullfs.ko kgdb: kvm_read: invalid address (0x354541500000000) #0 0x0000000000000000 in ?? () (kgdb) backtrace #0 0x0000000000000000 in ?? () Cannot access memory at address 0x0 (kgdb) On 3/24/2013 12:44 PM, Adrian Chadd wrote: > You need to use 'bt' to see the stack trace, then 'frame X' to go into > that frame. > > Post 'bt' output and I'll show you what you're looking for. > > > > > Adrian > From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 24 20:37:04 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 44F70B19 for ; Sun, 24 Mar 2013 20:37:04 +0000 (UTC) (envelope-from nbari@inbox.im) Received: from us3.route.mx (us3.route.mx [107.21.107.127]) by mx1.freebsd.org (Postfix) with ESMTP id F388C321 for ; Sun, 24 Mar 2013 20:37:03 +0000 (UTC) Received: (route-mx 28824 invoked from network); 24 Mar 2013 20:37:03 -0000 Received: from unknown (HELO [192.168.1.100]) (nbari@route.mx@route.mx) (envelope-sender ) by us3.route.mx (route-mx) with AES128-SHA encrypted SMTP for ; 24 Mar 2013 20:37:02 -0000 From: Nicolas de Bari Embriz Garcia Rojas Content-Type: multipart/signed; boundary="Apple-Mail=_8263D129-7C9C-4326-AF97-9BEEDBCCAF12"; protocol="application/pgp-signature"; micalg=pgp-sha512 Subject: bsnmp jail MIBS Date: Sun, 24 Mar 2013 20:36:57 +0000 Message-Id: To: freebsd-hackers@freebsd.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 20:37:04 -0000 --Apple-Mail=_8263D129-7C9C-4326-AF97-9BEEDBCCAF12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, any idea of how to properly configure the bsnmp-jails MIBS so = that I bsnmpd can properly resolve=20 I would like to use enterprises.fokus.begemot.jails instead of = .1.3.6.1.4.1.12325.1.1111 I am using bsnmpd under FreeBSD 9.1, I copied the JAILS-MIB.txt to = :/usr/share/snmp/mibs but not working, snmptranslate .1.3.6.1.4.1.12325.1.1111 returns this: SNMPv2-SMI::enterprises.12325.1.1111 any ideas ? regards -- > nbari --Apple-Mail=_8263D129-7C9C-4326-AF97-9BEEDBCCAF12 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBCgAGBQJRT2PpAAoJEHmadlLOisyrCDcP/0DYiW1uT/h2gyCafCT/CY69 7/i1j8gvUZZqFPp2YjMlflkj2FMTyV+8rXAjFlvocGNslJqp66qXkk7Jo5ioVuwb Mw3cElbAX5YZ6YXegfv8syl4wjhIDizdcpHb94fAkCNMtuIzhAMyIMwZPuJEbuVp j+jq3svBC864HTVv3Fwkh0IfHsWeRcf2kngID78IokenbWFridJedtAEiZMVwjeD zmNST/yE5mxhWVrMzH/9IpO/MdRMlwjFMRuJx+apv6jOXoYFndd6p6l8D31DyDcN v+Bh1i70BIBIiIfkiVLURRJFGONOxFrkgHGJPQdBvdb2AxjgeksmbZnm94qO4XSz KOd+EMapVrz2Oz9iE6Ny7lop5RKyHa0HcQxqpGV5gGw77WM2HJ/93e636wf8Zc1T sGu3yR2HKXMV7hzL0vtcCIUxFApLDgN1RWYfKsAFxKiXR4MXgz0e88czT5nPEgiG /bz+X0/ITr+sMHnzb5ye7xaI1RXl4YlyWwdq6E2N2Wus+eTyzV6plro4Zf8Lhgzw xyhJHcV//oSJHE9xp+D47fXcotJKeI8CH5kRbZlMc6N1hLQgT+qrCwrKwXqJ2d/+ 2Bu4HW2/Y2UA6FRbP0lJ6S++VUaUBjkgv4kHrD29WcWiRqax9xbsAfy3QHVQye+j N+qyRshBRWCvHRG9fiEQ =aExe -----END PGP SIGNATURE----- --Apple-Mail=_8263D129-7C9C-4326-AF97-9BEEDBCCAF12-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 24 21:16:19 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9CC82869 for ; Sun, 24 Mar 2013 21:16:19 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 3F7346A8 for ; Sun, 24 Mar 2013 21:16:19 +0000 (UTC) Received: from vincemacbook.unsane.co.uk (vincemacbook.unsane.co.uk [10.10.10.20]) (authenticated bits=0) by unsane.co.uk (8.14.6/8.14.6) with ESMTP id r2OLGFXu093926 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 24 Mar 2013 21:16:16 GMT (envelope-from vince@unsane.co.uk) Message-ID: <514F6D1F.2040404@unsane.co.uk> Date: Sun, 24 Mar 2013 21:16:15 +0000 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Nicolas de Bari Embriz Garcia Rojas Subject: Re: bsnmp jail MIBS References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 21:16:19 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/03/2013 20:36, Nicolas de Bari Embriz Garcia Rojas wrote: > Hi all, any idea of how to properly configure the bsnmp-jails MIBS so that I bsnmpd can properly resolve > > I would like to use enterprises.fokus.begemot.jails instead of .1.3.6.1.4.1.12325.1.1111 > > I am using bsnmpd under FreeBSD 9.1, I copied the JAILS-MIB.txt to :/usr/share/snmp/mibs > > but not working, snmptranslate .1.3.6.1.4.1.12325.1.1111 returns this: > > SNMPv2-SMI::enterprises.12325.1.1111 > > any ideas ? As far as I know snmptranslate looks for its mibs in /usr/local/share/snmp/mibs/ as its part of net-snmp having it there works for me [root@banshee /usr/local/share/snmp/mibs]# snmptranslate -m all .1.3.6.1.4.1.12325.1.1111 BEGEMOT-MIB::begemot.1111 [root@banshee /usr/local/share/snmp/mibs]# ls -la JAIL-MIB.txt - -rw-r--r-- 1 root wheel 2548 Mar 24 21:07 JAIL-MIB.txt [root@banshee /usr/local/share/snmp/mibs]# hope thats helpful. Vince > > regards > > > -- >> nbari > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRT20fAAoJEF4mgOY1fXowSUgP/2nsrgG52yFG9kHwf0TPO+Yt p2WUDUrbDnfL9UCyI19ijoywAPkurlLhdGbmYu81OOEDMv0YQxnI/fhBGSlIsZwF FGuB+dFj80PclkaSG356QdT+TPHGXpIj/JKTNvTdcPXt949Uoq3ckE06pHQuPJ4D iRDkbFRzZOVqGesyBpmbf2bXy/TfvHPQ+/NO4oS2c+v1ayvC9A505MJcQVSJOn/x 5zRRLxSDAalQJVcq+NcDTLrDk8I8S5gDA34MkscwZUB1jR741Busyz8WTRthd3oB W2FtXwCu6n+qghdUBJVuYtlvuo9UEA32kG4uuSeQqBlsL1jL7kmiEJLrEB9saTYd /yZmSh4DRz5GT6XeFTZpH3N3b+o21QicczwblvDkAT7j46//gtLYo+wMuC5m+zdV fJivIog9pfPjvekj5o8bMGV16sqt/FO11HYNOJxHSTKbY7El6xFE0VgppnnrSBpT KjXn9UJWBiouFfpsSL2DvLMKpfc8QardVRz2NR9IkpuqPeVErgkhZ3Tj0vXcEwPC 27KslN0u5wcTgq3D5vvcV++xn5+EPyEUnphNMRYtRm7u3x6K7FTlz800ok7+gZNU rsDjwZ8SuiktOEOI3XGIPaMvceJTJWq4pJxQapZIxjGxYlqyFWOuRyPja1IEpdik 8RgSHMr03vAwvwWyNhJm =UTDJ -----END PGP SIGNATURE----- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 24 21:27:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 918F6D41 for ; Sun, 24 Mar 2013 21:27:23 +0000 (UTC) (envelope-from nbari@inbox.im) Received: from us3.route.mx (us3.route.mx [107.21.107.127]) by mx1.freebsd.org (Postfix) with ESMTP id 2CCC2727 for ; Sun, 24 Mar 2013 21:27:22 +0000 (UTC) Received: (route-mx 29068 invoked from network); 24 Mar 2013 21:27:15 -0000 Received: from unknown (HELO [192.168.1.100]) (nbari@route.mx@route.mx) (envelope-sender ) by us3.route.mx (route-mx) with AES128-SHA encrypted SMTP for ; 24 Mar 2013 21:27:15 -0000 Subject: Re: bsnmp jail MIBS Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/signed; boundary="Apple-Mail=_D146FA79-077D-4805-9AEF-1F6F8C548C5C"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Nicolas de Bari Embriz Garcia Rojas In-Reply-To: <514F6D1F.2040404@unsane.co.uk> Date: Sun, 24 Mar 2013 21:27:11 +0000 Message-Id: <7CB37C27-164D-4537-8BA8-783A405D8856@inbox.im> References: <514F6D1F.2040404@unsane.co.uk> To: Vincent Hoffman X-Mailer: Apple Mail (2.1283) X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 21:27:23 -0000 --Apple-Mail=_D146FA79-077D-4805-9AEF-1F6F8C548C5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Thanks that made the trick. I just copy the all the MIBS from /usr/shar/snmp/mibs to = /usr/local/share/snmp/mibs/ and now can get details with snmpwalk -v2c -c public localhost JAILS-MIB::jails Can the values of jailInOctets and jailOutOctets be used for measuring = the jail bandwidth consummation. regards. -- > nbari On Mar 24, 2013, at 9:16 PM, Vincent Hoffman wrote: > On 24/03/2013 20:36, Nicolas de Bari Embriz Garcia Rojas wrote: > > Hi all, any idea of how to properly configure the bsnmp-jails MIBS = so that I bsnmpd can properly > resolve > > > > I would like to use enterprises.fokus.begemot.jails instead of > .1.3.6.1.4.1.12325.1.1111 > > > > I am using bsnmpd under FreeBSD 9.1, I copied the JAILS-MIB.txt to > :/usr/share/snmp/mibs > > > > but not working, snmptranslate .1.3.6.1.4.1.12325.1.1111 returns = this: > > > > SNMPv2-SMI::enterprises.12325.1.1111 > > > > any ideas ? > As far as I know snmptranslate looks for its mibs in > /usr/local/share/snmp/mibs/ as its part of net-snmp >=20 > having it there works for me >=20 > [root@banshee /usr/local/share/snmp/mibs]# snmptranslate -m all > .1.3.6.1.4.1.12325.1.1111 > BEGEMOT-MIB::begemot.1111 > [root@banshee /usr/local/share/snmp/mibs]# ls -la JAIL-MIB.txt > - -rw-r--r-- 1 root wheel 2548 Mar 24 21:07 JAIL-MIB.txt > [root@banshee /usr/local/share/snmp/mibs]# >=20 >=20 > hope thats helpful. >=20 > Vince > > > > regards > > > > > > -- > >> nbari > > >=20 --Apple-Mail=_D146FA79-077D-4805-9AEF-1F6F8C548C5C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) iQIcBAEBCgAGBQJRT2+vAAoJEHmadlLOisyrLm4P/Rdu9NKxci/EAK9YC+f4Rk8+ kitocT8XSfyFaNzZ0/fQJuzOmH/MTZoAMa1XfDKoxE9jEbZBkHwCF5Smwu4SutlN VfmbTXcLnRyWZ1Ovz2pJtc1SbXI/kpA9MCebEHjTGZ5nOfCiEaCpFrs29n80hCn8 xhrsoaQzV6eJYVbxxBi+2lEwMDYGMThJe21/8B6B0y401FN1hJbHFCKH5eZyyDWu tLfgnMvYM9Kp6gr8YCHxlB5Tpk+AMEt5pPf61PuPJuTpbBStLUFpkmY9XAqUunkb +5vJsoWHWdU+QSvx1GtZQvJyaaK8QPpdcDtHjTPn9towZ5jKdnG9xXCi7WWjPyHR Pn+XfoFJrxeClJJK3TnCoaV8yWXoHrrNYJrXPBpddS9+e0Dyn82X3XytAVEPwU5/ QbZ57j89f56qDfkVI5UHtsqu07M4B8XjlG7XvyNiQEXYfdH2x2SslqZPHa184huI PM1h/eoxMZ4o1lTsRVni+FiHKYQNDth+unGT2mki1q83NJ+Ijcu3GBjudVAZhM/0 jV1zDTiQ4DYvDTSY5bnT2mVMZ0JSuqE+Gar8LDlusGjmyvphnC6YnpjKj2nfOa+X nZkKUh1kOMYf30k8twPfEUDMH19hc6Y6ba/Tm396Vf6SUdv7zWN9/oRLoTqcDT13 8h0VhQqDjI6tC6WwnuxA =94kF -----END PGP SIGNATURE----- --Apple-Mail=_D146FA79-077D-4805-9AEF-1F6F8C548C5C-- From owner-freebsd-hackers@FreeBSD.ORG Sun Mar 24 21:49:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4C2D67B for ; Sun, 24 Mar 2013 21:49:55 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id E03957DC for ; Sun, 24 Mar 2013 21:49:54 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id p43so4592608wea.12 for ; Sun, 24 Mar 2013 14:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=t1U1L2Kj7DWeyOk3DvQYuivgZrGrtqCA1Si/HZXnYS0=; b=qTaYYw2jSiAza7a0blTBuNAPXEKNnYOQ03ss6b2RpplFAyv1Qo5tj2i4JAqtn3JBlL smGKRgCLNYT6G8T1HU5LwU9Ytr1KXGMl/QXhqKZhFttyzjbk06Ed2UIRxPU2MJbW8zUG vL+itWhLVwoNaX2ZcS8MHMwIGXUCa67Rwm9kVQYoYYF6V4nuBtIJHEFoJdeUF3RCOor7 RQSFkCkJWBjmZJmJH8O/lg13Ri/Qom6LS02IwYSncVKp7Y4Llz4+yKCWNv7CBJsOoPD7 X8WuhmkQehb9Nj0EzdYyfb3VOagz0FFpync0ZVuJL7HdPTNezuQDYTf62Z1P1eJlpQxb YvaQ== MIME-Version: 1.0 X-Received: by 10.194.120.169 with SMTP id ld9mr14157568wjb.24.1364161794119; Sun, 24 Mar 2013 14:49:54 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Sun, 24 Mar 2013 14:49:53 -0700 (PDT) In-Reply-To: <514F62E9.8020100@gmail.com> References: <514F367E.8000908@gmail.com> <514F62E9.8020100@gmail.com> Date: Sun, 24 Mar 2013 14:49:53 -0700 X-Google-Sender-Auth: IBCGvYwbjPY8FEIjEx1KXkCftzU Message-ID: Subject: Re: Debugging kernel cores without a stack From: Adrian Chadd To: Joshua Isom Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Mar 2013 21:49:55 -0000 Hi, Do you rebuild the world _and_ kernel together, or do you have them out of sync? Adrian From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 25 00:19:45 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C2659AEC; Mon, 25 Mar 2013 00:19:45 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 8D43DD8C; Mon, 25 Mar 2013 00:19:45 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id at1so2795026iec.41 for ; Sun, 24 Mar 2013 17:19:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=Rc5VIiPFxtHxsoiJPDJJ/YBQLql/mRqbHZU6OfVVB+4=; b=JGZRe+tHdw8cZoKMxX1h+yL5fbL4aNqsBkKRCB3PQ7wagxjxWthhB3r3Fxb7iqfUer XQzOtAPiJigLhpxfV9oxmYWJTHaYlM0Xx3JRXfRBn1CceRheq7OXxiKPFtl9yqdJpK4Q xeocu8exMwK+ooL65yLjxNWrksJMVeBJzUYJDEn20mNKxwmjZp70lhUWvzbI04V3xhBQ fq8pQlgM5M6ko9CbNDzH3knds6/U++2scm3/kV0FdICR2NBtRJuJQ/ZXw+0WqE9hxZr8 zTL+M+ykx+NTW323klCwrmDoK+L4vhZj9dvSigmsbeGl38Iwvi1EISLb7uRHkuNQ8zD/ rIfw== X-Received: by 10.50.51.200 with SMTP id m8mr6309594igo.52.1364170785157; Sun, 24 Mar 2013 17:19:45 -0700 (PDT) Received: from [192.168.1.44] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id ew5sm13645270igc.2.2013.03.24.17.19.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 24 Mar 2013 17:19:44 -0700 (PDT) Message-ID: <514F981A.6090902@gmail.com> Date: Sun, 24 Mar 2013 19:19:38 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Debugging kernel cores without a stack References: <514F367E.8000908@gmail.com> <514F62E9.8020100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 00:19:45 -0000 So far they've been out of sync. I'd done it once before with a 6 base and 7 kernel to get some hardware to work. I installed world in a chroot and kgdb seems to be working fine in the chroot. I thought the debugger would have worked regardless. On 3/24/2013 4:49 PM, Adrian Chadd wrote: > Hi, > > Do you rebuild the world _and_ kernel together, or do you have them out of sync? > > > > > Adrian > From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 25 04:42:21 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A389E24 for ; Mon, 25 Mar 2013 04:42:21 +0000 (UTC) (envelope-from yuri@rawbw.com) Received: from shell0.rawbw.com (shell0.rawbw.com [198.144.192.45]) by mx1.freebsd.org (Postfix) with ESMTP id 71350954 for ; Mon, 25 Mar 2013 04:42:21 +0000 (UTC) Received: from eagle.yuri.org (stunnel@localhost [127.0.0.1]) (authenticated bits=0) by shell0.rawbw.com (8.14.4/8.14.4) with ESMTP id r2P4Ddpe033791 for ; Sun, 24 Mar 2013 21:13:39 -0700 (PDT) (envelope-from yuri@rawbw.com) Message-ID: <514FCEF3.8070902@rawbw.com> Date: Sun, 24 Mar 2013 21:13:39 -0700 From: Yuri User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130226 Thunderbird/17.0.3 MIME-Version: 1.0 To: FreeBSD Hackers Subject: helgrind (valgrind plugin) errors coming from nsdispatch(3) 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.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 04:42:21 -0000 While running helgrind on my program, I observed several errors that stem from the nsdispatch calls, see helgrind log below. "lock order" error in helgrind is generated when some data is protected by two mutexes, and they were locked in different order on different occasions. I think, mutexes in question are nss_lock and conf_lock in lib/libc/net/nsdispatch.c It seems like authors of helgrind took an approach that such situation is error prone in general, thus they point it out. So what would be the prevalent judgement here, is this something worth fixing in libc, or such errors should be ignored? 9.1-STABLE amd64 valgrind-3.8.0_1,1 Yuri ---helgrind log--- ==6736== Thread #1: lock order "0x282B150 before 0x282B190" violated ==6736== ==6736== Observed (incorrect) order is: acquisition of lock at 0x282B190 ==6736== at 0x155AA4F: pthread_mutex_trylock (hg_intercepts.c:550) ==6736== by 0x25B87F8: nsdispatch (in /lib/libc.so.7) ==6736== by 0x25A3C50: getpwuid_r (in /lib/libc.so.7) ==6736== by 0x3153EAA: ??? ==6736== by 0x3152B5D: ??? ==6736== by 0x3074F3C: ??? ==6736== by 0x8225A6: myfunc2(bool) (my1.cpp:146) ==6736== by 0x5FC14A: myfunc1(int, char**) (my2.cpp:39) ==6736== by 0x5E5B61: main (main.cpp:326) ==6736== ==6736== followed by a later acquisition of lock at 0x282B150 ==6736== at 0x155C27F: pthread_rwlock_wrlock_WRK (hg_intercepts.c:1479) ==6736== by 0x25B8818: nsdispatch (in /lib/libc.so.7) ==6736== by 0x25A3C50: getpwuid_r (in /lib/libc.so.7) ==6736== by 0x3153EAA: ??? ==6736== by 0x3152B5D: ??? ==6736== by 0x3074F3C: ??? ==6736== by 0x8225A6: myfunc2(bool) (my1.cpp:146) ==6736== by 0x5FC14A: myfunc1(int, char**) (my2.cpp:39) ==6736== by 0x5E5B61: main (main.cpp:326) ==6736== ==6736== Required order was established by acquisition of lock at 0x282B150 ==6736== at 0x155C44F: pthread_rwlock_rdlock_WRK (hg_intercepts.c:1532) ==6736== by 0x25B8126: nsdispatch (in /lib/libc.so.7) ==6736== by 0x25A3C50: getpwuid_r (in /lib/libc.so.7) ==6736== by 0x3153EAA: ??? ==6736== by 0x3152B5D: ??? ==6736== by 0x3074F3C: ??? ==6736== by 0x8225A6: myfunc2(bool) (my1.cpp:146) ==6736== by 0x5FC14A: myfunc1(int, char**) (my2.cpp:39) ==6736== by 0x5E5B61: main (main.cpp:326) ==6736== ==6736== followed by a later acquisition of lock at 0x282B190 ==6736== at 0x155AA4F: pthread_mutex_trylock (hg_intercepts.c:550) ==6736== by 0x25B87F8: nsdispatch (in /lib/libc.so.7) ==6736== by 0x25A3C50: getpwuid_r (in /lib/libc.so.7) ==6736== by 0x3153EAA: ??? ==6736== by 0x3152B5D: ??? ==6736== by 0x3074F3C: ??? ==6736== by 0x8225A6: myfunc2(bool) (my1.cpp:146) ==6736== by 0x5FC14A: myfunc1(int, char**) (my2.cpp:39) ==6736== by 0x5E5B61: main (main.cpp:326) From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 25 07:42:06 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2F7BD1DF for ; Mon, 25 Mar 2013 07:42:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5DB481F8 for ; Mon, 25 Mar 2013 07:42:05 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id JAA20655; Mon, 25 Mar 2013 09:42:01 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UK22b-000Ntu-Cj; Mon, 25 Mar 2013 09:42:01 +0200 Message-ID: <514FFFC6.9040602@FreeBSD.org> Date: Mon, 25 Mar 2013 09:41:58 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: Joshua Isom Subject: Re: Debugging kernel cores without a stack References: <514F367E.8000908@gmail.com> <514F62E9.8020100@gmail.com> <514F981A.6090902@gmail.com> In-Reply-To: <514F981A.6090902@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 07:42:06 -0000 on 25/03/2013 02:19 Joshua Isom said the following: > I thought the debugger would have worked regardless. No, kgdb and libkvm have to be in sync with kernel. Unfortunately. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 25 20:44:15 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B0DDCE00; Mon, 25 Mar 2013 20:44:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C0E1EF77; Mon, 25 Mar 2013 20:44:14 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id WAA28554; Mon, 25 Mar 2013 22:44:13 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UKEFZ-000PDL-4Y; Mon, 25 Mar 2013 22:44:13 +0200 Message-ID: <5150B71B.6060106@FreeBSD.org> Date: Mon, 25 Mar 2013 22:44:11 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD Current , freebsd-hackers@FreeBSD.org Subject: Fwd: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good References: <5150B598.7050700@FreeBSD.org> In-Reply-To: <5150B598.7050700@FreeBSD.org> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <5150B598.7050700@FreeBSD.org> Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 20:44:15 -0000 Would like to ask for opinions on this topic... Please read this PR for context: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 Especially Jaakko's insightful description of the problem. -------- Original Message -------- Message-ID: <5150B598.7050700@FreeBSD.org> Date: Mon, 25 Mar 2013 22:37:44 +0200 From: Andriy Gapon Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good Can't believe that we are still where we were more than two years ago... I think that we have to make this change even if it _might_ break some existing rulesets. Rationale: - current behavior is contrary to any documentation - current behavior is contrary to common sense - current behavior is very hard to describe and account for - I presume that very few people actually fully understand the current behavior - I presume that even fewer people made a conscious choice to depend or make use of its non-trivial features of the current behavior So, we should make the behavior of devfs pattern consistent with the documentation and the common sense. In addition to Jaakko's patch I propose that we pass FNM_PATHNAME to fnmatch(9), so that the matching is indeed consistent with glob(3) / shell glob-ing rules for filesystem paths. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 25 20:58:49 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6BFF5238; Mon, 25 Mar 2013 20:58:49 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id B5208D9; Mon, 25 Mar 2013 20:58:48 +0000 (UTC) Received: by mail-we0-f175.google.com with SMTP id t11so3467387wey.34 for ; Mon, 25 Mar 2013 13:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NjV7IsSndrzfxsxeWH9SrUdQiCmqSO2rPRRuaQqUldU=; b=m+5wQNwR7LOH4/+spcnWTMnSTnUDEhAsnyfxFsIjT1gLv0+msk8Gcbio0o9Ltc2onG s4v55o4sHgkqA0VNTD10kVWTJSPTs2OYZojAXdVfMdpp0tE7o6Mt+b8cs7TnnYRGYji8 k+l+Mb+JNG+vsmZGgTCf/GJlsU21V+5XCkuITzRRVoHs8wuSgj4bU8ew/Il786ZgIaPZ PX0dCFo08Ng6zjPLUKz5LESx33FrLPkDykxi5Jh5RiUY11JHzOh1ytPgwuZIC/24xmBA TGOXfIqvgHcqCcjhKebx8zBhippyHRU7kSmaY9zeE90s0H9Q+EzftrZ79Wi0/tdnk+1S NmwA== MIME-Version: 1.0 X-Received: by 10.180.73.6 with SMTP id h6mr4359094wiv.27.1364245127844; Mon, 25 Mar 2013 13:58:47 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 25 Mar 2013 13:58:47 -0700 (PDT) In-Reply-To: <5150B71B.6060106@FreeBSD.org> References: <5150B598.7050700@FreeBSD.org> <5150B71B.6060106@FreeBSD.org> Date: Mon, 25 Mar 2013 22:58:47 +0200 Message-ID: Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like zvol/pool/vms) good From: Kimmo Paasiala To: Andriy Gapon Content-Type: text/plain; charset=UTF-8 X-Mailman-Approved-At: Mon, 25 Mar 2013 21:22:34 +0000 Cc: freebsd-hackers@freebsd.org, FreeBSD Current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 20:58:49 -0000 On Mon, Mar 25, 2013 at 10:44 PM, Andriy Gapon wrote: > > Would like to ask for opinions on this topic... > Please read this PR for context: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 > Especially Jaakko's insightful description of the problem. > > > -------- Original Message -------- > Message-ID: <5150B598.7050700@FreeBSD.org> > Date: Mon, 25 Mar 2013 22:37:44 +0200 > From: Andriy Gapon > Subject: Re: kern/122838: [devfs] devfs doesn't handle complex paths (like > zvol/pool/vms) good > > > Can't believe that we are still where we were more than two years ago... > > I think that we have to make this change even if it _might_ break some existing > rulesets. > > Rationale: > - current behavior is contrary to any documentation > - current behavior is contrary to common sense > - current behavior is very hard to describe and account for > - I presume that very few people actually fully understand the current behavior > - I presume that even fewer people made a conscious choice to depend or make use > of its non-trivial features of the current behavior > > So, we should make the behavior of devfs pattern consistent with the > documentation and the common sense. > > In addition to Jaakko's patch I propose that we pass FNM_PATHNAME to fnmatch(9), > so that the matching is indeed consistent with glob(3) / shell glob-ing rules > for filesystem paths. > > -- > Andriy Gapon > > > Absolutely yes. Any kind of rule based matching should default to matching full strings. The rule syntax should then offer options to narrow down the matching to a specific part(s) of the matched strings. -Kimmo From owner-freebsd-hackers@FreeBSD.ORG Mon Mar 25 22:21:17 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5A46168E; Mon, 25 Mar 2013 22:21:17 +0000 (UTC) (envelope-from jrisom@gmail.com) Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) by mx1.freebsd.org (Postfix) with ESMTP id 224CE693; Mon, 25 Mar 2013 22:21:17 +0000 (UTC) Received: by mail-ia0-f169.google.com with SMTP id j5so6041680iaf.0 for ; Mon, 25 Mar 2013 15:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=3w17sCn+Q7ir8s05XZI//ZAxCY7FsnKFmrlyOZiD5QE=; b=AJZ8tbL1CiexbelYY/k1yhE0EoHsGPJG4trhB9fM9H57DeBeBpS2PtK/UZFEgv/6wD aqaCOZ70zMg/+Fi9hYbecvDy6MtBeADs2PaXg4Vs4LVc+pGeKC1B9QdXhTCV6ZRRE1fq 5BvrZ8fP1FTyHjzAC3IO7JhiWBsv0pikH7hao5sUZtOsMHmwiSY9/TW92G1ar6R0FSqL CSZsUOXLWGu6+QqA+7Op4EzGDEQBH5BDr4jz49uppkLoBJIabK1X+2fPiM2FvCPhzUE2 DwWcZLL95qqNjaIy6dtvbD6OFWrW0GfX658oetUTScR6b6rsGiXbpaue0zSYt0+Qpyi0 O0UQ== X-Received: by 10.50.56.236 with SMTP id d12mr12719320igq.92.1364250076828; Mon, 25 Mar 2013 15:21:16 -0700 (PDT) Received: from [192.168.1.44] (c-98-212-197-211.hsd1.il.comcast.net. [98.212.197.211]) by mx.google.com with ESMTPS id ua6sm21581449igb.0.2013.03.25.15.21.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 15:21:16 -0700 (PDT) Message-ID: <5150CDD5.5080102@gmail.com> Date: Mon, 25 Mar 2013 17:21:09 -0500 From: Joshua Isom User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Andriy Gapon Subject: Re: Debugging kernel cores without a stack References: <514F367E.8000908@gmail.com> <514F62E9.8020100@gmail.com> <514F981A.6090902@gmail.com> <514FFFC6.9040602@FreeBSD.org> In-Reply-To: <514FFFC6.9040602@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 22:21:17 -0000 On 3/25/2013 2:41 AM, Andriy Gapon wrote: > on 25/03/2013 02:19 Joshua Isom said the following: >> I thought the debugger would have worked regardless. > > No, kgdb and libkvm have to be in sync with kernel. > Unfortunately. > Is it a bug or necessity? From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 26 00:54:03 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3E2CAE46; Tue, 26 Mar 2013 00:54:03 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id AFF37D1C; Tue, 26 Mar 2013 00:54:02 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id r5so3029902wey.39 for ; Mon, 25 Mar 2013 17:54:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=XwAbQnZEoXlryP/gzXdbNx3VtNpplqEzWa7sgXCCBmQ=; b=lDekJdIR3nvTuvBLsyCYpRcr5Dfnm6G+3U5D6jBKsDXGjksWjrrSWxzqnx3Fyz0SLz SebrGIlBHdkdyn7WOAjiP80fCwRsZ/7ZV9SZcVgquMtpgxywAuuUQKjqi+Qz17UDoSYn rBLv1Ye4eJQcsr54cEjTMQTULIZV4Fz5ETdkqMZeIekbEpcRS2HqumIx0Z92OhuXOJCg 9hmwyS44hHN72vcQsmn4WJauNxC6daug8ykl7PHh099BHxR/+X4WhP0RLwrI5HaUo2vU xG+zMaPf3yW6hzYGpjcCUI0lNBuJKqFbaMvuEWfIVJElYdcdQQqsUb7ZluaDp5yIqtTX Sa1w== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr20878365wid.29.1364259241884; Mon, 25 Mar 2013 17:54:01 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Mon, 25 Mar 2013 17:54:01 -0700 (PDT) In-Reply-To: <5150CDD5.5080102@gmail.com> References: <514F367E.8000908@gmail.com> <514F62E9.8020100@gmail.com> <514F981A.6090902@gmail.com> <514FFFC6.9040602@FreeBSD.org> <5150CDD5.5080102@gmail.com> Date: Mon, 25 Mar 2013 17:54:01 -0700 X-Google-Sender-Auth: SrouZxVyuLV6ifudtDG4wFcXDqU Message-ID: Subject: Re: Debugging kernel cores without a stack From: Adrian Chadd To: Joshua Isom Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, Andriy Gapon X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 00:54:03 -0000 It's because there are kernel structures which kgdb needs to get its grubby fingers into when decoding things. I wish things weren't so tightly coupled though.. Adrian From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 26 01:58:33 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 62617C8E for ; Tue, 26 Mar 2013 01:58:33 +0000 (UTC) (envelope-from paul.koch137@gmail.com) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by mx1.freebsd.org (Postfix) with ESMTP id 41F96F3E for ; Tue, 26 Mar 2013 01:58:33 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id wp1so1336625pac.33 for ; Mon, 25 Mar 2013 18:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:subject:message-id:x-mailer:mime-version :content-type:content-transfer-encoding; bh=9+6VbZKDbnEYx8sRlZitktLouYA8c8xzIgMmvBoFTmE=; b=ibSvl/dOLI7jYdhM7eJUUS4wdWFNLvz6fI6pXxX0C+VmSX7TQIZJ5+a4DZl73sdj8Q SSJ6NBT118o0HaO44pE8RhalsY2dYj+G0VDyHCOdcjksXVjIW0ReKkrhx452NnaZIaba ZacuFAxUCTTEOc05HoLzrn/AiFl/gXnzMMpfHRJws85Busvv8/td5skg5xbmGHQSkhMB lt3AtZ/53S5Ht+ftk3CCDYbYbeDbrme+ixHVMwaTjUsEVrleSyYQSR4FfBhQE2QXM0fj +qozrlVIEUdRMid2K5z0IFFWRpZTzKwq4ZL2qcpBti0deKdAyQYup9uj7q+qI2Ty/7NG aU0A== X-Received: by 10.68.91.66 with SMTP id cc2mr20936752pbb.51.1364263107316; Mon, 25 Mar 2013 18:58:27 -0700 (PDT) Received: from speedy (CPE-121-222-103-202.lnse2.cha.bigpond.net.au. [121.222.103.202]) by mx.google.com with ESMTPS id ri1sm15431724pbc.16.2013.03.25.18.58.25 (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 25 Mar 2013 18:58:26 -0700 (PDT) Date: Tue, 26 Mar 2013 11:58:02 +1000 From: Paul Koch To: hackers@freebsd.org Subject: syscalls per process ? Message-ID: <20130326115802.15ce1626@speedy> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.6; amd64-portbld-freebsd9.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 01:58:33 -0000 Hi, At the start of all our programs, we set up a SIGALRM signal handler to retrieve rusage stats each second and log this info for analysis. It is useful for long running programs. One of the things we would really really like to get is the number of system calls the process has performed. Is there a simple way for a process to retrieve its own number of syscalls it has performed ? Pity it's not available via getrusage(). We don't want to run an external program (eg. truss/dtrace) on each program. Paul. From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 26 06:57:37 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B3E158F3 for ; Tue, 26 Mar 2013 06:57:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2EF5EFBA for ; Tue, 26 Mar 2013 06:57:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2Q6vQm4034690; Tue, 26 Mar 2013 08:57:26 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2Q6vQm4034690 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2Q6vQkZ034689; Tue, 26 Mar 2013 08:57:26 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 26 Mar 2013 08:57:26 +0200 From: Konstantin Belousov To: Paul Koch Subject: Re: syscalls per process ? Message-ID: <20130326065726.GM3794@kib.kiev.ua> References: <20130326115802.15ce1626@speedy> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qJd89WIdOyaVRnzq" Content-Disposition: inline In-Reply-To: <20130326115802.15ce1626@speedy> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 06:57:37 -0000 --qJd89WIdOyaVRnzq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 26, 2013 at 11:58:02AM +1000, Paul Koch wrote: > Hi, >=20 > At the start of all our programs, we set up a SIGALRM signal handler > to retrieve rusage stats each second and log this info for analysis. > It is useful for long running programs. One of the things we > would really really like to get is the number of system calls the > process has performed. >=20 > Is there a simple way for a process to retrieve its own number of > syscalls it has performed ? Pity it's not available via getrusage(). >=20 > We don't want to run an external program (eg. truss/dtrace) on each > program. AFAIR, the per-threads syscalls are not accounted. The accounting was performed for some short time, but it was only used as a workaround for some nfs client issue, and since the alternate approach was used, the td_syscalls was removed. Only global system count of the syscalls is maintained. --qJd89WIdOyaVRnzq Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRUUbVAAoJEJDCuSvBvK1Bn/YP/jCe3TtEYugmKlPZZPdOxYZq CEQQz68gdiD71n1dH09V3J1DAQVVZi3cre4trdR4BBb+h34npY3IdlMsLA7qaL1Z bwUAwkFcQ6jejcZYKcKKeFKbsrhG5uNdPaWoDrxBcVSXUHkoiMBDq3HzDxzVQBdO RsmwN89WTA9JhVIQJq/wuc+zzjhEPxI2KOKuzLIE71qsFqcMeKc6gvWCPjnrvye6 ArLIUr45lETFsqido6Yp2ylWfClF1tQNjtuGxixKuAv6uf2ZB8rbr7vaIROv+jV3 efe6dB7TZLBogvz9i9Zj1/A36ooSY7+KOqviIbjpN82Epx3IGoBeq7KgzmrPZ205 6x7YUPlGU86D+L4X/9P3xatROS8hMjVU13WYeFSf3NGIiL7tAly4m3W5vpoVGOgb oAZ/rqAQi8+NRL/+NJ3kluGNq55fY8PDELk7Ubk1CbxFzRvRy/lYvoIhnYlIoZ3+ 2uHN0S1eXAU/5H0AUevZJJOiIVa8FFnBs8pTLjAFHFg6sdHY+KMpK4nZQfY3m4lY XbZY9f/GWBd5TsJLliK6rYOYo6UihYq2gIwDc0zb0dw5wiqDYHm6irmQqEz1Z+8H CJbMn2WT6v/+ZS/2ZQjGGG6RjX+QBakmA2aECFOxCjA99Dd7cCmogeNFP2laqePR K0rl9pBbch2bA0JiNnjE =90md -----END PGP SIGNATURE----- --qJd89WIdOyaVRnzq-- From owner-freebsd-hackers@FreeBSD.ORG Tue Mar 26 10:40:38 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2D10A4A4 for ; Tue, 26 Mar 2013 10:40:38 +0000 (UTC) (envelope-from mattblists@icritical.com) Received: from mail1.icritical.com (mail1.icritical.com [93.95.13.41]) by mx1.freebsd.org (Postfix) with SMTP id 9158510B for ; Tue, 26 Mar 2013 10:40:36 +0000 (UTC) Received: (qmail 9626 invoked from network); 26 Mar 2013 10:34:15 -0000 Received: from localhost (127.0.0.1) by mail1.icritical.com with SMTP; 26 Mar 2013 10:34:15 -0000 Received: (qmail 9614 invoked by uid 599); 26 Mar 2013 10:34:15 -0000 Received: from unknown (HELO PDC002.icritical.int) (212.57.254.146) by mail1.icritical.com (qpsmtpd/0.28) with ESMTP; Tue, 26 Mar 2013 10:34:15 +0000 Message-ID: <515179A2.2090904@icritical.com> Date: Tue, 26 Mar 2013 10:34:10 +0000 From: Matt Burke User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130122 Thunderbird/17.0.2 MIME-Version: 1.0 To: Paul Koch Subject: Re: syscalls per process ? References: <20130326115802.15ce1626@speedy> In-Reply-To: <20130326115802.15ce1626@speedy> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-TLS-Incoming: YES X-Virus-Scanned: by iCritical at mail1.icritical.com Cc: hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 10:40:38 -0000 On 03/26/13 01:58, Paul Koch wrote: > We don't want to run an external program (eg. truss/dtrace) on each > program. Not exactly what you want, but a single DTrace instance can collect data globally, not just while attached to a specific target: # dtrace -qn 'syscall:::entry{@x[execname,probefunc]=count()} tick-1s{trunc(@x,20); printa(@x); exit(1)}' chrome poll 557 Xorg writev 685 chrome read 690 wine write 700 nvidia-settings read 702 Xorg select 724 conky poll 853 wineserver freebsd32_gettimeofday 1001 wineserver write 1071 wineserver read 1136 wineserver freebsd32_kevent 1163 conky read 1308 chrome gettimeofday 1316 Xorg read 1431 Xorg setitimer 1448 chrome clock_gettime 1685 wine sigprocmask 1810 wine freebsd32_gettimeofday 1872 wine read 2393 Xorg clock_gettime 31594 -- Sorry for the following... iCritical is a brand of Critical Software Ltd. Registered in England & Wales: 04909220. Registered Office: IC2, Keele Science Park, Keele, Staffordshire, ST5 5NH. This message has been scanned for security threats by iCritical. The information contained in this message is confidential and intended for the addressee only. If you have received this message in error, or there are any problems with its content, please contact the sender. From owner-freebsd-hackers@FreeBSD.ORG Wed Mar 27 00:56:55 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1D05EAB for ; Wed, 27 Mar 2013 00:56:55 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 8026922A for ; Wed, 27 Mar 2013 00:56:55 +0000 (UTC) Received: by mail-ob0-f173.google.com with SMTP id dn14so7584815obc.4 for ; Tue, 26 Mar 2013 17:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Zeb/GqwqTyH7ofYccVNIo3tLx9dlPL3LdJjH6bG02Ms=; b=zR/+de5qI+VVcpNRJR8nLSoRPve/yEGcnfCx2cBkfVsOqB31Mvsx+HX6s0yEF8Xmcb 9In7gdx94+KaiLcmHGDiGx13av++NJpC2Vb4mTpHKPZjoSdt/HSnXLnAECCY2QN0E2Ry yaM3fMsOI6SIVhSybXr0MQBfH+cgAQmDDFlPLM9iot6ugy6jhQ6SoxoYzZWrikozqyK/ 27Ix6dGjSM851Zt77ROGv1HTxqiImVAzxFzEsxe2HWmuSzULpysVrcaz3cABoK55dewk la9JKceK9+OXT2cGI8sLr4HRegRNmwpR31GvO9P0f3CQKutBr+uamOyAjlbXU22SLBp1 k4QA== MIME-Version: 1.0 X-Received: by 10.60.28.37 with SMTP id y5mr3858007oeg.134.1364345815133; Tue, 26 Mar 2013 17:56:55 -0700 (PDT) Sender: carpeddiem@gmail.com Received: by 10.60.132.142 with HTTP; Tue, 26 Mar 2013 17:56:54 -0700 (PDT) In-Reply-To: <20121222164602.GB32022@sandvine.com> References: <20121222164602.GB32022@sandvine.com> Date: Tue, 26 Mar 2013 20:56:54 -0400 X-Google-Sender-Auth: XI2inxwSuif54RxpqbAydl4_hnI Message-ID: Subject: Re: [PATCH] Add WITH_DEBUG_FILES knob to enable separate debug files From: Ed Maste To: freebsd-hackers@freebsd.org Content-Type: multipart/mixed; boundary=e89a8fb1f7f0a981de04d8dd835d X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Mar 2013 00:56:55 -0000 --e89a8fb1f7f0a981de04d8dd835d Content-Type: text/plain; charset=ISO-8859-1 On 22 December 2012 11:46, Ed Maste wrote: > When this knob is set standalone debug files for shared objects are > built and installed in /usr/lib/debug/.debug. GDB > searches this path for debug data. I'm picking this up again - here is a new version of the patch, which should address the base/ports issue and other problems. Here's what it does: - Add WITH_DEBUG_FILES src.conf knob to control standalone debug file generation, instead of using standalone files whenever DEBUG_FLAGS is set. - Switch debug file extension from .symbols to .debug, for consistency with other users of this feature. - Store debug files under /usr/lib/debug for base system components, and in a .debug subdirectory for other share/mk consumers. - Switch gdb to use the default standalone debug directory of /usr/lib/debug. Also available at http://people.freebsd.org/~emaste/patches/shlib-debug-symbols.diff. Changes to bsd.prog.mk will come after. --e89a8fb1f7f0a981de04d8dd835d Content-Type: application/octet-stream; name="shlib-debug-symbols.diff" Content-Disposition: attachment; filename="shlib-debug-symbols.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hers8qbh1 ZGlmZiAtLWdpdCBhL2V0Yy9tdHJlZS9CU0QudXNyLmRpc3QgYi9ldGMvbXRyZWUvQlNELnVzci5k aXN0CmluZGV4IDI5OTM4OWYuLjZlMjY2NGMgMTAwNjQ0Ci0tLSBhL2V0Yy9tdHJlZS9CU0QudXNy LmRpc3QKKysrIGIvZXRjL210cmVlL0JTRC51c3IuZGlzdApAQCAtMTgsNiArMTgsMjIgQEAKICAg ICAgICAgICAgIGFvdXQKICAgICAgICAgICAgIC4uCiAgICAgICAgIC4uCisgICAgICAgIGRlYnVn CisgICAgICAgICAgICBib290CisgICAgICAgICAgICAuLgorICAgICAgICAgICAgbGliCisgICAg ICAgICAgICAgICAgZ2VvbQorICAgICAgICAgICAgICAgIC4uCisgICAgICAgICAgICAuLgorICAg ICAgICAgICAgdXNyCisgICAgICAgICAgICAgICAgbGliCisgICAgICAgICAgICAgICAgICAgIGVu Z2luZXMKKyAgICAgICAgICAgICAgICAgICAgLi4KKyAgICAgICAgICAgICAgICAuLgorICAgICAg ICAgICAgICAgIGxpYjMyCisgICAgICAgICAgICAgICAgLi4KKyAgICAgICAgICAgIC4uCisgICAg ICAgIC4uCiAgICAgICAgIGR0cmFjZQogICAgICAgICAuLgogICAgICAgICBlbmdpbmVzCmRpZmYg LS1naXQgYS9nbnUvdXNyLmJpbi9nZGIvTWFrZWZpbGUuaW5jIGIvZ251L3Vzci5iaW4vZ2RiL01h a2VmaWxlLmluYwppbmRleCBjNDBlOWI4Li5hZTBhMWNlIDEwMDY0NAotLS0gYS9nbnUvdXNyLmJp bi9nZGIvTWFrZWZpbGUuaW5jCisrKyBiL2dudS91c3IuYmluL2dkYi9NYWtlZmlsZS5pbmMKQEAg LTM3LDYgKzM3LDcgQEAgR0RCX0NST1NTX0RFQlVHR0VSPQogCSR7Q05UUkJfR0RCfS9nZGIvc2ln bmFscyAke0NOVFJCX0dEQn0vZ2RiL3R1aSAke1RBUkdFVF9TVUJESVJ9CiAKIENGTEFHUys9IC1E SEFWRV9DT05GSUdfSCAtRFJMX05PX0NPTVBBVCAtRE1JX09VVD0xIC1EVFVJPTEKK0NGTEFHUys9 IC1EREVCVUdESVI9XCIvdXNyL2xpYi9kZWJ1Z1wiCiBDRkxBR1MrPSAtSS4KIENGTEFHUys9IC1J JHtUQVJHRVRfU1VCRElSfQogQ0ZMQUdTKz0gLUkke0JNQUtFX0JVfS9saWJiZmQgLUkke0JNQUtF X0JVfS9saWJiZmQvJHtUQVJHRVRfQ1BVQVJDSH0KZGlmZiAtLWdpdCBhL2dudS91c3IuYmluL2dk Yi9hcmNoL2FtZDY0L2NvbmZpZy5oIGIvZ251L3Vzci5iaW4vZ2RiL2FyY2gvYW1kNjQvY29uZmln LmgKaW5kZXggYWM4MWM1NC4uNjc0ZjgxOCAxMDA2NDQKLS0tIGEvZ251L3Vzci5iaW4vZ2RiL2Fy Y2gvYW1kNjQvY29uZmlnLmgKKysrIGIvZ251L3Vzci5iaW4vZ2RiL2FyY2gvYW1kNjQvY29uZmln LmgKQEAgLTQzOSw5ICs0MzksNiBAQAogLyogTmFtZSBvZiB0aGlzIHBhY2thZ2UuICAqLwogI2Rl ZmluZSBQQUNLQUdFICJnZGIiCiAKLS8qIEdsb2JhbCBkaXJlY3RvcnkgZm9yIHNlcGFyYXRlIGRl YnVnIGZpbGVzLiAgKi8KLSNkZWZpbmUgREVCVUdESVIgIi91c3IvbG9jYWwvbGliL2RlYnVnIgot CiAvKiBEZWZpbmUgdG8gQkZEJ3MgZGVmYXVsdCBhcmNoaXRlY3R1cmUuICAqLwogI2RlZmluZSBE RUZBVUxUX0JGRF9BUkNIIGJmZF9pMzg2X2FyY2gKIApkaWZmIC0tZ2l0IGEvZ251L3Vzci5iaW4v Z2RiL2FyY2gvYXJtL2NvbmZpZy5oIGIvZ251L3Vzci5iaW4vZ2RiL2FyY2gvYXJtL2NvbmZpZy5o CmluZGV4IGUxYjEyOGMuLmIyNDgxZjggMTAwNjQ0Ci0tLSBhL2dudS91c3IuYmluL2dkYi9hcmNo L2FybS9jb25maWcuaAorKysgYi9nbnUvdXNyLmJpbi9nZGIvYXJjaC9hcm0vY29uZmlnLmgKQEAg LTQ1MSw5ICs0NTEsNiBAQAogLyogTmFtZSBvZiB0aGlzIHBhY2thZ2UuICAqLwogI2RlZmluZSBQ QUNLQUdFICJnZGIiCiAKLS8qIEdsb2JhbCBkaXJlY3RvcnkgZm9yIHNlcGFyYXRlIGRlYnVnIGZp bGVzLiAgKi8KLSNkZWZpbmUgREVCVUdESVIgIi91c3IvbG9jYWwvbGliL2RlYnVnIgotCiAvKiBE ZWZpbmUgdG8gQkZEJ3MgZGVmYXVsdCBhcmNoaXRlY3R1cmUuICAqLwogI2RlZmluZSBERUZBVUxU X0JGRF9BUkNIIGJmZF9hcm1fYXJjaAogCmRpZmYgLS1naXQgYS9nbnUvdXNyLmJpbi9nZGIvYXJj aC9pMzg2L2NvbmZpZy5oIGIvZ251L3Vzci5iaW4vZ2RiL2FyY2gvaTM4Ni9jb25maWcuaAppbmRl eCBmMjFkYTRjLi5lODQ5ZTBhIDEwMDY0NAotLS0gYS9nbnUvdXNyLmJpbi9nZGIvYXJjaC9pMzg2 L2NvbmZpZy5oCisrKyBiL2dudS91c3IuYmluL2dkYi9hcmNoL2kzODYvY29uZmlnLmgKQEAgLTQz OSw5ICs0MzksNiBAQAogLyogTmFtZSBvZiB0aGlzIHBhY2thZ2UuICAqLwogI2RlZmluZSBQQUNL QUdFICJnZGIiCiAKLS8qIEdsb2JhbCBkaXJlY3RvcnkgZm9yIHNlcGFyYXRlIGRlYnVnIGZpbGVz LiAgKi8KLSNkZWZpbmUgREVCVUdESVIgIi91c3IvbG9jYWwvbGliL2RlYnVnIgotCiAvKiBEZWZp bmUgdG8gQkZEJ3MgZGVmYXVsdCBhcmNoaXRlY3R1cmUuICAqLwogI2RlZmluZSBERUZBVUxUX0JG RF9BUkNIIGJmZF9pMzg2X2FyY2gKIApkaWZmIC0tZ2l0IGEvZ251L3Vzci5iaW4vZ2RiL2FyY2gv aWE2NC9jb25maWcuaCBiL2dudS91c3IuYmluL2dkYi9hcmNoL2lhNjQvY29uZmlnLmgKaW5kZXgg NWZhYTk2Yi4uNGNjMjlmOSAxMDA2NDQKLS0tIGEvZ251L3Vzci5iaW4vZ2RiL2FyY2gvaWE2NC9j b25maWcuaAorKysgYi9nbnUvdXNyLmJpbi9nZGIvYXJjaC9pYTY0L2NvbmZpZy5oCkBAIC00Mzks OSArNDM5LDYgQEAKIC8qIE5hbWUgb2YgdGhpcyBwYWNrYWdlLiAgKi8KICNkZWZpbmUgUEFDS0FH RSAiZ2RiIgogCi0vKiBHbG9iYWwgZGlyZWN0b3J5IGZvciBzZXBhcmF0ZSBkZWJ1ZyBmaWxlcy4g ICovCi0jZGVmaW5lIERFQlVHRElSICIvdXNyL2xvY2FsL2xpYi9kZWJ1ZyIKLQogLyogRGVmaW5l IHRvIEJGRCdzIGRlZmF1bHQgYXJjaGl0ZWN0dXJlLiAgKi8KICNkZWZpbmUgREVGQVVMVF9CRkRf QVJDSCBiZmRfaWE2NF9hcmNoCiAKZGlmZiAtLWdpdCBhL2dudS91c3IuYmluL2dkYi9hcmNoL21p cHMvY29uZmlnLmggYi9nbnUvdXNyLmJpbi9nZGIvYXJjaC9taXBzL2NvbmZpZy5oCmluZGV4IDQx YTY3MzEuLjJiMzc1YTYgMTAwNjQ0Ci0tLSBhL2dudS91c3IuYmluL2dkYi9hcmNoL21pcHMvY29u ZmlnLmgKKysrIGIvZ251L3Vzci5iaW4vZ2RiL2FyY2gvbWlwcy9jb25maWcuaApAQCAtNDM5LDkg KzQzOSw2IEBACiAvKiBOYW1lIG9mIHRoaXMgcGFja2FnZS4gICovCiAjZGVmaW5lIFBBQ0tBR0Ug ImdkYiIKIAotLyogR2xvYmFsIGRpcmVjdG9yeSBmb3Igc2VwYXJhdGUgZGVidWcgZmlsZXMuICAq LwotI2RlZmluZSBERUJVR0RJUiAiL3Vzci9sb2NhbC9saWIvZGVidWciCi0KIC8qIERlZmluZSB0 byBCRkQncyBkZWZhdWx0IGFyY2hpdGVjdHVyZS4gICovCiAjZGVmaW5lIERFRkFVTFRfQkZEX0FS Q0ggYmZkX21pcHNfYXJjaAogCmRpZmYgLS1naXQgYS9nbnUvdXNyLmJpbi9nZGIvYXJjaC9wb3dl cnBjL2NvbmZpZy5oIGIvZ251L3Vzci5iaW4vZ2RiL2FyY2gvcG93ZXJwYy9jb25maWcuaAppbmRl eCBmMTY5ZmFkLi4zNzQxNmE3IDEwMDY0NAotLS0gYS9nbnUvdXNyLmJpbi9nZGIvYXJjaC9wb3dl cnBjL2NvbmZpZy5oCisrKyBiL2dudS91c3IuYmluL2dkYi9hcmNoL3Bvd2VycGMvY29uZmlnLmgK QEAgLTQzOSw5ICs0MzksNiBAQAogLyogTmFtZSBvZiB0aGlzIHBhY2thZ2UuICAqLwogI2RlZmlu ZSBQQUNLQUdFICJnZGIiCiAKLS8qIEdsb2JhbCBkaXJlY3RvcnkgZm9yIHNlcGFyYXRlIGRlYnVn IGZpbGVzLiAgKi8KLSNkZWZpbmUgREVCVUdESVIgIi91c3IvbG9jYWwvbGliL2RlYnVnIgotCiAv KiBEZWZpbmUgdG8gQkZEJ3MgZGVmYXVsdCBhcmNoaXRlY3R1cmUuICAqLwogI2RlZmluZSBERUZB VUxUX0JGRF9BUkNIIGJmZF9yczYwMDBfYXJjaAogCmRpZmYgLS1naXQgYS9nbnUvdXNyLmJpbi9n ZGIvYXJjaC9wb3dlcnBjNjQvY29uZmlnLmggYi9nbnUvdXNyLmJpbi9nZGIvYXJjaC9wb3dlcnBj NjQvY29uZmlnLmgKaW5kZXggZDhiOWI2ZC4uNTg4NDNmYiAxMDA2NDQKLS0tIGEvZ251L3Vzci5i aW4vZ2RiL2FyY2gvcG93ZXJwYzY0L2NvbmZpZy5oCisrKyBiL2dudS91c3IuYmluL2dkYi9hcmNo L3Bvd2VycGM2NC9jb25maWcuaApAQCAtNDM5LDkgKzQzOSw2IEBACiAvKiBOYW1lIG9mIHRoaXMg cGFja2FnZS4gICovCiAjZGVmaW5lIFBBQ0tBR0UgImdkYiIKIAotLyogR2xvYmFsIGRpcmVjdG9y eSBmb3Igc2VwYXJhdGUgZGVidWcgZmlsZXMuICAqLwotI2RlZmluZSBERUJVR0RJUiAiL3Vzci9s b2NhbC9saWIvZGVidWciCi0KIC8qIERlZmluZSB0byBCRkQncyBkZWZhdWx0IGFyY2hpdGVjdHVy ZS4gICovCiAjZGVmaW5lIERFRkFVTFRfQkZEX0FSQ0ggYmZkX3JzNjAwMF9hcmNoCiAKZGlmZiAt LWdpdCBhL2dudS91c3IuYmluL2dkYi9hcmNoL3NwYXJjNjQvY29uZmlnLmggYi9nbnUvdXNyLmJp bi9nZGIvYXJjaC9zcGFyYzY0L2NvbmZpZy5oCmluZGV4IDU1MjdhNzkuLjk3NGU0MjYgMTAwNjQ0 Ci0tLSBhL2dudS91c3IuYmluL2dkYi9hcmNoL3NwYXJjNjQvY29uZmlnLmgKKysrIGIvZ251L3Vz ci5iaW4vZ2RiL2FyY2gvc3BhcmM2NC9jb25maWcuaApAQCAtNDM5LDkgKzQzOSw2IEBACiAvKiBO YW1lIG9mIHRoaXMgcGFja2FnZS4gICovCiAjZGVmaW5lIFBBQ0tBR0UgImdkYiIKIAotLyogR2xv YmFsIGRpcmVjdG9yeSBmb3Igc2VwYXJhdGUgZGVidWcgZmlsZXMuICAqLwotI2RlZmluZSBERUJV R0RJUiAiL3Vzci9sb2NhbC9saWIvZGVidWciCi0KIC8qIERlZmluZSB0byBCRkQncyBkZWZhdWx0 IGFyY2hpdGVjdHVyZS4gICovCiAjZGVmaW5lIERFRkFVTFRfQkZEX0FSQ0ggYmZkX3NwYXJjX2Fy Y2gKIApkaWZmIC0tZ2l0IGEvc2hhcmUvbWsvYnNkLmxpYi5tayBiL3NoYXJlL21rL2JzZC5saWIu bWsKaW5kZXggMzY2NDIxMC4uYmU4OTNjZCAxMDA2NDQKLS0tIGEvc2hhcmUvbWsvYnNkLmxpYi5t aworKysgYi9zaGFyZS9tay9ic2QubGliLm1rCkBAIC00Myw2ICs0MywxMSBAQCBDVEZGTEFHUys9 IC1nCiBTVFJJUD89CS1zCiAuZW5kaWYKIAorLmlmICR7TUtfREVCVUdfRklMRVN9ICE9ICJubyIg JiYgZW1wdHkoREVCVUdfRkxBR1M6TS1nKQorQ0ZMQUdTKz0gLWcKK0NURkZMQUdTKz0gLWcKKy5l bmRpZgorCiAuaW5jbHVkZSA8YnNkLmxpYm5hbWVzLm1rPgogCiAjIHByZWZlciAucyB0byBhIC5j LCBhZGQgLnBvLCByZW1vdmUgc3R1ZmYgbm90IHVzZWQgaW4gdGhlIEJTRCBsaWJyYXJpZXMKQEAg LTExNCw4ICsxMTksMTcgQEAgUE9fRkxBRz0tcGcKIGFsbDogb2Jqd2FybgogCiAuaWYgZGVmaW5l ZChTSExJQl9OQU1FKQotLmlmIGRlZmluZWQoREVCVUdfRkxBR1MpCi1TSExJQl9OQU1FX0ZVTEw9 JHtTSExJQl9OQU1FfS5kZWJ1ZworLmlmICR7TUtfREVCVUdfRklMRVN9ICE9ICJubyIKK1NITElC X05BTUVfRlVMTD0ke1NITElCX05BTUV9LmZ1bGwKKyMgVXNlICR7REVCVUdESVJ9IGZvciBiYXNl IHN5c3RlbSBkZWJ1ZyBmaWxlcywgZWxzZSAuZGVidWcgc3ViZGlyZWN0b3J5CisuaWYgJHtTSExJ QkRJUn0gPT0gIi9ib290IiB8fFwKKyAgICAke1NITElCRElSOkMvXC9saWIoXC8uKik/JC9cL2xp Yi99ID09ICIvbGliIiB8fFwKKyAgICAke1NITElCRElSOkMvXC91c3JcL2xpYigzMik/KFwvLiop Py9cL3VzclwvbGliL30gPT0gIi91c3IvbGliIgorREVCVUdGSUxFRElSPSR7REVCVUdESVJ9JHtT SExJQkRJUn0KKy5lbHNlCitERUJVR0ZJTEVESVI9JHtTSExJQkRJUn0vLmRlYnVnCitERUJVR0ZJ TEVNS0RJUj15ZXMKKy5lbmRpZgogLmVsc2UKIFNITElCX05BTUVfRlVMTD0ke1NITElCX05BTUV9 CiAuZW5kaWYKQEAgLTIwMSwxMiArMjE1LDEyIEBAICR7U0hMSUJfTkFNRV9GVUxMfTogJHtTT0JK U30KIAkke0NURk1FUkdFfSAke0NURkZMQUdTfSAtbyAkey5UQVJHRVR9ICR7U09CSlN9CiAuZW5k aWYKIAotLmlmIGRlZmluZWQoREVCVUdfRkxBR1MpCi0ke1NITElCX05BTUV9OiAke1NITElCX05B TUVfRlVMTH0gJHtTSExJQl9OQU1FfS5zeW1ib2xzCi0JJHtPQkpDT1BZfSAtLXN0cmlwLWRlYnVn IC0tYWRkLWdudS1kZWJ1Z2xpbms9JHtTSExJQl9OQU1FfS5zeW1ib2xzIFwKKy5pZiAke01LX0RF QlVHX0ZJTEVTfSAhPSAibm8iCiske1NITElCX05BTUV9OiAke1NITElCX05BTUVfRlVMTH0gJHtT SExJQl9OQU1FfS5kZWJ1ZworCSR7T0JKQ09QWX0gLS1zdHJpcC1kZWJ1ZyAtLWFkZC1nbnUtZGVi dWdsaW5rPSR7U0hMSUJfTkFNRX0uZGVidWcgXAogCSAgICAke1NITElCX05BTUVfRlVMTH0gJHsu VEFSR0VUfQogCi0ke1NITElCX05BTUV9LnN5bWJvbHM6ICR7U0hMSUJfTkFNRV9GVUxMfQorJHtT SExJQl9OQU1FfS5kZWJ1ZzogJHtTSExJQl9OQU1FX0ZVTEx9CiAJJHtPQkpDT1BZfSAtLW9ubHkt a2VlcC1kZWJ1ZyAke1NITElCX05BTUVfRlVMTH0gJHsuVEFSR0VUfQogLmVuZGlmCiAuZW5kaWYK QEAgLTI4NSwxMCArMjk5LDEzIEBAIF9saWJpbnN0YWxsOgogCSR7SU5TVEFMTH0gJHtTVFJJUH0g LW8gJHtMSUJPV059IC1nICR7TElCR1JQfSAtbSAke0xJQk1PREV9IFwKIAkgICAgJHtfSU5TVEFM TEZMQUdTfSAke19TSExJTlNUQUxMRkxBR1N9IFwKIAkgICAgJHtTSExJQl9OQU1FfSAke0RFU1RE SVJ9JHtTSExJQkRJUn0KLS5pZiBkZWZpbmVkKERFQlVHX0ZMQUdTKQorLmlmICR7TUtfREVCVUdf RklMRVN9ICE9ICJubyIKKy5pZiAke0RFQlVHRklMRU1LRElSfSA9PSAieWVzIgorCW1rZGlyIC1w ICR7REVTVERJUn0ke0RFQlVHRklMRURJUn0KKy5lbmRpZgogCSR7SU5TVEFMTH0gLW8gJHtMSUJP V059IC1nICR7TElCR1JQfSAtbSAke0xJQk1PREV9IFwKIAkgICAgJHtfSU5TVEFMTEZMQUdTfSBc Ci0JICAgICR7U0hMSUJfTkFNRX0uc3ltYm9scyAke0RFU1RESVJ9JHtTSExJQkRJUn0KKwkgICAg JHtTSExJQl9OQU1FfS5kZWJ1ZyAke0RFU1RESVJ9JHtERUJVR0ZJTEVESVJ9CiAuZW5kaWYKIC5p ZiBkZWZpbmVkKFNITElCX0xJTkspCiAjICR7X1NITElCRElSUFJFRklYfSBhbmQgJHtfTERTQ1JJ UFRST09UfSBhcmUgYm90aCBuZWVkZWQgd2hlbiBjcm9zcy1idWlsZGluZwpkaWZmIC0tZ2l0IGEv c2hhcmUvbWsvYnNkLm93bi5tayBiL3NoYXJlL21rL2JzZC5vd24ubWsKaW5kZXggZjFhMTVkNi4u NmExNGI4YSAxMDA2NDQKLS0tIGEvc2hhcmUvbWsvYnNkLm93bi5taworKysgYi9zaGFyZS9tay9i c2Qub3duLm1rCkBAIC00Myw2ICs0Myw5IEBACiAjIExJQk1PREUJTGlicmFyeSBtb2RlLiBbJHtO T0JJTk1PREV9XQogIwogIworIyBERUJVR0RJUglCYXNlIHBhdGggZm9yIHN0YW5kYWxvbmUgZGVi dWcgZmlsZXMuIFsvdXNyL2xpYi9kZWJ1Z10KKyMKKyMKICMgS01PRERJUglCYXNlIHBhdGggZm9y IGxvYWRhYmxlIGtlcm5lbCBtb2R1bGVzCiAjCQkoc2VlIGtsZCg0KSkuIFsvYm9vdC9rZXJuZWxd CiAjCkBAIC0xNDcsNiArMTUwLDggQEAgTElCT1dOPz0JJHtCSU5PV059CiBMSUJHUlA/PQkke0JJ TkdSUH0KIExJQk1PREU/PQkke05PQklOTU9ERX0KIAorREVCVUdESVI/PQkvdXNyL2xpYi9kZWJ1 ZworCiAKICMgU2hhcmUgZmlsZXMKIFNIQVJFRElSPz0JL3Vzci9zaGFyZQpAQCAtMzY2LDYgKzM3 MSw3IEBAIF9fREVGQVVMVF9OT19PUFRJT05TID0gXAogICAgIEJTRF9HUkVQIFwKICAgICBDTEFO R19FWFRSQVMgXAogICAgIENURiBcCisgICAgREVCVUdfRklMRVMgXAogICAgIEdQTF9EVEMgXAog ICAgIEhFU0lPRCBcCiAgICAgSUNPTlYgXApkaWZmIC0tZ2l0IGEvdG9vbHMvYnVpbGQvb3B0aW9u cy9XSVRIX0RFQlVHX0ZJTEVTIGIvdG9vbHMvYnVpbGQvb3B0aW9ucy9XSVRIX0RFQlVHX0ZJTEVT Cm5ldyBmaWxlIG1vZGUgMTAwNjQ0CmluZGV4IDAwMDAwMDAuLmE2NDFjNmYKLS0tIC9kZXYvbnVs bAorKysgYi90b29scy9idWlsZC9vcHRpb25zL1dJVEhfREVCVUdfRklMRVMKQEAgLTAsMCArMSw2 IEBACisuXCIgJEZyZWVCU0QkCitTZXQgdG8gc3RyaXAgZGVidWcgaW5mbyBpbnRvIGEgc2VwYXJh dGUgZmlsZSBmb3IgZWFjaCBzaGFyZWQgbGlicmFyeS4KK1RoZSBkZWJ1ZyBmaWxlcyB3aWxsIGJl IHBsYWNlZCBpbiBhIHN1YmRpcmVjdG9yeSBvZgorLlBhIC91c3IvbGliL2RlYnVnCithbmQgYXJl IGxvY2F0ZWQgYXV0b21hdGljYWxseSBieQorLlhyIGdkYiAxIC4K --e89a8fb1f7f0a981de04d8dd835d-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 28 08:37:08 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B26DE15A; Thu, 28 Mar 2013 08:37:08 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id C387F706; Thu, 28 Mar 2013 08:37:07 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA04091; Thu, 28 Mar 2013 10:36:59 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1UL8KR-000DVf-H1; Thu, 28 Mar 2013 10:36:59 +0200 Message-ID: <5154012A.4010602@FreeBSD.org> Date: Thu, 28 Mar 2013 10:36:58 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: FreeBSD Current , freebsd-hackers@FreeBSD.org Subject: big change to devfs rules path matching References: <5150B598.7050700@FreeBSD.org> <5150B71B.6060106@FreeBSD.org> In-Reply-To: <5150B71B.6060106@FreeBSD.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=x-viet-vps Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 08:37:08 -0000 on 25/03/2013 22:44 Andriy Gapon said the following: > > Would like to ask for opinions on this topic... > Please read this PR for context: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 > Especially Jaakko's insightful description of the problem. So I would like to commit the following patch sooner rather than later: http://people.freebsd.org/~avg/devfs_rule.diff The only difference from the Jaakko's patch in the PR is FNM_PATHNAME. Please review and test. Especially if you rely on any non-trivial devfs rules. Thank you. -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 28 10:51:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 814D5B14; Thu, 28 Mar 2013 10:51:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id CEAC2D6D; Thu, 28 Mar 2013 10:51:38 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2SApY8J036055; Thu, 28 Mar 2013 12:51:34 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2SApY8J036055 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2SApYob036054; Thu, 28 Mar 2013 12:51:34 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 28 Mar 2013 12:51:34 +0200 From: Konstantin Belousov To: Mikolaj Golub Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130328105134.GO3794@kib.kiev.ua> References: <201301251531.43540.jhb@freebsd.org> <20130212215054.GA9839@gmail.com> <201302200904.15324.jhb@freebsd.org> <20130220195801.GA8679@gmail.com> <20130316180915.GA91146@gmail.com> <20130316191605.GJ3794@kib.kiev.ua> <20130316223339.GA3534@gmail.com> <20130317063033.GL3794@kib.kiev.ua> <20130317091930.GA2833@gmail.com> <20130324155426.GA87022@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kDCrHF7AtgO4AaDI" Content-Disposition: inline In-Reply-To: <20130324155426.GA87022@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Stanislav Sedov , Attilio Rao , "Robert N. M. Watson" , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 10:51:39 -0000 --kDCrHF7AtgO4AaDI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 24, 2013 at 05:54:28PM +0200, Mikolaj Golub wrote: > Here is an updated patch set, which I think includes all kib's > suggestions. It also introduces procstat groups, umask, rlimit, and > osrel notes. >=20 > http://people.freebsd.org/~trociny/procstat_core.3.patch >=20 > Sbuf section interface looks like below: >=20 > /* start a section */ > sbuf_start_section(sb, NULL); > /* write something to sbuf */ > ... > /* start a subsection (need to save the current section length) */ > sbuf_start_section(sb, &old_len); > /* write something to sbuf */ > ... > /* end a subsection padding to 4 bytes with '\0' bytes=20 > (need to provide the previously saved section length) */ > sbuf_end_section(sb, old_len, 4, 0); > ... > /* aling the whole section to page size */ > sbuf_end_section(sb, -1, PAGE_SIZE, 0); This looks fine. >=20 > Open issues/questions: >=20 > 1) I would also like to make libprocstat(3) extract environment, args, > and auxv from the core. It looks like I don't need to store envv and > argv in notes, as it is already present in the core. But I think I > need to know psstrings to find them. >=20 > Would it be ok, if I add auxv and psstrings notes, and extract envv > and agrv from a program section in the core? Yes, I agree that not doing this in kernel at the time of the core dump is preferred. As usual, both args/env and aux vector could be overriden by the userspace, so its reading is only best-efforts operation. >=20 > 2) I started NT_PROCSTAT constants from the first not used number in > elf_common.h, i.e. 8. But in this case they conflict with those > available on other systems: >=20 > contrib/binutils/include/elf/common.h: >=20 > #define NT_PSTATUS 10 /* Has a struct pstatus */ > #define NT_FPREGS 12 /* Has a struct fpregset */ > #define NT_PSINFO 13 /* Has a struct psinfo */ > #define NT_LWPSTATUS 16 /* Has a struct lwpstatus_t */ > #define NT_LWPSINFO 17 /* Has a struct lwpsinfo_t */ > #define NT_WIN32PSTATUS 18 /* Has a struct win32_pstatus */ >=20 > Although note name =3D "FreeBSD" should have disambiguated this, readelf > looks like ignores this and its output for my core on i386 looks > confusing: >=20 > Owner Data size Description > FreeBSD 0x0000006c NT_PRPSINFO (prpsinfo structure) > FreeBSD 0x00000068 NT_PRSTATUS (prstatus structure) > FreeBSD 0x000000b0 NT_FPREGSET (floating point regis= ters) > FreeBSD 0x00000018 NT_THRMISC (thrmisc structure) > FreeBSD 0x00000304 Unknown note type: (0x00000008) > FreeBSD 0x00000a6c Unknown note type: (0x00000009) > FreeBSD 0x000008d4 NT_PSTATUS (pstatus structure) > FreeBSD 0x0000000c Unknown note type: (0x0000000b) > FreeBSD 0x00000006 NT_FPREGS (floating point registe= rs) > FreeBSD 0x000000d4 NT_PSINFO (psinfo structure) > FreeBSD 0x00000008 Unknown note type: (0x0000000e) >=20 > Should I use some other range for NT_PROCSTAT notes? I think the only possible solution is to post on the binutils list and fix the readelf ignore of the note vendor. >=20 > 3) Following our current code I align notes to sizeof(Elf_Size), which > is 4 on i386 and 8 on amd64. >=20 > But I have an issue reading the notes by readelf on amd64, which alway > uses 4 byte alignment: >=20 > contrib/binutils/binutils/readelf.c: >=20 > next =3D (Elf_External_Note *)(inote.descdata + align_power (inote.= descsz, 2)); >=20 > where >=20 > #define align_power(addr, align) \ > (((addr) + ((bfd_vma) 1 << (align)) - 1) & ((bfd_vma) -1 << (align))) >=20 > Should I change alignment to 4 bytes? In the generic Elf 64bit draft specification I have, the notes sections are specified to consists of entries, each of which is an array of 8-byte words. I think we are right using the 8-byte alignment. >=20 > 4) In libprocstat I added new functions and placed them under already > existent FBSD_1.3 version section in Symbol.map. >=20 > Shouldn't I bump the version? Won't I need any additional care if I > want to MFC the code to stable/9 and may be 8? Version of what ? MFC does not require any additional actions, FBSD_1.3 is the valid version namespace in 9 and 8. --kDCrHF7AtgO4AaDI Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRVCC1AAoJEJDCuSvBvK1BRTEP/2xe3QXaEVtZnhl1ONnfZSzU DZomEhZkMHxR+BIMQ+jCchCXFl8bbzXDcYPv6qOu/zoy17iiqHu231PB9dmqBUgG V4vcHPXh2VN6k7AWff5JT8pGUiXrIPB905gzetjk+vXt+1hJ5zY8M0c6TxcnEaOG XXCMp88F1+yrXRZ50GjyMUSmqZLDAlUduuk6EAEEam1mLqegKsKVqAXY1IvepG5e 42/9eJ1x2Om1dzNfSOA4dwjpNcqeFsYrQZ6rwCZUlvXSyCZTf8XTSc+5jY8AX/vW rTqI9/ydoEfU2NIsp/LmN/tEC16mbLUUSfXQUuei8IkUbdiydXN2qQ0PptccKC58 xX1JlREyHTfQ1knXbpxHqI20HCKYo6jzlsxe76+E7e4Ch6Y8Cwaj3p/VfsE09Ils ECO2JrpUhovM9U1R+CUakNS7A8VUyXLBR5QQBZQrwaEnQkXI/gg8CXWvcQX2Bhx0 MkkzTRxGg382FUtESbqCYY9HLfyBQpWfhhGCQQAz1ahJIM1llsSMhLBcYcvgZ7IG ey3at9xtW4tafA659jDWSdxkOP4jmKEQdcy1/tV1m1DeiSBNEv/KRug9k6kmDpMx kJIwnOlqvzeAvF6bYZ7SmC/mPnr42YDSQf5EPgRz90IF6sArSRghujJpDH5rSaVW QZA518XsK2A0pRlpLJCS =29ax -----END PGP SIGNATURE----- --kDCrHF7AtgO4AaDI-- From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 28 16:54:34 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 65F9247C; Thu, 28 Mar 2013 16:54:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 10C8F5FC; Thu, 28 Mar 2013 16:54:32 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id SAA10475; Thu, 28 Mar 2013 18:54:31 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <515475C7.6010404@FreeBSD.org> Date: Thu, 28 Mar 2013 18:54:31 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130313 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, FreeBSD Hackers Subject: close(2) while accept(2) is blocked X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 16:54:34 -0000 So, this started as a simple question, but the answer was quite unexpected to me. Let's say we have an opened and listen-ed socket and let's assume that we know that one thread is blocked in accept(2) and another thread is calling close(2). What is going to happen? Turns out that practically nothing. For kernel the close call would be almost a nop. My understanding is this: - when socket is created, its reference count is 1 - when accept(2) is called, fget in kernel increments the reference count (kept in an associated struct file) - when close(2) is called, the reference count is decremented The reference count is still greater than zero, so fdrop does not call fo_close. That means that in the case of a socket soclose is not called. I am sure that the reference counting in this case is absolutely correct with respect to managing kernel side structures. But I am not that it is correct with respect to hiding the explicit close(2) call from other threads that may be waiting on the socket. In other words, I am not sure if fo_close is supposed to signify that there are no uses of a file, or that userland close-d the file. Or perhaps these should be two different methods. Additional note is that shutdown(2) doesn't wake up the thread in accept(2) either. At least that's true for unix domain sockets. Not sure if this is a bug. But the summary seems to be is that currently it is not possible to break a thread out of accept(2) (at least without resorting to signals). -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 28 17:25:09 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 300A9626 for ; Thu, 28 Mar 2013 17:25:09 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 088C27C7 for ; Thu, 28 Mar 2013 17:25:08 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id c11so12132061ieb.29 for ; Thu, 28 Mar 2013 10:25:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=H8gyh8Xdns/cU9N1gIKP6Pbuu3JQUT4nGbMRaFlOCCc=; b=nOQ296KatKURiHQggQEqTv7eiVhAlBkZRXFhbE1klGp/N+qlqYQt6Dq4AXl6H1hbZ5 wMvNnWYYSXrdG+jrEI+wBRUSWxeg73DMwsfJ2EMfIdxpwJr9t7VEG8WVSWrVMgTcZibF xlZhAbILzU47peaksvxxdRHrp1yyaL8Uo6SltyMSBG7DbB19GTa+LpwLB26o13JFUWQc s1ZCz0G8vUkz/zic3ckPJ4QGNmpl/4KfdhA8L3wK7O+HdotPzq+BZ457NBA4PBEKBumk H1b7myvWxJXbQSp5rb4zAbKLd9/w0Yr/KAEfGvipCyb2JgxgZvDVHIrgZ3m5PXS0PLFT hKbg== MIME-Version: 1.0 X-Received: by 10.50.47.170 with SMTP id e10mr7780823ign.84.1364491508472; Thu, 28 Mar 2013 10:25:08 -0700 (PDT) Received: by 10.231.103.70 with HTTP; Thu, 28 Mar 2013 10:25:08 -0700 (PDT) Date: Thu, 28 Mar 2013 11:25:08 -0600 Message-ID: Subject: CFR: FireWire: Don't allow a tlabel to reference an xfer after free From: Will Andrews To: hackers@freebsd.org X-Gm-Message-State: ALoCoQkssnkv8FwX9LUcrEjGQPWv6SbinDkiDowYf5LPqrqCngAYDJzH9ZrsFJDqO43X12/Y/CPJ X-Mailman-Approved-At: Thu, 28 Mar 2013 17:30:39 +0000 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Alexander Kabaev X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:25:09 -0000 Diff: http://people.freebsd.org/~will/patches/fix-fwmem-use-after-free.diff >From the commit log: FireWire: Don't allow a tlabel to reference an xfer after free. sys/dev/firewire/firewire.c: - fw_xfer_unload(): Since we are about to free this xfer, call fw_tl_free() to remove the xfer from its tlabel's list, if it has a tlabel. - In every occasion when a xfer is removed from a tlabel's list, reset xfer->tl to -1 while holding fc->tlabel_lock, so that the xfer isn't mis-identified as belonging to a tlabel. Thanks, --Will. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 28 17:36:11 2013 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A8014B20 for ; Thu, 28 Mar 2013 17:36:11 +0000 (UTC) (envelope-from will@firepipe.net) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 78996859 for ; Thu, 28 Mar 2013 17:36:11 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id bn7so9352089ieb.23 for ; Thu, 28 Mar 2013 10:36:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type:x-gm-message-state; bh=THTPRorVbnBlaHZY5rPoW0pwWEXkB4NETOXYxEfGBtM=; b=hj0rR2Vyu7weKp/ltuYA25ybAXX/wzjvQbBZz2s+J1ToZQLRoYOJaY5gChk97Pmsgf 20ok5aKS3pU62hg1NW9y2heRpOA3qjct/VuQmKgmk6petNQOd8ws2HyXdAGZfqSfG1h/ 2mDl/lRQ8QDByNR8LNbBW5O00r3aDL8bj0bGmFdzFyNH9X4EzAE0ACfdK5Bvvfez2MoV 20IhtvlTV3aEG1SDQWldZlgDZ3l9EcuV+m1u4cVPLHmhEAnIISLAigi+AMrKU5vb1cSh T2r/sKwyqzcS5ZVpipG5rJQdcB/IZzFDOK73bX7LSKf30ElPXraDz2KiqJPsjjzK6oUf 97rA== MIME-Version: 1.0 X-Received: by 10.50.30.69 with SMTP id q5mr8221226igh.1.1364492171171; Thu, 28 Mar 2013 10:36:11 -0700 (PDT) Received: by 10.231.103.70 with HTTP; Thu, 28 Mar 2013 10:36:10 -0700 (PDT) Date: Thu, 28 Mar 2013 11:36:10 -0600 Message-ID: Subject: CFR: Fix a panic in userspace dtrace From: Will Andrews To: hackers@freebsd.org X-Gm-Message-State: ALoCoQm7namMvYsTCNDu0253Os4l3V5PTvitGV5PLRN1iSCXq5dJ2qyZq2d2NjefmFMsqr9AMbF0 Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: George Neville-Neil , "Justin T. Gibbs" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 17:36:11 -0000 Diff: http://people.freebsd.org/~will/patches/fix-fasttrap-panic.diff Commit log: Fix a panic in userspace dtrace. The bug here is that the proc lock is already held in the case of fasttrap_fork(), which then calls proc_ops(), which tries to hold it again. Upon inspection, every other consumer of proc_ops() has already placed a hold and then dropped the proc lock. Change fasttrap_fork() to match these semantics, which also happen to mirror Solaris. Change proc_ops() to assert that the proc object is held and unlocked, rather than executing a hold/rele cycle itself. Note: fasttrap_fork() is only ever called if an userspace program being dtrace'd happens to fork(). So this bug doesn't apply if you are dtrace'ing a userspace process that doesn't fork. Also, at least for ztest, userspace dtrace is still unusable because when the child process exits, both dtrace and ztest appear to spin forever. The dtrace process doesn't appear to do anything; the ztest process can't be attached via gdb since it's already being ptrace()'d by dtrace. This will require more investigation to fix. The commit log is a bit dated; I believe that more recent changes by gibbs@fixed the latter issues. Thanks, --Will. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 28 21:18:28 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9D255BBE; Thu, 28 Mar 2013 21:18:28 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx1.freebsd.org (Postfix) with ESMTP id 8202933C; Thu, 28 Mar 2013 21:18:27 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id d17so1533285eek.11 for ; Thu, 28 Mar 2013 14:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=984artyxhfQm7yYAfwXYIJqaxzIT1NO9oyT8TZ4uPyg=; b=QAaWU3tCKNVJ8bBFACAQMeyTW0HI39VVNh0w4RzNj8QB9QexB1F/9MItNjukTx6/cP 1GRN96ZmHZLqXoqNDAkcCeZt/A8mRKT2ppvspHaev8UeS3aJGSEviC9PDL0qIq2EsSYT 8h9PHKEQQIwZ+tCR/A/C+SKYeG6aZ69onBYun/snuXtFTB2INV6/KBoMFM/uzJfH52Vs l/FNaBbTu4wqBW2J/JlyzmZ5JUSFciKpuAU9nHIX1WiXnVlwUHwayoiVSd35TqK5kLHX rTZOIPfQ94u39rJLFn+iM+wCRuFJQugFs0IpfO278c1UmsIJuKEBJ/idUTVYyPv7Lz1d gX3Q== X-Received: by 10.14.0.73 with SMTP id 49mr407426eea.21.1364505506209; Thu, 28 Mar 2013 14:18:26 -0700 (PDT) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPS id s3sm388518eem.4.2013.03.28.14.18.24 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 28 Mar 2013 14:18:25 -0700 (PDT) Sender: Mikolaj Golub Date: Thu, 28 Mar 2013 23:18:21 +0200 From: Mikolaj Golub To: Konstantin Belousov Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130328211820.GA6657@gmail.com> References: <20130212215054.GA9839@gmail.com> <201302200904.15324.jhb@freebsd.org> <20130220195801.GA8679@gmail.com> <20130316180915.GA91146@gmail.com> <20130316191605.GJ3794@kib.kiev.ua> <20130316223339.GA3534@gmail.com> <20130317063033.GL3794@kib.kiev.ua> <20130317091930.GA2833@gmail.com> <20130324155426.GA87022@gmail.com> <20130328105134.GO3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130328105134.GO3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov , Attilio Rao , "Robert N. M. Watson" , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 21:18:28 -0000 On Thu, Mar 28, 2013 at 12:51:34PM +0200, Konstantin Belousov wrote: > In the generic Elf 64bit draft specification I have, the notes sections > are specified to consists of entries, each of which is an array of 8-byte > words. I think we are right using the 8-byte alignment. I have impression many implementations use 4-byte alignment. E.g. in NetBSD: sys/kern/core_elf32.c: #define ELFROUNDSIZE 4 /* XXX Should it be sizeof(Elf_Word)? */ #define elfround(x) roundup((x), ELFROUNDSIZE) Also, we have inconsistency with imgactl_elf.c/parse_notes(), which uses 4-byte alignment: note = (const Elf_Note *)((const char *)(note + 1) + roundup2(note->n_namesz, sizeof(Elf32_Addr)) + roundup2(note->n_descsz, sizeof(Elf32_Addr))); I suppose there were no issues before, because accidentally the sizes of all notes we had were 8 bytes aligned. Now, when I add new notes it will break things. I don't have strong opinion, it will be ok for me to leave 8-byte alignment and fix issues, just want to have strong support here :-) BTW, looking at NetBSD code I see they set p_align in the note segement to ELFROUNDSIZE: /* Write out the PT_NOTE header. */ ws.psections->p_type = PT_NOTE; ws.psections->p_offset = notestart; ws.psections->p_vaddr = 0; ws.psections->p_paddr = 0; ws.psections->p_filesz = notesize; ws.psections->p_memsz = 0; ws.psections->p_flags = PF_R; ws.psections->p_align = ELFROUNDSIZE; while we set to 0: /* The note segement. */ phdr->p_type = PT_NOTE; phdr->p_offset = hdrsize; phdr->p_vaddr = 0; phdr->p_paddr = 0; phdr->p_filesz = notesz; phdr->p_memsz = 0; phdr->p_flags = 0; phdr->p_align = 0; Shouldn't we set it to alignment size too? Note also, they set "Segment is readable" flag. > > > > 4) In libprocstat I added new functions and placed them under already > > existent FBSD_1.3 version section in Symbol.map. > > > > Shouldn't I bump the version? Won't I need any additional care if I > > want to MFC the code to stable/9 and may be 8? > Version of what ? MFC does not require any additional actions, FBSD_1.3 > is the valid version namespace in 9 and 8. Ok. Now I see it was rather silly question :-). Thanks. For this and your other notes. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 28 21:29:57 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2FC2A1B5 for ; Thu, 28 Mar 2013 21:29:57 +0000 (UTC) (envelope-from wayne@manor.msen.com) Received: from manor.msen.com (manor.msen.com [148.59.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id E963D3EA for ; Thu, 28 Mar 2013 21:29:56 +0000 (UTC) Received: from manor.msen.com (localhost [127.0.0.1]) by manor.msen.com (8.12.11/8.12.11) with ESMTP id r2SLTt5v050665 for ; Thu, 28 Mar 2013 16:29:56 -0500 (EST) (envelope-from wayne@manor.msen.com) Received: (from wayne@localhost) by manor.msen.com (8.12.11/8.12.11/Submit) id r2SLTtlV050664 for freebsd-hackers@freebsd.org; Thu, 28 Mar 2013 16:29:55 -0500 (EST) (envelope-from wayne) Date: Thu, 28 Mar 2013 16:29:55 -0500 From: Michael Wayne To: freebsd-hackers@freebsd.org Subject: Seeking an extended-support O/S similar to FreeBSD Message-ID: <20130328212955.GJ42080@manor.msen.com> Mail-Followup-To: freebsd-hackers@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 21:29:57 -0000 I'm NOT trying to start a flame war here. I'm trying to find a viable solution to a very frustrating, real problem. It's clear that FreeBSD has absolutely no interest in maintaining an extended maintainence release version of the O/S. The high resource commitment required to keep up with the current incessant FreeBSD release process is beyond quite a number of people. I'm at the point of admitting that FreeBSD is simply too much work for us to continue to use. So, I'm wondering if anyone reading the list is aware of a viable alternative. I'm seeking a BSD-based O/S that is designed to be installed in a server environment and not ever get any feature upgrades or require any noticable additional resources, only security fixes for the O/S and ports. While this concept is clearly in total opposition to the philosophy of the FreeBSD team, I'm hoping that some other, smaller project might exist to fill this need. Any suggestions? From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 28 21:45:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EC46146E for ; Thu, 28 Mar 2013 21:45:16 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by mx1.freebsd.org (Postfix) with ESMTP id 89D54666 for ; Thu, 28 Mar 2013 21:45:16 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id hm14so3674541wib.4 for ; Thu, 28 Mar 2013 14:45:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=MPI/Db+NdYCYHKYnEcjU9c2G+Axfcrku77ExpxMgS5U=; b=HsGIRbTzQwuZW3r6MsX5pu4U/QJb+2/T5A7VI3P3xX3TegF+sHpfOMQ+uUePRx7Wtq hS4/FkITni8VtQD1NmBlQeK24ojpZ8ukfxd5ISe2Soqgdh06rZdBBxNFSMeBBYP/Ze7o yMqLKAppqvpklhR/6UOWv0qLhJdWhA79zVQdiE6DKGSPYLOQKjLj4PJ3tNFEonP91uwF 53vVfsyndGUDAUOY3iXYLsmHC7jzwBVOC/zPLlDKb+DZwmKVZBWCTkQ9UrGh30Ij7I1J URrFNSKpL4j4Fga2xnFlT76qd6U1+MeLLsQJUa3aArY4WkmWKvr9Ox/0dWpqDlqHHU9X ts4g== MIME-Version: 1.0 X-Received: by 10.194.22.5 with SMTP id z5mr354681wje.5.1364507115752; Thu, 28 Mar 2013 14:45:15 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Thu, 28 Mar 2013 14:45:15 -0700 (PDT) In-Reply-To: <20130328212955.GJ42080@manor.msen.com> References: <20130328212955.GJ42080@manor.msen.com> Date: Thu, 28 Mar 2013 14:45:15 -0700 X-Google-Sender-Auth: my5nIKzSqOu7geqJP5KugdhvkOQ Message-ID: Subject: Re: Seeking an extended-support O/S similar to FreeBSD From: Adrian Chadd To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 21:45:17 -0000 On 28 March 2013 14:29, Michael Wayne wrote: > I'm NOT trying to start a flame war here. I'm trying to find a > viable solution to a very frustrating, real problem. > > It's clear that FreeBSD has absolutely no interest in maintaining > an extended maintainence release version of the O/S. The high > resource commitment required to keep up with the current incessant > FreeBSD release process is beyond quite a number of people. I'm at > the point of admitting that FreeBSD is simply too much work for us > to continue to use. Well, the open source project as a whole doesn't have the resources to do this. I think the general consensus is "it'd be nice if a commercial company came up and do this." > So, I'm wondering if anyone reading the list is aware of a viable > alternative. I'm seeking a BSD-based O/S that is designed to be > installed in a server environment and not ever get any feature > upgrades or require any noticable additional resources, only security > fixes for the O/S and ports. I suggest asking ixSystems and looking at PC-BSD. There have been mumblings about a commerically supported PC-BSD distribution. Which is FreeBSD plus their testing and management and install stuff, along with what I hope is some commercial support if you need it. > While this concept is clearly in total opposition to the philosophy > of the FreeBSD team, I'm hoping that some other, smaller project > might exist to fill this need. It's actually in line with our philosophy. If people are willing to pay for it, then grab a company to do it. :) Adrian From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 28 23:10:58 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BB069981 for ; Thu, 28 Mar 2013 23:10:58 +0000 (UTC) (envelope-from kline@thought.org) Received: from p3plsmtpa08-01.prod.phx3.secureserver.net (p3plsmtpa08-01.prod.phx3.secureserver.net [173.201.193.102]) by mx1.freebsd.org (Postfix) with ESMTP id 9F8259C6 for ; Thu, 28 Mar 2013 23:10:58 +0000 (UTC) Received: from ethic.thought.org ([209.180.213.209]) by p3plsmtpa08-01.prod.phx3.secureserver.net with id HBAr1l00c4XeM0101BAsWB; Thu, 28 Mar 2013 16:10:52 -0700 Date: Thu, 28 Mar 2013 16:10:43 -0700 From: Gary Kline To: freebsd-hackers@freebsd.org Subject: Re: Seeking an extended-support O/S similar to FreeBSD Message-ID: <20130328231043.GA3666@ethic.thought.org> References: <20130328212955.GJ42080@manor.msen.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130328212955.GJ42080@manor.msen.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 23:10:58 -0000 On Thu, Mar 28, 2013 at 04:29:55PM -0500, Michael Wayne wrote: > I'm NOT trying to start a flame war here. I'm trying to find a > viable solution to a very frustrating, real problem. > > It's clear that FreeBSD has absolutely no interest in maintaining > an extended maintainence release version of the O/S. The high > resource commitment required to keep up with the current incessant > FreeBSD release process is beyond quite a number of people. I'm at > the point of admitting that FreeBSD is simply too much work for us > to continue to use. > > So, I'm wondering if anyone reading the list is aware of a viable > alternative. I'm seeking a BSD-based O/S that is designed to be > installed in a server environment and not ever get any feature > upgrades or require any noticable additional resources, only security > fixes for the O/S and ports. > > While this concept is clearly in total opposition to the philosophy > of the FreeBSD team, I'm hoping that some other, smaller project > might exist to fill this need. > > Any suggestions? Many, many [many] years ago I was in favor of a linux+bsd system. AFAIK, it had some support. you might scout it out. over a year ago I gave up my FBSD server which ran 7.3 and had my own DNS and web and mail server side. I tried to upgrade but there were too many ports that refused to build. nutshell, someone in the dallas-ft. worth area became my volunteer system admin. he used centOS-6.3 and fedora-17. the fedora-17 desktop kept crashing for hardware faults so I finally bought a refurb h.p. just off lease, put on ubuntu 12.04 LTS. The next version, 13.04 will be out in a few weeks. I now use godaddy.com. they do my DNS. I use mutt as my mailer. I've got fetchmail working "reasonably well" [smirk !] my web server is on the Centos 6.3. mail goes to godaddy... and when ubuntu's 13.04 long term support is here, I won't have to fmess with my desktop for THREE years! dunno anything about centos. I =do= know that while the Berkeley distros are the BEST, [in my biased opinion], linux is good-enough {tm} > 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" -- Gary Kline kline@thought.org http://www.thought.org Public Service Unix Twenty-six years of service to the Unix community. From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 28 23:47:56 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 792D02AF; Thu, 28 Mar 2013 23:47:56 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (relay02.stack.nl [IPv6:2001:610:1108:5010::104]) by mx1.freebsd.org (Postfix) with ESMTP id 0B550B1F; Thu, 28 Mar 2013 23:47:56 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 751A135930F; Fri, 29 Mar 2013 00:47:53 +0100 (CET) Received: by snail.stack.nl (Postfix, from userid 1677) id 5C2752848C; Fri, 29 Mar 2013 00:47:53 +0100 (CET) Date: Fri, 29 Mar 2013 00:47:53 +0100 From: Jilles Tjoelker To: Andriy Gapon Subject: Re: close(2) while accept(2) is blocked Message-ID: <20130328234753.GA88844@stack.nl> References: <515475C7.6010404@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <515475C7.6010404@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 23:47:56 -0000 On Thu, Mar 28, 2013 at 06:54:31PM +0200, Andriy Gapon wrote: > So, this started as a simple question, but the answer was quite > unexpected to me. > Let's say we have an opened and listen-ed socket and let's assume that > we know that one thread is blocked in accept(2) and another thread is > calling close(2). What is going to happen? > Turns out that practically nothing. For kernel the close call would > be almost a nop. > My understanding is this: > - when socket is created, its reference count is 1 > - when accept(2) is called, fget in kernel increments the reference > count (kept in an associated struct file) > - when close(2) is called, the reference count is decremented > The reference count is still greater than zero, so fdrop does not call > fo_close. That means that in the case of a socket soclose is not > called. > I am sure that the reference counting in this case is absolutely > correct with respect to managing kernel side structures. I agree this is expected and correct from the kernel point of view. > But I am not that it is correct with respect to hiding the explicit > close(2) call from other threads that may be waiting on the socket. In > other words, I am not sure if fo_close is supposed to signify that > there are no uses of a file, or that userland close-d the file. Or > perhaps these should be two different methods. It would be possible to keep track of the file descriptor number but I think it is not worth the large amount of extra code. Keeping track of file descriptor number would be necessary to interrupt waits after a close or dup2 on the file descriptor that was passed to the blocking call, even if the object remains open on a different file descriptor number or in a different process. Also, most people would use the new functionality incorrectly anyway. A close() on a file descriptor another thread is using is risky since it is in most cases impossible to prove that the other thread is in fact blocked on the file descriptor and not preempted right before making the system call. In the latter case, the other thread might accept a connection from a different socket created later. A dup2() of /dev/null onto the file descriptor would be safer. > Additional note is that shutdown(2) doesn't wake up the thread in > accept(2) either. At least that's true for unix domain sockets. > Not sure if this is a bug. I think it is a bug. It works properly for IPv4 TCP sockets. The resulting error is [ECONNABORTED] for a blocking socket which likely leads to infinite looping if the thread does not know about the shutdown(2) (because that error normally means the accept should be retried later). For a non-blocking socket the error is [EWOULDBLOCK] which also leads to infinite looping and is certainly wrong because select/poll do report the socket as readable. Both of these are in kern_accept() in sys/kern/uipc_syscalls.c. POSIX does not say which error code we should return here but these two are almost certainly wrong (it is usable for waking up threads stuck in accept() if those threads check a variable after every accept() failure and do not rely on the exact value of errno). Linux returns [EINVAL] for both blocking and non-blocking sockets, probably from the POSIX error condition "The socket is not accepting connections." In our man page that error condition is formulated "listen(2) has not been called on the socket descriptor." which is clearly not the case. Also, I think a non-blocking accept() should immediately fail with the head->so_error if it is set, rather than returning [EWOULDBLOCK] until another connection arrives. Likewise, filt_solisten() in sys/kern/uipc_socket.c only returns true if there is a connection, not if there was an error or shutdown() has been called. On the other hand, sopoll_generic() looks correct. Error reporting on non-blocking accept() might usefully be postponed until there is a connection or the socket has been shut down, to reduce context switches. > But the summary seems to be is that currently it is not possible to > break a thread out of accept(2) (at least without resorting to > signals). Pthread cancellation works better than raw signals for this use case. In a proper implementation such as in FreeBSD 9.0 or newer and used properly, it allows avoiding the resource leak that may happen when calling longjmp() or pthread_exit() in a signal handler just after accept() has created a new socket. -- Jilles Tjoelker From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 00:27:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C5533A95 for ; Fri, 29 Mar 2013 00:27:39 +0000 (UTC) (envelope-from rodperson@rodperson.com) Received: from www6.pairlite.com (www6.pairlite.com [64.130.10.16]) by mx1.freebsd.org (Postfix) with ESMTP id A6D90D41 for ; Fri, 29 Mar 2013 00:27:39 +0000 (UTC) Received: from [192.168.1.10] (c-71-60-224-178.hsd1.pa.comcast.net [71.60.224.178]) by www6.pairlite.com (Postfix) with ESMTPSA id 1B20D67AEE for ; Thu, 28 Mar 2013 20:27:29 -0400 (EDT) Message-ID: <5156316F.9050202@rodperson.com> Date: Fri, 29 Mar 2013 20:27:27 -0400 From: Rod Person User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: freebsd-hackers@freebsd.org Subject: Help porting Linux app - getting Free Memory and Real Memory Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Mar 2013 01:44:45 +0000 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 00:27:39 -0000 Hi All, I'm working on a port I maintain and the code has drastically changed. Everything is going we except that the program gives warnings that there isn't enough free memory on the system to perform certain actions. The program uses Linux call to /proc/meminfo to get this information. I've worked it out that I should be using the sysctl function to get this information. I wrote this code that seems to give the information that I need, but it does not seem to match up with calling [CMD=""]sysctl[/CMD] from the command line. #include #include #include #include #include #include struct vmtotal getVMinfo(){ struct vmtotal vm_info; int mib[2]; mib[0] = CTL_VM; mib[1] = VM_TOTAL; size_t len = sizeof(vm_info); sysctl(mib, 2, &vm_info, &len, NULL, 0); return vm_info; } int getSysCtl(int top_level, int next_level){ int mib[2], ctlvalue; size_t len; mib[0] = top_level; mib[1] = next_level; len = sizeof(ctlvalue); sysctl(mib, 2, &ctlvalue, &len, NULL, 0); return ctlvalue; } int main(void){ int realmem = getSysCtl(CTL_HW, HW_REALMEM); int usermem = getSysCtl(CTL_HW, HW_USERMEM); int pagesize = getSysCtl(CTL_HW, HW_PAGESIZE); printf("Real Memory: %i\n",realmem); printf("User Memory: %i\n",usermem); printf("Page Size: %i\n",pagesize); struct vmtotal vmsize = getVMinfo(); printf("Total VM Memory: %i\n",vmsize.t_vm); printf("Total Real Memory: %i\n",vmsize.t_rm); printf("shared real memory: %i\n",vmsize.t_rmshr); printf("active shared real memory: %i\n",vmsize.t_armshr); printf("Total Free Memory pages: %i\n",vmsize.t_free); } gives me the following output: Real Memory: 1006632960 User Memory: -1004396544 Page Size: 4096 Total VM Memory: 269489480 Total Real Memory: 153927 shared real memory: 6015 active shared real memory: 5736 Total Free Memory pages: 1497516 But the command sysctl vm.vmtotal outputs: vm.vmtotal: System wide totals computed every five seconds: (values in kilobytes) =============================================== Processes: (RUNQ: 1 Disk Wait: 0 Page Wait: 0 Sleep: 89) Virtual Memory: (Total: 1078017644K Active: 4167380K) Real Memory: (Total: 617380K Active: 516236K) Shared Virtual Memory: (Total: 38944K Active: 28844K) Shared Real Memory: (Total: 24652K Active: 23536K) Free Memory: 5987760K I see that if I use the formula [B](Total Free Pages * Page Size)/1024[/B], I get a number extremely close to the Free Memory number of the command line output, but I'm not sure if that is correct. Any suggestions? Thanks Rod From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 02:31:51 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C1CC7EA5 for ; Fri, 29 Mar 2013 02:31:51 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qc0-x22a.google.com (mail-qc0-x22a.google.com [IPv6:2607:f8b0:400d:c01::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 885A9622 for ; Fri, 29 Mar 2013 02:31:51 +0000 (UTC) Received: by mail-qc0-f170.google.com with SMTP id d42so78230qca.1 for ; Thu, 28 Mar 2013 19:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zStf1w/Wy/YLabbhROMztCo6mzfKncAVikSebo1S4rs=; b=nXJ//y/no4C4jrVHZKlpOhGpWwnHSijykOqlymwmAdyG0HmSDXRIim5k++n1r4r0VC BOnu33xFZ5uEQ0zCQP/yqNP9e7qnyLHW3+T+CUJYK6iTE/2Tan5LnsZF1yTQC8/QFnGv KAxeuN5bU8ii8V0R++fQk6yiOU8aCgO8rn0bSk1sFCG46IgrYmjrGO0ZFJwXc5j9RW29 0dYX8P58+LWerVDg5RMh/tzl7sxa6bM0Jf0ztK89iXtejQ4wuL/FQmX1dM+rbOs2U0/z wQ5HoI7vHS3ds68/NEBKQwIAZxPqeWT2ypDsbjfWRjlvb3JG5f7JJRqusOaZPy5HtUIw tSZA== MIME-Version: 1.0 X-Received: by 10.49.62.2 with SMTP id u2mr1641953qer.22.1364524311010; Thu, 28 Mar 2013 19:31:51 -0700 (PDT) Received: by 10.49.50.67 with HTTP; Thu, 28 Mar 2013 19:31:50 -0700 (PDT) Received: by 10.49.50.67 with HTTP; Thu, 28 Mar 2013 19:31:50 -0700 (PDT) In-Reply-To: <20130328231043.GA3666@ethic.thought.org> References: <20130328212955.GJ42080@manor.msen.com> <20130328231043.GA3666@ethic.thought.org> Date: Thu, 28 Mar 2013 19:31:50 -0700 Message-ID: Subject: Re: Seeking an extended-support O/S similar to FreeBSD From: Freddie Cash To: Gary Kline Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 02:31:51 -0000 I'm confused. Every other minor release of FreeBSD is supported for 2 full years, with no new features added, just security fixes (aka Extended Releases). And every major release of FreeBSD is supported for at least 4, somtimes 5, years. Canonical just shortened their support for LTS to 3 years, including server releases. And you can't get new versions of software on Ubuntu without upgrading the OS or adding random PPA repos. Sometimes you can get a backports repo, but they aren't officially supported. And only the official repos get security updates (if you're lucky). RedHat isn't much better. Sure, they'll support the core OS for 5 years, but you can't install new, up-to-date software on it unless you upgrade the entire OS (been down that road too many times to ever want to try again). We gave up on RedHat after fighting with 2.x, 3.x, and 4.x. FreeBSD isn't perfect (what OS is?), but it's amazing that you can install the newest versions of MySQL, Firefox, KDE, Postfix, etc on 7.4 (until the end of Feb, anyway), or 8.3, or 9.0, or 9.1. And can continue to get security fixes for all those releases (except 7.x now). Good luck installing any of those onto a Linux release from 2-3 years ago. What's missing from FreeBSD support? From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 03:29:09 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12D08789 for ; Fri, 29 Mar 2013 03:29:09 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 89D1B8BF for ; Fri, 29 Mar 2013 03:29:07 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r2T3Svfs050009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Mar 2013 14:28:58 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r2T3Skh7042825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Mar 2013 14:28:46 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r2T3Sjr7042780; Fri, 29 Mar 2013 14:28:45 +1100 (EST) (envelope-from peter) Date: Fri, 29 Mar 2013 14:28:45 +1100 From: Peter Jeremy To: Rod Person Subject: Re: Help porting Linux app - getting Free Memory and Real Memory Message-ID: <20130329032845.GG81066@server.rulingia.com> References: <5156316F.9050202@rodperson.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <5156316F.9050202@rodperson.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 03:29:09 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Mar-29 20:27:27 -0400, Rod Person wrote: >Everything is going we except that the program gives warnings that there >isn't enough free memory on the system to perform certain actions. That premise sounds suspiciously like the upstream author doesn't understand how Unix VM works. >int getSysCtl(int top_level, int next_level){ > int mib[2], ctlvalue; > size_t len; > > mib[0] =3D top_level; > mib[1] =3D next_level; > len =3D sizeof(ctlvalue); > > sysctl(mib, 2, &ctlvalue, &len, NULL, 0); =20 > =20 > return ctlvalue; >} > > >int main(void){ > int realmem =3D getSysCtl(CTL_HW, HW_REALMEM); > int usermem =3D getSysCtl(CTL_HW, HW_USERMEM); HW_REALMEM and HW_USERMEM return an unsigned long, not an int. That probably explains the nonsense value you are seeing in 'User Memory'. > printf("Total VM Memory: %i\n",vmsize.t_vm); > printf("Total Real Memory: %i\n",vmsize.t_rm); > printf("shared real memory: %i\n",vmsize.t_rmshr); > printf("active shared real memory: %i\n",vmsize.t_armshr); > printf("Total Free Memory pages: %i\n",vmsize.t_free); And these numbers are all in pages as you surmise. --=20 Peter Jeremy --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFVCm0ACgkQ/opHv/APuIczIgCfW6kLSGbI7zmjJ7OfNmvdfzzr xzoAn0OiKx1nRg9okBvAFxcCqy6ms2C9 =t6ZM -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 09:22:50 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 49D23B78; Fri, 29 Mar 2013 09:22:50 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 99031696; Fri, 29 Mar 2013 09:22:49 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2T9MkOk077437; Fri, 29 Mar 2013 11:22:46 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2T9MkOk077437 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2T9MjhO077436; Fri, 29 Mar 2013 11:22:45 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 29 Mar 2013 11:22:45 +0200 From: Konstantin Belousov To: Mikolaj Golub Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130329092245.GU3794@kib.kiev.ua> References: <201302200904.15324.jhb@freebsd.org> <20130220195801.GA8679@gmail.com> <20130316180915.GA91146@gmail.com> <20130316191605.GJ3794@kib.kiev.ua> <20130316223339.GA3534@gmail.com> <20130317063033.GL3794@kib.kiev.ua> <20130317091930.GA2833@gmail.com> <20130324155426.GA87022@gmail.com> <20130328105134.GO3794@kib.kiev.ua> <20130328211820.GA6657@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/27iTK9B7rPulYWO" Content-Disposition: inline In-Reply-To: <20130328211820.GA6657@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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 version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: Stanislav Sedov , Attilio Rao , "Robert N. M. Watson" , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 09:22:50 -0000 --/27iTK9B7rPulYWO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 28, 2013 at 11:18:21PM +0200, Mikolaj Golub wrote: > On Thu, Mar 28, 2013 at 12:51:34PM +0200, Konstantin Belousov wrote: >=20 > > In the generic Elf 64bit draft specification I have, the notes sections > > are specified to consists of entries, each of which is an array of 8-by= te > > words. I think we are right using the 8-byte alignment. >=20 > I have impression many implementations use 4-byte alignment. E.g. in > NetBSD: >=20 > sys/kern/core_elf32.c: >=20 > #define ELFROUNDSIZE 4 /* XXX Should it be sizeof(Elf_Word)? */ > #define elfround(x) roundup((x), ELFROUNDSIZE) Note that this is core_elf32. I am concerned with the 64-bit cores. >=20 > Also, we have inconsistency with imgactl_elf.c/parse_notes(), which > uses 4-byte alignment: >=20 > note =3D (const Elf_Note *)((const char *)(note + 1) + > roundup2(note->n_namesz, sizeof(Elf32_Addr)) + > roundup2(note->n_descsz, sizeof(Elf32_Addr))); >=20 > I suppose there were no issues before, because accidentally the sizes > of all notes we had were 8 bytes aligned. Indeed, both ABI and NOINIT notes have size which is multiple of 8. >=20 > Now, when I add new notes it will break things. I don't have strong > opinion, it will be ok for me to leave 8-byte alignment and fix > issues, just want to have strong support here :-) Well, while the issue is discussed and decided, you could just make your new notes size be multiple of 8 too. >=20 > BTW, looking at NetBSD code I see they set p_align in the note > segement to ELFROUNDSIZE: >=20 > /* Write out the PT_NOTE header. */ > ws.psections->p_type =3D PT_NOTE; > ws.psections->p_offset =3D notestart; > ws.psections->p_vaddr =3D 0; > ws.psections->p_paddr =3D 0; > ws.psections->p_filesz =3D notesize; > ws.psections->p_memsz =3D 0; > ws.psections->p_flags =3D PF_R; > ws.psections->p_align =3D ELFROUNDSIZE; >=20 > while we set to 0: >=20 > /* The note segement. */ > phdr->p_type =3D PT_NOTE; > phdr->p_offset =3D hdrsize; > phdr->p_vaddr =3D 0; > phdr->p_paddr =3D 0; > phdr->p_filesz =3D notesz; > phdr->p_memsz =3D 0; > phdr->p_flags =3D 0; > phdr->p_align =3D 0; You mean, for the core dumps ? >=20 > Shouldn't we set it to alignment size too? Note also, they set > "Segment is readable" flag. I think both changes are fine. I skimmed over the usermode parts of the patch. One thing I did not liked is the mis-handling of the read() return values. If there is short read, the errno value is meaningless, but warn() would still append it to the message. I suggest to explicitely distinguish -1 and >=3D 0 returns =66rom reads. --/27iTK9B7rPulYWO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRVV1lAAoJEJDCuSvBvK1BZGIQAJf+hjGDPWtSzNu9sKlfkux8 tPg8xPtVK+htzeZhHyugVqWDsw/rScuLJIvWrtTxgFCy9FMyLVtrDYpOU6OHxzd4 PvjQDLjX1Y/MmW/YC6nxe4apBg4MUzFEkCfrsovRR1IOFbCJOXI8+JYBfSte09Zn sKA5UfPjhoTuF+1GqL3i729zsOZCXbevIpdZ96DxJ0x3FLSQJfby4Jk/sG6CRZWQ R5HiErWfOGu79gA5gR3kHKtlpIQb4iY3TZAZn5L2Qklixjy46HTjlBMeYeRFZKGn 5+qRJAkgcuiXjMOlmXF96AIhzng0o0Ny2nKIW2UsjnTwYpLYGXJf5XSqPAWvnWTb dflSnmE0SGFIbY7rqyhH8xl41QJGvZk5trhxPZfM9qrxSot7r30ZF/aFmswMyh09 08Kp/DC5fP7OfOwnPDbfI4OFAzCDKRIvofTWFbntNb2BNM2eWSLZfm1zIQnpadhg XAGuUj6sbAuVYA75PCIFMW1wa4CTyLfcP82uiFzqOlnTVOHQwDOkQ4ZLGclFl7+S JteULxP+lQ60s1fDcoI9zQblNNqidnFp52WyCHgrOrSt73S4bm+ZImj61Ct98/hw NQKNzN6vrY1wH57CJmzGm38OQ+gbx9GPI2xC6IpvRMt4ay3yL19mFaFpmpZbVEfo WTP92/7u993K4AS7e+r/ =tmGP -----END PGP SIGNATURE----- --/27iTK9B7rPulYWO-- From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 12:32:08 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A6B5783D; Fri, 29 Mar 2013 12:32:08 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by mx1.freebsd.org (Postfix) with ESMTP id 3D3D4F84; Fri, 29 Mar 2013 12:32:07 +0000 (UTC) Received: by mail-ee0-f51.google.com with SMTP id c4so203860eek.10 for ; Fri, 29 Mar 2013 05:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=FpJ0+MsgWnQ+HeV4MEpNTXHsW81Nv+zxGs76zz4EUOg=; b=k1LOhBdn40R5U/OX29k4sQS59iMnt8ERYqFWoGFmgxye3SpnjVOP8i780VCGkWS8sS bu2HVhDiQ3cdOqpXMCxy83joRPfNCVnG9yssRBozdbTymbcSaQADiAvBL2uYbGW+7ia2 GH+xemG4ArFo0zQ5EuitlGE/fg1a+mG4SQl77ZUMt0wTV/hm1c/5FbEpkog2nZ32CuAw uVZeRnVeAumvXp1E4ODZ12pmP4I9a+U1F3YwOL2IzhMiSYSnkFCYr6AWJdNpyDO75pR7 4VD0TkVmifWo/2mCGQw84tYeU8w5PKpkvLcrY6LXLmQuM5bIdy0qWV4zasEOLrbcdnXY 3v0A== X-Received: by 10.14.5.6 with SMTP id 6mr7321801eek.42.1364560320088; Fri, 29 Mar 2013 05:32:00 -0700 (PDT) Received: from localhost ([188.230.122.226]) by mx.google.com with ESMTPS id 3sm3805903eej.6.2013.03.29.05.31.58 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Fri, 29 Mar 2013 05:31:59 -0700 (PDT) Date: Fri, 29 Mar 2013 14:31:57 +0200 From: Mikolaj Golub To: Konstantin Belousov Subject: Re: libprocstat(3): retrieve process command line args and environment Message-ID: <20130329123155.GA94024@gmail.com> References: <20130220195801.GA8679@gmail.com> <20130316180915.GA91146@gmail.com> <20130316191605.GJ3794@kib.kiev.ua> <20130316223339.GA3534@gmail.com> <20130317063033.GL3794@kib.kiev.ua> <20130317091930.GA2833@gmail.com> <20130324155426.GA87022@gmail.com> <20130328105134.GO3794@kib.kiev.ua> <20130328211820.GA6657@gmail.com> <20130329092245.GU3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130329092245.GU3794@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Stanislav Sedov , Attilio Rao , freebsd-hackers@freebsd.org, Mikolaj Golub , "Robert N. M. Watson" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 12:32:08 -0000 On Fri, Mar 29, 2013 at 11:22:45AM +0200, Konstantin Belousov wrote: > On Thu, Mar 28, 2013 at 11:18:21PM +0200, Mikolaj Golub wrote: > > On Thu, Mar 28, 2013 at 12:51:34PM +0200, Konstantin Belousov wrote: > > > > > In the generic Elf 64bit draft specification I have, the notes sections > > > are specified to consists of entries, each of which is an array of 8-byte > > > words. I think we are right using the 8-byte alignment. > > > > I have impression many implementations use 4-byte alignment. E.g. in > > NetBSD: > > > > sys/kern/core_elf32.c: > > > > #define ELFROUNDSIZE 4 /* XXX Should it be sizeof(Elf_Word)? */ > > #define elfround(x) roundup((x), ELFROUNDSIZE) > Note that this is core_elf32. I am concerned with the 64-bit cores. core_elf64.c: #define ELFSIZE 64 #include "core_elf32.c" > > > > Also, we have inconsistency with imgactl_elf.c/parse_notes(), which > > uses 4-byte alignment: > > > > note = (const Elf_Note *)((const char *)(note + 1) + > > roundup2(note->n_namesz, sizeof(Elf32_Addr)) + > > roundup2(note->n_descsz, sizeof(Elf32_Addr))); > > > > I suppose there were no issues before, because accidentally the sizes > > of all notes we had were 8 bytes aligned. > Indeed, both ABI and NOINIT notes have size which is multiple of 8. > > > > > Now, when I add new notes it will break things. I don't have strong > > opinion, it will be ok for me to leave 8-byte alignment and fix > > issues, just want to have strong support here :-) > Well, while the issue is discussed and decided, you could just make > your new notes size be multiple of 8 too. I thought about this too. Then I need to be more caerful when extracting stats from notes, because the length returned by procstat_core_get() can be more than a real payload. Ok, I will try this way. I could add length to the note header, which is currently contains only structsize, so it would became something like: struct { int structsize; int lenght; } But not sure it is worth doing, especially if the forced 8-bit alignment is a temporary mesure. > > > > BTW, looking at NetBSD code I see they set p_align in the note > > segement to ELFROUNDSIZE: > > > > /* Write out the PT_NOTE header. */ > > ws.psections->p_type = PT_NOTE; > > ws.psections->p_offset = notestart; > > ws.psections->p_vaddr = 0; > > ws.psections->p_paddr = 0; > > ws.psections->p_filesz = notesize; > > ws.psections->p_memsz = 0; > > ws.psections->p_flags = PF_R; > > ws.psections->p_align = ELFROUNDSIZE; > > > > while we set to 0: > > > > /* The note segement. */ > > phdr->p_type = PT_NOTE; > > phdr->p_offset = hdrsize; > > phdr->p_vaddr = 0; > > phdr->p_paddr = 0; > > phdr->p_filesz = notesz; > > phdr->p_memsz = 0; > > phdr->p_flags = 0; > > phdr->p_align = 0; > You mean, for the core dumps ? yes > > > > Shouldn't we set it to alignment size too? Note also, they set > > "Segment is readable" flag. > I think both changes are fine. > > I skimmed over the usermode parts of the patch. One thing I did not liked > is the mis-handling of the read() return values. If there is short read, > the errno value is meaningless, but warn() would still append it to > the message. I suggest to explicitely distinguish -1 and >= 0 returns > from reads. ok. Thanks. -- Mikolaj Golub From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 12:34:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 737DA950 for ; Fri, 29 Mar 2013 12:34:20 +0000 (UTC) (envelope-from freebsd-lists@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1A9FA7 for ; Fri, 29 Mar 2013 12:34:20 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id F11C833C6C; Fri, 29 Mar 2013 08:34:08 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id EE0D939829; Fri, 29 Mar 2013 08:34:06 -0400 (EDT) From: Lowell Gilbert To: Rod Person Subject: Re: Help porting Linux app - getting Free Memory and Real Memory References: <5156316F.9050202@rodperson.com> <20130329032845.GG81066@server.rulingia.com> Date: Fri, 29 Mar 2013 08:34:06 -0400 In-Reply-To: <20130329032845.GG81066@server.rulingia.com> (Peter Jeremy's message of "Fri, 29 Mar 2013 14:28:45 +1100") Message-ID: <44li962xmp.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 12:34:20 -0000 Peter Jeremy writes: > On 2013-Mar-29 20:27:27 -0400, Rod Person wrote: >>Everything is going we except that the program gives warnings that there >>isn't enough free memory on the system to perform certain actions. > > That premise sounds suspiciously like the upstream author doesn't > understand how Unix VM works. To be more blunt, these checks may well be useless on Linux. On a quick look, you seem to maintain three ports: idutils, mspdebug, and jogl. I wouldn't expect a free-memory check to be appropriate on any of those. In any case, the definition of "free memory" is different between the VM systems in Linux and BSD . Even if the checks do make sense, the FreeBSD implementation would at the minimum have to include all of the pages that are allocated but not mapped. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 13:08:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7C37553C for ; Fri, 29 Mar 2013 13:08:12 +0000 (UTC) (envelope-from rodperson@rodperson.com) Received: from www6.pairlite.com (www6.pairlite.com [64.130.10.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5C90E1EC for ; Fri, 29 Mar 2013 13:08:12 +0000 (UTC) Received: from [192.168.1.10] (c-71-60-224-178.hsd1.pa.comcast.net [71.60.224.178]) by www6.pairlite.com (Postfix) with ESMTPSA id 0DE0267AEE; Fri, 29 Mar 2013 09:08:07 -0400 (EDT) Message-ID: <51559228.5020302@rodperson.com> Date: Fri, 29 Mar 2013 09:07:52 -0400 From: Rod Person User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Peter Jeremy Subject: Re: Help porting Linux app - getting Free Memory and Real Memory References: <5156316F.9050202@rodperson.com> <20130329032845.GG81066@server.rulingia.com> In-Reply-To: <20130329032845.GG81066@server.rulingia.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Mar 2013 13:14:20 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 13:08:12 -0000 On 03/28/13 23:28, Peter Jeremy wrote: > On 2013-Mar-29 20:27:27 -0400, Rod Person wrote: >> Everything is going we except that the program gives warnings that there >> isn't enough free memory on the system to perform certain actions. > That premise sounds suspiciously like the upstream author doesn't > understand how Unix VM works. First, thanks for you reply. I can't speak to this and only say that he read the Linux proc system for the Free Memory and Cache memory values. Adds them together and that become the value used for free memory. My little hack does seem to stop these warning though. I just want to make sure it correct in thinking and if possible use some standard way of calculating these values. >> int getSysCtl(int top_level, int next_level){ >> int mib[2], ctlvalue; >> size_t len; >> >> mib[0] = top_level; >> mib[1] = next_level; >> len = sizeof(ctlvalue); >> >> sysctl(mib, 2, &ctlvalue, &len, NULL, 0); >> >> return ctlvalue; >> } >> >> >> int main(void){ >> int realmem = getSysCtl(CTL_HW, HW_REALMEM); >> int usermem = getSysCtl(CTL_HW, HW_USERMEM); > HW_REALMEM and HW_USERMEM return an unsigned long, not an int. That > probably explains the nonsense value you are seeing in 'User Memory'. man 3 sysctl, list them as integer that is why I did this. Rod From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 13:17:20 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 16C58780 for ; Fri, 29 Mar 2013 13:17:20 +0000 (UTC) (envelope-from rodperson@rodperson.com) Received: from www6.pairlite.com (www6.pairlite.com [64.130.10.16]) by mx1.freebsd.org (Postfix) with ESMTP id EBC45286 for ; Fri, 29 Mar 2013 13:17:19 +0000 (UTC) Received: from [192.168.1.10] (c-71-60-224-178.hsd1.pa.comcast.net [71.60.224.178]) by www6.pairlite.com (Postfix) with ESMTPSA id 4165F67AEE; Fri, 29 Mar 2013 09:17:19 -0400 (EDT) Message-ID: <51559451.9050708@rodperson.com> Date: Fri, 29 Mar 2013 09:17:05 -0400 From: Rod Person User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Lowell Gilbert Subject: Re: Help porting Linux app - getting Free Memory and Real Memory References: <5156316F.9050202@rodperson.com> <20130329032845.GG81066@server.rulingia.com> <44li962xmp.fsf@lowell-desk.lan> In-Reply-To: <44li962xmp.fsf@lowell-desk.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Mar 2013 13:45:40 +0000 Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 13:17:20 -0000 On 03/29/13 08:34, Lowell Gilbert wrote: > Peter Jeremy writes: > >> On 2013-Mar-29 20:27:27 -0400, Rod Person wrote: >>> Everything is going we except that the program gives warnings that there >>> isn't enough free memory on the system to perform certain actions. >> That premise sounds suspiciously like the upstream author doesn't >> understand how Unix VM works. > To be more blunt, these checks may well be useless on Linux. > On a quick look, you seem to maintain three ports: idutils, mspdebug, > and jogl. I wouldn't expect a free-memory check to be appropriate on any > of those. Really? The port in question if graphics/fotoxx. I have no involvement in the others. For the latter two, I'm not even sure what they are. > In any case, the definition of "free memory" is different between the VM > systems in Linux and BSD . Even if the checks do make sense, the FreeBSD > implementation would at the minimum have to include all of the pages > that are allocated but not mapped. Yes I have read this. Fotoxx uses free memory calculation when applying effects to images. It looks at the image size then calculates how much memory it needs to apply an effect, such as image sharpening. For example, on a 4.5MB jpg file it seems to calculate that 40MB of free memory is need to apply sharpening to the image. 40MB doesn't seem like a lot of memory to me, but since the application way of figuring free memory is Linux specific the warning dialog appear, although it seem to have no ill effect on actually applying the sharpening effect. Rod From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 13:57:31 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B6229778 for ; Fri, 29 Mar 2013 13:57:31 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-da0-x230.google.com (mail-da0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) by mx1.freebsd.org (Postfix) with ESMTP id 90BDE715 for ; Fri, 29 Mar 2013 13:57:31 +0000 (UTC) Received: by mail-da0-f48.google.com with SMTP id p8so229626dan.7 for ; Fri, 29 Mar 2013 06:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=qYUFuSq104eyNTHjaOnxikd7SQNUAJorVb6UQrXcO5Q=; b=s2b9ivmk0sgaIKpns3xo4KUIrLL6ztyTL3DxxLQVZ2J0VqQe4wX5eBkMcB4+kqJscM ua+B/jF/5sDLUJhdfDSU0XHBXJbD4JZ0EM1Iw4ChHD9QCp6UmUFuvrbjqE0dU+Dongbg skY0iGKZjfsNth2gfNwdwD1Zzr+wCh0Fr93oY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=qYUFuSq104eyNTHjaOnxikd7SQNUAJorVb6UQrXcO5Q=; b=M9+12NXykJiWOuwh/jW4cbKxj65I40cb2m1NTe2z7O2G6l4x0Quic06lbNVIG0fZpQ bdN37ABETAJPywdDm214IK3X2aeb2L6vKjpe0xcZxKgFK0zXFTrsbDceBWSitKzFJzgh MZMJGudNfo4z9TnU33mG2oLsz03c6YxyX27QlR2ntjdP9vmYEuHk2fbjf8Xz9H+28NO2 KR9iCFd85sICwca+w6KnRPryYwazU4AgdDxwL0knGKK7QXU++AbNjU4mkoS3UA1knqs7 7VsSJ2JC56peIjka0K7hCX/ZtOW9+8eTVTLljT1y5igj9j8lQaFZ6np2NZWyVzpTWPRX sDEQ== X-Received: by 10.66.233.34 with SMTP id tt2mr4425935pac.160.1364565451167; Fri, 29 Mar 2013 06:57:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.246.3 with HTTP; Fri, 29 Mar 2013 06:57:01 -0700 (PDT) In-Reply-To: <51559451.9050708@rodperson.com> References: <5156316F.9050202@rodperson.com> <20130329032845.GG81066@server.rulingia.com> <44li962xmp.fsf@lowell-desk.lan> <51559451.9050708@rodperson.com> From: Eitan Adler Date: Fri, 29 Mar 2013 09:57:01 -0400 Message-ID: Subject: Re: Help porting Linux app - getting Free Memory and Real Memory To: Rod Person Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkdi7h9emSlZScTDS4I/hRjFkacEvhsFyO5K23Q5s3cVig5VXtGc38BGAYJdwniqLL+8Bzn Cc: Lowell Gilbert , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 13:57:31 -0000 On 29 March 2013 09:17, Rod Person wrote: > On 03/29/13 08:34, Lowell Gilbert wrote: >> Peter Jeremy writes: >> >>> On 2013-Mar-29 20:27:27 -0400, Rod Person wrote: >>>> Everything is going we except that the program gives warnings that there >>>> isn't enough free memory on the system to perform certain actions. >>> That premise sounds suspiciously like the upstream author doesn't >>> understand how Unix VM works. >> To be more blunt, these checks may well be useless on Linux. >> On a quick look, you seem to maintain three ports: idutils, mspdebug, >> and jogl. I wouldn't expect a free-memory check to be appropriate on any >> of those. > Really? The port in question if graphics/fotoxx. I have no involvement > in the others. For the latter two, I'm not even sure what they are. > >> In any case, the definition of "free memory" is different between the VM >> systems in Linux and BSD . Even if the checks do make sense, the FreeBSD >> implementation would at the minimum have to include all of the pages >> that are allocated but not mapped. > Yes I have read this. Fotoxx uses free memory calculation when applying > effects to images. It looks at the image size then calculates how much > memory it needs to apply an effect, such as image sharpening. For > example, on a 4.5MB jpg file it seems to calculate that 40MB of free > memory is need to apply sharpening to the image. 40MB doesn't seem like > a lot of memory to me, but since the application way of figuring free > memory is Linux specific the warning dialog appear, although it seem to > have no ill effect on actually applying the sharpening effect. This is also racy and wrong. The application has the memory free (I doubt it allocates 2^32 = bytes of space). What happens if I start 1000 of this programs at the same time, the each check the free memory at the same time, find it to be sufficient, allocate memory, and it now becomes insufficient according to the program? The application should trust the operating system to manage this correctly unless it has *very* good reason not to (for instance, database programs often perform their own swapping/paging). My suggestion if you are to patch this program at all is to remove the check entirely and submit this upstream. -- Eitan Adler From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 14:04:18 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 57251A43 for ; Fri, 29 Mar 2013 14:04:18 +0000 (UTC) (envelope-from freebsd-lists@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id 30ABD75D for ; Fri, 29 Mar 2013 14:04:17 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id EC1D233C6E; Fri, 29 Mar 2013 10:04:11 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id 39B8239829; Fri, 29 Mar 2013 10:04:11 -0400 (EDT) From: Lowell Gilbert To: Rod Person Subject: Re: Help porting Linux app - getting Free Memory and Real Memory References: <5156316F.9050202@rodperson.com> <20130329032845.GG81066@server.rulingia.com> <44li962xmp.fsf@lowell-desk.lan> <51559451.9050708@rodperson.com> Date: Fri, 29 Mar 2013 10:04:11 -0400 In-Reply-To: <51559451.9050708@rodperson.com> (Rod Person's message of "Fri, 29 Mar 2013 09:17:05 -0400") Message-ID: <44haju2tgk.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: Lowell Gilbert , freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 14:04:18 -0000 Rod Person writes: > On 03/29/13 08:34, Lowell Gilbert wrote: >> Peter Jeremy writes: >> >>> On 2013-Mar-29 20:27:27 -0400, Rod Person wrote: >>>> Everything is going we except that the program gives warnings that there >>>> isn't enough free memory on the system to perform certain actions. >>> That premise sounds suspiciously like the upstream author doesn't >>> understand how Unix VM works. >> To be more blunt, these checks may well be useless on Linux. >> On a quick look, you seem to maintain three ports: idutils, mspdebug, >> and jogl. I wouldn't expect a free-memory check to be appropriate on any >> of those. > Really? The port in question if graphics/fotoxx. I have no involvement > in the others. For the latter two, I'm not even sure what they are. Oops. I apologize; I actually looked for ports maintained by the other person who responded to you. Very silly mistake on my part. I don't think a free-memory check is appropriate here, either. >> In any case, the definition of "free memory" is different between the VM >> systems in Linux and BSD . Even if the checks do make sense, the FreeBSD >> implementation would at the minimum have to include all of the pages >> that are allocated but not mapped. > Yes I have read this. Fotoxx uses free memory calculation when applying > effects to images. It looks at the image size then calculates how much > memory it needs to apply an effect, such as image sharpening. For > example, on a 4.5MB jpg file it seems to calculate that 40MB of free > memory is need to apply sharpening to the image. 40MB doesn't seem like > a lot of memory to me, but since the application way of figuring free > memory is Linux specific the warning dialog appear, although it seem to > have no ill effect on actually applying the sharpening effect. I would recommend removing the check completely. The upstream author should do this for the Linux version as well; it really doesn't make sense in a system that supports virtual memory. If you decide to support it anyway to make some kind of performance guarantees, you probably should check against all of user memory; "free" memory is by definition being underutilized. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 14:27:56 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BD3CEBD7 for ; Fri, 29 Mar 2013 14:27:56 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [188.252.31.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4127B8AE for ; Fri, 29 Mar 2013 14:27:55 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5) with ESMTP id r2TERd9g058827; Fri, 29 Mar 2013 15:27:39 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.6/8.14.5/Submit) with ESMTP id r2TERdOx058824; Fri, 29 Mar 2013 15:27:39 +0100 (CET) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 29 Mar 2013 15:27:39 +0100 (CET) From: Wojciech Puchar To: Rod Person Subject: Re: Help porting Linux app - getting Free Memory and Real Memory In-Reply-To: <5156316F.9050202@rodperson.com> Message-ID: References: <5156316F.9050202@rodperson.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 29 Mar 2013 15:27:39 +0100 (CET) Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 14:27:56 -0000 > I'm working on a port I maintain and the code has drastically changed. > Everything is going we except that the program gives warnings that there > isn't enough free memory on the system to perform certain actions. > The program uses Linux call to /proc/meminfo to get this information. this is just a nonsense. the only thing program should check is data size limit. man getrlimit. RLIMIT_DATA is fine. unices (including linux) have virtual memory. providing enough total VM is a job for sysadmin. checking available memory by one program doesn't make much sense, as other programs are running in the same time. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 14:48:23 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1EB41FD8 for ; Fri, 29 Mar 2013 14:48:23 +0000 (UTC) (envelope-from freebsd-lists@be-well.ilk.org) Received: from be-well.ilk.org (be-well.ilk.org [23.30.133.173]) by mx1.freebsd.org (Postfix) with ESMTP id EB038988 for ; Fri, 29 Mar 2013 14:48:22 +0000 (UTC) Received: from lowell-desk.lan (lowell-desk.lan [172.30.250.41]) by be-well.ilk.org (Postfix) with ESMTP id 5238B33C60; Fri, 29 Mar 2013 10:48:17 -0400 (EDT) Received: by lowell-desk.lan (Postfix, from userid 1147) id E9CB239829; Fri, 29 Mar 2013 10:48:15 -0400 (EDT) From: Lowell Gilbert To: Rod Person Subject: Re: Help porting Linux app - getting Free Memory and Real Memory References: <5156316F.9050202@rodperson.com> <20130329032845.GG81066@server.rulingia.com> <51559228.5020302@rodperson.com> Date: Fri, 29 Mar 2013 10:48:15 -0400 In-Reply-To: <51559228.5020302@rodperson.com> (Rod Person's message of "Fri, 29 Mar 2013 09:07:52 -0400") Message-ID: <44d2ui2rf4.fsf@lowell-desk.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-hackers@freebsd.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 14:48:23 -0000 Rod Person writes: > man 3 sysctl, list them as integer that is why I did this. "unsigned long" *is* an integer, but it's a different kind of integer than an "int." This is an important distinction in the C language. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 14:14:15 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C08F3651 for ; Fri, 29 Mar 2013 14:14:15 +0000 (UTC) (envelope-from rodperson@rodperson.com) Received: from www6.pairlite.com (www6.pairlite.com [64.130.10.16]) by mx1.freebsd.org (Postfix) with ESMTP id 9FE1C80B for ; Fri, 29 Mar 2013 14:14:15 +0000 (UTC) Received: from [192.168.1.10] (c-71-60-224-178.hsd1.pa.comcast.net [71.60.224.178]) by www6.pairlite.com (Postfix) with ESMTPSA id DD1A967AEE; Fri, 29 Mar 2013 10:14:10 -0400 (EDT) Message-ID: <5155A1A4.6080801@rodperson.com> Date: Fri, 29 Mar 2013 10:13:56 -0400 From: Rod Person User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Lowell Gilbert Subject: Re: Help porting Linux app - getting Free Memory and Real Memory References: <5156316F.9050202@rodperson.com> <20130329032845.GG81066@server.rulingia.com> <44li962xmp.fsf@lowell-desk.lan> <51559451.9050708@rodperson.com> <44haju2tgk.fsf@lowell-desk.lan> In-Reply-To: <44haju2tgk.fsf@lowell-desk.lan> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 29 Mar 2013 15:32:44 +0000 Cc: freebsd-hackers@freebsd.org, lists@eitanadler.com X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 14:14:15 -0000 On 03/29/13 10:04, Lowell Gilbert wrote: > I would recommend removing the check completely. The upstream author > should do this for the Linux version as well; it really doesn't make > sense in a system that supports virtual memory. If you decide to > support it anyway to make some kind of performance guarantees, you > probably should check against all of user memory; "free" memory is by > definition being underutilized. Well, being that I received this suggestion from you and Eitan; this is probably the way to go. I'll contact the upstream author and see if he has a better explanation as why he does this. There is one other section that uses this check also, but I have not seen it raise a warning on my testing of the app. Thank you guys. Rod From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 18:06:47 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C91529B7 for ; Fri, 29 Mar 2013 18:06:47 +0000 (UTC) (envelope-from wayne@manor.msen.com) Received: from manor.msen.com (manor.msen.com [148.59.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id 8CC171F3 for ; Fri, 29 Mar 2013 18:06:47 +0000 (UTC) Received: from manor.msen.com (localhost [127.0.0.1]) by manor.msen.com (8.12.11/8.12.11) with ESMTP id r2TI6kwq063377 for ; Fri, 29 Mar 2013 13:06:46 -0500 (EST) (envelope-from wayne@manor.msen.com) Received: (from wayne@localhost) by manor.msen.com (8.12.11/8.12.11/Submit) id r2TI6k8P063376 for freebsd-hackers@freebsd.org; Fri, 29 Mar 2013 13:06:46 -0500 (EST) (envelope-from wayne) Date: Fri, 29 Mar 2013 13:06:46 -0500 From: Michael Wayne To: FreeBSD Hackers Subject: Re: Seeking an extended-support O/S similar to FreeBSD Message-ID: <20130329180646.GL42080@manor.msen.com> Mail-Followup-To: FreeBSD Hackers References: <20130328212955.GJ42080@manor.msen.com> <20130328231043.GA3666@ethic.thought.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 18:06:47 -0000 On Thu, Mar 28, 2013 at 07:31:50PM -0700, Freddie Cash wrote: > > Every other minor release of FreeBSD is supported for 2 full years, with no > new features added, just security fixes (aka Extended Releases). > > And every major release of FreeBSD is supported for at least 4, somtimes 5, > years. That's exactly the issue. After 4-5 years, there's nothing. > RedHat isn't much better. Sure, they'll support the core OS for 5 years, > but you can't install new, up-to-date software on it unless you upgrade the > entire OS (been down that road too many times to ever want to try again). > We gave up on RedHat after fighting with 2.x, 3.x, and 4.x. Thanks. I appreciate the feedback. > FreeBSD isn't perfect (what OS is?), but it's amazing that you can install > the newest versions of MySQL, Firefox, KDE, Postfix, etc on 7.4 (until the > end of Feb, anyway), or 8.3, or 9.0, or 9.1. And can continue to get > security fixes for all those releases (except 7.x now). That's no help at all to a bunch of machines that started life on 4.1 back in 2000 and will continue to run another 10-15 years, is it? What's your suggestion for dealing with that? It's not like anything currently supported is gonna fit on those machines without a rediculous amount of effort. > What's missing from FreeBSD support? Having one release supported for an extended time. It would be insane to consider maintaining every release for an extended period but ONE release, supported for an extended period (decades) would really help. We're far enough down the security path that there are not that many security vulnerabilities in base. Ports generally build just fine on older versions. From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 18:32:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5717B922 for ; Fri, 29 Mar 2013 18:32:12 +0000 (UTC) (envelope-from toasty@dragondata.com) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 24C9A333 for ; Fri, 29 Mar 2013 18:32:12 +0000 (UTC) Received: by mail-ie0-f170.google.com with SMTP id c11so812628ieb.15 for ; Fri, 29 Mar 2013 11:32:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dragondata.com; s=google; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=mWNs4Qcil2qF0SvlEWPuwHZfZk0pc7LEQyLBVo+8Wkk=; b=gp9+vBebFEDE7TUvWmcKBW0WdipxJ7LVSCo4/nXUB5weSuKPaxJUxt653a+z3n+1rm E7QOFdxAm8ZhNaB2GPEqiJqeK8ABPg1ind8llpvX6v1ih8RC5piOIFTQxzPtMqgqU/pV M83lGa/SxjHxR87nA2PrSyaH49NDUkC+HP3Zk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=mWNs4Qcil2qF0SvlEWPuwHZfZk0pc7LEQyLBVo+8Wkk=; b=McNFMTUkYou9xqgc+pmXk9P90EO1hKvxdz5JV6ojcqbFbJyVvLjQmrB0mSxsgT4Eo2 gHpwl4+vb5PehNydjN7x4mTwnJ2ptZQk0wewKaMB6X8MJfzqn1D3rZo3FXglUM/HN/60 cSzIL5PdmZ8MCuKkF1aKNCPrSbm/0ii5wQc3Dfu8sqIUZiAU4bkWDYbOO6ORoOWKyaP5 BLT8gT5U2v3tuj0ENtMxkiCsU3ob+HAMEhZ1eLDPY6NsnYw/YLk+DkaYdzjaVIQp0Kp/ bvC5zmIkL5NZsherQD0MiZHrMUCUMhKJ6HVUeNL547K40+isM4Fn97sYp7hetxlvvfFp uMMA== X-Received: by 10.50.127.132 with SMTP id ng4mr331124igb.32.1364581931821; Fri, 29 Mar 2013 11:32:11 -0700 (PDT) Received: from vpn132.rw1.your.org (vpn132.rw1.your.org. [204.9.51.132]) by mx.google.com with ESMTPS id y5sm602641igg.7.2013.03.29.11.32.10 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 29 Mar 2013 11:32:11 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: Seeking an extended-support O/S similar to FreeBSD From: Kevin Day In-Reply-To: <20130329180646.GL42080@manor.msen.com> Date: Fri, 29 Mar 2013 13:32:09 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5659014B-03C2-4FBC-B2F9-4C1B667C2A67@dragondata.com> References: <20130328212955.GJ42080@manor.msen.com> <20130328231043.GA3666@ethic.thought.org> <20130329180646.GL42080@manor.msen.com> To: Michael Wayne X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQkPKrjgn2RaEypvYptxeSUfolTvkJ/GxD6Rkpv5rD+u2SpEdR2FaJpvfVniHbwWHGbowoKt Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 18:32:12 -0000 On Mar 29, 2013, at 1:06 PM, Michael Wayne = wrote: > On Thu, Mar 28, 2013 at 07:31:50PM -0700, Freddie Cash wrote: >>=20 >> Every other minor release of FreeBSD is supported for 2 full years, = with no >> new features added, just security fixes (aka Extended Releases). >>=20 >> And every major release of FreeBSD is supported for at least 4, = somtimes 5, >> years. >=20 > That's exactly the issue. After 4-5 years, there's nothing. >=20 >> FreeBSD isn't perfect (what OS is?), but it's amazing that you can = install >> the newest versions of MySQL, Firefox, KDE, Postfix, etc on 7.4 = (until the >> end of Feb, anyway), or 8.3, or 9.0, or 9.1. And can continue to get >> security fixes for all those releases (except 7.x now). >=20 > That's no help at all to a bunch of machines that started life on > 4.1 back in 2000 and will continue to run another 10-15 years, is > it? What's your suggestion for dealing with that? It's not like > anything currently supported is gonna fit on those machines without > a rediculous amount of effort. >=20 >> What's missing from FreeBSD support? >=20 > Having one release supported for an extended time. It would be > insane to consider maintaining every release for an extended period > but ONE release, supported for an extended period (decades) would > really help. We're far enough down the security path that there > are not that many security vulnerabilities in base. Ports generally > build just fine on older versions. =20 We have servers that are currently in production use that we purchased = in 2002. They're fully capable of running 9.1-RELEASE, so we keep them = updated regularly. FreeBSD 2.x through 9.1 are installable off a single = CD - disk space requirements have not increased in any substantial way. = Later kernels tend to have more things in modules, so memory usage may = be lower just with a GENERIC kernel.=20 Compatibility also isn't really an issue - this isn't like Windows where = upgrading from Windows XP to Windows 8 is going to leave you with a = bunch of applications that don't work and missing drivers for half your = stuff. In most cases support is additive, and backwards compatible.=20 It's very rare for a new version to pull support for hardware that's = even slightly commonly used. The only reason things get pulled are that = usually there's nobody with hardware anymore to even test it, so trying = to maintain compatibility even on an ancient version of FreeBSD is hard = because the ability to verify they haven't broken it is gone. You also need to consider power cost v.s. replacing hardware, too. A = server that was a beast in 2000 is likely slower than a modern day Atom = box, and likely uses 10-30x the power. We obsolete (and donate) old = equipment once replacing it pays for itself in 6 months. All of our = pre-2002 servers are gone now due to this, and we'll probably be in the = 2005 range by the end of the year. And keep in mind that there have been many vulnerabilities in the base = system, mostly local but some remote. Just pushing a patch out to = FreeBSD 4.1 is going to be a big undertaking because, again, it = supported some obscure stuff that got removed because there are no = developers who even have that hardware anymore. (ISDN for example) Asking for "decades" of support is rare for any software product, unless = you're talking about enterprise levels of support that basically pay for = a few people's salaries to be dedicated on it. To use Microsoft as an = example, Windows Server 2003 was released in 2003, and standard = support/updates ended in 2010. That's *paid* support that lasts 7 years. = You can pay even more gobs of money to get another 5 years of *support* = but no updates out of them. If you want security updates to Windows = Server 2003 beyond 2010, you installed Server 2008, which is supported = until 2015. Their basic policy is they support things for a minimum of 5 = years, or 2 years after the next version comes out, whichever is longer.=20= Rather than saying you want a 20-30 year commitment on one specific = version, can you go into more detail why updating isn't possible for = you? freebsd-update has made updating about as painless as I can = imagine it being. Especially if you want to live a little dangerously = and skip the last step that removes the old libraries - you don't need = to recompile anything if you really can't. If you're operating things = that are extremely risk averse where any change needs substantial = validation before putting it into production, you're probably better off = with a commercial OS that splits out individual changes instead of = rolling releases like FreeBSD. We walk a lot of our customers through keeping their systems updated, so = I'm always curious to hear why it's unpalatable for some reason. -- Kevin From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 18:57:11 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9FE6184C for ; Fri, 29 Mar 2013 18:57:11 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 3863364F for ; Fri, 29 Mar 2013 18:57:11 +0000 (UTC) Received: by mail-we0-f178.google.com with SMTP id z53so526128wey.37 for ; Fri, 29 Mar 2013 11:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=yNUhukKoDTJbd9TtLSBUEJIMGNf7OWhXTPiZqSP/Q7Q=; b=s2evQ/8RX4L/AS61ty+hXoPYVeeoPbs4JpX8vIFhF876YYPLxF+LcrcxHExznIickl 0ShXvPfcIqiKsiuz22WIygnd8A1YNGMJ39YELuq5yPERtadtp6SE3jVFKLKHVpy9vxsz EKkcALCVWMQij3sRejmHZCfsO1RBjeog+ZyYcNfPfZX3kgPq2QQ+SNBGCPkQm0ygQHY3 IQGSB77PjKtvzjNbXEcliK2buY0h9hVw9oc9EkfbJKfUuGAkC8Ol8IbiEl/jbGXPXr5H 74VJ8i/a+Ap86Ye0bJ9Irv3QOwWoUCiBoS3BQHriS5cU726PS0lB0cn7sfiBoaF76cjb P2vg== MIME-Version: 1.0 X-Received: by 10.194.171.74 with SMTP id as10mr5217179wjc.0.1364583430209; Fri, 29 Mar 2013 11:57:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.108.130 with HTTP; Fri, 29 Mar 2013 11:57:10 -0700 (PDT) In-Reply-To: <20130329180646.GL42080@manor.msen.com> References: <20130328212955.GJ42080@manor.msen.com> <20130328231043.GA3666@ethic.thought.org> <20130329180646.GL42080@manor.msen.com> Date: Fri, 29 Mar 2013 11:57:10 -0700 X-Google-Sender-Auth: _3ARAgW6ECMWXFYJGbsrQYRfhcM Message-ID: Subject: Re: Seeking an extended-support O/S similar to FreeBSD From: Adrian Chadd To: FreeBSD Hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 18:57:11 -0000 Again, no-one is going to really complain if vendors/users decide to step up and run longer supported branches. I personally encourage that. I _encourage_ that people who are interested in keeping 6.x and earlier alive (and 7.x soon, and 8.x less soon) to jump in and submit patches to backport fixes and whatnot. The problem isn't that we don't want to - it's that we just don't have the collective time and energy to backport things to branches we're not using. If you're a company with a heavy investment in older branches, please consider what I've said. Participate in FreeBSD development and offer to support branches for longer. But please don't complain to a bunch of volunteers who look after stuff in their spare time, or companies who fund work for FreeBSD branches that they're using. The 'project' does what its users and developers contribute to. Adrian From owner-freebsd-hackers@FreeBSD.ORG Fri Mar 29 21:31:21 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B39FBBF3; Fri, 29 Mar 2013 21:31:21 +0000 (UTC) (envelope-from carl.shapiro@gmail.com) Received: from mail-ee0-f52.google.com (mail-ee0-f52.google.com [74.125.83.52]) by mx1.freebsd.org (Postfix) with ESMTP id EC3E7BD7; Fri, 29 Mar 2013 21:31:20 +0000 (UTC) Received: by mail-ee0-f52.google.com with SMTP id d17so365544eek.39 for ; Fri, 29 Mar 2013 14:31:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=UNRVeLlZ3+LV1qGwRyfHk/1RtGcJ+c2dGt68gzMzVqU=; b=Xs84vx7JVZwaigHnDXo1VAOnsgbv2RPy9I/Pt2Vg6Tt5nEOCwmARa+OcMoCYmT70og 8wopwBt64V9hCYfF9qeHQWDOjyHfXh0gY7JDFffO6wUcONcrZdV/s6ZbukOj3oTYUM65 O4p5hr1SbtVEy9xHMAdNZeECXlnlDUXXbZS4y2tcT49eGppmznK5EphrMnUJTUCU8dn0 pgcMroRBKRw91EIMh64aGa4e4E9t3rOsa+ZOX19GX7Gp3a9FmLhCVKdDuYahmerkmve6 jAtatIus0FxBYX9PQsYuRUfo6S9HwMnU64wRHDZBz26pZvPJtVH9jjVE9tTbgYWg4uel 7Ifw== X-Received: by 10.14.207.200 with SMTP id n48mr11887242eeo.4.1364592679631; Fri, 29 Mar 2013 14:31:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.14.129.2 with HTTP; Fri, 29 Mar 2013 14:30:59 -0700 (PDT) In-Reply-To: <515475C7.6010404@FreeBSD.org> References: <515475C7.6010404@FreeBSD.org> From: Carl Shapiro Date: Fri, 29 Mar 2013 14:30:59 -0700 Message-ID: Subject: Re: close(2) while accept(2) is blocked To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 21:31:21 -0000 On Thu, Mar 28, 2013 at 9:54 AM, Andriy Gapon wrote: > But the summary seems to be is that currently it is not possible to break > a thread > out of accept(2) (at least without resorting to signals). > This is a known problem for Java. Closing a socket that another thread is block on is supposed to unblock a thread and throw a SocketException. http://docs.oracle.com/javase/7/docs/api/java/net/Socket.html#close() In other operating systems, such as Solaris and MacOS X, closing the descriptor causes blocked system calls to return with an error. FreeBSD (and Linux) do not behave this way. There, a JVM must do extra bookkeeping to associate file descriptors with threads blocked on the descriptor. This allows the close method to identify blocked threads and send them a signal. On those threads the caller of the blocking method must further distinguish an error return as being caused by a signal sent on behalf of close. It is not obvious whether there is any benefit to having the current blocking behaviour. Threads are an afterthought in UNIX so this could just be an oversight. It would make a high-level language runtimes simpler if FreeBSD behaved more like Solaris and MacOS X. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 30 00:03:02 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A2D05BA1; Sat, 30 Mar 2013 00:03:02 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id 8B57D11A; Sat, 30 Mar 2013 00:03:02 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 32D7FB82A; Fri, 29 Mar 2013 16:54:31 -0700 (PDT) To: Carl Shapiro Subject: Re: close(2) while accept(2) is blocked In-reply-to: Your message of "Fri, 29 Mar 2013 14:30:59 PDT." References: <515475C7.6010404@FreeBSD.org> Comments: In-reply-to Carl Shapiro message dated "Fri, 29 Mar 2013 14:30:59 -0700." Date: Fri, 29 Mar 2013 16:54:31 -0700 From: Bakul Shah Message-Id: <20130329235431.32D7FB82A@mail.bitblocks.com> Cc: freebsd-net@freebsd.org, Andriy Gapon , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 00:03:02 -0000 On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro wrote: > > In other operating systems, such as Solaris and MacOS X, closing the > descriptor causes blocked system calls to return with an error. What happens if you select() on a socket and another thread closes this socket? Ideally select() should return (with EINTR?) so that the blocking thread can some cleanup action. And if you do that, the blocking accept() case is not really different. There is no point in *not* telling blocking threads that the descriptor they're waiting on is one EBADF and nothing is going to happen. > It is not obvious whether there is any benefit to having the current > blocking behaviour. This may need some new kernel code but IMHO this is worth fixing. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 30 03:42:04 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 679D8716 for ; Sat, 30 Mar 2013 03:42:04 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) by mx1.freebsd.org (Postfix) with ESMTP id 49408E7C for ; Sat, 30 Mar 2013 03:42:03 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r2U3g2pH021677; Sat, 30 Mar 2013 03:42:02 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 9jn29f5c5hgqzggsdzzxuv3j3a; Sat, 30 Mar 2013 03:42:02 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: Seeking an extended-support O/S similar to FreeBSD Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <20130329180646.GL42080@manor.msen.com> Date: Fri, 29 Mar 2013 20:42:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2EBA0470-F06B-4C15-A745-992521E511FC@kientzle.com> References: <20130328212955.GJ42080@manor.msen.com> <20130328231043.GA3666@ethic.thought.org> <20130329180646.GL42080@manor.msen.com> To: Michael Wayne X-Mailer: Apple Mail (2.1283) Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 03:42:04 -0000 >=20 > That's no help at all to a bunch of machines that started life on > 4.1 back in 2000 and will continue to run another 10-15 years=85 So you basically want a group of people to help you maintain FreeBSD 4-STABLE for an indefinite period of time? There seem to be quite a few people still running FreeBSD 4.x-based systems; I'm sure if you ask around you could find a group of people to help you with this. Tim From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 30 07:13:12 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3B613468 for ; Sat, 30 Mar 2013 07:13:12 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) by mx1.freebsd.org (Postfix) with ESMTP id C0726383 for ; Sat, 30 Mar 2013 07:13:11 +0000 (UTC) Received: by mail-ve0-f181.google.com with SMTP id pa12so1111266veb.26 for ; Sat, 30 Mar 2013 00:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=JGtbSOd8EZNi2wuIahn/OuQDugQmokIEWyyNw5ur17E=; b=aMqIASoLE4XG2ykHB3BIsIEdIi3D6DG6UxmjGonEfV6Vy5HxPi4zD3rVeGurf/2+Sy /TCoCnMROT13pwM/4uUZXnnyVxX1QmNFXbCp+HIYZ+QmR3ZRAVc7W8fQJuaAJUrmOEIR GzEjKQbMDpSMlB9SKDLcg8S2s+8XbUaUhR0H2ATJOJs+W/9Dp2a4TfwezBGCNuJ/oZ78 +Jnb+a3WTVJemWcmyekQ7aZBhhFB4xIe5TSPFkV1VYxWEbs6GtQk8l94QedJX6MEf1a+ 1E+836RlT6i77oMX3t4spyWtR8pqnvF8A+eBKPt2KX6o812tCB6vf34XZvhpmxBLAsIg LyiQ== MIME-Version: 1.0 X-Received: by 10.52.116.130 with SMTP id jw2mr3209499vdb.69.1364627590791; Sat, 30 Mar 2013 00:13:10 -0700 (PDT) Received: by 10.220.107.71 with HTTP; Sat, 30 Mar 2013 00:13:10 -0700 (PDT) Date: Sat, 30 Mar 2013 03:13:10 -0400 Message-ID: Subject: the Newcons Project From: "Sam Fourman Jr." To: freebsd-hackers@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 07:13:12 -0000 My understanding of this whole subject is limited, but bear with me... in my quest to get a "cool looking console for my desktop... I found this https://wiki.freebsd.org/Newcons does anyone know if someone is still actively working on the NewCons project? or is it already committed to HEAD and i just don't realize? the wiki is a bit confusing... I would VERY much be able to have a console that looked like this in FreeBSD http://wiki.gentoo.org/images/7/7c/Bootsplash.png but if my understanding is correct, we are not at this point (yet)... even if you pull the development source from here svn co svn://svn.freebsd.org/base/user/ed/newcons and change the kernel config like this: #device vga # VGA video card driver #device sc device vt device vt_vga could someone with more understanding of this, be able to tell me if the Newcons project (when completed) is even going to do what i'm looking for? if so, exactly what things have to be done yet, in order for FreeBSD to have a console like Gentoo? -- Sam Fourman Jr. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 30 08:10:52 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 996B5DDC; Sat, 30 Mar 2013 08:10:52 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id B29F66E6; Sat, 30 Mar 2013 08:10:51 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA29589; Sat, 30 Mar 2013 10:10:43 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1ULqs7-000OOh-HX; Sat, 30 Mar 2013 10:10:43 +0200 Message-ID: <51569DFF.5080708@FreeBSD.org> Date: Sat, 30 Mar 2013 10:10:39 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130321 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-hackers@FreeBSD.org, toolchain@FreeBSD.org Subject: clang: -mno-omit-leaf-frame-pointer X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=X-VIET-VPS Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 08:10:52 -0000 It seems that, unlike gcc, for clang -fno-omit-frame-pointer does not imply -mno-omit-leaf-frame-pointer. This is probably a bug. Meanwhile I would like to propose the following amd64-specific patch. Perhaps the same type of change would be useful for powerpc as well. I would like this change primarily for DTrace (fbt), but other debugging/profiling code may benefit from it as well. I chose to make -mno-omit-leaf-frame-pointer not conditional on clang, because with gcc it is just a nop (i.e. it doesn't hurt anything). --- a/sys/conf/Makefile.amd64 +++ b/sys/conf/Makefile.amd64 @@ -32,7 +32,7 @@ S= ../../.. .include "$S/conf/kern.pre.mk" .if !empty(DDB_ENABLED) || !empty(DTR_ENABLED) || !empty(HWPMC_ENABLED) -CFLAGS+= -fno-omit-frame-pointer +CFLAGS+= -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer .endif MKMODULESENV+= MACHINE=amd64 diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk index f0d3d4d..7eaba85 100644 --- a/sys/conf/kmod.mk +++ b/sys/conf/kmod.mk @@ -122,7 +122,7 @@ LDFLAGS+= -d -warn-common CFLAGS+= ${DEBUG_FLAGS} .if ${MACHINE_CPUARCH} == amd64 -CFLAGS+= -fno-omit-frame-pointer +CFLAGS+= -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer .endif .if ${MACHINE_CPUARCH} == powerpc -- Andriy Gapon From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 30 12:55:06 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1AA67A54; Sat, 30 Mar 2013 12:55:06 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw03.mail.saunalahti.fi (gw03.mail.saunalahti.fi [195.197.172.111]) by mx1.freebsd.org (Postfix) with ESMTP id D05F73E6; Sat, 30 Mar 2013 12:55:05 +0000 (UTC) Received: from jh (a91-153-115-208.elisa-laajakaista.fi [91.153.115.208]) by gw03.mail.saunalahti.fi (Postfix) with SMTP id 0279D21658B; Sat, 30 Mar 2013 14:45:22 +0200 (EET) Date: Sat, 30 Mar 2013 14:45:22 +0200 From: Jaakko Heinonen To: Andriy Gapon Subject: Re: big change to devfs rules path matching Message-ID: <20130330120724.GB32407@jh> References: <5150B598.7050700@FreeBSD.org> <5150B71B.6060106@FreeBSD.org> <5154012A.4010602@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5154012A.4010602@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-hackers@FreeBSD.org, FreeBSD Current X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 12:55:06 -0000 On 2013-03-28, Andriy Gapon wrote: > > Would like to ask for opinions on this topic... > > Please read this PR for context: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/122838 > > Especially Jaakko's insightful description of the problem. > > So I would like to commit the following patch sooner rather than later: > http://people.freebsd.org/~avg/devfs_rule.diff > The only difference from the Jaakko's patch in the PR is FNM_PATHNAME. > > Please review and test. Good to see this moving forward! Maybe the change warrants an UPDATING entry? -- Jaakko From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 30 16:14:41 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AE728F2B; Sat, 30 Mar 2013 16:14:41 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) by mx1.freebsd.org (Postfix) with ESMTP id 852B8F16; Sat, 30 Mar 2013 16:14:41 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r2UGEYF6026692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 30 Mar 2013 09:14:34 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r2UGEYwp026691; Sat, 30 Mar 2013 09:14:34 -0700 (PDT) (envelope-from jmg) Date: Sat, 30 Mar 2013 09:14:34 -0700 From: John-Mark Gurney To: Bakul Shah Subject: Re: close(2) while accept(2) is blocked Message-ID: <20130330161434.GG76354@funkthat.com> Mail-Followup-To: Bakul Shah , Carl Shapiro , freebsd-net@freebsd.org, Andriy Gapon , FreeBSD Hackers References: <515475C7.6010404@FreeBSD.org> <20130329235431.32D7FB82A@mail.bitblocks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130329235431.32D7FB82A@mail.bitblocks.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sat, 30 Mar 2013 09:14:34 -0700 (PDT) Cc: freebsd-net@freebsd.org, Carl Shapiro , Andriy Gapon , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 16:14:41 -0000 Bakul Shah wrote this message on Fri, Mar 29, 2013 at 16:54 -0700: > On Fri, 29 Mar 2013 14:30:59 PDT Carl Shapiro wrote: > > > > In other operating systems, such as Solaris and MacOS X, closing the > > descriptor causes blocked system calls to return with an error. > > What happens if you select() on a socket and another thread > closes this socket? Ideally select() should return (with > EINTR?) so that the blocking thread can some cleanup action. > And if you do that, the blocking accept() case is not really > different. > > There is no point in *not* telling blocking threads that the > descriptor they're waiting on is one EBADF and nothing is > going to happen. > > > It is not obvious whether there is any benefit to having the current > > blocking behaviour. > > This may need some new kernel code but IMHO this is worth fixing. As someone else pointed out in this thread, if a userland program depends upon this behavior, it has a race condition in it... Thread 1 Thread 2 Thread 3 enters routine to read enters routine to close calls close(3) open() returns 3 does read(3) for orignal fd How can the original threaded program ensure that thread 2 doesn't create a new fd in between? So even if you use a lock, this won't help, because as far as I know, there is no enter read and unlock mutex call yet... I decided long ago that this is only solvable by proper use of locking and ensuring that if you call close (the syscall), that you do not have any other thread that may use the fd. It's the close routine's (not syscall) function to make sure it locks out other threads and all other are out of the code path that will use the fd before it calls close.. If someone could describe how this new eject a person from read could be done in a race safe way, then I'd say go ahead w/ it... Otherwise we're just moving the race around, and letting people think that they have solved the problem when they haven't... I think I remeber another thread about this from a year or two ago, but I couldn't find it... If someone finds it, posting a link would be nice.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 30 16:55:26 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1D3AF5EF for ; Sat, 30 Mar 2013 16:55:26 +0000 (UTC) (envelope-from markd-freebsd-net@bushwire.net) Received: from smtp1.bushwire.net (f5.bushwire.net [199.48.133.46]) by mx1.freebsd.org (Postfix) with SMTP id E90AAD3 for ; Sat, 30 Mar 2013 16:55:25 +0000 (UTC) Received: (qmail 12681 invoked by uid 1001); 30 Mar 2013 16:48:03 -0000 Delivered-To: qmda-intercept-freebsd-hackers@freebsd.org DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=2004; d=bushwire.net; b=3IJ6OWc4TVBvKz6r35kPNDJrHdeaAiBcoNehaDN/D/As6rvzxr3z+YWNJKvx2RWa; Comments: DomainKeys? See http://en.wikipedia.org/wiki/DomainKeys DomainKey-Trace-MD: h=16; b=36; l=C18R71D32M65F45T27C51S48R42?69?46?38M17C39C27I50; Comments: QMDA 0.3 Received: (qmail 12657 invoked by uid 1001); 30 Mar 2013 16:48:03 -0000 Date: 30 Mar 2013 16:48:03 +0000 Message-ID: <20130330164803.12656.qmail@f5-external.bushwire.net> From: "Mark" To: freebsd-net@freebsd.org Subject: Re: close(2) while accept(2) is blocked References: <515475C7.6010404@FreeBSD.org> <20130329235431.32D7FB82A@mail.bitblocks.com> <20130330161434.GG76354@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130330161434.GG76354@funkthat.com> X-Mailman-Approved-At: Sat, 30 Mar 2013 17:05:09 +0000 Cc: FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 16:55:26 -0000 > As someone else pointed out in this thread, if a userland program > depends upon this behavior, it has a race condition in it... > > Thread 1 Thread 2 Thread 3 > enters routine to read > enters routine to close > calls close(3) > open() returns 3 > does read(3) for orignal fd > > How can the original threaded program ensure that thread 2 doesn't > create a new fd in between? So even if you use a lock, this won't > help, because as far as I know, there is no enter read and unlock > mutex call yet... > > I decided long ago that this is only solvable by proper use of locking > and ensuring that if you call close (the syscall), that you do not have > any other thread that may use the fd. It's the close routine's (not > syscall) function to make sure it locks out other threads and all other > are out of the code path that will use the fd before it calls close.. > > If someone could describe how this new eject a person from read could > be done in a race safe way, then I'd say go ahead w/ it... Otherwise > we're just moving the race around, and letting people think that they > have solved the problem when they haven't... Right. The only "safe" way is to have all blocking syscalls on the same fd in the same process return to userland. This would need to be initiated in the close() syscall. Btw. Threads aren't the only scenario. A signal handler can also close the fd. Maybe not advised, but I have used this "technique" to force a return from a blocking accept() call since about FBSD4.x Mark. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 30 19:43:06 2013 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A08428B; Sat, 30 Mar 2013 19:43:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) by mx1.freebsd.org (Postfix) with ESMTP id 5651A8A9; Sat, 30 Mar 2013 19:43:06 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7::e015:1126:f5aa:89a8] (unknown [IPv6:2001:7b8:3a7:0:e015:1126:f5aa:89a8]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 4E9165C44; Sat, 30 Mar 2013 20:42:59 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: clang: -mno-omit-leaf-frame-pointer From: Dimitry Andric In-Reply-To: <51569DFF.5080708@FreeBSD.org> Date: Sat, 30 Mar 2013 20:42:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0F14AC3C-6C38-4041-8775-F5E65C20EEB0@FreeBSD.org> References: <51569DFF.5080708@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.1503) Cc: freebsd-hackers@FreeBSD.org, toolchain@FreeBSD.org X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 19:43:06 -0000 On Mar 30, 2013, at 09:10, Andriy Gapon wrote: > It seems that, unlike gcc, for clang -fno-omit-frame-pointer does not = imply > -mno-omit-leaf-frame-pointer. This is probably a bug. Yes, this is indeed the case. There is even a rather old unresolved PR for it in LLVM's Bugzilla: http://llvm.org/bugs/show_bug.cgi?id=3D9825 > Meanwhile I would like to propose the following amd64-specific patch. = Perhaps > the same type of change would be useful for powerpc as well. Most likely yes. > I would like this change primarily for DTrace (fbt), but other > debugging/profiling code may benefit from it as well. >=20 > I chose to make -mno-omit-leaf-frame-pointer not conditional on clang, = because > with gcc it is just a nop (i.e. it doesn't hurt anything). The patch looks good to me, please commit. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 30 20:22:50 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EA21DAB1; Sat, 30 Mar 2013 20:22:50 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [173.228.5.8]) by mx1.freebsd.org (Postfix) with ESMTP id B9C15A0F; Sat, 30 Mar 2013 20:22:50 +0000 (UTC) Received: from bitblocks.com (localhost [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id F218BB82A; Sat, 30 Mar 2013 13:22:49 -0700 (PDT) To: John-Mark Gurney Subject: Re: close(2) while accept(2) is blocked In-reply-to: Your message of "Sat, 30 Mar 2013 09:14:34 PDT." <20130330161434.GG76354@funkthat.com> References: <515475C7.6010404@FreeBSD.org> <20130329235431.32D7FB82A@mail.bitblocks.com> <20130330161434.GG76354@funkthat.com> Comments: In-reply-to John-Mark Gurney message dated "Sat, 30 Mar 2013 09:14:34 -0700." Date: Sat, 30 Mar 2013 13:22:49 -0700 From: Bakul Shah Message-Id: <20130330202249.F218BB82A@mail.bitblocks.com> Cc: freebsd-net@freebsd.org, Carl Shapiro , Andriy Gapon , FreeBSD Hackers X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 20:22:51 -0000 On Sat, 30 Mar 2013 09:14:34 PDT John-Mark Gurney wrote: > > As someone else pointed out in this thread, if a userland program > depends upon this behavior, it has a race condition in it... > > Thread 1 Thread 2 Thread 3 > enters routine to read > enters routine to close > calls close(3) > open() returns 3 > does read(3) for orignal fd > > How can the original threaded program ensure that thread 2 doesn't > create a new fd in between? So even if you use a lock, this won't > help, because as far as I know, there is no enter read and unlock > mutex call yet... It is worse. Consider: fd = open(file,...); read(fd, ...); No guarantee read() gets data from the same opened file! Another thread could've come along, closed fd and pointed it to another file. So nothing is safe. Might as well stop using threads, right?! We are talking about cooperative threads where you don't have to assume the worst case. Here not being notified on a close event can complicate things. As an example, I have done something like this in the past: A frontend process validating TCP connections and then passing on valid TCP connections to another process for actual service (via sendmsg() over a unix domain). All the worker threads in service process can do a recvmsg() on the same fd. They process whatever tcp connection they get. Now what happens when the frontend process is restarted for some reason? All the worker threads need to eventually reconnect to a new unix domain posted by the new frontend process. You can handle this multiple ways but terminating all the blocking syscalls on the now invalid fd is the simplest solution from a user perspective. > I decided long ago that this is only solvable by proper use of locking > and ensuring that if you call close (the syscall), that you do not have > any other thread that may use the fd. It's the close routine's (not > syscall) function to make sure it locks out other threads and all other > are out of the code path that will use the fd before it calls close.. If you lock before close(), you have to lock before every other syscall on that fd. That complicates userland coding and slows down things when this can be handled more simply in the kernel. Another usecase is where N worker threads all accept() on the same fd. Single threading using a lock defeats any performance gain. > If someone could describe how this new eject a person from read could > be done in a race safe way, then I'd say go ahead w/ it... Otherwise > we're just moving the race around, and letting people think that they > have solved the problem when they haven't... In general it just makes sense to notify everyone waiting on something that the situation has changed and they are going to have to wait forever. The kernel should already have the necessary information about which threads are sleeping on a fd. Wake them all up. On being awakened they see that the fd is no longer valid and all return with a count of data already read or -1 and EBADF. Doing the equivalent in userland is complicated. Carl has pointed out how BSD and Linux have required a workaround compared to Solaris and OS X (in Java and IIRC, the Go runtime). Seems like we have a number of usecases and this is something worth fixing. From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 30 21:38:29 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 04207B2A for ; Sat, 30 Mar 2013 21:38:29 +0000 (UTC) (envelope-from mdf356@gmail.com) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by mx1.freebsd.org (Postfix) with ESMTP id C1793D6D for ; Sat, 30 Mar 2013 21:38:28 +0000 (UTC) Received: by mail-qa0-f44.google.com with SMTP id o13so380521qaj.17 for ; Sat, 30 Mar 2013 14:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=rFc0J7gvrcr4RLhy/VDJa/kWvPvymsY7XqG+kW4X48w=; b=J/T/aaBjNr8M4GZApLPRvXgXLoDBlZMO542ht4F8et8w3Zukd2dBtu9IVPsdm11kvO 7g7vUS3Atv1OTncxsmOXUlph54V1EflHGXm84D3+HlIgtMGB6nfa8csT4i8aNMhze8If XdNGCUOBD5cLs9Gvk7VZEImR95lum6WFjlEVdnfvq87H5GESaQ894OdlLbYqakLeGukM 2MeU98EaW+twqb9BMYkqpJPg+C52oj00RONe0ByyR2fkpjaWMaf44PsHOwAqDKhlbErF X5BuEQzb7qZKm11KKhs0vHE5ZH7TYC7O4ujKpBHpsais9xRoJZvu1uRRZtQbm4rla0Pf eiPw== MIME-Version: 1.0 X-Received: by 10.229.149.211 with SMTP id u19mr3012363qcv.13.1364679021572; Sat, 30 Mar 2013 14:30:21 -0700 (PDT) Sender: mdf356@gmail.com Received: by 10.229.253.201 with HTTP; Sat, 30 Mar 2013 14:30:21 -0700 (PDT) Date: Sat, 30 Mar 2013 14:30:21 -0700 X-Google-Sender-Auth: P1t7k1LC81SCPH_sZTJxlKxs3TQ Message-ID: Subject: extattr_set_* return type From: mdf@FreeBSD.org To: freebsd-hackers Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 21:38:29 -0000 Despite the man page correctly describing the return value for extattr_set_*, I thought recently that they returned 0/-1 for success/failure, not the number of bytes written, like write(2). This is because extattr_set_* is declared as returning an int, not an ssize_t. Both extattr_get and extattr_list return ssize_t, so this is inconsistent. The patch at http://people.freebsd.org/~mdf/0001-Fix-return-type-of-extattr_set_-and-fix-rmextattr-8-.patchfixes this. It compiles but it's untested. I don't think any compat shims are needed, since an old application will still sign extend and this will work (it's very unlikely anyone does extattr_set for 2GB or more). If anyone actually uses extattr on 64-bit, please test a new kernel but old userspace to be sure nothing is broken. I plan to commit this next week if I don't hear otherwise. Thanks, matthew