Re: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode

On 13 Jun 2016, at 12:09, Joel Dahl wrote: > >> On Mon, Jun 13, 2016 at 07:00:46AM -0400, Ngie Cooper (yaneurabeya) wrote: >> >>> On Jun 13, 2016, at 06:57, Joel Dahl wrote: >>> >>> Hi, >>> >>> I've just rebuilt and installed latest current on a machine here. I

Re: panic: rm_rlock: recursed on non-recursive rmlock mac_policy_rm @ /usr/src/sys/security/mac/mac_framework.c:198

On 28 Sep 2013, at 19:32, Konstantin Belousov wrote: It easy to reproduce. Just kldload mac_portacl and /etc/rc.d/syslogd restart This is due to priv_check_cred() call in mac_portacl.c:rules_check(). The call causes recusion into the mac framework from the mac callback. Robert should

Re: [rfc] migrate lagg to an rmlock

On 24 Aug 2013, at 17:36, Alfred Perlstein wrote: We should distinguish lock contention from line contention. When acquiring a rwlock on multiple CPUs concurrently, the cache lines used to implement the lock are contended, as they must bounce between caches via the cache coherence

Re: A PRIV_* flag for /dev/mem?

On 16 Jun 2013, at 23:48, Kirk McKusick wrote: I suppose it's safe to say further comment isn't forthcoming. So with one vote for and one against (or at least questioning), I'll humbly leave it up to myself to be the tie-breaker :-). Here's a proposed patch. I separate kmem access into

Re: panic: in_pcblookup_local (?)

On 2 May 2013, at 01:57, Glen Barber wrote: So, I am admittedly not too familiar with DDB. In fact, I just now realize the kernel is built without DDB... DDB is a very powerful tool in that it's been custom-developed to help debug common kernel panics. It lacks some of the flexibility, and

Re: panic: in_pcblookup_local (?)

On 2 May 2013, at 11:42, Glen Barber wrote: Hmm. Perhaps it would be worthwhile for me to rebuild the current kernel with DDB support. It looks like the machine has panicked a few times over the last two weeks or so, but based on the timestamps of the crash dumps and nagios complaints,

Re: panic: in_pcblookup_local (?)

On 1 May 2013, at 16:56, John Baldwin wrote: It looks like the ipi_hash_lock is locked (and udp_connect() locks it), so I think the offending code is somewhere else. Also, I can't find anything that removes an inp without hold the correct pcbinfo lock. Only thing I can think of is if the

Re: panic: in_pcblookup_local (?)

On 1 May 2013, at 19:03, Glen Barber wrote: I'll need to catch up on this thread later, but a few questions: Do we know if the application in question is multithreaded, and if so, might it be attempting concurrent operations on this socket? I do not know if zabbix-agent is multithreaded,

Re: please add auditdistd user/group to -stable and the 9.1-release?

My intuition (hope) is that 9.1 is past the point of no return on builds and so that boat has been missed; however, my plan is to MFC the auditdistd user to stable/8 and stable/9 after the 3-day MFC timeout. If Ken thinks builds have yet to start on the final 9.1 image, however, then I'm happy

Re: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd))

On 2 Dec 2012, at 14:21, Fbsd8 wrote: I've now committed the build glue required to install the recently merged Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and sponsored by the FreeBSD Foundation. This allows individual hosts generating audit trails to submit

Re: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd))

On 2 Dec 2012, at 15:34, Ryan Stone wrote: On Sun, Dec 2, 2012 at 8:05 AM, Robert Watson rwat...@freebsd.org wrote: Just to follow up on this thread, since the question has come up a number of times. mergemaser -p should be run prior to installworld always, but most of the time will do

Re: sysctl filesystem ?

On 26 Jun 2012, at 15:42, m...@freebsd.org wrote: While I understand the problems you allude to, the sysctl(8) binary can protect itself from them. IMO the biggest problem with sysctls not being files is that it makes no sense from the core UNIX philosophy that everything is a file.

Re: extattr_set_*() return type

On 21 Dec 2011, at 15:31, John Baldwin wrote: On Tuesday, December 20, 2011 5:18:58 pm m...@freebsd.org wrote: On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin j...@freebsd.org wrote: Hmm, if these functions are expected to operate like 'write(2)' and are supposed to return the number of bytes

Re: [poll / rfc] kdb_stop_cpus

On 4 Jun 2011, at 09:22, Andriy Gapon wrote: on 03/06/2011 20:57 Robert N. M. Watson said the following: On 3 Jun 2011, at 16:13, Andriy Gapon wrote: I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes, I am very interested to learn about your usecase

Divert socket problem (was: Re: svn commit: r222488 - in head/sys: contrib/pf/net netinet netinet/ipfw netinet6)

