Problem patching libc
Hi hackers, I saw the security-advisory about globbing vulnerability in ftpd and I tryed to patch my FreeBSD 4.0, but I got an error: /usr/src/lib/libc/../libc/gen/glob.c: In function `glob': /usr/src/lib/libc/../libc/gen/glob.c:171: `GLOB_MAXPATH' undeclared and the next /usr/src/lib/libc/../libc/gen/glob.c: In function `globextend': /usr/src/lib/libc/../libc/gen/glob.c:689: `GLOB_LIMIT' undeclared I think the patch is not correct or I'm wrong? Vladimir To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
In message <[EMAIL PROTECTED]>, Kirk McKusick writes: >Every vnode in the system has an associated object. No: device vnodes dont... I think the correct solution to that is to move devices away from vnodes and into the fdesc layer, just like fifo's and sockets. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: x86-64 Hammer and IA64 Itainium
On Tue, 17 Apr 2001, Jeremiah Gowdy wrote: > I'm not talking about joining the x86-64 project, otherwise I'd be mailing > them. I'm talking about FreeBSD using the gcc x86-64 compiler to port > FreeBSD to x86-64. I have a copy of the AMD x86-64 spec, mailed to me by > AMD (also available on their page in PDF), and there's no NDA with it. It's > public data. And the source code for the x86-64/Linux/GNU project is public > (GPL). I'm talking about a FreeBSD project to port to x86-64. I think a port to x86-64 is an excellent idea, but I also think that you're worrying about it too far in advance. As you say, the x86-64 project is working on getting gcc ported, which is important chunk of work. As such, it's probably best to not worry about a FreeBSD port until after they're done and have linux up and running on the processors. Once that's done, it'll probably be a matter to send a clawhammer system and a large box of cheese and crackers to the guys who did the freebsd alpha port. If the architecture is actually so similar to x86, it should only take them a few weekends. :) (Alternative options include Matt Dillon splurge-buying a clawhammer system at CompUSA and doing the port himself... the likelihood of such a plan seems to hinge on how much free time he has, though. Maybe send him cheese, crackers, and a CompUSA ad to help the process along.) Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
Date: Tue, 17 Apr 2001 09:49:54 -0400 (EDT) From: Robert Watson <[EMAIL PROTECTED]> To: Kirk McKusick <[EMAIL PROTECTED]> cc: Julian Elischer <[EMAIL PROTECTED]>, Rik van Riel <[EMAIL PROTECTED]>, [EMAIL PROTECTED], Matt Dillon <[EMAIL PROTECTED]>, David Xu <[EMAIL PROTECTED]> Subject: Re: vm balance On Mon, 16 Apr 2001, Kirk McKusick wrote: > I am still of the opinion that merging VM objects and vnodes would be a > good idea. Although it would touch a huge number of lines of code, when > the dust settled, it would simplify some nasty bits of the system. This > merger is really independent of making the number of vnodes dynamic. > Under the old name cache implementation, decreasing the number of vnodes > was slow and hard. With the current name cache implementation, > decreasing the number of vnodes would be easy. I concur that adding a > dynamically sized vnode cache would help performance on some workloads. I'm interested in this idea, although profess a gaping blind spot in expertise in the area of the VM system. However, one of the aspects of our VFS that has always concerned me is that use of a single vnode simplelock funnels most of the relevant (and performance-sensitive) calls. The result is that all accesses to an object represented by a vnode are serialized, which can represent a substantial performance hit for applications such as databases, where simultaneous write would be advantageous, or for various vn-backed oddities (possibly including vnode-backed swap?). At some point, apparently an effort was made to mark up vnode_if.src with possible alternative locking using read/write locks, but given that all the consumers use exclusive locks right now, I assume that was not followed through on. A large part of the cost is mitigated through caching on the under-side of VFS, allowing vnode operations to return rapidly, but while this catches a number of common cases (where the file is already in the cache), there are sufficient non-common cases that I would anticipate this being a problem. Are there any performance figures available that either confirm this concern, or demonstrate that in fact it is not relevant? :-) Would this concern introduce additional funneling in the VM system, or is the granularity of locks in the VM sufficiently low that it might improve performance by combining existing broad locks? Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services Every vnode in the system has an associated object. Every object backed by a file (e.g., everything but anonymous objects) has an associated vnode. So, the performance of one is pretty tied to the performance of the other. Matt is right that the VM does locking on a page level, but then has to get a lock on the associated vnode to do a read or a write, so really is pretty tied to the vnode lock performance. Merging the two data structures is not likely to change the performance characteristics of the system for either better or worse. But it will save a lot of headaches having to do with lock ordering that we have to deal with at the moment. Kirk McKusick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: x86-64 Hammer and IA64 Itainium
On Tue, Apr 17, 2001 at 12:49:04PM -0700, Jeremiah Gowdy wrote: > I would love to see FreeBSD running natively (64bit) under the x86-64 > architecture, and unlike the Itainium, it's differences with x86-32 > seem to be few (of course). > Porting FreeBSD to Itainium would/will/could be a much much larger > project than the port to x86-64. First things first... paragraphs would be nice. Large chunks of words are hard to read. Second, it is this difference from x86 that I think is justification enough to focus on Itanium rather than x86-64. I'm not sure exactly how x86-64 works, but it seems to me that it's simply the standard x86 architecture expanded to 64 bits. Isn't time we kill the x86? It's been around too long. I'm not sure how the Itanium looks, and I'm no Intel freak, but a change would be nice. We should begin moving in the direction of RISC (or at least VLIW). There's a reason every other processor has a radically different architecture. Motorola, Sun and Digital all broke new ground with their processors, because the x86 doesn't amount to all that much any more. Remember, this technology was designed for 20-year old computers. You can probably tell I'm not one to say, "If it ain't broke, don't fix it." My general attitude is that even if it works great, new possibilities should be explored if they promise something better. Now is our chance. Focus main development on Alpha and Itanium (ideally, major focus should be put on UltraSPARC and PPC, too), and leave the x86-64 porting to people who actually care. -- Andrew Hesford [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shoutcast, high cpu, threads
void wrote: > > The man pages say: > > sleep - suspend process execution for an interval measured in seconds > usleep - suspend process execution for an interval measured in microseconds > > Maybe he's using the wrong routine? > The FreeBSD manpages don't appear to comment on this matter, but usleep() isn't thread safe on all platforms. -- - Justin Wojdacki [EMAIL PROTECTED] (408) 350-5032 Communications Processors Group -- Analog Devices To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Shoutcast, high cpu, threads
On Tue, Apr 17, 2001 at 01:47:11AM -0400, Charles Sprickman wrote: > Hi, > > I'm running shoutcast on a 4.2R machine, and I'm finding that the > shoutcast server, when idle climbs up to around 90% cpu usage. Included > is a bit of back-and-forth with a shoutcast support person. > > I'm not too clear on what he's talking about, is there any information I > can pass on to him to help debug this? While I will take his suggestion > on increasing the sleep time, I don't want to push it too far or I may end > up with a "stuttering" server. > > Thanks, > > Charles > > -- Forwarded message -- > Date: Mon, 16 Apr 2001 10:27:33 -0700 > From: Tom Pepper <[EMAIL PROTECTED]> > To: Charles Sprickman <[EMAIL PROTECTED]> > Subject: Re: high cpu usage > > keep going up. your machine is fast enough that values as high as 10,000 > may show improvement. > > you're seeing this problem because freebsd is the only o/s i know of that > ignores sleep values with very small microsecond values. The man pages say: sleep - suspend process execution for an interval measured in seconds usleep - suspend process execution for an interval measured in microseconds Maybe he's using the wrong routine? -- Ben "I told Paddy no, I told Steve no, I told Paul no, and Ben fell asleep." --Kate C. (no, different Ben, I would have stayed up) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Problems with German Keyboard
On Tue, Apr 17, 2001 at 12:56:23PM +0200, [EMAIL PROTECTED] wrote: > I´ve troubles getting german "umlauts" to work properly. I played around This should have gone to -questions or to one of the German lists. Have a look at http://www.de.freebsd.org/de/umlaute/umlaute.html HTH, Harold To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
:>reference to me. I'm not even sure why they bother to check v_id. :>The vp reference from an nfsnode is a hard reference. :> : :Well, if that's the case, yank all uses of v_id from the nfs code, :I'll do the namecache and vnodes can be deleted to the joy of our users... : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 :[EMAIL PROTECTED] | TCP/IP since RFC 956 If you can yank v_id out from the kern/vfs_cache code, I will make similar fixes to the NFS code. I am not particularly interesting in returning vnodes to the MALLOC pool myself, but I am interested in fixing the two bugs I noticed when I ran over the code earlier today. Actually one bug. The vput() turns out to be correct, I just looked at the code again. However, the cache_lookup() call in nfs_vnops.c is broken. Assuming no other fixes, the vpid load needs to occur before the VOP_ACCESS call rather then after. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: x86-64 Hammer and IA64 Itainium
> I would like to see this too, however I think you have to sign NDA's and > the like to be a part of the AMD effort to develop for it. Understandable > I guess. Also they only seem interested in boosting Linux adoption of the > new AMD 64 bit procs. *shrug* I'm not talking about joining the x86-64 project, otherwise I'd be mailing them. I'm talking about FreeBSD using the gcc x86-64 compiler to port FreeBSD to x86-64. I have a copy of the AMD x86-64 spec, mailed to me by AMD (also available on their page in PDF), and there's no NDA with it. It's public data. And the source code for the x86-64/Linux/GNU project is public (GPL). I'm talking about a FreeBSD project to port to x86-64. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
In message <[EMAIL PROTECTED]>, Matt Dillon writes: > >: >:In message <[EMAIL PROTECTED]>, Matt Dillon writes: >:> >:>:In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: >:>: >:>:>I thought vnodes were in stable storage? >:>: >:>:They are, that's the point Matt is not seeing yet. >:> >:>I know vnodes are in stable storage. I'm just saying that NFS >:>is the least of your worries in trying to change that. >: >:The namecache can do without the use of soft references. >: >:The only reason vnodes are stable storage any more is that NFS >:uses soft references to vnodes. > >The only place I see soft references on vnode is in the NFS >lookup code which duplicates the VFS lookup code (except gets it wrong). >If you are refering to the nqlease code... that looks like a hard >reference to me. I'm not even sure why they bother to check v_id. >The vp reference from an nfsnode is a hard reference. > Well, if that's the case, yank all uses of v_id from the nfs code, I'll do the namecache and vnodes can be deleted to the joy of our users... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
: :In message <[EMAIL PROTECTED]>, Matt Dillon writes: :> :>:In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: :>: :>:>I thought vnodes were in stable storage? :>: :>:They are, that's the point Matt is not seeing yet. :> :>I know vnodes are in stable storage. I'm just saying that NFS :>is the least of your worries in trying to change that. : :The namecache can do without the use of soft references. : :The only reason vnodes are stable storage any more is that NFS :uses soft references to vnodes. The only place I see soft references on vnode is in the NFS lookup code which duplicates the VFS lookup code (except gets it wrong). If you are refering to the nqlease code... that looks like a hard reference to me. I'm not even sure why they bother to check v_id. The vp reference from an nfsnode is a hard reference. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
BAD BUG: Second try
Oops.
NOTE: I don't follow this lists for weeks at a time, so please
include me directly in any responses. Thanks.
Matt Dillon was looking at this, but I haven't heard from him
for a while on it.
Here is a patch to make it panic, instead of really, really
trashing memory (ignore the version, I'm using a vendor import
locally); the patch is to "crfree() and should be obvious:
===
diff -c -r1.2 kern_prot.c
*** kern/kern_prot.c2001/03/21 02:33:03 1.2
--- kern/kern_prot.c2001/04/17 02:22:48
***
*** 1001,1006
--- 1001,1009
int s;
s = splhigh();
+ if ( cr->cr_ref == 0) {
+ panic("Freeing already free credential!\n");
+ }
if (--cr->cr_ref == 0) {
/*
* Some callers of crget(), such as nfs_statfs(),
===
Unfortunately, There's also a nameidata structure (it's the
only data structure that's exactly 72 bytes long, which I was
able to determine by printing sizeof() information for all
kernel structures, and gre'ping for "72") getting freed and
then either continued to be used, or being used as a result
of an unchecked allocation failure (I'm still looking for
that one).
Basically, the second causes invariants to whine about data
modified on the freelist to my console, while the first one
results in an eventual panic dues to spammed memory (for the
obvious reason that you can't free the same thing twice).
The problems only become obvious when you open and then close
around 30,000 TCP connections; sometimes it takes a couple of
tries before it panics your machine.
I have some programs that demonstrate the bug, if anyone is
interested in repeating it on their machines locally (you will
need appropriate open file limits and bump up to 40,000 or so
net.inet.ip.portrange.last, e.g.:
sysctl -w net.inet.ip.portrange.last=45000
Which means your box will need about a gig of memory.
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to make snp(4) devfs-friendly
In message <[EMAIL PROTECTED]>, Dima Dorfman write s: >Brian Somers <[EMAIL PROTECTED]> writes: >> This looks good. I'd say you should commit the change yourself - >> feel free to say it's reviewed by me. > >I'm not a src/ committer.. :-/ If you have a "reviewed by" an old hand like Brian, then it is OK for you to commit it yourself. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
In message <[EMAIL PROTECTED]>, Matt Dillon writes: > >:In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: >: >:>I thought vnodes were in stable storage? >: >:They are, that's the point Matt is not seeing yet. > >I know vnodes are in stable storage. I'm just saying that NFS >is the least of your worries in trying to change that. The namecache can do without the use of soft references. The only reason vnodes are stable storage any more is that NFS uses soft references to vnodes. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to make snp(4) devfs-friendly
Brian Somers <[EMAIL PROTECTED]> writes: > This looks good. I'd say you should commit the change yourself - > feel free to say it's reviewed by me. I'm not a src/ committer.. :-/ > As an aside, when I did this to if_tun, I chose to do all the > destroy_dev()s at module unload time (I guess the snp device could do > with a MODULE_DECLARE). This allows the administrator to relax the The problem with making snp a module is that it relies on hooks in the tty subsystem which normally aren't there. Take a look at tty.c and search for "DEV_SNP". If we wanted to make it a module, those hooks would have to be compiled into the base kernel. Since they call some snp-specific functions (snpin, snpinc), those would also have to be in the base kernel. Of course, all of that stuff can be made a kernel option, but that kind of defeats the purpose of making it a module. Dima Dorfman [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
:>Note that I really don't care for using stable storeage as a hack :>to deal with this sort of thing. : :Well, I have to admit that it is a pretty smart way of dealing with :it for remote operations, but the trouble is that it prevents us from :ever lowering their number again. : :If Matt can device a smart way to loose the soft reference in nfs, :vnodes can be a truly dynamic thing. : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 NFS uses vnodes the same way that VFS uses vnodes. If you solve the problem for general VFS operation (namely *cache_lookup), you solve the problem for NFS as well. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Very Bad Bug: current, 4.2, 4.3
I mentioned a very bad bug on the -arch list a while back, which occurred when To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
:In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: : :>I thought vnodes were in stable storage? : :They are, that's the point Matt is not seeing yet. I know vnodes are in stable storage. I'm just saying that NFS is the least of your worries in trying to change that. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
In message <[EMAIL PROTECTED]>, Alfred Perlstein writes: >I thought vnodes were in stable storage? They are, that's the point Matt is not seeing yet. >Note that I really don't care for using stable storeage as a hack >to deal with this sort of thing. Well, I have to admit that it is a pretty smart way of dealing with it for remote operations, but the trouble is that it prevents us from ever lowering their number again. If Matt can device a smart way to loose the soft reference in nfs, vnodes can be a truly dynamic thing. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
* Poul-Henning Kamp <[EMAIL PROTECTED]> [010417 10:56] wrote:
> In message <[EMAIL PROTECTED]>, Matt Dillon writes:
> >:>I don't think NFS relies on vnodes never being freed.
> >:
> >:It does, in some case nfs stashes a vnode pointer and the v_id
> >:value away, and some time later tries to use that pair to try to
> >:refind the vnode again. If you free vnodes, it will still think
> >:the pointer is a vnode and if junk happens to be right it will
> >:think it is still a vnode. QED: Bad things (TM) will happen.
> >:
> >:# cd /sys/nfs
> >:# grep v_id *
> >:nfs_nqlease.c: vpid = vp->v_id;
> >:nfs_nqlease.c: if (vpid == vp->v_id) {
> >:nfs_nqlease.c: if (vpid == vp->v_id &&
> >:nfs_vnops.c:vpid = newvp->v_id;
> >:nfs_vnops.c:if (vpid == newvp->v_id) {
> >:
> >:--
> >:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
> >
> > hahahahahahahaha.. Look at the code more closely. v_id is not
> > managed by NFS, it's managed by vfs_cache.c. There's a big XXX
> > comment just before cache_purge() that explains it. Believe me,
> > NFS is the least of your worries here.
>
> Matt, you try to free vnodes back to the malloc pool and you will
> see what happens OK ?
I thought vnodes were in stable storage?
Note that I really don't care for using stable storeage as a hack
to deal with this sort of thing.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Represent yourself, show up at BABUG http://www.babug.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: x86-64 Hammer and IA64 Itainium
I would like to see this too, however I think you have to sign NDA's and the like to be a part of the AMD effort to develop for it. Understandable I guess. Also they only seem interested in boosting Linux adoption of the new AMD 64 bit procs. *shrug* = -Chris Watson (316) 326-3862 | FreeBSD Consultant, FreeBSD Geek Work: [EMAIL PROTECTED] | Open Systems Inc., Wellington, Kansas Home: [EMAIL PROTECTED] | http://open-systems.net = WINDOWS: "Where do you want to go today?" LINUX: "Where do you want to go tomorrow?" BSD: "Are you guys coming or what?" = irc.openprojects.net #FreeBSD -Join the revolution! ICQ: 20016186 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
x86-64 Hammer and IA64 Itainium
I'd like to know if anyone's considering support for the new AMD Sledgehammer/Clawhammer/*hammer with x86-64 architecture. I know the new hammer cpus will run as _very_ fast x86-32 processors, and FreeBSD would run happily under that, however, the x86-64 architecture offers major advantages over the 32bit architecture. More than simply 64bit integers. Like the Itainium, the Hammer has more registers. Not as many as Itainium's 128 64bit general purpose registers, but a good 16 64bit registers rather than the 8 32bit that exist now. I would love to see FreeBSD running natively (64bit) under the x86-64 architecture, and unlike the Itainium, it's differences with x86-32 seem to be few (of course). From what I understand of the FreeBSD kernel, the parts of the system which are platform specific are somewhat abstracted from the rest. And since it's really just the next revision of the 'same' platform, I'm hoping it would not be excessively difficult. There is coming a time soon when IA32/x86-32 production will be coming to an end, and since all of the processors FreeBSD supports are IA32, a decision will have to be made on where to move next. I've read the data sheet (read: book) Intel sent me on the Itainium, and if it performs as they say it does, it will be an excellent offering. As an x86 assembly programmer, the idea of 128 64bit registers makes me happy. However, there's not much room for an assembly language programmer in the bundled instruction world of the Itainium. Porting FreeBSD to Itainium would/will/could be a much much larger project than the port to x86-64. Linux/GNU people in association with AMD have already begun work on x86-64 versions of gcc and binutils. If Linux ports first, which in my opinion they probably will since they are working on it actively, FreeBSD can only gain from the work already done by the Linux/GNU/x86-64 group. http://www.x86-64.org Another group, supporting the IA64/Itainium architecture for Linux and GNU also exists. From reading their wish list for the IA64 gcc compiler, I can see they haven't really mastered the architecture with ILP, but instead are merely working on a functioning version first, with architectural optimizations coming later. As far as I can see, their work is benefitting future versions of FreeBSD as well. http://www.linuxia64.org/ I'm studying the AMD architecture in an effort to port my x86 assembly skills to x86-64. Learning IA64 assembly seems pointless since they want everything done with an ILP capable compiler for maximum performance. Although my kernel programming skills are in their infancy, I am a good C and assembly language programmer. Perhaps I could contribute to the FreeBSD x86-64 project, if and when there was one. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: User-defined bit in sysctl flags ?
In some email I received from Alfred Perlstein, sie wrote: > * Darren Reed <[EMAIL PROTECTED]> [010416 13:37] wrote: > > > > What do people think about having a range of bits in oid_kind that are > > not used by FreeBSD but are only to be used by ``private'' sysctl handlers? > > > > e.g. > > > > #define CTLFLAG_PRIVATE 0x0000 > > > > Do I need elaborate any further ? > > I think a half-paragraph explaining what this does would help. :) > > I'm assuming this allows someone to have thier own private numbered > mib in the sysctl tree, my question is why are you using hardcoded > numbers rather than names? Uh, no. The idea is so you can do this: #define SYSCTL_IPF(parent, nbr, name, access, ptr, val, descr) \ SYSCTL_OID(parent, nbr, name, CTLTYPE_INT|access, \ ptr, val, sysctl_ipf_int, "I", descr); SYSCTL_IPF(_net_inet_ipf, OID_AUTO, fr_tcpidletimeout, CTLFLAG_RW|CTL_PRIV, &fr_tcpidletimeout, 0, ""); and have CTL_PRIV be a bit which sysctl_ipf_int understands and not have to worry about the value of CTL_PRIV ever being afflicted with double-use by a FreeBSD flag because CTL_PRIV is part of CTLFLAG_PRIVATE. Darren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ypserv: a resolution (LOOKING for YP/DB experts!)
At 8:06 PM -0400 4/16/01, David E. Cross wrote: [...skipping over some important stuff...] >My second solution was to have the child call yp_init_dbs() >instead of yp_flush_all() (the former would just nuke the >references to the FDs, but actually keep them open). This >didn't work. Can anyone provide any clues as to why? Does >the DB library keep its own cache, and unless they are >"really" closed it will just loop back to the open ones anyway? >The current solution is suboptimal since for many cases it >removes the DBCACHE entirely, but I don't know what other >solution exists. >JKH: I think this _really_ needs to get into 4.3-RELEASE, >this has been a vexing bug for over a year. The current >solution may be sub-optimal, but... I'm inclined to think that we should have a better understanding of what is going on in the DB routines in this parent/child situation. If it was something that worked in 4.2 but would be newly broken in 4.3, then I would be more inclined to see a last-minute sub-optimal fix rushed into 4.3, but as it is I do not have a warm fuzzy feeling that the real problem is understood at this point. If someone familiar with these DB routines could look into Dave's problem and comment, that would make any patch feel somewhat warmer and fuzzier... Perhaps Dave should put up a proposed patch to the gang in freebsd-audit as well as freebsd-hackers? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
:
:In message <[EMAIL PROTECTED]>, Matt Dillon writes:
:>:>I don't think NFS relies on vnodes never being freed.
:>:
:>:It does, in some case nfs stashes a vnode pointer and the v_id
:>:value away, and some time later tries to use that pair to try to
:>:refind the vnode again. If you free vnodes, it will still think
:>:the pointer is a vnode and if junk happens to be right it will
:>:think it is still a vnode. QED: Bad things (TM) will happen.
:>:
:>:# cd /sys/nfs
:>:# grep v_id *
:>:nfs_nqlease.c: vpid = vp->v_id;
:>:nfs_nqlease.c: if (vpid == vp->v_id) {
:>:nfs_nqlease.c: if (vpid == vp->v_id &&
:>:nfs_vnops.c:vpid = newvp->v_id;
:>:nfs_vnops.c:if (vpid == newvp->v_id) {
:>:
:>:--
:>:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
:>
:> hahahahahahahaha.. Look at the code more closely. v_id is not
:> managed by NFS, it's managed by vfs_cache.c. There's a big XXX
:> comment just before cache_purge() that explains it. Believe me,
:> NFS is the least of your worries here.
:
:Matt, you try to free vnodes back to the malloc pool and you will
:see what happens OK ?
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
ok ok... lets see. Oh, ok I see what it's doing. Actually I think
you just found a bug.
if ((error = cache_lookup(dvp, vpp, cnp)) && error != ENOENT) {
struct vattr vattr;
int vpid;
if ((error = VOP_ACCESS(dvp, VEXEC, cnp->cn_cred, p)) != 0) {
*vpp = NULLVP;
return (error);
}
newvp = *vpp;
vpid = newvp->v_id;
This is totally bogus. VOP_ACCESS can block, so even using vpid above
to check that the vnode hasn't been ripped out from under the code won't
work.
Also, take a look at the vput() later on, and also the vput() in
kern/vfs_cache.c/vfs_cache_lookup() - that looks bogus to me too and
would probably crash the machine.
The easiest solution here is to make cache_lookup bump the ref count
on the returned vnode and require that all users of cache_lookup vrele()
it.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>:>I don't think NFS relies on vnodes never being freed.
>:
>:It does, in some case nfs stashes a vnode pointer and the v_id
>:value away, and some time later tries to use that pair to try to
>:refind the vnode again. If you free vnodes, it will still think
>:the pointer is a vnode and if junk happens to be right it will
>:think it is still a vnode. QED: Bad things (TM) will happen.
>:
>:# cd /sys/nfs
>:# grep v_id *
>:nfs_nqlease.c: vpid = vp->v_id;
>:nfs_nqlease.c: if (vpid == vp->v_id) {
>:nfs_nqlease.c: if (vpid == vp->v_id &&
>:nfs_vnops.c:vpid = newvp->v_id;
>:nfs_vnops.c:if (vpid == newvp->v_id) {
>:
>:--
>:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>
> hahahahahahahaha.. Look at the code more closely. v_id is not
> managed by NFS, it's managed by vfs_cache.c. There's a big XXX
> comment just before cache_purge() that explains it. Believe me,
> NFS is the least of your worries here.
Matt, you try to free vnodes back to the malloc pool and you will
see what happens OK ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
:>I don't think NFS relies on vnodes never being freed.
:
:It does, in some case nfs stashes a vnode pointer and the v_id
:value away, and some time later tries to use that pair to try to
:refind the vnode again. If you free vnodes, it will still think
:the pointer is a vnode and if junk happens to be right it will
:think it is still a vnode. QED: Bad things (TM) will happen.
:
:# cd /sys/nfs
:# grep v_id *
:nfs_nqlease.c: vpid = vp->v_id;
:nfs_nqlease.c: if (vpid == vp->v_id) {
:nfs_nqlease.c: if (vpid == vp->v_id &&
:nfs_vnops.c:vpid = newvp->v_id;
:nfs_vnops.c:if (vpid == newvp->v_id) {
:
:--
:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
hahahahahahahaha.. Look at the code more closely. v_id is not
managed by NFS, it's managed by vfs_cache.c. There's a big XXX
comment just before cache_purge() that explains it. Believe me,
NFS is the least of your worries here.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
In message <[EMAIL PROTECTED]>, Matt Dillon writes:
>
>:When I first heard you say this I thought you were off your rockers,
>:but gradually I have come to think that you may be right.
>:
>:I think the task will be easier if we get the vnode/buf relationship
>:untangled a bit first.
>:
>:I may also pay off to take vnodes out of diskoperations entirely before
>:we try the merge.
>
>Yes, I agree. The vnode/VM-object issue is minor compared to
>the vnode/buf/io issue.
We're getting there, we're getting there...
>:Actually the main problem is that NFS relies on vnodes never being
>:freed to hold "soft references" using "struct vnode * + v_id).
>:
>:--
>:Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
>
>I don't think NFS relies on vnodes never being freed.
It does, in some case nfs stashes a vnode pointer and the v_id
value away, and some time later tries to use that pair to try to
refind the vnode again. If you free vnodes, it will still think
the pointer is a vnode and if junk happens to be right it will
think it is still a vnode. QED: Bad things (TM) will happen.
# cd /sys/nfs
# grep v_id *
nfs_nqlease.c: vpid = vp->v_id;
nfs_nqlease.c: if (vpid == vp->v_id) {
nfs_nqlease.c: if (vpid == vp->v_id &&
nfs_vnops.c:vpid = newvp->v_id;
nfs_vnops.c:if (vpid == newvp->v_id) {
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/25110
Thanks for the quick reply!
At Tue, 17 Apr 2001 10:51:48 -0400,
Dan Eischen wrote:
> Akinori MUSHA wrote:
> > Would you take a look at PR#25110 ? Some programs are suffering with
> > a problem that with the threaded library a process cannot receive due
> > signals except SIGKILL and SIGSTOP from its children and thus it
> > stalls at waitpid() after forking.
> >
> > The PR precisely describes the underlying cause and points out how you
> > can examine and solve the problem.
> >
> > I'd appreciate if you or someone else with a clue could deal with it.
>
> You can try the patch below. I think I've posted this patch before,
> but I guess I never committed it.
I tested your patch with the latest 4-STABLE and the latest 5-CURRENT,
and both passed my test programs that didn't work before! Of course,
the test program provided in the PR by Ueno-san also worked properly.
Attached is the patch I used for 4-STABLE.
Now Dan, do you consider sliding it into 4.3-RELEASE? The problem had
been reported, you recognized and posted a fix, and the fix looks
reasonable and indeed works. I would be great to see 4.3-RELEASE
shipped with the fork-safe libc_r.
If you are sure it's a mature fix, I'd like you to pester jkh for
approval. :)
Regards,
--
/
/__ __Akinori.org / MUSHA.org
/ ) ) ) ) / FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp
"Freeze this moment a little bit longer, make each impression
a little bit stronger.. Experience slips away -- Time stand still"
Index: uthread/uthread_fork.c
===
RCS file: /home/ncvs/src/lib/libc_r/uthread/uthread_fork.c,v
retrieving revision 1.19.2.1
diff -u -r1.19.2.1 uthread_fork.c
--- uthread/uthread_fork.c 2000/11/09 23:46:03 1.19.2.1
+++ uthread/uthread_fork.c 2001/04/17 17:07:43
@@ -32,6 +32,7 @@
* $FreeBSD: src/lib/libc_r/uthread/uthread_fork.c,v 1.19.2.1 2000/11/09 23:46:03
deischen Exp $
*/
#include
+#include
#include
#include
#include
@@ -108,7 +109,16 @@
else if (_pq_init(&_readyq) != 0) {
/* Abort this application: */
PANIC("Cannot initialize priority ready queue.");
- } else {
+ } else if ((_thread_sigstack.ss_sp == NULL) &&
+ ((_thread_sigstack.ss_sp = malloc(SIGSTKSZ)) == NULL))
+ PANIC("Unable to allocate alternate signal stack");
+ else {
+ /* Install the alternate signal stack: */
+ _thread_sigstack.ss_size = SIGSTKSZ;
+ _thread_sigstack.ss_flags = 0;
+ if (_thread_sys_sigaltstack(&_thread_sigstack, NULL) != 0)
+ PANIC("Unable to install alternate signal stack");
+
/*
* Enter a loop to remove all threads other than
* the running thread from the thread list:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
:When I first heard you say this I thought you were off your rockers, :but gradually I have come to think that you may be right. : :I think the task will be easier if we get the vnode/buf relationship :untangled a bit first. : :I may also pay off to take vnodes out of diskoperations entirely before :we try the merge. Yes, I agree. The vnode/VM-object issue is minor compared to the vnode/buf/io issue. :>Under the old name cache implementation, decreasing :>the number of vnodes was slow and hard. With the current name cache :>implementation, decreasing the number of vnodes would be easy. : :Actually the main problem is that NFS relies on vnodes never being :freed to hold "soft references" using "struct vnode * + v_id). : :-- :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 I don't think NFS relies on vnodes never being freed. The worst that should happen is that NFS might need to do a LOOKUP. I haven't had a chance to look at the namei/vnode patch set yet but as long as a reasonable number of vnodes remain cached NFS shouldn't be effected too much. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
:I'm interested in this idea, although profess a gaping blind spot in :expertise in the area of the VM system. However, one of the aspects of :our VFS that has always concerned me is that use of a single vnode :simplelock funnels most of the relevant (and performance-sensitive) calls. :The result is that all accesses to an object represented by a vnode are :serialized, which can represent a substantial performance hit for :applications such as databases, where simultaneous write would be :advantageous, or for various vn-backed oddities (possibly including :vnode-backed swap?). : :At some point, apparently an effort was made to mark up vnode_if.src with :possible alternative locking using read/write locks, but given that all :... We only use simplelocks on vnodes for interlock operations. We use normal kern/kern_lock.c locks for vnode locking and use both shared and exclusive locks. You are absolutely correct about the serialization that can occur. A stalled write() will stall all other write()'s plus any read()'s. Stalled write()s are easy to come by. I did some work in this area to try to mitigate the problem. In 4.1/4.2 I added the bwillwrite() function. This function is called prior to obtaining the exclusive vnode lock and blocks the process if there aren't a sufficient number of filesystem buffers available to (likely) accomodate the operation. This (mostly) prevents the process from blocking in the buffer cache while holding an exclusive vnode lock and makes a big difference. :is already in the cache), there are sufficient non-common cases that I :would anticipate this being a problem. Are there any performance figures :available that either confirm this concern, or demonstrate that in fact it :is not relevant? :-) Would this concern introduce additional funneling in :the VM system, or is the granularity of locks in the VM sufficiently low :that it might improve performance by combining existing broad locks? : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :[EMAIL PROTECTED] NAI Labs, Safeport Network Services The VM system is in pretty good shape in regards to fine-grained locking (you get down to the VM page). The VFS system is in terrible shape - there is no fine grained locking at all for writes. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bin/25110
Akinori MUSHA wrote:
>
> Hi,
>
> Would you take a look at PR#25110 ? Some programs are suffering with
> a problem that with the threaded library a process cannot receive due
> signals except SIGKILL and SIGSTOP from its children and thus it
> stalls at waitpid() after forking.
>
> The PR precisely describes the underlying cause and points out how you
> can examine and solve the problem.
>
> I'd appreciate if you or someone else with a clue could deal with it.
You can try the patch below. I think I've posted this patch before,
but I guess I never committed it.
--
Dan Eischen
Index: uthread/uthread_fork.c
===
RCS file: /opt/b/CVS/src/lib/libc_r/uthread/uthread_fork.c,v
retrieving revision 1.23
diff -u -r1.23 uthread_fork.c
--- uthread/uthread_fork.c 2001/04/10 04:25:49 1.23
+++ uthread/uthread_fork.c 2001/04/17 14:44:37
@@ -32,6 +32,7 @@
* $FreeBSD: src/lib/libc_r/uthread/uthread_fork.c,v 1.23 2001/04/10 04:25:49
deischen Exp $
*/
#include
+#include
#include
#include
#include
@@ -112,7 +113,16 @@
else if (_pq_init(&_readyq) != 0) {
/* Abort this application: */
PANIC("Cannot initialize priority ready queue.");
- } else {
+ } else if ((_thread_sigstack.ss_sp == NULL) &&
+ ((_thread_sigstack.ss_sp = malloc(SIGSTKSZ)) == NULL))
+ PANIC("Unable to allocate alternate signal stack");
+ else {
+ /* Install the alternate signal stack: */
+ _thread_sigstack.ss_size = SIGSTKSZ;
+ _thread_sigstack.ss_flags = 0;
+ if (__sys_sigaltstack(&_thread_sigstack, NULL) != 0)
+ PANIC("Unable to install alternate signal stack");
+
/*
* Enter a loop to remove all threads other than
* the running thread from the thread list:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
On Mon, 16 Apr 2001, Kirk McKusick wrote: > I am still of the opinion that merging VM objects and vnodes would be a > good idea. Although it would touch a huge number of lines of code, when > the dust settled, it would simplify some nasty bits of the system. This > merger is really independent of making the number of vnodes dynamic. > Under the old name cache implementation, decreasing the number of vnodes > was slow and hard. With the current name cache implementation, > decreasing the number of vnodes would be easy. I concur that adding a > dynamically sized vnode cache would help performance on some workloads. I'm interested in this idea, although profess a gaping blind spot in expertise in the area of the VM system. However, one of the aspects of our VFS that has always concerned me is that use of a single vnode simplelock funnels most of the relevant (and performance-sensitive) calls. The result is that all accesses to an object represented by a vnode are serialized, which can represent a substantial performance hit for applications such as databases, where simultaneous write would be advantageous, or for various vn-backed oddities (possibly including vnode-backed swap?). At some point, apparently an effort was made to mark up vnode_if.src with possible alternative locking using read/write locks, but given that all the consumers use exclusive locks right now, I assume that was not followed through on. A large part of the cost is mitigated through caching on the under-side of VFS, allowing vnode operations to return rapidly, but while this catches a number of common cases (where the file is already in the cache), there are sufficient non-common cases that I would anticipate this being a problem. Are there any performance figures available that either confirm this concern, or demonstrate that in fact it is not relevant? :-) Would this concern introduce additional funneling in the VM system, or is the granularity of locks in the VM sufficiently low that it might improve performance by combining existing broad locks? Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
bin/25110
Hi, Would you take a look at PR#25110 ? Some programs are suffering with a problem that with the threaded library a process cannot receive due signals except SIGKILL and SIGSTOP from its children and thus it stalls at waitpid() after forking. The PR precisely describes the underlying cause and points out how you can examine and solve the problem. I'd appreciate if you or someone else with a clue could deal with it. Regards, -- / /__ __Akinori.org / MUSHA.org / ) ) ) ) / FreeBSD.org / Ruby-lang.org Akinori MUSHA aka / (_ / ( (__( @ iDaemons.org / and.or.jp "Freeze this moment a little bit longer, make each impression a little bit stronger.. Experience slips away -- Time stand still" To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problems with German Keyboard
Hi! I´ve troubles getting german "umlauts" to work properly. I played around with vidcontrol and kbdcontrol to load different keymaps, fonts and screenmaps but nothing changed. I always get a single beep when i press a key with an "umlaut". This problem only occurs when i am on the console. When i connect using ssh or telnet everything works. I am using 4.2-RELEASE and the SC console driver. Thanks, Egon -- Egon Rath, Thanstetten 67, 4521 Schiedlberg, Austria (Info: finger [EMAIL PROTECTED], ICQ 95692730) In God we Trust -- all others must submit an X.509 certificate. Charles Forsythe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to make snp(4) devfs-friendly
This looks good. I'd say you should commit the change yourself -
feel free to say it's reviewed by me.
As an aside, when I did this to if_tun, I chose to do all the
destroy_dev()s at module unload time (I guess the snp device could do
with a MODULE_DECLARE). This allows the administrator to relax the
driver-chosen permissions on tun devices with something like
kldload if_tun
>/dev/tun0
chmod blah /dev/tun0
The destroy_dev() added to snpclose() prevents this.
Having said all that, it's unlikely that anyone would want to relax
the permissions a snoop device that wasn't already opened, so the
destroy_dev() looks ok here in practice.
> Brian Somers <[EMAIL PROTECTED]> writes:
> > I haven't actually tested the code, but looking at the patch, I think
> > there's a problem with it...
> >
> > Specifically, on a non-devfs system - where the device nodes are
> > created with mknod(1), snp_clone() isn't going to be called before
> > snpopen().
> >
> > I've (ab)used drv2 as a flag to say whether make_dev() has been
> > called in net/if_tun.c, but I'm not sure if this is the right answer
> > either :*]
>
> I think the correct approach is to check for !(si_flags & SI_NAMED) as
> done in rev. 1.68 of sys/net/bpf.c (that rev. has a precedence bug,
> which has since been fixed). That was written by phk, who I take to
> be pretty authoritative on the subject; looking at the places SI_NAMED
> is used also supports this conclusion.
>
> A corrected patch is attached (although I didn't test it in the
> non-devfs case).
>
> Thanks!
>
> Dima Dorfman
> [EMAIL PROTECTED]
>
>
> Index: tty_snoop.c
> ===
> RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v
> retrieving revision 1.52
> diff -u -r1.52 tty_snoop.c
> --- tty_snoop.c 2001/03/26 12:41:01 1.52
> +++ tty_snoop.c 2001/04/17 09:16:52
> @@ -287,10 +287,10 @@
> return (error);
>
> if (dev->si_drv1 == NULL) {
> - int mynor = minor(dev);
> -
> + if (!(dev->si_flags & SI_NAMED))
> + make_dev(&snp_cdevsw, minor(dev), UID_ROOT, GID_WHEEL,
> + 0600, "snp%d", dev2unit(dev));
> dev->si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO);
> - make_dev(&snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor);
> } else
> return (EBUSY);
>
> @@ -365,6 +365,7 @@
> free(snp->snp_buf, M_SNP);
> snp->snp_flags &= ~SNOOP_OPEN;
> dev->si_drv1 = NULL;
> + destroy_dev(dev);
>
> return (snp_detach(snp));
> }
> @@ -505,10 +506,25 @@
> static void snp_drvinit __P((void *unused));
>
> static void
> +snp_clone(void *arg, char *name, int namelen, dev_t *dev)
> +{
> + int u;
> +
> + if (*dev != NODEV)
> + return;
> + if (dev_stdclone(name, NULL, "snp", &u) != 1)
> + return;
> + *dev = make_dev(&snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600,
> + "snp%d", u);
> + return;
> +}
> +
> +static void
> snp_drvinit(unused)
> void *unused;
> {
>
> + EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000);
> cdevsw_add(&snp_cdevsw);
> }
>
--
Brian <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to make snp(4) devfs-friendly
Brian Somers <[EMAIL PROTECTED]> writes:
> I haven't actually tested the code, but looking at the patch, I think
> there's a problem with it...
>
> Specifically, on a non-devfs system - where the device nodes are
> created with mknod(1), snp_clone() isn't going to be called before
> snpopen().
>
> I've (ab)used drv2 as a flag to say whether make_dev() has been
> called in net/if_tun.c, but I'm not sure if this is the right answer
> either :*]
I think the correct approach is to check for !(si_flags & SI_NAMED) as
done in rev. 1.68 of sys/net/bpf.c (that rev. has a precedence bug,
which has since been fixed). That was written by phk, who I take to
be pretty authoritative on the subject; looking at the places SI_NAMED
is used also supports this conclusion.
A corrected patch is attached (although I didn't test it in the
non-devfs case).
Thanks!
Dima Dorfman
[EMAIL PROTECTED]
Index: tty_snoop.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v
retrieving revision 1.52
diff -u -r1.52 tty_snoop.c
--- tty_snoop.c 2001/03/26 12:41:01 1.52
+++ tty_snoop.c 2001/04/17 09:16:52
@@ -287,10 +287,10 @@
return (error);
if (dev->si_drv1 == NULL) {
- int mynor = minor(dev);
-
+ if (!(dev->si_flags & SI_NAMED))
+ make_dev(&snp_cdevsw, minor(dev), UID_ROOT, GID_WHEEL,
+ 0600, "snp%d", dev2unit(dev));
dev->si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO);
- make_dev(&snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor);
} else
return (EBUSY);
@@ -365,6 +365,7 @@
free(snp->snp_buf, M_SNP);
snp->snp_flags &= ~SNOOP_OPEN;
dev->si_drv1 = NULL;
+ destroy_dev(dev);
return (snp_detach(snp));
}
@@ -505,10 +506,25 @@
static void snp_drvinit __P((void *unused));
static void
+snp_clone(void *arg, char *name, int namelen, dev_t *dev)
+{
+ int u;
+
+ if (*dev != NODEV)
+ return;
+ if (dev_stdclone(name, NULL, "snp", &u) != 1)
+ return;
+ *dev = make_dev(&snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600,
+ "snp%d", u);
+ return;
+}
+
+static void
snp_drvinit(unused)
void *unused;
{
+ EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000);
cdevsw_add(&snp_cdevsw);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to make snp(4) devfs-friendly
I haven't actually tested the code, but looking at the patch, I think
there's a problem with it...
Specifically, on a non-devfs system - where the device nodes are
created with mknod(1), snp_clone() isn't going to be called before
snpopen().
I've (ab)used drv2 as a flag to say whether make_dev() has been
called in net/if_tun.c, but I'm not sure if this is the right answer
either :*]
> Attached is a patch to make the snp(4) driver play ball with DEVFS.
> For better or for worse, I used the bpf(4) driver as a guide on how to
> do this.
>
> If someone could review this, and, if nothing is wrong with it, commit
> it, I'd appreciate it.
>
> Thanks in advance,
>
> Dima Dorfman
> [EMAIL PROTECTED]
>
> Index: tty_snoop.c
> ===
> RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v
> retrieving revision 1.52
> diff -u -r1.52 tty_snoop.c
> --- tty_snoop.c 2001/03/26 12:41:01 1.52
> +++ tty_snoop.c 2001/04/17 08:17:23
> @@ -286,12 +286,9 @@
> if ((error = suser(p)) != 0)
> return (error);
>
> - if (dev->si_drv1 == NULL) {
> - int mynor = minor(dev);
> -
> + if (dev->si_drv1 == NULL)
> dev->si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO);
> - make_dev(&snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor);
> - } else
> + else
> return (EBUSY);
>
> /*
> @@ -365,6 +362,7 @@
> free(snp->snp_buf, M_SNP);
> snp->snp_flags &= ~SNOOP_OPEN;
> dev->si_drv1 = NULL;
> + destroy_dev(dev);
>
> return (snp_detach(snp));
> }
> @@ -505,10 +503,25 @@
> static void snp_drvinit __P((void *unused));
>
> static void
> +snp_clone(void *arg, char *name, int namelen, dev_t *dev)
> +{
> + int u;
> +
> + if (*dev != NODEV)
> + return;
> + if (dev_stdclone(name, NULL, "snp", &u) != 1)
> + return;
> + *dev = make_dev(&snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600,
> + "snp%d", u);
> + return;
> +}
> +
> +static void
> snp_drvinit(unused)
> void *unused;
> {
>
> + EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000);
> cdevsw_add(&snp_cdevsw);
> }
>
--
Brian <[EMAIL PROTECTED]>
Don't _EVER_ lose your sense of humour !
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Patch to make snp(4) devfs-friendly
Attached is a patch to make the snp(4) driver play ball with DEVFS.
For better or for worse, I used the bpf(4) driver as a guide on how to
do this.
If someone could review this, and, if nothing is wrong with it, commit
it, I'd appreciate it.
Thanks in advance,
Dima Dorfman
[EMAIL PROTECTED]
Index: tty_snoop.c
===
RCS file: /st/src/FreeBSD/src/sys/kern/tty_snoop.c,v
retrieving revision 1.52
diff -u -r1.52 tty_snoop.c
--- tty_snoop.c 2001/03/26 12:41:01 1.52
+++ tty_snoop.c 2001/04/17 08:17:23
@@ -286,12 +286,9 @@
if ((error = suser(p)) != 0)
return (error);
- if (dev->si_drv1 == NULL) {
- int mynor = minor(dev);
-
+ if (dev->si_drv1 == NULL)
dev->si_drv1 = snp = malloc(sizeof(*snp), M_SNP, M_WAITOK|M_ZERO);
- make_dev(&snp_cdevsw, mynor, 0, 0, 0600, "snp%d", mynor);
- } else
+ else
return (EBUSY);
/*
@@ -365,6 +362,7 @@
free(snp->snp_buf, M_SNP);
snp->snp_flags &= ~SNOOP_OPEN;
dev->si_drv1 = NULL;
+ destroy_dev(dev);
return (snp_detach(snp));
}
@@ -505,10 +503,25 @@
static void snp_drvinit __P((void *unused));
static void
+snp_clone(void *arg, char *name, int namelen, dev_t *dev)
+{
+ int u;
+
+ if (*dev != NODEV)
+ return;
+ if (dev_stdclone(name, NULL, "snp", &u) != 1)
+ return;
+ *dev = make_dev(&snp_cdevsw, unit2minor(u), UID_ROOT, GID_WHEEL, 0600,
+ "snp%d", u);
+ return;
+}
+
+static void
snp_drvinit(unused)
void *unused;
{
+ EVENTHANDLER_REGISTER(dev_clone, snp_clone, 0, 1000);
cdevsw_add(&snp_cdevsw);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: vm balance
In message <[EMAIL PROTECTED]>, Kirk McKusick writes: >I am still of the opinion that merging VM objects and vnodes would >be a good idea. Although it would touch a huge number of lines of >code, when the dust settled, it would simplify some nasty bits of >the system. When I first heard you say this I thought you were off your rockers, but gradually I have come to think that you may be right. I think the task will be easier if we get the vnode/buf relationship untangled a bit first. I may also pay off to take vnodes out of diskoperations entirely before we try the merge. >Under the old name cache implementation, decreasing >the number of vnodes was slow and hard. With the current name cache >implementation, decreasing the number of vnodes would be easy. Actually the main problem is that NFS relies on vnodes never being freed to hold "soft references" using "struct vnode * + v_id). -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
