mbuf leak found... for real this time.
I found it... our favorite function... nfsrv_create()!!! :) The problem was/is a create of an already existing file (with O_EXCL|O_CREATE, I would bet, but I don't have anyway to tell) returns *nothing* to the sender. The last time I had this problem it was because nfsrv_create() was not clearing error before its return (signalling to the caller that there was a more severe error and the packet should not be responded to. I have looked through the code, and arround line 1759 there should be a "goto nfsmreply0". Clearly we need to set error to 0 before we depart from this function with this kind of condition, I am just not sure the 'correct' way to do it. Any-who, I am not able to reproduce this reliably since the OS (all OS's I have tried, including the troubled machine) issue a getattr() to see if the file exists as a first stage, not even attempting the create call for the first try. This looks like a race condition waiting for us to loose it. As another aside... I really do think that on returning with an error condition, it may be a good idea to free those mbuf/mbuf-clusters. I cannot see a reason to keep them lying arround. -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leak found... for real this time.
PS: I was down to only 3k mbuf-clusters free on the server, so I 'rm'-ed the troublesome file and the create went through and no more mbuf-leaking. On the downside, I cannot reproduce this problem any longer with any reliability. -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
* David Malone ([EMAIL PROTECTED]) [990723 18:41]: if ((bi-bi_socktype == sep-se_socktype strcmp(bi-bi_service, sep-se_service) == 0) || matchservent(bi-bi_service, sep-se_service, sep-se_proto)) It should probably say: if (bi-bi_socktype == sep-se_socktype ((strcmp(bi-bi_service, sep-se_service) == 0) || matchservent(bi-bi_service, sep-se_service, sep-se_proto))) Holymoley, detect the braces-quiz. Those braces which changed are hard to spot, but prolly mean the world in this case -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Mentioning RFC numbers in /etc/services
Hi folks, I plan to mention in the comments for each service in /etc/services, the latest RFC describing the service. I also plan to mention in the manpage for services(5) the e-mail address to which requests for "How do I get the RFCs" should be sent. If anyone is worried that I'll get RFC numbers wrong, I'm happy to pass my diffs by him. I intend to do this next week-end, so let me know before then if you'd like to see what I'll be doing beforehand. Thanks, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
Ronald G. Minnich wrote in list.freebsd-hackers: On Fri, 23 Jul 1999, Kris Kennaway wrote: On Thu, 22 Jul 1999, Ronald G. Minnich wrote: Are you saying that as an ordinary user I can mount something on top of /tmp, for example? If the vfs.usermount sysctl is 1, and you have appropriate access to the thing you're trying to mount (block device, etc). OK, so let's say it is 1. Let's say I have "appropriate access" to /tmp. I mount my own fs on /tmp. I now have read/write access to everything anyone writes to /tmp. Not possible. You have to _own_ the mount point (which is usually not the case for /tmp). Or, let's say I don't have "appropriate access" to /tmp. Pick some other place. I mount my file system there for my files. Now everyone who wants can look for these user mounts and walk them at will. My private stuff is quite public. You own it, so you can set the permission appropriately, so nobody else can access it if you don't want that. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:[EMAIL PROTECTED]) "In jedem Stück Kohle wartet ein Diamant auf seine Geburt" (Terry Pratchett) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Sat, Jul 24, 1999, Sheldon Hearn wrote: Hi folks, I plan to mention in the comments for each service in /etc/services, the latest RFC describing the service. I also plan to mention in the manpage for services(5) the e-mail address to which requests for "How do I get the RFCs" should be sent. If anyone is worried that I'll get RFC numbers wrong, I'm happy to pass my diffs by him. I intend to do this next week-end, so let me know before then if you'd like to see what I'll be doing beforehand. Are you going to be listing all the RFCs that apply? For example, DNS is 1033, 1034, and 1035, and NNTP is 0850 and 0977. -- |Chris Costello [EMAIL PROTECTED] |Never trust a computer you can't lift. - Stan Masor ` To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rndcontrol and SMP
What is needed to make this support a more sensible number of IRQs? Mainly changing the ioctl and its clients (rndcontrol only?) to supply more bits. I am currently rewriting /dev/random (and rndcontrol). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Base Kerberos 5 support?
I would love to see krb 5 made part of the standard distribution. BEST has been using it for several years now with no problems and I believe that it is a whole lot easier to administrate then krb 4. I have Heimdal commit-ready (this has been the case for a year). I am waiting for it to be more compatible with MITK5. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM LDAP in FreeBSD
Quoth "Keith Stevenson": (Mark Murray: jump in here if I get this wrong) The way I understand it, a PAM module (pam_unix?) would need to be able to look at the password hash and figure out which of the crypt functions to call. Ideally, the PAM configuration would be able to specify which crypt functions are valid for the system. I'm sure this could be done. I'm not sure that it is PAM's job. I'll look at it. That said, one of the very attractive features of specifying the crypt function in the login class is the ability to assign different crypt algorithms on a user by user basis. ...or group... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
Adrian Filipi-Martin wrote: Cool... Is 1GB of ram really needed? We used to run a 64 meg system then 128 meg and then 384 meg, it doesn't seem to do much even for a heavily loaded ISP Server. Not really. The customer whose box this is chose this much memory because his previous server was a 256MB UltraSparc that was swamped all the time with a load of 6 to 7. Alas, since Solaris doesn't overcommit... :-) /me slaps himself -- "Bad boy!" -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "Your usefulness to my realm ended the day you made it off Hustaing alive." -- Sun Tzu Liao to his ex-finacee, Isis Marik To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rndcontrol and SMP
On Sat, 24 Jul 1999, Mark Murray wrote: What is needed to make this support a more sensible number of IRQs? Mainly changing the ioctl and its clients (rndcontrol only?) to supply more bits. I am currently rewriting /dev/random (and rndcontrol). When you say rewriting, do you mean syncing with the version of the code in Linux (1.04, instead of our 0.95) or actually rewriting? If the latter, I'm curious as to what your aims are. Kris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rndcontrol and SMP
When you say rewriting, do you mean syncing with the version of the code in Linux (1.04, instead of our 0.95) or actually rewriting? If the latter, I'm curious as to what your aims are. I want to implement Bruce Schneier's Yarrow. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rndcontrol and SMP
On Sat, 24 Jul 1999, Mark Murray wrote: When you say rewriting, do you mean syncing with the version of the code in Linux (1.04, instead of our 0.95) or actually rewriting? If the latter, I'm curious as to what your aims are. I want to implement Bruce Schneier's Yarrow. Ah - I had this idea as well, but hadn't looked into it further. Updating the /dev/random code to 1.04 is probably compatible with this goal to a large extent. Kris M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org -- The Feynman Problem-Solving Algorithm: (1) Write down the problem (2) Think real hard (3) Write down the answer -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leak found... for real this time.
:I found it... our favorite function... nfsrv_create()!!! :)
Yeee Haw!
:The problem was/is a create of an already existing file (with O_EXCL|O_CREATE,
:I would bet, but I don't have anyway to tell) returns *nothing* to the sender.
:The last time I had this problem it was because nfsrv_create() was not clearing
:error before its return (signalling to the caller that there was a more
:severe error and the packet should not be responded to. I have looked
:through the code, and arround line 1759 there should be a
:"goto nfsmreply0". Clearly we need to set error to 0 before we depart from
:this function with this kind of condition, I am just not sure the
:'correct' way to do it.
Hmmm. Interesting. An EEXIST error occuring at that point for an
NFSV3 mount will execute the correct nfsm_reply(), but since it is
NFSV3 the nfsm_reply() macro will not jump to a return(0) ... when
it finishes constructing the reply it falls through instead.
In this case I believe the nfsm_reply() call on line 1761 is correct,
but that we are failing to clear the error afterwords and this is
resulting in a non-zero return(). Thus the reply packet is being
properly formatted but not being transmitted.
I think all we need to do is set error = 0 for the NFSV3 case after
the nfsm_srvwcc_data() call. See the enclosed patch. We definitely
do not want to call nfsm_reply(0), because we already correctly call
nfsm_reply() on line 1761 (in STABLE).
I really appreciate the effort you've put into tracking down these
problems, Dave! You are virtually the only one who has enough of a
mix of NFS clients to truely test the server-side code. The only
testing I can do is between FreeBSD boxes!
In anycase, please try the enclosed patch. The patch, if correct,
should be applied to all branches.
And if there is anyone else up on NFS I would appreciate a review of
the patch! Remember that nfsm_reply() deals with errors differently
between NFSv2 and NFSv3.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
:Any-who, I am not able to reproduce this reliably since the OS (all OS's I
:have tried, including the troubled machine) issue a getattr() to see if the
:file exists as a first stage, not even attempting the create call for the
:first try. This looks like a race condition waiting for us to loose it.
:
:As another aside... I really do think that on returning with an error
:condition, it may be a good idea to free those mbuf/mbuf-clusters. I cannot
:see a reason to keep them lying arround.
:
:--
:David Cross | email: [EMAIL PROTECTED]
Index: nfs_serv.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_serv.c,v
retrieving revision 1.72.2.2
diff -u -r1.72.2.2 nfs_serv.c
--- nfs_serv.c 1999/06/30 22:05:14 1.72.2.2
+++ nfs_serv.c 1999/07/24 16:31:48
@@ -1765,6 +1765,7 @@
nfsm_srvpostop_attr(0, vap);
}
nfsm_srvwcc_data(dirfor_ret, dirfor, diraft_ret, diraft);
+ error = 0;
} else {
nfsm_srvfhtom(fhp, v3);
nfsm_build(fp, struct nfs_fattr *, NFSX_V2FATTR);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Sat, 24 Jul 1999, Sheldon Hearn wrote: Hi folks, I plan to mention in the comments for each service in /etc/services, the latest RFC describing the service. I also plan to mention in the manpage for services(5) the e-mail address to which requests for "How do I get the RFCs" should be sent. If anyone is worried that I'll get RFC numbers wrong, I'm happy to pass my diffs by him. I intend to do this next week-end, so let me know before then if you'd like to see what I'll be doing beforehand. I'd check, if I were you, if any of the other BSDs have done this already, to greatly simplify the task. Thanks, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Fri, 23 Jul 1999, Daniel C. Sobral wrote: Not really. The customer whose box this is chose this much memory because his previous server was a 256MB UltraSparc that was swamped all the time with a load of 6 to 7. Alas, since Solaris doesn't overcommit... :-) This isn't a comment meant to contribute to the overcommit holy war (opinion mode: I think FreeBSD should overcommit, or at worst have a sysctl and default to overcommit - admins who don't want overcommit can then hang themselves), but we have to be a wee bit careful when throwing load averages around... I've seen FreeBSD boxes virtually unuseable with 3-4 loads, and Solaris boxes still chugging away at 5+... Perhaps 'load average' is being calculated a wee bit differently. -- Mike Hoskins [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
Mike Hoskins wrote: This isn't a comment meant to contribute to the overcommit holy war (opinion mode: I think FreeBSD should overcommit, or at worst have a sysctl and default to overcommit - admins who don't want overcommit can then hang themselves), but we have to be a wee bit careful when throwing load averages around... I've seen FreeBSD boxes virtually unuseable with 3-4 loads, and Solaris boxes still chugging away at 5+... Perhaps 'load average' is being calculated a wee bit differently. I think that would rather be a function of the memory footprint of the workload. The message said memory was increased because Solaris was overloaded with _swapping_. The load itself isn't really of much importance in this case. Since Solaris does not overcommit, it needs (much) more memory than FreeBSD would. Thus, changing to FreeBSD and upgrading the memory at the same time is sure likely to give the impressive results described. Solaris is not a bad operating system. It's just misguided. :-) -- Daniel C. Sobral(8-DCS) [EMAIL PROTECTED] [EMAIL PROTECTED] "Your usefulness to my realm ended the day you made it off Hustaing alive." -- Sun Tzu Liao to his ex-finacee, Isis Marik To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf leak found... for real this time.
Hmmm. Interesting. An EEXIST error occuring at that point for an NFSV3 mount will execute the correct nfsm_reply(), but since it is NFSV3 the nfsm_reply() macro will not jump to a return(0) ... when it finishes constructing the reply it falls through instead. In this case I believe the nfsm_reply() call on line 1761 is correct, but that we are failing to clear the error afterwords and this is resulting in a non-zero return(). Thus the reply packet is being properly formatted but not being transmitted. I think all we need to do is set error = 0 for the NFSV3 case after the nfsm_srvwcc_data() call. See the enclosed patch. We definitely do not want to call nfsm_reply(0), because we already correctly call nfsm_reply() on line 1761 (in STABLE). I really appreciate the effort you've put into tracking down these problems, Dave! You are virtually the only one who has enough of a mix of NFS clients to truely test the server-side code. The only testing I can do is between FreeBSD boxes! In anycase, please try the enclosed patch. The patch, if correct, should be applied to all branches. And if there is anyone else up on NFS I would appreciate a review of the patch! Remember that nfsm_reply() deals with errors differently between NFSv2 and NFSv3. Yes, I concur with your patch whole-heartedly. Apparently last night I was too-tired, and not intoxicated enough to understand the nfs_serv.c code :) I alas will not be able to test it. The machine is up and stable with 3k mbufs in reserve.. maybe later :) As an aside, what about getting rid of that mbuf leak if a nfs-service routine returns with error!=0? -- David Cross | email: [EMAIL PROTECTED] Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
Daniel C. Sobral wrote: Mike Hoskins wrote: This isn't a comment meant to contribute to the overcommit holy war (opinion mode: I think FreeBSD should overcommit, or at worst have a sysctl and default to overcommit - admins who don't want overcommit can then hang themselves), but we have to be a wee bit careful when throwing load averages around... I've seen FreeBSD boxes virtually unuseable with 3-4 loads, and Solaris boxes still chugging away at 5+... Perhaps 'load average' is being calculated a wee bit differently. I think that would rather be a function of the memory footprint of the workload. The message said memory was increased because Solaris was overloaded with _swapping_. The load itself isn't really of much importance in this case. I think there is some confusion. In case of swapping the workload (A.K.A. CPU run queue length) will be _low_. Intensive swapping/paging means overloaded I/O subsystem and underloaded CPU. If the CPU has high load then the paging does not make a big problem, it just happens in "background" and does not really affect the system performance limited by the CPU bottleneck. Well, it may also favor the CPU-intensive application and limit the I/O-intensive applications if the filesystems and swap areas are on the same disks. (Yes, I have seen both cases in the real life). Since Solaris does not overcommit, it needs (much) more memory than FreeBSD would. Thus, changing to FreeBSD and upgrading the memory at It does not. It needs more swap space configured but not the physical memory. And at the current disk prices a 9G SCSI disk configured for swap would cost under $300, so the difference is not _that_ big. Solaris is not a bad operating system. It's just misguided. :-) It's just terrible from the systems administration standpoint :-) -SB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Sat, 24 Jul 1999 08:25:55 EST, Chris Costello wrote: Are you going to be listing all the RFCs that apply? For example, DNS is 1033, 1034, and 1035, and NNTP is 0850 and 0977. I doubt I'll be listing obsoleted RFCs. :-) I'll do the best I can. Send me private mail if you'd like to see what that is. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Linear buffers in VESA screen modes
Is there a plan for how to access the linear framebuffer in VESA video modes? So far as I can tell, the current[1] VESA code doesn't support enabling the linear framebuffer access at all, even though "vidcontrol -i mode" is happy to tell you the details of the buffers that you can't get access to! [1] actually, I'm working in -stable, but at a quick glance the -current code is the same in this area. I have used the following hack to make it work for my purposes: % cvs diff -c vesa.c Index: vesa.c === RCS file: /repository/src/sys/i386/isa/vesa.c,v retrieving revision 1.15.2.5 diff -c -r1.15.2.5 vesa.c *** vesa.c 1999/04/16 15:58:21 1.15.2.5 --- vesa.c 1999/07/24 23:26:21 *** *** 777,783 } #endif /* 0 */ ! if (vesa_bios_set_mode(mode)) return 1; #if VESA_DEBUG 0 --- 777,784 } #endif /* 0 */ ! /* If mode has a linear buffer, enable use of it*/ ! if (vesa_bios_set_mode(info.vi_buffer ? (mode | 0x4000) : mode)) return 1; #if VESA_DEBUG 0 This currently does the right thing (at least on my hardware) because all the modes that syscons supports for character I/O don't have a linear mapping and hence those modes get set for windowed access as before. However, it's probably not the proper solution. The application for which I need this is to support capture from the bktr driver onto the screen (ie. so that you can watch TV without X). With the above hack and a small (100-line) program it works very nicely - far tidier than installing X just for this purpose on some embedded systems where I need this capability. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Linear buffers in VESA screen modes
Is there a plan for how to access the linear framebuffer in VESA video modes? So far as I can tell, the current[1] VESA code doesn't support enabling the linear framebuffer access at all, even though "vidcontrol -i mode" is happy to tell you the details of the buffers that you can't get access to! [1] actually, I'm working in -stable, but at a quick glance the -current code is the same in this area. Actually -CURRENT sets up the linear framebuffer if available. I have used the following hack to make it work for my purposes: [...] The vesa module in -CURRENT does basically the same as your patch. Kazu To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
Ronald G. Minnich wrote: On Fri, 23 Jul 1999, Kris Kennaway wrote: On Thu, 22 Jul 1999, Ronald G. Minnich wrote: Are you saying that as an ordinary user I can mount something on top of /tmp, for example? If the vfs.usermount sysctl is 1, and you have appropriate access to the thing you're trying to mount (block device, etc). OK, so let's say it is 1. Let's say I have "appropriate access" to /tmp. I mount my own fs on /tmp. I now have read/write access to everything anyone writes to /tmp. "Appropriate access" includes the idea that you need to own the mountpoint directory. If you have a system that's so badly run that arbitrary users own /tmp, then I'd say user mounts are the least of your problems :-) Or, let's say I don't have "appropriate access" to /tmp. Pick some other place. I mount my file system there for my files. Now everyone who wants can look for these user mounts and walk them at will. My private stuff is quite public. Correct (unless you want your private stuff to be private, and chmod your mountpoint's parent directory accordingly). But thanks for the note. I just now realized that if I add a private name space to v9fs (which is easy), and then turn on user mounts, user processes can have private name spaces on freebsd! I can't wait to see the security problems that causes when setuid executables assume that they only need to be worrying about one filesystem namespace. :-) - mark Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Filesystem question...
On Sun, 25 Jul 1999, Mark Newton wrote: Ronald G. Minnich wrote: But thanks for the note. I just now realized that if I add a private name space to v9fs (which is easy), and then turn on user mounts, user processes can have private name spaces on freebsd! I can't wait to see the security problems that causes when setuid executables assume that they only need to be worrying about one filesystem namespace. :-) There shouldn't be any problems if mount enabled the flags for nosuid/nodev etc. if suser(p) != 0. - mark Mark Newton Email: [EMAIL PROTECTED] (W) Network Engineer Email: [EMAIL PROTECTED] (H) Internode Systems Pty Ltd Desk: +61-8-82232999 "Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mbuf leak found... for real this time.
I found it... our favorite function... nfsrv_create()!!! :) The problem was/is a create of an already existing file (with O_EXCL|O_CREATE, I would bet, but I don't have anyway to tell) returns *nothing* to the sender. The last time I had this problem it was because nfsrv_create() was not clearing error before its return (signalling to the caller that there was a more severe error and the packet should not be responded to. I have looked through the code, and arround line 1759 there should be a goto nfsmreply0. Clearly we need to set error to 0 before we depart from this function with this kind of condition, I am just not sure the 'correct' way to do it. Any-who, I am not able to reproduce this reliably since the OS (all OS's I have tried, including the troubled machine) issue a getattr() to see if the file exists as a first stage, not even attempting the create call for the first try. This looks like a race condition waiting for us to loose it. As another aside... I really do think that on returning with an error condition, it may be a good idea to free those mbuf/mbuf-clusters. I cannot see a reason to keep them lying arround. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf leak found... for real this time.
PS: I was down to only 3k mbuf-clusters free on the server, so I 'rm'-ed the troublesome file and the create went through and no more mbuf-leaking. On the downside, I cannot reproduce this problem any longer with any reliability. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/usr.sbin/inetd builtins.c inetd.h
* David Malone (dwmal...@maths.tcd.ie) [990723 18:41]: if ((bi-bi_socktype == sep-se_socktype strcmp(bi-bi_service, sep-se_service) == 0) || matchservent(bi-bi_service, sep-se_service, sep-se_proto)) It should probably say: if (bi-bi_socktype == sep-se_socktype ((strcmp(bi-bi_service, sep-se_service) == 0) || matchservent(bi-bi_service, sep-se_service, sep-se_proto))) Holymoley, detect the braces-quiz. Those braces which changed are hard to spot, but prolly mean the world in this case -- Jeroen Ruigrok van der Werven asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Cum angelis et pueris, fideles inveniamur. Quis est iste Rex gloriae...? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Mentioning RFC numbers in /etc/services
Hi folks, I plan to mention in the comments for each service in /etc/services, the latest RFC describing the service. I also plan to mention in the manpage for services(5) the e-mail address to which requests for How do I get the RFCs should be sent. If anyone is worried that I'll get RFC numbers wrong, I'm happy to pass my diffs by him. I intend to do this next week-end, so let me know before then if you'd like to see what I'll be doing beforehand. Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Filesystem question...
Ronald G. Minnich wrote in list.freebsd-hackers: On Fri, 23 Jul 1999, Kris Kennaway wrote: On Thu, 22 Jul 1999, Ronald G. Minnich wrote: Are you saying that as an ordinary user I can mount something on top of /tmp, for example? If the vfs.usermount sysctl is 1, and you have appropriate access to the thing you're trying to mount (block device, etc). OK, so let's say it is 1. Let's say I have appropriate access to /tmp. I mount my own fs on /tmp. I now have read/write access to everything anyone writes to /tmp. Not possible. You have to _own_ the mount point (which is usually not the case for /tmp). Or, let's say I don't have appropriate access to /tmp. Pick some other place. I mount my file system there for my files. Now everyone who wants can look for these user mounts and walk them at will. My private stuff is quite public. You own it, so you can set the permission appropriately, so nobody else can access it if you don't want that. Regards Oliver -- Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany (Info: finger userinfo:o...@dorifer.heim3.tu-clausthal.de) In jedem Stück Kohle wartet ein Diamant auf seine Geburt (Terry Pratchett) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Sat, Jul 24, 1999, Sheldon Hearn wrote: Hi folks, I plan to mention in the comments for each service in /etc/services, the latest RFC describing the service. I also plan to mention in the manpage for services(5) the e-mail address to which requests for How do I get the RFCs should be sent. If anyone is worried that I'll get RFC numbers wrong, I'm happy to pass my diffs by him. I intend to do this next week-end, so let me know before then if you'd like to see what I'll be doing beforehand. Are you going to be listing all the RFCs that apply? For example, DNS is 1033, 1034, and 1035, and NNTP is 0850 and 0977. -- |Chris Costello ch...@calldei.com |Never trust a computer you can't lift. - Stan Masor ` To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: rndcontrol and SMP
What is needed to make this support a more sensible number of IRQs? Mainly changing the ioctl and its clients (rndcontrol only?) to supply more bits. I am currently rewriting /dev/random (and rndcontrol). M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Base Kerberos 5 support?
I would love to see krb 5 made part of the standard distribution. BEST has been using it for several years now with no problems and I believe that it is a whole lot easier to administrate then krb 4. I have Heimdal commit-ready (this has been the case for a year). I am waiting for it to be more compatible with MITK5. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: PAM LDAP in FreeBSD
Quoth Keith Stevenson: (Mark Murray: jump in here if I get this wrong) The way I understand it, a PAM module (pam_unix?) would need to be able to look at the password hash and figure out which of the crypt functions to call. Ideally, the PAM configuration would be able to specify which crypt functions are valid for the system. I'm sure this could be done. I'm not sure that it is PAM's job. I'll look at it. That said, one of the very attractive features of specifying the crypt function in the login class is the ability to assign different crypt algorithms on a user by user basis. ...or group... M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
Adrian Filipi-Martin wrote: Cool... Is 1GB of ram really needed? We used to run a 64 meg system then 128 meg and then 384 meg, it doesn't seem to do much even for a heavily loaded ISP Server. Not really. The customer whose box this is chose this much memory because his previous server was a 256MB UltraSparc that was swamped all the time with a load of 6 to 7. Alas, since Solaris doesn't overcommit... :-) /me slaps himself -- Bad boy! -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Your usefulness to my realm ended the day you made it off Hustaing alive. -- Sun Tzu Liao to his ex-finacee, Isis Marik To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: rndcontrol and SMP
On Sat, 24 Jul 1999, Mark Murray wrote: What is needed to make this support a more sensible number of IRQs? Mainly changing the ioctl and its clients (rndcontrol only?) to supply more bits. I am currently rewriting /dev/random (and rndcontrol). When you say rewriting, do you mean syncing with the version of the code in Linux (1.04, instead of our 0.95) or actually rewriting? If the latter, I'm curious as to what your aims are. Kris To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: rndcontrol and SMP
When you say rewriting, do you mean syncing with the version of the code in Linux (1.04, instead of our 0.95) or actually rewriting? If the latter, I'm curious as to what your aims are. I want to implement Bruce Schneier's Yarrow. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: rndcontrol and SMP
On Sat, 24 Jul 1999, Mark Murray wrote: When you say rewriting, do you mean syncing with the version of the code in Linux (1.04, instead of our 0.95) or actually rewriting? If the latter, I'm curious as to what your aims are. I want to implement Bruce Schneier's Yarrow. Ah - I had this idea as well, but hadn't looked into it further. Updating the /dev/random code to 1.04 is probably compatible with this goal to a large extent. Kris M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org -- The Feynman Problem-Solving Algorithm: (1) Write down the problem (2) Think real hard (3) Write down the answer -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf leak found... for real this time.
:I found it... our favorite function... nfsrv_create()!!! :)
Yeee Haw!
:The problem was/is a create of an already existing file (with O_EXCL|O_CREATE,
:I would bet, but I don't have anyway to tell) returns *nothing* to the sender.
:The last time I had this problem it was because nfsrv_create() was not clearing
:error before its return (signalling to the caller that there was a more
:severe error and the packet should not be responded to. I have looked
:through the code, and arround line 1759 there should be a
:goto nfsmreply0. Clearly we need to set error to 0 before we depart from
:this function with this kind of condition, I am just not sure the
:'correct' way to do it.
Hmmm. Interesting. An EEXIST error occuring at that point for an
NFSV3 mount will execute the correct nfsm_reply(), but since it is
NFSV3 the nfsm_reply() macro will not jump to a return(0) ... when
it finishes constructing the reply it falls through instead.
In this case I believe the nfsm_reply() call on line 1761 is correct,
but that we are failing to clear the error afterwords and this is
resulting in a non-zero return(). Thus the reply packet is being
properly formatted but not being transmitted.
I think all we need to do is set error = 0 for the NFSV3 case after
the nfsm_srvwcc_data() call. See the enclosed patch. We definitely
do not want to call nfsm_reply(0), because we already correctly call
nfsm_reply() on line 1761 (in STABLE).
I really appreciate the effort you've put into tracking down these
problems, Dave! You are virtually the only one who has enough of a
mix of NFS clients to truely test the server-side code. The only
testing I can do is between FreeBSD boxes!
In anycase, please try the enclosed patch. The patch, if correct,
should be applied to all branches.
And if there is anyone else up on NFS I would appreciate a review of
the patch! Remember that nfsm_reply() deals with errors differently
between NFSv2 and NFSv3.
-Matt
Matthew Dillon
dil...@backplane.com
:Any-who, I am not able to reproduce this reliably since the OS (all OS's I
:have tried, including the troubled machine) issue a getattr() to see if the
:file exists as a first stage, not even attempting the create call for the
:first try. This looks like a race condition waiting for us to loose it.
:
:As another aside... I really do think that on returning with an error
:condition, it may be a good idea to free those mbuf/mbuf-clusters. I cannot
:see a reason to keep them lying arround.
:
:--
:David Cross | email: cro...@cs.rpi.edu
Index: nfs_serv.c
===
RCS file: /home/ncvs/src/sys/nfs/nfs_serv.c,v
retrieving revision 1.72.2.2
diff -u -r1.72.2.2 nfs_serv.c
--- nfs_serv.c 1999/06/30 22:05:14 1.72.2.2
+++ nfs_serv.c 1999/07/24 16:31:48
@@ -1765,6 +1765,7 @@
nfsm_srvpostop_attr(0, vap);
}
nfsm_srvwcc_data(dirfor_ret, dirfor, diraft_ret, diraft);
+ error = 0;
} else {
nfsm_srvfhtom(fhp, v3);
nfsm_build(fp, struct nfs_fattr *, NFSX_V2FATTR);
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Sat, 24 Jul 1999, Sheldon Hearn wrote: Hi folks, I plan to mention in the comments for each service in /etc/services, the latest RFC describing the service. I also plan to mention in the manpage for services(5) the e-mail address to which requests for How do I get the RFCs should be sent. If anyone is worried that I'll get RFC numbers wrong, I'm happy to pass my diffs by him. I intend to do this next week-end, so let me know before then if you'd like to see what I'll be doing beforehand. I'd check, if I were you, if any of the other BSDs have done this already, to greatly simplify the task. Thanks, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Fri, 23 Jul 1999, Daniel C. Sobral wrote: Not really. The customer whose box this is chose this much memory because his previous server was a 256MB UltraSparc that was swamped all the time with a load of 6 to 7. Alas, since Solaris doesn't overcommit... :-) This isn't a comment meant to contribute to the overcommit holy war (opinion mode: I think FreeBSD should overcommit, or at worst have a sysctl and default to overcommit - admins who don't want overcommit can then hang themselves), but we have to be a wee bit careful when throwing load averages around... I've seen FreeBSD boxes virtually unuseable with 3-4 loads, and Solaris boxes still chugging away at 5+... Perhaps 'load average' is being calculated a wee bit differently. -- Mike Hoskins m...@adept.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: deny ktrace without read permissions?
PR bin/3546 asks that `ktrace(1)' not be allowed on files that do not have read permissions for the user attempting to execute them. The intent of this change is to prevent a user from seeing how an executable with '--x--x--x' perms works by ktrace'ing its execution. My question to the -hackers is: is this a useful semantic? Would it break anything if added? If we make kernel auditing based upon KTRACE (which may or may not happen), this is not a useful change since we need to be able to 'audit' system calls regardless of whether or not KTRACE is used. If this kind of addition is done, then it'll have to be removed since system auditing must occur and be essentially 'independant' of what options are used. If adding auditing has a negative effect on the successful completion of a system call, then it's not going to be used. (There are certain things that can't be avoided, such as additional CPU/memory use, but it should not effect whether or not the syscall is completed.) Also, I believe that KTRACE should be allowed since security through obscurity isn't a good reason to avoid letting the user see the syscall. If security is an issue, KTRACE shouldn't be in the system kernel. Nate To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
Mike Hoskins wrote: This isn't a comment meant to contribute to the overcommit holy war (opinion mode: I think FreeBSD should overcommit, or at worst have a sysctl and default to overcommit - admins who don't want overcommit can then hang themselves), but we have to be a wee bit careful when throwing load averages around... I've seen FreeBSD boxes virtually unuseable with 3-4 loads, and Solaris boxes still chugging away at 5+... Perhaps 'load average' is being calculated a wee bit differently. I think that would rather be a function of the memory footprint of the workload. The message said memory was increased because Solaris was overloaded with _swapping_. The load itself isn't really of much importance in this case. Since Solaris does not overcommit, it needs (much) more memory than FreeBSD would. Thus, changing to FreeBSD and upgrading the memory at the same time is sure likely to give the impressive results described. Solaris is not a bad operating system. It's just misguided. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Your usefulness to my realm ended the day you made it off Hustaing alive. -- Sun Tzu Liao to his ex-finacee, Isis Marik To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
On Sat, 24 Jul 1999, Mike Hoskins wrote: On Fri, 23 Jul 1999, Daniel C. Sobral wrote: Not really. The customer whose box this is chose this much memory because his previous server was a 256MB UltraSparc that was swamped all the time with a load of 6 to 7. Alas, since Solaris doesn't overcommit... :-) This isn't a comment meant to contribute to the overcommit holy war (opinion mode: I think FreeBSD should overcommit, or at worst have a sysctl and default to overcommit - admins who don't want overcommit can then hang themselves), but we have to be a wee bit careful when throwing load averages around... I've seen FreeBSD boxes virtually unuseable with 3-4 loads, and Solaris boxes still chugging away at 5+... Perhaps 'load average' is being calculated a wee bit differently. Speaking about loads, I have a question that I can't figure out... On one of our systems which is a Pentium II 400 with the ABIT BH6 with 384 megs of RAM. Just for reference, the previous was a AMD K6-233 on a ASUS P55T2P4 with 64 Megs of RAM. It seems like whether there is a heavy load or light load, at times, when typing just w in the shell or any command or even in pine, the FreeBSD OS would just hang for like 30 seconds or so... It isn't a network issue either because I can jump around in my screen windows but just commands don't work like in real time. There is this long delay. Anyone have any ideas what can be causing this? Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf leak found... for real this time.
Hmmm. Interesting. An EEXIST error occuring at that point for an NFSV3 mount will execute the correct nfsm_reply(), but since it is NFSV3 the nfsm_reply() macro will not jump to a return(0) ... when it finishes constructing the reply it falls through instead. In this case I believe the nfsm_reply() call on line 1761 is correct, but that we are failing to clear the error afterwords and this is resulting in a non-zero return(). Thus the reply packet is being properly formatted but not being transmitted. I think all we need to do is set error = 0 for the NFSV3 case after the nfsm_srvwcc_data() call. See the enclosed patch. We definitely do not want to call nfsm_reply(0), because we already correctly call nfsm_reply() on line 1761 (in STABLE). I really appreciate the effort you've put into tracking down these problems, Dave! You are virtually the only one who has enough of a mix of NFS clients to truely test the server-side code. The only testing I can do is between FreeBSD boxes! In anycase, please try the enclosed patch. The patch, if correct, should be applied to all branches. And if there is anyone else up on NFS I would appreciate a review of the patch! Remember that nfsm_reply() deals with errors differently between NFSv2 and NFSv3. Yes, I concur with your patch whole-heartedly. Apparently last night I was too-tired, and not intoxicated enough to understand the nfs_serv.c code :) I alas will not be able to test it. The machine is up and stable with 3k mbufs in reserve.. maybe later :) As an aside, what about getting rid of that mbuf leak if a nfs-service routine returns with error!=0? -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: What good PII/PIII Motherboards for FreeBSD and Celeron CPU's
Daniel C. Sobral wrote: Mike Hoskins wrote: This isn't a comment meant to contribute to the overcommit holy war (opinion mode: I think FreeBSD should overcommit, or at worst have a sysctl and default to overcommit - admins who don't want overcommit can then hang themselves), but we have to be a wee bit careful when throwing load averages around... I've seen FreeBSD boxes virtually unuseable with 3-4 loads, and Solaris boxes still chugging away at 5+... Perhaps 'load average' is being calculated a wee bit differently. I think that would rather be a function of the memory footprint of the workload. The message said memory was increased because Solaris was overloaded with _swapping_. The load itself isn't really of much importance in this case. I think there is some confusion. In case of swapping the workload (A.K.A. CPU run queue length) will be _low_. Intensive swapping/paging means overloaded I/O subsystem and underloaded CPU. If the CPU has high load then the paging does not make a big problem, it just happens in background and does not really affect the system performance limited by the CPU bottleneck. Well, it may also favor the CPU-intensive application and limit the I/O-intensive applications if the filesystems and swap areas are on the same disks. (Yes, I have seen both cases in the real life). Since Solaris does not overcommit, it needs (much) more memory than FreeBSD would. Thus, changing to FreeBSD and upgrading the memory at It does not. It needs more swap space configured but not the physical memory. And at the current disk prices a 9G SCSI disk configured for swap would cost under $300, so the difference is not _that_ big. Solaris is not a bad operating system. It's just misguided. :-) It's just terrible from the systems administration standpoint :-) -SB To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Mentioning RFC numbers in /etc/services
On Sat, 24 Jul 1999 08:25:55 EST, Chris Costello wrote: Are you going to be listing all the RFCs that apply? For example, DNS is 1033, 1034, and 1035, and NNTP is 0850 and 0977. I doubt I'll be listing obsoleted RFCs. :-) I'll do the best I can. Send me private mail if you'd like to see what that is. Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Linear buffers in VESA screen modes
Is there a plan for how to access the linear framebuffer in VESA video modes? So far as I can tell, the current[1] VESA code doesn't support enabling the linear framebuffer access at all, even though vidcontrol -i mode is happy to tell you the details of the buffers that you can't get access to! [1] actually, I'm working in -stable, but at a quick glance the -current code is the same in this area. I have used the following hack to make it work for my purposes: % cvs diff -c vesa.c Index: vesa.c === RCS file: /repository/src/sys/i386/isa/vesa.c,v retrieving revision 1.15.2.5 diff -c -r1.15.2.5 vesa.c *** vesa.c 1999/04/16 15:58:21 1.15.2.5 --- vesa.c 1999/07/24 23:26:21 *** *** 777,783 } #endif /* 0 */ ! if (vesa_bios_set_mode(mode)) return 1; #if VESA_DEBUG 0 --- 777,784 } #endif /* 0 */ ! /* If mode has a linear buffer, enable use of it*/ ! if (vesa_bios_set_mode(info.vi_buffer ? (mode | 0x4000) : mode)) return 1; #if VESA_DEBUG 0 This currently does the right thing (at least on my hardware) because all the modes that syscons supports for character I/O don't have a linear mapping and hence those modes get set for windowed access as before. However, it's probably not the proper solution. The application for which I need this is to support capture from the bktr driver onto the screen (ie. so that you can watch TV without X). With the above hack and a small (100-line) program it works very nicely - far tidier than installing X just for this purpose on some embedded systems where I need this capability. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Linear buffers in VESA screen modes
Is there a plan for how to access the linear framebuffer in VESA video modes? So far as I can tell, the current[1] VESA code doesn't support enabling the linear framebuffer access at all, even though vidcontrol -i mode is happy to tell you the details of the buffers that you can't get access to! [1] actually, I'm working in -stable, but at a quick glance the -current code is the same in this area. Actually -CURRENT sets up the linear framebuffer if available. I have used the following hack to make it work for my purposes: [...] The vesa module in -CURRENT does basically the same as your patch. Kazu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Filesystem question...
Ronald G. Minnich wrote: On Fri, 23 Jul 1999, Kris Kennaway wrote: On Thu, 22 Jul 1999, Ronald G. Minnich wrote: Are you saying that as an ordinary user I can mount something on top of /tmp, for example? If the vfs.usermount sysctl is 1, and you have appropriate access to the thing you're trying to mount (block device, etc). OK, so let's say it is 1. Let's say I have appropriate access to /tmp. I mount my own fs on /tmp. I now have read/write access to everything anyone writes to /tmp. Appropriate access includes the idea that you need to own the mountpoint directory. If you have a system that's so badly run that arbitrary users own /tmp, then I'd say user mounts are the least of your problems :-) Or, let's say I don't have appropriate access to /tmp. Pick some other place. I mount my file system there for my files. Now everyone who wants can look for these user mounts and walk them at will. My private stuff is quite public. Correct (unless you want your private stuff to be private, and chmod your mountpoint's parent directory accordingly). But thanks for the note. I just now realized that if I add a private name space to v9fs (which is easy), and then turn on user mounts, user processes can have private name spaces on freebsd! I can't wait to see the security problems that causes when setuid executables assume that they only need to be worrying about one filesystem namespace. :-) - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Filesystem question...
On Sun, 25 Jul 1999, Mark Newton wrote: Ronald G. Minnich wrote: But thanks for the note. I just now realized that if I add a private name space to v9fs (which is easy), and then turn on user mounts, user processes can have private name spaces on freebsd! I can't wait to see the security problems that causes when setuid executables assume that they only need to be worrying about one filesystem namespace. :-) There shouldn't be any problems if mount enabled the flags for nosuid/nodev etc. if suser(p) != 0. - mark Mark Newton Email: new...@internode.com.au (W) Network Engineer Email: new...@atdot.dotat.org (H) Internode Systems Pty Ltd Desk: +61-8-82232999 Network Man - Anagram of Mark Newton Mobile: +61-416-202-223 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Filesystem question...
Mark Newton wrote: But thanks for the note. I just now realized that if I add a private name space to v9fs (which is easy), and then turn on user mounts, user processes can have private name spaces on freebsd! I can't wait to see the security problems that causes when setuid executables assume that they only need to be worrying about one filesystem namespace. :-) Yeah... it would be interesting to have a user-fs in which all executables where automatically chown to root, and setuid. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Your usefulness to my realm ended the day you made it off Hustaing alive. -- Sun Tzu Liao to his ex-finacee, Isis Marik To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
