Possible sequencing bug in vmspace_exec() and vmspace_unshare().
This is the code: p-p_vmspace = newvmspace; pmap_pinit2(vmspace_pmap(newvmspace)); vmspace_free(oldvmspace); if (p == curthread-td_proc)/* XXXKSE ? */ pmap_activate(curthread); What I don't understand is how the old vmspace can possibly be freed before the new map is activated. Wouldn't that clear out the pte's in the active MMU mapping? There seems to be a small window of opportunity where a TLB load could blow the kernel up. Shouldn't the vmspace_free() call occur after the pmap_activate()? -Matt ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM + Vinum
Lukas Ertl [EMAIL PROTECTED] writes: following the recent discussion about GEOM and Vinum I wrote some proof-of-concept code, or rather, I copy'n'pasted the necessary stuff for a prototype. Of course it's ugly, it's buggy, it's by far not complete, but at least it understands the most basic setup: a volume with a single plex and a single subdisk. This is great! DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
send(2) does not block, send(2) man page wrong?
The documentation for send(2) says
If no messages space is available at the socket to hold the message to be
transmitted, then send() normally blocks, unless the socket has been
placed in non-blocking I/O mode. The select(2) call may be used to
determine when it is possible to send more data.
I cannot get send (or sendto which is what is really interests me)
to block on FreeBSD 4.9. When I send as fast as I can to a socket,
send rapidly fails with ENOBUFS. I am not surprised that the kernel is
running out of mbufs but I am surprised that send does not block until
more become available.
Select does not block either. It always says that I can write to the
socket and then send fails with ENOBUFS.
The udp_output function in /sys/netinet/udp_usrreq.c, seems clear:
/*
* Calculate data length and get a mbuf
* for UDP and IP headers.
*/
M_PREPEND(m, sizeof(struct udpiphdr), M_DONTWAIT);
if (m == 0) {
error = ENOBUFS;
if (addr)
splx(s);
goto release;
}
There is no sign of send blocking waiting for a mbuf or of it returning
EAGAIN if the socket is non-blocking.
Is the documentation for send(2) wrong or is there some way to make
send and sendto block?
I have used setsockopt(s, SOL_SOCKET, SO_SNDBUF) to reduce the size
of the output queue for the socket but send still returns ENOBUFS and
never blocks or returns EAGAIN.
I note that send on Linux and Solaris blocks and that on these systems
select can be used to wait until the send will not block.
I have written a test program,
http://www.infres.enst.fr/~pook/send/server.c, that shows that send does
not block on FreeBSD. It does with Linux and Solaris.
thanks for your help
Stuart
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
mmap() on pseudo device
Hi, I am trying to share some memory between a networking daemon and the FreeBSD 5.1 kernel. I am trying to implement the shared memory using a pseudo-device via the make_dev() call. mknod at the command line prompt no longer seems to work(no longer supported because of the devfs interface? - it would be great if anyone could confirm this). My questions : 1. I'm creating a pseudo device and having a user space process mmap() the device memory into its address space. So the mmap for the device has to be implemented. Are there any useful driver/source files I could look at for this? 2. How can I access the mmaped memory from another kernel loadable module? 3. For the user space program, after it does a mmap() on the pseudo-device, is there any way it can force malloc() to operate on the mmaped memory? Or am I forced to write my own lightweight memory manager? Most of the memory managers around seem to be way too complicated to quickly fix or customize for a simple need. TIA, Anand ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
save-entropy in jail environment
Hi, do i need save-entropy cronjobs in a jail environment or is it useless? I experience heavy load when save-entropy runs, because there are many jails on the system. So i wondered about if i need this only on base system... Any ideas or hints, how to minimize the load? bye, Andy ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM + Vinum
On Tue, 20 Jan 2004, Dag-Erling Smørgrav wrote: Lukas Ertl [EMAIL PROTECTED] writes: following the recent discussion about GEOM and Vinum I wrote some proof-of-concept code, or rather, I copy'n'pasted the necessary stuff for a prototype. Of course it's ugly, it's buggy, it's by far not complete, but at least it understands the most basic setup: a volume with a single plex and a single subdisk. This is great! Thanks! I was actually hoping to get a little more feedback, since I'm not so sure if I'm going into the right direction, and I'd like to hear what people say about it before I dive into hacking it more, and there was virtually no feedback at all. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM + Vinum
Lukas Ertl wrote: On Tue, 20 Jan 2004, Dag-Erling Smørgrav wrote: Lukas Ertl [EMAIL PROTECTED] writes: following the recent discussion about GEOM and Vinum I wrote some proof-of-concept code, or rather, I copy'n'pasted the necessary stuff for a prototype. Of course it's ugly, it's buggy, it's by far not complete, but at least it understands the most basic setup: a volume with a single plex and a single subdisk. This is great! Thanks! I was actually hoping to get a little more feedback, since I'm not so sure if I'm going into the right direction, and I'd like to hear what people say about it before I dive into hacking it more, and there was virtually no feedback at all. regards, le If you were going in the wrong direction I'm sure there would be dozens of people who would have let you know. -- Jeremy Faulkner http://www.gldis.ca ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
Daniel == Daniel O'Connor [EMAIL PROTECTED] writes: Daniel On Friday 09 January 2004 10:04, Greg Shenaut wrote: In nuntio [EMAIL PROTECTED], Michel TALON divulgat: By the way, what's the reason that it is impossible to have just one floppy which boots FreeBSD kernel, allows to see an unbootable cdrom and continue installation from here? I agree. The boot floppy tries to do w a y too much. I think we should think of the boot floppy as way to implement an old-style console emulator: it boots and you tell it where to read the *real* boot image from. It should support all of the usual sources: CDs/DVDs, NFS mounts, FTP, and so on. Daniel *How* does it support all of those sources? CD/DVD drives Daniel need drivers (ATA optimisticly, but quite possibly SCSI), Daniel FTP/NFS need network card support, NFS needs nfsclient.ko You're missing the solution. It's right in front of you. For network drivers, support PXE, RTL and etherboot. PXE even provides the UDP portion of a TCP stack. For disks, use BIOS. No seriously. BIOS support for cdroms and hard disks is still maintained as it's required to support windoze installs. AFAIK, too, one cdrom driver works for all the modern drives, too. In fact, FreeDOS might be an excellent bootstrap platform. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
short analysys of qmail integer overflow bug - let there be light
Hey folks.
There are rumors out there that setting /var/qmail/control/databytes to
a reasonable value (for example 16384 = 16MB) will prevent the
possibility of exploitation regarding the integer overflow in function
blast().
That is not true.
This is how blast() is called:
void smtp_data() {
int hops;
unsigned long qp;
char *qqx;
if (!seenmail) { err_wantmail(); return; }
if (!rcptto.len) { err_wantrcpt(); return; }
seenmail = 0;
if (databytes) bytestooverflow = databytes + 1;
if (qmail_open(qqt) == -1) { err_qqt(); return; }
qp = qmail_qp(qqt);
out(354 go ahead\r\n);
received(qqt,SMTP,local,remoteip,remotehost,remoteinfo,fakehelo);
blast(hops);
hops = (hops = MAXHOPS);
if (hops) qmail_fail(qqt);
qmail_from(qqt,mailfrom.s);
qmail_put(qqt,rcptto.s,rcptto.len);
qqx = qmail_close(qqt);
if (!*qqx) { acceptmessage(qp); return; }
if (hops) { out(554 too many hops, this message is looping
(#5.4.6)\r\n); return; }
if (databytes) if (!bytestooverflow) { out(552 sorry, that message
size exceeds my databytes limit (#5.3.4)\r\n); return; }
if (*qqx == 'D') out(554 ); else out(451 );
out(qqx + 1);
out(\r\n);
}
So you see, the input value is only checked against the databytes limit
*after* the function blast() is called. The overflow resides in function
blast(), thus even setting databytes to 1 (lowest possible value) will
not prevent the overflow to happen. People should not comment a bug
without reading the code. (not from this mailing list).
The simplest way to fix is to define pos variable as unsigned int
instead of int, in the blast() function.
What happens in blast()? Here what happens:
Input is read byte by byte, and if input byte != '\n', then pos is
incremented. This is a neverending loop, without any logical tests.
Thus, pos gets an upper-bounds overflow and becomes negative (because
it is a signed integer). If it is defined as unsigned, it simply becomes
0, and keeps being incremented in a neverending circle loop, untill the
first '\n' is met. This renders any hack attack useless. DOS is
possible, but DOS is possible in many other more effective ways. It's
the way of the Internet protocols.
This is the original blast() function:
void blast(hops)
int *hops;
{
char ch;
int state;
int flaginheader;
/* my comment here: unsigned int pos */
int pos; /* number of bytes since most recent \n, if fih */
int flagmaybex; /* 1 if this line might match RECEIVED, if fih */
int flagmaybey; /* 1 if this line might match \r\n, if fih */
int flagmaybez; /* 1 if this line might match DELIVERED, if fih */
state = 1;
*hops = 0;
flaginheader = 1;
pos = 0; flagmaybex = flagmaybey = flagmaybez = 1;
for (;;) {
substdio_get(ssin,ch,1);
if (flaginheader) {
if (pos 9) {
if (ch != delivered[pos]) if (ch != DELIVERED[pos])
flagmaybez = 0;
if (flagmaybez) if (pos == 8) ++*hops;
if (pos 8)
if (ch != received[pos]) if (ch != RECEIVED[pos])
flagmaybex = 0;
if (flagmaybex) if (pos == 7) ++*hops;
if (pos 2) if (ch != \r\n[pos]) flagmaybey = 0;
if (flagmaybey) if (pos == 1) flaginheader = 0;
}
++pos;
if (ch == '\n') { pos = 0; flagmaybex = flagmaybey = flagmaybez = 1; }
}
switch(state) {
case 0:
if (ch == '\n') straynewline();
if (ch == '\r') { state = 4; continue; }
break;
case 1: /* \r\n */
if (ch == '\n') straynewline();
if (ch == '.') { state = 2; continue; }
if (ch == '\r') { state = 4; continue; }
state = 0;
break;
case 2: /* \r\n + . */
if (ch == '\n') straynewline();
if (ch == '\r') { state = 3; continue; }
state = 0;
break;
case 3: /* \r\n + .\r */
if (ch == '\n') return;
put(.);
put(\r);
if (ch == '\r') { state = 4; continue; }
state = 0;
break;
case 4: /* + \r */
if (ch == '\n') { state = 1; break; }
if (ch != '\r') { put(\r); state = 0; }
}
put(ch);
}
}
One can see that pos is later used as an index for memory location. And
that's all folks. :) I say it is exploitable. Just an opinion.
Cheers to all,
Alin-Adrian Anton.
Below there is a small rfc821 line too long implementing patch:
--- qmail-smtpd.c.origMon Jun 15 13:53:16 1998
+++ qmail-smtpd.cMon Jan 19 23:29:35 2004
@@ -1,3 +1,15 @@
+/*
+*This is a patched version of qmail, implementing RFC 821 regarding
text line limitations.
+*Developed by Alin-Adrian Anton
([EMAIL PROTECTED],[EMAIL PROTECTED])
+*
+*You may remove this banner if it annoys you. This patch is public
domain, for the
+*benefit of the community.
+*
+*It also fixes an integer overflow in the blast() function.
+NOTE: it implements the most relaxed RFC821, as it is specified there.
+*/
+
+
#include sig.h
#include readwrite.h
#include stralloc.h
@@ -48,7 +60,6 @@
void die_control() { out(421 unable to read controls (#4.3.0)\r\n);
flush(); _exit(1); }
void
Curious problem w/ 5.2-RELEASE su
I have two systems which I recently upgraded from src to 5.2-RELEASE. (Both systems were upgraded from the same /usr/src tree) Everything seemed to be working fine until a little while ago this morning, when I started having this problem with /usr/bin/su: $ su - su in free(): error: chunk is already free Abort trap (core dumped) $ sudo sh $ id uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest) $ su - su in free(): error: chunk is already free Abort trap (core dumped) Does anyone have any idea what would be causing this? The MD5 hash of /usr/bin/su and all linked libraries are identical between the two systems, but /usr/sbin/su works just fine on the other host. dmesg reports nothing unusual on system startup. What can I do to fix this? Thanks in advance! -- Brian C. Ledbetter [EMAIL PROTECTED] http://www.shadowcom.net/brian/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM + Vinum
Lukas Ertl [EMAIL PROTECTED] writes: I was actually hoping to get a little more feedback, since I'm not so sure if I'm going into the right direction, and I'd like to hear what people say about it before I dive into hacking it more, and there was virtually no feedback at all. I've only had time to look at the diagram, not the code, but it looks to me like you're doing what I would have done myself (i.e. making a plex class, a volume class etc.) I'm not grog@ though, so it's still possible we're *both* wrong. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Curious problem w/ 5.2-RELEASE su
Additionally, I am seeing this message in syslog: Jan 20 10:48:26 tokyo su: in openpam_load_module(): no pam_wheel.so found though /usr/lib/pam_wheel.so - /usr/lib/pam_wheel.so.2 exists, and has the same md5 hash as on the working host. What am I missing here? On Tue, Jan 20, 2004 at 11:08:43AM -0500, Brian Ledbetter wrote: I have two systems which I recently upgraded from src to 5.2-RELEASE. (Both systems were upgraded from the same /usr/src tree) Everything seemed to be working fine until a little while ago this morning, when I started having this problem with /usr/bin/su: $ su - su in free(): error: chunk is already free Abort trap (core dumped) $ sudo sh $ id uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest) $ su - su in free(): error: chunk is already free Abort trap (core dumped) Does anyone have any idea what would be causing this? The MD5 hash of /usr/bin/su and all linked libraries are identical between the two systems, but /usr/sbin/su works just fine on the other host. dmesg reports nothing unusual on system startup. What can I do to fix this? Thanks in advance! -- Brian C. Ledbetter [EMAIL PROTECTED] http://www.shadowcom.net/brian/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Brian C. Ledbetter [EMAIL PROTECTED] http://www.shadowcom.net/brian/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: send(2) does not block, send(2) man page wrong?
On Monday, January 19, 2004, at 08:53 AM, Stuart Pook wrote: The documentation for send(2) says If no messages space is available at the socket to hold the message to be transmitted, then send() normally blocks, unless the socket has been placed in non-blocking I/O mode. The select(2) call may be used to determine when it is possible to send more data. I cannot get send (or sendto which is what is really interests me) to block on FreeBSD 4.9. When I send as fast as I can to a socket, send rapidly fails with ENOBUFS. I am not surprised that the kernel is running out of mbufs but I am surprised that send does not block until more become available. Select does not block either. It always says that I can write to the socket and then send fails with ENOBUFS. The udp_output function in /sys/netinet/udp_usrreq.c, seems clear: UDP does not have a need to block, so it does not. The UDP delivery 'promise' is best effort, and datagrams will get spilled anywhere along the route to the destination (no user crying over ...). If you use TCP, which has a need to block, your sending process will be blocked until both local and remote buffering space is available. You could make a case that the man page for 'send(2)' is either inaccurate or misleading. The problem is that 'send()' actually doesn't handle this; as your post indicates, the decision to block or fail a transmission is taken at the protocol level, and 'send()' is generally blind to that. Cheers, Justin -- Justin C. Walker, Curmudgeon-At-Large * Institute for General Semantics| If you're not confused, | You're not paying attention *--*---* ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM + Vinum
On Tue, 20 Jan 2004, Kevin Wooten wrote: I am partially done with a replacement (not vinum compatible), that will hopefully do the same thing in the end, and more. I am trying to make a vinum that is more GEOM-ish. What I am experimenting with is using mirror, and ccd to handle the mirroring and disk concatenation. Then writing a single geom_stripe module that will stripe (with or without parity data). Once this is finished, the GEOM config. should allow just about all the complex configurations imaginable, even more than vinum. The fine thing about GEOM is that it offers a whole bunch of new possibilities. I'm very interested to see a native GEOM RAID implementation, and I think Pawel is working on this one. I think we should really get together on a separate mailing list - is it time for freebsd-geom@ yet? regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM + Vinum
On Tue, 20 Jan 2004, Lukas Ertl wrote: On Tue, 20 Jan 2004, Kevin Wooten wrote: I am partially done with a replacement (not vinum compatible), that will hopefully do the same thing in the end, and more. I am trying to make a vinum that is more GEOM-ish. What I am experimenting with is using mirror, and ccd to handle the mirroring and disk concatenation. Then writing a single geom_stripe module that will stripe (with or without parity data). Once this is finished, the GEOM config. should allow just about all the complex configurations imaginable, even more than vinum. The fine thing about GEOM is that it offers a whole bunch of new possibilities. I'm very interested to see a native GEOM RAID implementation, and I think Pawel is working on this one. I'm currently trying to understand how GEOM works. I have no pros or cons on the code, eating it raw. I think we should really get together on a separate mailing list - is it time for freebsd-geom@ yet? I would be there. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ My 2 cents is to start building the house from the ground with the geom classes, then add on the algorithms from the existing vinum. and end up with the roof as is the the vinum configuration tool. Soeren Straarup | aka OZ2DAK aka Xride FreeBSD wannabe | FreeBSD since 2.2.6-R If you see the light at the end of the tunnel, then make sure it is not a train.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Possible sequencing bug in vmspace_exec() and vmspace_unshare().
On Tuesday 20 January 2004 04:35 am, Matthew Dillon wrote: This is the code: p-p_vmspace = newvmspace; pmap_pinit2(vmspace_pmap(newvmspace)); vmspace_free(oldvmspace); if (p == curthread-td_proc)/* XXXKSE ? */ pmap_activate(curthread); What I don't understand is how the old vmspace can possibly be freed before the new map is activated. Wouldn't that clear out the pte's in the active MMU mapping? There seems to be a small window of opportunity where a TLB load could blow the kernel up. Shouldn't the vmspace_free() call occur after the pmap_activate()? Looks like it. It also seems that for vmspace_exec(), the operation is always done on the current proc, so that XXXKSE check should be a KASSERT() instead. Hmm, seems I moved the vmspace_free()'s to where they are now in rev 1.201 (they used to be before the pmap_init2() call) I just didn't move them far enough it seems. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve = http://www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM + Vinum
Kevin Wooten [EMAIL PROTECTED] writes: Lukas Ertl wrote: I think we should really get together on a separate mailing list - is it time for freebsd-geom@ yet? Definitely! or some gyration thereof... freebsd-fs should be close enough for government work. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM + Vinum
On Tue, 20 Jan 2004, Kevin Wooten wrote: My 2 cents is to start building the house from the ground with the geom classes, then add on the algorithms from the existing vinum. and end up with the roof as is the the vinum configuration tool. My point is that with the GEOM config...who needs vinum config?? People should have a clean update path and FreeBSD has always respected POLA. What I know from the recent thread about vinum and GEOM, and given that there will be more upcoming changes to the I/O infrastructure, vinum is likely to be broken once FreeBSD 5.3 is out. The 5.3 branch should clearly be a -stable branch once again, and if we want people to finally upgrade from 4.x, they have to be able to do it without much fuss. So, providing a completely compatible geom_vinum is a must, IMHO. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: save-entropy in jail environment
Andy Hilker [EMAIL PROTECTED] wrote: Hi, do i need save-entropy cronjobs in a jail environment or is it useless? I experience heavy load when save-entropy runs, because there are many jails on the system. So i wondered about if i need this only on base system... Any ideas or hints, how to minimize the load? The random(4) device is per-kernel, not per-jail, so it's not useful for those processes to be running in jails at all. -- Brian Fundakowski Feldman \'[ FreeBSD ]''\ [EMAIL PROTECTED] \ The Power to Serve! \ Opinions expressed are my own. \,,\ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Discussion on the future of floppies in 5.x and 6.x
On Wednesday 21 January 2004 00:43, David Gilbert wrote: I agree. The boot floppy tries to do w a y too much. I think we should think of the boot floppy as way to implement an old-style console emulator: it boots and you tell it where to read the *real* boot image from. It should support all of the usual sources: CDs/DVDs, NFS mounts, FTP, and so on. Daniel *How* does it support all of those sources? CD/DVD drives Daniel need drivers (ATA optimisticly, but quite possibly SCSI), Daniel FTP/NFS need network card support, NFS needs nfsclient.ko You're missing the solution. It's right in front of you. For network drivers, support PXE, RTL and etherboot. PXE even provides the UDP portion of a TCP stack. For disks, use BIOS. No seriously. BIOS support for cdroms and hard disks is still maintained as it's required to support windoze installs. AFAIK, too, one cdrom driver works for all the modern drives, too. In fact, FreeDOS might be an excellent bootstrap platform. True.. Although I believe the loader could do it just as well and it's already imported :) (It uses the BIOS to read the kernel, and groks PXE, although I am hazy on the specifics) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Curious problem w/ 5.2-RELEASE su
Did you run mergemaster? I had this problem recently and when I run mergemaster everything worked fine. hth, Ganbold At 12:19 AM 21.01.2004, you wrote: Additionally, I am seeing this message in syslog: Jan 20 10:48:26 tokyo su: in openpam_load_module(): no pam_wheel.so found though /usr/lib/pam_wheel.so - /usr/lib/pam_wheel.so.2 exists, and has the same md5 hash as on the working host. What am I missing here? On Tue, Jan 20, 2004 at 11:08:43AM -0500, Brian Ledbetter wrote: I have two systems which I recently upgraded from src to 5.2-RELEASE. (Both systems were upgraded from the same /usr/src tree) Everything seemed to be working fine until a little while ago this morning, when I started having this problem with /usr/bin/su: $ su - su in free(): error: chunk is already free Abort trap (core dumped) $ sudo sh $ id uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest) $ su - su in free(): error: chunk is already free Abort trap (core dumped) Does anyone have any idea what would be causing this? The MD5 hash of /usr/bin/su and all linked libraries are identical between the two systems, but /usr/sbin/su works just fine on the other host. dmesg reports nothing unusual on system startup. What can I do to fix this? Thanks in advance! -- Brian C. Ledbetter [EMAIL PROTECTED] http://www.shadowcom.net/brian/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Brian C. Ledbetter [EMAIL PROTECTED] http://www.shadowcom.net/brian/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Using the struct cmsgcred in practice
Hey everyone, I'm working on an application that needs to make use of the cmsgcred structure, but am unable to find decent documenation on it -- the only code I have found using it (via Google) is in PostgreSQL, but it's abstracted through multiple layers (the server code, in any case -- the client code is quite straightforward). Would anybody be able to give me tips on what to send to the client to request the data? I've been able to find the code to read the code from the client and to get the client to send the response to the server. But any simple client/server someone could hack up demonstrating this principle solely (or software package that's more straightforward and less abstracted that PostgreSQL) would be greatly appreciated. Kind regards, Devon H. O'Dell ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mmap() on pseudo device
On Tuesday 20 January 2004 09:08, Anand Subramanian wrote: 1. I'm creating a pseudo device and having a user space process mmap() the device memory into its address space. So the mmap for the device has to be implemented. Are there any useful driver/source files I could look at for this? 2. How can I access the mmaped memory from another kernel loadable module? The bktr driver is probably reasonable to look at, although it needs contiguous address space and I suspect you don't. 3. For the user space program, after it does a mmap() on the pseudo-device, is there any way it can force malloc() to operate on the mmaped memory? Or am I forced to write my own lightweight memory manager? Most of the memory managers around seem to be way too complicated to quickly fix or customize for a simple need. Why would you want to malloc from your mmap'd region? Once you have mmap'd it you can validly read/write (subject to memory protections) without having to malloc it first. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GEOM + Vinum
On Tuesday, 20 January 2004 at 14:51:08 +0100, Lukas Ertl wrote: On Tue, 20 Jan 2004, Dag-Erling Smørgrav wrote: Lukas Ertl [EMAIL PROTECTED] writes: following the recent discussion about GEOM and Vinum I wrote some proof-of-concept code, or rather, I copy'n'pasted the necessary stuff for a prototype. Of course it's ugly, it's buggy, it's by far not complete, but at least it understands the most basic setup: a volume with a single plex and a single subdisk. This is great! Thanks! I was actually hoping to get a little more feedback, since I'm not so sure if I'm going into the right direction, and I'd like to hear what people say about it before I dive into hacking it more, and there was virtually no feedback at all. I'm sure you were expecting to hear from me. Sorry about that, but I've just got back from a very intensive conference, and I still have over 2000 messages to catch up on. I'm certainly very happy to see that you've done this work, and as soon as I get some time I'll try it out here. And to answer another message: yes, Vinum on FreeBSD *must* be adapted to GEOM. There's no other solution. Greg -- See complete headers for address and phone numbers. pgp0.pgp Description: PGP signature
Re: Discussion on the future of floppies in 5.x and 6.x
Daniel == Daniel O'Connor [EMAIL PROTECTED] writes: Daniel True.. Although I believe the loader could do it just as well Daniel and it's already imported :) Daniel (It uses the BIOS to read the kernel, and groks PXE, although Daniel I am hazy on the specifics) I think the loader understands PXE well and understands certain BIOS things well. I mentioned FreeDOS since it would understand some CDROM nuances well. AFAIK, the loader understood CDROMs to the extent that they emulated a floppy of some sort. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Curious problem w/ 5.2-RELEASE su
Thank you very much for the advice - it works perfectly after running mergemaster! I will slink away now, and remember to RTFM first next time. Sorry for the noise, all! :) On Wed, Jan 21, 2004 at 09:03:16AM +0800, Ganbold wrote: Did you run mergemaster? I had this problem recently and when I run mergemaster everything worked fine. hth, Ganbold At 12:19 AM 21.01.2004, you wrote: Additionally, I am seeing this message in syslog: Jan 20 10:48:26 tokyo su: in openpam_load_module(): no pam_wheel.so found though /usr/lib/pam_wheel.so - /usr/lib/pam_wheel.so.2 exists, and has the same md5 hash as on the working host. What am I missing here? On Tue, Jan 20, 2004 at 11:08:43AM -0500, Brian Ledbetter wrote: I have two systems which I recently upgraded from src to 5.2-RELEASE. (Both systems were upgraded from the same /usr/src tree) Everything seemed to be working fine until a little while ago this morning, when I started having this problem with /usr/bin/su: $ su - su in free(): error: chunk is already free Abort trap (core dumped) $ sudo sh $ id uid=0(root) gid=0(wheel) groups=0(wheel), 2(kmem), 3(sys), 4(tty), 5(operator), 20(staff), 31(guest) $ su - su in free(): error: chunk is already free Abort trap (core dumped) Does anyone have any idea what would be causing this? The MD5 hash of /usr/bin/su and all linked libraries are identical between the two systems, but /usr/sbin/su works just fine on the other host. dmesg reports nothing unusual on system startup. What can I do to fix this? Thanks in advance! -- Brian C. Ledbetter [EMAIL PROTECTED] http://www.shadowcom.net/brian/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Brian C. Ledbetter [EMAIL PROTECTED] http://www.shadowcom.net/brian/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] -- Brian C. Ledbetter [EMAIL PROTECTED] http://www.shadowcom.net/brian/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Real Time FreeBSD?!!!
Hi Anubis and Den! Anubis, I've translated the questions into what I understood. Den, do not hesitate to complain if I had it wrong. I would guess the original message was: - what is the roadmap of FreeBSD (new features)? - (I let this one to authorized people :-) ) - How can a real-time system be designed around FreeBSD? - I've seen many people that knew what a real-time system is but they had different views... It all depends on the type of application and the allowed reaction time, in the end. What do you want to do? If the POSIX extensions are OK, then go for it. FreeBSD is a nice system! - FreeBSD has a small kernel due to module support but how stable is this kernel? - let's say it's stable enough to serve as a secure Internet backbone and file server (that must say pretty much...) - What are the current issues? - See the release notes. anubis écrit: Dude, could you rephrase that? Its a bit hard to understand On Sun, 18 Jan 2004 04:09 pm, sam Long wrote: I have a system FreeBSD 5.1-p11. How will develop further FreeBSD? How real time is possible to make from FreeBSD operational system? I know, that in FreeBSD there are expansions real time of standard POSIX. I have a small kernel of system due to modules, but on how many stably such kernel? What problems can be?I have born all modules for limits of a kernel. Thank you for the help Den. __ Do you Yahoo!? Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes http://hotjobs.sweepstakes.yahoo.com/signingbonus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
