Date: Sat, 30 Aug 2003 10:57:07 -0400 (EDT) From: Robert Watson <rwatson@freebsd.org> To: Kenneth Culver <culverk@yumyumyum.org> Cc: freebsd-ports@freebsd.org Subject: Re: 2 ports broken after gcc import Message-ID: <Pine.NEB.3.96L.1030830105202.47993M-100000@fledge.watson.org> In-Reply-To: <20030829235521.T25083@alpha.yumyumyum.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 29 Aug 2003, Kenneth Culver wrote: > > Might devfs propagate ACL characteristics via /dev nodes into > > applications? Otherwise, the symptom you described would have made me > > point to the IP firewall first. > > My machine that was showing the problem didn't have a firewall enabled. > I'll still mess with it some more to see what I can come up with, maybe > it was the firewall, but I don't remember having ipfilter or ipfirewall > in the kernel but it'd been a while since I edited that config file or > compiled that kernel so maybe I took out the firewall options and never > compiled, and then compiled today. (It's been about a month since I did > anything kernel related on that machine). Anyway, when I pinpoint the > problem I'll mail the list. I think I missed the message that this is a response to, but here's an answer to the question: UFS_ACL controls only the introduction of ACL code into UFS1 and UFS2 file systems, and enables conditional use of ACLs code if the ACLs flag is set on a file system. If the ACLs flag is not set on a file system, the UFS1/UFS2 code is intended to run along its original permissions-based code path. Devfs isn't based on UFS, and so it should be unaffected by the UFS_ACL flag. If there's a definite causal relationship between UFS_ACL and the nmap failure, I can't help but wonder if it's a result of a timing, code layout, or memory allocation change of some sort. I wouldn't rule out a bug in the ACL code, but it seems somewhat unlikely as, without the ACLs flag set, the code path in the UFS code should be minimally changed... The best path to track this down is to try to figure out for sure which system call is failing, compare expected vs. wire network transmissions, and see if we can reproduce this in a simpler test program. We've recently made some changes in how the permissions of new objects are calculated using ACLs; they were made somewhat before the gcc changes, I believe, but it might also be interesting to see test cases from before both changes, in between the changes, and after both, to confirm that it was definitely the gcc change that kicked off the problem, rather than the UFS change. Finally, I'd like to know what, if any, optimization flags you're using for the kernel compile... Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030830105202.47993M-100000>