From blu@sac.sfbay.sun.com Fri Jun 12 05:26:25 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5CCQOZv009929 for ; Fri, 12 Jun 2009 05:26:24 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n5CCQM8f004335; Fri, 12 Jun 2009 20:26:23 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KL400A03L7V2700@brm-avmta-1.central.sun.com>; Fri, 12 Jun 2009 06:26:19 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL40084KL7VS810@brm-avmta-1.central.sun.com>; Fri, 12 Jun 2009 06:26:19 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5CCQInh043072; Fri, 12 Jun 2009 05:26:18 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5CCQGmd009923; Fri, 12 Jun 2009 05:26:16 -0700 (PDT) Received: (from blu@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n5CCQGBE009919; Fri, 12 Jun 2009 05:26:16 -0700 (PDT) Date: Fri, 12 Jun 2009 05:26:16 -0700 (PDT) From: Brian Utterback Subject: Abandon the use of snapshots in mntfs. [PSARC/2009/352 FastTrack timeout 06/19/2009] To: PSARC-ext@sun.com Cc: Robert.Harris@sun.com Message-id: <200906121226.n5CCQGBE009919@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 17744 I am sponsoring this fasttrack on behalf of Robert Harris. The timeout is set to 06/19/2009. Requested binding is patch. Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Abandon the use of snapshots in mntfs. 1.2. Name of Document Author/Supplier: Author: Robert Harris 1.3 Date of This Document: 12 June, 2009 4. Technical Description 1. Proposal: Abandon the use of snapshots in mntfs. 2. The Problem: The contents of /etc/mnttab are created by mntfs on demand. mntfs parses the in-kernel mnttab structures to create a snapshot that can be used to satisfy subsequent calls to read() or ioctl(). The snapshot is stored by the kernel within the address space of the process that made the first call to read() or ioctl(). The enclosing mapping is removed from the calling process's address space by mntfs on last close(). The snapshot-in-userland design has a flaw: the kernel cannot determine whether or not a close() is a specific process's last if the vnode count is greater than 1. This is because there is no way to determine whether a count that is greater than one has originated from dup(), from fork() or from both. This means that mntfs is unable to ensure that every insertion of a mapping into a process's address space is paired with a corresponding deletion. Two specific manifestations are 6394241, in which a newly-execed process has an arbitrary range of its address space unmapped by mntfs, and 6813502, in which a process address space is entirely consumed by orphaned mappings left behind by mntfs. 3. Solutions: The most obvious solution seemed, at first, to involve storing the snapshot data within the corresponding vnode, thereby allowing the existing file system infrastructure to free the resources when no longer required. This, however, was rejected on account of complications inherent in the unprivileged user's resulting ability to allocate and retain kernel memory. The only choice left has been to abandon the use of snapshots in their current form. This necessitates some minor changes to the behaviour of /etc/mnttab and its API, described in mnttab(4) and getmntent(3C). The current snapshot implementation means that, until a call to close() or resetmnttab(), clients reading /etc/mnttab will see those resources that were mounted at the time the snapshot was created, i.e. at the first read() or ioctl(). Thus resources that have been unmounted in the intervening time will still appear to be present. With the proposed changes, a process will not see any resources that have been unmounted since the first call to read() or ioctl(), with one exception: if a call to read() terminates in the middle of a line, then the next read() will be obliged to consume the remainder of that line, even if the corresponding resource has been unmounted in the intervening time. This prevents the possibility of seemingly-garbled text. Note that where the remainder of a line is stored for possible later consumption, it is kept on the corresponding vnode's private structure. 4. Impact: 4.1 Overview: The current API includes an ioctl for obtaining the number of mounted resources within the snapshot (MNTIOC_NMNTS) and another ioctl for obtaining the major and minor numbers for these resources (MNTIOC_GETDEVLIST). The first ioctl is used to obtain the size of an array to pass to the second ioctl. Following the proposed changes, MNTIOC_NMNTS will return the number of resources currently mounted by the kernel. However, many of the mounted resources are usually hidden; they never appear during a read() of /etc/mnttab, and are visible to ioctl() only when specifically requested. The value returned by MNTIOC_NMNTS will therefore be viewed by the majority of consumers as an over-estimate of the number of mounted resources. In reality, the value obtained by MNTIOC_NMNTS will be defined as the upper-limit on the number of mounted resources, and should be used only to determine the length of the array passed to MNTIOC_GETDEVLIST. MNTIOC_GETDEVLIST will, following the proposed changes, populate the supplied array with the major and minor numbers of only those mouted resources that are visible to the user. Typically, hence, this will leave many entries in the supplied array undefined. With the proposed changes, the MNTIOC_GETDEVLIST ioctl() itself will return the number of mounted resources, and hence the number of meaningful entries in the supplied array. In the current mntfs implementation, an ioctl() for MNTIOC_GETDEVLIST does not employ its return value for anything other than to indicate an error. In theory, then, this change introduces a backwards incompatability: existing code that uses MNTIOC_NMNTS and then MNTIOC_GETDEVLIST to obtain the major and minor numbers of mounted resources will find that the last entries are meaningless. However, MNTIOC_GETDEVLIST has not worked since S10 FCS: it now returns nonsense, as described in 6814666. Implementing the proposed changes calls for additions to the zone_t and vfs_t structs. The zone_t will acquire a pointer to an avl_tree_t, and the vfs_t will acquire a pointer to a newly-defined structure. The purpose is to allow each vfs_t to be stored in an AVL tree, sorted by a unique high-resolution time. This is to allow rapid location of the next available vfs_t in the mnttab table. If its predecessor were unmounted then there would be no vfs_next pointer to follow, and a linear search would otherwise be required from the start of the circularly-linked list. 4.2 Interface changes: 1. The MNTIOC_GETDEVLIST command is modified so that the calling ioctl() returns the number of mounted resources represented in the supplied array, which is the same as the number of visible resources mounted on the system. This interface will be Uncommitted. 2. The vfs struct acquires a new member, vfs_mntmeta, which is a pointer to a new, private structure with type 'struct vfs_mntmeta'. The new member and the private structure will constitute a Private interface. 3. The zone struct acquires a new member, zone_vfstree, which is a pointer to an avl_tree_t. The new member will constitute a Private interface. 5. Release binding: Patch. 6. Documentation impact: Changes to the mnttab(4) and getmntent(3C) man pages: *** mnttab.old Thu Jun 11 14:40:19 2009 --- mnttab.new Thu Jun 11 14:38:09 2009 *************** *** 47,66 **** IOCTLS The following ioctl(2) calls are supported: ! MNTIOC_NMNTS Returns the count of mounted resources ! in the current snapshot in the uint32_t ! pointed to by arg. ! MNTIOC_GETDEVLIST Returns an array of uint32_t's that is ! twice as long as the length returned by ! MNTIOC_NMNTS. Each pair of numbers is ! the major and minor device number for ! the file system at the corresponding ! line in the current /etc/mnttab ! snapshot. arg points to the memory ! buffer to receive the device number ! information. MNTIOC_SETTAG Sets a tag word into the options list for a mounted file system. A tag is a notation that will appear in the --- 47,87 ---- IOCTLS The following ioctl(2) calls are supported: ! MNTIOC_NMNTS Obtains the upper limit on the number ! of mounted resources. arg points to a ! uint32_t; this will be set to the upper ! limit on the number of mounted ! resources that will be identified by a ! subsequent MNTIOC_GETDEVLIST. ! MNTIOC_GETDEVLIST Obtains the actual number of mounted ! resources, together with their major ! and minor numbers. arg points to an ! array of uint_ts that must be at least ! twice as long as the length obtained by ! MNTIOC_NMNTS. The array will contain a ! pair of numbers for each mounted ! resource, comprising its major and ! minor numbers. + A resource will not be represented in + the array if it was mounted after the + preceding MNTIOC_NMNTS command. It is + an error to use MNTIOC_GETDEVLIST + without having first used MNTIOC_NMNTS. + + The number of mounted resources actu- + ally represented in the array will be + returned by the call to ioctl() itself. + The values of any remaining elements of + the array are undefined. + + A process that has used either + MNTIOC_NMNTS or MNTIOC_GETDEVLIST must + call resetmnttab(3C) before + getmntent(3C), getextmntent(3C) or + getmntany(3C). + MNTIOC_SETTAG Sets a tag word into the options list for a mounted file system. A tag is a notation that will appear in the *************** *** 101,109 **** location. EINVAL The tag specified in a MNTIOC_SETTAG call ! already exists as a file system option, or ! the tag specified in a MNTIOC_CLRTAG call ! does not exist. ENAMETOOLONG The tag specified in a MNTIOC_SETTAG call is too long or the tag would make the total --- 122,132 ---- location. EINVAL The tag specified in a MNTIOC_SETTAG call ! already exists as a file system option, the ! tag specified in a MNTIOC_CLRTAG call does ! not exist or a request for MNTIOC_GETDEVLIST ! was made without a prior request for ! MNTIOC_NMNTS. ENAMETOOLONG The tag specified in a MNTIOC_SETTAG call is too long or the tag would make the total *************** *** 144,156 **** ments. NOTES ! The snapshot of the mnttab information is taken any time a ! read(2) is performed at offset 0 (the beginning) of the ! mnttab file. The file modification time returned by stat(2) ! for the mnttab file is the time of the last change to ! mounted file system information. A poll(2) system call ! requesting a POLLRDBAND event can be used to block and wait ! for the system's mounted file system information to be dif- ! ferent from the most recent snapshot since the mnttab file ! was opened. --- 167,204 ---- ments. NOTES ! During a call to read(2) of /etc/mnttab, the corresponding ! in-kernel information cannot change. However, it will do so ! between successive calls to read(2) if, for example, ! resources are unmounted. The underlying file system, mntfs, ! implements two features to ensure that /etc/mnttab will con- ! tain sensible data even if there are changes to the in- ! kernel table of mounted resources. ! ! Firstly, if a call to read(2) terminates only part of the ! way through a line, then the next call to read(2) will start ! by reading the remainder of the interrupted line, even if ! the corresponding resource has been unmounted in the inter- ! vening time. ! ! Secondly, successive calls to read(2) will return 0 after ! reading the newest resource that was mounted at the time of ! the first call to read(2), even if, in the intervening time, ! additional resources have been mounted and are still ! present. ! ! Following a rewind(3C) of /etc/mnttab, or a call to ! resetmnttab(3C), the next call to read(2) will be considered ! the first: any saved remainder will be discarded and all ! resources mounted at that time are eligible to be read by ! subsequent calls to read(2). /etc/mnttab does not support ! the use of a file offset for any purpose other than rewind- ! ing the file. ! ! The file modification time returned by stat(2) for the ! mnttab file is the time of the last change to mounted file ! system information. A poll(2) system call requesting a ! POLLRDBAND event can be used to block and wait for the ! system's mounted file system information to be different ! from that at the time of the first read(2) of mnttab. *** getmntent.old Thu Jun 11 14:37:35 2009 --- getmntent.new Thu Jun 11 14:41:24 2009 *************** *** 40,51 **** Each getmntent() call causes a new line to be read from the mnttab file. Successive calls can be used to search the ! entire list. The getmntany() function searches the file ! referenced by fp until a match is found between a line in ! the file and mpref. A match occurs if all non-null entries ! in mpref match the corresponding fields in the file. These ! functions do not open, close, or rewind the file. getextmntent() The getextmntent() function is an extended version of the getmntent() function that returns, in addition to the infor- --- 40,58 ---- Each getmntent() call causes a new line to be read from the mnttab file. Successive calls can be used to search the ! entire list, although mnttab entries added by the kernel ! after the first call to getmntent() will be ignored. Follow- ! ing a call to resetmnttab(), the next call to getmntent() ! will be considered the first: all resources mounted at that ! time will be eligible to be read by subsequent calls to ! getmntent(). + The getmntany() function searches the file referenced by fp + until a match is found between a line in the file and mpref. + A match occurs if all non-null entries in mpref match the + corresponding fields in the file. These functions do not + open, close, or rewind the file. + getextmntent() The getextmntent() function is an extended version of the getmntent() function that returns, in addition to the infor- *************** *** 53,63 **** of the mounted resource to which the line in mnttab corresponds. The getextmntent() function also fills in the extmntent structure defined in the header. ! For getextmntent() to function properly, it must be notified ! when the mnttab file has been reopened or rewound since a ! previous getextmntent() call. This notification is accom- ! plished by calling resetmnttab(). Otherwise, it behaves ! exactly as getmntent() described above. The data pointed to by the mnttab structure members are stored in a static area and must be copied to be saved --- 60,67 ---- of the mounted resource to which the line in mnttab corresponds. The getextmntent() function also fills in the extmntent structure defined in the header. ! Otherwise, it behaves exactly as getmntent() described ! above. The data pointed to by the mnttab structure members are stored in a static area and must be copied to be saved *************** *** 77,89 **** sition purposes. resetmnttab() ! The resetmnttab() function notifies getextmntent() to reload ! from the kernel the device information that corresponds to ! the new snapshot of the mnttab information (see mnttab(4)). ! Subsequent getextmntent() calls then return correct ! extmnttab information. This function should be called when- ! ever the mnttab file is either rewound or closed and reo- ! pened before any calls are made to getextmntent(). RETURN VALUES getmntent() and getmntany() --- 81,91 ---- sition purposes. resetmnttab() ! The resetmnttab() function causes the next call to ! getmntent(), getextmntent() or getmntany() to behave as ! though /etc/mnttab had just been opened. In addition, this ! function will have a similar effect on read(2); see ! mnttab(4) for more details. RETURN VALUES getmntent() and getmntany() 7. References: 1. CR 6394241 mntfs is not exec safe 2. CR 6813502 mntfs will leak mappings when called from a forking MT program. 3. CR 6814666 MNTIOC_GETDEVLIST produces nonsense 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.6. ARC Exposure: open From gdamore@sun.com Fri Jun 12 07:14:14 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5CEED7b013820 for ; Fri, 12 Jun 2009 07:14:13 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n5CEEA5d027852 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 12 Jun 2009 22:14:12 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KL400K2JQ7NOM00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 12 Jun 2009 08:14:11 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL4008KJQ72S8B0@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 12 Jun 2009 08:13:51 -0600 (MDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5CEDoIB027091 for ; Fri, 12 Jun 2009 07:13:50 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KL400600PXOSB00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 12 Jun 2009 07:13:50 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KL4006XCQ724710@fe-sfbay-10.sun.com>; Fri, 12 Jun 2009 07:13:50 -0700 (PDT) Date: Fri, 12 Jun 2009 07:13:50 -0700 From: "Garrett D'Amore" Subject: Re: Abandon the use of snapshots in mntfs. [PSARC/2009/352 FastTrack timeout 06/19/2009] In-reply-to: <200906121226.n5CCQGBE009919@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: Brian Utterback Cc: PSARC-ext@sun.com, Robert.Harris@sun.com Message-id: <4A32629E.9090601@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906121226.n5CCQGBE009919@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 18577 +1. -- Garrett Brian Utterback wrote: > I am sponsoring this fasttrack on behalf of Robert Harris. The > timeout is set to 06/19/2009. Requested binding is patch. > > Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI > This information is Copyright 2009 Sun Microsystems > 1. Introduction > 1.1. Project/Component Working Name: > Abandon the use of snapshots in mntfs. > 1.2. Name of Document Author/Supplier: > Author: Robert Harris > 1.3 Date of This Document: > 12 June, 2009 > 4. Technical Description > 1. Proposal: > > Abandon the use of snapshots in mntfs. > > > 2. The Problem: > > The contents of /etc/mnttab are created by mntfs on demand. > mntfs parses the in-kernel mnttab structures to create a > snapshot that can be used to satisfy subsequent calls to > read() or ioctl(). The snapshot is stored by the kernel > within the address space of the process that made the first > call to read() or ioctl(). The enclosing mapping is removed > from the calling process's address space by mntfs on last > close(). > > The snapshot-in-userland design has a flaw: the kernel cannot > determine whether or not a close() is a specific process's > last if the vnode count is greater than 1. This is because > there is no way to determine whether a count that is greater > than one has originated from dup(), from fork() or from > both. > > This means that mntfs is unable to ensure that every > insertion of a mapping into a process's address space is > paired with a corresponding deletion. Two specific > manifestations are 6394241, in which a newly-execed process > has an arbitrary range of its address space unmapped by > mntfs, and 6813502, in which a process address space is > entirely consumed by orphaned mappings left behind by mntfs. > > > 3. Solutions: > > The most obvious solution seemed, at first, to involve > storing the snapshot data within the corresponding vnode, > thereby allowing the existing file system infrastructure to > free the resources when no longer required. This, however, > was rejected on account of complications inherent in the > unprivileged user's resulting ability to allocate and retain > kernel memory. > > The only choice left has been to abandon the use of snapshots > in their current form. This necessitates some minor changes > to the behaviour of /etc/mnttab and its API, described in > mnttab(4) and getmntent(3C). > > The current snapshot implementation means that, until a call > to close() or resetmnttab(), clients reading /etc/mnttab will > see those resources that were mounted at the time the > snapshot was created, i.e. at the first read() or ioctl(). > Thus resources that have been unmounted in the intervening > time will still appear to be present. > > With the proposed changes, a process will not see any > resources that have been unmounted since the first call to > read() or ioctl(), with one exception: if a call to read() > terminates in the middle of a line, then the next read() will > be obliged to consume the remainder of that line, even if the > corresponding resource has been unmounted in the intervening > time. This prevents the possibility of seemingly-garbled > text. > > Note that where the remainder of a line is stored for > possible later consumption, it is kept on the corresponding > vnode's private structure. > > > 4. Impact: > > 4.1 Overview: > > The current API includes an ioctl for obtaining the number of > mounted resources within the snapshot (MNTIOC_NMNTS) and > another ioctl for obtaining the major and minor numbers for > these resources (MNTIOC_GETDEVLIST). The first ioctl is used > to obtain the size of an array to pass to the second ioctl. > > Following the proposed changes, MNTIOC_NMNTS will return the > number of resources currently mounted by the kernel. > However, many of the mounted resources are usually hidden; > they never appear during a read() of /etc/mnttab, and are > visible to ioctl() only when specifically requested. The > value returned by MNTIOC_NMNTS will therefore be viewed by > the majority of consumers as an over-estimate of the number > of mounted resources. In reality, the value obtained by > MNTIOC_NMNTS will be defined as the upper-limit on the number > of mounted resources, and should be used only to determine > the length of the array passed to MNTIOC_GETDEVLIST. > > MNTIOC_GETDEVLIST will, following the proposed changes, > populate the supplied array with the major and minor > numbers of only those mouted resources that are > visible to the user. Typically, hence, this will leave > many entries in the supplied array undefined. With > the proposed changes, the MNTIOC_GETDEVLIST ioctl() > itself will return the number of mounted resources, > and hence the number of meaningful entries in the > supplied array. In the current mntfs implementation, > an ioctl() for MNTIOC_GETDEVLIST does not employ > its return value for anything other than to indicate > an error. > > In theory, then, this change introduces a backwards > incompatability: existing code that uses MNTIOC_NMNTS and > then MNTIOC_GETDEVLIST to obtain the major and minor numbers > of mounted resources will find that the last entries are > meaningless. However, MNTIOC_GETDEVLIST has not worked since > S10 FCS: it now returns nonsense, as described in 6814666. > > Implementing the proposed changes calls for additions to the > zone_t and vfs_t structs. The zone_t will acquire a pointer > to an avl_tree_t, and the vfs_t will acquire a pointer to a > newly-defined structure. The purpose is to allow each vfs_t > to be stored in an AVL tree, sorted by a unique > high-resolution time. This is to allow rapid location of the > next available vfs_t in the mnttab table. If its predecessor > were unmounted then there would be no vfs_next pointer to > follow, and a linear search would otherwise be required from > the start of the circularly-linked list. > > 4.2 Interface changes: > > 1. The MNTIOC_GETDEVLIST command is modified so that the > calling ioctl() returns the number of mounted resources > represented in the supplied array, which is the same > as the number of visible resources mounted on the system. > This interface will be Uncommitted. > > 2. The vfs struct acquires a new member, vfs_mntmeta, which > is a pointer to a new, private structure with type > 'struct vfs_mntmeta'. The new member and the private > structure will constitute a Private interface. > > 3. The zone struct acquires a new member, zone_vfstree, > which is a pointer to an avl_tree_t. The new member > will constitute a Private interface. > > > 5. Release binding: > > Patch. > > > 6. Documentation impact: > > Changes to the mnttab(4) and getmntent(3C) man pages: > > *** mnttab.old Thu Jun 11 14:40:19 2009 > --- mnttab.new Thu Jun 11 14:38:09 2009 > *************** > *** 47,66 **** > IOCTLS > The following ioctl(2) calls are supported: > > ! MNTIOC_NMNTS Returns the count of mounted resources > ! in the current snapshot in the uint32_t > ! pointed to by arg. > > ! MNTIOC_GETDEVLIST Returns an array of uint32_t's that is > ! twice as long as the length returned by > ! MNTIOC_NMNTS. Each pair of numbers is > ! the major and minor device number for > ! the file system at the corresponding > ! line in the current /etc/mnttab > ! snapshot. arg points to the memory > ! buffer to receive the device number > ! information. > > MNTIOC_SETTAG Sets a tag word into the options list > for a mounted file system. A tag is a > notation that will appear in the > --- 47,87 ---- > IOCTLS > The following ioctl(2) calls are supported: > > ! MNTIOC_NMNTS Obtains the upper limit on the number > ! of mounted resources. arg points to a > ! uint32_t; this will be set to the upper > ! limit on the number of mounted > ! resources that will be identified by a > ! subsequent MNTIOC_GETDEVLIST. > > ! MNTIOC_GETDEVLIST Obtains the actual number of mounted > ! resources, together with their major > ! and minor numbers. arg points to an > ! array of uint_ts that must be at least > ! twice as long as the length obtained by > ! MNTIOC_NMNTS. The array will contain a > ! pair of numbers for each mounted > ! resource, comprising its major and > ! minor numbers. > > + A resource will not be represented in > + the array if it was mounted after the > + preceding MNTIOC_NMNTS command. It is > + an error to use MNTIOC_GETDEVLIST > + without having first used MNTIOC_NMNTS. > + > + The number of mounted resources actu- > + ally represented in the array will be > + returned by the call to ioctl() itself. > + The values of any remaining elements of > + the array are undefined. > + > + A process that has used either > + MNTIOC_NMNTS or MNTIOC_GETDEVLIST must > + call resetmnttab(3C) before > + getmntent(3C), getextmntent(3C) or > + getmntany(3C). > + > MNTIOC_SETTAG Sets a tag word into the options list > for a mounted file system. A tag is a > notation that will appear in the > *************** > *** 101,109 **** > location. > > EINVAL The tag specified in a MNTIOC_SETTAG call > ! already exists as a file system option, or > ! the tag specified in a MNTIOC_CLRTAG call > ! does not exist. > > ENAMETOOLONG The tag specified in a MNTIOC_SETTAG call is > too long or the tag would make the total > --- 122,132 ---- > location. > > EINVAL The tag specified in a MNTIOC_SETTAG call > ! already exists as a file system option, the > ! tag specified in a MNTIOC_CLRTAG call does > ! not exist or a request for MNTIOC_GETDEVLIST > ! was made without a prior request for > ! MNTIOC_NMNTS. > > ENAMETOOLONG The tag specified in a MNTIOC_SETTAG call is > too long or the tag would make the total > *************** > *** 144,156 **** > ments. > > NOTES > ! The snapshot of the mnttab information is taken any time a > ! read(2) is performed at offset 0 (the beginning) of the > ! mnttab file. The file modification time returned by stat(2) > ! for the mnttab file is the time of the last change to > ! mounted file system information. A poll(2) system call > ! requesting a POLLRDBAND event can be used to block and wait > ! for the system's mounted file system information to be dif- > ! ferent from the most recent snapshot since the mnttab file > ! was opened. > > --- 167,204 ---- > ments. > > NOTES > ! During a call to read(2) of /etc/mnttab, the corresponding > ! in-kernel information cannot change. However, it will do so > ! between successive calls to read(2) if, for example, > ! resources are unmounted. The underlying file system, mntfs, > ! implements two features to ensure that /etc/mnttab will con- > ! tain sensible data even if there are changes to the in- > ! kernel table of mounted resources. > ! > ! Firstly, if a call to read(2) terminates only part of the > ! way through a line, then the next call to read(2) will start > ! by reading the remainder of the interrupted line, even if > ! the corresponding resource has been unmounted in the inter- > ! vening time. > ! > ! Secondly, successive calls to read(2) will return 0 after > ! reading the newest resource that was mounted at the time of > ! the first call to read(2), even if, in the intervening time, > ! additional resources have been mounted and are still > ! present. > ! > ! Following a rewind(3C) of /etc/mnttab, or a call to > ! resetmnttab(3C), the next call to read(2) will be considered > ! the first: any saved remainder will be discarded and all > ! resources mounted at that time are eligible to be read by > ! subsequent calls to read(2). /etc/mnttab does not support > ! the use of a file offset for any purpose other than rewind- > ! ing the file. > ! > ! The file modification time returned by stat(2) for the > ! mnttab file is the time of the last change to mounted file > ! system information. A poll(2) system call requesting a > ! POLLRDBAND event can be used to block and wait for the > ! system's mounted file system information to be different > ! from that at the time of the first read(2) of mnttab. > > > *** getmntent.old Thu Jun 11 14:37:35 2009 > --- getmntent.new Thu Jun 11 14:41:24 2009 > *************** > *** 40,51 **** > > Each getmntent() call causes a new line to be read from the > mnttab file. Successive calls can be used to search the > ! entire list. The getmntany() function searches the file > ! referenced by fp until a match is found between a line in > ! the file and mpref. A match occurs if all non-null entries > ! in mpref match the corresponding fields in the file. These > ! functions do not open, close, or rewind the file. > > getextmntent() > The getextmntent() function is an extended version of the > getmntent() function that returns, in addition to the infor- > --- 40,58 ---- > > Each getmntent() call causes a new line to be read from the > mnttab file. Successive calls can be used to search the > ! entire list, although mnttab entries added by the kernel > ! after the first call to getmntent() will be ignored. Follow- > ! ing a call to resetmnttab(), the next call to getmntent() > ! will be considered the first: all resources mounted at that > ! time will be eligible to be read by subsequent calls to > ! getmntent(). > > + The getmntany() function searches the file referenced by fp > + until a match is found between a line in the file and mpref. > + A match occurs if all non-null entries in mpref match the > + corresponding fields in the file. These functions do not > + open, close, or rewind the file. > + > getextmntent() > The getextmntent() function is an extended version of the > getmntent() function that returns, in addition to the infor- > *************** > *** 53,63 **** > of the mounted resource to which the line in mnttab > corresponds. The getextmntent() function also fills in the > extmntent structure defined in the header. > ! For getextmntent() to function properly, it must be notified > ! when the mnttab file has been reopened or rewound since a > ! previous getextmntent() call. This notification is accom- > ! plished by calling resetmnttab(). Otherwise, it behaves > ! exactly as getmntent() described above. > > The data pointed to by the mnttab structure members are > stored in a static area and must be copied to be saved > --- 60,67 ---- > of the mounted resource to which the line in mnttab > corresponds. The getextmntent() function also fills in the > extmntent structure defined in the header. > ! Otherwise, it behaves exactly as getmntent() described > ! above. > > The data pointed to by the mnttab structure members are > stored in a static area and must be copied to be saved > *************** > *** 77,89 **** > sition purposes. > > resetmnttab() > ! The resetmnttab() function notifies getextmntent() to reload > ! from the kernel the device information that corresponds to > ! the new snapshot of the mnttab information (see mnttab(4)). > ! Subsequent getextmntent() calls then return correct > ! extmnttab information. This function should be called when- > ! ever the mnttab file is either rewound or closed and reo- > ! pened before any calls are made to getextmntent(). > > RETURN VALUES > getmntent() and getmntany() > --- 81,91 ---- > sition purposes. > > resetmnttab() > ! The resetmnttab() function causes the next call to > ! getmntent(), getextmntent() or getmntany() to behave as > ! though /etc/mnttab had just been opened. In addition, this > ! function will have a similar effect on read(2); see > ! mnttab(4) for more details. > > RETURN VALUES > getmntent() and getmntany() > > > 7. References: > > 1. CR 6394241 mntfs is not exec safe > > 2. CR 6813502 mntfs will leak mappings when called from a forking MT program. > > 3. CR 6814666 MNTIOC_GETDEVLIST produces nonsense > > 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.6. ARC Exposure: open > > From glenn.skinner@sun.com Fri Jun 12 10:01:52 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5CH1qjb020275 for ; Fri, 12 Jun 2009 10:01:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5CH1pu6010419; Fri, 12 Jun 2009 10:01:51 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KL40050DXZ3X300@nwk-avmta-1.sfbay.Sun.COM>; Fri, 12 Jun 2009 10:01:51 -0700 (PDT) Received: from ivrel.sfbay.sun.com ([129.146.74.76]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL4007DTXZ37CF0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 12 Jun 2009 10:01:51 -0700 (PDT) Received: from ivrel (ivrel [129.146.74.76]) by ivrel.sfbay.sun.com (8.13.8+Sun/8.13.8) with SMTP id n5CH1otM012509; Fri, 12 Jun 2009 10:01:50 -0700 (PDT) Date: Fri, 12 Jun 2009 10:01:50 -0700 (PDT) From: Glenn Skinner Subject: Re: 2009/352 [Abandon the use of snapshots in mntfs] To: PSARC-ext@sun.com, blu@sac.sfbay.sun.com Cc: Robert.Harris@sun.com Reply-to: Glenn Skinner Message-id: <200906121701.n5CH1otM012509@ivrel.sfbay.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.6_36 SunOS 5.11 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: pcl/fuDNXyLA8G+twKbHAA== X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 1160 Date: Fri, 12 Jun 2009 05:26:16 -0700 (PDT) From: Brian Utterback Subject: Abandon the use of snapshots in mntfs. [PSARC/2009/352 FastTrack timeout 06/19/2009] I am sponsoring this fasttrack on behalf of Robert Harris. The timeout is set to 06/19/2009. Requested binding is patch. ... 4.2 Interface changes: 1. The MNTIOC_GETDEVLIST command is modified so that the calling ioctl() returns the number of mounted resources represented in the supplied array, which is the same as the number of visible resources mounted on the system. This interface will be Uncommitted. 2. The vfs struct acquires a new member, vfs_mntmeta, which is a pointer to a new, private structure with type 'struct vfs_mntmeta'. The new member and the private structure will constitute a Private interface. 3. The zone struct acquires a new member, zone_vfstree, which is a pointer to an avl_tree_t. The new member will constitute a Private interface. By "Private" in the last two of these, do you really mean "Consolidation Private"? If so, I'll add my +1 to Garrett's. -- Glenn From Robert.Harris@sun.com Fri Jun 12 11:20:56 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5CIKtLX023664 for ; Fri, 12 Jun 2009 11:20:56 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5CIKepg002887 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 12 Jun 2009 19:20:55 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KL5004031MU7Q00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 12 Jun 2009 11:20:54 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KL5001WF1MSN320@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 12 Jun 2009 11:20:53 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5CIKk9Z010982; Fri, 12 Jun 2009 18:20:46 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KL5001001D1AB00@fe-emea-10.sun.com>; Fri, 12 Jun 2009 19:20:46 +0100 (BST) Received: from [192.168.0.100] (host86-138-178-96.range86-138.btcentralplus.com [86.138.178.96]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KL500MEW1MLAG60@fe-emea-10.sun.com>; Fri, 12 Jun 2009 19:20:46 +0100 (BST) Date: Fri, 12 Jun 2009 19:20:45 +0100 From: Robert Harris Subject: Re: 2009/352 [Abandon the use of snapshots in mntfs] In-reply-to: <200906121701.n5CH1otM012509@ivrel.sfbay.sun.com> Sender: Robert.Harris@sun.com To: Glenn Skinner Cc: PSARC-ext@sun.com, blu@sac.sfbay.sun.com Message-id: <9C34CA13-413C-4F83-AA59-4F6E1FF83666@Sun.COM> MIME-version: 1.0 X-Mailer: Apple Mail (2.935.3) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906121701.n5CH1otM012509@ivrel.sfbay.sun.com> Status: RO Content-Length: 1258 On 12 Jun 2009, at 18:01, Glenn Skinner wrote: > Date: Fri, 12 Jun 2009 05:26:16 -0700 (PDT) > From: Brian Utterback > Subject: Abandon the use of snapshots in mntfs. [PSARC/2009/352 > FastTrack timeout 06/19/2009] > > I am sponsoring this fasttrack on behalf of Robert Harris. The > timeout is set to 06/19/2009. Requested binding is patch. > > ... > 4.2 Interface changes: > > 1. The MNTIOC_GETDEVLIST command is modified so that the > calling ioctl() returns the number of mounted resources > represented in the supplied array, which is the same > as the number of visible resources mounted on the system. > This interface will be Uncommitted. > > 2. The vfs struct acquires a new member, vfs_mntmeta, which > is a pointer to a new, private structure with type > 'struct vfs_mntmeta'. The new member and the private > structure will constitute a Private interface. > > 3. The zone struct acquires a new member, zone_vfstree, > which is a pointer to an avl_tree_t. The new member > will constitute a Private interface. > > By "Private" in the last two of these, do you really mean > "Consolidation Private"? Yes. > If so, I'll add my +1 to Garrett's. Thanks. R From gdamore@sun.com Tue Jun 30 11:22:00 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5UILxKk006020 for ; Tue, 30 Jun 2009 11:22:00 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5UILjnn011792 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Tue, 30 Jun 2009 19:21:58 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KM20020BDO6W000@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 30 Jun 2009 11:21:42 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KM200KIKDO5P770@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 30 Jun 2009 11:21:41 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5UILf7i018885 for ; Tue, 30 Jun 2009 11:21:41 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KM200E00DIGH700@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 30 Jun 2009 11:21:41 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KM2001AIDO57L50@fe-sfbay-09.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Tue, 30 Jun 2009 11:21:41 -0700 (PDT) Date: Tue, 30 Jun 2009 11:21:41 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/352 Abandon the use of snapshots in mntfs. Sender: Garrett.Damore@sun.com To: PSARC-ext Message-id: <4A4A57B5.9030103@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 88 This case was approved last week at PSARC. I've updated the IAM file. -- Garrett From brian.utterback@Sun.COM Fri Nov 6 08:23:19 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA6GNHdH025000 for ; Fri, 6 Nov 2009 08:23:17 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id nA6GNEnn034148 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 6 Nov 2009 09:23:17 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSP00J1346SQH00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 06 Nov 2009 08:23:16 -0800 (PST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSP00FTQ46RXJ60@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 06 Nov 2009 08:23:15 -0800 (PST) Received: from [129.148.9.81] (sr1-ubur-02.East.Sun.COM [129.148.9.81]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA6GNBGC008578; Fri, 06 Nov 2009 11:23:12 -0500 (EST) Date: Fri, 06 Nov 2009 11:23:11 -0500 From: Brian Utterback Subject: Re: Abandon the use of snapshots in mntfs. [PSARC/2009/352 FastTrack timeout 06/19/2009] In-reply-to: <4A32629E.9090601@sun.com> Cc: Brian Utterback , PSARC-ext@Sun.COM, Robert.Harris@Sun.COM Message-id: <4AF44D6F.3020109@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200906121226.n5CCQGBE009919@sac.sfbay.sun.com> <4A32629E.9090601@sun.com> User-Agent: Thunderbird 2.0.0.24pre (X11/20091028) Status: RO Content-Length: 19801 I little house cleaning. After this case was approved, the project team decided to take a different approach which was submitted and approved in PSARC 2009/566. Since the approach in 2009/352 is no longer valid, I am marking it as withdrawn to avoid future confusion. > Brian Utterback wrote: >> I am sponsoring this fasttrack on behalf of Robert Harris. The >> timeout is set to 06/19/2009. Requested binding is patch. >> Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI >> This information is Copyright 2009 Sun Microsystems >> 1. Introduction >> 1.1. Project/Component Working Name: >> Abandon the use of snapshots in mntfs. >> 1.2. Name of Document Author/Supplier: >> Author: Robert Harris >> 1.3 Date of This Document: >> 12 June, 2009 >> 4. Technical Description >> 1. Proposal: >> >> Abandon the use of snapshots in mntfs. >> >> >> 2. The Problem: >> >> The contents of /etc/mnttab are created by mntfs on demand. >> mntfs parses the in-kernel mnttab structures to create a >> snapshot that can be used to satisfy subsequent calls to >> read() or ioctl(). The snapshot is stored by the kernel >> within the address space of the process that made the first >> call to read() or ioctl(). The enclosing mapping is removed >> from the calling process's address space by mntfs on last >> close(). >> >> The snapshot-in-userland design has a flaw: the kernel cannot >> determine whether or not a close() is a specific process's >> last if the vnode count is greater than 1. This is because >> there is no way to determine whether a count that is greater >> than one has originated from dup(), from fork() or from >> both. >> >> This means that mntfs is unable to ensure that every >> insertion of a mapping into a process's address space is >> paired with a corresponding deletion. Two specific >> manifestations are 6394241, in which a newly-execed process >> has an arbitrary range of its address space unmapped by >> mntfs, and 6813502, in which a process address space is >> entirely consumed by orphaned mappings left behind by mntfs. >> >> >> 3. Solutions: >> >> The most obvious solution seemed, at first, to involve >> storing the snapshot data within the corresponding vnode, >> thereby allowing the existing file system infrastructure to >> free the resources when no longer required. This, however, >> was rejected on account of complications inherent in the >> unprivileged user's resulting ability to allocate and retain >> kernel memory. >> >> The only choice left has been to abandon the use of snapshots >> in their current form. This necessitates some minor changes >> to the behaviour of /etc/mnttab and its API, described in >> mnttab(4) and getmntent(3C). >> >> The current snapshot implementation means that, until a call >> to close() or resetmnttab(), clients reading /etc/mnttab will >> see those resources that were mounted at the time the >> snapshot was created, i.e. at the first read() or ioctl(). >> Thus resources that have been unmounted in the intervening >> time will still appear to be present. >> >> With the proposed changes, a process will not see any >> resources that have been unmounted since the first call to >> read() or ioctl(), with one exception: if a call to read() >> terminates in the middle of a line, then the next read() will >> be obliged to consume the remainder of that line, even if the >> corresponding resource has been unmounted in the intervening >> time. This prevents the possibility of seemingly-garbled >> text. >> >> Note that where the remainder of a line is stored for >> possible later consumption, it is kept on the corresponding >> vnode's private structure. >> >> >> 4. Impact: >> >> 4.1 Overview: >> >> The current API includes an ioctl for obtaining the number of >> mounted resources within the snapshot (MNTIOC_NMNTS) and >> another ioctl for obtaining the major and minor numbers for >> these resources (MNTIOC_GETDEVLIST). The first ioctl is used >> to obtain the size of an array to pass to the second ioctl. >> >> Following the proposed changes, MNTIOC_NMNTS will return the >> number of resources currently mounted by the kernel. >> However, many of the mounted resources are usually hidden; >> they never appear during a read() of /etc/mnttab, and are >> visible to ioctl() only when specifically requested. The >> value returned by MNTIOC_NMNTS will therefore be viewed by >> the majority of consumers as an over-estimate of the number >> of mounted resources. In reality, the value obtained by >> MNTIOC_NMNTS will be defined as the upper-limit on the number >> of mounted resources, and should be used only to determine >> the length of the array passed to MNTIOC_GETDEVLIST. >> >> MNTIOC_GETDEVLIST will, following the proposed changes, >> populate the supplied array with the major and minor >> numbers of only those mouted resources that are >> visible to the user. Typically, hence, this will leave >> many entries in the supplied array undefined. With >> the proposed changes, the MNTIOC_GETDEVLIST ioctl() >> itself will return the number of mounted resources, >> and hence the number of meaningful entries in the >> supplied array. In the current mntfs implementation, >> an ioctl() for MNTIOC_GETDEVLIST does not employ >> its return value for anything other than to indicate >> an error. >> >> In theory, then, this change introduces a backwards >> incompatability: existing code that uses MNTIOC_NMNTS and >> then MNTIOC_GETDEVLIST to obtain the major and minor numbers >> of mounted resources will find that the last entries are >> meaningless. However, MNTIOC_GETDEVLIST has not worked since >> S10 FCS: it now returns nonsense, as described in 6814666. >> >> Implementing the proposed changes calls for additions to the >> zone_t and vfs_t structs. The zone_t will acquire a pointer >> to an avl_tree_t, and the vfs_t will acquire a pointer to a >> newly-defined structure. The purpose is to allow each vfs_t >> to be stored in an AVL tree, sorted by a unique >> high-resolution time. This is to allow rapid location of the >> next available vfs_t in the mnttab table. If its predecessor >> were unmounted then there would be no vfs_next pointer to >> follow, and a linear search would otherwise be required from >> the start of the circularly-linked list. >> >> 4.2 Interface changes: >> >> 1. The MNTIOC_GETDEVLIST command is modified so that the >> calling ioctl() returns the number of mounted resources >> represented in the supplied array, which is the same >> as the number of visible resources mounted on the system. >> This interface will be Uncommitted. >> 2. The vfs struct acquires a new member, vfs_mntmeta, which >> is a pointer to a new, private structure with type >> 'struct vfs_mntmeta'. The new member and the private >> structure will constitute a Private interface. >> 3. The zone struct acquires a new member, zone_vfstree, >> which is a pointer to an avl_tree_t. The new member >> will constitute a Private interface. >> >> >> 5. Release binding: >> >> Patch. >> >> >> 6. Documentation impact: >> >> Changes to the mnttab(4) and getmntent(3C) man pages: >> >> *** mnttab.old Thu Jun 11 14:40:19 2009 >> --- mnttab.new Thu Jun 11 14:38:09 2009 >> *************** >> *** 47,66 **** >> IOCTLS >> The following ioctl(2) calls are supported: >> ! MNTIOC_NMNTS Returns the count of mounted resources >> ! in the current snapshot in the uint32_t >> ! pointed to by arg. >> ! MNTIOC_GETDEVLIST Returns an array of uint32_t's that is >> ! twice as long as the length returned by >> ! MNTIOC_NMNTS. Each pair of numbers is >> ! the major and minor device number for >> ! the file system at the corresponding >> ! line in the current /etc/mnttab >> ! snapshot. arg points to the memory >> ! buffer to receive the device number >> ! information. >> MNTIOC_SETTAG Sets a tag word into the options list >> for a mounted file system. A tag is a >> notation that will appear in the >> --- 47,87 ---- >> IOCTLS >> The following ioctl(2) calls are supported: >> ! MNTIOC_NMNTS Obtains the upper limit on the number >> ! of mounted resources. arg points to a >> ! uint32_t; this will be set to the upper >> ! limit on the number of mounted >> ! resources that will be identified by a >> ! subsequent MNTIOC_GETDEVLIST. >> ! MNTIOC_GETDEVLIST Obtains the actual number of mounted >> ! resources, together with their major >> ! and minor numbers. arg points to an >> ! array of uint_ts that must be at least >> ! twice as long as the length obtained by >> ! MNTIOC_NMNTS. The array will contain a >> ! pair of numbers for each mounted >> ! resource, comprising its major and >> ! minor numbers. >> + A resource will not be represented in >> + the array if it was mounted after the >> + preceding MNTIOC_NMNTS command. It is >> + an error to use MNTIOC_GETDEVLIST >> + without having first used MNTIOC_NMNTS. >> + + The number of mounted resources actu- >> + ally represented in the array will be >> + returned by the call to ioctl() itself. >> + The values of any remaining elements of >> + the array are undefined. >> + + A process that has used either >> + MNTIOC_NMNTS or MNTIOC_GETDEVLIST must >> + call resetmnttab(3C) before >> + getmntent(3C), getextmntent(3C) or >> + getmntany(3C). >> + MNTIOC_SETTAG Sets a tag word into the options list >> for a mounted file system. A tag is a >> notation that will appear in the >> *************** >> *** 101,109 **** >> location. >> EINVAL The tag specified in a MNTIOC_SETTAG call >> ! already exists as a file system option, or >> ! the tag specified in a MNTIOC_CLRTAG call >> ! does not exist. >> ENAMETOOLONG The tag specified in a MNTIOC_SETTAG call is >> too long or the tag would make the total >> --- 122,132 ---- >> location. >> EINVAL The tag specified in a MNTIOC_SETTAG call >> ! already exists as a file system option, the >> ! tag specified in a MNTIOC_CLRTAG call does >> ! not exist or a request for MNTIOC_GETDEVLIST >> ! was made without a prior request for >> ! MNTIOC_NMNTS. >> ENAMETOOLONG The tag specified in a MNTIOC_SETTAG call is >> too long or the tag would make the total >> *************** >> *** 144,156 **** >> ments. >> NOTES >> ! The snapshot of the mnttab information is taken any time a >> ! read(2) is performed at offset 0 (the beginning) of the >> ! mnttab file. The file modification time returned by stat(2) >> ! for the mnttab file is the time of the last change to >> ! mounted file system information. A poll(2) system call >> ! requesting a POLLRDBAND event can be used to block and wait >> ! for the system's mounted file system information to be dif- >> ! ferent from the most recent snapshot since the mnttab file >> ! was opened. >> --- 167,204 ---- >> ments. >> NOTES >> ! During a call to read(2) of /etc/mnttab, the corresponding >> ! in-kernel information cannot change. However, it will do so >> ! between successive calls to read(2) if, for example, >> ! resources are unmounted. The underlying file system, mntfs, >> ! implements two features to ensure that /etc/mnttab will con- >> ! tain sensible data even if there are changes to the in- >> ! kernel table of mounted resources. >> ! ! Firstly, if a call to read(2) terminates only part of the >> ! way through a line, then the next call to read(2) will start >> ! by reading the remainder of the interrupted line, even if >> ! the corresponding resource has been unmounted in the inter- >> ! vening time. >> ! ! Secondly, successive calls to read(2) will return 0 after >> ! reading the newest resource that was mounted at the time of >> ! the first call to read(2), even if, in the intervening time, >> ! additional resources have been mounted and are still >> ! present. >> ! ! Following a rewind(3C) of /etc/mnttab, or a call to >> ! resetmnttab(3C), the next call to read(2) will be considered >> ! the first: any saved remainder will be discarded and all >> ! resources mounted at that time are eligible to be read by >> ! subsequent calls to read(2). /etc/mnttab does not support >> ! the use of a file offset for any purpose other than rewind- >> ! ing the file. >> ! ! The file modification time returned by stat(2) for the >> ! mnttab file is the time of the last change to mounted file >> ! system information. A poll(2) system call requesting a >> ! POLLRDBAND event can be used to block and wait for the >> ! system's mounted file system information to be different >> ! from that at the time of the first read(2) of mnttab. >> >> *** getmntent.old Thu Jun 11 14:37:35 2009 >> --- getmntent.new Thu Jun 11 14:41:24 2009 >> *************** >> *** 40,51 **** >> Each getmntent() call causes a new line to be read from the >> mnttab file. Successive calls can be used to search the >> ! entire list. The getmntany() function searches the file >> ! referenced by fp until a match is found between a line in >> ! the file and mpref. A match occurs if all non-null entries >> ! in mpref match the corresponding fields in the file. These >> ! functions do not open, close, or rewind the file. >> getextmntent() >> The getextmntent() function is an extended version of the >> getmntent() function that returns, in addition to the infor- >> --- 40,58 ---- >> Each getmntent() call causes a new line to be read from the >> mnttab file. Successive calls can be used to search the >> ! entire list, although mnttab entries added by the kernel >> ! after the first call to getmntent() will be ignored. Follow- >> ! ing a call to resetmnttab(), the next call to getmntent() >> ! will be considered the first: all resources mounted at that >> ! time will be eligible to be read by subsequent calls to >> ! getmntent(). >> + The getmntany() function searches the file referenced by fp >> + until a match is found between a line in the file and mpref. >> + A match occurs if all non-null entries in mpref match the >> + corresponding fields in the file. These functions do not >> + open, close, or rewind the file. >> + getextmntent() >> The getextmntent() function is an extended version of the >> getmntent() function that returns, in addition to the infor- >> *************** >> *** 53,63 **** >> of the mounted resource to which the line in mnttab >> corresponds. The getextmntent() function also fills in the >> extmntent structure defined in the header. >> ! For getextmntent() to function properly, it must be notified >> ! when the mnttab file has been reopened or rewound since a >> ! previous getextmntent() call. This notification is accom- >> ! plished by calling resetmnttab(). Otherwise, it behaves >> ! exactly as getmntent() described above. >> The data pointed to by the mnttab structure members are >> stored in a static area and must be copied to be saved >> --- 60,67 ---- >> of the mounted resource to which the line in mnttab >> corresponds. The getextmntent() function also fills in the >> extmntent structure defined in the header. >> ! Otherwise, it behaves exactly as getmntent() described >> ! above. >> The data pointed to by the mnttab structure members are >> stored in a static area and must be copied to be saved >> *************** >> *** 77,89 **** >> sition purposes. >> resetmnttab() >> ! The resetmnttab() function notifies getextmntent() to reload >> ! from the kernel the device information that corresponds to >> ! the new snapshot of the mnttab information (see mnttab(4)). >> ! Subsequent getextmntent() calls then return correct >> ! extmnttab information. This function should be called when- >> ! ever the mnttab file is either rewound or closed and reo- >> ! pened before any calls are made to getextmntent(). >> RETURN VALUES >> getmntent() and getmntany() >> --- 81,91 ---- >> sition purposes. >> resetmnttab() >> ! The resetmnttab() function causes the next call to >> ! getmntent(), getextmntent() or getmntany() to behave as >> ! though /etc/mnttab had just been opened. In addition, this >> ! function will have a similar effect on read(2); see >> ! mnttab(4) for more details. >> RETURN VALUES >> getmntent() and getmntany() >> >> >> 7. References: >> >> 1. CR 6394241 mntfs is not exec safe >> >> 2. CR 6813502 mntfs will leak mappings when called from a forking MT >> program. >> >> 3. CR 6814666 MNTIOC_GETDEVLIST produces nonsense >> >> 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.6. ARC Exposure: open >> >> > -- blu It's bad civic hygiene to build technologies that could someday be used to facilitate a police state. - Bruce Schneier ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom From gww@eng.sun.com Fri Nov 6 09:09:02 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA6H91Yw025948 for ; Fri, 6 Nov 2009 09:09:02 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id nA6H8wbD000265 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Sat, 7 Nov 2009 01:09:00 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSP00M0H6AZGL00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 06 Nov 2009 09:08:59 -0800 (PST) Received: from dm-eng-02.sfbay.sun.com ([129.146.11.32]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSP00FRU6AZX870@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 06 Nov 2009 09:08:59 -0800 (PST) Received: from marduk.eng.sun.com (marduk.SFBay.Sun.COM [129.146.108.224]) by dm-eng-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA6H8vbl000854; Fri, 06 Nov 2009 09:08:57 -0800 (PST) Received: from marduk.eng.sun.com (localhost [127.0.0.1]) by marduk.eng.sun.com (8.13.6+Sun/8.12.11) with ESMTP id nA6H8omN002211; Fri, 06 Nov 2009 09:08:50 -0800 (PST) Received: (from gww@localhost) by marduk.eng.sun.com (8.13.6+Sun/8.12.11/Submit) id nA6H8oxX002210; Fri, 06 Nov 2009 09:08:50 -0800 (PST) Date: Fri, 06 Nov 2009 09:08:50 -0800 (PST) From: Gary Winiger Subject: Re: Abandon the use of snapshots in mntfs. [PSARC/2009/352 FastTrack timeout 06/19/2009] To: brian.utterback@sun.com Cc: blu@sac.sfbay.sun.com, PSARC-ext@sun.com, Robert.Harris@sun.com Message-id: <200911061708.nA6H8oxX002210@marduk.eng.sun.com> Content-transfer-encoding: 7BIT X-Sun-Charset: US-ASCII X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 336 Brian, > I little house cleaning. After this case was approved, the project > team decided to take a different approach which was submitted and > approved in PSARC 2009/566. Since the approach in 2009/352 is no > longer valid, I am marking it as withdrawn to avoid future confusion. Wouldn't superceeded be more appropriate? Gary.. From brian.utterback@sun.com Fri Nov 6 09:44:03 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id nA6Hi2sE026744 for ; Fri, 6 Nov 2009 09:44:03 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id nA6Hhxft017225 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Fri, 6 Nov 2009 17:44:02 GMT Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KSP009037XCDK00@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 06 Nov 2009 10:44:00 -0700 (MST) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KSP00MR27XB9820@brm-avmta-1.central.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Fri, 06 Nov 2009 10:44:00 -0700 (MST) Received: from [129.148.9.81] (sr1-ubur-02.East.Sun.COM [129.148.9.81]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.4) with ESMTP id nA6HhsIM003649; Fri, 06 Nov 2009 12:43:57 -0500 (EST) Date: Fri, 06 Nov 2009 12:43:54 -0500 From: Brian Utterback Subject: Re: Abandon the use of snapshots in mntfs. [PSARC/2009/352 FastTrack timeout 06/19/2009] In-reply-to: <200911061708.nA6H8oxX002210@marduk.eng.sun.com> To: Gary Winiger Cc: blu@sac.sfbay.sun.com, PSARC-ext@sun.com, Robert.Harris@sun.com Message-id: <4AF4605A.2050709@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200911061708.nA6H8oxX002210@marduk.eng.sun.com> User-Agent: Thunderbird 2.0.0.24pre (X11/20091028) Status: RO Content-Length: 856 Perhaps. The project team asked me to withdraw it, and it seemed to fit the explanation in the status.allowed file, so I went with it. I've changed it to superseded now. Gary Winiger wrote: > Brian, > >> I little house cleaning. After this case was approved, the project >> team decided to take a different approach which was submitted and >> approved in PSARC 2009/566. Since the approach in 2009/352 is no >> longer valid, I am marking it as withdrawn to avoid future confusion. > > Wouldn't superceeded be more appropriate? > > Gary.. -- blu It's bad civic hygiene to build technologies that could someday be used to facilitate a police state. - Bruce Schneier ---------------------------------------------------------------------- Brian Utterback - Solaris RPE, Sun Microsystems, Inc. Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom