Re: easy way to crash freebsd
At 15:25 02/03/01 -0800, Alfred Perlstein wrote: On Fri, 2 Mar 2001, Dan Phoenix wrote: symbolic link /etc/resolv.conf to a non-existant filethrow a bunch of connections at it and watch it reboot. * Dan Phoenix [EMAIL PROTECTED] [010302 15:24] wrote: People asking me how this could be used as a local user. Well i guess if you wanted to you could find something root runs that writes to /tmp then umask resolv.conf and echo "" resolv.conf I am in no way supporting that...just answering a question. Try overwriting /dev/mem, it's much more interesting. There are a lot of other ways: - reboot - halt ... and the simplest of all: turn off the ON/OFF button. cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ipchains ported to FreeBSD
At 22:20 28/02/01 -0600, Dan Nelson wrote: In the last episode (Mar 01), jett tayer said: can ipchains / iptables be ported to FreeBSD... this is a suggestion if u dont mind. We've already got ipfw and ipfilter; why in the world would we need a third packet-filtering systam? :) add to this that ipchains will certainly be replaced by iptables! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where can I find out rules on blocking in threads?
At 17:21 26/02/01 -0800, Marc W wrote: hello! I'm running into a problem with some threading using pthreads in an application i'm writing for FreeBSD. The application basically 1. initializes some UI goo (but doesn't start any of it UP) using a GUI framework (Qt) 2. creates a FIFO, and then spawns a thread 3. this new thread then does: fifo = open(fifoPath, O_RDONLY); 4. after the new thread is spawned, the application is supposed to then continue initialization, showing the main window and continuing on happily. Now, the problem is that when step 3 above blocks on the open(2) call (as it should, since the other end of the pipe isn't opened yet), the whole application is frozen, and the main thread can't continue with GUI processing, and the app appears to die. What is goofy is that this works just fine under Linux. So, FreeBSD has slightly different blocking rules or something -- but I don't understand them. It also hangs under Solaris 8/Intel. So, the question is: how can I find out what these differences are and try to get around them. I'm using this to limit instances of my program to one, and need a named pipe instead of just a lock file so that new instances can communicate any arguments they might have been given, etc ... any suggestions? depens on how long it blocks? is it indefinitely blocking or for some time? in the latter, you might use a sleep() in the child before the open(). Does the parent wait for its child (the thread that does the open fifo thing)? can you provided a small piece of code that shows this behaviour? cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Where can I find out rules on blocking in threads?
It seems ther's a problem here:) the manpage of open states " disables thread rescheduling...". Is this the explanation? As far as I can tell, Posix requires that some function should not block the process, and lists open(), fcntl(), ... Are there any pthread gurus who could give us the real truth here? cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: warning in free():
Now having free() write to stdout/stderr isn't necessarily a good thing
for daemons. If the message goes through a socket, it'll be hard to
debug, which was the original intent.
I suggest having some way so that when a program becomes a daemon,
it can set some "silent-libc" or "libc messages go to logs" instead of
using stdout/stderr.
Wouldn't it not be cool if err() and warn() had the capability of using syslog
instead of a file or std* when needed. err_set_file allows one to use a file
instead. How about allowing the use of syslog?
At 16:16 22/02/01 +0300, Dmitry Dicky wrote:
Also, if you do something like:
void *ptr = malloc(size);
...
ptr++;
free() will complain about it.
Make sure you are not modifying ptr after it has been malloc()ed.
On 22-Feb-01 Alfred Perlstein wrote:
* Madhavi Suram [EMAIL PROTECTED] [010222 05:09] wrote:
Hi
I am running a C program in user space on FreeBSD 3.3 release. I got a
warning like this:
testing in free(): warning: modified (chunk-) pointer.
testing is the name of the executable I am running.
Could anyone tell me what this warning means? What may be the effect
of
this code when I shift it to kernel with due modifications?
It means you've most likely corrupted your malloc pool, meaning you've
written past/before the edge of an allocation you've done.
To fix it start being mor careful with pointers and checking array
bounds.
--
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
--
*
("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ
`6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys
(_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44
_..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia
(il),-'' (li),' ((!.-' +7 (812) 3148860, 5585314
*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: warning in free():
At 18:37 22/02/01 +0200, diman wrote: Open AF_UNIX socket to syslogd and then use err_set_file() to redirect all err/warn messages to syslogd instead of stdin/stdout. That should help you debug daemons. I agree, but one of the nice things about syslog interface is that it hides all the socket/device stuff. so getting back to the socket api is somewhat unsatisfactory. Also, I think having this directly in err() and warn() and friends would be more elegant. and this doesn't seem hard to do. something like using a function pointer to use fprintf or syslog, and an additionnal void* to use either err_file or syslog priority. Does this sound ok or is it an unuseful complication of code? cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Staticaly allocated buffers in library. Is it correct?
At 12:46 19/02/01 -0800, Matt Dillon wrote: Yes, but we are talking about simple stupid config files here. Programs which actually tokenize an input stream typically do not use fgets(). Tokenizers either use [f]lex, [f]getc(), read() (and handle the buffering themselves), or mmap(). I used the tokenize() just as an example. I consider that every program that reads a line thinks it is a line and that the next fgets will read the _next_ line. but fgets doesn't guarantee that. so we have the following alternatives: - assume the file is well formed (no too long lines). - check that the lines are not too long. I personally prefer the second alternative. It has a cost, but this is more robust. How many times have we seen things assumed for some time, and then the code reused by someone else in another purpose but failing to check that the assumptions are no more true. This has often resulted in security problems. So I'd go for "trust BUT control". and this is even more important in library functions. cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: postfix: No buffer space available
You might want to try setting
net.inet.tcp.sendspace
net.inet.tcp.recvspace
to larger values. I have these in my /etc/sysctl.conf.
regards,
mouss
At 15:28 20/02/01 +0100, Len Conrad wrote:
Sorry to bother you hackers again, but two submissions to -questions got
no response so it looks like another scaleability issue on you people can
handle :
On a very busy postfix relay hub, we're seeing this:
Feb 19 15:00:16 imgate2 postfix/smtpd[323]: fatal: socket: No buffer
space available
Feb 19 15:00:17 imgate2 postfix/smtp[684]: fatal: socket: No buffer
space available
Can we fix this with a systcl write?
The server already has:
# sysctl -a | grep maxfile
kern.maxfiles: 16384
kern.maxfilesperproc: 16384
... which fixed "fatal: too many files open" pb for this client last November.
btw, Wietse Venema himself asked me to be informed of how I manage to
tweak FreeBSD to handle this apparent scaleability issue.
"sysctl -a"
gives:
kern.ostype: FreeBSD
kern.osrelease: 4.1.1-RELEASE
kern.osrevision: 199506
kern.version: FreeBSD 4.1.1-RELEASE #0: Tue Sep 26 00:46:59 GMT 2000
[EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC
kern.maxvnodes: 32525
kern.maxproc: 532
kern.maxfiles: 16384
kern.argmax: 65536
kern.securelevel: -1
kern.hostname: imgate2.snip.net
kern.hostid: 0
kern.clockrate: { hz = 100, tick = 1, tickadj = 5, profhz = 1024,
stathz = 128 }
kern.posix1version: 199309
kern.ngroups: 16
kern.job_control: 1
kern.saved_ids: 0
kern.boottime: { sec = 982608649, usec = 136401 } Mon Feb 19 13:50:49 2001
kern.domainname:
kern.osreldate: 411000
kern.bootfile: /kernel
kern.maxfilesperproc: 16384
kern.maxprocperuid: 531
kern.dumpdev:
kern.ipc.maxsockbuf: 262144
kern.ipc.sockbuf_waste_factor: 8
kern.ipc.somaxconn: 128
kern.ipc.max_linkhdr: 16
kern.ipc.max_protohdr: 60
kern.ipc.max_hdr: 76
kern.ipc.max_datalen: 136
kern.ipc.nmbclusters: 1024
kern.ipc.semmap: 30
kern.ipc.semmni: 10
kern.ipc.semmns: 60
kern.ipc.semmnu: 30
kern.ipc.semmsl: 60
kern.ipc.semopm: 100
kern.ipc.semume: 10
kern.ipc.semusz: 92
kern.ipc.semvmx: 32767
kern.ipc.semaem: 16384
kern.ipc.shmmax: 4194304
kern.ipc.shmmin: 1
kern.ipc.shmmni: 96
kern.ipc.shmseg: 64
kern.ipc.shmall: 1024
kern.ipc.shm_use_phys: 0
kern.ipc.mbuf_wait: 32
kern.ipc.mbtypes: 460 164 160 0 0 0 0 0 0 0 0 0 0 0 0 0
kern.ipc.nmbufs: 4096
kern.ipc.maxsockets: 1064
kern.dummy: 0
kern.ps_strings: 3217031152
kern.usrstack: 3217031168
kern.logsigexit: 1
kern.cam.cd.changer.min_busy_seconds: 5
kern.cam.cd.changer.max_busy_seconds: 15
kern.fallback_elf_brand: 9
kern.init_path: /sbin/init:/sbin/oinit:/sbin/init.bak:/stand/sysinstall
kern.module_path: /;/boot/;/modules/
kern.acct_suspend: 2
kern.acct_resume: 4
kern.acct_chkfreq: 15
kern.timecounter.method: 0
kern.timecounter.hardware: i8254
kern.ps_arg_cache_limit: 256
kern.ps_argsopen: 1
kern.fast_vfork: 1
kern.randompid: 0
kern.ps_showallprocs: 1
kern.shutdown.poweroff_delay: 5000
kern.shutdown.kproc_shutdown_wait: 60
kern.sugid_coredump: 0
kern.coredump: 1
kern.corefile: %N.core
kern.quantum: 10
kern.ccpu: 1948
kern.fscale: 2048
kern.devstat.numdevs: 7
kern.devstat.generation: 7
kern.devstat.version: 4
kern.nselcoll: 60034
kern.consmute: 0
kern.filedelay: 30
kern.dirdelay: 29
kern.metadelay: 28
kern.chroot_allow_open_directories: 1
vm.loadavg: { 0.39 0.43 0.52 }
vm.v_free_min: 886
vm.v_free_target: 2906
vm.v_free_reserved: 248
vm.v_inactive_target: 4359
vm.v_cache_min: 2906
vm.v_cache_max: 5812
vm.v_pageout_free_min: 34
vm.pageout_algorithm: 0
vm.swap_enabled: 1
vm.swap_async_max: 4
vm.swap_idle_threshold1: 2
vm.swap_idle_threshold2: 10
vm.v_free_severe: 567
vm.stats.sys.v_swtch: 15651300
vm.stats.sys.v_trap: 1045137
vm.stats.sys.v_syscall: 53830549
vm.stats.sys.v_intr: 19460810
vm.stats.sys.v_soft: 3519936
vm.stats.vm.v_vm_faults: 610808
vm.stats.vm.v_cow_faults: 138115
vm.stats.vm.v_cow_optim: 0
vm.stats.vm.v_zfod: 310288
vm.stats.vm.v_ozfod: 309994
vm.stats.vm.v_swapin: 0
vm.stats.vm.v_swapout: 0
vm.stats.vm.v_swappgsin: 0
vm.stats.vm.v_swappgsout: 0
vm.stats.vm.v_vnodein: 374
vm.stats.vm.v_vnodeout: 0
vm.stats.vm.v_vnodepgsin: 2490
vm.stats.vm.v_vnodepgsout: 0
vm.stats.vm.v_intrans: 2
vm.stats.vm.v_reactivated: 125
vm.stats.vm.v_pdwakeups: 0
vm.stats.vm.v_pdpages: 0
vm.stats.vm.v_dfree: 0
vm.stats.vm.v_pfree: 355480
vm.stats.vm.v_tfree: 809980
vm.stats.vm.v_page_size: 4096
vm.stats.vm.v_page_count: 127974
vm.stats.vm.v_free_reserved: 248
vm.stats.vm.v_free_target: 2906
vm.stats.vm.v_free_min: 886
vm.stats.vm.v_free_count: 97173
vm.stats.vm.v_wire_count: 8879
vm.stats.vm.v_active_count: 11659
vm.stats.vm.v_inactive_target: 4359
vm.stats.vm.v_inactive_count: 10259
vm.stats.vm.v_cache_count: 4
vm.stats.vm.v_cache_min: 2906
vm.stats.vm.v_cache_max: 5812
vm.stats.vm.v_pageout_free_min: 34
vm.stats.vm.v_interrupt_free_min: 2
vm.stats.misc.zero_page_count: 70388
vm.stats.misc.cnt_prezero: 376460
vm.max_proc_mmap: 36401
vm.pageout_stats_max: 2906
vm.pageout_ful
Re: COPTFLAGS without -O in /etc/make.conf breaks kernel make
At 05:51 20/02/01 +0100, Cyrille Lefevre wrote: "Julian Stacey" [EMAIL PROTECTED] writes: Here's a weirdness in 4.2-RELEASE kernel generation: - Compiling a GENERIC kernel _Without -O optimiser causes a broken make ! - Compiling a GENERIC kernel _With_ -O optimiser compiles OK. this question is cyclic. and yes, the kernel *have* to be compiled w/ -O turned on. sorry, I don't remember why. if you want yo put something to COPTFLAGS, try something like this : As far as I know, "-O" is necessary because of the "-Wuninitialized" option. but I'm not sure if removing the latter will make you able to compile without -O. cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: postfix: No buffer space available
At 11:34 20/02/01 -0700, Drew Eckhardt wrote: These control the default socket buffer size. Assuming postfix is not setting the appropriate socket options, when they are increased space will run out with even fewer connections. If they are decreased such that they are less than the bandwidth delay product, you will have TCP/IP performance problems. The original poster needs to play with some of the kern.ipc values instead, most notably kern.ipc.maxsockbuf. You're right. a quick check shows that ENOBUFS may be caused by too many things, including mbuf allocation failures, and even the network interface queue has its "word"... cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Staticaly allocated buffers in library. Is it correct?
Hi Matt,
At 09:23 19/02/01 -0800, Matt Dillon wrote:
Yes. System libraries traditionally use statically allocated buffers
because, even now, there is no dynamic equivalent for fgets(). The
closest you can get is to mmap() the file and extract the lines that
way.
But as long as the buffer sizes are reasonable and the library uses
fgets() with the proper length limitation, using a statically allocated
buffer is not a big deal. Most configuration files couldn't have long
lines and still be legal anyway.
Note that the classical loop
while (fgets(buf, n, fp) != NULL) {
tokenize(buf, args...);
...
}
may have problems if the line is too long, so one needs to detect it by
looking for the '\n'. if none is found, then one can either abort on error
or ignore the line. In the latter case, you need to read the remaining chars
so that the next fgets won't get them.
regards,
mouss
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Bug in creating ICMP error messages in FreeBSD4.2
At 14:25 19/02/01 +0200, [EMAIL PROTECTED] wrote: Hi, I encountered the following problem in the 4.2 version. In ip_forward, the following lines intend to save the mbuf in case we want to send ICMP error later: mcopy = m_copy(m, 0, imin((int)ip-ip_len, 64)); if (mcopy (mcopy-m_flags M_EXT)) m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); Later on, before sending the ICMP packet we do: if (mcopy-m_flags M_EXT) m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t)); The problem as I understand it is that the m_copydata and m_copyback, actually do nothing (It just copies from mcopy to itself). I'm speaking from memory, so don't take this for more than it is:) As far as I understand: m_copym copies the mbuf, but if there is external storage, only pointers are copied. so you get two mbuf chains with a common external storage. m_copydata will copy the external storage. that's why there are both m_copym and m_copydata. so while m_copydata(mcopy, (mcopy...)) is surprising, it's not nothing. it copies the data pointed to in mcopy. cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: soft updates and qmail (RE: qmail IO problems)
At 21:25 07/02/01 +1000, Greg Black wrote: Tony Finch wrote: Why not just use rename(2)? To protect against the new filename already existing? Why not just read the man page for rename(2) before making suggestions? I find nothing convincing in the manpage. Could you please tell what I am missing. - both rename and link require the files to be on the fs - both rename and the link/unlink guarantee the existence of the file whatever happens so what's the motivation except old heritage of possibly broken rename()? or is it just because qmail developper have seen that in the fwtk code? regards, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: echo request deny
At 12:05 06/02/01 +, milunovic wrote: Is there anyway to deny echo request on FreeBSD (except ipfw add deny icmp from any to any) ? On Linux It was simple,just echo 1/proc/.../icmp_echo_request 'ifconfig ifacename down' does the same, and even more. just kidding:) I don't see a valid reason to block echo req in an absolute manner. Doing it on a per-rule basis (such as for some source hosts) seems to me to be the right way. and this is currently only handled by IP filtering engines, which again seems to be the right way. Or may be do you have a motivation that I missed? If you're having script kiddies trying to ping hosts in order to attack'em, you'll certainly want to block more than just echo requests, so ipfw or ipf are worth the pain. Otherwise, they can replace ping with traceroute, telnet, netcat, or do you mean you want to prohibit using ping on the host itself so that your users do not ping other hosts? then change the permissions of /sbin/ping (and any other equivalent prog. it must be setuid to use raw sockets, so they can't just compile one and use it). regards, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: POSIX mutexes on FreeBSD
At 11:20 02/02/01 -0800, Jeffrey D. Wheelhouse wrote: Hi, While porting a project from Solaris to FreeBSD 4.2, I found out that the existing FreeBSD implementation of POSIX mutexes doesn't support sharing mutexes between processes. In order to get around this, I eventually did my own implementation of mutexes that works within the uthread framework and supports the PTHREAD_PROCESS_SHARED attribute. do you mean that the "PTHREAD_PROCESS_SHARED", pthread_mutexattr_getpshared and the like do not currently work? dunno if they were there before, but they are in current. so you might want to check. cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
At 02:01 29/01/01 -0500, Garance A Drosihn wrote: Mouss [EMAIL PROTECTED] mentioned that NetBSD has a closeall function in it's libc, and it sounded like he was going to mimic that instead of the fcntl change. If I were going to mimic something, I'd rather mimic netbsd than some feature which exists only in AIX. And as I mentioned in my previous message, I think the AIX strategy warps the definition of the fcntl routine, so I was not too fond of it even if there hadn't been any BSD-based alternative to follow. -- I fully agree that we'd better mimic netbsd than aix... but the netbsd closeall() is just a libc function that calls close() for all descriptors. so we can still mimic it with: #define closeall(start) fcntl(start, F_CLOSEM, 0) and with this, we have both netbsd and aix compat. note that if I do it for freebsd, I'll do the same for netbsd and openbsd (I'm a fan of *BSD convergence [I don't mean they should be the same, but unjustified diffs should be killed whenever possible]:). As for the "generic" syscall mechanism, I'd love it. I think that there are many places where "names" would be good, instead of hardcoded numbers. The only problem is to find a way to do that without reducing performance. names are good. just try to see what it would be if filenames were replaced by inodes. I think that having a name-based mechanism makes it easier to add new syscalls or reject deprecated ones. Now this is not restricted to syscalls. there are other places. for examaple, we could have device names that are "user" configurable, instead of the ef0, npx0, and the like. for network interfaces, I'd suggest adding a field "title" so that one can do: # ifconfig external instead of something like "ifconfig fxp0". While this is of limited use in ifconfig (the guy who uses ifconfig should know what he is doing), this would be useful when configuring firewalls and the like. Indeed, it means a thing to block some packets received by "external" interface than by "ef0". While the guy might change the interface and replace an ef0 with a xl1, the "external" concept is still the same. back to the closeall, here is what I suggest: - add the fcntl option. the coherence arg is certainly reasonable, but fcntl is not a "cohrent" function (thanks to svr4 lobbying into posix:). - add a closeall macro to call it. this gives both aix and netbsd compat (and if the fcntl thing goes into netbsd, the compat would be full). cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
At 10:37 28/01/01 -0800, Luigi Rizzo wrote:
generic_syscall("fdcloseall", );
In this way it would be clear what the non-portable pieces of code
are, and the mechanism would be extensible with no changes to
libraries and syscalls. You could even have dynamically-loaded
modules implementing new "syscalls".
I see a meachanism like
new_syscall(str, args) = syscall(hash(str), args)
where hash() is chosen to guarantee unicity (that wouldn't be hard to find).
we then have both performance (working with indexes instead of comparing
strings) like what is currently available, and the flexibility of strings.
Note that this goes in the same dynamic "wind" than loadable modules and
the like: static gets old...
cheers,
mouss
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
At 09:37 29/01/01 -0800, Matt Dillon wrote: This is a bad idea. One of the reasons why it is so easy for us to write portability modules for Sun, Linux, etc... is because of the hard-coded syscall numbers. Syscalls work plenty well enough as they are now, we do not need a new mechansm. true, but if the same idea gets adopted by those many OSes, then it's a benefit for them all. just how PAM came: it was non-portabble before adoption! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
At 08:57 29/01/01 -0800, Luigi Rizzo wrote:
hi,
i have to admit i am not too much into theory of hashing, but i am
unclear on how a perfect hash function can be simpler than "the
obvious method" when the namespace is changing dynamically because
modules are added or deleted.
(the obvious method would be a cheap hash on 2-4 chars of
the name followed by a scan of the list in each hash slot.)
one way would be to rehash when a syscall is added. hopefully, you want spend
your time adding'em. but it is probable that even this is unneded, though
one still
needs to check.
for example, when adding named_syscall("foo", args), you compute
hash("foo") using
the "current hash function, you try to insert it, and if you have a
collision, you recompute
the hashes.
but, yes, this is over-engineering...
Hopefully the number of functions using this method is
small enough not to worry about the depth of the lists,
and the type of calls using this method is one where the amt
of work in the syscall itself is way larger than the matching cost.
yes, one can just strcmp() through the list. it's what filesystem code does
anyway,
and there are far more files than there are syscalls.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
At 12:28 29/01/01 -0500, Garrett Wollman wrote: On Sun, 28 Jan 2001 12:45:10 -0800 (PST), Luigi Rizzo [EMAIL PROTECTED] said: kind-of, though the function name should be a string and not an integer (easier to extend/allocate), and it should allow return values in user-supplied buffers, same as ioctl/fcntl calls do. dlsym() you mean at user level? That's certainly possible, but I think this is way more than we need. strcmp() is ok given the number of syscalls. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
I agree that breaking coherence is bad, though I find fcntl is the kind of functions to use when you don't have a more specific one:) then I'd propose int fdcloseall(int start); (I remember having seen some closeall() function in M$ windows I think there is such function in M$ windows, so while I didn't sell my soul to Bill, I don't see enough reason to choose a new one (that said, I'm not sure of the syntax and use there...). Note that unlike fcntl() change, this requires adding a syscall, and remaking libc. I'm gonna work on this (and put in the optimization idea suggested by Matt). regards, mouss On Sat, 27 Jan 2001, Garance A Drosihn wrote: [snip] void closeallfds(int start); While I understand that defining a new routine is more work than just adding a parameter to an existing routine, I do think it is more appropriate to have that new routine than to use fcntl for this. The description for fcntl says the first parameter is: a descriptor to be operated on by 'cmd' as described below. For the proposed F_CLOSEM command, it does not operate on the GIVEN fd, it operates on a whole bunch of OTHER fd's. This means that a program which calls fcntl with a cmd-argument which is different than the programmer thinks is being passed could cause some pretty painful-to-debug errors in sections of the program which have nothing to do with the section that has the bug. [snip] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
There is a closeall() in NetBSD libc (it's a loop on close()). I suggest using the same name, and adding the function for all the *bsd. On Sat, 27 Jan 2001, Garance A Drosihn wrote: [snip] On the other hand, I seem to remember this being done (in some other program, if not in lpr) because closeallfds *is* a system routine in some place or another. The intent of closeallfds is the same as what you have implemented, as it is: void closeallfds(int start); [snip] cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: packet redirection design problem [Divert Sockets Fragmentation revisited]
the "defrag all" feature of Linux solves the discussed problem, but can be improved. We do not need to defrag the packets. We just need to queue them. and, when the first frag has been received, we only need to save the informations necessary for filtering (ip header stuff + ports for TCP/UDP and other things for icmp or ) the algo might be something like: - if packet is not frag, do as usual and skip the frag stuff - find packet in fragments list - if not found, create a new list - if the list contains the infos on the ports (I am restricting myself to tcp/udp for simplicity, but any kind of infos may be used), then the packet is ready for filtering: the rule may be found and applied to the packet. we do not need to queue it. * if the packet is the last one, delete the list * if frag timeout, delete the list - if not, then - if packet contains the infos (first frag), then store them and find the filtering rule and apply it for all the packets queued in the list. - else, queue packet So the code would be like the reassembly one, except that: - packets are "delivered" (passed to filters and the rest of ip_input) when the first frag is received (I am assuming that the first frag contains the infos necessary for filtering). - to handle next frags, the infos (ip header stuff and ports or so) are still kept in the list. With this method, if fragments come in order, packets are never queued. (Note that linux is unfriendly here: it sends frags in reverse order...). cheers, mouss On Sat, 27 Jan 2001, Peter Pentchev wrote: Hmm isn't this exactly the issue that's addressed in the Linux kernel by the 'always reassemble the whole packet before processing' config option? Wouldn't this be good/desired behavior? Or am I on crack - is FreeBSD already doing this? From this discussion I gather it's not.. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
At 10:33 26/01/01 -0800, Matt Dillon wrote:
I think it is worth doing. A quick google search shows that
the linux folks discussed the AIX thingy in March 1999, but
I don't think they actually implemented. From the discussion,
it appears that the fcntl would be useful and (not having seen
your patches), almost certainly trivial to implement.
you're right. (I can resend it as a tar file...)
*** kern_descrip.c Fri Jan 26 19:42:18 2001
--- kern_descrip.c.new Fri Jan 26 20:24:07 2001
***
*** 364,369
--- 364,387
(caddr_t)(intptr_t)uap-arg, sizeof(fl));
}
return(error);
+
+ /* close all descriptors starting from a given value */
+ case F_CLOSEM:
+ {
+ i = uap-fd;
+
+ p-p_retval[0] = 0;
+ if ((unsigned)i = fdp-fd_nfiles) {
+ return (EBADF);
+ }
+ for (; i=fdp-fd_lastfile; i++) {
+ struct close_args uap; /* XXX. requires _SYS_SYSPROTO_H_ */
+ uap.fd = i;
+ close(p, uap);
+ }
+ return 0;
+ }
+
default:
return (EINVAL);
}
The F_CLOSEM is added to sys/fcntl.h
fcntl.diff
*** fcntl.h Fri Jan 26 20:24:45 2001
--- fcntl.h.new Fri Jan 26 20:25:39 2001
***
*** 156,161
--- 156,162
#define F_GETLK 7 /* get record locking
information */
#define F_SETLK 8 /* set record locking
information */
#define F_SETLKW9 /* F_SETLK; wait if blocked */
+ #define F_CLOSEM 10 /* close open fd's larger = arg
*/
/* file descriptor flags (F_GETFD, F_SETFD) */
#define FD_CLOEXEC 1 /* close-on-exec flag */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
packet redirection design problem [Divert Sockets Fragmentation revisited]
"IP filtering engines" that do something to packet based on rule matching have a problem when fragmentation comes to play. In the case of a "packet redirector' such as divert, the problem is that only the first fragment will match the rule, if the rule uses ports or whatever info contained in the payload. The problem occurs if the packet (that should match) is subject to change by the engine (either redirection, nat, blocking, ...) IP Filter handles such situation with specific code. It would be a nice thing if this is added to standard code so that packet filters writers do not need to add their own. Any opinions? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting default hostname to localhost
At 15:24 17/01/01 -0500, Robert Watson wrote: On the contrary, there are many applications that expect the results of a gethostname() to resolve, and point to the local machine. It's arguable that these applications are broken, but there are enough of them to raise consideration. They include lpd, sdr, and cvsup. Consider that currently you can't run the printer spooler if you don't have a hostname that resolves to an IP; you're right. but in my understanding, the problem was transient: get a hostname to make DHCP works. or am I wrong here? anyway, I have nothing against "locallhost", but then I'd suggest modifying getty to make it coherent. regards, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting default hostname to localhost
At 21:16 16/01/01 -0500, Robert Watson wrote: The nice thing about "localhost" is that it already appears in /etc/hosts, and is a relatively reserved name, so unlikely to conflict too much based on resolution order. I.e., amnesiac.res.cmu.edu is not an unlikely name. sure, but I consider that the "hostname" variable has nothing to do with resolution. you can call your host amnesiac and still "ping localhost" thanks to /etc/localhost. in other words, callin it "amnesiac" has nothing to do with "amnesiac.foo.bar". regards, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Protections on inetd (and /sbin/* /usr/sbin/* in general)
At 07:47 17/01/01 +0100, Walter W. Hop wrote: The exploit managed to start inetd, camped on the specified port I guess, if it doesn't exist already, that it wouldn't be so hard to create a small patch to the kernel, so that only processes owned by root, or a certain group of users (let's say "daemon"), were allowed to set up listeners... just make IPPORT_RESERVED equal to 65535:) but then how will he be able to run an unprivileged http server? As it was said before, trying to change permissions, delete unnecessary binaries is just to much work for not much benefit. that thing called "minimalism" has simply failed to be of a real usefulness (I am exagerating a bit, but the truth is not elsewhere). it's like saying "don't let us have a knife at home, in case a thief gets in". but then you're just frustrating yourself. real attackers come with their own tools. regards, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Setting default hostname to localhost
A look at /usr/src/libexec/getty/main.c shows the folowing: if (hostname[0] == '\0') strcpy(hostname, "Amnesiac"); so, coherence suggests that the default should be "Amnesiac". Othewise, you'll get different hostnames for dhcp (and the like), and getty sessions. regards, mouss At 11:45 12/01/01 -0800, Archie Cobbs wrote: There is an RFC that specifies a "private use" top level domain, analogous to 192.168.0.0/16, 10.0.0.0/8, etc. The domain is ".local" so any default ending in ".local" should not conflict. -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: pppd mkdir diff
These are probably cosmetic comments, but here they are anyway...
At 09:54 13/01/01 +, W.H.Scholten wrote:
+char *dirname(char *path) {
+ char *slash;
+
+ while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1 ] = 0;
if path is an empty string, you are accessing path[-1], which is dangerous.
Also, you're computing strlen too many times, and strlen is a loop
(while (*ptr) ptr++). so I suggest using a pointer to the string as in
/usr/bin/dirname/dirname.c. mainly:
if (*path == '\0') return "/"; /* if const is not ok, strdup("/") */
ptr = path;
while (*ptr) ptr++;
while ((*ptr == '/') (ptr path)) ptr--;
...
+
+ slash = strrchr(path, '/');
+ if (slash) {
+ *slash = 0;
+ while (path[ strlen(path)-1 ] == '/') path[ strlen(path)-1
] = 0;
you already did that (I mean trimming the trailing slashes).
Finally, I'd propose adding such a function (dirname) in a library (either libc
or say libfile) to allow code reuse. such a lib would contain functions
such as basename, dir_create (mkdir -p), so that the commands
mkdir, rmdir, cp, mv, ... etc call the lib functions instead of rewriting code.
regards,
mouss
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: pppd mkdir diff
At 14:50 16/01/01 +0200, Peter Pentchev wrote: As somebody already pointed out, there *is* a dirname(3) function, and even a dirname(1) cmdline utility to invoke it. oops. I'll need to stay current:) In a followup to Alfred's mkdir(1) commit, I sent a sample implementation of a direxname() function, which calls dirname(3) in a loop, and returns the longest existing path component. I'll get back to him shortly with a patch to mkdir(1) using direxname() to report a meaningful error message, something like "Cannot create /exists/nonex/foo/bar, nonexistent path components after /exists". In the meantime, attached is my first shot at direxname() implementation, using dirname(3)'s static buffer. I'm not convinced you really need to check which is the "largest" parent that exists. if /a doesn't exist, and I do a mkdir /a/b/c/d, just a "/a/b/c does not exist" is far sufficient. For me, if you ignore permissions and the like, the condition to create a directory is that its parent exists, whatever are his grand-parents. after the error is shown, one will anyway check which dirs exist. doing the stat() on all those just consumes time, with few benefits. on an NFS mounted fs, this would be just annoyiing sometimes. now if you really insist, I'd suggest doing the stat the other way: check the root, then its children, then the children of the latter... like in mkdir -p. at last, note that there might be race conditions while you stat(). but there is hardly a way to avoid'em. at least, a single stat() reduces the window of opportunity. regards, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Mounting a CDROM in freeBSD 4.2
and you must make sure your kernel is compiled with options CD9660 At 18:08 16/01/01 +0100, Philippe CASIDY wrote: The naming of the cdrom has changed from 3.x to 4.x. I do not remember the old name but the new name is /dev/acd0c for an ATAPI cdrom. So you must have in /etc/fstab something like... /dev/acd0c /cdrom cd9660 ro,noauto 0 0 Maybe you encounter this kind of trouble. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
At 20:29 29/12/00 +0100, Marco van de Voort wrote:
Perfect for your purposes. I, as user (and with some machines
running on FreeBSD), want to be able to rebuild the kernel at any
time, and fix myself when needed. I don't want any binary packages
that can cause trouble and delay days.
before working for a com company, I'm a BSD user, and my participation to
this list is from this point of view.
I've never asked for any modifications that would make user's life harder.
note that I've not asked for any modifs, I just "started" the question.
You mean some base support in makefiles to make patching easier?
In general: No problem with that.
well, I was meaning a patch to config and to some makefiles.
why config?
I find it annoying that config must be run in $arch/conf, with the exact config
filename, and that either one has to be root or he has to copy kernel sources.
the config program requires that you run it in ${sys}/$arch/conf and that
you give
it a "pure" filename. "config /sys/i386/conf/GENERIC" doesn't work!
This is because it needs three dirs: the ${sys}/$arch/conf, the ${sys}/conf and
the ${sys}/compile. but I still believe this is an old heritage that may be
easily
"fixed".
In specific cases: No.
As a BSD user, I'll never ask for specific stuff, be it for a company I
work for:)
my discussion was about how to ease 3d party stuff in BSD, not how to
make any company or anybody happy by any sacrificial modifs.
The problem I was talking about is that if every company modifies the
kernel sources
or the build procedure in its own way, then the least of the things that
happen is that
the modifications are not compatible, which is not good.
now, let's forget about companies and about any commercial entities.
There are things to improve in BSD (though it's perfect:). and among those,
the possibility for extensibility, be it by single developpers, by
commercial companies,
or by anyone on earth.
The question is not who does what, the real question is how anything is done.
if that is good, it's good and we oughtta take it. if it's bad, we'd better
reject it.
cheers,
mouss
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
RE: FreeBSD vs. Linux, Solaris, and NT
At 12:44 26/12/00 +0100, Marco van de Voort wrote: I ran into people at NASA who use Python because (beside being a good language) it isn't GPL. Pure paranoia. You don't have to share the code that is written IN Python. Only modifications TO python (if it were GPL) what if you read before you naswer? the guy said python isn't gpl'd, what seas are you swimming in? For legal and security reason they cannot share changes to code they make, so anything GPL is unusable. So are programs that run on Linux required to be open source? I need to know. You may only shared link to GPL'ed packages, and the rest is up to you. h'mmm' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Collecting waiting statistics (simulation question)
I hope you're patient to wait until 2019 to get an answer. or you'll probably correct your clock At 09:55 27/11/19 -0700, Jeff Rhyason wrote: Can anybody help me with a project I am working on? I am trying to simulate different memory allocation policies for a discrete event simulation course. Being the guy I am, I decided to collect some real statistics from a real system. The difficulty I've encountered is that I can't find how to make them accessible! Is there a way that I can log a large amount of statistics regarding kernel memory allocator activity and make that accessible to a user process? (Something like Solaris' crash(1m) and kmalog) Thanks in advance for any comments! -Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD vs Linux, Solaris, and NT
just wanna jump in while it's hot... I work for a commercial company, and I did what I could to convince people that *BSD is the way, and we're happily using FreeBSD. now, we modiy the kernel sources, and this is a problem since this changes the way people build the kernel. what we did is provide procedures to modify the kernel config file (GENERIC for example), conf/files and so, in order to build the kernel. While this is ok, it doesn't sound perfect to me. I'd love it if thrid party modifications were intended in the kernel sources. I'm ready to do the work. mainly, I'd propose some patches to config so that thrid party additions/modifications are made easier [the real problem is that when many companies modify the kernel. If they all do it as we do, then it's impossible. but if it's provided by the system, then it's easier]. regards, mouss At 21:45 27/12/00 +0200, Taavi Talvik wrote: On Wed, 27 Dec 2000, someone on freebsd-hackers wrote: They dont want your stinking binary contributions. Get used to it. Not suprisingly you're both wrong. Many binary-only ports exist in the FreeBSD ports tree. World is not black and white. There are binary ports (for example netscape). But there are no well defined procedures for including binary device drivers with FreeBSD. Even building modules outside /usr/src/sys/modules is not easy task. What about asking for additional driver modules on fresh install? Lack of well defined procedures for inclusion of binary only drivers is definitely our shortcoming. We are moving to right direction (kernel modules etc.), but we are not there yet. There are reasons for binary only drivers. For example - ADSL, it is coming more common, but supply chain is just too long. Card manufacturers are helpful, they provide programming information, but they are not free, they just can't ignore chipset suppliers (who are not ready for releasing some firmware yet). best regards, taavi To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ONTOPIC - FreeBSD vs Linux, Solaris, and NT - Not a bunch of licence Jihad crap
At 17:07 28/12/00 -0200, Rik van Riel wrote: On Wed, 27 Dec 2000, Jeremiah Gowdy wrote: If you slant your judgement so far against the other products, it makes you sound like you don't know what you're talking about (no offense). You need to point out the pros and cons of ALL three systems. Not just the pros of FreeBSD and the cons of Linux/Windows. Indeed. Not doing this makes the FreeBSD crowd look like a bunch of kids who shouldn't be taken seriously. Not only does this weaken FreeBSD (hey, not my problem), but it also weakens the opinion people have of the free unix systems in general ... which DOES create a problem for me (Linux is my fulltime job). OS comparison is hard and requires much resources and is after all a loss of time and energy. things get outdated very soon. now, one can still write a paper such as the one discussed here, without being asked to prepare a phd on which OS does what. I've seen more "fucking" stuff in the linux circles than in *BSD ones, and I've never found that this did any bad to anything. just check all those "doing this with linux" books. one of my favourites is "Linux application development" where the authors seem to acknowledge that everything has been invented in linux (so many "linux does a well a job at this", when it's an old unix functionality). But I'm not gonna sue'em. after all, win* books also keep claiming some of the super-modern-ntfs-andwhat-you-want things, and those guys at other companies do the same. so, that's likely to be a game, no? yes, if we all make efforts to make this world better, it'll be good. but we first have to agree, and that is the hard step cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: make(1) -DREMOTE?
and I guess you tried to compile it with this define and it didn't work! probably someone was working on it (or is he still working on it) to implement remote make jobs, aka dmake. so this is mostly "work in progress" or "unfinished". regards, mouss At 04:01 26/12/00 -0500, Will Andrews wrote: Hi all, I'm a bit confused about a certain "feature" in make(1). There is a compile-time option that can be enabled: -DREMOTE. This enables (as far as I can tell) some kind of remote job management capability. In three or four years that I've used FreeBSD (as well as other Unix variants), I've never seen this capability demonstrated. So, I'm wondering who uses it, and what purpose it serves. There is nothing in the manpage about this "feature". Thanks, -- wca To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen ..
On Wed, 20 Dec 2000, Peter Seebach wrote: In message [EMAIL PROTECTED], Aled Morris writes: Shouldn't you use "kill(0, SIGSEGV)" ? Gratuitously verbose! raise(SIGSEGV); what about abort()? isn't yet less chars to type? cheers, mouss To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
