From sacadmin Wed Mar 8 15:25:09 2006 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k28NP8IQ018598; Wed, 8 Mar 2006 15:25:09 -0800 (PST) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id k28NP7JM014239; Wed, 8 Mar 2006 15:25:07 -0800 (PST) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10/Submit) id k28NP7Oe014235; Wed, 8 Mar 2006 15:25:07 -0800 (PST) Date: Wed, 8 Mar 2006 15:25:07 -0800 (PST) Message-Id: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> From: Don Cragun To: PSARC@sac.sfbay.sun.com Cc: casper.dik@sun.com, craig.mohrman@sun.com, michael.shapiro@sun.com Subject: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] Status: RO Content-Length: 22550 Subject: PSARC FastTrack [03/15/2006]: Extended FILE space for 32-bit Solaris processes I am submitting this FastTrack for Craig Mohrman. It times out on Wednesday, March 15, 2006. A minor release binding is requested for changing _file to __file in struct DIR. A patch release binding is requested for everything else. If this FastTrack is approved, PSARC case 2001/680 (Large fd stdio) will be marked closed withdrawn. Sincerely, Don Cragun Template Version: @(#)sac_nextcase 1.56 10/26/05 SMI Copyright 2006 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: Extended FILE space for 32-bit Solaris processes 1.2. Name of Document Author/Supplier: Author: Craig Mohrman 1.3 Date of This Document: 08 March, 2006 THANKS ====== Firstly a note of thanks to Don Cragun, Casper Dik, and Mike Shapiro for their guidance, reviews, ideas, and baby sitting (of me). I could not have done this without them. Hopefully the 4th try will be the charm. 4. Technical Description NOTE ==== Please read the entire proposal before commenting. Much detail and many answers lie beneath. Thank you. Summary ======= 32-bit Solaris processes will no longer be limited to 256 FILE's with LITTLE chance of silent data corruption. Silent data corruption can only occur if: 1. the process uses FILE->_file directly, 2. the process uses the fileno() macro (the fileno() macro was removed from our headers in Solaris release 2.7) rather than the fileno() function, or 3. the process truncates the value returned by the fileno() function. This is a runtime change with no limit on the age of the software. Even pre-2.7 software will work. Background ========== It has been a historical limitation of UNIX implementations that an unsigned char is used to store the value of the file descriptor (fd) associated with the stream (FILE). The effect of this is that the maximum value such a file descriptor could take was 255. This limitation has become burdensome for a number of customers. See, for example: 1085341 _file in stdio.h should be an unsigned long 1147964 NIS+ servers start repeatedly doing FULL RESYNCS ... runs out of fd's 1173088 request to remove the stdio streams file pointer fopen limit of 256. 1253283 gethostbyname fails if more than 255 file descriptors are already open 1266821 lpsched goes into an infinite loop hanging. 4009255 getnettype limits # of fd's to 255 4031927 the use of fopen() in cdbopen() of libcdb fails when open files greater than 255 4043375 socketpair() returns EAGAIN. 4050822 dlopen() core dumps when no fds available (was ypmatch dumps core). 4081318 in.named: fdopen: Error 0 4101908 SUBSCRIBE/UNSUBSCRIBE fail if more than 256 files are open ... 4131997 pam_start() fails when the application has more than 255 open file .. 4152876 getspnam_r() fails due to use of fopen() in libnsl.so in 4156580 getnetlist uses fopen, limiting RPC to 256 descriptors 4166190 FNS uses fopen(), this is bad. 4239433 Request to remove the stdio streams file pointer fopen limit of 256. 4275900 dbx fails to open a file if there are more than 255 lwps running 4292123 Error in libsecurity: cannot open /etc/netconfig 4353836 if more than 255 file descriptors are already open then gethostbyname 4400631 "getgrent" calls "fopen" instead of "open" 4459640 Java crash with a load of more than 20 users, assertion on 4472001 gethostbyname failed with NO_RECOVERY when there are more .. 4472174 use of fopen in zip utils implementation 4472176 use of fopen in java sound implementation 4472179 use of fopen in J2SE networking classes implementation 4472183 Solaris: use of fopen() in timezone classes implementation 4472199 use of fopen() in java runtime profiling support 4472643 fopen and fdopen fail in less than FOPEN_MAX or STREAM_MAX calls 4481723 yacc generated code does not handle error returned by fdopen etc. Additionally, if application code uses a lot of file descriptors but also takes care to avoid stdio, it will still find that certain standard library functions break when fds 0...255 are all in use. (e.g., socket, nsl, nss and nameserver libraries alone contain nearly 100 calls to stdio functions returning a FILE *) This has lead to various bugs, many of which in effect require reimplementing parts of stdio inside applications or libraries, or rewriting an application to use file descriptors above 255 instead of using FILE * more naturally. This is a continuous maintenance burden, especially where additional code gets added to reimplement bits of stdio to work with fds > 255. While this limit is now lifted for 64-bit applications, we are still faced with this issue for our own 32-bit runtime, 32-bit JVM, and a variety of 32-bit applications. It is not possible for binary compatibility reasons to simply change the _file field of the FILE structure from an unsigned char to an int because this would cause the size of the structure to change and would therefore break binary compatibility constraints. This proposal draws on experiences and supersedes the following cases: PSARC/1996/413 - Lots of File Descriptors current status: closed superseded 1998/109 While discussing the case Steve Chessin proposed a reserved fd open against a device which yields the fd unusable. PSARC/1998/109 - Extended Stdio current status: closed withdrawn Joe Townsend and Mike Shapiro propose a new fcntl() command which will invalidate an fd that will be stored in the _file field. PSARC/2001/680 - Large fd stdio current status: discussing Casper Dik proposes a new "F" flag for internal usage of extended FILEs. If this case is approved, PSARC/2001/680 will be marked closed withdrawn. Overview of Changes =================== These changes will only affect 32-bit applications. The 64-bit environment is unchanged except for the fcntl(F_BADFD) system call which will fail. The default 32-bit case will work as it does today. The user must take action(s) in order to enable this feature. (I.e., opt in.) Applications that enable this feature will be able to associate any valid file descriptor (fd) with a STDIO stream. This feature can be enabled using a preloadable library or a new enable_extended_FILE_stdio(3C) function. When this feature is enabled, larger fd's (>255) will be stored in an auxiliary location and a bogus (bad) fd will be stored in the FILE->_file field. Improper accesses by the application to the FILE->_file field will either yield the proper underlying fd for those fd's <= 255 or the unavailable (bad) fd. Accessing the (bad) fd will yield errors. There is very little chance of silent data corruption. There are 2 programmatic interfaces allowing access to the larger than 256-fd FILE pool provided that the RLIMIT_NOFILE resource limit has been raised. The default RLIMIT_NOFILE is 256 fd's. The first interface is adding a flag, "F", to the existing mode string of standard I/O open calls, e.g. fopen(), fdopen(), popen(). This is intended to be used by library routines (e.g. gethostent()) but applications may use it as well. This interface provides no safeguards against misuse. The FILE pointer returned by these stdio open routines must never to passed to any uninspected code; data corruption may occur if uninspected code misuses a FILE pointer opened in this manner. The second interface, enable_extended_FILE_stdio(), is more generalized and does provide protection to software with unknown behaviors such as 3rd party libraries without source code. To aid in "cleaning up" source code which contains FILE->_file access we propose to rename FILE->_file to FILE->__file (additional "_"). This will forcibly break the compilation of any source containing references to FILE->_file. Obviously this will grab the attention of developers who will then hopefully recode FILE->_file to the more appropriate fileno(FILE). Sun code needs this as much as 3rd party code. This will very quickly clean up Solaris to be fiLE->_file clean and guarantee that using extended FILE will work throughout Solaris. Without this it will be very difficult to verify Solaris, and other software products, readiness. If it is known that the application accesses the FILE->_file field directly then this feature should not be used, even though we go to great lengths to handle all possible cases there can always be another case we did not think of. For well behaved applications (no direct FILE->_file accesses) then this works wonderfully. Details of Changes ================== 1. A new bitfield will be added to the FILE struct, __extendedfd. When this bitfield is set to 1, the file descriptor associated with the stream is stored as auxiliary data; not in _file. How _file is set in this case depends on other issues specified below. A second bitfield is added to the FILE struct, __extendedfd_nocheck. This bitfield is used to control error checking. 2. We add a new fcntl() command. marked_fd = fcntl(low_fd, F_BADFD, action) This fcntl() command will: A. mark the first currently closed file descriptor greater than or equal to low_fd to be unavailable for assignment as a file descriptor for any following system call that allocates a file descriptor, B. set the action to be taken by the kernel when marked_fd is passed in as an fd in subsequent system calls. If action is 0, any reference to marked_fd will return an error with errno set to EBADF; otherwise, any reference to marked_fd will send an "action" signal to the process and return an error with errno set to EBADF. The "action" may be any valid signal number. The "action" signal will not be sent if the application attempts close(marked_fd). We believe that many applications exist that attempt to close() fd's they did not open. This new fcntl() command will return the file descriptor that has been marked as unavailable. If no file descriptor in the range 3 <= low_fd <= marked_fd <= 255 can be marked, the fcntl() will fail and return -1. If the call fails, errno will be set as follows: EAGAIN All file descriptors in the inclusive range low_fd through 255 refer to files that are currently open in the process. EBADF low_fd is less than 3 or greater than 255. EEXIST A file descriptor has already been marked by an earlier call to fcntl(). EINVAL action is not a valid signal number. This fcntl() may only be called successfully once. Subsequent calls will return an error. An unallocatable file descriptor set by the fcntl() F_BADFD command will be inherited by a child across fork operations and cleared in the new process image during exec and spawn operations. This new fcntl(F_BADFD) command should not be used directly by applications. Applications should use enable_extended_FILE_stdio() (see #6 below) instead. Calling fcntl(F_BADFD) directly serves no purpose and would cause a subsequent call to enable_extended_FILE_stdio() to fail. 3. An additional flag "F" is added to the mode argument in our implementation of fopen(), fdopen(), and popen(). This flag will allow fopen() and fdopen() to assign/specify a file descriptor larger than 255. popen() will also recognize "F" in its mode string because it passes its mode string through to fdopen(). The "F" flag will only be recognized if it is the last character of the mode argument. When fopen() is called it will use the lowest available file descriptor. The "F" flag, when used by Sun's engineers, will be used by library routines only if that use of fopen() is to create a stream that will not be returned to application code for any use. If the file descriptor allocated (after F flag processing) is less than 256, __extendedfd will be set to 0 and _file will be set to the new file descriptor. Otherwise the action depends on the current value of __STDIO_bad_fd and the presence of the F flag. If __STDIO_bad_fd is less than 0 and the F flag is not present, the fopen() or fdopen() will fail; otherwise __extendedfd will be set to 1, _file will be set to (unsigned char)__STDIO_bad_fd, and the file descriptor will be stored in an auxiliary location. Another new bitfield, FILE->__extendedfd_nocheck, will be set to 1 to help us manage this internally requested extended FILE. These changes only apply to the 32-bit code path. The following pseudo code demonstrates what the new 32-bit fopen() might look like: libc will initialize: __STDIO_bad_fd = -1; /* runtime is signaling us to use */ /* extended FILEs */ /* default < 0; no extended FILEs */ fopen(filename, mode) { fd = open(filename, ...) if (fd < 0) return (NULL) if(fd < 256) { FILE->_file = fd FILE->__extendedfd = 0 FILE->__extendedfd_nocheck = 1 } else if ("F"_is_the_last_character_in_mode) { FILE->__extendedfd = 1 FILE->__extendedfd_nocheck = 1 fd is stored in an auxiliary location } else if(__STDIO_bad_fd >= 0) { FILE->_file = (unsigned char)__STDIO_bad_fd FILE->__extendedfd = 1 FILE->__extendedfd_nocheck = 0 fd is stored in an auxiliary location } else { close(fd) errno = EMFILE return (NULL) } } The possible scenarios are thus: A) User does nothing and runs applications: Everything works or fails as before. B) User raises RLIMIT_NOFILE: Normal stdio calls still limited to 256 FILE's but any usage of the "F" flag will allow RLIMIT_NOFILE FILE's. C) User raises RLIMIT_NOFILE and pre-loads extended FILE library: Application gets RLIMIT_NOFILE FILE's. Direct access to FILE->_file are preserved for the fd's <= 255. fd's > 255 will receive errors or signal. User's choice. Solaris internal libraries ("F" usage) gets the same as B above. $ ulimit -n 1000 $ LD_PRELOAD_32=/usr/lib/extendedFILE.so.1 \ application [args...] 4. It has been noted that private copies of STDIO code exist to locally alleviate the 256 fd limitation. These codes will be identified and subsequently converted to use the new STDIO and "F" flag. These changes are not part of this case but are being duly noted for future action. [Note: Casper has alerted me to one such case in networking code. I can find no other instances.] Upon integration, Sun Engineering will be notified of the availability of this change. 5. We add a preloadable library that can be used to invoke the new enable_extended_FILE_stdio(low_fd, action) function before entering main(). If the user sets the environment variable STDIO_BADFD to a value between 3 and 255 inclusive when loading the preloadable library, low_fd will be set to that value. Otherwise, low_fd will be given the default value 196. The "action" parameter can also be user specified. If the "action" parameter is not specified the default "action" will be to return errors and set errno as indicated above. The user can also choose to have signal sent by setting the environment variable STDIO_BADFD_SIGNAL to the desired signal number or name before launching their application. $ ulimit -n 1000 $ LD_PRELOAD_32=/usr/lib/extendedFILE.so.1 STDIO_BADFD=100 \ STDIO_BADFD_SIGNAL=SIGABRT application [args...] 6. A second programming interface; enable_extended_FILE_stdio(int fd, int action) is added to allow 3rd parties and end users access to the interface used in the preloadable library. (#5 above) The fd argument is the starting point to begin searching for an available fd to be marked as the unallocatable file descriptor. Its value must be between 3-255 inclusive. If an available fd cannot be found an error is returned. A value of -1 for fd will use a built in scheme for searching for an available fd. The action argument is the requested signal to be sent to the application in the event of an error in the usage of this mechanism or improper access to FILE->_file is detected. A value of -1 yields the default SIGABRT signal. A value of 0 disables the sending of a signal. 7. Rename FILE->_file to FILE->__file (additional "_"). This will aid all of Sun and 3rd parties in the source code cleanup that directly accesses _file. This is needed to ensure the safety in using the extended FILE mechanism. This change will not affect running code in any way; it only generates errors at compile time. References to _file in the remainder of this proposal refer to code that exists in applications that has not yet been converted to use public interfaces. The four programming interfaces described here provide similar features, but are intended for different audiences. The fcntl(low_fd, F_BADFD, action) function should never be called directly by applications. It is only intended to be used by enable_extended_FILE_stdio() which performs the additional "paperwork" needed to fully enable this feature. The "F" mode flag to fdopen(), fopen(), and popen() is intended for use in applications and libraries in cases where it is known that the FILE pointer returned will never be passed to any code that may use the FILE pointer to directly access the _file field. This flag allows large file descriptors to be used in cases where it is known that the FILE pointer will only be used in safe ways. Fewer checks for invalid file descriptors are performed since all uses of the "F" mode flag can be assumed to have been inspected. The "F" flag must never be used in any case where the FILE pointer will be given to uninspected code that might directly access _file through that FILE pointer. Passing a FILE pointer opened using the "F" flag to uninspected code could lead to data corruption. The "F" flag's primary intention is to allow the Solaris libraries to open configuration files with stdio functions when the file descriptors below 256 have been depleted. The enable_extended_FILE_stdio() function and the /usr/lib/extendedFILE.so.1 preloadable library can be used by any application that needs to use extended file descriptors with STDIO routines. They fully enable the extended file descriptors for STDIO features. New applications and applications that can be easily modified are expected to use the enable_extended_FILE_stdio() function; the preloadable library provides the same features when an existing application can't be modified to call enable_extended_FILE_stdio(). As long as the application checks for error returns and doesn't change the file descriptor being used by an STDIO stream by directly changing _file, using extended file descriptors will not increase the likelihood of data corruption. This is intended for 3rd party use. There is one theoretical case where this fails: (void) close(FILE->_file); FILE->_file = myfd; Assume FILE->_file is filled with the marked badfd file descriptor because we are using extended FILEs. The close() function will fail but since this usage ignores the return status the application proceeds to perform low level I/O on FILE->_file while calls to STDIO functions would continue to use the original, extended file descriptor. If the application continues using STDIO functions after changing FILE->_file silent data corruption could occur because the application thinks it has changed fd's via the above assignment but the actual STDIO fd is stored in the auxiliary location. The chances for corruption are even higher if myfd has a value greater than 255 and is truncated by the assignment to 8-bit _file. If the application does use _file directly (including using the fileno() macro that was provided in in Solaris 2.0 through 2.7), it should not use this feature. PERFORMANCE =========== The default, extended FILE's not enabled, will maintain current performance. With extended FILE's enabled, access to fd's <= 255 will also maintain current performance. fd's >= 256 will take a performance hit due to storage/retrieval of the file descriptor in an auxiliary location. fopen() with fds < 256 is as fast as before. fopen() is 5-10% slower with fd's >= 256 than with fd's < 256. Only 32 bit applications are affected. There is a small penalty in the remainder of the stdio code where file descriptors are used; but since stdio tries hard to avoid using file descriptors and the use of file descriptors causes much more expensive system calls this disappears in the noise. DOCUMENTATION ============= The fopen(3C), fdopen(3C), and popen(3C) man pages will be adjusted to this new behavior. A new man page for extendedFILE.so.1 will be created to explain in great detail how to use the feature and various scenarios will be presented. A new man page for enable_extended_FILE_stdio() will be created to explain the programmatic interface. FAILING CASE ============ We have added code to detect the theoretical failing case described above. If this failing case is detected then a simple message will be printed to stderr and abort() will be called. Exported Interfaces =================== Interface Stability --------- --------- FILE->__extendedfd project private FILE->__extendedfd_nocheck project private "F" flag to fopen() evolving "F" flag in fdopen() evolving "F" flag in popen() evolving F_BADFD fcntl() command project private enable_extended_FILE_stdio() evolving /usr/lib/extendedFILE.so.1 stable STDIO_BADFD env. variable stable STDIO_BADFD_SIGNAL env. variable stable STDIO_BADFD_SIGNAL_MESSAGE env. variable stable 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From sacadmin Wed Mar 8 15:58:13 2006 Received: from norton.SFBay.Sun.COM (norton.SFBay.Sun.COM [129.146.228.124]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k28NwDIQ019583 for ; Wed, 8 Mar 2006 15:58:13 -0800 (PST) Received: from norton.SFBay.Sun.COM (localhost [127.0.0.1]) by norton.SFBay.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k28NwCxu170801; Wed, 8 Mar 2006 15:58:12 -0800 (PST) Received: (from jwadams@localhost) by norton.SFBay.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k28NwCk8170800; Wed, 8 Mar 2006 15:58:12 -0800 (PST) Date: Wed, 8 Mar 2006 15:58:11 -0800 From: Jonathan Adams To: Don Cragun Cc: PSARC@sac.sfbay.sun.com, casper.dik@sun.com, craig.mohrman@sun.com, michael.shapiro@sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] Message-ID: <20060308235811.GZ101087@eng.sun.com> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> User-Agent: Mutt/1.4.2.1i Status: RO Content-Length: 3371 On Wed, Mar 08, 2006 at 03:25:07PM -0800, Don Cragun wrote: > Subject: PSARC FastTrack [03/15/2006]: Extended FILE space for 32-bit Solaris processes ... > A minor release binding is requested for changing _file to __file in > struct DIR. A patch release binding is requested for everything else. Uh, here you say "struct DIR"", but the only mention of _file below is in reference to "struct FILE". ... > To aid in "cleaning up" source code which contains FILE->_file > access we propose to rename FILE->_file to FILE->__file > (additional "_"). This will forcibly break the compilation of > any source containing references to FILE->_file. Obviously > this will grab the attention of developers who will then > hopefully recode FILE->_file to the more appropriate > fileno(FILE). Sun code needs this as much as 3rd party code. > This will very quickly clean up Solaris to be fiLE->_file clean > and guarantee that using extended FILE will work throughout > Solaris. Without this it will be very difficult to verify > Solaris, and other software products, readiness. Shouldn't this be listed in the interface table? > 2. We add a new fcntl() command. > marked_fd = fcntl(low_fd, F_BADFD, action) > This fcntl() command will: > A. mark the first currently closed file descriptor greater > than or equal to low_fd to be unavailable for assignment > as a file descriptor for any following system call that > allocates a file descriptor, > B. set the action to be taken by the kernel when marked_fd > is passed in as an fd in subsequent system calls. If > action is 0, any reference to marked_fd will return an > error with errno set to EBADF; otherwise, any reference > to marked_fd will send an "action" signal to the > process and return an error with errno set to EBADF. > The "action" may be any valid signal number. The > "action" signal will not be sent if the application > attempts close(marked_fd). We believe that many > applications exist that attempt to close() fd's they > did not open. But the close will not succeed, right? The file descriptor will remain "bad" for the lifetime of the process? What happens if you dup2() over the bad FD? Or someone in the kernel closeandsetf()s it? > 4. It has been noted that private copies of STDIO code exist > to locally alleviate the 256 fd limitation. These codes > will be identified and subsequently converted to use the > new STDIO and "F" flag. These changes are not part of this > case but are being duly noted for future action. [Note: > Casper has alerted me to one such case in networking code. > I can find no other instances.] > > Upon integration, Sun Engineering will be notified of the > availability of this change. But one reason for the current __nsl_c_f{open,gets,close}() interface is that they *don't* use FDs beneath 256 (they use F_DUPFD to move the descriptor above 255; see _raise_fd()); that way, they don't interfere with the <=255 fd space. If we switch them over to using the "F" flag, they'll start interfering again. Shouldn't the "F" flag imply "please move the descriptor above 255, if possible", so that libraries will not interfere with applications which can't use large descriptors? Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development From sacadmin Wed Mar 8 16:20:07 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k290K6IQ019988 for ; Wed, 8 Mar 2006 16:20:07 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k290JtWa029333; Wed, 8 Mar 2006 19:19:55 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k290Js5X017560; Wed, 8 Mar 2006 19:19:54 -0500 (EST) Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] From: Bill Sommerfeld To: Don Cragun Cc: PSARC@sac.sfbay.sun.com, Casper.Dik@sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com In-Reply-To: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> Content-Type: text/plain Message-Id: <1141863593.15640.604.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Wed, 08 Mar 2006 19:19:54 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1746 first: yay! that said, i have some relatively minor comments: > If this FastTrack is approved PSARC case 2001/680 (Large fd stdio) > will be marked closed withdrawn. nit: "closed duplicate 2006/162" might be a better choice Observability: Does the toxic descriptor reserved by F_BADFD appear in the output of pfiles? Does it appear in the process's /proc/$pid/fd directory? if so, what does it look like? If it appears, what happens if a process opens another process's toxic fd? Corner case: pfiles operates by controlling an agent LWP in the target process, causing that process to execute various usually-safe syscalls on its descriptors. (I learned this when I found, and then later fixed, bug 6183247) If the F_BADFD "action" is set to send a signal, will running pfiles on the target process trigger that signal from the agent LWP? Rationale for single toxic descriptor? On Wed, 2006-03-08 at 18:25, Don Cragun wrote: > This fcntl() may only be called successfully once. > Subsequent calls will return an error. An unallocatable > file descriptor set by the fcntl() F_BADFD command will be > inherited by a child across fork operations and cleared in > the new process image during exec and spawn operations. > > This new fcntl(F_BADFD) command should not be used directly > by applications. Applications should use > enable_extended_FILE_stdio() (see #6 below) instead. > Calling fcntl(F_BADFD) directly serves no purpose and would > cause a subsequent call to enable_extended_FILE_stdio() to > fail. This looks like a perhaps unnecessarily fragile spot in the design; is there some reason why it's difficult to mark multiple descriptors as toxic? - Bill From sacadmin Wed Mar 8 19:29:54 2006 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k293TrIQ026225 for ; Wed, 8 Mar 2006 19:29:54 -0800 (PST) Received: from spartan.SFBay.Sun.COM (localhost [127.0.0.1]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with ESMTP id k293TrJM014835; Wed, 8 Mar 2006 19:29:53 -0800 (PST) Received: (from dwc@localhost) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10/Submit) id k293TrRK014834; Wed, 8 Mar 2006 19:29:53 -0800 (PST) Date: Wed, 8 Mar 2006 19:29:53 -0800 (PST) Message-Id: <200603090329.k293TrRK014834@spartan.SFBay.Sun.COM> From: Don Cragun To: jonathan.adams@sun.com Cc: PSARC@sac.sfbay.sun.com, casper.dik@sun.com, craig.mohrman@sun.com, michael.shapiro@sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] Status: RO Content-Length: 2736 >From jwadams@norton.SFBay.Sun.COM Wed Mar 8 15:58:18 2006 > >On Wed, Mar 08, 2006 at 03:25:07PM -0800, Don Cragun wrote: >> Subject: PSARC FastTrack [03/15/2006]: Extended FILE space for 32-bit Solaris processes >... >> A minor release binding is requested for changing _file to __file in >> struct DIR. A patch release binding is requested for everything else. > >Uh, here you say "struct DIR"", but the only mention of _file below is >in reference to "struct FILE". My mistake. You're correct; I meant struct FILE. (I had been researching a telldir(), closedir(), opendir(), seekdir() sequnece issue just before submitting this case and my fingers had learned to type DIR too well. ;-{ ) > >... >> To aid in "cleaning up" source code which contains FILE->_file >> access we propose to rename FILE->_file to FILE->__file >> (additional "_"). This will forcibly break the compilation of ... ... ... > >Shouldn't this be listed in the interface table? Yes. I'll add it, along with any other approved changes to the spec, before marking the case closed. (I expect it will be marked project private, but need to verify that with the project team.) > >> 2. We add a new fcntl() command. >> marked_fd = fcntl(low_fd, F_BADFD, action) >> This fcntl() command will: >> A. mark the first currently closed file descriptor greater ... ... ... >> B. set the action to be taken by the kernel when marked_fd ... ... ... > >But the close will not succeed, right? The file descriptor will remain >"bad" for the lifetime of the process? The close() will not succeed; the process just won't be sent a signal for this specific case of close(marked_fd). > >What happens if you dup2() over the bad FD? Or someone in the kernel >closeandsetf()s it? I will let the project team respond to the rest of these. Note that since Craig has been called for jury duty, Casper may be responding rather than Craig. > >> 4. It has been noted that private copies of STDIO code exist >> to locally alleviate the 256 fd limitation. These codes >> will be identified and subsequently converted to use the >> new STDIO and "F" flag. These changes are not part of this ... ... ... > >But one reason for the current __nsl_c_f{open,gets,close}() interface is >that they *don't* use FDs beneath 256 (they use F_DUPFD to move the >descriptor above 255; see _raise_fd()); that way, they don't interfere >with the <=255 fd space. If we switch them over to using the >"F" flag, they'll start interfering again. > >Shouldn't the "F" flag imply "please move the descriptor above 255, if >possible", so that libraries will not interfere with applications >which can't use large descriptors? > >Cheers, >- jonathan From sacadmin Wed Mar 8 23:49:23 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k297nMIQ000088 for ; Wed, 8 Mar 2006 23:49:23 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k297nJCM013867; Thu, 9 Mar 2006 08:49:19 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k297nIDk021328; Thu, 9 Mar 2006 08:49:18 +0100 (MET) Message-Id: <200603090749.k297nIDk021328@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Jonathan Adams cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <20060308235811.GZ101087@eng.sun.com> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060308235811.GZ101087@eng.sun.com> Date: Thu, 09 Mar 2006 08:49:18 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 2048 >But the close will not succeed, right? The file descriptor will remain >"bad" for the lifetime of the process? Correct. >What happens if you dup2() over the bad FD? Or someone in the kernel >closeandsetf()s it? Currently the only call to closeandsetf() with a non-NULL second argument is the call as a result of F_DUP2FD. The "setf" portion of that call cannot fail so the only affected caller was changed to not call closeandsetf(). The fd allocation routines make sure the fd is never allocated. >But one reason for the current __nsl_c_f{open,gets,close}() interface is >that they *don't* use FDs beneath 256 (they use F_DUPFD to move the >descriptor above 255; see _raise_fd()); that way, they don't interfere >with the <=255 fd space. If we switch them over to using the >"F" flag, they'll start interfering again. That's arguably bug in the implementation of those interfaces. If you look at the bug reports that led to the creation of those functions you see that the problem the fixes address was fopen failing *in the library* because the *application* exhausted fds <= 255 (for sockets and such). Other reasons to not follow this example are: - the FILE *s in the library are shortlived and do not exhaust file descriptors for applications; applications usually don't have control when those files are used and libraries often close them before returning. We're talking about one additional fd, typically, for hypothetical applications using fopen() running close to the limit. The are no bug reports about such applications. - the fcntl(fd, F_DUP2FD, 256) call usually fails because the default descriptor softlimit is 256. - adding the code to check for "F" and move the fd will add costs for *all* callers *and* the code will usually fail anyway. >Shouldn't the "F" flag imply "please move the descriptor above 255, if >possible", so that libraries will not interfere with applications >which can't use large descriptors? We considered that but rejected it for the above reasons. Casper From sacadmin Wed Mar 8 23:58:19 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k297wIIQ001032 for ; Wed, 8 Mar 2006 23:58:19 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k297wGCM016161; Thu, 9 Mar 2006 08:58:16 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k297wGDk004047; Thu, 9 Mar 2006 08:58:16 +0100 (MET) Message-Id: <200603090758.k297wGDk004047@vaticaan.Holland.Sun.COM> From: Casper.Dik@sun.com To: Bill Sommerfeld cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <1141863593.15640.604.camel@thunk> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <1141863593.15640.604.camel@thunk> Date: Thu, 09 Mar 2006 08:58:16 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 2098 >Observability: > >Does the toxic descriptor reserved by F_BADFD appear in the output of >pfiles? No, it appears as a closed file. >Does it appear in the process's /proc/$pid/fd directory? if so, what >does it look like? No. It is a closed file descriptor which cannot be used. >If it appears, what happens if a process opens another process's toxic >fd? N/A >Corner case: > >pfiles operates by controlling an agent LWP in the target process, >causing that process to execute various usually-safe syscalls on its >descriptors. >(I learned this when I found, and then later fixed, bug 6183247) >If the F_BADFD "action" is set to send a signal, will running pfiles on >the target process trigger that signal from the agent LWP? If the injected agent tries to operates on the bad file descriptor, then yes. However, that means that the agent lwp does something on an fd which appears otherwise closed. >Rationale for single toxic descriptor? It's partially an implementation artefact and also because we don't need any more. The implementation of a toxic file descriptor turned out to be tricky because of some properties of file descriptor handling. In earlier discussion a "bad device" was suggested. However, it is not possible to make a "bad fd" which actually refers to a file/vnode whatever be immune to close() without also modifying the locations where close() an dup2() happen in the kernel. So the implementation actually uses one field in the per-process file table to indicate that a bad descriptor exists. In the descriptor table, the file looks like it is not used but the code which allocates file descriptors is taught to never allocate it. >This looks like a perhaps unnecessarily fragile spot in the design; is >there some reason why it's difficult to mark multiple descriptors as >toxic? See above. I'm don't think F_BADFD should be for general consumption and calling it is not supported (it also fails in 64 bit applications) We could, however, make later calls to F_BADFD return the already allocated bad descriptor and just change the action. Casper From sacadmin Thu Mar 9 01:21:12 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k299LCIQ002569 for ; Thu, 9 Mar 2006 01:21:12 -0800 (PST) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k299LAx13108; Thu, 9 Mar 2006 02:21:10 -0700 (MST) Received: from vpn-129-150-117-36.uk.sun.com ([129.150.117.36]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1FHHMb-0005Rq-KM; Thu, 09 Mar 2006 09:23:17 +0000 Message-ID: <440FF364.1080909@sun.com> Date: Thu, 09 Mar 2006 09:20:36 +0000 From: Alan Burlison User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Don Cragun CC: PSARC@sac.sfbay.sun.com, casper.dik@sun.com, craig.mohrman@sun.com, michael.shapiro@sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> In-Reply-To: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 4087 I have several questions: > 3. An additional flag "F" is added to the mode argument in our > implementation of fopen(), fdopen(), and popen(). This > flag will allow fopen() and fdopen() to assign/specify a > file descriptor larger than 255. popen() will also > recognize "F" in its mode string because it passes its mode > string through to fdopen(). What happens if someone codes to our interface (i.e. uses the "F" flag) and then tries to build the code on another system that doesn't support the F flag? Will errors ensue, or do the appropriate standards specify that unrecognised flag characters to fopen() et al should be ignored? > 5. We add a preloadable library that can be used to invoke the > new enable_extended_FILE_stdio(low_fd, action) function > before entering main(). If the user sets the environment > variable STDIO_BADFD to a value between 3 and 255 inclusive > when loading the preloadable library, low_fd will be set to > that value. Otherwise, low_fd will be given the default > value 196. > > The "action" parameter can also be user specified. If the > "action" parameter is not specified the default "action" > will be to return errors and set errno as indicated above. > The user can also choose to have signal sent by setting the > environment variable STDIO_BADFD_SIGNAL to the desired > signal number or name before launching their application. > > $ ulimit -n 1000 > $ LD_PRELOAD_32=/usr/lib/extendedFILE.so.1 STDIO_BADFD=100 \ > STDIO_BADFD_SIGNAL=SIGABRT application [args...] Why is the preload required, why can't libc check for the environment variables at startup and do the right thing automatically? We frequently tell customers that LD_PRELOAD is *only* to be used for testing and debugging and in general LD_PRELOAD is an evil hack that causes all sorts of deployment issues, I'm concerned that we are proposing to use it here. > 6. A second programming interface; > enable_extended_FILE_stdio(int fd, int action) is added to > allow 3rd parties and end users access to the interface > used in the preloadable library. (#5 above) The fd > argument is the starting point to begin searching for an > available fd to be marked as the unallocatable file > descriptor. Its value must be between 3-255 inclusive. If > an available fd cannot be found an error is returned. A > value of -1 for fd will use a built in scheme for searching > for an available fd. The action argument is the requested > signal to be sent to the application in the event of an > error in the usage of this mechanism or improper access to > FILE->_file is detected. A value of -1 yields the default > SIGABRT signal. A value of 0 disables the sending of a > signal. How will the signal handler distinguish that a fd > 256 is the cause of it's invocation? Earlier on you say that errno will be set to EBADF, but that seems a bit generic - errno can get set to EBADF in many ways. > The enable_extended_FILE_stdio() function and the > /usr/lib/extendedFILE.so.1 preloadable library can be used by > any application that needs to use extended file descriptors > with STDIO routines. They fully enable the extended file > descriptors for STDIO features. New applications and > applications that can be easily modified are expected to use > the enable_extended_FILE_stdio() function; the preloadable > library provides the same features when an existing application > can't be modified to call enable_extended_FILE_stdio(). As > long as the application checks for error returns and doesn't > change the file descriptor being used by an STDIO stream by > directly changing _file, using extended file descriptors will > not increase the likelihood of data corruption. This is > intended for 3rd party use. Can extended stdio be turned off as well as on? What happens if I need to dlopen() a library that will fail with it turned on? -- Alan Burlison -- From sacadmin Thu Mar 9 01:33:24 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k299XNIQ002651 for ; Thu, 9 Mar 2006 01:33:24 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k299XCCM028395; Thu, 9 Mar 2006 10:33:12 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k299XCDk015366; Thu, 9 Mar 2006 10:33:12 +0100 (MET) Message-Id: <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Alan Burlison cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <440FF364.1080909@sun.com> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> Date: Thu, 09 Mar 2006 10:33:12 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 2166 >What happens if someone codes to our interface (i.e. uses the "F" flag) >and then tries to build the code on another system that doesn't support >the F flag? Will errors ensue, or do the appropriate standards specify >that unrecognised flag characters to fopen() et al should be ignored? The standard specifies the following about the mode: The argument mode points to a string beginning with one of the following sequences: (listed all modes) This leaves open the possibility of adding additional characters and ignoring them. But for maximum portability, it is probably advised to use something like: #if defined(SOLARIS_LARGE_FD) && !defined(_LP64) #define FOPEN_F "F" #else #define FOPEN_F "" #endif And use: fopen(file, "rw" FOPEN_F); >Why is the preload required, why can't libc check for the environment >variables at startup and do the right thing automatically? We >frequently tell customers that LD_PRELOAD is *only* to be used for >testing and debugging and in general LD_PRELOAD is an evil hack that >causes all sorts of deployment issues, I'm concerned that we are >proposing to use it here. The provided LD_PRELOAD is precisely for such a reason; adding the code to the program is much preferred and the LD_PRELOAD is provided as a workaround similar to 0@0.so >How will the signal handler distinguish that a fd > 256 is the cause of >it's invocation? Earlier on you say that errno will be set to EBADF, >but that seems a bit generic - errno can get set to EBADF in many ways. It won't be able to distinguish between the two in the current implementation (it's primary purpose is to abort programs). >Can extended stdio be turned off as well as on? What happens if I need >to dlopen() a library that will fail with it turned on? No, it cannot be turned off as that would leave all the FILE *s with fp->_file set to bad_fd in limbo. If you dlopen() a library which will fail in the presence of extended FILEs then that same library will also fail when the feature is disabled but in a different manner. It will fail fopen()s as the library will not encounter the problem until fds < 256 are exhausted. Casper From sacadmin Thu Mar 9 01:48:23 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k299mNIQ002783 for ; Thu, 9 Mar 2006 01:48:23 -0800 (PST) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k299mJx21270; Thu, 9 Mar 2006 02:48:19 -0700 (MST) Received: from vpn-129-150-120-84.uk.sun.com ([129.150.120.84]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1FHHmt-0005YT-1A; Thu, 09 Mar 2006 09:50:27 +0000 Message-ID: <440FF9DF.3080703@sun.com> Date: Thu, 09 Mar 2006 09:48:15 +0000 From: Alan Burlison User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Casper.Dik@sun.com CC: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> In-Reply-To: <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 2627 Casper.Dik@Sun.COM wrote: > The standard specifies the following about the mode: > > The argument mode points to a string beginning with one of the > following sequences: > (listed all modes) > > This leaves open the possibility of adding additional characters > and ignoring them. Have we tested this out on other platforms to see if they *do* ignore the extra flags? > But for maximum portability, it is probably advised to use something like: > > > #if defined(SOLARIS_LARGE_FD) && !defined(_LP64) > #define FOPEN_F "F" > #else > #define FOPEN_F "" > #endif > > And use: > > fopen(file, "rw" FOPEN_F); This is (with all due respect) pretty vile :-( >> Why is the preload required, why can't libc check for the environment >> variables at startup and do the right thing automatically? We >> frequently tell customers that LD_PRELOAD is *only* to be used for >> testing and debugging and in general LD_PRELOAD is an evil hack that >> causes all sorts of deployment issues, I'm concerned that we are >> proposing to use it here. > > The provided LD_PRELOAD is precisely for such a reason; adding the > code to the program is much preferred and the LD_PRELOAD is provided > as a workaround similar to 0@0.so Yes, but why is the LD_PRELOAD needed, why can't libc just check the environment variables directly? I'm *really* not enamoured of this (ab)use of LD_PRELOAD. >> How will the signal handler distinguish that a fd > 256 is the cause of >> it's invocation? Earlier on you say that errno will be set to EBADF, >> but that seems a bit generic - errno can get set to EBADF in many ways. > > It won't be able to distinguish between the two in the current > implementation (it's primary purpose is to abort programs). Then shouldn't the signal number be fixed to SIGABRT? I still think we need to be unambiguously able to tell why the handler was called. >> Can extended stdio be turned off as well as on? What happens if I need >> to dlopen() a library that will fail with it turned on? > > No, it cannot be turned off as that would leave all the FILE *s with > fp->_file set to bad_fd in limbo. > > If you dlopen() a library which will fail in the presence of > extended FILEs then that same library will also fail when the feature > is disabled but in a different manner. It will fail fopen()s as the > library will not encounter the problem until fds < 256 are exhausted. Ok. I'd also suggest that it might be a good idea to publish this ARC case via Opensolaris as people outside Sun will probably have more experience of other systems than we have. -- Alan Burlison -- From sacadmin Thu Mar 9 02:02:09 2006 Received: from nis-uk.uk.sun.com (nis-uk.UK.Sun.COM [129.156.85.41]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29A27IQ003423 for ; Thu, 9 Mar 2006 02:02:08 -0800 (PST) Received: from enospc.uk.sun.com (enospc [129.156.173.14]) by nis-uk.uk.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k29A1joR028842; Thu, 9 Mar 2006 10:01:45 GMT Received: from [129.156.173.21] (enoexec [129.156.173.21]) by enospc.uk.sun.com (8.13.4+Sun/8.13.3/CTE 3.0) with ESMTP id k29A1iuI002146; Thu, 9 Mar 2006 10:01:44 GMT Message-ID: <440FFD08.6020003@Sun.COM> Date: Thu, 09 Mar 2006 10:01:44 +0000 From: Darren J Moffat User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Casper.Dik@Sun.COM CC: Alan Burlison , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> In-Reply-To: <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 527 Casper.Dik@sun.com wrote: > #if defined(SOLARIS_LARGE_FD) && !defined(_LP64) > #define FOPEN_F "F" > #else > #define FOPEN_F "" > #endif > > And use: > > fopen(file, "rw" FOPEN_F); When the large file support was added there was the option to specifically code to the transitional API or to just enable large file awareness by passing compilation flags. Is it possible to do something similar in this case so that the source doesn't need to be touched and the runtime doesn't need to use LD_PRELOAD ? -- Darren J Moffat From sacadmin Thu Mar 9 02:45:53 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29AjqIQ003969 for ; Thu, 9 Mar 2006 02:45:53 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k29AjmCM007616; Thu, 9 Mar 2006 11:45:49 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k29AjmDk023077; Thu, 9 Mar 2006 11:45:48 +0100 (MET) Message-Id: <200603091045.k29AjmDk023077@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Darren J Moffat cc: Alan Burlison , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <440FFD08.6020003@Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> <440FFD08.6020003@Sun.COM> Date: Thu, 09 Mar 2006 11:45:48 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1433 >Casper.Dik@sun.com wrote: >> #if defined(SOLARIS_LARGE_FD) && !defined(_LP64) >> #define FOPEN_F "F" >> #else >> #define FOPEN_F "" >> #endif >> >> And use: >> >> fopen(file, "rw" FOPEN_F); > > >When the large file support was added there was the option to >specifically code to the transitional API or to just enable large >file awareness by passing compilation flags. > >Is it possible to do something similar in this case so that the >source doesn't need to be touched and the runtime doesn't need >to use LD_PRELOAD ? I did that once, but the combinatorial explosion is just horrid. (fopen fopenF fopenF64 fopen64 popen popenF fdopen fdopenF freopen freopenF freopen64 freopenF64 and a few more; and then there are a few more functions which call fopen and return a file) I personally believe that the "F" flag should not be documented and it certainly is not to be used by applications. It is documented purely for the use in libraries which don't want to fail due to a shortage of low fds, *not* applications. (But then, private interfaces are much less private than before now) Or perhaps we should just bite the bullet and enable it by default and when users or applications raise the fd limit *and* break the rules they will find some processes aborting. And have a single variable STDIO_DISABLE_XFDS; but this means allocating an fd for each 32 bit application (somewhat more expensive process startup) Casper From sacadmin Thu Mar 9 02:51:59 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29ApwIQ003992 for ; Thu, 9 Mar 2006 02:51:59 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k29AptCM010345; Thu, 9 Mar 2006 11:51:56 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k29AptDk000976; Thu, 9 Mar 2006 11:51:55 +0100 (MET) Message-Id: <200603091051.k29AptDk000976@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Alan Burlison cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <440FF9DF.3080703@sun.com> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> <440FF9DF.3080703@sun.com> Date: Thu, 09 Mar 2006 11:51:55 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 941 >Have we tested this out on other platforms to see if they *do* ignore >the extra flags? No; I believe this is outside the scope of the project. >This is (with all due respect) pretty vile :-( Yep. This is why applications in general should use the one "enable feature" call and not the "F" flag. >Yes, but why is the LD_PRELOAD needed, why can't libc just check the >environment variables directly? I'm *really* not enamoured of this >(ab)use of LD_PRELOAD. Because it costs. Startup speed of programs isn't stellar on Solaris already. Because there still is some danger of breakage and we prefer to make it slightly more obvious that you shouldn't lightheartedly "just set the environment variable" as LD_PRELOAD will wave red or yellow flags. OTOH, libthreads induction into libc already makes libc scan the entire environment anyway, so .... Still, having it as an environment variable may send the wrong message. Casper From sacadmin Thu Mar 9 03:08:53 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29B8qIQ004758 for ; Thu, 9 Mar 2006 03:08:52 -0800 (PST) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k29B8nx18555; Thu, 9 Mar 2006 04:08:49 -0700 (MST) Received: from vpn-129-150-120-84.uk.sun.com ([129.150.120.84]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1FHJ2m-0005la-LJ; Thu, 09 Mar 2006 11:10:56 +0000 Message-ID: <44100CBD.8060909@sun.com> Date: Thu, 09 Mar 2006 11:08:45 +0000 From: Alan Burlison User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Casper.Dik@sun.com CC: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> <440FF9DF.3080703@sun.com> <200603091051.k29AptDk000976@vaticaan.Holland.Sun.COM> In-Reply-To: <200603091051.k29AptDk000976@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 1626 Casper.Dik@Sun.COM wrote: >> Have we tested this out on other platforms to see if they *do* ignore >> the extra flags? > > No; I believe this is outside the scope of the project. I'd still like to know the answer though. If (for example) I make perl use this flag I'd like to have some idea of the potential carnage. It doesn't seem reasonable to push the onus of this investigation on to every potential consumer of the new interface. >> Yes, but why is the LD_PRELOAD needed, why can't libc just check the >> environment variables directly? I'm *really* not enamoured of this >> (ab)use of LD_PRELOAD. > > Because it costs. Startup speed of programs isn't stellar on > Solaris already. Because there still is some danger of breakage and > we prefer to make it slightly more obvious that you shouldn't > lightheartedly "just set the environment variable" as LD_PRELOAD > will wave red or yellow flags. Have the costs been quantified? And I don't see that setting ENABLE_EXTENDED_FILE_STDIO is any *less* a red flag than setting LD_PRELOAD, plus you don't have to deal with all the nastiness when multiple things try to use the LD_PRELOAD and don't properly check that nobody else has set it before them. LD_PRELOAD is a sysadmin's nightmare, I *really* don't think it should be used for what in time will come to be considered 'standard' Solaris behaviour. > OTOH, libthreads induction into libc already makes libc scan the entire > environment anyway, so .... > > Still, having it as an environment variable may send the wrong > message. And how is LD_PRELOAD any different? -- Alan Burlison -- From sacadmin Thu Mar 9 03:15:38 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29BFbIQ004805 for ; Thu, 9 Mar 2006 03:15:37 -0800 (PST) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k29BFWx20386; Thu, 9 Mar 2006 04:15:32 -0700 (MST) Received: from vpn-129-150-120-84.uk.sun.com ([129.150.120.84]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1FHJ9H-0005mJ-SP; Thu, 09 Mar 2006 11:17:40 +0000 Message-ID: <44100E50.2050101@sun.com> Date: Thu, 09 Mar 2006 11:15:28 +0000 From: Alan Burlison User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Casper.Dik@sun.com CC: Darren J Moffat , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> <440FFD08.6020003@Sun.COM> <200603091045.k29AjmDk023077@vaticaan.Holland.Sun.COM> In-Reply-To: <200603091045.k29AjmDk023077@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 905 Casper.Dik@Sun.COM wrote: > I personally believe that the "F" flag should not be documented and it > certainly is not to be used by applications. It is documented purely > for the use in libraries which don't want to fail due to a shortage of > low fds, *not* applications. (But then, private interfaces are much > less private than before now) That's a very fine hair to split, some things are both applications *and* an embeddable library. > Or perhaps we should just bite the bullet and enable it by default > and when users or applications raise the fd limit *and* break the rules > they will find some processes aborting. And have a single variable > STDIO_DISABLE_XFDS; but this means allocating an fd for each 32 bit > application (somewhat more expensive process startup) This might indeed be the best solution. Do we have a handle on the additional startup costs? -- Alan Burlison -- From sacadmin Thu Mar 9 03:35:30 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29BZTIQ004971 for ; Thu, 9 Mar 2006 03:35:29 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k29BZECM000820; Thu, 9 Mar 2006 12:35:26 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k29BZEDk025892; Thu, 9 Mar 2006 12:35:14 +0100 (MET) Message-Id: <200603091135.k29BZEDk025892@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Alan Burlison cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <44100CBD.8060909@sun.com> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> <440FF9DF.3080703@sun.com> <200603091051.k29AptDk000976@vaticaan.Holland.Sun.COM> <44100CBD.8060909@sun.com> Date: Thu, 09 Mar 2006 12:35:14 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 548 About the "F" flag: A cursory examination shows that: (Open)BSD works pretty much like Solaris (check first char, then check for +/b in second/3rd) Linux looks at all characters in the mode, allows for: 'x': O_EXCLUSIVE 'm': use mmap 'c': (no cancellation?) default: ignore So both main open source variants are "F"-safe. AIX/HP-UX: I can't tell from the manual page. >And how is LD_PRELOAD any different? One would assume people would regard LD_PRELOAD_32 with more suspicion than STDIO_ENABLE_LARGE_FDS. Casper From sacadmin Thu Mar 9 03:41:41 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29BfeIQ005036 for ; Thu, 9 Mar 2006 03:41:41 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k29BfbCM003100; Thu, 9 Mar 2006 12:41:37 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k29BfbDk003708; Thu, 9 Mar 2006 12:41:37 +0100 (MET) Message-Id: <200603091141.k29BfbDk003708@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Alan Burlison cc: Darren J Moffat , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <44100E50.2050101@sun.com> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> <440FFD08.6020003@Sun.COM> <200603091045.k29AjmDk023077@vaticaan.Holland.Sun.COM> <44100E50.2050101@sun.com> Date: Thu, 09 Mar 2006 12:41:37 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1031 >That's a very fine hair to split, some things are both applications >*and* an embeddable library. Fair enough. >> Or perhaps we should just bite the bullet and enable it by default >> and when users or applications raise the fd limit *and* break the rules >> they will find some processes aborting. And have a single variable >> STDIO_DISABLE_XFDS; but this means allocating an fd for each 32 bit >> application (somewhat more expensive process startup) > >This might indeed be the best solution. Do we have a handle on the >additional startup costs? No. It's one system call and a little bit glue around it. The loss of one seemingly random file descriptor might be a problem. (we specifically did not pick "255" or "3" but rather we try: - the first successful attempt at the lowest available starting at 196, 120, 60 and 3 (so 196 is the most likely outcome) We specifically wanted to avoid "known interesting values" like "255", "128", "127", "64", "63", "20", "19"; 3 and up are tried in desparation. Casper From sacadmin Thu Mar 9 06:50:27 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29EoQIQ007720 for ; Thu, 9 Mar 2006 06:50:26 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k29EoJ1P004303; Thu, 9 Mar 2006 14:50:19 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.5+Sun/8.13.5/Submit) id k29EoIuW004302; Thu, 9 Mar 2006 09:50:18 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] From: Bill Sommerfeld To: Alan Burlison Cc: Don Cragun , PSARC@sac.sfbay.sun.com, Casper.Dik@sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com In-Reply-To: <440FF364.1080909@sun.com> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> Content-Type: text/plain; charset=ASCII Content-Transfer-Encoding: 7bit Message-Id: <1141915818.4124.27.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.334 Date: Thu, 09 Mar 2006 09:50:18 -0500 Status: RO Content-Length: 504 On Thu, 2006-03-09 at 04:20, Alan Burlison wrote: > We > frequently tell customers that LD_PRELOAD is *only* to be used for > testing and debugging and in general LD_PRELOAD is an evil hack that > causes all sorts of deployment issues, I'm concerned that we are > proposing to use it here. I think this is one of the areas of the proposal which we can incrementally refine after integration -- we can always add more ways to enable the feature as we build more experience with it. - Bill From sacadmin Thu Mar 9 06:52:53 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29EqqIQ007757 for ; Thu, 9 Mar 2006 06:52:52 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k29EqjCM006160; Thu, 9 Mar 2006 15:52:45 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k29EqiDk009144; Thu, 9 Mar 2006 15:52:44 +0100 (MET) Message-Id: <200603091452.k29EqiDk009144@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Alan Burlison cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <44100CBD.8060909@sun.com> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> <440FF9DF.3080703@sun.com> <200603091051.k29AptDk000976@vaticaan.Holland.Sun.COM> <44100CBD.8060909@sun.com> Date: Thu, 09 Mar 2006 15:52:44 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 343 Roger Faulkner points out that we should not pollute the env var name space needlessly and suggests that we prefix all the environment variables with: _STDIO_ rather than STDIO_ We also wanted to drop the "STDIO_BADFD_SIGNAL_MESSAGE" variable (this seems like a superfluous knob) but we inadvertendly left that in the design. Casper From sacadmin Thu Mar 9 07:42:02 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29Fg2IQ008630 for ; Thu, 9 Mar 2006 07:42:02 -0800 (PST) Received: from barman.uk.sun.com (barman.UK.Sun.COM [129.156.132.12]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k29Ffpx03741; Thu, 9 Mar 2006 08:41:52 -0700 (MST) Received: from vpn-129-150-120-84.uk.sun.com ([129.150.120.84]) by barman.uk.sun.com with esmtp (Exim 4.42) id 1FHNJ1-0006Pt-25; Thu, 09 Mar 2006 15:43:59 +0000 Message-ID: <44104CBA.3040000@sun.com> Date: Thu, 09 Mar 2006 15:41:46 +0000 From: Alan Burlison User-Agent: Thunderbird 1.5 (X11/20060113) MIME-Version: 1.0 To: Bill Sommerfeld CC: Don Cragun , PSARC@sac.sfbay.sun.com, Casper.Dik@sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <1141915818.4124.27.camel@localhost> In-Reply-To: <1141915818.4124.27.camel@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Status: RO Content-Length: 694 Bill Sommerfeld wrote: >> frequently tell customers that LD_PRELOAD is *only* to be used for >> testing and debugging and in general LD_PRELOAD is an evil hack that >> causes all sorts of deployment issues, I'm concerned that we are >> proposing to use it here. > > I think this is one of the areas of the proposal which we can > incrementally refine after integration -- we can always add more ways to > enable the feature as we build more experience with it. Once it is integrated and people start using it it becomes very difficult to remove without breaking things. If we don't think customers should use it it seems a bit strange that we would integrate it. -- Alan Burlison -- From sacadmin Thu Mar 9 08:22:39 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29GMcIQ009671 for ; Thu, 9 Mar 2006 08:22:39 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k29GMYCM020879; Thu, 9 Mar 2006 17:22:35 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k29GMYDk006623; Thu, 9 Mar 2006 17:22:34 +0100 (MET) Message-Id: <200603091622.k29GMYDk006623@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Alan Burlison cc: Bill Sommerfeld , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <44104CBA.3040000@sun.com> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <1141915818.4124.27.camel@localhost> <44104CBA.3040000@sun.com> Date: Thu, 09 Mar 2006 17:22:34 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1000 >Bill Sommerfeld wrote: > >>> frequently tell customers that LD_PRELOAD is *only* to be used for >>> testing and debugging and in general LD_PRELOAD is an evil hack that >>> causes all sorts of deployment issues, I'm concerned that we are >>> proposing to use it here. >> >> I think this is one of the areas of the proposal which we can >> incrementally refine after integration -- we can always add more ways to >> enable the feature as we build more experience with it. > >Once it is integrated and people start using it it becomes very >difficult to remove without breaking things. If we don't think >customers should use it it seems a bit strange that we would integrate it. I don't think Bill is suggesting the removal; but more alternate form of enabling it in addition to pre-loading the object. I have no great objection to changing the enabler to a PRELOAD mechanism (as libc already scans all environment variables, adding another one seems like a next to no cost option) Casper From sacadmin Thu Mar 9 08:59:13 2006 Received: from phys-aus08-1 (phys-aus08-1.Central.Sun.COM [129.153.131.88]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29GxCIQ011366 for ; Thu, 9 Mar 2006 08:59:13 -0800 (PST) Received: from conversion-daemon.aus08-mail1.central.sun.com by aus08-mail1.central.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IVV00001DLFCX@aus08-mail1.central.sun.com> (original mail from David.Robinson@sun.com) for PSARC@sac.sfbay.sun.com; Thu, 09 Mar 2006 10:59:12 -0600 (CST) Received: from [129.153.128.60] (jetsun.Central.Sun.COM [129.153.128.60]) by aus08-mail1.central.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IVV00EK7DUOTB@aus08-mail1.central.sun.com>; Thu, 09 Mar 2006 10:59:12 -0600 (CST) Date: Thu, 09 Mar 2006 10:59:12 -0600 From: David Robinson Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-reply-to: <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> To: Casper.Dik@Sun.COM Cc: Alan Burlison , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Message-id: <44105EE0.5010308@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051023) References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> Status: RO Content-Length: 521 >>How will the signal handler distinguish that a fd > 256 is the cause of >>it's invocation? Earlier on you say that errno will be set to EBADF, >>but that seems a bit generic - errno can get set to EBADF in many ways. > > > It won't be able to distinguish between the two in the current > implementation (it's primary purpose is to abort programs). Will you be defining any new siginfo_t si_code's to note that this is an "interesting" signal? I assume it will be setting si_errno == EBADF which helps. -David From sacadmin Thu Mar 9 09:07:10 2006 Received: from eastmail1bur.East.Sun.COM (eastmail1bur.East.Sun.COM [129.148.9.49]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29H79IQ011426 for ; Thu, 9 Mar 2006 09:07:09 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k29H75bB008016; Thu, 9 Mar 2006 12:07:05 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k29H75wu024258; Thu, 9 Mar 2006 12:07:05 -0500 (EST) Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] From: Bill Sommerfeld To: Casper.Dik@sun.com Cc: Alan Burlison , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com In-Reply-To: <200603091622.k29GMYDk006623@vaticaan.Holland.Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <1141915818.4124.27.camel@localhost> <44104CBA.3040000@sun.com> <200603091622.k29GMYDk006623@vaticaan.Holland.Sun.COM> Content-Type: text/plain Message-Id: <1141924024.23131.3.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Thu, 09 Mar 2006 12:07:05 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 313 On Thu, 2006-03-09 at 11:22, Casper.Dik@Sun.COM wrote: > I don't think Bill is suggesting the removal; but more alternate > form of enabling it in addition to pre-loading the object. Correct -- but we could also define a lower stability level for mechanisms we think could be shuffled aside.. - Bill From sacadmin Thu Mar 9 09:38:03 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29Hc2IQ012012 for ; Thu, 9 Mar 2006 09:38:03 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k29HbwCM019571; Thu, 9 Mar 2006 18:37:58 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k29HbvDk009828; Thu, 9 Mar 2006 18:37:58 +0100 (MET) Message-Id: <200603091737.k29HbvDk009828@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: David Robinson cc: Alan Burlison , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <44105EE0.5010308@sun.com> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> <44105EE0.5010308@sun.com> Date: Thu, 09 Mar 2006 18:37:57 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1570 > > >>>How will the signal handler distinguish that a fd > 256 is the cause of >>>it's invocation? Earlier on you say that errno will be set to EBADF, >>>but that seems a bit generic - errno can get set to EBADF in many ways. >> >> >> It won't be able to distinguish between the two in the current >> implementation (it's primary purpose is to abort programs). > >Will you be defining any new siginfo_t si_code's to note that >this is an "interesting" signal? I assume it will be setting >si_errno == EBADF which helps. It might be possible to implement this; it would, in fact, be the *first* signal to deliver an "fd" (claims in the header file to the contrary notwithstanding). But we might hit a hurdle in siginfo_kto32() which keys on signal and not on type of event delivered and we're usually delivering this signal from a 64 bit kernel to a 32 bit process. I do find, however, that such a feature adds way too much in the form of knobs and whistles and makes the architecture too entrenched. What would an application do when it catches this signal? The intention is that we just "SIGABORT (core dumped)" and that we take it from there. It takes it from a 8-line kernel safety net to a much larger piece of code with, in my mind, fairly limited utility. (We add the only case of SIGABRT originating in a system call and the stack trace will tell you which fd it was; but it will always be libc::bad_fd so that again is of limited value; what you really want to know is which FILE * we are using and that is impossible to tell in the kernel) Casper From sacadmin Thu Mar 9 11:48:41 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29JmeIQ016007 for ; Thu, 9 Mar 2006 11:48:41 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k29JmbCM025154; Thu, 9 Mar 2006 20:48:38 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k29JmbDk020098; Thu, 9 Mar 2006 20:48:37 +0100 (MET) Message-Id: <200603091948.k29JmbDk020098@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Jonathan Adams , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060308235811.GZ101087@eng.sun.com> Date: Thu, 09 Mar 2006 20:48:37 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 376 >The "setf" portion of that call cannot fail so the only affected caller >was changed to not call closeandsetf(). But because of the obvious (now) race condition in this approach I've changed closeandsetf() to do the proper thing when setting to a non-NULL file *. (Only called from F_DUP2FD for now: the new failure requires the caller to call closef() on the fp) Casper From sacadmin Thu Mar 9 12:01:19 2006 Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29K1IIQ016747 for ; Thu, 9 Mar 2006 12:01:19 -0800 (PST) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5) with ESMTP id k29K1IXj002673; Thu, 9 Mar 2006 15:01:18 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.5+Sun/8.13.5/Submit) id k29K1Ibs002670; Thu, 9 Mar 2006 15:01:18 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17424.35214.459791.910047@gargle.gargle.HOWL> Date: Thu, 9 Mar 2006 15:01:18 -0500 From: James Carlson To: Casper.Dik@sun.com Cc: Jonathan Adams , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: Casper.Dik@sun.com's message of 9 March 2006 20:48:37 References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060308235811.GZ101087@eng.sun.com> <200603091948.k29JmbDk020098@vaticaan.Holland.Sun.COM> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 721 Casper.Dik@sun.com writes: > > >The "setf" portion of that call cannot fail so the only affected caller > >was changed to not call closeandsetf(). > > But because of the obvious (now) race condition in this approach I've > changed closeandsetf() to do the proper thing when setting to a non-NULL > file *. (Only called from F_DUP2FD for now: the new failure requires > the caller to call closef() on the fp) Nit, probably, but closefrom() and fdwalk() also ignore the magic descriptor, right? -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From sacadmin Thu Mar 9 12:07:18 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29K7HIQ017115 for ; Thu, 9 Mar 2006 12:07:18 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k29K7ECM029605; Thu, 9 Mar 2006 21:07:14 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k29K7EDk012551; Thu, 9 Mar 2006 21:07:14 +0100 (MET) Message-Id: <200603092007.k29K7EDk012551@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: James Carlson cc: Jonathan Adams , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <17424.35214.459791.910047@gargle.gargle.HOWL> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060308235811.GZ101087@eng.sun.com> <200603091948.k29JmbDk020098@vaticaan.Holland.Sun.COM> <17424.35214.459791.910047@gargle.gargle.HOWL> Date: Thu, 09 Mar 2006 21:07:13 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 808 >Casper.Dik@sun.com writes: >> >> >The "setf" portion of that call cannot fail so the only affected caller >> >was changed to not call closeandsetf(). >> >> But because of the obvious (now) race condition in this approach I've >> changed closeandsetf() to do the proper thing when setting to a non-NULL >> file *. (Only called from F_DUP2FD for now: the new failure requires >> the caller to call closef() on the fp) > >Nit, probably, but closefrom() and fdwalk() also ignore the magic >descriptor, right? Because the "fd" appears closed to all onlookers, fdwalk() and closefrom() don't see it (it's not in /proc/self/fd). But even if they call close() on it, as with the old idiom: for (i = getdtablesize(); --i > 2; ) (void) close(i); then close() will just return EBADF and not fail. Casper From sacadmin Thu Mar 9 12:20:30 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29KKUIQ017399 for ; Thu, 9 Mar 2006 12:20:30 -0800 (PST) Received: from jurassic.eng.sun.com (localhost [127.0.0.1]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k29KKTih657731 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 9 Mar 2006 12:20:29 -0800 (PST) Received: (from tpm@localhost) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5/Submit) id k29KKSVt657730; Thu, 9 Mar 2006 12:20:28 -0800 (PST) Date: Thu, 9 Mar 2006 12:20:28 -0800 From: Tim Marsland To: Don Cragun Cc: PSARC@sac.sfbay.sun.com, casper.dik@sun.com, craig.mohrman@sun.com, michael.shapiro@sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] Message-ID: <20060309202028.GD610875@eng.sun.com> Reply-To: Tim Marsland References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> User-Agent: Mutt/1.4.2.1i Organization: Operating Platforms Group; Sun Microsystems, Inc. Status: RO Content-Length: 1073 Apologies if I missed this, but presumably there's a hash table or something that maps from the FILE * (for the >255 case) to "an fd in an auxiliary location"? One of the things that really vexed us when trying to completely abstract FILE in the 64-bit environment back in 1997 is that the standards require that FILE is a complete type i.e. that this behaviour should work: void function(FILE *fp) { FILE copyfp; ... copyfp = *fp; ... fwrite(©fp, ....); } Now I'm happy to believe that the risk of the incidence of this problem in modern code is worth the benefit of fixing the problem, but given that the complete type requirement implies what may now be a shallow copy, I wanted to check with the project team that the proposed solution is vulnerable to this problem for fd values > 255. Secondly, I don't quite understand the value of allowing the fcntl to specify an arbitrary signal. Isn't SIGABRT enough i.e. -1 means SIGABRT, 0 means don't send anything? Or is there other ways to use this that I'm missing? What's the thinking here? tim From sacadmin Thu Mar 9 12:57:06 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29Kv5IQ018719 for ; Thu, 9 Mar 2006 12:57:06 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k29Kv1CM010152; Thu, 9 Mar 2006 21:57:01 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k29Kv1Dk013591; Thu, 9 Mar 2006 21:57:01 +0100 (MET) Message-Id: <200603092057.k29Kv1Dk013591@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Tim Marsland cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <20060309202028.GD610875@eng.sun.com> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060309202028.GD610875@eng.sun.com> Date: Thu, 09 Mar 2006 21:57:01 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 2258 >Apologies if I missed this, but presumably there's a hash table or >something that maps from the FILE * (for the >255 case) to "an fd in >an auxiliary location"? Correct. >One of the things that really vexed us when trying to completely abstract >FILE in the 64-bit environment back in 1997 is that the standards require >that FILE is a complete type i.e. that this behaviour should work: > > void > function(FILE *fp) > { > FILE copyfp; > ... > copyfp = *fp; > ... > fwrite(©fp, ....); > } This doesn't work in the current implementation anyway. In the current implementation, there are three things missing from the FILE *: - lock - mbstate - bufend Well, nearly all types of IO will involve "_bufend"; if you perform the above operation, much of the code will explode already. (corrupt memory et.al.) The _bufend() return value is never checked. That's my reason to believe that moving this to the auxiliary structure is just fine and dandy. The discussion in: 4093157 big stdio breaks standards conformance seems to be that all that needed to be supported was: The header file contains a type definition statement for type FILE. Test Strategy: INCLUDE header file UNDEFINE FILE using #undef. DECLARE a variable of that type VERIFY there were no compiler errors. >Now I'm happy to believe that the risk of the incidence of this >problem in modern code is worth the benefit of fixing the problem, >but given that the complete type requirement implies what may now >be a shallow copy, I wanted to check with the project team that the >proposed solution is vulnerable to this problem for fd values > 255. When this happens if the code doesn't crash beforehand on references relative to _bufend() the code will trap on the reference to the fd. >Secondly, I don't quite understand the value of allowing the fcntl to >specify an arbitrary signal. Isn't SIGABRT enough i.e. -1 means SIGABRT, >0 means don't send anything? Or is there other ways to use this that I'm missing? What's the thinking here? Yeah; that is perhaps another one of those "one knob too many". So can we settle for: - SIGABRT or - choice of SIGABRT and EBADF returns. Casper From sacadmin Thu Mar 9 14:46:22 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29MkLIQ023938 for ; Thu, 9 Mar 2006 14:46:22 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k29MkICM004596; Thu, 9 Mar 2006 23:46:19 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k29MkIDk027086; Thu, 9 Mar 2006 23:46:18 +0100 (MET) Message-Id: <200603092246.k29MkIDk027086@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Tim Marsland cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <20060309202028.GD610875@eng.sun.com> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060309202028.GD610875@eng.sun.com> Date: Thu, 09 Mar 2006 23:46:18 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 636 > copyfp = *fp; > ... > fwrite(©fp, ....); Here's the list of "vile" things done in the standards test: FILE var; FILE deref; deref = fopen(file, type)[0]; FILE deref; deref = freopen(filename, type, stream)[0]; FILE deref; deref = tmpfile()[0]; FILE deref; deref = fdopen(fildes, type)[0]; FILE deref; deref = fopen(file, type)[0]; FILE deref; deref = freopen(filename, type, stream)[0]; FILE deref; deref = tmpfile()[0]; FILE deref; deref = fdopen(fildes, type)[0]; Casper From sacadmin Thu Mar 9 15:47:26 2006 Received: from eastmail2bur.East.Sun.COM (eastmail2bur.East.Sun.COM [129.148.13.40]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k29NlPIQ026617 for ; Thu, 9 Mar 2006 15:47:26 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k29NlDWa018666; Thu, 9 Mar 2006 18:47:13 -0500 (EST) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k29NlDc8025746; Thu, 9 Mar 2006 18:47:13 -0500 (EST) Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] From: Bill Sommerfeld To: Casper.Dik@sun.com Cc: Darren J Moffat , Alan Burlison , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com In-Reply-To: <200603091045.k29AjmDk023077@vaticaan.Holland.Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> <440FFD08.6020003@Sun.COM> <200603091045.k29AjmDk023077@vaticaan.Holland.Sun.COM> Content-Type: text/plain Message-Id: <1141948032.23131.380.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.333 Date: Thu, 09 Mar 2006 18:47:13 -0500 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 697 On Thu, 2006-03-09 at 05:45, Casper.Dik@sun.com wrote: > Or perhaps we should just bite the bullet and enable it by default > and when users or applications raise the fd limit *and* break the rules > they will find some processes aborting. Given that there's already breakage due to apps bumping into the 256-fd limit, being bold here may minimize the net pain suffered. The header files have been correct since solaris 7. The number of applications which need >256 fd's and which use stdio is likely to increase over time (especially since everyone else has fixed this problem). The number of unique .o's compiled with the pre-s7 definition of fileno() can only shrink. - Bill From sacadmin Thu Mar 9 16:05:08 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2A058IQ027537 for ; Thu, 9 Mar 2006 16:05:08 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2A057UC019591; Thu, 9 Mar 2006 18:05:07 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2A057DO019590; Thu, 9 Mar 2006 18:05:07 -0600 (CST) Date: Thu, 9 Mar 2006 18:05:07 -0600 From: Nicolas Williams To: Bill Sommerfeld Cc: Casper.Dik@sun.com, Darren J Moffat , Alan Burlison , Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] Message-ID: <20060310000507.GX9040@binky.Central.Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <440FF364.1080909@sun.com> <200603090933.k299XCDk015366@vaticaan.Holland.Sun.COM> <440FFD08.6020003@Sun.COM> <200603091045.k29AjmDk023077@vaticaan.Holland.Sun.COM> <1141948032.23131.380.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1141948032.23131.380.camel@thunk> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1632 On Thu, Mar 09, 2006 at 06:47:13PM -0500, Bill Sommerfeld wrote: > On Thu, 2006-03-09 at 05:45, Casper.Dik@sun.com wrote: > > Or perhaps we should just bite the bullet and enable it by default > > and when users or applications raise the fd limit *and* break the rules > > they will find some processes aborting. > > Given that there's already breakage due to apps bumping into the 256-fd > limit, being bold here may minimize the net pain suffered. Well, many apps have gotten around this by doing such things as LRU/LFU closing of connections or what have you and sticking to 256 fildes, or else dup2()ing fildes above 255. At a previous job I wrote an LD_PRELOAD object that wrapped around syscalls that return fildes and around fopen()/fdopen()/... to ensure that fildes not obviously intended for STDIO, not 0, 1 or 2, be dup2()ed above 255, and then in the STDIO wrappers dup()ed back below 256. This still leaves the STDIO limit at 256 fildes, but at least it makes it safe(r) to set the soft fildes limit higher than 256. It clearly violates POSIX in that if the app knows that there is no fildes #6 then it may expect syscalls that return new FDs to return #6, but will instead get something much larger; however, I can't think of why apps would rely on this other than for fildes 0, 1 and 2 (i.e., "close(0); fd = open(...);" fd had better == 0). The Solaris apps I've seen that need to have lots of fildes open typically don't use STDIO for the majority of those fildes, but for housekeeping tasks (e.g., reading config files). Specific examples that come to mind: Samba, the old Xedoc NetInfo server. Nico -- From sacadmin Fri Mar 10 08:18:20 2006 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AGIKIQ019998 for ; Fri, 10 Mar 2006 08:18:20 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id k2AGIFJN018178; Fri, 10 Mar 2006 08:18:15 -0800 (PST) Message-Id: <200603101618.k2AGIFJN018178@spartan.SFBay.Sun.COM> Date: Fri, 10 Mar 2006 08:18:15 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: sommerfeld@Sun.COM Cc: Casper.Dik@Sun.COM, PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: vzmdZvLVbR0aQ202ndSYYg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 2625 >Date: Thu, 09 Mar 2006 18:47:13 -0500 >From: Bill Sommerfeld > >On Thu, 2006-03-09 at 05:45, Casper.Dik@sun.com wrote: >> Or perhaps we should just bite the bullet and enable it by default >> and when users or applications raise the fd limit *and* break the rules >> they will find some processes aborting. I don't understand why we're even considering making this the default action. The materials clearly state that data corruption may occur if applications that use the fileno() macro or refer to _file in struct FILE directly. I don't believe we should make the assumption that just because we will drop core when we detect bad usage that that means this is a good idea as a default. This feature should only be used when the author of the code making use of it has decided that it is safe to do so. The author will know it is safe to do so if the entire application can be rebuilt on ONNV after these changes are putback, but there is no guarantee that a Seibel application linked with a 3rd party library built in 1995 and delivered in binary only can run safely in this environment. New applications (or applications that are now aware of this new feature) can call enable_extended_FILE_stdio() and never need to use a preload nor environment variables. This is the route that we should be suggesting for application writers. The preloadable library and its associated environment variables should be viewed as a temporary work around to be used after applications have been checked for bad behavior and found to be clean, and then used only until the application is fixed to use enable_extended_FILE_stdio(). > >Given that there's already breakage due to apps bumping into the 256-fd >limit, being bold here may minimize the net pain suffered. If some high end third party application crashes in the middle of a transaction because we detected a change in _file, the pain suffered may be huge. This needs to remain an opt in feature. > >The header files have been correct since solaris 7. Yes. > >The number of applications which need >256 fd's and which use stdio is >likely to increase over time (especially since everyone else has fixed >this problem). Yes. > >The number of unique .o's compiled with the pre-s7 definition of >fileno() can only shrink. Actually, it can shrink or remain constant; but it doesn't matter. Until we EOL support for applications built with the 32-bit ABIs that were in place in Solaris 2.0, we can't make this the default behavior. (Meanwhile, Don is crawling back into his hole to finish a ballot on another draft standard...) > > - Bill From sacadmin Fri Mar 10 08:26:35 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AGQYIQ020280 for ; Fri, 10 Mar 2006 08:26:35 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2AGQVCM002241; Fri, 10 Mar 2006 17:26:31 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2AGQVDk023165; Fri, 10 Mar 2006 17:26:31 +0100 (MET) Message-Id: <200603101626.k2AGQVDk023165@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Don Cragun cc: sommerfeld@Sun.COM, PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <200603101618.k2AGIFJN018178@spartan.SFBay.Sun.COM> References: <200603101618.k2AGIFJN018178@spartan.SFBay.Sun.COM> Date: Fri, 10 Mar 2006 17:26:31 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1389 >I don't understand why we're even considering making this the default >action. The materials clearly state that data corruption may occur if >applications that use the fileno() macro or refer to _file in struct >FILE directly. I don't believe we should make the assumption that just >because we will drop core when we detect bad usage that that means this >is a good idea as a default. The code tries very hard to prevent file corruption by using the badfd so I don't think we actually believe file corruption can still occur: if (fp->_file) is changed then the next stdio operation which uses the FD will abort() if (fp->_file) is read then the first use of that fd will cause the kernel to send SIGABRT to the offending thread. I think we're trying to weigh "convenience for many" vs "risk for some". But I don't think that this case needs to make the behaviour the default; if we have gained experience then we may change our mind and do a follow up case. >Actually, it can shrink or remain constant; but it doesn't matter. >Until we EOL support for applications built with the 32-bit ABIs that >were in place in Solaris 2.0, we can't make this the default behavior. fp->_file can still be used, though :-( (Until we do a putback) >(Meanwhile, Don is crawling back into his hole to finish a ballot on >another draft standard...) Please approve my RTI first :-) Casper From sacadmin Fri Mar 10 08:48:36 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AGmaIQ020477 for ; Fri, 10 Mar 2006 08:48:36 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2AGmREj004672; Fri, 10 Mar 2006 16:48:27 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.5+Sun/8.13.5/Submit) id k2AGmRKE004671; Fri, 10 Mar 2006 11:48:27 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] From: Bill Sommerfeld To: Casper.Dik@sun.com Cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com In-Reply-To: <200603101626.k2AGQVDk023165@vaticaan.Holland.Sun.COM> References: <200603101618.k2AGIFJN018178@spartan.SFBay.Sun.COM> <200603101626.k2AGQVDk023165@vaticaan.Holland.Sun.COM> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1142009306.4541.10.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.334 Date: Fri, 10 Mar 2006 11:48:27 -0500 Status: RO Content-Length: 1293 On Fri, 2006-03-10 at 11:26, Casper.Dik@Sun.COM wrote: > The code tries very hard to prevent file corruption by using the > badfd so I don't think we actually believe file corruption can still > occur: > > if (fp->_file) is changed then the next stdio operation which > uses the FD will abort() > > if (fp->_file) is read then the first use of that fd will cause > the kernel to send SIGABRT to the offending thread. moreover, the failures can only occur with a non-default setting of the per-process file descriptor limit. I don't think anyone is suggesting changing this limit. > I think we're trying to weigh "convenience for many" vs "risk for some". And to remove what many developers I've talked to see as a barrier to porting applications to Solaris. > >Actually, it can shrink or remain constant; but it doesn't matter. > >Until we EOL support for applications built with the 32-bit ABIs that > >were in place in Solaris 2.0, we can't make this the default behavior. > > fp->_file can still be used, though :-( (Until we do a putback) As part of this case, perhaps we should Obsolete (but not EOF) just the part of the ABI involving fp->_file, as a strong suggestion (but not a requirement) that code built against pre-s7 headers be put out of its misery. - Bill From sacadmin Fri Mar 10 09:22:36 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AHMaIQ022055 for ; Fri, 10 Mar 2006 09:22:36 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2AHMala020392; Fri, 10 Mar 2006 11:22:36 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2AHMZVl020391; Fri, 10 Mar 2006 11:22:35 -0600 (CST) Date: Fri, 10 Mar 2006 11:22:35 -0600 From: Nicolas Williams To: Don Cragun Cc: PSARC@sac.sfbay.sun.com, Casper.Dik@Sun.COM, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] Message-ID: <20060310172235.GH9040@binky.Central.Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 5558 On Wed, Mar 08, 2006 at 03:25:07PM -0800, Don Cragun wrote: > Summary > ======= > 32-bit Solaris processes will no longer be limited to 256 FILE's > with LITTLE chance of silent data corruption. > Silent data corruption can only occur if: > 1. the process uses FILE->_file directly, > 2. the process uses the fileno() macro (the > fileno() macro was removed from our headers in > Solaris release 2.7) rather than the fileno() > function, or > 3. the process truncates the value returned by the > fileno() function. > > This is a runtime change with no limit on the age of the software. > Even pre-2.7 software will work. Is the requirement that 32-bit processes be able to have a soft fildes limit higher than 256 safely, or that they be able to use STDIO with more than 256 file descriptors open? Some of the CRs listed in the materials can be addressed by meeting the former requirement and not the latter, and without resorting to bad file descriptors. Bugs in third party apps where fdopen() errors are not checked, however, would only be improved by meeting the latter requirement. OTOH, standards compliance seems easier to meet if trying to meet the former requirement than the latter. [...] > To aid in "cleaning up" source code which contains FILE->_file > access we propose to rename FILE->_file to FILE->__file > (additional "_"). This will forcibly break the compilation of > any source containing references to FILE->_file. Obviously > this will grab the attention of developers who will then > hopefully recode FILE->_file to the more appropriate > fileno(FILE). Sun code needs this as much as 3rd party code. > This will very quickly clean up Solaris to be fiLE->_file clean > and guarantee that using extended FILE will work throughout > Solaris. Without this it will be very difficult to verify > Solaris, and other software products, readiness. Who will do this cleanup? In what consolidations? > If it is known that the application accesses the FILE->_file > field directly then this feature should not be used, even > though we go to great lengths to handle all possible cases > there can always be another case we did not think of. For well > behaved applications (no direct FILE->_file accesses) then this > works wonderfully. Is it possible to detect whether an object was built on a system where fileno() was a macro? [...] > This new fcntl(F_BADFD) command should not be used directly > by applications. Applications should use > enable_extended_FILE_stdio() (see #6 below) instead. > Calling fcntl(F_BADFD) directly serves no purpose and would > cause a subsequent call to enable_extended_FILE_stdio() to > fail. Does this include shared objects? That is, can shared objects call enable_extended_FILE_stdio()? Or only main programs and the LD_PRELOADable object? If multiple objects in one process want different actions, then what? How does a user decide on an action? Can we have a "default" action for those who don't care so we can change it later? [...] > The possible scenarios are thus: > > A) User does nothing and runs applications: > Everything works or fails as before. > > B) User raises RLIMIT_NOFILE: > Normal stdio calls still limited to 256 FILE's but > any usage of the "F" flag will allow RLIMIT_NOFILE > FILE's. A common problem with raising the soft fildes limit past 256 for 32-bit apps is that STDIO may be used sparingly for housekeeping but lots of file descriptors may be used by the app w/o STDIO, which then starves STDIO of file descriptors even though STDIO needs very few file descriptors, and then the app exits or crashes when it tries to do its housekeeping. It might be useful, when not using the fopen() F flag or the extendedFILE.so.1 LD_PRELOAD object, but running with the soft fildes limit >>256 to ensure that file descriptors are dup2()ed above 256 outside STDIO and dup()ed below 256 by fdopen(). This way STDIO would by default be limited to 256 fildes but for all other uses the application would not be so limited. > C) User raises RLIMIT_NOFILE and pre-loads extended > FILE library: > Application gets RLIMIT_NOFILE FILE's. > Direct access to FILE->_file are preserved for the > fd's <= 255. > fd's > 255 will receive errors or signal. User's > choice. > Solaris internal libraries ("F" usage) gets the > same as B above. > > $ ulimit -n 1000 > $ LD_PRELOAD_32=/usr/lib/extendedFILE.so.1 \ > application [args...] [...] > 6. A second programming interface; > enable_extended_FILE_stdio(int fd, int action) is added to > allow 3rd parties and end users access to the interface > used in the preloadable library. (#5 above) The fd > argument is the starting point to begin searching for an > available fd to be marked as the unallocatable file > descriptor. Its value must be between 3-255 inclusive. If > an available fd cannot be found an error is returned. A > value of -1 for fd will use a built in scheme for searching > for an available fd. The action argument is the requested > signal to be sent to the application in the event of an > error in the usage of this mechanism or improper access to > FILE->_file is detected. A value of -1 yields the default > SIGABRT signal. A value of 0 disables the sending of a > signal. Is the fd argument necessary? Nico -- From sacadmin Fri Mar 10 09:59:26 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AHxPIQ023100 for ; Fri, 10 Mar 2006 09:59:25 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2AHxKCM002487; Fri, 10 Mar 2006 18:59:21 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2AHxJDk019791; Fri, 10 Mar 2006 18:59:19 +0100 (MET) Message-Id: <200603101759.k2AHxJDk019791@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Nicolas Williams cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <20060310172235.GH9040@binky.Central.Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060310172235.GH9040@binky.Central.Sun.COM> Date: Fri, 10 Mar 2006 18:59:19 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 3191 >Is the requirement that 32-bit processes be able to have a soft fildes >limit higher than 256 safely, or that they be able to use STDIO with >more than 256 file descriptors open? Both. >Some of the CRs listed in the materials can be addressed by meeting the >former requirement and not the latter, and without resorting to bad file >descriptors. Bugs in third party apps where fdopen() errors are not >checked, however, would only be improved by meeting the latter >requirement. None of the listed bugs can be fixed without resorting to a horrid mess of shadow stdio implementations. >OTOH, standards compliance seems easier to meet if trying to meet the >former requirement than the latter. The fix will be standard compliant. >Who will do this cleanup? In what consolidations? Consolidations will find that their uses of _file will fail to compile and that would then be their fault. (We had one or two such occurences only in onnv) >Is it possible to detect whether an object was built on a system where >fileno() was a macro? No. The history of the prior four PSARC cases will show you that all possible things were researched. It would also not contribute useful information (see mtst.c in ON) >Does this include shared objects? That is, can shared objects call >enable_extended_FILE_stdio()? Or only main programs and the >LD_PRELOADable object? Yes, that's how extendedFILE.so works; there is no way for us to limit calls to the "main" program. >If multiple objects in one process want different actions, then what? First one wins. >How does a user decide on an action? Can we have a "default" action for >those who don't care so we can change it later? The default is SIGABRT. As per other mail, it's somewhat up in the air whether we really want the action to be settable. To define the fd seems a useful knob. >A common problem with raising the soft fildes limit past 256 for 32-bit >apps is that STDIO may be used sparingly for housekeeping but lots of >file descriptors may be used by the app w/o STDIO, which then starves >STDIO of file descriptors even though STDIO needs very few file >descriptors, and then the app exits or crashes when it tries to do its >housekeeping. > >It might be useful, when not using the fopen() F flag or the >extendedFILE.so.1 LD_PRELOAD object, but running with the soft fildes >limit >>256 to ensure that file descriptors are dup2()ed above 256 >outside STDIO and dup()ed below 256 by fdopen(). This is expensive and doesn't solve the issue because there are many cases where we want more than 256 FILE *s. >This way STDIO would by default be limited to 256 fildes but for all >other uses the application would not be so limited. But is not standards compliant and breaks known idiom such as: close(0); close(1); close(2); dup(fd); dup(fd); dup(fd); close(fd); Which copies fd to fd's 0, 1 and 2. >Is the fd argument necessary? I think it's the most important one: applications are known to reserve fixed file descriptors for specific purposes (the shell uses 15-19); we hope to have picked a reasonable default but allowing users to set it allows them to steer clear of the fds important for apps. Casper From sacadmin Fri Mar 10 10:06:53 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AI6qIQ023236 for ; Fri, 10 Mar 2006 10:06:52 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2AI6q3X020773; Fri, 10 Mar 2006 12:06:52 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2AI6qYB020772; Fri, 10 Mar 2006 12:06:52 -0600 (CST) Date: Fri, 10 Mar 2006 12:06:52 -0600 From: Nicolas Williams To: Casper.Dik@Sun.COM Cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] Message-ID: <20060310180651.GJ9040@binky.Central.Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060310172235.GH9040@binky.Central.Sun.COM> <200603101759.k2AHxJDk019791@vaticaan.Holland.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603101759.k2AHxJDk019791@vaticaan.Holland.Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1995 On Fri, Mar 10, 2006 at 06:59:19PM +0100, Casper.Dik@Sun.COM wrote: > >A common problem with raising the soft fildes limit past 256 for 32-bit > >apps is that STDIO may be used sparingly for housekeeping but lots of > >file descriptors may be used by the app w/o STDIO, which then starves > >STDIO of file descriptors even though STDIO needs very few file > >descriptors, and then the app exits or crashes when it tries to do its > >housekeeping. > > > >It might be useful, when not using the fopen() F flag or the > >extendedFILE.so.1 LD_PRELOAD object, but running with the soft fildes > >limit >>256 to ensure that file descriptors are dup2()ed above 256 > >outside STDIO and dup()ed below 256 by fdopen(). > > This is expensive and doesn't solve the issue because there are > many cases where we want more than 256 FILE *s. Right, but for those explicit action must be taken (use the F flag, call enable_extended_FILE_stdio() and/or LD_PRELOAD extendedFILE.so.1. That is, we may be able to provide a very useful default where STDIO remains litmited to 256 by default (as in this proposal) but where the soft fildes limit can be raised past 256 without starving STDIO of file descriptors. > >This way STDIO would by default be limited to 256 fildes but for all > >other uses the application would not be so limited. > > But is not standards compliant and breaks known idiom such as: > > close(0); close(1); close(2); > dup(fd); dup(fd); dup(fd); > close(fd); > > Which copies fd to fd's 0, 1 and 2. See my post yesterday. I wrote an LD_PRELOAD object that this this sort of thing and, of course, it exempted file descriptors 0, 1 and 2. > >Is the fd argument necessary? > > I think it's the most important one: applications are known to > reserve fixed file descriptors for specific purposes (the shell uses > 15-19); we hope to have picked a reasonable default but allowing users > to set it allows them to steer clear of the fds important for apps. I see. Thanks. Nico -- From sacadmin Fri Mar 10 10:11:54 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AIBsIQ023387 for ; Fri, 10 Mar 2006 10:11:54 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2AIBrfB020780; Fri, 10 Mar 2006 12:11:53 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2AIBrwM020779; Fri, 10 Mar 2006 12:11:53 -0600 (CST) Date: Fri, 10 Mar 2006 12:11:53 -0600 From: Nicolas Williams To: Casper.Dik@Sun.COM Cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] Message-ID: <20060310181153.GK9040@binky.Central.Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060310172235.GH9040@binky.Central.Sun.COM> <200603101759.k2AHxJDk019791@vaticaan.Holland.Sun.COM> <20060310180651.GJ9040@binky.Central.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060310180651.GJ9040@binky.Central.Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 1538 On Fri, Mar 10, 2006 at 12:06:52PM -0600, Nicolas Williams wrote: > On Fri, Mar 10, 2006 at 06:59:19PM +0100, Casper.Dik@Sun.COM wrote: > > >A common problem with raising the soft fildes limit past 256 for 32-bit > > >apps is that STDIO may be used sparingly for housekeeping but lots of > > >file descriptors may be used by the app w/o STDIO, which then starves > > >STDIO of file descriptors even though STDIO needs very few file > > >descriptors, and then the app exits or crashes when it tries to do its > > >housekeeping. > > > > > >It might be useful, when not using the fopen() F flag or the > > >extendedFILE.so.1 LD_PRELOAD object, but running with the soft fildes > > >limit >>256 to ensure that file descriptors are dup2()ed above 256 > > >outside STDIO and dup()ed below 256 by fdopen(). > > > > This is expensive and doesn't solve the issue because there are > > many cases where we want more than 256 FILE *s. > > Right, but for those explicit action must be taken (use the F flag, call > enable_extended_FILE_stdio() and/or LD_PRELOAD extendedFILE.so.1. > > That is, we may be able to provide a very useful default where STDIO > remains litmited to 256 by default (as in this proposal) but where the > soft fildes limit can be raised past 256 without starving STDIO of file > descriptors. Also, it's not expensive: the dup2()ing above 256 can just happen by default in the kernel for fildes that would be neither 0, 1, or 2 (or ; Fri, 10 Mar 2006 10:12:44 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2AICeCM005520; Fri, 10 Mar 2006 19:12:40 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2AICeDk006288; Fri, 10 Mar 2006 19:12:40 +0100 (MET) Message-Id: <200603101812.k2AICeDk006288@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Nicolas Williams cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <20060310180651.GJ9040@binky.Central.Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060310172235.GH9040@binky.Central.Sun.COM> <200603101759.k2AHxJDk019791@vaticaan.Holland.Sun.COM> <20060310180651.GJ9040@binky.Central.Sun.COM> Date: Fri, 10 Mar 2006 19:12:40 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 864 >That is, we may be able to provide a very useful default where STDIO >remains litmited to 256 by default (as in this proposal) but where the >soft fildes limit can be raised past 256 without starving STDIO of file >descriptors. No, we would not because not returning the lowest available fd from a system call is a standards violation. Secondly, we have no clue whether a file descriptor we are about to return for: dup, socket, accept, open, pipe, receiving fds over the wire are going to be passed to fdopen() or not. So I'm not sure which fds can be safely moved to > 256. >> Which copies fd to fd's 0, 1 and 2. > >See my post yesterday. I wrote an LD_PRELOAD object that this this sort >of thing and, of course, it exempted file descriptors 0, 1 and 2. You mean if I ran "dup()" and any of the fds 0, 1, 2 was open it would return 0, 1 or 2? Casper From sacadmin Fri Mar 10 10:21:52 2006 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AILpIQ023497 for ; Fri, 10 Mar 2006 10:21:51 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IVX00B01B36Z2@mpk-mail1.sfbay.sun.com> (original mail from ed.gould@sun.com) for PSARC@sac.sfbay.sun.com; Fri, 10 Mar 2006 10:21:51 -0800 (PST) Received: from [192.168.0.10] (vpn-129-150-28-69.SFBay.Sun.COM [129.150.28.69]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IVX00CG8CB1WY@mpk-mail1.sfbay.sun.com>; Fri, 10 Mar 2006 10:21:01 -0800 (PST) Date: Fri, 10 Mar 2006 10:21:01 -0800 From: Ed Gould Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-reply-to: <20060310181153.GK9040@binky.Central.Sun.COM> To: Craig.Mohrman@Sun.COM Cc: Nicolas Williams , Don Cragun , Michael.Shapiro@Sun.COM, Casper Dik , PSARC@sac.sfbay.sun.com Message-id: MIME-version: 1.0 (Apple Message framework v623) X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060310172235.GH9040@binky.Central.Sun.COM> <200603101759.k2AHxJDk019791@vaticaan.Holland.Sun.COM> <20060310180651.GJ9040@binky.Central.Sun.COM> <20060310181153.GK9040@binky.Central.Sun.COM> Status: RO Content-Length: 431 This case is bordering on being non-obvious. I've seen some comments about potential data corruption, and some responses to those comments. But I don't have a clear sense of the state of the proposal. If someone can summarize the various concerns (performance, data integrity, possibly others) and how this proposal deals with them, and the conclusions are satisfactory, then fine. Otherwise, I'll have to derail. --Ed From sacadmin Fri Mar 10 10:26:20 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AIQKIQ023544 for ; Fri, 10 Mar 2006 10:26:20 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2AIQJ9A020806; Fri, 10 Mar 2006 12:26:19 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2AIQJST020805; Fri, 10 Mar 2006 12:26:19 -0600 (CST) Date: Fri, 10 Mar 2006 12:26:19 -0600 From: Nicolas Williams To: Casper.Dik@Sun.COM Cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] Message-ID: <20060310182619.GL9040@binky.Central.Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060310172235.GH9040@binky.Central.Sun.COM> <200603101759.k2AHxJDk019791@vaticaan.Holland.Sun.COM> <20060310180651.GJ9040@binky.Central.Sun.COM> <200603101812.k2AICeDk006288@vaticaan.Holland.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603101812.k2AICeDk006288@vaticaan.Holland.Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 2293 On Fri, Mar 10, 2006 at 07:12:40PM +0100, Casper.Dik@Sun.COM wrote: > > >That is, we may be able to provide a very useful default where STDIO > >remains litmited to 256 by default (as in this proposal) but where the > >soft fildes limit can be raised past 256 without starving STDIO of file > >descriptors. > > No, we would not because not returning the lowest available fd from > a system call is a standards violation. Ah, but there's a loop hole: except for fildes 0, 1, 2, and any fildes which they just closed (and even then), apps generally can't know what that fildes would be because: a) libraries may open files, so unless the app loops over all fildes to look for (with istty(), say) bad fildes numbers, it wouldn't know which fildes are available and b) because of multi-threading and because of (a) one cannot rely on this behaviour at all. This behaviour works for fildes 0, 1 and 2 mostly because they usually are closed in situations where there aren't other threads running that might get them. As for expecting this: close(fd); /* open will return the same fd */ if (open(...) ...) this would only fail to happen in my proposal (assuming one thread) when fd was obtained from fileno(). > Secondly, we have no clue whether a file descriptor we are about to > return for: > dup, socket, accept, open, pipe, receiving fds over the wire > > are going to be passed to fdopen() or not. But fdopen() knows what to do! just dup(). > So I'm not sure which fds can be safely moved to > 256. All. Let fopen(), fdopen(), tmpfile() do the right thing under the covers to get a fildes < 256. > >> Which copies fd to fd's 0, 1 and 2. > > > >See my post yesterday. I wrote an LD_PRELOAD object that this this sort > >of thing and, of course, it exempted file descriptors 0, 1 and 2. > > You mean if I ran "dup()" and any of the fds 0, 1, 2 was open it > would return 0, 1 or 2? No, I mean the syscall interposers worked like this: int open(...) { ... if (real_open == NULL) real_open = dlsym(RTLD_NEXT, "open"); fd = real_open(...); if (fd < 3) return (fd); if (soft fildes limit > 256) return (dup2(fd, 256)); return (fd); } The STDIO interposers called the real syscalls (and the fdopen() interposer called real_dup() to get fildes < 256). Nico -- From sacadmin Fri Mar 10 10:42:13 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.68.36]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AIgDIQ023753 for ; Fri, 10 Mar 2006 10:42:13 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k2AIg340408596; Fri, 10 Mar 2006 10:42:12 -0800 (PST) Message-Id: <200603101842.k2AIg340408596@jurassic.eng.sun.com> Date: Fri, 10 Mar 2006 08:41:00 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: Craig.Mohrman@sun.com, ed.gould@sun.com Cc: Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, Casper.Dik@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: k7JTm4bJxj3V5R76Bcmz8g== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 962 > From: Ed Gould ... > This case is bordering on being non-obvious. I've seen some comments > about potential data corruption, and some responses to those comments. > But I don't have a clear sense of the state of the proposal. > > If someone can summarize the various concerns (performance, data > integrity, possibly others) and how this proposal deals with them, and > the conclusions are satisfactory, then fine. Otherwise, I'll have to > derail. > > --Ed I was about to compose a similar message. I've been concerned about approving a change this significant without a formal opinion to point at. What's stopped me from suggesting it before was the question, "What would we put in the opinion?". The on/off by default discussion seems to have provided something. BTW: If this ends up default on, I think this *must* have an opinion. We conciously allow the potential for data corruption into the default system! - jek3 From sacadmin Fri Mar 10 10:42:28 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AIgRIQ023764 for ; Fri, 10 Mar 2006 10:42:27 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2AIgKCM012399; Fri, 10 Mar 2006 19:42:20 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2AIgKDk012524; Fri, 10 Mar 2006 19:42:20 +0100 (MET) Message-Id: <200603101842.k2AIgKDk012524@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Nicolas Williams cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <20060310182619.GL9040@binky.Central.Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060310172235.GH9040@binky.Central.Sun.COM> <200603101759.k2AHxJDk019791@vaticaan.Holland.Sun.COM> <20060310180651.GJ9040@binky.Central.Sun.COM> <200603101812.k2AICeDk006288@vaticaan.Holland.Sun.COM> <20060310182619.GL9040@binky.Central.Sun.COM> Date: Fri, 10 Mar 2006 19:42:20 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 517 >But fdopen() knows what to do! just dup(). No, because you can't be sure that the application won't remember the fd in someway and use it instead of fileno(). And will fdopen() then also close the fd? I think this discussion has no place in the PSARC case, though, as it is about allowing for the use of more than > 256 FILE*s as well as the others and renumbering fds in fdopen is likely to fail a standards test or two (run your interposer on the standards test suites and we'll talk again, off-line) Casper From sacadmin Fri Mar 10 10:54:37 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AIsaIQ024414 for ; Fri, 10 Mar 2006 10:54:37 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2AIsRgv004724; Fri, 10 Mar 2006 18:54:27 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.5+Sun/8.13.5/Submit) id k2AIsQ2o004723; Fri, 10 Mar 2006 13:54:26 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] From: Bill Sommerfeld To: Joseph Kowalski Cc: Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, Casper.Dik@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200603101842.k2AIg340408596@jurassic.eng.sun.com> References: <200603101842.k2AIg340408596@jurassic.eng.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1142016866.4541.61.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.334 Date: Fri, 10 Mar 2006 13:54:26 -0500 Status: RO Content-Length: 528 On Fri, 2006-03-10 at 13:41, Joseph Kowalski wrote: > BTW: If this ends up default on, I think this *must* have an opinion. > We conciously allow the potential for data corruption into the default > system! Because of the "toxic fd" mechanism, the potential for undetected data corruption here seems small compared with the "background risk" of undetected data corruption from latent application bugs due to reliance on the unspecified behaviors/implementation artifacts which change from release to release. - Bill From sacadmin Fri Mar 10 10:55:04 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.36]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AIt4IQ024428 for ; Fri, 10 Mar 2006 10:55:04 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k2AIsvxC414904; Fri, 10 Mar 2006 10:55:03 -0800 (PST) Message-Id: <200603101855.k2AIsvxC414904@jurassic.eng.sun.com> Date: Fri, 10 Mar 2006 08:53:51 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: Casper.Dik@sun.com, sommerfeld@sun.com Cc: Don.Cragun@sun.com, PSARC@sac.sfbay.sun.com, Craig.Mohrman@sun.com, Michael.Shapiro@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ui7YR6mnyLXF72EkoUwmdg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 993 > From: Bill Sommerfeld ... > > I think we're trying to weigh "convenience for many" vs "risk for some". > > And to remove what many developers I've talked to see as a barrier to > porting applications to Solaris. Yes, but by providing the ability to opt-in to this envivonment, you've lowered that barrier from being a 16' chain link fence topped with razor wire to a neat little 4" curb. The only people who will be perturbed by the "curb" aren't really programmers anyway - as Romeo's friend was characterized (after being run through with a sword); "He was just a man who liked to hear himself talk". Such are the people who would be unsatisfied by the opt-in solution (IMHO). 8^) BTW: a couple of months ago this issue was discussed on the gnome development alias. It was quite interesting how "Why doesn't Solaris fix this?!?", changed to "Oh, I see." after I explained the ABI, our commitment to compatibility and that nasty little fileno() macro. - jek3 From sacadmin Fri Mar 10 11:07:24 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.57]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AJ7OIQ024729 for ; Fri, 10 Mar 2006 11:07:24 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k2AJ7HQ6426898; Fri, 10 Mar 2006 11:07:23 -0800 (PST) Message-Id: <200603101907.k2AJ7HQ6426898@jurassic.eng.sun.com> Date: Fri, 10 Mar 2006 09:06:11 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: Joseph.Kowalski@eng.sun.com, sommerfeld@sun.com Cc: Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, Casper.Dik@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: tGT8zv/MMhIHYNy0IFxNvA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1419 > From: Bill Sommerfeld ... > On Fri, 2006-03-10 at 13:41, Joseph Kowalski wrote: > > BTW: If this ends up default on, I think this *must* have an opinion. > > We conciously allow the potential for data corruption into the default > > system! > > Because of the "toxic fd" mechanism, the potential for undetected data > corruption here seems small compared with the "background risk" of > undetected data corruption from latent application bugs due to reliance > on the unspecified behaviors/implementation artifacts which change from > release to release. Wow. Input parser overflow. Is the contention that since the risk of data corruption of something we intentionally put into the system is similar to the risk of things we unintentionally put into the system that this is OK? Can I point out that if we unintentionally put something into the system which causes data corruption, we react as quickly as we can to take it out. Or, should I interpret this as "since poorly written programs can experience data corruption (and be release dependent due to unsupport/undocumented behaviors), that its also acceptable for programs which conform to the system specification? I'll take my statement a bit further. If both of the following are true: 1) Data corruption is *possible* due to the design. 2) On by default. I will not only derail, but I will likely vote to reject. - jek3 From sacadmin Fri Mar 10 11:10:22 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AJALIQ024770 for ; Fri, 10 Mar 2006 11:10:21 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2AJAFCM020565; Fri, 10 Mar 2006 20:10:15 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2AJAFDk018941; Fri, 10 Mar 2006 20:10:15 +0100 (MET) Message-Id: <200603101910.k2AJAFDk018941@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Joseph Kowalski cc: Craig.Mohrman@Sun.COM, Ed.Gould@Sun.COM, Nicolas.Williams@Sun.COM, Don.Cragun@Sun.COM, Michael.Shapiro@Sun.COM, PSARC@sac.sfbay.sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <200603101842.k2AIg340408596@jurassic.eng.sun.com> References: <200603101842.k2AIg340408596@jurassic.eng.sun.com> Date: Fri, 10 Mar 2006 20:10:15 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 2770 >I've been concerned about approving a change this significant without a >formal opinion to point at. What's stopped me from suggesting it before >was the question, "What would we put in the opinion?". The on/off by >default discussion seems to have provided something. > >BTW: If this ends up default on, I think this *must* have an opinion. >We conciously allow the potential for data corruption into the default >system! As the case stands, the default is off. I think we should keep it that way and, if we feel the need, revisit that decision later (for Nevada only). I would not have suggested that a default of "on" is appriorate had I not believed that there is //no data corruption possible//. I still firmly hold that belief. The only mention of datacorruption is related to core dumps which can happen when applications stray beyond the limits we have set out. The sudden termination of an application CANNOT lead to unacceptable data corruption. Certainly, a database application must be able to recover from termination at any point during its operation as powerfailure or system crashes can strike anytime. As for performance: we have done extensive testing and have rearranged code such that there are *no* performance penalties except in those cases where fopen() would previously fail with EMFILE. We've also found a deficiency in the stdio library which causes MT applications to run more slowly in fopen() than they should; fixing that makes MT fopen()/fclose() pairs 10-20% faster than before. The only thing that would be slower is a tight loop fileno() becnhmark; but this is only relative to snv_32 and later as Roger removed the locking in fileno() at that point; our code still runs faster than earlier Solaris releases when it comes to running fileno(). As for the non-obviousness: arriving at this fix took four ARC cases; we're now into the fifth (unless I missed one). So the *fix* itself is not obvious to arrive at; but not that it is finished, it appears that the discussion really centers on: - bells and whistles (knobs) some what more, some want fewer (we lean towards fewer) - default on or off (we lean towards off) - preload or environment variable to enable feature (envvar seemst to offer the best future direction, IMHO) Perhaps Craig, Don and I should give the spec another beating. Since the project is "code complete", more or less, I'd like to propose we give spec a whirl and then finalize implementation and PSARC work (whether fasttrack or opinion) in parallel as escalations to remove fopens() from our libraries are still coming in. We should not let our schedule dictate what we do, but I think there isn't disagreement on the core of the proposal, just the color of the paintjob. Casper From sacadmin Fri Mar 10 11:18:16 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.55]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AJIGIQ024827 for ; Fri, 10 Mar 2006 11:18:16 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k2AJIAOO437062; Fri, 10 Mar 2006 11:18:15 -0800 (PST) Message-Id: <200603101918.k2AJIAOO437062@jurassic.eng.sun.com> Date: Fri, 10 Mar 2006 09:17:03 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: Joseph.Kowalski@eng.sun.com, Casper.Dik@Sun.COM Cc: Craig.Mohrman@Sun.COM, Ed.Gould@Sun.COM, Nicolas.Williams@Sun.COM, Don.Cragun@Sun.COM, Michael.Shapiro@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kO7NJVGbUrHppVF+k9qZFA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 2165 > From: Casper.Dik@Sun.COM ... > >I've been concerned about approving a change this significant without a > >formal opinion to point at. What's stopped me from suggesting it before > >was the question, "What would we put in the opinion?". The on/off by > >default discussion seems to have provided something. > > > >BTW: If this ends up default on, I think this *must* have an opinion. > >We conciously allow the potential for data corruption into the default > >system! > > As the case stands, the default is off. I think we should keep it that > way and, if we feel the need, revisit that decision later (for Nevada > only). > > I would not have suggested that a default of "on" is appriorate > had I not believed that there is //no data corruption possible//. > > I still firmly hold that belief. The only mention of datacorruption > is related to core dumps which can happen when applications stray beyond > the limits we have set out. The sudden termination of an application > CANNOT lead to unacceptable data corruption. Certainly, a database > application must be able to recover from termination at any point > during its operation as powerfailure or system crashes can strike > anytime. Bravo! Programs that used to run, now core dumping isn't quite as bad as data corruption, but its still rather odious. > As for the non-obviousness: arriving at this fix took four ARC > cases; we're now into the fifth (unless I missed one). So the > *fix* itself is not obvious to arrive at; but not that it is > finished, it appears that the discussion really centers on: > > - bells and whistles (knobs) some what more, some want fewer > (we lean towards fewer) > - default on or off > (we lean towards off) > - preload or environment variable to enable feature > (envvar seemst to offer the best future direction, IMHO) Like I said. Since this is a highly visible project and hopefully the fifth time is that charm, I think we should produce an opinion iff we have something to say. That doesn't mean we need a meeting. (Humm, I thought you we leaning toward preload. I guess I need to reread that part of the discussion.) - jek3 From sacadmin Fri Mar 10 11:19:19 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.17.55]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AJJJIQ024840 for ; Fri, 10 Mar 2006 11:19:19 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k2AJJCwb437582; Fri, 10 Mar 2006 11:19:18 -0800 (PST) Message-Id: <200603101919.k2AJJCwb437582@jurassic.eng.sun.com> Date: Fri, 10 Mar 2006 09:18:06 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: Joseph.Kowalski@eng.sun.com, Casper.Dik@sun.com Cc: Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: REdlxfDB02+9f28nECfKyA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 511 > Date: Fri, 10 Mar 2006 20:10:15 +0100 > From: Casper.Dik@sun.com > Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] > To: Joseph Kowalski > Cc: Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, PSARC@sac.sfbay.sun.com > Content-transfer-encoding: 7BIT > X-PMX-Version: 5.1.2.240295 > > <<< No Message Collected >>> Should I take this personally? 8^) - jek3 From sacadmin Fri Mar 10 11:32:08 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AJW7IQ024971 for ; Fri, 10 Mar 2006 11:32:07 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2AJW0CM025259; Fri, 10 Mar 2006 20:32:00 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2AJW0Dk015617; Fri, 10 Mar 2006 20:32:00 +0100 (MET) Message-Id: <200603101932.k2AJW0Dk015617@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Joseph Kowalski cc: Craig.Mohrman@Sun.COM, Ed.Gould@Sun.COM, Nicolas.Williams@Sun.COM, Don.Cragun@Sun.COM, Michael.Shapiro@Sun.COM, PSARC@sac.sfbay.sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <200603101918.k2AJIAOO437062@jurassic.eng.sun.com> References: <200603101918.k2AJIAOO437062@jurassic.eng.sun.com> Date: Fri, 10 Mar 2006 20:32:00 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 674 >Programs that used to run, now core dumping isn't quite as bad as >data corruption, but its still rather odious. But this is for programs which would previously confronted with fopen() failure and failed that way or which would have run out of file descriptors because the default descriptor limit is 256. (Even with "default on", the user/administrator will have to change at least one more knob to make the "interesting" situation arise) >(Humm, I thought you we leaning toward preload. I guess I need to reread >that part of the discussion.) Oh, perhaps I leaned incorrectly. I suppose my arguments for LD_PRELOAD_32 must have been fairly strong then :-) Casper From sacadmin Fri Mar 10 11:32:41 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AJWeIQ024990 for ; Fri, 10 Mar 2006 11:32:41 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2AJWK9t004762; Fri, 10 Mar 2006 19:32:21 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.5+Sun/8.13.5/Submit) id k2AJWKi7004761; Fri, 10 Mar 2006 14:32:20 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] From: Bill Sommerfeld To: Joseph Kowalski Cc: Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, Casper.Dik@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200603101907.k2AJ7HQ6426898@jurassic.eng.sun.com> References: <200603101907.k2AJ7HQ6426898@jurassic.eng.sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1142019140.4541.77.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.334 Date: Fri, 10 Mar 2006 14:32:20 -0500 Status: RO Content-Length: 970 On Fri, 2006-03-10 at 14:06, Joseph Kowalski wrote: > Or, should I interpret this as "since poorly written programs can > experience data corruption (and be release dependent due to > unsupport/undocumented behaviors), that its also acceptable for programs > which conform to the system specification? The way I read the proposal, 1) correctly written programs built against pre-s7 header files may abort if run in a non-default environment (where, in addition to the feature being enabled, the fd limit is raised above the default limit of 256). If this abort is a problem, these programs can run with the default system fd resource limit, at which point they will behave as they always did. 2) undetected data corruption is only possible for poorly written programs which meddle in the guts of stdio. I'd appreciate seeing examples where correctly written programs would misbehave without aborting in the presence of a FILE opened on a fd>255. - Bill From sacadmin Fri Mar 10 11:38:36 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AJcZIQ025016 for ; Fri, 10 Mar 2006 11:38:35 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2AJcPCM026662; Fri, 10 Mar 2006 20:38:25 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2AJcPDk023297; Fri, 10 Mar 2006 20:38:25 +0100 (MET) Message-Id: <200603101938.k2AJcPDk023297@vaticaan.Holland.Sun.COM> From: Casper.Dik@sun.com To: Bill Sommerfeld cc: Joseph Kowalski , Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, PSARC@sac.sfbay.sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <1142019140.4541.77.camel@localhost> References: <200603101907.k2AJ7HQ6426898@jurassic.eng.sun.com> <1142019140.4541.77.camel@localhost> Date: Fri, 10 Mar 2006 20:38:25 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 1080 > 1) correctly written programs built against pre-s7 header files may >abort if run in a non-default environment (where, in addition to the >feature being enabled, the fd limit is raised above the default limit of >256). If this abort is a problem, these programs can run with the >default system fd resource limit, at which point they will behave as >they always did. > > 2) undetected data corruption is only possible for poorly written >programs which meddle in the guts of stdio. Well, we think this should always lead to an abort but could be wrong. >I'd appreciate seeing examples where correctly written programs would >misbehave without aborting in the presence of a FILE opened on a fd>255. I'd appreciate seeing even a contrived example which does not cause an abort() of extremly badly behaved code, considering that we believe we cover: close(fp->_file); fp->_file = ... (followed by stdio calls) dup2(..., fp->_file); Not that *any* syscall using the descriptor except for close() will cause the code in the getf() error path to raise a signal. Casper From sacadmin Fri Mar 10 11:56:12 2006 Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AJuCIQ025885 for ; Fri, 10 Mar 2006 11:56:12 -0800 (PST) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id k2AJuCQu021122; Fri, 10 Mar 2006 13:56:12 -0600 (CST) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id k2AJuCZp021121; Fri, 10 Mar 2006 13:56:12 -0600 (CST) Date: Fri, 10 Mar 2006 13:56:12 -0600 From: Nicolas Williams To: Casper.Dik@Sun.COM Cc: Don Cragun , PSARC@sac.sfbay.sun.com, Craig.Mohrman@Sun.COM, Michael.Shapiro@Sun.COM Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] Message-ID: <20060310195611.GN9040@binky.Central.Sun.COM> References: <200603082325.k28NP7Oe014235@spartan.SFBay.Sun.COM> <20060310172235.GH9040@binky.Central.Sun.COM> <200603101759.k2AHxJDk019791@vaticaan.Holland.Sun.COM> <20060310180651.GJ9040@binky.Central.Sun.COM> <200603101812.k2AICeDk006288@vaticaan.Holland.Sun.COM> <20060310182619.GL9040@binky.Central.Sun.COM> <200603101842.k2AIgKDk012524@vaticaan.Holland.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200603101842.k2AIgKDk012524@vaticaan.Holland.Sun.COM> User-Agent: Mutt/1.5.7i Status: RO Content-Length: 792 On Fri, Mar 10, 2006 at 07:42:20PM +0100, Casper.Dik@Sun.COM wrote: > > >But fdopen() knows what to do! just dup(). > > No, because you can't be sure that the application won't remember > the fd in someway and use it instead of fileno(). But who does that? > And will fdopen() then also close the fd? Dunno. > I think this discussion has no place in the PSARC case, though, > as it is about allowing for the use of more than > 256 FILE*s as > well as the others and renumbering fds in fdopen is likely > to fail a standards test or two (run your interposer on the standards > test suites and we'll talk again, off-line) OK. I'll drop it. As for that interposer, I don't have it with me -- it belongs to a previous employer, was written years ago and only targetted Samba. Nico -- From sacadmin Fri Mar 10 14:13:17 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AMDGIQ029200 for ; Fri, 10 Mar 2006 14:13:16 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2AMD6A9004850; Fri, 10 Mar 2006 22:13:06 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.5+Sun/8.13.5/Submit) id k2AMD6FV004849; Fri, 10 Mar 2006 17:13:06 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] From: Bill Sommerfeld To: Casper.Dik@sun.com Cc: Joseph Kowalski , Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, PSARC@sac.sfbay.sun.com In-Reply-To: <200603101938.k2AJcPDk023297@vaticaan.Holland.Sun.COM> References: <200603101907.k2AJ7HQ6426898@jurassic.eng.sun.com> <1142019140.4541.77.camel@localhost> <200603101938.k2AJcPDk023297@vaticaan.Holland.Sun.COM> Content-Type: text/plain; charset=ASCII Content-Transfer-Encoding: 7bit Message-Id: <1142028785.4541.300.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.334 Date: Fri, 10 Mar 2006 17:13:05 -0500 Status: RO Content-Length: 450 On Fri, 2006-03-10 at 14:38, Casper.Dik@sun.com wrote: > I'd appreciate seeing even a contrived example which does not cause > an abort() of extremly badly behaved code how about: ASSERT(fileno(f1) < 256); ASSERT(fileno(f2) >= 256); close(f1->_file); f1->_file = fileno(f2); (perform I/O on f1 or f1->_file) but this is conceptually no different from code which breaks given pid's, uid's or gid's which don't fit in a short. - Bill From sacadmin Fri Mar 10 14:16:25 2006 Received: from phys-mpk-1 (phys-mpk-1.SFBay.Sun.COM [129.146.11.81]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AMGPIQ029237 for ; Fri, 10 Mar 2006 14:16:25 -0800 (PST) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IVX00F01MHV1M@mpk-mail1.sfbay.sun.com> (original mail from ed.gould@sun.com) for PSARC@sac.sfbay.sun.com; Fri, 10 Mar 2006 14:16:25 -0800 (PST) Received: from [192.168.0.10] (vpn-129-150-22-181.SFBay.Sun.COM [129.150.22.181]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IVX00D37N5HXH@mpk-mail1.sfbay.sun.com>; Fri, 10 Mar 2006 14:15:18 -0800 (PST) Date: Fri, 10 Mar 2006 14:15:18 -0800 From: Ed Gould Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-reply-to: <200603101910.k2AJAFDk018941@vaticaan.Holland.Sun.COM> To: Casper.Dik@Sun.COM Cc: Michael.Shapiro@Sun.COM, Craig.Mohrman@Sun.COM, Joseph Kowalski , Don.Cragun@Sun.COM, PSARC@sac.sfbay.sun.com, Nicolas.Williams@Sun.COM Message-id: <532f568459eb10ed663d3593e65acea9@sun.com> MIME-version: 1.0 (Apple Message framework v623) X-Mailer: Apple Mail (2.623) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200603101842.k2AIg340408596@jurassic.eng.sun.com> <200603101910.k2AJAFDk018941@vaticaan.Holland.Sun.COM> Status: RO Content-Length: 670 Casper, Thanks for the summary. On Mar 10, 2006, at 11:10, Casper.Dik@Sun.COM wrote: > Perhaps Craig, Don and I should give the spec another beating. > > Since the project is "code complete", more or less, I'd like to propose > we give spec a whirl and then finalize implementation and PSARC work > (whether fasttrack or opinion) in parallel as escalations to remove > fopens() from our libraries are still coming in. > > We should not let our schedule dictate what we do, but I think there > isn't > disagreement on the core of the proposal, just the color of the > paintjob. That sounds good to me. So the case should go to "waiting need spec" for now? --Ed From sacadmin Fri Mar 10 15:04:44 2006 Received: from localhost.east.sun.com (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2AN4hIQ001219 for ; Fri, 10 Mar 2006 15:04:43 -0800 (PST) Received: from localhost.east.sun.com (localhost [127.0.0.1]) by localhost.east.sun.com (8.13.5+Sun/8.13.5) with ESMTP id k2AN4Xkp004864; Fri, 10 Mar 2006 23:04:34 GMT Received: (from sommerfeld@localhost) by localhost.east.sun.com (8.13.5+Sun/8.13.5/Submit) id k2AN4XTV004863; Fri, 10 Mar 2006 18:04:33 -0500 (EST) X-Authentication-Warning: localhost.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] From: Bill Sommerfeld To: Ed Gould Cc: Casper.Dik@sun.com, Michael.Shapiro@sun.com, Craig.Mohrman@sun.com, Joseph Kowalski , Don.Cragun@sun.com, PSARC@sac.sfbay.sun.com, Nicolas.Williams@sun.com In-Reply-To: <532f568459eb10ed663d3593e65acea9@sun.com> References: <200603101842.k2AIg340408596@jurassic.eng.sun.com> <200603101910.k2AJAFDk018941@vaticaan.Holland.Sun.COM> <532f568459eb10ed663d3593e65acea9@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1142031873.4541.414.camel@localhost> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.334 Date: Fri, 10 Mar 2006 18:04:33 -0500 Status: RO Content-Length: 1043 On Fri, 2006-03-10 at 17:15, Ed Gould wrote: > That sounds good to me. So the case should go to "waiting need spec" > for now? I see several distinct components of this: 1) renaming (FILE *)->_file. not controversial. 2) infrastructure changes allowing stdio on fd's > 255 3) providing an interface to permit selective callers of stdio to state that they're fileno()>255-safe. apparently not controversial; some argument about whether it should seek out fd's >255 or not to make more room for code which isn't safe. 4) providing an interface to assert that an entire process is fileno()>255-safe. #1 is independant of the others #2 provides infrastructure for #3 and #4. Only #4 seems particularly controversial, and it's irrelevant to the "escalations to remove fopens()" problem, which would be satisfied by the integration of #2+#3 (plus changes to use #3). And we can deliver multiple ways to do #4 based on implementation experience. So splitting the case (to allow phased delivery) may make sense... - Bill From sacadmin Fri Mar 10 15:47:50 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2ANloIQ001750 for ; Fri, 10 Mar 2006 15:47:50 -0800 (PST) Received: from shortty (shortty.SFBay.Sun.COM [129.146.226.160]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k2ANlneg675532; Fri, 10 Mar 2006 15:47:49 -0800 (PST) Message-Id: <200603102347.k2ANlneg675532@jurassic.eng.sun.com> Date: Fri, 10 Mar 2006 15:47:49 -0800 (PST) From: Craig Mohrman Reply-To: Craig Mohrman Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: sommerfeld@sun.com Cc: Casper.Dik@sun.com, Joseph.Kowalski@eng.sun.com, Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: gLFnJn/PuTMtzeNNMixSGg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 2673 >X-Unix-From: sommerfeld@sun.com Fri Mar 10 14:13:24 2006 >Date: Fri, 10 Mar 2006 17:13:05 -0500 >From: Bill Sommerfeld >Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] >To: Casper.Dik@sun.com >Cc: Joseph Kowalski , Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, PSARC@sac.sfbay.sun.com >X-PMX-Version: 5.1.2.240295 > >On Fri, 2006-03-10 at 14:38, Casper.Dik@sun.com wrote: >> I'd appreciate seeing even a contrived example which does not cause >> an abort() of extremly badly behaved code > >how about: > ASSERT(fileno(f1) < 256); > ASSERT(fileno(f2) >= 256); > close(f1->_file); > f1->_file = fileno(f2); > > (perform I/O on f1 or f1->_file) > Let's look at this carefully. If this were attempted on S10 then: ASSERT(fileno(f2) >= 256); is not possible because no FILE can contain an fd >= 256. If this were attempted on an Extended FILE OS then this won't compile because we have renamed the FILE->_file field so the user's been warned that something changed. Also, if the user had done due diligence and checked the return of close() he would have received a -1 and errno = 9. So, we did tell you something was wrong. >but this is conceptually no different from code which breaks given >pid's, uid's or gid's which don't fit in a short. > > - Bill What DOES fail and it's what we've documented is: FILE->_file = 300; If this is a normal FILE then this produces the SAME corruption that they receive today. If this is an Extended FILE then FILE->_file contains the toxic descriptor and all STDIO I/O is performed on the hidden fd. If the user has replaced the toxic descriptor: FILE->_file = 300; and attempts to perform STDIO I/O we have a safety check that will abort() the program the next time the STDIO buffers are filled. No actual harm to their data happens because the hidden fd remains intact and STDIO I/O is still being performed there. If the user is performing low level I/O on FILE->_file then they corrupt themselves in a manner similar to older Solaris's. So the window for corruption is extremely small and perhaps only theoretical. Existing binaries don't know of a world where FILE->_file >= 256 so it is highly unlikely that they wonder into it. IT being: FILE->_file = 300; Recompilation will fail sources that reference _file directly as it was renamed. What does that leave? We will gain some experience with this internally as the other parts of Solaris are recompiled and trip over their FILE->_file usages and are forced to fix their codes. craig From sacadmin Fri Mar 10 19:43:39 2006 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2B3hdIQ006817 for ; Fri, 10 Mar 2006 19:43:39 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id k2B3hcJN019050; Fri, 10 Mar 2006 19:43:38 -0800 (PST) Message-Id: <200603110343.k2B3hcJN019050@spartan.SFBay.Sun.COM> Date: Fri, 10 Mar 2006 19:43:38 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Spec Update for Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: PSARC@sac.sfbay.sun.com Cc: Casper.Dik@Sun.COM, Craig.Mohrman@Sun.COM, Nicolas.Williams@Sun.COM, Michael.Shapiro@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: VZbobBdTk+xitv+VXI8ENw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 24449 I am submitting this spec update for the project team. Unless an extension is requested, the timer remains set to expire Wednesday, March 15, 2006. A minor release binding is requested for changing _file to _magic in struct FILE. A patch release binding is requested for everything else. PSARC case 2001/680 (Large fd stdio) has been marked "closed superseded 2006/162". The original files corresponding to those that have changed as a result of this update have been saved in the materials directory with an "OLD_" prefix. The updated DESIGN.txt file is also included below. I believe that there was consensus in the e-mail discussion on most points. The following changes have been made in the updated files in the materials directory. 1) Removed STDIO_BADFD_SIGNAL_MESSAGE environment variable from the Exported Interfaces table. 2) Added a leading "_" to the remaining environment variables. 3) Changed __extendedfd_nocheck to __xf_nocheck. 4) Changed __file to _magic. (Extensive comments will also be added to the header explaining why applications should not use this field.) 5) Some editorial clean up on the extendedFILE.3LIB man page. It isn't clear to me whether any changes were needed for the following points. No changes have been made to the spec to address these points so far. The project team will make changes if there is a clear consensus to do so. 1) Bill Sommerfeld commented: As part of this case, perhaps we should Obsolete (but not EOF) just the part of the ABI involving fp->_file, as a strong suggestion (but not a requirement) that code built against pre-s7 headers be put out of its misery. There has been no discussion on this topic in the case log. 2) Tim Marsland commented: Secondly, I don't quite understand the value of allowing the fcntl to specify an arbitrary signal. Isn't SIGABRT enough i.e. -1 means SIGABRT, 0 means don't send anything? Or is there other ways to use this that I'm missing? What's the thinking here? The reason this was in the proposal is because some applications catch or ignore SIGABRT. Although the project team doesn't know of any specific applications that catch or ignore SIGABRT that would also want to use this feature, we wanted to give those applications the ability to choose a different signal that they could then catch and drop core without otherwise disturbing the current program logic. It is less useful when using using the preloadable library than when calling fcntl() directly, but Craig did use it in some cases while testing various prototypes. Sincerely, Don Cragun Copyright 2006 Sun Microsystems, Inc. THANKS ====== Firstly a note of thanks to Don Cragun, Casper Dik, and Mike Shapiro for their guidance, reviews, ideas, and baby sitting (of me). I could not have done this without them. Hopefully the 4th try will be the charm. 1. Introduction 1.1. Project/Component Working Name: Extended FILE space for 32-bit Solaris processes 1.2. Name of Document Author/Supplier: Author: Craig Mohrman 1.3 Date of This Document: 8 March, 2006 4. Technical Description NOTE ==== Please read the entire proposal before commenting. Much detail and many answers lie beneath. Thank you. Summary ======= 32-bit Solaris processes will no longer be limited to 256 FILE's with LITTLE chance of silent data corruption. Silent data corruption can only occur if: 1. the process uses FILE->_file directly, 2. the process uses the fileno() macro (the fileno() macro was removed from our headers in Solaris release 2.7) rather than the fileno() function, or 3. the process truncates the value returned by the fileno() function. This is a runtime change with no limit on the age of the software. Even pre-2.7 software will work. Background ========== It has been a historical limitation of UNIX implementations that an unsigned char is used to store the value of the file descriptor (fd) associated with the stream (FILE). The effect of this is that the maximum value such a file descriptor could take was 255. This limitation has become burdensome for a number of customers. See, for example: 1085341 _file in stdio.h should be an unsigned long 1147964 NIS+ servers start repeatedly doing FULL RESYNCS ... runs out of fd's 1173088 request to remove the stdio streams file pointer fopen limit of 256. 1253283 gethostbyname fails if more than 255 file descriptors are already open 1266821 lpsched goes into an infinite loop hanging. 4009255 getnettype limits # of fd's to 255 4031927 the use of fopen() in cdbopen() of libcdb fails when open files greater than 255 4043375 socketpair() returns EAGAIN. 4050822 dlopen() core dumps when no fds available (was ypmatch dumps core). 4081318 in.named: fdopen: Error 0 4101908 SUBSCRIBE/UNSUBSCRIBE fail if more than 256 files are open ... 4131997 pam_start() fails when the application has more than 255 open file .. 4152876 getspnam_r() fails due to use of fopen() in libnsl.so in 4156580 getnetlist uses fopen, limiting RPC to 256 descriptors 4166190 FNS uses fopen(), this is bad. 4239433 Request to remove the stdio streams file pointer fopen limit of 256. 4275900 dbx fails to open a file if there are more than 255 lwps running 4292123 Error in libsecurity: cannot open /etc/netconfig 4353836 if more than 255 file descriptors are already open then gethostbyname 4400631 "getgrent" calls "fopen" instead of "open" 4459640 Java crash with a load of more than 20 users, assertion on 4472001 gethostbyname failed with NO_RECOVERY when there are more .. 4472174 use of fopen in zip utils implementation 4472176 use of fopen in java sound implementation 4472179 use of fopen in J2SE networking classes implementation 4472183 Solaris: use of fopen() in timezone classes implementation 4472199 use of fopen() in java runtime profiling support 4472643 fopen and fdopen fail in less than FOPEN_MAX or STREAM_MAX calls 4481723 yacc generated code does not handle error returned by fdopen etc. Additionally, if application code uses a lot of file descriptors but also takes care to avoid stdio, it will still find that certain standard library functions break when fds 0...255 are all in use. (e.g., socket, nsl, nss and nameserver libraries alone contain nearly 100 calls to stdio functions returning a FILE *) This has lead to various bugs, many of which in effect require reimplementing parts of stdio inside applications or libraries, or rewriting an application to use file descriptors above 255 instead of using FILE * more naturally. This is a continuous maintenance burden, especially where additional code gets added to reimplement bits of stdio to work with fds > 255. While this limit is now lifted for 64-bit applications, we are still faced with this issue for our own 32-bit runtime, 32-bit JVM, and a variety of 32-bit applications. It is not possible for binary compatibility reasons to simply change the _file field of the FILE structure from an unsigned char to an int because this would cause the size of the structure to change and would therefore break binary compatibility constraints. This proposal draws on experiences and supersedes the following cases: PSARC/1996/413 - Lots of File Descriptors current status: closed superseded 1998/109 While discussing the case Steve Chessin proposed a reserved fd open against a device which yields the fd unusable. PSARC/1998/109 - Extended Stdio current status: closed withdrawn Joe Townsend and Mike Shapiro propose a new fcntl() command which will invalidate an fd that will be stored in the _file field. PSARC/2001/680 - Large fd stdio current status: discussing Casper Dik proposes a new "F" flag for internal usage of extended FILEs. If this case is approved, PSARC/2001/680 will be marked closed withdrawn. Overview of Changes =================== These changes will only affect 32-bit applications. The 64-bit environment is unchanged except for the fcntl(F_BADFD) system call which will fail. The default 32-bit case will work as it does today. The user must take action(s) in order to enable this feature. (I.e., opt in.) Applications that enable this feature will be able to associate any valid file descriptor (fd) with a STDIO stream. This feature can be enabled using a preloadable library or a new enable_extended_FILE_stdio(3C) function. When this feature is enabled, larger fd's (>255) will be stored in an auxiliary location and a bogus (bad) fd will be stored in the FILE->_file field. Improper accesses by the application to the FILE->_file field will either yield the proper underlying fd for those fd's <= 255 or the unavailable (bad) fd. Accessing the (bad) fd will yield errors. There is very little chance of silent data corruption. There are 2 programmatic interfaces allowing access to the larger than 256-fd FILE pool provided that the RLIMIT_NOFILE resource limit has been raised. The default RLIMIT_NOFILE is 256 fd's. The first interface is adding a flag, "F", to the existing mode string of standard I/O open calls, e.g. fopen(), fdopen(), popen(). This is intended to be used by library routines (e.g. gethostent()) but applications may use it as well. This interface provides no safeguards against misuse. The FILE pointer returned by these stdio open routines must never to passed to any uninspected code; data corruption may occur if uninspected code misuses a FILE pointer opened in this manner. The second interface, enable_extended_FILE_stdio(), is more generalized and does provide protection to software with unknown behaviors such as 3rd party libraries without source code. To aid in "cleaning up" source code which contains FILE->_file access we propose to rename FILE->_file to FILE->_magic. This will forcibly break the compilation of any source containing references to FILE->_file. Obviously this will grab the attention of developers who will then hopefully recode FILE->_file to the more appropriate fileno(FILE). Sun code needs this as much as 3rd party code. This will very quickly clean up Solaris to be fiLE->_file clean and guarantee that using extended FILE will work throughout Solaris. Without this it will be very difficult to verify Solaris, and other software products, readiness. If it is known that the application accesses the FILE->_file field directly then this feature should not be used, even though we go to great lengths to handle all possible cases there can always be another case we did not think of. For well behaved applications (no direct FILE->_file accesses) then this works wonderfully. Details of Changes ================== 1. A new bitfield will be added to the FILE struct, __extendedfd. When this bitfield is set to 1, the file descriptor associated with the stream is stored as auxiliary data; not in _file. How _file is set in this case depends on other issues specified below. A second bitfield is added to the FILE struct, __xf_nocheck. This bitfield is used to control error checking. 2. We add a new fcntl() command. marked_fd = fcntl(low_fd, F_BADFD, action) This fcntl() command will: A. mark the first currently closed file descriptor greater than or equal to low_fd to be unavailable for assignment as a file descriptor for any following system call that allocates a file descriptor, B. set the action to be taken by the kernel when marked_fd is passed in as an fd in subsequent system calls. If action is 0, any reference to marked_fd will return an error with errno set to EBADF; otherwise, any reference to marked_fd will send an "action" signal to the process and return an error with errno set to EBADF. The "action" may be any valid signal number. The "action" signal will not be sent if the application attempts close(marked_fd). We believe that many applications exist that attempt to close() fd's they did not open. This new fcntl() command will return the file descriptor that has been marked as unavailable. If no file descriptor in the range 3 <= low_fd <= marked_fd <= 255 can be marked, the fcntl() will fail and return -1. If the call fails, errno will be set as follows: EAGAIN All file descriptors in the inclusive range low_fd through 255 refer to files that are currently open in the process. EBADF low_fd is less than 3 or greater than 255. EEXIST A file descriptor has already been marked by an earlier call to fcntl(). EINVAL action is not a valid signal number. This fcntl() may only be called successfully once. Subsequent calls will return an error. An unallocatable file descriptor set by the fcntl() F_BADFD command will be inherited by a child across fork operations and cleared in the new process image during exec and spawn operations. This new fcntl(F_BADFD) command should not be used directly by applications. Applications should use enable_extended_FILE_stdio() (see #6 below) instead. Calling fcntl(F_BADFD) directly serves no purpose and would cause a subsequent call to enable_extended_FILE_stdio() to fail. 3. An additional flag "F" is added to the mode argument in our implementation of fopen(), fdopen(), and popen(). This flag will allow fopen() and fdopen() to assign/specify a file descriptor larger than 255. popen() will also recognize "F" in its mode string because it passes its mode string through to fdopen(). The "F" flag will only be recognized if it is the last character of the mode argument. When fopen() is called it will use the lowest available file descriptor. The "F" flag, when used by Sun's engineers, will be used by library routines only if that use of fopen() is to create a stream that will not be returned to application code for any use. If the file descriptor allocated (after F flag processing) is less than 256, __extendedfd will be set to 0 and _file will be set to the new file descriptor. Otherwise the action depends on the current value of __STDIO_bad_fd and the presence of the F flag. If __STDIO_bad_fd is less than 0 and the F flag is not present, the fopen() or fdopen() will fail; otherwise __extendedfd will be set to 1, _file will be set to (unsigned char)__STDIO_bad_fd, and the file descriptor will be stored in an auxiliary location. Another new bitfield, FILE->__xf_nocheck, will be set to 1 to help us manage this internally requested extended FILE. These changes only apply to the 32-bit code path. The following pseudo code demonstrates what the new 32-bit fopen() might look like: libc will initialize: __STDIO_bad_fd = -1; /* runtime is signaling us to use */ /* extended FILEs */ /* default < 0; no extended FILEs */ fopen(filename, mode) { fd = open(filename, ...) if (fd < 0) return (NULL) if(fd < 256) { FILE->_file = fd FILE->__extendedfd = 0 FILE->__xf_nocheck = 1 } else if ("F"_is_the_last_character_in_mode) { FILE->__extendedfd = 1 FILE->__xf_nocheck = 1 fd is stored in an auxiliary location } else if(__STDIO_bad_fd >= 0) { FILE->_file = (unsigned char)__STDIO_bad_fd FILE->__extendedfd = 1 FILE->__xf_nocheck = 0 fd is stored in an auxiliary location } else { close(fd) errno = EMFILE return (NULL) } } The possible scenarios are thus: A) User does nothing and runs applications: Everything works or fails as before. B) User raises RLIMIT_NOFILE: Normal stdio calls still limited to 256 FILE's but any usage of the "F" flag will allow RLIMIT_NOFILE FILE's. C) User raises RLIMIT_NOFILE and pre-loads extended FILE library: Application gets RLIMIT_NOFILE FILE's. Direct access to FILE->_file are preserved for the fd's <= 255. fd's > 255 will receive errors or signal. User's choice. Solaris internal libraries ("F" usage) gets the same as B above. $ ulimit -n 1000 $ LD_PRELOAD_32=/usr/lib/extendedFILE.so.1 \ application [args...] 4. It has been noted that private copies of STDIO code exist to locally alleviate the 256 fd limitation. These codes will be identified and subsequently converted to use the new STDIO and "F" flag. These changes are not part of this case but are being duly noted for future action. [Note: Casper has alerted me to one such case in networking code. I can find no other instances.] Upon integration, Sun Engineering will be notified of the availability of this change. 5. We add a preloadable library that can be used to invoke the new enable_extended_FILE_stdio(low_fd, action) function before entering main(). If the user sets the environment variable STDIO_BADFD to a value between 3 and 255 inclusive when loading the preloadable library, low_fd will be set to that value. Otherwise, low_fd will be given the default value 196. The "action" parameter can also be user specified. If the "action" parameter is not specified the default "action" will be to return errors and set errno as indicated above. The user can also choose to have signal sent by setting the environment variable _STDIO_BADFD_SIGNAL to the desired signal number or name before launching their application. $ ulimit -n 1000 $ LD_PRELOAD_32=/usr/lib/extendedFILE.so.1 _STDIO_BADFD=100 \ _STDIO_BADFD_SIGNAL=SIGABRT application [args...] 6. A second programming interface; enable_extended_FILE_stdio(int fd, int action) is added to allow 3rd parties and end users access to the interface used in the preloadable library. (#5 above) The fd argument is the starting point to begin searching for an available fd to be marked as the unallocatable file descriptor. Its value must be between 3-255 inclusive. If an available fd cannot be found an error is returned. A value of -1 for fd will use a built in scheme for searching for an available fd. The action argument is the requested signal to be sent to the application in the event of an error in the usage of this mechanism or improper access to FILE->_file is detected. A value of -1 yields the default SIGABRT signal. A value of 0 disables the sending of a signal. 7. Rename FILE->_file to FILE->_magic. This will aid all of Sun and 3rd parties in the source code cleanup that directly accesses _file. This is needed to ensure the safety in using the extended FILE mechanism. This change will not affect running code in any way; it only generates errors at compile time. References to _file in the remainder of this proposal refer to code that exists in applications that has not yet been converted to use public interfaces. The four programming interfaces described here provide similar features, but are intended for different audiences. The fcntl(low_fd, F_BADFD, action) function should never be called directly by applications. It is only intended to be used by enable_extended_FILE_stdio() which performs the additional "paperwork" needed to fully enable this feature. The "F" mode flag to fdopen(), fopen(), and popen() is intended for use in applications and libraries in cases where it is known that the FILE pointer returned will never be passed to any code that may use the FILE pointer to directly access the _file field. This flag allows large file descriptors to be used in cases where it is known that the FILE pointer will only be used in safe ways. Fewer checks for invalid file descriptors are performed since all uses of the "F" mode flag can be assumed to have been inspected. The "F" flag must never be used in any case where the FILE pointer will be given to uninspected code that might directly access _file through that FILE pointer. Passing a FILE pointer opened using the "F" flag to uninspected code could lead to data corruption. The "F" flag's primary intention is to allow the Solaris libraries to open configuration files with stdio functions when the file descriptors below 256 have been depleted. The enable_extended_FILE_stdio() function and the /usr/lib/extendedFILE.so.1 preloadable library can be used by any application that needs to use extended file descriptors with STDIO routines. They fully enable the extended file descriptors for STDIO features. New applications and applications that can be easily modified are expected to use the enable_extended_FILE_stdio() function; the preloadable library provides the same features when an existing application can't be modified to call enable_extended_FILE_stdio(). As long as the application checks for error returns and doesn't change the file descriptor being used by an STDIO stream by directly changing _file, using extended file descriptors will not increase the likelihood of data corruption. This is intended for 3rd party use. There is one theoretical case where this fails: (void) close(FILE->_file); FILE->_file = myfd; Assume FILE->_file is filled with the marked badfd file descriptor because we are using extended FILEs. The close() function will fail but since this usage ignores the return status the application proceeds to perform low level I/O on FILE->_file while calls to STDIO functions would continue to use the original, extended file descriptor. If the application continues using STDIO functions after changing FILE->_file silent data corruption could occur because the application thinks it has changed fd's via the above assignment but the actual STDIO fd is stored in the auxiliary location. The chances for corruption are even higher if myfd has a value greater than 255 and is truncated by the assignment to 8-bit _file. If the application does use _file directly (including using the fileno() macro that was provided in in Solaris 2.0 through 2.7), it should not use this feature. PERFORMANCE =========== The default, extended FILE's not enabled, will maintain current performance. With extended FILE's enabled, access to fd's <= 255 will also maintain current performance. fd's >= 256 will take a performance hit due to storage/retrieval of the file descriptor in an auxiliary location. fopen() with fds < 256 is as fast as before. fopen() is 5-10% slower with fd's >= 256 than with fd's < 256. Only 32 bit applications are affected. There is a small penalty in the remainder of the stdio code where file descriptors are used; but since stdio tries hard to avoid using file descriptors and the use of file descriptors causes much more expensive system calls this disappears in the noise. DOCUMENTATION ============= The fopen(3C), fdopen(3C), and popen(3C) man pages will be adjusted to this new behavior. A new man page for extendedFILE.so.1 will be created to explain in great detail how to use the feature and various scenarios will be presented. A new man page for enable_extended_FILE_stdio() will be created to explain the programmatic interface. FAILING CASE ============ We have added code to detect the theoretical failing case described above. If this failing case is detected then a simple message will be printed to stderr and abort() will be called. Exported Interfaces =================== Interface Stability --------- --------- FILE->__extendedfd project private FILE->__xf_nocheck project private FILE->_magic (was _file) project private "F" flag to fopen() evolving "F" flag in fdopen() evolving "F" flag in popen() evolving F_BADFD fcntl() command project private enable_extended_FILE_stdio() evolving /usr/lib/extendedFILE.so.1 stable _STDIO_BADFD env. variable stable _STDIO_BADFD_SIGNAL env. variable stable 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack From sacadmin Sun Mar 12 10:53:54 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.166]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2CIrrIQ007761 for ; Sun, 12 Mar 2006 10:53:54 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k2CIrmgF300056; Sun, 12 Mar 2006 10:53:52 -0800 (PST) Message-Id: <200603121853.k2CIrmgF300056@jurassic.eng.sun.com> Date: Sun, 12 Mar 2006 08:52:36 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: Ed.Gould@sun.com, sommerfeld@sun.com Cc: Casper.Dik@sun.com, Michael.Shapiro@sun.com, Craig.Mohrman@sun.com, Joseph.Kowalski@sun.com, Don.Cragun@sun.com, PSARC@sac.sfbay.sun.com, Nicolas.Williams@sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Tm2Udui05mAC91UuL9nMKw== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 1321 > From: Bill Sommerfeld ... > I see several distinct components of this: > > 1) renaming (FILE *)->_file. not controversial. > 2) infrastructure changes allowing stdio on fd's > 255 > 3) providing an interface to permit selective callers of stdio to > state that they're fileno()>255-safe. apparently not controversial; > some argument about whether it should seek out fd's >255 or not to make > more room for code which isn't safe. > 4) providing an interface to assert that an entire process is > fileno()>255-safe. > > #1 is independant of the others > #2 provides infrastructure for #3 and #4. > > Only #4 seems particularly controversial, and it's irrelevant to the > "escalations to remove fopens()" problem, which would be satisfied by > the integration of #2+#3 (plus changes to use #3). > > And we can deliver multiple ways to do #4 based on implementation > experience. But, without knowing the decision on #1, one might not want to approve the others for integration (completeness). Besides, I suspect this will be eventually derailed, just for the creation of an opinion. This is obvious? 8^) The only thing obvious to me (having lived through the previous 4 iterations) is that we need to finally do something. I suggest keeping this case as a single unit. - jek3 From sacadmin Sun Mar 12 11:00:37 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.58.37]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2CJ0aIQ008297 for ; Sun, 12 Mar 2006 11:00:37 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k2CJ0UMC301085; Sun, 12 Mar 2006 11:00:35 -0800 (PST) Message-Id: <200603121900.k2CJ0UMC301085@jurassic.eng.sun.com> Date: Sun, 12 Mar 2006 08:59:19 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: sommerfeld@sun.com, Craig.Mohrman@eng.sun.com Cc: Casper.Dik@sun.com, Joseph.Kowalski@eng.sun.com, Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: kko0cOJwic/4S9uUi8MXMA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 923 > From: Craig Mohrman ... > >On Fri, 2006-03-10 at 14:38, Casper.Dik@sun.com wrote: > >> I'd appreciate seeing even a contrived example which does not cause > >> an abort() of extremly badly behaved code > > > >how about: > > ASSERT(fileno(f1) < 256); > > ASSERT(fileno(f2) >= 256); > > close(f1->_file); > > f1->_file = fileno(f2); > > > > (perform I/O on f1 or f1->_file) > > > > Let's look at this carefully. > > If this were attempted on S10 then: What about S7, or attempted on S10 in some old crufty library which was compiled on S7? (Or whenever is prior to fileno ceaseing to be a macro). BTW: remember we **encourage** ISVs to compile on the oldest system they intend to support. The java currently in Nevada was compiled on Solaris 7. (The one to be delivered in a month or two will be compiled on Solaris 8). Point is, the ^Q%$^#$ macro is still an important case. - jek3 From sacadmin Sun Mar 12 11:06:32 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2CJ6VIQ008338 for ; Sun, 12 Mar 2006 11:06:31 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2CJ6MCM029214; Sun, 12 Mar 2006 20:06:22 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2CJ6MDk023070; Sun, 12 Mar 2006 20:06:22 +0100 (MET) Message-Id: <200603121906.k2CJ6MDk023070@vaticaan.Holland.Sun.COM> From: Casper.Dik@sun.com To: Joseph Kowalski cc: sommerfeld@sun.com, Craig.Mohrman@eng.sun.com, Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, PSARC@sac.sfbay.sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <200603121900.k2CJ0UMC301085@jurassic.eng.sun.com> References: <200603121900.k2CJ0UMC301085@jurassic.eng.sun.com> Date: Sun, 12 Mar 2006 20:06:22 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 983 > >> From: Craig Mohrman >... >> >On Fri, 2006-03-10 at 14:38, Casper.Dik@sun.com wrote: >> >> I'd appreciate seeing even a contrived example which does not cause >> >> an abort() of extremly badly behaved code >> > >> >how about: >> > ASSERT(fileno(f1) < 256); >> > ASSERT(fileno(f2) >= 256); >> > close(f1->_file); >> > f1->_file = fileno(f2); >> > >> > (perform I/O on f1 or f1->_file) >> > >> >> Let's look at this carefully. >> >> If this were attempted on S10 then: > >What about S7, or attempted on S10 in some old crufty library which was >compiled on S7? (Or whenever is prior to fileno ceaseing to be a macro). > >BTW: remember we **encourage** ISVs to compile on the oldest system they >intend to support. The java currently in Nevada was compiled on Solaris >7. (The one to be delivered in a month or two will be compiled on >Solaris 8). Point is, the ^Q%$^#$ macro is still an important case. The macro was gone in 7, right? Casper From sacadmin Sun Mar 12 11:51:43 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.224.130]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2CJphIQ008617 for ; Sun, 12 Mar 2006 11:51:43 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5) with SMTP id k2CJpbvn330460; Sun, 12 Mar 2006 11:51:41 -0800 (PST) Message-Id: <200603121951.k2CJpbvn330460@jurassic.eng.sun.com> Date: Sun, 12 Mar 2006 09:50:26 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: Joseph.Kowalski@eng.sun.com, Casper.Dik@sun.com Cc: sommerfeld@sun.com, Craig.Mohrman@eng.sun.com, Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: Wamu8xmAB6m8FUclt06tzg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 453 > From: Casper.Dik@sun.com ... > The macro was gone in 7, right? > > Casper I'm not sure if it was gone in 7 or 8. I think this was answered in the thread, but I'm not sure it matters that much. Due to the way we encourage ISV's to operate, I tend to suspect it may not be as dead as others suspect. I also recall that the earlier cases had concerns about old libraries that will never be regenerated. That's all I was trying to assert. - jek3 From sacadmin Mon Mar 13 08:50:35 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.228.50]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2DGoZIQ028905 for ; Mon, 13 Mar 2006 08:50:35 -0800 (PST) Received: from shortty (shortty.SFBay.Sun.COM [129.146.226.160]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2DGoYhk151724; Mon, 13 Mar 2006 08:50:34 -0800 (PST) Message-Id: <200603131650.k2DGoYhk151724@jurassic.eng.sun.com> Date: Mon, 13 Mar 2006 08:50:34 -0800 (PST) From: Craig Mohrman Reply-To: Craig Mohrman Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: Joseph.Kowalski@sun.com, Casper.Dik@sun.com Cc: sommerfeld@sun.com, Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: iOrjEyqOCEivFSnDjvn0LQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 2193 >Date: Sun, 12 Mar 2006 09:50:26 -1000 (HST) >From: Joseph Kowalski >Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] >To: Joseph.Kowalski@eng.sun.com, Casper.Dik@sun.com >Cc: sommerfeld@sun.com, Craig.Mohrman@eng.sun.com, Craig.Mohrman@sun.com, Ed.Gould@sun.com, Nicolas.Williams@sun.com, Don.Cragun@sun.com, Michael.Shapiro@sun.com, PSARC@sac.sfbay.sun.com >X-PMX-Version: 5.1.2.240295 > > >> From: Casper.Dik@sun.com >... >> The macro was gone in 7, right? >> >> Casper > Correct. >I'm not sure if it was gone in 7 or 8. I think this was answered in the >thread, but I'm not sure it matters that much. > >Due to the way we encourage ISV's to operate, I tend to suspect it may not >be as dead as others suspect. > This is good stuff Joe. I did not know that. >I also recall that the earlier cases had concerns about old libraries that >will never be regenerated. > >That's all I was trying to assert. > >- jek3 > This is exactly the reason for the bogus fd. The fd's 0-255 in FILE will continue to be work as before. So old code written with FILE->_file direct access, ie. the fileno() macro, will continue to work just fine. And given that these older software probably knew there were only 256 FILE's we should be ok. When we get an fd >= 256 then FILE->_file gets the bogus fd. It's when code starts filling in FILE->_file with their own fd's that overwrite the bogus fd is when we could get into trouble. We do have a check to detect this when the app/library needs to fill FILE buffers. My question to PSARC is "has anyone ever seen code like that?" . /* assume this is an extended FILE and FILE->_file >= 256 */ (void) close(FILE->_file); /* attempting to close the bogus fd */ FILE->_file = 0; Do 3rd party applications or libraries actually switch out _file and continue performing I/O on this new fd and thus bypassing proper interface usage? And if one day someone does find a bad enough program that this solution doesn't work then too bad. You can't use this. Good thing this was an opt-in and not default behavior. You will just have to continue operating as before. craig From sacadmin Mon Mar 13 10:59:50 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2DIxnIQ003743 for ; Mon, 13 Mar 2006 10:59:49 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2DIxeCM002082; Mon, 13 Mar 2006 19:59:40 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2DIxeDk016899; Mon, 13 Mar 2006 19:59:40 +0100 (MET) Message-Id: <200603131859.k2DIxeDk016899@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Craig Mohrman cc: Joseph.Kowalski@Sun.COM, sommerfeld@Sun.COM, Craig.Mohrman@Sun.COM, Ed.Gould@Sun.COM, Nicolas.Williams@Sun.COM, Don.Cragun@Sun.COM, Michael.Shapiro@Sun.COM, PSARC@sac.sfbay.sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <200603131650.k2DGoYhk151724@jurassic.eng.sun.com> References: <200603131650.k2DGoYhk151724@jurassic.eng.sun.com> Date: Mon, 13 Mar 2006 19:59:40 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 842 >My question to PSARC is "has anyone ever seen code like that?" . > /* assume this is an extended FILE and FILE->_file >= 256 */ > (void) close(FILE->_file); /* attempting to close the bogus fd */ > FILE->_file = 0; >Do 3rd party applications or libraries actually switch out _file >and continue performing I/O on this new fd and thus bypassing proper >interface usage? > >And if one day someone does find a bad enough program that this solution >doesn't work then too bad. You can't use this. >Good thing this was an opt-in and not default behavior. >You will just have to continue operating as before. Hm, one wonders now if such programs/libraries exist and such programs use newer components which enabled extended FILE I/O, would it then be advisable to have a environment variable which makes sure that enabled_....() fails? Casper From sacadmin Mon Mar 13 11:50:51 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.104.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2DJopIQ006076 for ; Mon, 13 Mar 2006 11:50:51 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2DJoJnu357955; Mon, 13 Mar 2006 11:50:42 -0800 (PST) Message-Id: <200603131950.k2DJoJnu357955@jurassic.eng.sun.com> Date: Mon, 13 Mar 2006 09:49:24 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: Craig.Mohrman@eng.sun.com, Casper.Dik@Sun.COM Cc: Joseph.Kowalski@Sun.COM, sommerfeld@Sun.COM, Craig.Mohrman@Sun.COM, Ed.Gould@Sun.COM, Nicolas.Williams@Sun.COM, Don.Cragun@Sun.COM, Michael.Shapiro@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: SggQSZ2zUr0CgU5kw5dSUQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 683 Now for something completely different.... We started with two ways to enable this: LD_PRELOAD and an environment variable. I believe we've reduced it to an environment variable. I don't think either of the above are the best way to enable this (but you do need one of them, for applications which already exist). What's missing is a way to link a program such that it always gets the new behavior (if available). Otherwise, you always need a wrapper script around the program known to work with the new behavior. (Well, you could have it set the environment variable and then re-exec itself, but let's not go there.) There are probably a number of ways to do this. - jek3 From sacadmin Mon Mar 13 12:22:17 2006 Received: from sunnl.holland.sun.com (sunnl.Holland.Sun.COM [129.159.201.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2DKMGIQ007493 for ; Mon, 13 Mar 2006 12:22:16 -0800 (PST) Received: from vaticaan.Holland.Sun.COM (vaticaan [129.159.201.10]) by sunnl.holland.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.3beta1412) with ESMTP id k2DKM9CM022180; Mon, 13 Mar 2006 21:22:09 +0100 (MET) Received: from holland (casper@room101 [129.159.201.52]) by vaticaan.Holland.Sun.COM (8.12.10+Sun/8.12.9) with ESMTP id k2DKM9Dk028734; Mon, 13 Mar 2006 21:22:09 +0100 (MET) Message-Id: <200603132022.k2DKM9Dk028734@vaticaan.Holland.Sun.COM> From: Casper.Dik@Sun.COM To: Joseph Kowalski cc: Craig.Mohrman@eng.sun.com, Joseph.Kowalski@Sun.COM, sommerfeld@Sun.COM, Craig.Mohrman@Sun.COM, Ed.Gould@Sun.COM, Nicolas.Williams@Sun.COM, Don.Cragun@Sun.COM, Michael.Shapiro@Sun.COM, PSARC@sac.sfbay.sun.com Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] In-Reply-To: <200603131950.k2DJoJnu357955@jurassic.eng.sun.com> References: <200603131950.k2DJoJnu357955@jurassic.eng.sun.com> Date: Mon, 13 Mar 2006 21:22:09 +0100 Sender: casper@holland.sun.com Status: RO Content-Length: 724 >We started with two ways to enable this: LD_PRELOAD and an environment >variable. I believe we've reduced it to an environment variable. No, the SPEC only ever specified LD_PRELOAD_32 and not an environment variable. (The spec allows applications themselves to also switch the big knob) >What's missing is a way to link a program such that it always gets the >new behavior (if available). Otherwise, you always need a wrapper script >around the program known to work with the new behavior. (Well, you could >have it set the environment variable and then re-exec itself, but let's >not go there.) > >There are probably a number of ways to do this. That way is adding a specific function call to the program. Casper From sacadmin Mon Mar 13 12:28:26 2006 Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.108.31]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2DKSQIQ007622 for ; Mon, 13 Mar 2006 12:28:26 -0800 (PST) Received: from hawaiian-sun (vpn-129-150-12-95.SFBay.Sun.COM [129.150.12.95]) by jurassic.eng.sun.com (8.13.6.Gamma0+Sun/8.13.5) with SMTP id k2DKSJuM392355; Mon, 13 Mar 2006 12:28:24 -0800 (PST) Message-Id: <200603132028.k2DKSJuM392355@jurassic.eng.sun.com> Date: Mon, 13 Mar 2006 10:27:07 -1000 (HST) From: Joseph Kowalski Reply-To: Joseph Kowalski Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: Joseph.Kowalski@eng.sun.com, Casper.Dik@Sun.COM Cc: Craig.Mohrman@eng.sun.com, Joseph.Kowalski@Sun.COM, sommerfeld@Sun.COM, Craig.Mohrman@Sun.COM, Ed.Gould@Sun.COM, Nicolas.Williams@Sun.COM, Don.Cragun@Sun.COM, Michael.Shapiro@Sun.COM, PSARC@sac.sfbay.sun.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: ryb0h4q/RdEzR5RmQDLtiA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.7_20 SunOS 5.11 i86pc i386 Status: RO Content-Length: 121 > That way is adding a specific function call to the program. Opps. Forgot about that. Sorry for the noise. - jek3 From sacadmin Wed Mar 15 15:34:10 2006 Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id k2FNYAIQ009310 for ; Wed, 15 Mar 2006 15:34:10 -0800 (PST) Received: from spartan.SFBay.Sun.COM (spartan.SFBay.Sun.COM [129.146.226.64]) by spartan.SFBay.Sun.COM (8.12.10+Sun/8.12.10) with SMTP id k2FNY9JN029521; Wed, 15 Mar 2006 15:34:09 -0800 (PST) Message-Id: <200603152334.k2FNY9JN029521@spartan.SFBay.Sun.COM> Date: Wed, 15 Mar 2006 15:34:09 -0800 (PST) From: Don Cragun Reply-To: Don Cragun Subject: Re: Extended FILE space for 32-bit Solaris processes [PSARC/2006/162 Timeout: 03/15/2006] To: PSARC@sac.sfbay.sun.com Cc: casper.dik@Sun.COM, craig.mohrman@Sun.COM, michael.shapiro@Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: R2OCaZBGIHZ1TrxVHxxgIA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.5 SunOS 5.9 sun4u sparc Status: RO Content-Length: 302 Given that: 1. no new issues have been raised since the spec update on Friday, 2. both ARC members who stated that they might derail have agreed that the case is OK as a fast-track with the current spec, and 3. the timer has expired, I have marked this case closed approved 03/15/2006. - Don