Re: ELF binary type "0" not known.
On Fri, Sep 16, 2005 at 11:56:09AM +, Wouter van Rooij wrote: > I have this error message when i'm wanting to start mozilla for example. Do > some of you know whats wrong and what I can do to get it working again? > > Wouter van Rooij Hey Wouter, you should have just asked me ;-) -Guido ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1->5.2
On Thu, Jan 15, 2004 at 05:04:59PM -0500, Robert Watson wrote: > > IPFILTER now relies on the PFIL_HOOKS kernel option; this is something > that is somewhat poorly documented, and we should add it to the errate I > suspect. If you add "options PFIL_HOOKS" to your kernel config, it should > work. Moving to PFIL_HOOKS for all the "funky IP input/ouput" feature is > a goal for 5.3 (in fact, I believe Sam has it almost entirely done in one > of his development branches), and should both simplify the input/output > paths, and also simplify locking for the IP stack. So the change is for a > good cause :-). > That reminds me: is there a way to influence the order in which the various packages are hooked up? E.g. I can imagine a situation where you want IPfilter NATting and ipfw filtering. In such a scenario you want to be able to specify _exactly_ that ipfilter comes before ipfw when packets come in, and vice versa when packets go out. -Guido ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: hosts_access(3) - correct usage?
On Wed, Oct 29, 2003 at 09:38:50AM -0500, Dan Langille wrote:
> Is this the right way to use hosts_access? The code blows up during
> the hosts_access call. I'm told it runs OK on Linux/Solaris. I'm
> wonderding if there's something different it needs to do be doing on
> FreeBSD.
>
> Thanks
>
> #ifdef HAVE_LIBWRAP
> P(mutex); /* hosts_access is not thread safe */
> request_init(&request, RQ_DAEMON, my_name, RQ_FILE, newsockfd,
> 0);
> fromhost(&request);
> if (!hosts_access(&request)) {
> V(mutex);
> Jmsg2(NULL, M_WARNING, 0, _("Connection from %s:%d refused
> by hosts.access"),
>inet_ntoa(cli_addr.sin_addr), ntohs(cli_addr.sin_port));
> close(newsockfd);
> continue;
> }
> V(mutex);
> #endif
This seems okay to me.
OpenSSH uses:
struct request_info req;
request_init(&req, RQ_DAEMON, __progname, RQ_FILE, sock_in, 0);
fromhost(&req);
if (!hosts_access(&req)) {
debug("Connection refused by tcp wrapper");
refuse(&req);
/* NOTREACHED */
fatal("libwrap refuse returns");
}
I take it that newsockfd is the one returned from accept()?
I'd try using a debug version of libwrap...
-Guido
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: magic symbolic links (ideas/patches?)
IIRC Willem-Jan Withagen has done this years ago. I Cc ed him. -Guido On Wed, Mar 12, 2003 at 07:39:52PM -0500, John wrote: > Hi Folks, > >I have a need to implement a highly specific variant usage of > what are commonly referred to as magic symlinks, ie: > >/src -> /.src/$ARCH/src > >where $ARCH needs to come from the user environment. > >A related patchset from NetBSD (1995) can be seen here: > > http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=1781 > >In my specific implementation, the value of $ARCH will ALWAYS > be 3 characters (Not having implemented anything yet, and to > avoid possibly playing the userland game, I was thinking of > adding a field to the proc structure and having the setenv/putenv > functions place the value there via a sysctl, thus allowing a > very simple interface... short sighted?). > >If anyone has any comments, or patches hanging around for > this type of implementation, I would appreciate a pointer to them. > > Many, Many Thanks, > John > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Guido van Rooij | Phone: ++31 653 994 773 Madison Gurkha, Technology Think-Tank | [EMAIL PROTECTED] | FreeBSD committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: umass driver speed
Was this ever committed? -Guido On Thu, Nov 28, 2002 at 01:53:26PM +0100, Nick Hibma wrote: > > Woohoo! Congrats. Nice job. If other people could test this, this should > be committed. I'll have to have a quick look at the initialisation code > that has been added to see whether there is no problem with that, but > from the quick glance I just had, I don't think there is a prolbem in > there. > > Nick > > > > > Bingo! :) > > > > When I changed the bsqh initialisation, I get speed above 400 KB/s, > > that makes me feel much better :) > > > > I am sending a corrected patch as attachment. > > > > Tomas > > > > On Thu, 28 Nov 2002, Ian Dowse wrote: > > > > > I had a quick look at the patch - one thing I noticed is that you > > > are possibly not initialising all of the bsqh fields. In -current, > > > bsqh->hlink and bsqh->qh.qh_hlink are set up to point at the `lsqh' > > > QH. It might not be the problem though. > > > > > > Ian > > > > > > > -- > [EMAIL PROTECTED] http://www.van-laarhoven.org/ > [EMAIL PROTECTED]http://www.etla.net/~n_hibma/ > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- Guido van Rooij | Phone: ++31 653 994 773 Madison Gurkha, Technology Think-Tank | [EMAIL PROTECTED] | FreeBSD committer To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
syscons dead key and X bug?
I loaded a keymap in syscons with some special chars, e.g. a modified us.iso.kbd like this: 041 dgra dtil nopnopdgra dtil nopnop O dgra '`' ( 'a' 224 ) ( 'A' 192 ) ( 'e' 232 ) ( 'E' 200 ) ( 'i' 236 ) ( 'I' 204 ) ( 'o' 242 ) ( 'O' 210 ) ( 'u' 249 ) ( 'U' 217 ) dtil '~' ( 'a' 227 ) ( 'A' 195 ) ( 'n' 241 ) ( 'N' 209 ) ( 'o' 245 ) ( 'O' 213 ) Now, when I start X after loading this keymap, the '`' and '~' no longer produce anything. If I reload the us.iso.kbd keymap and restart X, it works as expected. I take it that the above is a bug? -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
On Fri, Jan 04, 2002 at 03:11:45PM -0800, Terry Lambert wrote: > > I knew that I could multiply the number of packets sent by a > factor of 5... I was pointing out a flaw in the idea of allowing > path MTU ICMP back in, unconditionally... Thre is nothing 'unconditionally' in ipfilter. The IP packetheader and the first 8 bytes of the UDP/ICMP/TCP header are examined and checked if they match a valid state entry. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: path_mtu_discovery
On Fri, Jan 04, 2002 at 12:46:19PM -0800, Terry Lambert wrote: > William Carrel wrote: > > Blocking all ICMP is bad m'kay? > > First, I agree... > > > ipfilter with 'keep state' on the connections will automatically allow > > back in relevant ICMP messages such as mustfrag. > > Heh... I need to try to write a "mustfrag" daemon, which will > spoof them back whenever it sees traffic... and see what happens. > The sender will start sending smaller segments. That's it. But if you are in the patch between sender and receiver you can do worse things than that. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: review: single step thoruggh the probe messages
On Mon, Nov 26, 2001 at 12:36:01PM -0800, John Baldwin wrote: > > I would call the variable name 'console_pausing' or some such, rather than > cninit_notyetfinished to better explain what the variable does. > Ok, I also need to get rid of printf and directly write as to not interfere with dmesg output. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
review: single step thoruggh the probe messages
Attached some patches that add a -p functionality to the boot process.
If booting with -p, every line printed during probing happens only
after one presses a key.
This was usefull to see the probe messages of a system that completely
hung (read: no scroll-back functionslity left) after probing.
-Guido
--- sbin/reboot/boot_i386.8.origMon Nov 26 16:13:29 2001
+++ sbin/reboot/boot_i386.8 Sun Nov 25 16:46:57 2001
@@ -220,6 +220,8 @@
and
.Fl h
options are automatically set.
+.It Fl p
+pause after each attached device during the device probing phase.
.It Fl r
use the statically configured default for the device containing the
root file system
--- sys/boot/i386/libi386/bootinfo.c.orig Mon Nov 26 16:13:16 2001
+++ sys/boot/i386/libi386/bootinfo.cSat Nov 24 00:10:23 2001
@@ -97,6 +97,9 @@
case 'h':
howto |= RB_SERIAL;
break;
+ case 'p':
+ howto |= RB_PAUSE;
+ break;
case 'r':
howto |= RB_DFLTROOT;
break;
--- sys/sys/reboot.h.orig Mon Nov 26 16:13:05 2001
+++ sys/sys/reboot.hSat Nov 24 00:08:11 2001
@@ -61,6 +61,7 @@
#defineRB_GDB 0x8000 /* use GDB remote debugger instead of DDB */
#defineRB_MUTE 0x1 /* Come up with the console muted */
#defineRB_SELFTEST 0x2 /* don't boot to normal operation, do selftest
*/
+#defineRB_PAUSE0x4 /* pause after each line during autoconfig */
#defineRB_BOOTINFO 0x8000 /* have `struct bootinfo *' arg */
--- sys/kern/tty_cons.c.origMon Nov 26 16:12:31 2001
+++ sys/kern/tty_cons.c Mon Nov 26 15:58:30 2001
@@ -98,6 +98,7 @@
static d_close_t *cn_phys_close; /* physical device close function */
static d_open_t *cn_phys_open; /* physical device open function */
struct consdev *cn_tab; /* physical console device info */
+static u_char cninit_notyetfinished=1; /* zero if we left autoconfigure */
CONS_DRIVER(cons, NULL, NULL, NULL, NULL, NULL, NULL, NULL);
@@ -175,6 +176,7 @@
}
cn_dev_t = cn_tab->cn_dev;
cn_udev_t = dev2udev(cn_dev_t);
+ cninit_notyetfinished = 0;
}
static void
@@ -443,6 +445,12 @@
if (c == '\n')
(*cn_tab->cn_putc)(cn_tab->cn_dev, '\r');
(*cn_tab->cn_putc)(cn_tab->cn_dev, c);
+ if ((c == '\n') && (boothowto & RB_PAUSE) &&
+ (cninit_notyetfinished)) {
+ printf("\r");
+ (void)cngetc();
+ printf(" \r");
+ }
}
}
Re: buildworld breakage during "make depend" at usr.bin/kdump
On Thu, Nov 01, 2001 at 01:29:50PM +0100, Dag-Erling Smorgrav wrote:
> Guido van Rooij <[EMAIL PROTECTED]> writes:
> > May I aks which shell you are using?
>
> Zsh.
I am starting to wonder which sh is broken.
Btw there is a difference between sh and {t,}csh: in the sh case the newline
is replaced with 1 space. In the case of the 2 others, there are 2 spaces.
-Guido
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: buildworld breakage during "make depend" at usr.bin/kdump
On Thu, Nov 01, 2001 at 12:43:21PM +0100, Dag-Erling Smorgrav wrote: > "Eugene L. Vorokov" <[EMAIL PROTECTED]> writes: > > Uhmz ? > > Your shell is broken. > Just tried it with /bin/sh, /bin/csh and /bin/tcsh and they all remove the newlines. That is a lot of broken shells. May I aks which shell you are using? -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
make buildworld not selfcontained?
I have a system that is built with CPUTYPE=p2 When I set CPUTYPE to pentium and do a buildworld, I cannot use the obj tree to do an installworld on a pentium system. The reason being that the tools in usr/obj/usr/src/i386 are apparently built with libraries from the p2 system. I think that is broken. The reason seems to be that xinstall is built in the bootstrap-tools: target. But because it is used later on in installworld, it seems that it should be rebuild later. There does not seem to be a real solution for this problem.. I am not sure if xinstall is needed druing a make buildworld, but if not, the most easy would be to make it only in the installworld phase. But that would break installing from readonly mounts. Adding an explicit bootstrap-tools target to Makefile might also solve it.. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: grep memory footage
On Thu, Oct 04, 2001 at 11:49:49AM -0700, Mike Smith wrote: > > It's a known bug in grep; there are probably a bunch of PRs outstanding > on it. We need grep to be updated. > >From looking at the source, it seems that the lates version still seems to have the same problem. The problem seems to be in grep.c:grep(), where the variable save seems to ever increase. But the code is so amazingly hairy that I cannot figure out why. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
grep memory footage
When fgrepping a huge file (say 10GB) for a non-existing string, fgrep's memory size skyrockets. At a certain point in time its SIZE was 391M (RSS was about 30MB) and the system got rather unreponsive. The string was about 12 bytes big, and we fail to see why grep would need so much. Is there a good explanation for this? -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: panic in FFS and other related I/O problems
Shouldn't this be put in to an option so it gets documented?
-Guido
On Mon, Apr 02, 2001 at 09:12:53AM -0700, Peter Wemm wrote:
...
> diff -u -r1.4 ldscript.i386
> --- conf/ldscript.i3862000/01/11 15:35:16 1.4
> +++ conf/ldscript.i3862001/04/02 16:07:18
> @@ -6,7 +6,7 @@
> SECTIONS
> {
>/* Read-only sections, merged into text segment: */
> - . = 0xc010 + SIZEOF_HEADERS;
> + . = 0x8010 + SIZEOF_HEADERS;
>.interp : { *(.interp) }
>.hash : { *(.hash)}
>.dynsym: { *(.dynsym) }
> Index: i386/include/pmap.h
> ===
> RCS file: /home/ncvs/src/sys/i386/include/pmap.h,v
> retrieving revision 1.70
> diff -u -r1.70 pmap.h
> --- i386/include/pmap.h 2000/11/30 01:53:02 1.70
> +++ i386/include/pmap.h 2001/04/02 16:07:18
> @@ -92,9 +92,9 @@
> #endif
> #ifndef NKPDE
> #ifdef SMP
> -#define NKPDE254 /* addressable number of page
>tables/pde's */
> +#define NKPDE510 /* addressable number of page
>tables/pde's */
> #else
> -#define NKPDE255 /* addressable number of page
>tables/pde's */
> +#define NKPDE511 /* addressable number of page
>tables/pde's */
> #endif /* SMP */
> #endif
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: gdb question
On Wed, Jan 03, 2001 at 12:37:21PM -0500, Thierry wrote: > > Hi, > > I use the "fork" function to call another function "foo( )" > > In gdb, I would like to put a breakpoint in this function "foo( )", When I > execute, the function "foo( )" is stopped, but gdb doesn't give me the hand. > > How I can put a breakpoint in a function call by a "fork" system ? If you exec after the fork you could do it with: gdb --exec=program1 --symbols=program2 if program1 exec program2. if you only fork you can use the set follow_fork_mode setting to follow the child. Hmm no that I check it, it does not seem to work though I am using a 4.1 stablish system though. Perhaps it does work on later systems. -Guido -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: splFoo() question
On Sat, Mar 18, 2000 at 01:31:28PM -0700, Warner Losh wrote: > > I'd like to be able to do some simple spl locking in a driver that I'm > writing. While I could go the splhigh() route, I'm concerned that > spending lots of time at splhigh could cause problems, and some of my > critical sections look to be very expensive. They only need > protection against the card itself, not against the entire system. It > just seems to be an overly large hammer. > perhaps we need some mutex mechanism? -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPFW / IP Filter question
On Thu, Feb 03, 2000 at 11:28:49PM +0200, [EMAIL PROTECTED] wrote: > A quick question, is it possible to copy all traffic coming into a > particular interface to a divert socket, while still having the traffic > also running normally and taking normal routes etc. > > I would have thought you would use the tee option in ipfw for this, but > its not implemented yet according to my man pages, so I was wondering if > there was another way to do this, cause it makes traffic analysis a hell > of a lot easier if I can do this rather than having to sniff it with bpf > or something. I can;t answer this for ipfw (though IIRC there does exist a tee option in -current for ipfw). With ipfilter you can dup al traffic to an alternate device, like a tunnel device. e.g: pass in on lo0 dup-to tun0 from localhost to localhost or: pass in on lo0 dup-to ed0:1.2.3.4 from localhost to localhost where 1.2.3.4 is a machine on the same lan as ed0. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bug in vn, a pnaic and how to debug modules (was Re: open ref counts in CAM and vn)
On Thu, Feb 03, 2000 at 10:05:22AM -0700, Kenneth D. Merry wrote: > > The reference counting should be handled by PHK's disk layer (which sits > above CAM), and the da driver's close routine should only get called on > final close. ok. > > I don't know about the vn device, though. > That was the reason fro the posting. vnconfig -u goes directly to the vn device but that device has no track of open count. I don't see any code to notify the upper layer that the device is gove. That is wrong of course. In fact, one can vnconfig -u a device, while the device is used in a mount. The ufs layer doesn't even know that the device is gone and accessing the mount is still possible. Unmounting is not. So in this case, I guess vnconfig -u should fail. I think this is best achieved by using a ref counter in the vn device code. There is another bug in the vn code as well, which has tom do with modules. The following will panic on a page fault in vnsetcred (in the VOP_UNLOCK call): kldload vn vnconfig -c something vnconfig -u something kldunload vn kldload vn vnconfig -c something <--- instant panic I have not been able to debug this further, because it seems (but I have to recheck to be sure), that add-symbol-file /modules/vn does not allow one to look at variables delcared inside the vn module. Is there an easy way btw to determine ? I looked inside the debugger in the linker_files queue and then use the load address there, plus the start address of .text as found by objdump of the vn module. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
open ref counts in CAM and vn
A collegue fo mine had the problem that it was possible to vnconfig -u a vn device that was currently in use. This strikes me as odd. When looking through the da device code, I notice a similar problem. Suppose I have a zip fdisk mounted with a disklabel and 2 ufs partitions on it. When I mount both partitions, the disk will be locked. But it will be unlocked at the first unmount. I guess there should be a refcounter that keeps track of the amount of opens and only unlock devices at the last close. Same for vn.c. Any comments? -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
vaio z505sx and fxp suspend/resume problem
When I suspend and later resume a VAIO z505sx, the fxp interface seems not to be able to send out packets. Receiving goes okay (as tcpdump -n will actually dump all packets on the wire). No errors are reporteed on the interface (kernel or netstat -ni). Ifconfig-ing the interface down and up again does not seem to make a difference. It seems after 1-2 minutes the interface is okay again. The interface was both tried with mdia selection to auto and to UTP (both worked in the same way) Have others seen the same and is thyere a known fix? -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
booting from a second slice
what is the correct way (if at all) to boot off a second FreeBSD slice, given the following fdisk table (see below)? I thought that the three stage boot would make such a think possible. F2 in the boot manager does not work, but I would have thought that the loader would enable me to say currdev=disk1s2a: but an ls gives an error (lik unable to open xxx or something like that). I know about the 1024 cylinder limit, however I would expect loader to be able to work beyond that limit.. (btw: I take it that nextboot does not work with the btx stuff (couldn't locate any such stuff in the sources). If so, it should probably be removed in the i386 case (not in pc98 case though). fdisk table: *** Working on device /dev/rwd0 *** parameters extracted from in-core disklabel are: cylinders=12595 heads=16 sectors/track=63 (1008 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=12595 heads=16 sectors/track=63 (1008 blks/cyl) Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 63, size 3071313 (1499 Meg), flag 80 (active) beg: cyl 0/ sector 1/ head 1; end: cyl 1023/ sector 63/ head 15 The data for partition 2 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 3071376, size 3071376 (1499 Meg), flag 0 beg: cyl 1023/ sector 63/ head 255; end: cyl 1023/ sector 63/ head 15 The data for partition 3 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 6142752, size 3071376 (1499 Meg), flag 0 beg: cyl 1023/ sector 63/ head 255; end: cyl 1023/ sector 63/ head 15 The data for partition 4 is: sysid 165,(FreeBSD/NetBSD/386BSD) start 9214128, size 3481632 (1700 Meg), flag 0 beg: cyl 1023/ sector 63/ head 255; end: cyl 1023/ sector 63/ head 15 -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ipfilter volunteer
I'd like to volunteer to maintain ipfilter. I already told several people at the usenix conference, but as I have seen others taking interest as well, it seems right to at least spread it more publicly. I am still waiting for a machine I won at the conference to start on it though so it might take some weeks before seeing some action. Current plans are to import a more recent version of ipfilter followed by having a look at features implemented by ipfw that are currently missing in ipfilter. -Guido To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ipfilter volunteer
I'd like to volunteer to maintain ipfilter. I already told several people at the usenix conference, but as I have seen others taking interest as well, it seems right to at least spread it more publicly. I am still waiting for a machine I won at the conference to start on it though so it might take some weeks before seeing some action. Current plans are to import a more recent version of ipfilter followed by having a look at features implemented by ipfw that are currently missing in ipfilter. -Guido To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: inetd+libwrap and wrapping UDP services
On Tue, Jun 15, 1999 at 08:07:02PM +0200, Sheldon Hearn wrote: > > > On Tue, 15 Jun 1999 20:05:10 +0200, Guido van Rooij wrote: > > > And when you fix that, the wrapper stuff gets invoked for every > > packet... > > Even worse than I anticipated. :-) > > So then we just note in the manpage that only TCP-based services are > wrapped? Hmmm..I would just enable the UDP stuff. It is a policy issue, so why not at least giving the functionality. I woul however note in the manpage what the consequences are for nowait UDP services. While you're at it, I'd alos mention what the consequence of the wait option is (i.e. wrapper only for the starting connection). -Guido To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: D'oh!
On Tue, Jun 15, 1999 at 10:37:18AM -0700, Matthew Dillon wrote:
>
> Sounds good to me! If someone on -hackers has easy access to the OpenBSD
> source, it would be nice if he could check whether the OpenBSD code
> has the same problem and notify the OpenBSD folks if it does.
they dont seem to have the nfs_node_hash_lock at all.
Our code in nfs_nget():
loop:
for (np = nhpp->lh_first; np != 0; np = np->n_hash.le_next) {
if (mntp != NFSTOV(np)->v_mount || np->n_fhsize != fhsize ||
bcmp((caddr_t)fhp, (caddr_t)np->n_fhp, fhsize))
continue;
vp = NFSTOV(np);
if (vget(vp, 1))
goto loop;
*npp = np;
return(0);
}
/*
* Obtain a lock to prevent a race condition if the getnewvnode()
* or MALLOC() below happens to block.
*/
if (nfs_node_hash_lock) {
while (nfs_node_hash_lock) {
nfs_node_hash_lock = -1;
tsleep(&nfs_node_hash_lock, PVM, "nfsngt", 0);
}
nfs_node_hash_lock = 1;
/*
* Do the MALLOC before the getnewvnode since doing so afterward
* might cause a bogus v_data pointer to get dereferenced
* elsewhere if MALLOC should block.
*/
MALLOC(np, struct nfsnode *, sizeof *np, M_NFSNODE, M_WAITOK);
error = getnewvnode(VT_NFS, mntp, nfsv2_vnodeop_p, &nvp);
Their code:
loop:
for (np = nhpp->lh_first; np != 0; np = np->n_hash.le_next) {
if (mntp != NFSTOV(np)->v_mount || np->n_fhsize != fhsize ||
bcmp((caddr_t)fhp, (caddr_t)np->n_fhp, fhsize))
continue;
vp = NFSTOV(np);
if (vget(vp, LK_EXCLUSIVE, p))
goto loop;
*npp = np;
return(0);
}
error = getnewvnode(VT_NFS, mntp, nfsv2_vnodeop_p, &nvp);
if (error) {
*npp = 0;
return (error);
}
vp = nvp;
MALLOC(np, struct nfsnode *, sizeof *np, M_NFSNODE, M_WAITOK);
I have not checked if they have fixed this otherwise though.
-Guido
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
Re: inetd+libwrap and wrapping UDP services
On Tue, Jun 15, 1999 at 08:01:55PM +0200, Sheldon Hearn wrote: > > Hi folks, > > The patches on PR 12097 that deal with fixing inetd's handling of > tcp_wrapper support do _not_ enable wrapping of UDP services. David > Malone and I are busy working on a patch for doing so, but I have a > question that I probably should have asked when we started. > > Is there any point in wrapping UDP services (identified as "dgram udp" > services in inetd.conf)? Since they're all single-threaded, using the > wait option, any successful connection opens up a rolling period during > which any further connections will not be wrapped (hence the word > rolling). > And when you fix that, the wrapper stuff gets invoked for every packet... -Guido To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: USENIX FreeBSD Dinner
I dont realy care ;-) -Guido To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
