From owner-freebsd-arch@FreeBSD.ORG Sun May 15 08:53:37 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D83AF16A4CE; Sun, 15 May 2005 08:53:37 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6EE0243D96; Sun, 15 May 2005 08:53:37 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4F8rXgv007767; Sun, 15 May 2005 04:53:34 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4284ED54.9010603@FreeBSD.org> References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> <421DAD8F.6000704@portaone.com> <4284D038.50805@FreeBSD.org> <4284D4BC.9070705@FreeBSD.org> <4284ED54.9010603@FreeBSD.org> Date: Sun, 15 May 2005 04:53:33 -0400 To: Maxim Sobolev From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 cc: Paul Saab cc: freebsd-arch@FreeBSD.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2005 08:53:38 -0000 At 9:09 PM +0300 5/13/05, Maxim Sobolev wrote: >Garance A Drosihn wrote: > >>Note that I'm not just "running this through buildworld". That's >>how all the previous changes were tested, too. I have a whole >>battery of tests that I've been slogging through. > >Well, I'd suggest you to put those tests into src/tools/regression, >to ensure that this won't be broken occasionally in the future. Some of the testing has to do with things outside of imgact_shell.c itself. This thread started out with a change that made to /bin/sh which worked fine in -current, but then didn't work in -stable due to a minor change in imgact_shell.c. So I'm a bit paranoid. I haven't been testing with your code, but if you have that code installed, then you might try the following shell script: #!/usr/bin/env BLAH=aBc BLAH2=OtheR /bin/sh # echo $BLAH $BLAH2 Assuming your change to works about the same as mine, that script should be an infinite loop. That's because the historical code would startup 'env' with: DBG: arg[ 0] = '/usr/bin/env' DBG: arg[ 1] = 'BLAH=aBc' DBG: arg[ 2] = 'BLAH2=OtheR' DBG: arg[ 3] = '/bin/sh' DBG: arg[ 4] = '/tmp/shelltest3' While the new code starts it up with: DBG: arg[ 0] = '/usr/bin/env' DBG: arg[ 1] = 'BLAH=aBc BLAH2=OtheR /bin/sh' DBG: arg[ 2] = '/tmp/shelltest3' This threw me at first, because I have actually used that construct to start out some scripts. But it turns out that trick causes the exact same looping on solaris and linux, so I guess I was just lucky that I never tried it on anything but FreeBSD! I wonder if anyone else has used that. It also looks like something goes wrong with /bin/sh when options are given on the #!-line, which may be left-over from my previous change to it. I haven't tracked that down yet, but I want to understand that before committing the fix we want. My guess is that those are the only two programs in the base system which need to care about this change, but the update I have also provides a kludge (which would be undocumented and TEMPORARY) to give people a way to get the historical parsing-behavior if they needed it for some script. I'm not sure if I'll commit that part, but it's useful for my testing. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Sun May 15 09:24:37 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD11D16A4CE; Sun, 15 May 2005 09:24:37 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C16643DBF; Sun, 15 May 2005 09:24:37 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4F9OZ6Y014161; Sun, 15 May 2005 05:24:36 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4284D038.50805@FreeBSD.org> References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> <421DAD8F.6000704@portaone.com> <4284D038.50805@FreeBSD.org> Date: Sun, 15 May 2005 05:24:35 -0400 To: Maxim Sobolev From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 cc: freebsd-arch@FreeBSD.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2005 09:24:38 -0000 At 7:05 PM +0300 5/13/05, Maxim Sobolev wrote: >Attached please find patch which rips any special processing >of command line arguments. It should put FreeBSD into the very >same ship with the rest of unices and linuces out there. > >...This corresponds to the case (3) from the Garance's original >message. > >I've run this change through buildworld. Fwiw, this is the patch that I have been working with for the same purpose. I might trim down the comments some more. This includes a kludge to recognize '#!#<' as a way to trigger the historical parsing behavior. I have another version which also recognizes '#!#+' as a way to trigger a whole bunch of debug messages, but that's probably of no interest to anyone but me. This patch is also at: http://people.freebsd.org/imgact_shell.diff and the file you'd end up with by applying the patch is at: http://people.freebsd.org/imgact_shell.c This has installed and tested in i386 and powerpc, and sometime on Sunday I'll have it installed on a sparc64 machine. (it's building now, but my ultra10 machine is much much slower than my i386 and my Mac-mini...). Index: imgact_shell.c =================================================================== RCS file: /home/ncvs/src/sys/kern/imgact_shell.c,v retrieving revision 1.32 diff -u -r1.32 imgact_shell.c --- imgact_shell.c 25 Feb 2005 10:17:53 -0000 1.32 +++ imgact_shell.c 15 May 2005 09:07:13 -0000 @@ -36,6 +36,15 @@ #include #include +#define KEEP_OLDCODE 1 +#if BYTE_ORDER == LITTLE_ENDIAN /* temp for OLD_CODE kludge */ +#define DBG_MAGIC 0x2B23 /* #+ in "little-endian" */ +#define OLD_MAGIC 0x3C23 /* #< */ +#else +#define DBG_MAGIC 0x232B /* #+ in big-endian */ +#define OLD_MAGIC 0x233C /* #< */ +#endif + #if BYTE_ORDER == LITTLE_ENDIAN #define SHELLMAGIC 0x2123 /* #! */ #else @@ -43,15 +52,66 @@ #endif /* - * Shell interpreter image activator. An interpreter name beginning - * at imgp->args->begin_argv is the minimal successful exit requirement. + * At the time of this writing, MAXSHELLCMDLEN == PAGE_SIZE. This is + * significant because the caller has only mapped in one page of the + * file we're reading. This code should be changed to know how to + * read in the second page, but I'm not doing that just yet... + */ +#if MAXSHELLCMDLEN > PAGE_SIZE +#error "MAXSHELLCMDLEN is larger than a single page!" +#endif + +/** + * Shell interpreter image activator. An interpreter name beginning at + * imgp->args->begin_argv is the minimal successful exit requirement. + * + * If the given file is a shell-script, then the first line will start + * with the two characters `#!' (aka SHELLMAGIC), followed by the name + * of the shell-interpreter to run, followed by zero or more tokens. + * + * If there are *any* tokens, then we start up the interpreter such that + * it will see: + * arg[0] -> The name of interpreter as specified after `#!' in the + * first line of the script. The interpreter name must + * not be longer than MAXSHELLCMDLEN bytes. + * arg[1] -> *If* there are any additional tokens on the first line, + * then we add a new arg[1], which is a copy of the rest of + * that line. The copy starts at the first token after the + * interpreter name. We leave it to the interpreter to + * parse the tokens in that value. + * arg[x] -> the full pathname of the script. This will either be + * arg[2] or arg[1], depending on whether or not tokens + * were found after the interpreter name. + * arg[x+1] -> whatever arguments that were specified on the original + * command line (if the user had specified any). + * + * This processing is described in the execve(2) man page. + */ + +/* + * HISTORICAL NOTE: From 1993 to mid-2005, FreeBSD parsed out the tokens as + * found on the first line of the script, and setup each token as a separate + * value in arg[]. This extra processing did not match the behavior of other + * OS's, and caused a few subtle problems. For one, it meant the kernel was + * deciding how those values should be parsed (wrt characters for quoting or + * comments, etc), while the interpreter might have other rules for parsing. + * It also meant the interpreter had no way of knowing which arguments came + * from the first line of the shell script, and which arguments were specified + * by the user on the command line. + * + * Luckily, only few things in the base system would notice that non-standard + * processing (mainly /bin/sh and /usr/bin/env). And for programs which are + * not in the base system, the "newer" behavior matches how NetBSD, OpenBSD, + * Linux, Solaris, AIX, IRIX, and some other Unixes have always setup the + * arg-list for the interpreter. So if a program can handle this behavior on + * any of those other OS's, it should be able to handle it for FreeBSD too. */ int exec_shell_imgact(imgp) struct image_params *imgp; { const char *image_header = imgp->image_header; - const char *ihp; + const char *ihp, *interpb, *interpe, *maxp, *optb, *opte; int error, offset; size_t length, clength; struct vattr vattr; @@ -79,14 +139,34 @@ if (error) return (error); - clength = (vattr.va_size > MAXSHELLCMDLEN) ? - MAXSHELLCMDLEN : vattr.va_size; + /* + * Copy shell name and arguments from image_header into a string + * buffer. Remember that the caller has mapped only the + * first page of the file into memory. + */ + clength = (vattr.va_size > PAGE_SIZE) ? PAGE_SIZE : vattr.va_size; + + maxp = &image_header[clength]; + ihp = &image_header[2]; +#if KEEP_OLDCODE + /* + * XXX - Temporarily provide a quick-and-dirty way to get the + * older, non-standard option-parsing behavior, just in case + * someone finds themselves in an emergency where they need it. + * This will not be documented. It is only for initial testing. + */ + if (*(const short *)ihp == OLD_MAGIC) + ihp += 2; + else + goto new_code; + interpb = ihp; + /* * Figure out the number of bytes that need to be reserved in the * argument string to copy the contents of the interpreter's command * line into the argument string. */ - ihp = &image_header[2]; + ihp = interpb; offset = 0; while (ihp < &image_header[clength]) { /* Skip any whitespace */ @@ -152,7 +232,7 @@ * Loop through the interpreter name yet again, copying as * we go. */ - ihp = &image_header[2]; + ihp = interpb; offset = 0; while (ihp < &image_header[clength]) { /* Skip whitespace */ @@ -174,8 +254,96 @@ imgp->args->begin_argv[offset++] = '\0'; imgp->args->argc++; } + goto common_end; +new_code: +#endif + /* + * Find the beginning and end of the interpreter_name. If the + * line does not include any interpreter, or if the name which + * was found is too long, we bail out. + */ + while (ihp < maxp && ((*ihp == ' ') || (*ihp == '\t'))) + ihp++; + interpb = ihp; + while (ihp < maxp && ((*ihp != ' ') && (*ihp != '\t') && (*ihp != '\n') + && (*ihp != '\0'))) + ihp++; + interpe = ihp; + if (interpb == interpe) + return (ENOEXEC); + if ((interpe - interpb) >= MAXSHELLCMDLEN) + return (ENAMETOOLONG); + + /* + * Find the beginning of the options (if any), and the end-of-line. + * Then trim the trailing blanks off the value. Note that some + * other operating systems do *not* trim the trailing whitespace... + */ + while (ihp < maxp && ((*ihp == ' ') || (*ihp == '\t'))) + ihp++; + optb = ihp; + while (ihp < maxp && ((*ihp != '\n') && (*ihp != '\0'))) + ihp++; + opte = ihp; + while (--ihp > interpe && ((*ihp == ' ') || (*ihp == '\t'))) + opte = ihp; /* + * We need to "pop" (remove) the present value of arg[0], and "push" + * either two or three new values in the arg[] list. To do this, + * we first shift all the other values in the `begin_argv' area to + * provide the exact amount of room for the values added. Set up + * `offset' as the number of bytes to be added to the `begin_argv' + * area, and 'length' as the number of bytes being removed. + */ + offset = interpe - interpb + 1; /* interpreter */ + if (opte != optb) /* options (if any) */ + offset += opte - optb + 1; + offset += strlen(imgp->args->fname) + 1; /* fname of script */ + length = (imgp->args->argc == 0) ? 0 : + strlen(imgp->args->begin_argv) + 1; /* bytes to delete */ + + if (offset - length > imgp->args->stringspace) + return (E2BIG); + + bcopy(imgp->args->begin_argv + length, imgp->args->begin_argv + offset, + imgp->args->endp - (imgp->args->begin_argv + length)); + + offset -= length; /* calculate actual adjustment */ + imgp->args->begin_envv += offset; + imgp->args->endp += offset; + imgp->args->stringspace -= offset; + + /* + * If there was no arg[0] when we started, then the interpreter_name + * is adding an argument (instead of replacing the arg[0] we started + * with). And we're always adding an argument when we include the + * full pathname of the original script. + */ + if (imgp->args->argc == 0) + imgp->args->argc = 1; + imgp->args->argc++; + + /* + * The original arg[] list has been shifted appropriately. Copy in + * the interpreter name and options-string. + */ + length = interpe - interpb; + bcopy(interpb, imgp->args->buf, length); + *(imgp->args->buf + length) = '\0'; + offset = length + 1; + if (opte != optb) { + length = opte - optb; + bcopy(optb, imgp->args->buf + offset, length); + *(imgp->args->buf + offset + length) = '\0'; + offset += length + 1; + imgp->args->argc++; + } + +#if KEEP_OLDCODE +common_end: +#endif + /* * Finally, add the filename onto the end for the interpreter to * use and copy the interpreter's name to imgp->interpreter_name * for exec to use. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Sun May 15 09:36:13 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E536416A4CE; Sun, 15 May 2005 09:36:13 +0000 (GMT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5396243D6D; Sun, 15 May 2005 09:36:13 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4F9aBrX018139; Sun, 15 May 2005 05:36:11 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> <421DAD8F.6000704@portaone.com> <4284D038.50805@FreeBSD.org> Date: Sun, 15 May 2005 05:36:10 -0400 To: Garance A Drosehn From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 cc: freebsd-arch@FreeBSD.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2005 09:36:14 -0000 At 5:24 AM -0400 5/15/05, Garance A Drosehn tiredly wrote: > >This patch is also at: > >http://people.freebsd.org/imgact_shell.diff > >and the file you'd end up with by applying the patch is at: > >http://people.freebsd.org/imgact_shell.c Those URL's should have been: http://people.freebsd.org/~gad/imgact_shell.diff http://people.freebsd.org/~gad/imgact_shell.c Feel free to scream if there's something in there which looks wrong. I'm still not claiming to be a master kernel programmer... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Mon May 16 02:21:22 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D5C716A4CE; Mon, 16 May 2005 02:21:22 +0000 (GMT) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A22F43D93; Mon, 16 May 2005 02:21:22 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4G2LJqD012754; Sun, 15 May 2005 22:21:20 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> <421DAD8F.6000704@portaone.com> <4284D038.50805@FreeBSD.org> <4284D4BC.9070705@FreeBSD.org> <4284ED54.9010603@FreeBSD.org> Date: Sun, 15 May 2005 22:21:19 -0400 To: Maxim Sobolev From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 cc: freebsd-arch@FreeBSD.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2005 02:21:22 -0000 At 4:53 AM -0400 5/15/05, Garance A Drosehn wrote: >... you might try the following shell script: > > #!/usr/bin/env BLAH=aBc BLAH2=OtheR /bin/sh > # > echo $BLAH $BLAH2 > >Assuming your change to works about the same as mine, that script >should be an infinite loop. Well, this behavior is the same as what the user would see with the same script on other OS's. I could add an option to `env' which script-writers could use to avoid this problem, but I'm not sure it's worth the trouble... >It also looks like something goes wrong with /bin/sh when options >are given on the #!-line, which may be left-over from my previous >change to it. I haven't tracked that down yet, but I want to >understand that before committing the fix we want. Well, `sh' is probably doing the right thing, but the end result still breaks the `#!'-trick which is documented in some books on perl and ruby (and python?). So I want to commit a fix to `sh' which will allow that trick to work, and then I'll commit the change to imgact_shell.c that I wrote up. Probably commit an entry to UPDATING at the same time, since the change could possibly break some people's scripts. Not likely, but possible... That's at: http://people.freebsd.org/~gad/imgact_shell.diff http://people.freebsd.org/~gad/imgact_shell.c -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-arch@FreeBSD.ORG Tue May 17 04:25:18 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A3A1516A4CE; Tue, 17 May 2005 04:25:18 +0000 (GMT) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DFC3C43D94; Tue, 17 May 2005 04:25:17 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j4H4PBsO003073; Tue, 17 May 2005 00:25:12 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> <421DAD8F.6000704@portaone.com> <4284D038.50805@FreeBSD.org> <4284D4BC.9070705@FreeBSD.org> Date: Tue, 17 May 2005 00:25:11 -0400 To: Maxim Sobolev From: Garance A Drosihn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 cc: Paul Saab cc: freebsd-arch@freebsd.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 04:25:18 -0000 At 12:45 PM -0400 5/13/05, Garance A Drosihn wrote: > >Note that I'm not just "running this through buildworld". That's >how all the previous changes were tested, too. I have a whole >battery of tests that I've been slogging through. Scanning through /usr/src, the following scripts *might* have problems with this change we agreed on, depending on how they are used: ./contrib/ipfilter/rules/BASIC.NAT=: #!/sbin/ipnat -f - ./contrib/ipfilter/rules/BASIC_1.FW: #!/sbin/ipf -f - ./contrib/ipfilter/rules/BASIC_2.FW: #!/sbin/ipf -f - ./contrib/ntp/scripts/monitoring/ntptrap: #!/local/bin/perl --*-perl-*- ./sys/conf/makeLINT.sed: #!/usr/bin/sed -E -n -f ./tools/regression/ia64/unaligned/unaligned.t: #!/usr/bin/env perl -w ./tools/tools/backout_commit/backout_commit.rb: #!/usr/bin/env ruby -w I don't think any of these are serious, but it's nice to find them ahead of the change instead of after the fact. I will probably be out of town for Tuesday and part of Wednesday. And I imagine I'll spend part of Thursday "in a galaxy far-far away", even though the first two episodes were incredibly lame. But I do still expect to commit the change sometime later this week, unless someone objects. But since this is change somewhat more disruptive than I initially expected, I doubt I will MFC all of these changes into 5.x-stable. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-arch@FreeBSD.ORG Tue May 17 05:37:22 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5996616A4CE; Tue, 17 May 2005 05:37:22 +0000 (GMT) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 569CC43DDF; Tue, 17 May 2005 05:37:21 +0000 (GMT) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.62] (porta-billing-master. [209.121.79.7]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j4H5bD3q068719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 17 May 2005 07:37:16 +0200 (CEST) (envelope-from sobomax@FreeBSD.org) Message-ID: <42898308.2020704@FreeBSD.org> Date: Tue, 17 May 2005 08:37:12 +0300 From: Maxim Sobolev User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garance A Drosihn References: <200410020349.i923nG8v021675@northstar.hetzel.org> <20041002052856.GE17792@nexus.dglawrence.com> <20041002233542.GL714@nexus.dglawrence.com> <421DAD8F.6000704@portaone.com> <4284D038.50805@FreeBSD.org> <4284D4BC.9070705@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/881/Mon May 16 23:13:31 2005 on www.portaone.com X-Virus-Status: Clean cc: Paul Saab cc: freebsd-arch@FreeBSD.org Subject: Re: Bug in #! processing - One More Time X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2005 05:37:22 -0000 Garance A Drosihn wrote: > At 12:45 PM -0400 5/13/05, Garance A Drosihn wrote: > >> >> Note that I'm not just "running this through buildworld". That's >> how all the previous changes were tested, too. I have a whole >> battery of tests that I've been slogging through. > > > Scanning through /usr/src, the following scripts *might* have problems > with this change we agreed on, depending on how they are used: > > ./contrib/ipfilter/rules/BASIC.NAT=: > #!/sbin/ipnat -f - > ./contrib/ipfilter/rules/BASIC_1.FW: > #!/sbin/ipf -f - > ./contrib/ipfilter/rules/BASIC_2.FW: > #!/sbin/ipf -f - > ./contrib/ntp/scripts/monitoring/ntptrap: > #!/local/bin/perl --*-perl-*- > ./sys/conf/makeLINT.sed: > #!/usr/bin/sed -E -n -f > ./tools/regression/ia64/unaligned/unaligned.t: > #!/usr/bin/env perl -w > ./tools/tools/backout_commit/backout_commit.rb: > #!/usr/bin/env ruby -w > > I don't think any of these are serious, but it's nice to find them > ahead of the change instead of after the fact. I will probably be > out of town for Tuesday and part of Wednesday. And I imagine I'll > spend part of Thursday "in a galaxy far-far away", even though the > first two episodes were incredibly lame. But I do still expect to > commit the change sometime later this week, unless someone objects. > > But since this is change somewhat more disruptive than I initially > expected, I doubt I will MFC all of these changes into 5.x-stable. I've looked at them too. Actually "-f -" can be collapsed to the "-f-", while "-E -n -f" to the "-Enf". env(1) can be fixed to DTRT, so that nothing is really unfixable. -Maxim From owner-freebsd-arch@FreeBSD.ORG Thu May 19 18:31:16 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E52A16A4CE; Thu, 19 May 2005 18:31:16 +0000 (GMT) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B84543D7E; Thu, 19 May 2005 18:31:15 +0000 (GMT) (envelope-from jkim@niksun.com) Received: from [10.70.0.244] (daemon.mj.niksun.com [10.70.0.244]) by anuket.mj.niksun.com (8.13.1/8.13.1) with ESMTP id j4JIXArn028903; Thu, 19 May 2005 14:33:11 -0400 (EDT) (envelope-from jkim@niksun.com) From: Jung-uk Kim Organization: Niksun, Inc. To: freebsd-arch@freebsd.org Date: Thu, 19 May 2005 14:31:08 -0400 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200505191431.08189.jkim@niksun.com> X-Virus-Scanned: ClamAV 0.83/880/Mon May 16 11:00:02 2005 on anuket.mj.niksun.com X-Virus-Status: Clean cc: rwatson@freebsd.org cc: freebsd-amd64@freebsd.org Subject: AMD64 NUMA-awareness? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 18:31:16 -0000 ULE scheduler paper (http://www.usenix.org/publications/library/proceedings/bsdcon03/tech/roberson.html) says: 'SMT introduces a concept of non-uniform processors into ULE which could be extended to support NUMA. The concept of expressing the penalty for migration through the use of separate queues could be further developed to include a local and global load-balancing policy. At the time of this writing, however, FreeBSD does not support any true NUMA capable machines and so this is left until such time that it does.' I am not sure about the meaning of 'true NUMA capable machines' but AMD64 is ccNUMA unless I am completely mistaken, and FreeBSD/amd64 is well-supported. Even multicore processors are available now and Intel is going to release dual-core processors with HTT to make matters worse. Is there anybody working on this? Thanks, Jung-uk Kim From owner-freebsd-arch@FreeBSD.ORG Thu May 19 18:39:23 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2267716A4CE; Thu, 19 May 2005 18:39:23 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CA6743D66; Thu, 19 May 2005 18:39:18 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4JIgTn3095560; Thu, 19 May 2005 12:42:29 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <428CDD17.7020207@samsco.org> Date: Thu, 19 May 2005 12:38:15 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jung-uk Kim References: <200505191431.08189.jkim@niksun.com> In-Reply-To: <200505191431.08189.jkim@niksun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: rwatson@freebsd.org cc: freebsd-amd64@freebsd.org cc: freebsd-arch@freebsd.org Subject: Re: AMD64 NUMA-awareness? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 18:39:23 -0000 Jung-uk Kim wrote: > ULE scheduler paper > (http://www.usenix.org/publications/library/proceedings/bsdcon03/tech/roberson.html) > says: > > 'SMT introduces a concept of non-uniform processors into ULE which > could be extended to support NUMA. The concept of expressing the > penalty for migration through the use of separate queues could be > further developed to include a local and global load-balancing > policy. At the time of this writing, however, FreeBSD does not > support any true NUMA capable machines and so this is left until such > time that it does.' > > I am not sure about the meaning of 'true NUMA capable machines' but > AMD64 is ccNUMA unless I am completely mistaken, and FreeBSD/amd64 is > well-supported. Even multicore processors are available now and > Intel is going to release dual-core processors with HTT to make > matters worse. > Even HTT by itself presents some interesting scheduling challenges that need to be accounted for. > Is there anybody working on this? Jeff stated recently that both ULE and 4BSD have some very primitive awareness of topology, but that much more work is needed. NUMA would also benefit from the UMA memory allocator understanding memory topology and working with the scheduler to keep processes on CPUs that are closest to their memory. Unfortunately, there doesn't appear to be much work going on, so if anyone is interested, it's a great project and I encourage all to help. Scott From owner-freebsd-arch@FreeBSD.ORG Thu May 19 22:20:42 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47FF816A4CE for ; Thu, 19 May 2005 22:20:42 +0000 (GMT) Received: from smtp.speedfactory.net (talon.speedfactory.net [66.23.216.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id B276543D3F for ; Thu, 19 May 2005 22:20:41 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 26625 invoked from network); 19 May 2005 18:20:53 +0000 Received: from 66-23-216-49.clients.speedfactory.net (HELO palm.tree.com) (66.23.216.49) by mail.speedfactory.net with AES256-SHA encrypted SMTP; 19 May 2005 18:20:53 +0000 Received: from [127.0.0.1] (localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j4JMKdpP088684; Thu, 19 May 2005 18:20:40 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: "freebsd-arch@freebsd.org" Content-Type: text/plain Message-Id: <1116541239.7597.6779.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 19 May 2005 18:20:39 -0400 Content-Transfer-Encoding: 7bit Subject: nuking TDP_WAKEPROC0 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 22:20:42 -0000 The TDP_WAKEPROC0 workaround addressed the problem that wakeup for proc0 could not be called in setrunnable context and had to be delayed. Replacing sleep/wakeup for proc0 with low level primitives borrowed from starting interrupt threads allows the necessary functionality to be called directly by setrunnable(). Using a restart variable allows to get rid of periodic rescans. Please take a look at: http://people.freebsd.org/~ups/proc0.patch If nobody objects or requests more time for a review I will check in the changes early next week. Stephan From owner-freebsd-arch@FreeBSD.ORG Thu May 19 23:52:36 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1AC616A4CE for ; Thu, 19 May 2005 23:52:36 +0000 (GMT) Received: from pd4mo3so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E6CC43D67 for ; Thu, 19 May 2005 23:52:36 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd2mr7so.prod.shaw.ca (pd2mr7so-qfe3.prod.shaw.ca [10.0.141.10])2004))freebsd-arch@freebsd.org; Thu, 19 May 2005 17:52:35 -0600 (MDT) Received: from pn2ml3so.prod.shaw.ca ([10.0.121.147]) by pd2mr7so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGR007ZSGZN2ME0@pd2mr7so.prod.shaw.ca> for freebsd-arch@freebsd.org; Thu, 19 May 2005 17:52:35 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IGR00I16GZNHD@l-daemon> for freebsd-arch@freebsd.org; Thu, 19 May 2005 17:52:35 -0600 (MDT) Date: Thu, 19 May 2005 16:52:33 -0700 From: Colin Percival To: freebsd-arch@freebsd.org Message-id: <428D26C1.2020201@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) Subject: RFC: Using fixed-length strings for version[] and osrelease[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 23:52:36 -0000 In vers.c (created by src/sys/conf/newvers.sh), the strings version[] and osrelease[] are not declared with a fixed length. As a result, as the kernel moves from x.y-RELEASE to x.y-RELEASE-p1, and later to x.y-RELEASE-p10, the length of these strings will change; this causes cascading differences in addresses throughout the kernel binary. This is not a major problem for most people, but it causes difficulty for FreeBSD Update. Such cascading differences in addresses cause FreeBSD Update to recognize the kernel as having changed, at which point it decided that the new kernel needs to be distributed to everybody -- or rather, it would do this but for the fact that my FreeBSD Update build code replaces the traditional "x.y-RELEASE-p15" name with "x.y-SECURITY". As this is the last remaining place where the files built and distributed by FreeBSD Update differ from the standard src tree, I'd like to remove the need for this local patch. At BSDCan last week, Jacques Vidrine pointed out that this could be done simply by declaring these two strings as having fixed length -- i.e., by zero-padding them. Would anyone object to the following patch being applied? --- newvers.sh 15 Jan 2005 13:25:41 -0000 1.68 +++ newvers.sh 19 May 2005 23:48:21 -0000 @@ -87,9 +87,9 @@ cat << EOF > vers.c $COPYRIGHT char sccspad[32 - 4 /* sizeof(sccs) */] = { '\\0' }; char sccs[4] = { '@', '(', '#', ')' }; -char version[] = "${VERSION} #${v}: ${t}\\n ${u}@${h}:${d}\\n"; +char version[512] = "${VERSION} #${v}: ${t}\\n ${u}@${h}:${d}\\n"; char ostype[] = "${TYPE}"; -char osrelease[] = "${RELEASE}"; +char osrelease[64] = "${RELEASE}"; int osreldate = ${RELDATE}; char kern_ident[] = "${i}"; EOF The lengths 512 and 64 are chosen as being considerably more than double the likely lengths of these strings; on my system, these two strings are 12 bytes and 134 bytes long respectively. Colin Percival From owner-freebsd-arch@FreeBSD.ORG Fri May 20 06:49:32 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 246E816A4CE for ; Fri, 20 May 2005 06:49:32 +0000 (GMT) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64FA743D72 for ; Fri, 20 May 2005 06:49:31 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: (qmail 26343 invoked from network); 20 May 2005 06:49:31 -0000 Received: from gate.funkthat.com (HELO hydrogen.funkthat.com) ([69.17.45.168]) (envelope-sender ) by mail25.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 May 2005 06:49:31 -0000 Received: from hydrogen.funkthat.com (tmlifo@localhost.funkthat.com [127.0.0.1])j4K6nT2g052171; Thu, 19 May 2005 23:49:30 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.12.10/8.12.10/Submit) id j4K6nTgg052170; Thu, 19 May 2005 23:49:29 -0700 (PDT) Date: Thu, 19 May 2005 23:49:29 -0700 From: John-Mark Gurney To: Colin Percival Message-ID: <20050520064929.GC959@funkthat.com> Mail-Followup-To: Colin Percival , freebsd-arch@freebsd.org References: <428D26C1.2020201@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <428D26C1.2020201@freebsd.org> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD 4.2-RELEASE i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html cc: freebsd-arch@freebsd.org Subject: Re: RFC: Using fixed-length strings for version[] and osrelease[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: John-Mark Gurney List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 06:49:32 -0000 Colin Percival wrote this message on Thu, May 19, 2005 at 16:52 -0700: > Would anyone object to the following patch being applied? > > --- newvers.sh 15 Jan 2005 13:25:41 -0000 1.68 > +++ newvers.sh 19 May 2005 23:48:21 -0000 > @@ -87,9 +87,9 @@ cat << EOF > vers.c > $COPYRIGHT > char sccspad[32 - 4 /* sizeof(sccs) */] = { '\\0' }; > char sccs[4] = { '@', '(', '#', ')' }; > -char version[] = "${VERSION} #${v}: ${t}\\n ${u}@${h}:${d}\\n"; > +char version[512] = "${VERSION} #${v}: ${t}\\n ${u}@${h}:${d}\\n"; > char ostype[] = "${TYPE}"; > -char osrelease[] = "${RELEASE}"; > +char osrelease[64] = "${RELEASE}"; > int osreldate = ${RELDATE}; > char kern_ident[] = "${i}"; > EOF > > The lengths 512 and 64 are chosen as being considerably more than double the > likely lengths of these strings; on my system, these two strings are 12 bytes > and 134 bytes long respectively. Nope, but I would say make them just a bit larger than necessary right now, and add the necessary CTASSERT lines to make sure we don't overflow.. I'd say no more than 256 bytes for the VERSION string, since CTASSERT will prevent the overflow... Though you might want to make the fixed size dependent upon the release kernel and not for custom compiled kernels... No point in penalizing kernels that don't need this... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Fri May 20 08:36:34 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A02016A4CE; Fri, 20 May 2005 08:36:34 +0000 (GMT) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EC6B43D7F; Fri, 20 May 2005 08:36:34 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j4K8aXS3089157; Fri, 20 May 2005 04:36:33 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost)j4K8aXbH089153; Fri, 20 May 2005 04:36:33 -0400 (EDT) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Fri, 20 May 2005 04:36:32 -0400 (EDT) From: Jeff Roberson To: Scott Long In-Reply-To: <428CDD17.7020207@samsco.org> Message-ID: <20050520043319.N82493@mail.chesapeake.net> References: <200505191431.08189.jkim@niksun.com> <428CDD17.7020207@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-arch@freebsd.org cc: rwatson@freebsd.org cc: freebsd-amd64@freebsd.org cc: Jung-uk Kim Subject: Re: AMD64 NUMA-awareness? X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 08:36:34 -0000 On Thu, 19 May 2005, Scott Long wrote: > Jung-uk Kim wrote: > > > ULE scheduler paper > > (http://www.usenix.org/publications/library/proceedings/bsdcon03/tech/roberson.html) > > says: > > > > 'SMT introduces a concept of non-uniform processors into ULE which > > could be extended to support NUMA. The concept of expressing the > > penalty for migration through the use of separate queues could be > > further developed to include a local and global load-balancing > > policy. At the time of this writing, however, FreeBSD does not > > support any true NUMA capable machines and so this is left until such > > time that it does.' > > > > I am not sure about the meaning of 'true NUMA capable machines' but > > AMD64 is ccNUMA unless I am completely mistaken, and FreeBSD/amd64 is > > well-supported. Even multicore processors are available now and > > Intel is going to release dual-core processors with HTT to make > > matters worse. > > > > Even HTT by itself presents some interesting scheduling challenges that > need to be accounted for. > > > Is there anybody working on this? > > Jeff stated recently that both ULE and 4BSD have some very primitive > awareness of topology, but that much more work is needed. NUMA would > also benefit from the UMA memory allocator understanding memory topology > and working with the scheduler to keep processes on CPUs that are > closest to their memory. Unfortunately, there doesn't appear to be > much work going on, so if anyone is interested, it's a great project and > I encourage all to help. I have put a great deal of thought into the issues in both UMA and schedulers for NUMA. I have not put any code in as of yet, however. I think that linux has had limited success with numa support on AMD64. The remote penalty doesn't seem to be great enough to really warrant much more complicated algorithms. Interested parties are certainly welcome to explore this more. I believe remote accesses are in the range of 33-50% more expensive than local. We might benefit by making a copy of the kernel text for each processor. That would be a good starting point to see if any gains are observed in the best case. > > Scott > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > From owner-freebsd-arch@FreeBSD.ORG Fri May 20 21:13:31 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD8DC16A4CF for ; Fri, 20 May 2005 21:13:31 +0000 (GMT) Received: from cp385968-a.gelen1.lb.home.nl (cp385968-a.gelen1.lb.home.nl [84.28.185.135]) by mx1.FreeBSD.org (Postfix) with SMTP id B573943DBC for ; Fri, 20 May 2005 21:13:27 +0000 (GMT) (envelope-from crafty@alesys.com) Received: from [159.118.236.213] (port=2497 helo=[woodcock]) by cp385968-a.gelen1.lb.home.nl with esmtp id 5591637018Cleveland104070 for freebsd-arch@freebsd.org; Fri, 20 May 2005 23:13:28 +0200 Mime-Version: 1.0 (Apple Message framework v728) Content-Transfer-Encoding: 7bit Message-Id: <543496680.19958@cp385968-a.gelen1.lb.home.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-arch@freebsd.org From: Patty Date: Fri, 20 May 2005 23:13:27 +0200 X-Mailer: Apple Mail (2.728) Subject: Dude check out this sweet site! X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 21:13:31 -0000 ADD 3+ inches today - don't get left behind http://www.legahe.com/ss/ Are you happy about your size and sexual performance? From owner-freebsd-arch@FreeBSD.ORG Fri May 20 21:18:15 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB8AD16A4CF for ; Fri, 20 May 2005 21:18:14 +0000 (GMT) Received: from pd3mo1so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6399D43D3F for ; Fri, 20 May 2005 21:18:14 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mr5so.prod.shaw.ca (pd3mr5so-qfe3.prod.shaw.ca [10.0.141.12])2004))freebsd-arch@freebsd.org; Fri, 20 May 2005 15:17:27 -0600 (MDT) Received: from pn2ml9so.prod.shaw.ca ([10.0.121.7]) by pd3mr5so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGT003SR4H3GB20@pd3mr5so.prod.shaw.ca> for freebsd-arch@freebsd.org; Fri, 20 May 2005 15:17:27 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IGT007984H2N5@l-daemon> for freebsd-arch@freebsd.org; Fri, 20 May 2005 15:17:27 -0600 (MDT) Date: Fri, 20 May 2005 14:17:25 -0700 From: Colin Percival In-reply-to: <20050520064929.GC959@funkthat.com> To: John-Mark Gurney Message-id: <428E53E5.7050509@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 References: <428D26C1.2020201@freebsd.org> <20050520064929.GC959@funkthat.com> User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) cc: freebsd-arch@freebsd.org Subject: Re: RFC: Using fixed-length strings for version[] and osrelease[] X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 21:18:15 -0000 John-Mark Gurney wrote: > Colin Percival wrote this message on Thu, May 19, 2005 at 16:52 -0700: >>The lengths 512 and 64 are chosen as being considerably more than double the >>likely lengths of these strings; on my system, these two strings are 12 bytes >>and 134 bytes long respectively. > > Nope, but I would say make them just a bit larger than necessary right > now, and add the necessary CTASSERT lines to make sure we don't overflow.. > > I'd say no more than 256 bytes for the VERSION string, since CTASSERT will > prevent the overflow... > > Though you might want to make the fixed size dependent upon the release > kernel and not for custom compiled kernels... No point in penalizing > kernels that don't need this... I don't think there's much point worrying about saving a few hundred bytes, but I've put together a patch which allows the strings to be lengthened if necessary. The lengths are now 256 bytes and 32 bytes. I've also added a BRANCH_OVERRIDE variable which can bs set in the environment; this is probably not going to be useful to many people, but it will allow me to identify the osrelease[] string and avoid distributing a new kernel when the patch number is bumped due to a userland-only fix. Any objections to the following patch? @@ -33,6 +33,9 @@ TYPE="FreeBSD" REVISION="6.0" BRANCH="CURRENT" +if [ "X${BRANCH_OVERRIDE}" != "X" ]; then + BRANCH=${BRANCH_OVERRIDE} +fi RELEASE="${REVISION}-${BRANCH}" VERSION="${TYPE} ${RELEASE}" @@ -85,11 +88,14 @@ v=`cat version` u=${USER:-root} d=`pwd` i=`${MAKE:-make} -V KERN_IDENT` cat << EOF > vers.c $COPYRIGHT +#define VERSTR "${VERSION} #${v}: ${t}\\n ${u}@${h}:${d}\\n" +#define RELSTR "${RELEASE}" + char sccspad[32 - 4 /* sizeof(sccs) */] = { '\\0' }; char sccs[4] = { '@', '(', '#', ')' }; -char version[] = "${VERSION} #${v}: ${t}\\n ${u}@${h}:${d}\\n"; +char version[sizeof(VERSTR) > 256 ? sizeof(VERSTR) : 256] = VERSTR; char ostype[] = "${TYPE}"; -char osrelease[] = "${RELEASE}"; +char osrelease[sizeof(RELSTR) > 32 ? sizeof(RELSTR) : 32] = RELSTR; int osreldate = ${RELDATE}; char kern_ident[] = "${i}"; EOF Colin Percival From owner-freebsd-arch@FreeBSD.ORG Fri May 20 23:34:03 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD3EC16A4CF for ; Fri, 20 May 2005 23:34:03 +0000 (GMT) Received: from ms-smtp-04.nyroc.rr.com (ms-smtp-04.nyroc.rr.com [24.24.2.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2235F43D53 for ; Fri, 20 May 2005 23:34:03 +0000 (GMT) (envelope-from teevee@maine.rr.com) Received: from [192.168.1.103] (cpe-24-25-185-204.maine.res.rr.com [24.25.185.204])j4KNY0pl011311 for ; Fri, 20 May 2005 19:34:01 -0400 (EDT) Message-ID: <428E73FA.5040600@maine.rr.com> Date: Fri, 20 May 2005 19:34:18 -0400 From: steve User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-arch@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Subject: hppa arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 23:34:03 -0000 Will there ever be hppa supported releases of Freebsd? Just curious as I have a 7300 series workstation and HP/UX is boring. Thanks! From owner-freebsd-arch@FreeBSD.ORG Fri May 20 23:53:42 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FE1116A4D0 for ; Fri, 20 May 2005 23:53:42 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46A8D43D5E for ; Fri, 20 May 2005 23:53:41 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j4KNre9F031940; Fri, 20 May 2005 16:53:40 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j4KNree7031939; Fri, 20 May 2005 16:53:40 -0700 Date: Fri, 20 May 2005 16:53:40 -0700 From: Brooks Davis To: steve Message-ID: <20050520235340.GB31212@odin.ac.hmc.edu> References: <428E73FA.5040600@maine.rr.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zx4FCpZtqtKETZ7O" Content-Disposition: inline In-Reply-To: <428E73FA.5040600@maine.rr.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: freebsd-arch@freebsd.org Subject: Re: hppa arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 May 2005 23:53:42 -0000 --zx4FCpZtqtKETZ7O Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 20, 2005 at 07:34:18PM -0400, steve wrote: > Will there ever be hppa supported releases of Freebsd? Just curious as I= =20 > have a 7300 series workstation and HP/UX is boring. Highly unlikely. We don't generally port to architectures we know are known dead ends (i.e. the manufacture intends to kill them off). I'm pretty sure NetBSD has a port so you migth look there if you want to ditch HP/UX. -- Brooks --=20 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 --zx4FCpZtqtKETZ7O Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCjniDXY6L6fI4GtQRAj8HAKDSEwz/h9CHb2A/MZt7ljrpmNW1wQCgyzmx BPIUh2QpDsh8DwPRjqT0p5Y= =wBTm -----END PGP SIGNATURE----- --zx4FCpZtqtKETZ7O-- From owner-freebsd-arch@FreeBSD.ORG Sat May 21 09:12:27 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CE25516A4CE for ; Sat, 21 May 2005 09:12:27 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9EA9743DA2 for ; Sat, 21 May 2005 09:12:26 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so573973rne for ; Sat, 21 May 2005 02:12:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WmzhvBm6azQcnCrbankzm9VwZ0C3/vQYMSOB9roaXKKfhelfZmv+QdoY6/yvx9YKN+iG+JOCBEAvik9+fgKA6yAcYpw9kJ0vsMNDN7/7CIUMN5XzOsEK1No9QHSuy5MtseqiDhtFGr/SZmXIvfdsNWLi3lhAW3bbX7/VuYHPYPg= Received: by 10.38.75.4 with SMTP id x4mr585958rna; Sat, 21 May 2005 02:12:25 -0700 (PDT) Received: by 10.38.209.31 with HTTP; Sat, 21 May 2005 02:12:25 -0700 (PDT) Message-ID: <84dead7205052102126b30df91@mail.gmail.com> Date: Sat, 21 May 2005 09:12:25 +0000 From: Joseph Koshy To: Brooks Davis In-Reply-To: <20050520235340.GB31212@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <428E73FA.5040600@maine.rr.com> <20050520235340.GB31212@odin.ac.hmc.edu> cc: steve cc: freebsd-arch@freebsd.org Subject: Re: hppa arch X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Joseph Koshy List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 09:12:27 -0000 > I'm pretty sure NetBSD has a port so you migth look there if=20 > you want to ditch HP/UX. OpenBSD too: http://www.openbsd.org/hppa.html --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-arch@FreeBSD.ORG Sat May 21 23:30:34 2005 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 957A716A471 for ; Sat, 21 May 2005 23:30:34 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd3mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id A0FA443D88 for ; Sat, 21 May 2005 23:11:15 +0000 (GMT) (envelope-from cperciva@freebsd.org) Received: from pd4mr2so.prod.shaw.ca (pd4mr2so-qfe3.prod.shaw.ca [10.0.141.213]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV0055J4ERGP30@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 17:11:15 -0600 (MDT) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd4mr2so.prod.shaw.ca (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0IGV003604EROJ90@pd4mr2so.prod.shaw.ca> for freebsd-arch@freebsd.org; Sat, 21 May 2005 17:11:15 -0600 (MDT) Received: from [192.168.0.60] (S0106006067227a4a.vc.shawcable.net [24.87.209.6]) by l-daemon (iPlanet Messaging Server 5.2 HotFix 1.18 (built Jul 28 2003)) with ESMTP id <0IGV0079S4EQ01@l-daemon> for freebsd-arch@freebsd.org; Sat, 21 May 2005 17:11:15 -0600 (MDT) Date: Sat, 21 May 2005 16:11:07 -0700 From: Colin Percival To: freebsd-arch@freebsd.org Message-id: <428FC00B.3080909@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en X-Enigmail-Version: 0.91.0.0 User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050406) Subject: Scheduler fixes for hyperthreading X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 23:30:35 -0000 As you are probably all aware by now, HyperThreading has been disabled on the stable and security branches due to a problem with information leakage between threads which are scheduled simultaneously on the two processor cores. Clearly, some people (and at least one large company) are unhappy about us having hyperthreading disbaled, so the security team would like to see hyperthreading re-enabled by default as soon as we believe that this can be done safely. The following must be done before hyperthreading is re-enabled: 1. The scheduler must be taught to not run threads on the same processor core unless they p_candebug() each other. For reasons of performance and locking, this is probably best accomplished by only allowing threads to share a processor core if they belong to the same process. 2. When a thread is in the kernel, there must be a mechanism for it to IPI its siblings and put them to sleep, and then wake them up later. This would be used any time when a thread in the kernel is about to handle sensitive data in a non-oblivious manner; IPsec is a good example of where this would be necessary. Does anyone want to step forward to work on this? Colin Percival