On 4 Jun 2011, at 15:30, Kristof Provost wrote: div_bind probably also needs to surround the call to in_pcbbind with INP_HASHW(UN)LOCK(...) I'm currently running 222680. I've only now seen the issue, but I've also just now activated INVARIANTS. Hi Kristof: Thanks for the detailed report,

Re: [poll / rfc] kdb_stop_cpus

On 3 Jun 2011, at 16:13, Andriy Gapon wrote: I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes, I am very interested to learn about your usecase for it. The issue that prompted the sysctl was non-NMI IPIs being used to enter the debugger or reboot following a core

Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)

On 6 Mar 2011, at 16:30, Jeremy Chadwick wrote: 2. Are you absolutely 100% sure the kernel you're using was built with options UFS_ACL defined in it? Doing a strings -a /boot/kernel/kernel | grep UFS_ACL should suffice. Yep, it does: % strings -a /boot/kernel/kernel | grep

Re: www/chromium crashing whole system

On 15 Nov 2010, at 22:19, Alexander Best wrote: thanks for all your help. i've recently switched to chromium 6.0.472.63 and so far my computer has been very stable. if i experience more lock ups i'll let you know and try to figure out a way to gain access to some more debugging data. I'd

Re: [PATCH] Netdump for review and testing -- preliminary version

On 15 Oct 2010, at 20:39, Garrett Cooper wrote: But there are already some cases that aren't properly handled today in the ddb area dealing with dumping that aren't handled properly. Take for instance the following two scenarios: 1. Call doadump twice from the debugger. 2. Call doadump,

Re: [PATCH] Netdump for review and testing -- preliminary version

On 13 Oct 2010, at 18:46, Ryan Stone wrote: On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson rwat...@freebsd.org wrote: + /* +* get and fill a header mbuf, then chain data as an extended +* mbuf. +*/ + MGETHDR(m,

Re: [PATCH] Netdump for review and testing -- preliminary version

On 14 Oct 2010, at 15:10, Attilio Rao wrote: My concern is less about occasional lost dumps that destabilising the dumping process: calls into the memory allocator can currently trigger a lot of interesting behaviours, such as further calls back into the VM system, which can then trigger

Re: sysctls in kern_shutdown: add twin tunables

On 30 Sep 2010, at 19:19, Andriy Gapon wrote: http://people.freebsd.org/~avg/kern_shutdown-tunables.diff The above patch adds twin tunables for the following (R/W) sysctls: - debug.debugger_on_panic - debug.trace_on_panic - kern.sync_on_panic This seems useful to me, but I am not sure

Re: MAXCPU preparations

On 29 Sep 2010, at 12:49, John Baldwin wrote: On Tuesday, September 28, 2010 6:24:32 pm Robert N. M. Watson wrote: On 28 Sep 2010, at 19:40, Sean Bruno wrote: If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus. I assume that mp_maxid is the new kern.smp.maxcpus

Re: MAXCPU preparations

On 28 Sep 2010, at 17:45, Sean Bruno wrote: Working on a dynamic version today. I'll spam it over to you for review later. I'm moving the percpu struct definitions outside of struct memory_type, allocating quantity kern.smp.maxcpus, removing the boundary checks based on MEMSTAT_MAXCPU

Re: MAXCPU preparations

On 28 Sep 2010, at 19:40, Sean Bruno wrote: If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus. I assume that mp_maxid is the new kern.smp.maxcpus? Can you inject some history here so I can understand why one is better than the other? So, unlike maxcpus, mp_maxid is

Re: AppleTalk status

On 25 May 2010, at 14:13, Nathan Whitehorn wrote: I'm working on updating net/netatalk to version 2.1 (or 2.1.1 when that comes out the next couple of days), and I'm wondering what state AppleTalk support is in these days. Is anybody still using it, or would now be the time to make all

Re: AppleTalk status

On 25 May 2010, at 17:48, Julian Elischer wrote: I'm working on updating net/netatalk to version 2.1 (or 2.1.1 when that comes out the next couple of days), and I'm wondering what state AppleTalk support is in these days. Is anybody still using it, or would now be the time to make all

Re: GrandCentralDispatch in FreeBSD?

On 13 May 2010, at 10:21, Tom Evans wrote: I saw today that you've written a proof of concept MPM for apache in GCD [1] - are there any plans to port GCD to FreeBSD? Hi Tom-- Actually, I also ported GCD to FreeBSD last year, and developed the MPM on FreeBSD/GCD :-). It requires a post-8.0

Re: net.inet.tcp.timer_race: does anyone have a non-zero value?

On Mar 7, 2010, at 12:33 PM, Mikolaj Golub wrote: On Sun, 7 Mar 2010 11:59:35 + (GMT) Robert Watson wrote: Please check the results of the following command: % sysctl net.inet.tcp.timer_race net.inet.tcp.timer_race: 0 Are the results for FreeBSD7 look interesting for you?