Date: Sat, 30 Aug 2003 12:22:02 -0400 (EDT) From: Kenneth Culver <culverk@yumyumyum.org> To: Robert Watson <rwatson@freebsd.org> Cc: freebsd-ports@freebsd.org Subject: Re: 2 ports broken after gcc import Message-ID: <20030830121939.E28935@alpha.yumyumyum.org> In-Reply-To: <Pine.NEB.3.96L.1030830105202.47993M-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1030830105202.47993M-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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... > Well, don't worry too much, I went back and checked the kernel config I used for the kernel that was having problems, and it did indeed have IPFILTER compiled in, BUT I had no rules loading. Both of the rules files were empty. (That's basically what I said in my previous message). I just took me the better part of a night to sort out what I had on that box and remember what I did. Anyway, like I said, I won't be back on that box until Tuesday so I'll have to let you know which knob I turned then... although if it WAS the firewall that's really wierd since I had no rules loaded, and my other box that never had the problem DID have rules loaded. Ken
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030830121939.E28935>