Vinum Bootstrapping Article Reviewers Wanted
I'm working on an article that describes how to get started using Vinum (software RAID). After a gentle introduction, it takes the reader through the process starting with /stand/sysinstall and ending with a sever with mirrored volumes. It also covers several hardware failure scenarios and the recovery techniques needed to get a server back to normal. I'd like to make sure that the step-by-step procedures that it contains are correct for a wide audience. Folks experienced with Vinum could help by reviewing the article and commenting on subtleties I've missed. Vinum newbies could by providing a perspective that I lack. I'd particularly like to find reviewers who tried to get Vinum going in the past but gave up. You'll need to have access to a CPU on which you can do fresh FreeBSD installs. Anything better than a 486 with 8 MB of RAM should be ok as long as you can get to installation media. You'll need two or more disk drives of at least 500 MB or so. IDE or SCSI, mix & match are ok. The article is about 30 pages, so you'll need time to read it and try the procedures. I'd budget at least 2-3 hours, more if you'll have to scrape the hardware together. Comments returned to me in the next few days might make it into a version of the article that I hope will appear in the next print edition of the handbook. So if you have the necessary time, hardware, and inclination, please drop me a line and I'll get you a draft! Thanks, Bob To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [patch] extension of newsyslog
Toshihiko ARAI wrote: > Hello, > > I add script call features to newsyslog. This adds a one field to > newsyslog.conf. When newsyslog processed log file, this can execute > arbitrary program. > > Situation to assume: > * For the log file which cannot use signal. > * Cases to do statistical application for log file. > > A sample entry of newsylog.conf: > # logfilename [owner:group] mode count size when [ZB] [/pid_file] [sig_num] >[/program] > /var/log/foo.log bar:baz640 1 100 * Z - - /etc/foo.sh > > '-' is usable as a filler of null field. > > I used similar enhanced function from the past. I think that you can > apply this patch for 5-current. In addition, I can prepare a patch > for 4-stable if it is necessary. > > I ask for testing and a review of the following patches. it would be interresting to have the possibility to pass optional args to program. also, how about testing for the first (or the last) char to be & to run the program asynchronously ? much better, always run the program asynchronously so that hanging programs (who knowns?) don't block the whole process. to do this, somewhere in main(), add something such as signal(SIGCHLD, SIG_IGN) and delete the while statment in post_prog(). Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IPSEC code error
I haven't reviewed that particular piece of code for correctness, but noticed that the caching of the privilege check there actually does cause problems for a variety of reasons in my work. I'd much rather individual uses of suser() appeared in the netinet6 tree, and that appropriate context for the check was passed down the stack to where the knowledge of privilege is needed, rather than just the flag. Sometime, I'll get around to some diffs. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sat, 6 Oct 2001, Terry Lambert wrote: > On a related topic, there appears to be a code error in the > IPSEC code. > > Specifically, the priv flag is set to 1 if the user is root > and the socket is non-null (this lets the code be called > from the bridging code as well, so ignore the first half of > the "if" test, and concentrate on the "uid == 0" test). > > In the code that examines this flag, the comment is that it > is looking at whether or not the port is a priviledged port, > not whether or not the user who owns it is root. > > This implies that the "rootness" check improperly flags any > ports opened by root, regardless of whether or not they are > priviledged ports. > > Is the code where the flag is initialized correct, or is the > comment where the flag is observed correct? > > -- Terry > > 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: Heads up! My interview....
Looks like a great interview -- congrats :-). Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Mon, 8 Oct 2001, Wilko Bulte wrote: > On Mon, Oct 08, 2001 at 12:31:15PM -0700, Matt Dillon wrote: > > OSNews interviewed me, it's up in today's page! I think it's a really > > good interview but, of course, I am biased :-) > > > > http://osnews.com/story.php?news_id=153 > > Really interesting reading! > > -- > | / o / /_ _ email: [EMAIL PROTECTED] > |/|/ / / /( (_) Bulte Arnhem, The Netherlands > > 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: Heads up! My interview....
On Mon, Oct 08, 2001 at 12:31:15PM -0700, Matt Dillon wrote: > OSNews interviewed me, it's up in today's page! I think it's a really > good interview but, of course, I am biased :-) > > http://osnews.com/story.php?news_id=153 Really interesting reading! -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Heads up! My interview....
OSNews interviewed me, it's up in today's page! I think it's a really good interview but, of course, I am biased :-) http://osnews.com/story.php?news_id=153 On the side: Oh my god, they listed my personal web page! It's like having your parents show your friends your messy room! (read: I haven't been keeping it cleaned up.) 8-| -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: strange network performace
Thanks for the great help on this. It's hard to find any really good data on tweaking these kinds of things, to I mess with things (and go off suggestions from others) until I see benefits, and test from there. I haven't hit any problems from them yet, but I'm sure they are on their way. On this topic, I'm curious if you (or anyone for that matter) have any good FreeBSD tweaks to make NFS serving as good as it can be. Also, I actually do set the boot time sysctl's at boot time, I just neglected to mention that here :(. Thanks again! Eric Terry Lambert wrote: > > Eric Anderson wrote: > > > > Oh, well, I thought you said "10mb/s", not "10MB/s" .. that makes > > it a bit different. I wonder if it could still be a tcp window > > size or something.. Try these sysctl's on C: > > vfs.nfs.gatherdelay=0 > > vfs.nfs.async=1 > > vfs.vmiodirenable=1 > > Alfred stated that he had seen some strangeness with this. > > > kern.ipc.maxsockbuf=2097152 > > kern.ipc.somaxconn=8192 > > This won't work, unless it's done at boot time, since that's > where the zone sizes are initialized (should be read-only). > > > kern.ipc.maxsockets=16424 > > Also boot time (should be read-only) -- note that these > things are strange, as the UDP and TCP allocations don't > occur from the same space, so there are some which size > per-protocol structures, while others size per-system > structures. The distinction between global vs. protocol > specific isn't really clearly documented. > > > kern.maxfiles=65536 > > Also boot time (should be read-only). > > > kern.maxfilesperproc=32768 > > Just a soft limit -- can be done any time. > > > net.inet.tcp.rfc1323=1 > > net.inet.tcp.delayed_ack=0 > > net.inet.tcp.sendspace=65535 > > net.inet.tcp.recvspace=65535 > > net.inet.udp.recvspace=65535 > > Cranking up the space and the connections simultaneously will > make you need more than 2G of memory, max, for the sockets > for the window data, should the windows be full. Be very > careful, since it's possible to run out of memory and crash > the box doing this... for it to work, you'd need to have 4G > of RAM, and set the KVA space up to 3G (from the default of > 1G). THere are some bugs in /sys/i386/machdep.c as regards > overallocation with an alomost full memory map (mostly swap > related stuff for page tables that will no longer fit in the > address space, along with everything else). > > This is a good suggestion, but is fraught with peril, if the > system networking load goes very high (e.g. DDOS or other > attack). > > > net.inet.udp.maxdgram=57344 > > Probably no change for his application. > > > net.local.stream.recvspace=65535 > > net.local.stream.sendspace=65535 > > No change (UNIX domain sockets only). > > The other suggestions are good. > > -- Terry -- - Eric Anderson[EMAIL PROTECTED]Centaur Technology # rm -rf /bin/laden - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Some thoughts on if_ioctl()
< said: > Second, let's look at the handling of SIOCADDMULTI/SIOCDELMULTI. > There is code obviously taken from if_loop.c and used in some > drivers, which tries to do something with the third argument "data" > of the if_ioctl() driver method if "data" isn't NULL. The historic implementation passed SIOCADDMULTI directly down to the interface to implement, which resulted in lots of duplicated code all over the place to manage the list of multicast addresses. Several years ago, I rewrote the multicast management code to simply indicate to the driver when the list has changed, obviating the need for the driver itself to manage the list. > If I understand the kernel code right, if_ioctl()'s third argument > is always NULL Not so. Any ioctl() in class 'i' which is not handled by the generic code will get passed down to the driver to handle; some of these requests may require the data pointer. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: splx() overhead.
* John Baldwin <[EMAIL PROTECTED]> [011008 11:46] wrote: > > On 08-Oct-01 [EMAIL PROTECTED] wrote: > > In doing some kernel profiling analysis it seems that splx is taking up big > > chunks of time. > > That's becaause splx() can result in interrupts blocked during an spl() getting > a chance to run, including soft interrrupts such as softclock and the network > software interrupts. Note that splx itself is quick, it is the releasing of > interrupts which is expensive, which will only happen on the "outside" splx() > if you have nested spl's. It's not the releasing that's expensive, it's _running_ them in the context of the party that does the splx() that makes them look expensive. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: bleh. Re: ufs_rename panic
On Sun, Oct 07, 2001 at 06:09:45PM -0700, Kris Kennaway wrote: > On Fri, Oct 05, 2001 at 04:17:14PM -0700, Yevgeniy Aleynikov wrote: > > > And why FreeBSD security officer's email address always bounces my > > mail? > > Don't know, it's apparently still working fine for others. Wild guess: FreeBSD.org's anti-spam getting in your way? -- | / o / /_ _ email: [EMAIL PROTECTED] |/|/ / / /( (_) Bulte Arnhem, The Netherlands To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: strange network performace
Eric Anderson wrote: > > Oh, well, I thought you said "10mb/s", not "10MB/s" .. that makes > it a bit different. I wonder if it could still be a tcp window > size or something.. Try these sysctl's on C: > vfs.nfs.gatherdelay=0 > vfs.nfs.async=1 > vfs.vmiodirenable=1 Alfred stated that he had seen some strangeness with this. > kern.ipc.maxsockbuf=2097152 > kern.ipc.somaxconn=8192 This won't work, unless it's done at boot time, since that's where the zone sizes are initialized (should be read-only). > kern.ipc.maxsockets=16424 Also boot time (should be read-only) -- note that these things are strange, as the UDP and TCP allocations don't occur from the same space, so there are some which size per-protocol structures, while others size per-system structures. The distinction between global vs. protocol specific isn't really clearly documented. > kern.maxfiles=65536 Also boot time (should be read-only). > kern.maxfilesperproc=32768 Just a soft limit -- can be done any time. > net.inet.tcp.rfc1323=1 > net.inet.tcp.delayed_ack=0 > net.inet.tcp.sendspace=65535 > net.inet.tcp.recvspace=65535 > net.inet.udp.recvspace=65535 Cranking up the space and the connections simultaneously will make you need more than 2G of memory, max, for the sockets for the window data, should the windows be full. Be very careful, since it's possible to run out of memory and crash the box doing this... for it to work, you'd need to have 4G of RAM, and set the KVA space up to 3G (from the default of 1G). THere are some bugs in /sys/i386/machdep.c as regards overallocation with an alomost full memory map (mostly swap related stuff for page tables that will no longer fit in the address space, along with everything else). This is a good suggestion, but is fraught with peril, if the system networking load goes very high (e.g. DDOS or other attack). > net.inet.udp.maxdgram=57344 Probably no change for his application. > net.local.stream.recvspace=65535 > net.local.stream.sendspace=65535 No change (UNIX domain sockets only). The other suggestions are good. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ftp4.za.freebsd.org
Some of you might have been aware for a little while that ftp4.za.freebsd.org's FreeBSD mirror has been broken. That has, to a large extent been due to a total lack of space on Internet Solutions' ftp server. As a result, I've set up a separate machine, which is now carrying Internet Solutions' FreeBSD mirror, with ftp4.za.freebsd.org being pointed to that machine. The machine unfortunately does not have enough disk to carry a full mirror, but has everything except the ports directory from ftp.freebsd.org. Ciao, Geoff. -- Geoff Rehmet, Internet Solutions tel: +27-11-283-5462, fax: +27-11-283-5401 mobile: +27-83-292-5800 email: [EMAIL PROTECTED], [EMAIL PROTECTED] URL: http://www.is.co.za To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Debbuging hard lockups...
I can generate hard lockups on my SMP box pretty easily. When locked, it fails to respond to anything - I can't even get into the kernel debugger to fire up. The lockups don't happen on UP machines under the same conditions, so I can't even see if console debugging would work, because I don't have a second SMP machine to run the kernel on. I'm running 4.4-stable, and I'm looking for suggestions on how to deal with this, other than "don't do that". Debugging kernel options, maybe? Thanks, http://www.mired.org/home/mwm/ Q: How do you make the gods laugh? A: Tell them your plans. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: splx() overhead.
On 08-Oct-01 [EMAIL PROTECTED] wrote: > In doing some kernel profiling analysis it seems that splx is taking up big > chunks of time. That's becaause splx() can result in interrupts blocked during an spl() getting a chance to run, including soft interrrupts such as softclock and the network software interrupts. Note that splx itself is quick, it is the releasing of interrupts which is expensive, which will only happen on the "outside" splx() if you have nested spl's. > The mbuf macros call splimp()..splx() explicitly..are they required at > interrupt time? Is there a higher performance way of protecting the necessary > code? Not really. > B -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use 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: splx() overhead.
On Mon, Oct 08, 2001 at 12:08:14PM -0400, [EMAIL PROTECTED] wrote: > In doing some kernel profiling analysis it seems that splx is taking up big > chunks of time. > > The mbuf macros call splimp()..splx() explicitly..are they required at > interrupt time? Is there a higher performance way of protecting the necessary > code? Yes and yes. spl macros are now no-ops in current and are being replaced by locks which protect data structures. -- Brooks -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg29065/pgp0.pgp Description: PGP signature
Re: Change to ldscript.i386
Mark Peek wrote: > I made a change to page align the data segment on the powerpc port and I > noticed something strange with the i386 alignment. The data section appears > to be wasting space by aligning to the same address (offset) in the next > page rather than to the next page boundary. Below is the patch and a > before/after objdump of the kernel headers. The difference isn't that big > (no more than 4K) but my patch seems more correct. > > Am I missing any reason why it was done this way? If not, I'll apply the > patch to -current. It is sone this way because that's the way standard ELF files are laid out. Using the same next address means that you dont have to put padding in the file itself, and can simply double map the same page when loading executables. Before: Idx Name Size VMA LMA File off Algn 17 set_vga_set 001c c0398248 c0398248 00298248 2**2 18 .data 00049d20 c0399280 c0399280 00298280 2**5 Note the file offset from section 17 -> 18 is increased by 28 bytes. After: Idx Name Size VMA LMA File off Algn 17 set_vga_set 001c c0398248 c0398248 00298248 2**2 18 .data 00049d20 c0399000 c0399000 00299000 2**5 Now the file offset is increased by 3512 bytes instead of 28 bytes. But note that also the virtual address of .data is lower. Anyway, that is why it was done that way. What is or isn't good for application executables doesn't necessarily apply to the kernel since it isn't demand paged. In the kernel case the larger file size may actually end up using one less page of actual memory for the kernel data segment. However, I seem to recall Bruce telling me once that the 4MB page implementation breaks something with the text read-only protection, so doing any roundup at all is probably futile. Incidently, I have long been tempted to make a similar change to the *userland* elf executable layout. I think this will significantly speed up executable exec() times since we wont have to do the silly BSS pre-zero on the bounary page, which will case an out-of-order page read. If the VM system supported a "post faultin" callback hook we could avoid that. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
[patch] extension of newsyslog
Hello,
I add script call features to newsyslog. This adds a one field to
newsyslog.conf. When newsyslog processed log file, this can execute
arbitrary program.
Situation to assume:
* For the log file which cannot use signal.
* Cases to do statistical application for log file.
A sample entry of newsylog.conf:
# logfilename [owner:group] mode count size when [ZB] [/pid_file] [sig_num] [/program]
/var/log/foo.log bar:baz640 1 100 * Z - - /etc/foo.sh
'-' is usable as a filler of null field.
I used similar enhanced function from the past. I think that you can
apply this patch for 5-current. In addition, I can prepare a patch
for 4-stable if it is necessary.
I ask for testing and a review of the following patches.
Thanks.
--
Toshihiko ARAI
Index: newsyslog.8
===
RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.8,v
retrieving revision 1.32
diff -u -r1.32 newsyslog.8
--- newsyslog.8 2001/07/30 15:17:17 1.32
+++ newsyslog.8 2001/09/30 08:54:07
@@ -76,7 +76,7 @@
Each line of the file contains information about a particular log file
that should be handled by
.Nm .
-Each line has five mandatory fields and four optional fields, with
+Each line has five mandatory fields and five optional fields, with
whitespace separating each field. Blank lines or lines beginning with
``#'' are ignored. The fields of the configuration file are as
follows:
@@ -294,12 +294,28 @@
.Ar signal_number
is sent the process id contained in this
file. This field must start with "/" in order to be recognized
-properly.
+properly. Same as
+.Ar flags
+field, you can use "-" for null field.
.It Ar signal_number
This optional field specifies
-the signal number will be sent to the daemon process.
+the signal number or signal name will be sent to the daemon process.
By default
-a SIGHUP will be sent.
+a SIGHUP will be sent. Same as
+.Ar flags
+field, you can use "-" for null field.
+.It Ar path_to_program
+This optional field specifies
+the path name of a script for postprocessing of log file.
+This field must be specified with full path.
+And a file must be execute permission by specified
+.Ar owner
+and
+.Ar group .
+When
+.Ar path_to_program
+is called, new log file is given to the first argument, and old
+log file is given to the second argument.
.El
.Sh OPTIONS
The following options can be used with
Index: newsyslog.c
===
RCS file: /home/ncvs/src/usr.sbin/newsyslog/newsyslog.c,v
retrieving revision 1.37
diff -u -r1.37 newsyslog.c
--- newsyslog.c 2001/07/31 16:25:55 1.37
+++ newsyslog.c 2001/10/08 14:09:19
@@ -38,6 +38,7 @@
#include
#include
+#include
#include
#include
#include
@@ -73,6 +74,7 @@
struct conf_entry {
char *log; /* Name of the log */
char *pid_file; /* PID file */
+ char *prog; /* Program for postprocessing */
int uid;/* Owner of log */
int gid;/* Group of log */
int numlogs;/* Number of logs to keep */
@@ -106,11 +108,13 @@
static void do_entry(struct conf_entry * ent);
static void PRS(int argc, char **argv);
static void usage(void);
-static void dotrim(char *log, const char *pid_file, int numdays, int falgs,
- int perm, int owner_uid, int group_gid, int sig);
+static void dotrim(char *log, const char *pid_file, const char *prog,
+ int numdays, int falgs, int perm, int owner_uid,
+ int group_gid, int sig);
static int log_trim(char *log);
static void compress_log(char *log);
static void bzcompress_log(char *log);
+static int post_prog(const char *prog, char *log, int owner_uid, int group_gid);
static int sizefile(char *file);
static int age_old_log(char *file);
static pid_t get_pid(const char *pid_file);
@@ -119,6 +123,7 @@
int group_gid);
static void createdir(char *dirpart);
static time_t parseDWM(char *s);
+static int signame_to_signum(char *sig);
int
main(int argc, char **argv)
@@ -200,7 +205,7 @@
else
pid_file = NULL;
}
- dotrim(ent->log, pid_file, ent->numlogs,
+ dotrim(ent->log, pid_file, ent->prog, ent->numlogs,
ent->flags, ent->permissions, ent->uid, ent->gid,
ent->sig);
} else {
@@ -460,34 +465,52 @@
if (q && *q) {
if (*q == '/')
working->pid_file = strdup(q);
- else if (isdigit(*q))
+ else if (isalnum(*q))
goto got_sig;
- else
- errx(1,
- "illegal pid file or signal number in config file:\n%s",
+
splx() overhead.
In doing some kernel profiling analysis it seems that splx is taking up big chunks of time. The mbuf macros call splimp()..splx() explicitly..are they required at interrupt time? Is there a higher performance way of protecting the necessary code? B To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Change to ldscript.i386
I made a change to page align the data segment on the powerpc port and I
noticed something strange with the i386 alignment. The data section appears
to be wasting space by aligning to the same address (offset) in the next
page rather than to the next page boundary. Below is the patch and a
before/after objdump of the kernel headers. The difference isn't that big
(no more than 4K) but my patch seems more correct.
Am I missing any reason why it was done this way? If not, I'll apply the
patch to -current.
Thanks,
Mark
-
Index: ldscript.i386
===
RCS file: /cvs/freebsd/src/sys/conf/ldscript.i386,v
retrieving revision 1.5
diff -u -u -r1.5 ldscript.i386
--- ldscript.i386 2001/09/18 01:12:43 1.5
+++ ldscript.i386 2001/09/24 22:34:02
@@ -55,9 +55,8 @@
.fini : { *(.fini)} =0x9090
.rodata: { *(.rodata) *(.gnu.linkonce.r*) }
.rodata1 : { *(.rodata1) }
- /* Adjust the address for the data segment. We want to adjust up to
- the same address within the page on the next page up. */
- . = ALIGN(0x1000) + (. & (0x1000 - 1)) ;
+ /* Adjust the address for the data segment to the next page up. */
+ . = ((. + 0x1000) & ~(0x1000 - 1));
.data:
{
*(.data)
Before patch:
kernel: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 000d c01000d4 c01000d4 00d4 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .hash 95f0 c01000e4 c01000e4 00e4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .dynsym 00015770 c01096d4 c01096d4 96d4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .dynstr 00014352 c011ee44 c011ee44 0001ee44 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .text 00207448 c01331a0 c01331a0 000331a0 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .rodata 0005bfa0 c033a600 c033a600 0023a600 2**5
CONTENTS, ALLOC, LOAD, READONLY, DATA
6 set_modmetadata_set 050c c03965a0 c03965a0 002965a0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
7 set_sysinit_set 0894 c0396aac c0396aac 00296aac 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
8 set_sysctl_set 0b44 c0397340 c0397340 00297340 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
9 set_db_cmd_set 0004 c0397e84 c0397e84 00297e84 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
10 set_db_show_cmd_set 0044 c0397e88 c0397e88 00297e88 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 set_sysuninit_set 0338 c0397ecc c0397ecc 00297ecc 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
12 set_kbddriver_set 0008 c0398204 c0398204 00298204 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
13 set_cons_set 000c c039820c c039820c 0029820c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
14 set_videodriver_set 0010 c0398218 c0398218 00298218 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
15 set_scterm_set 0004 c0398228 c0398228 00298228 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
16 set_scrndr_set 001c c039822c c039822c 0029822c 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
17 set_vga_set 001c c0398248 c0398248 00298248 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
18 .data 00049d20 c0399280 c0399280 00298280 2**5
CONTENTS, ALLOC, LOAD, DATA
19 .got 000c c03e2fa0 c03e2fa0 002e1fa0 2**2
CONTENTS, ALLOC, LOAD, DATA
20 .dynamic 0040 c03e2fac c03e2fac 002e1fac 2**2
CONTENTS, ALLOC, LOAD, DATA
21 .bss 00035534 c03e3000 c03e3000 002e2000 2**5
ALLOC
22 .comment 8caf 002e2000 2**0
CONTENTS, READONLY
23 .note 3688 002eacaf 2**0
CONTENTS, READONLY
After patch:
kernel: file format elf32-i386
Sections:
Idx Name Size VMA LMA File off Algn
0 .interp 000d c01000d4 c01000d4 00d4 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .hash 95f0 c01000e4 c01000e4 00e4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .dynsym 00015770 c01096d4 c01096d4 96d4 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 .dynstr 00014352 c011ee44 c011ee44 0001ee44 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .text 00207448 c01331a0 c01331a0 000331a0 2**4
CONTENTS, ALLOC, LOAD, READONLY, CODE
5 .rodata 0005bfa0 c033a600 c033a600 0023a600 2**5
Re: Some thoughts on if_ioctl()
On Mon, Oct 08, 2001 at 09:03:54AM -0600, Warner Losh wrote: > Actaully, it should return ENOTTY rather than EINVAL. ENOTTY means > that the ioctl isn't understood. I've had to fix several drivers at > work that didn't follow this convention due to ignorance on the part > of the driver writer. I was looking for a discussion about this, and insted came across a much older discussion than I remembered. :-) Unfortunately I can't find a threaded view, so here are some links. http://mail-index.netbsd.org/current-users/1994/07/12/0006.html http://mail-index.netbsd.org/current-users/1994/07/12/0014.html http://mail-index.netbsd.org/current-users/1994/07/12/0016.html http://mail-index.netbsd.org/current-users/1994/07/12/0018.html -- Leo Bicknell - [EMAIL PROTECTED] Systems Engineer - Internetworking Engineer - CCIE 3440 Read TMBG List - [EMAIL PROTECTED], www.tmbg.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: strange network performace
Danny Braniss wrote: > setup: > host A: dual pentium III/1GHz (Dell 2450) > host B: dual pentium III/950MHz (Intel STL2) > host C: Pentium III/1GHz (Dell GX150) > > all connected at 100Mgb full duplex > all three are running FreeBSD 4.4. > > all three have identical troughput when writing to a NetAPP fileserver ~ 10MBs > > but: > B -> A: ~ 6MBs > C -> A: ~ 2MBs > > Q: why is C -> A so bad? > show us the output of "ifconfig -a" on each box. -- -- Daniel Frazier <[EMAIL PROTECTED]> Tel: 302-239-5900 Ext. 231 Systems AdministratorFax: 302-239-3909 MAGPAGE, We Power the Internet WWW: http://www.magpage.com/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, Historical Review of Pennsylvania, 1759. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Some thoughts on if_ioctl()
In message <[EMAIL PROTECTED]> Yar Tikhiy writes: : First, the current implementation of the utility function : ether_ioctl(), which can do good job common to ethernet drivers, : won't indicate the situation when an ioctl command is unsupported : by it. It will return 0 in this case. Wouldn't it be better to : return EINVAL so the driver can do something about that? : Now each driver using ether_ioctl() has to maintain painfully the : list of the ioctl commands that may be passed to ether_ioctl(), or : the kernel will be likely to panic in copyout() dereferencing a : NULL pointer. Actaully, it should return ENOTTY rather than EINVAL. ENOTTY means that the ioctl isn't understood. I've had to fix several drivers at work that didn't follow this convention due to ignorance on the part of the driver writer. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
processes stuck in 'ffsvgt' states (kern/19479)
Greetings all, I have two boxes that encountered the problem reported as kern/19479. The system took 102400K of FFS vnodes, and hang. They are two SMP boxes that both have 2.5G of physical memory. maxusers is 384. The problem happens on 4.3-RC#0 and 4.4-RC#0. I guess that the problem happens on machines that have large physical memory and need to access many files. (our machines have millions of files) It is simple to reproduce the bug with 'cp': In single-user mode, use the native 'cp' to copy directories with about 34000 subdirectories to another partition (cp -Rp), then the number of FFS nodes keeps growing without stop. After a while, it hangs with processes in 'ffsvgt' and 'FFS no' state. The 'top' still runs, but any process that do disk I/O would block. If I kill the 'cp' process before running out of vnodes, the number of FFS nodes doesn't go down after 10 minutes. If I umount the target partition that I'm copying directories to, the number of FFS nodes drops down to normal value immediately. It doesn't matter whether these partitions are mounted with soft-updates or not. Some of the partitions are using vinum. In addition to single-user mode, it also happened many times in muliple-user mode when there are more than 1G of InAct mem (less than 3000 processes), but I have never seen this problem at peek load when the system has less than 200M of InAct mem (5000 to 6000 processes running). It seems that the problem occurred more frequently after we added more RAM. We didn't notice this problem when we have only 2G of RAM, after we upgraded to 2.5G of RAM, both of our machines crashed every one or two days. I guess that FreeBSD might use too much vnodes when there are lots of free memory. ps: we have applied the kernel patch that increase kernel address space to 2G = Below are some sys stats when moving directories in single-user mode. $ while true; do vmstat -m | grep 'FFS node' ; sleep 3; done FFS node272660 68165K 68166K102400K 6604950 0 256 FFS node272767 68192K 68192K102400K 6609500 0 256 <> FFS node272803 68201K 68201K102400K 6612060 0 256 FFS node272803 68201K 68201K102400K 6612060 0 256 FFS node103352 51676K 54947K102400K 3405540 0 512 <> FFS node 17186K 54947K102400K 3405540 0 512 FFS node 17186K 54947K102400K 3405540 0 512 $ sysctl -a | grep vnode kern.maxvnodes: 134881 vm.stats.vm.v_vnodein: 210149 vm.stats.vm.v_vnodeout: 0 vm.stats.vm.v_vnodepgsin: 357224 vm.stats.vm.v_vnodepgsout: 0 = Below are some sys stats before crash in multiple-user mode, when many online users go to sleep, and the number of processes drop down, and the Inact mem keep increasing. $ while true; do vmstat -m | grep 'FFS node' ; sleep 3; done << InUse vnodes stay unchanged as 99200K for many hours >> FFS node198399 99200K 99200K102400K 39630210 0 512 FFS node198399 99200K 99200K102400K 39632740 0 512 FFS node198399 99200K 99200K102400K 39635380 0 512 FFS node198395 99198K 99200K102400K 39637950 0 512 FFS node198399 99200K 99200K102400K 39641020 0 512 << InUse vnodes start to increse>> FFS node198510 99255K 99256K102400K 39644760 0 512 FFS node198678 99339K 99339K102400K 39647120 0 512 FFS node198861 99431K 99431K102400K 39649580 0 512 FFS node199049 99525K 99525K102400K 39652760 0 512 FFS node199224 99612K 99612K102400K 39656030 0 512 FFS node199452 99726K 99726K102400K 39659130 0 512 FFS node199636 99818K 99818K102400K 39661610 0 512 FFS node199753 99877K 99877K102400K 39663920 0 512 FFS node199939 99970K 99970K102400K 39666480 0 512 FFS node200142100071K 100071K102400K 39669540 0 512 FFS node200346100173K 100173K102400K 39672100 0 512 FFS node200547100274K 100274K102400K 39674330 0 512 FFS node200719100360K 100360K102400K 39676450 0 512 FFS node200901100451K 100451K102400K 39679520 0 512 FFS node201059100530K 100530K102400K 39681820 0 512 FFS node201246100623K 100623K102400K 39684240 0 512 FFS node201446100723K 100724K102400K 39686820 0 512 FFS node201593100797K 100797K102400K 39689530 0 512 FFS node201735100868K 100868K102400K 39692260 0 512 FFS node201803100902K 100902K102400K 39695310 0 512 FFS node201949100975K 100975K102400K 39698060 0 512 FFS node202152101076K 101077K102400K 39700900 0 512 FFS node202317101159K 101159K102400K 39703850 0 512 FFS node202506101253K 101253K102400K 39706570 0 512 FFS node202655101328K 101328K102400K 39708660 0 512 FFS no
Re: strange network performace
heheh.. well, that definitely could be it.. Let me know what you find out.. Eric Danny Braniss wrote: > > > Oh, well, I thought you said "10mb/s", not "10MB/s" .. that makes it a bit >different. I wonder if it could still be a tcp window size or something.. Try these >sysctl's on C: > ... > > i will, but im beginning to believe that it's memory related, not the > quantity (they all have over 256M) but quality/bus, but that means > hardware, and i have my software hat today :-) > > thanks, > > danny -- - Eric Anderson[EMAIL PROTECTED]Centaur Technology # rm -rf /bin/laden - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: strange network performace
> Oh, well, I thought you said "10mb/s", not "10MB/s" .. that makes it a bit >different. I wonder if it could still be a tcp window size or something.. Try these >sysctl's on C: ... i will, but im beginning to believe that it's memory related, not the quantity (they all have over 256M) but quality/bus, but that means hardware, and i have my software hat today :-) thanks, danny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: strange network performace
Oh, well, I thought you said "10mb/s", not "10MB/s" .. that makes it a bit different. I wonder if it could still be a tcp window size or something.. Try these sysctl's on C: vfs.nfs.gatherdelay=0 vfs.nfs.async=1 vfs.vmiodirenable=1 kern.ipc.maxsockbuf=2097152 kern.ipc.somaxconn=8192 kern.ipc.maxsockets=16424 kern.maxfiles=65536 kern.maxfilesperproc=32768 net.inet.tcp.rfc1323=1 net.inet.tcp.delayed_ack=0 net.inet.tcp.sendspace=65535 net.inet.tcp.recvspace=65535 net.inet.udp.recvspace=65535 net.inet.udp.maxdgram=57344 net.local.stream.recvspace=65535 net.local.stream.sendspace=65535 Just a try.. Danny Braniss wrote: > > > And what happens when you go from A or B to C? Have you been running a top or >systat -vmstat while this is happening? > > I'm thinking it might be a purely IO thing, on the proc box. I have seen similar >slowness with the default FreeBSD > > install on single proc boxes, but a few sysctl's seem to do the trick. > > a reminder: > A -> NetAPP > B -> NetAPP > C -> NetAPP > is fine, im running the same test, and the results are consitant, ~10MGBs > > so that should eliminate network/switch/port/cable problems, right? > > btw, no network errors are reported, neither from the hosts nor the switches. > > danny > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- - Eric Anderson[EMAIL PROTECTED]Centaur Technology # rm -rf /bin/laden - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: strange network performace
> And what happens when you go from A or B to C? Have you been running a top or systat >-vmstat while this is happening? > I'm thinking it might be a purely IO thing, on the proc box. I have seen similar >slowness with the default FreeBSD > install on single proc boxes, but a few sysctl's seem to do the trick. a reminder: A -> NetAPP B -> NetAPP C -> NetAPP is fine, im running the same test, and the results are consitant, ~10MGBs so that should eliminate network/switch/port/cable problems, right? btw, no network errors are reported, neither from the hosts nor the switches. danny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: strange network performace
And what happens when you go from A or B to C? Have you been running a top or systat -vmstat while this is happening? I'm thinking it might be a purely IO thing, on the proc box. I have seen similar slowness with the default FreeBSD install on single proc boxes, but a few sysctl's seem to do the trick. Eric Danny Braniss wrote: > > > How many times did you run the test? Could it have been cached in host B, but not >C? What about disk performance? > > Maybe one is ATA66 or 100, and tthe other is not? Host C may only be UDMA33, and >possibly have a slow drive, with a > > lower amount of memory for caching. Did you rebuild kernels on any of them? > > > > so many questions :-)! > > the test were run many times, on host C the port was changed, the cable was > changed, the NIC was changed. > > the disk is not relevant, the test uses a small program i wrote that writes > from memory. > > at the moment all three run the same version of the kernel, the only diff is > that A & B are smp, and C is not. > > danny -- - Eric Anderson[EMAIL PROTECTED]Centaur Technology # rm -rf /bin/laden - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: strange network performace
> How many times did you run the test? Could it have been cached in host B, but not >C? What about disk performance? > Maybe one is ATA66 or 100, and tthe other is not? Host C may only be UDMA33, and >possibly have a slow drive, with a > lower amount of memory for caching. Did you rebuild kernels on any of them? > so many questions :-)! the test were run many times, on host C the port was changed, the cable was changed, the NIC was changed. the disk is not relevant, the test uses a small program i wrote that writes from memory. at the moment all three run the same version of the kernel, the only diff is that A & B are smp, and C is not. danny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: strange network performace
How many times did you run the test? Could it have been cached in host B, but not C? What about disk performance? Maybe one is ATA66 or 100, and tthe other is not? Host C may only be UDMA33, and possibly have a slow drive, with a lower amount of memory for caching. Did you rebuild kernels on any of them? Eric Danny Braniss wrote: > > setup: > host A: dual pentium III/1GHz (Dell 2450) > host B: dual pentium III/950MHz (Intel STL2) > host C: Pentium III/1GHz (Dell GX150) > > all connected at 100Mgb full duplex > all three are running FreeBSD 4.4. > > all three have identical troughput when writing to a NetAPP fileserver ~ 10MBs > > but: > B -> A: ~ 6MBs > C -> A: ~ 2MBs > > Q: why is C -> A so bad? > > danny > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message -- - Eric Anderson[EMAIL PROTECTED]Centaur Technology # rm -rf /bin/laden - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
strange network performace
setup: host A: dual pentium III/1GHz (Dell 2450) host B: dual pentium III/950MHz (Intel STL2) host C: Pentium III/1GHz (Dell GX150) all connected at 100Mgb full duplex all three are running FreeBSD 4.4. all three have identical troughput when writing to a NetAPP fileserver ~ 10MBs but: B -> A: ~ 6MBs C -> A: ~ 2MBs Q: why is C -> A so bad? danny To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: chroot
On Thu, Oct 04, 2001 at 05:32:16PM -0600, Thierry Black wrote:
[ please don't write in HTML. Do it again and I'll drop you in a kill file.]
However, to answer the question "why don't we allow users to chroot", I
present you with:
$ mkdir -p hack/usr/lib
$ mkdir -p hack/usr/bin
$ cp evilness.so hack/usr/lib/libc.so
$ ln /usr/bin/at hack/usr/bin
$ cat hack-a-tack.c
#include
int main (void) { chroot("hack"); exec ("/usr/bin/at", "/usr/bin/at", NULL);}
$ gcc -o hack-a-tack hack-a-tack.c
$ ./hack-a-tack
Now, code I wrote is running with root privilages. While it's
clearly running in a chrooted enviroment, you can still do
Very Bad Things.
(This, of course, assumes that you have write permissions somewhere
on the same file system as a suid program. This is probably true
on many systems)
--
Mike Bristow, seebitwopie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Some thoughts on if_ioctl()
Hi there, I'd like to discuss the following issues prior to modifying the kernel. First, the current implementation of the utility function ether_ioctl(), which can do good job common to ethernet drivers, won't indicate the situation when an ioctl command is unsupported by it. It will return 0 in this case. Wouldn't it be better to return EINVAL so the driver can do something about that? Now each driver using ether_ioctl() has to maintain painfully the list of the ioctl commands that may be passed to ether_ioctl(), or the kernel will be likely to panic in copyout() dereferencing a NULL pointer. Second, let's look at the handling of SIOCADDMULTI/SIOCDELMULTI. There is code obviously taken from if_loop.c and used in some drivers, which tries to do something with the third argument "data" of the if_ioctl() driver method if "data" isn't NULL. If I understand the kernel code right, if_ioctl()'s third argument is always NULL and serves nothing since these ioctl commands just notify the driver that the list of multicast groups on an interface has been changed. Is it true? If it is, I'd like to remove the questionable code and document the feature in ifnet(9) for newbie kernel hackers will be confused no longer. -- Yar To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
