From autofs-bounces@linux.kernel.org Mon Jan 5 07:33:30 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i05FXUnF023922 for ; Mon, 5 Jan 2004 07:33:30 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i05FTHJe009757; Mon, 5 Jan 2004 07:29:43 -0800 Received: from glock.ssa.crane.navy.mil (glock.ssa.crane.navy.mil [164.227.42.142]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i05FSPJc009649 for ; Mon, 5 Jan 2004 07:29:13 -0800 Received: from ssa.crane.navy.mil (tdennist@localhost [127.0.0.1]) by glock.ssa.crane.navy.mil (8.9.3/8.9.3) with ESMTP id KAA00639; Mon, 5 Jan 2004 10:28:01 -0500 Message-ID: <3FF98281.E4AEE29A@ssa.crane.navy.mil> Date: Mon, 05 Jan 2004 10:28:01 -0500 From: Todd Denniston Organization: Code 6067, NSWC Crane X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.22 i686) X-Accept-Language: en MIME-Version: 1.0 To: Dylan Subject: Re: [autofs] autofs4 and NIS References: <200401010159.12640.autofs@dylan.me.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Dylan wrote: > > Hello all, > > I'm currently using autofs4 to mount nfs shares. The config files are > distributed via NIS, which overall is working without a hitch. I have > two related problems, however... > > It is, obviously, necessary to restart the NIS server from time to time, > in order to take account of config changes (usually changes to user > accounts.) When I do this, the following occurs: I am a bit confused here. Why do you need to _restart_ the NIS server to push out the changes for USER ACCOUNTS? All of the systems I currently work with have have a Makefile in /var/yp, and you just need to do a cd /var/yp;make (or make PARTICULAR_CONFIG_FILE) and the updated user data is pushed to the NIS client machines. Although when I run 'make -n' I do see some "kill -TERM 0" buried in there, they look to only be ran if the awk commands before them return a non-zero exit status. -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 5 22:36:31 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i066aUx7002138 for ; Mon, 5 Jan 2004 22:36:31 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i066We1x020416; Mon, 5 Jan 2004 22:33:17 -0800 Received: from petasus.ch.intel.com (petasus.ch.intel.com [143.182.124.5]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i05GM1Jc021725 for ; Mon, 5 Jan 2004 08:22:49 -0800 Received: from sedona.intel.com (sedona.ch.intel.com [143.182.202.83]) 1.6 2003/12/18 18:58:11 root Exp $) with ESMTP id i05GLqZ5017178; Mon, 5 Jan 2004 16:21:52 GMT Received: from sedona.intel.com (chlx001.ch.intel.com [143.182.226.71]) by sedona.intel.com (8.12.10/8.12.9/d:) with ESMTP id i05GLptZ020460; Mon, 5 Jan 2004 09:21:51 -0700 (MST) X-Envelope-From: mlblandf@sedona.ch.intel.com Message-ID: <3FF98F1F.6010709@sedona.intel.com> Date: Mon, 05 Jan 2004 09:21:51 -0700 From: Michael Blandford User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dylan Subject: Re: [autofs] autofs4 and NIS References: <200401010159.12640.autofs@dylan.me.uk> In-Reply-To: <200401010159.12640.autofs@dylan.me.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org X-Mailman-Approved-At: Mon, 05 Jan 2004 22:32:39 -0800 cc: autofs mailing list X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Dylan wrote: >Hello all, > >I'm currently using autofs4 to mount nfs shares. The config files are >distributed via NIS, which overall is working without a hitch. I have >two related problems, however... > >It is, obviously, necessary to restart the NIS server from time to time, >in order to take account of config changes (usually changes to user >accounts.) When I do this, the following occurs: > > I think we need to address this issue in particular. I can't think of any reason you need to restart your NIS master for config changes. We have masters/slaves that have been up for years at a time without restarting. These probably see > 100 map changes/pushes a day. What changes are being made that a 'make' in /var/yp doesnt solve? Also, you can set up a NIS slave/secondary to handle any connections in the event the master is unavailable or to help handle the load. Then you always have NIS coverage. I think if you solve this problem, the others will become non issues. Michael _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 6 08:31:29 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i06GVPt8000595 for ; Tue, 6 Jan 2004 08:31:29 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06GOY1x009984; Tue, 6 Jan 2004 08:25:00 -0800 Received: from gate.nmr.mgh.harvard.edu (gate.nmr.mgh.harvard.edu [132.183.203.69]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06GNn1v009878 for ; Tue, 6 Jan 2004 08:24:32 -0800 Received: from gate.nmr.mgh.harvard.edu (localhost [127.0.0.1]) i06GNgNv025941verify=NOT); Tue, 6 Jan 2004 11:23:42 -0500 Received: from localhost (raines@localhost)i06GNgfj025937; Tue, 6 Jan 2004 11:23:42 -0500 X-Authentication-Warning: gate.nmr.mgh.harvard.edu: raines owned process doing -bs Date: Tue, 6 Jan 2004 11:23:42 -0500 (EST) From: Paul Raines To: "H. Peter Anvin" Subject: Re: [autofs] rm hangs on symlinks to down mount points In-Reply-To: <3FF21106.4000907@zytor.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: I am now in one of the unmountable mount situation I described before: [root@gate /root]# umount /autofs/space/meso_013 umount: /autofs/space/meso_013: device is busy [root@gate /root]# umount -f /autofs/space/meso_013 umount2: Device or resource busy umount: /autofs/space/meso_013: Illegal seek [root@gate /root]# find /proc -lname '*meso*' 2>&1 | grep -v 'No such' [root@gate /root]# fuser -m /autofs/space/meso_013 /autofs/space/meso_013: Stale NFS file handle [root@gate /root]# ps auxw | grep auto root 650 0.0 0.1 1612 580 ? S 2003 0:02 /usr/sbin/automount /autofs/space yp auto.space intr,rw,hard,nodev,rs As you can see, no process is advertising itself as one that is keeping the mount "busy". So I see nothing I can kill. There are no automount subprocesses, just the parent one. I can try stopping that but I have over 30 users on the system now and I would rather not cause an interruption. Is there any other solution? Any better way to hunt for processes that are keeping a mount busy? -- --------------------------------------------------------------- Paul Raines email: raines@nmr.mgh.harvard.edu MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street Charlestown, MA 02129 USA _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 6 12:00:12 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i06K0Bc6006043 for ; Tue, 6 Jan 2004 12:00:12 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06Juk1x023837; Tue, 6 Jan 2004 11:57:02 -0800 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06Jtl1v023732 for ; Tue, 6 Jan 2004 11:56:42 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i06Jtgj4025612 for ; Tue, 6 Jan 2004 11:55:42 -0800 (PST) Received: from sun.com (vpn-129-152-200-55.East.Sun.COM [129.152.200.55]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HR3002V83CLHJ@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Tue, 06 Jan 2004 11:55:41 -0800 (PST) Date: Tue, 06 Jan 2004 14:55:25 -0500 From: Mike Waychison To: Kernel Mailing List , autofs mailing list Message-id: <3FFB12AD.6010000@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org Subject: [autofs] [RFC] Towards a Modern Autofs X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============38600530579307429==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============38600530579307429== Content-type: multipart/signed; boundary=------------enig0477A4B7AFFA9B1FED23E6A8; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0477A4B7AFFA9B1FED23E6A8 Content-Type: multipart/mixed; boundary="------------010205070700060103030200" This is a multi-part message in MIME format. --------------010205070700060103030200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Everyone, We've spent some time over the past couple months researching how Linux autofs can be brought to a level that is comparable to that found on other major Unix systems out there. The attached paper was written an attempt to design an automount system with complete Solaris-style autofs functionality. This includes browsing, direct maps and lazy mounting of multimounts. The paper can also be found online at: ftp://ftp-eng.cobalt.com/pub/whitepapers/autofs/towards_a_modern_autofs.txt and ftp://ftp-eng.cobalt.com/pub/whitepapers/autofs/towards_a_modern_autofs.pdf Over this time, We've discovered that Linux namespaces completely wreak havoc onthe current autofs implementation for several reasons. We've tried to define consistent semantics for dealing with automounts in a multi-namespace environment. After a lot of contemplation, these design ideas are the most reasonable we could find. If you have alternative ideas, or better ideas, or just think we're idiots, let us know. Suggestions and comments are not just welcome, they are NEEDED. Thanks, -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------010205070700060103030200 Content-Type: text/plain; name="towards_a_modern_autofs.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="towards_a_modern_autofs.txt" Sun Microsystems Inc. -- Linux Software Engineering Towards a Modern AutoFS ====================== By: Mike Waychison Edited By: Tim Hockin Copyright 2003-2004, Sun Microsystems, Inc. Table of Contents ================= 1 Abstract 2 Introduction 3 Requirements 4 Analyzing the Alternatives 5 Proposed implementation 5.1 Indirect Maps 5.1.1 Browsing 5.2 Direct Maps 5.3 Multimounts and Offsets 5.3.1 Explanation 5.3.2 Implementation 5.3.3 Multimounts without root offsets 5.4 Expiry 5.5 Handling Changing Maps 5.5.1 Base Triggers 5.5.2 Forcing Expiry to Occur 5.6 The Userspace Utility 6 New Facilities 6.1 Mountpoint file descriptors 6.2 Native Expiry Support 6.3 Cloning super_block 6.3.1 The --bind problem 7 Scalability 8 Conclusion 1 Abstract ========== Automounting is a system that allows local and network filesystems to be mounted as needed. The automount configuration for a system is distributed via flat files or via network based lookups. This can become a difficult system to get right given the large set of features required and some new features available in Linux today. By breaking out the task of automounting from a daemon into a usermode helper application, we are able to simplify the architecture in both userspace and kernelspace. This enables us to solve some existing problems, deal with Linux filesystem namespaces, and gives us an architecture to provide per-namespace automount configurations. This document describes such a system and details what infrastructure needs to be added to the Linux kernel before such a system can be implemented. 2 Introduction ============== Traditionally, automounting has been implemented in one of two ways. The earlier implementations usually handled the entire problem of automounting by creating a userspace NFS server. More modern implementations have added kernel support directly by either modifying the VFS layer or by creating filesystems that cope with the problem. Both of these architectures have traditionally relied on one or more daemons that handled all policy in userspace and were responsible for performing the actual mounting of filesystems. The earlier implementations that used a userspace NFS server worked by mounting NFS shares at appropriate locations in the filesystem tree. The daemon that served those shares would then be able to trap all directory traversals and perform mount actions as required. Some systems have also used similar techniques to catch triggering actions and have the desired filesystem mounted elsewhere, using symbolic links that point back to them. These systems lent themselves to difficult administration and often lead to hung filesystems and cruft mounts when the daemon was unexpectedly killed. Later implementations placed traps directly into the kernel by creating a new filesystem called 'autofs'. This filesystem would be responsible for triggering on directory traversals and would pass mount requests up to userspace. The kernel infrastructure became necessary as it became more and more evident that implementing everything in userspace became extremely tedious and difficult to properly manage. Different architectural models exist for daemon implementations. Solaris currently uses a single daemon approach that handles all requests coming from kernelspace. This allows for easy management of changing maps and for dealing with the expiry of nested maps. The single daemon approach was also preferred because it consolidated any process overhead for the entire system into one process. One of the difficulties in managing a single daemon automount system is that the entire system must be tooled to work asynchronously. This includes all components from performing NIS lookups to performing NFS mounts. Although this is an achievable goal, it requires a lot of work. It is much simpler to have a single process for each automount trigger that uses the existing synchronous facilities. Unlike Solaris, Linux uses a multi-process daemon approach. This system works adequately given the level of functionality it aims to support, but it is not without flaws. Linux currently only supports the use of indirect maps and the nesting of maps via the fstype=autofs mount option. Each indirect mountpoint has exactly one daemon and one map associated with it. All map lookups are performed synchronously within the daemon. This means that a lookup for an entry within a given mount may block and may cause a second lookup within the same indirect mount to block unnecessarily. This is a fair design decision as both entries are determined to be coming from the same source and will equally block [[[The exception to this is of course any networked map that is being served from a slave server. Any cached entries may be returned at different speeds and blocking times may actually vary. A second example of where this rule doesn't apply is when a local file-backed map is referenced, which in turn includes another map from the network.]]]. Mounts are handled in an asynchronous fashion by forking and executing the mount(1) command. Linux's implementation is multi-process in the sense that each indirect mountpoint has an associated daemon process. Nesting of maps is handled by maintaining parent-child relationships between daemon processes. A parent process manages the parent map. When an entry in this map is accessed which has the 'fstype=autofs' option specified, the daemon forks and executes a new copy of itself. This child daemon is responsible for the nested map. The two processes communicate with each other using signal IPC so that they may synchronize expiry of the nested map. One problem with Linux's multi-process approach is that it does not handle lazy mounts in multimount entries. This is evident in the implementation of automount 3.9.99-4.0.0-pre10 (the most current release at the time of this writing). In this daemon implementation, multimounts are not lazy mounted and will, by default, attempt to mount all entries in the multimount immediately. It will also, by default, fail if any of the filesystems fail to mount properly. This latter problem has been quick-fixed by the addition of a 'nostrict' option for multimounts. This leads to large numbers of potentially unneeded filesystems being mounted and causes unnecessary latency. A multimount entry may contain multiple shares from different hosts and mounting them all can cause a noticeable lag to a user application. Mounting unneeded remote filesystems also increases the likelihood that one of the filesystems will go stale and hang processes which attempt to access them. A filesystem can go stale when the system serving it crashes, is rebooted or when network connectivity is lost. For example, depending on the configuration given to an NFS client, a crashed server will cause all processes accessing the NFS filesystem to hang indefinitely. Another flaw that both Solaris' and Linux's automount models have is that neither lends itself to dealing nicely with filesystem namespaces, a new feature in Linux as of kernels 2.4.19 and 2.5.22. Namespaces allow a system to have multiple distinct mount hierarchies. Namespaces are created by a call to the clone(2) system call with the CLONE_NEWNS flag. This call creates a new process as it usually would, but the new process receives an entirely new copy of the parent process's namespace. This is done by creating a new mount table for the given process, and essentially re-executing all previous mounts in the new mount table. This creates a completely distinct mount table, and allows any changes such as bind mounts, moved mounts, new mounts, and unmounts to only be reflected within that namespace. This idea was partially borrowed from distributed operating systems such as Plan 9 ("The Use of Name Spaces in Plan 9", Rob Pike et al. "http://plan9.bell-labs.com/sys/doc/names.html") and Spring ("A Uniform Name Service for Spring's UNIX Environment" Michael N. Nelson / Sanjay R. Radia http://www.usenix.org/publications/library/proceedings/sf94/full_papers/nelson.ps), which allows users to create their own mount hierarchies, independent from any other user. The key as to why these automounting implementations cause problems when using namespaces is that the previous implementations rely on a daemon process that inherently resides within a single namespace. Whenever an autofs mount is triggered, the kernel communicates with the daemon, which in turn mounts the filesystem onto the given path. Unfortunately, this breaks cross namespace functionality because the mounted filesystem is grafted into the daemon's namespace, which may or may not be the same namespace as used by the triggering application. Namespaces are designed such that cross-namespace facilities are deliberately absent. The easiest method for performing any cross-namespace functions is to execute within the alternative namespace. Determining whether a process is a user application causing a trigger or an automount daemon performing a mount has also traditionally been difficult and required special casing. We can avoid any such special casing by providing a file descriptor that describes the target directory to the automounter, which would in turn fchdir(2) to the target location. With the current state of automount understood, we can explore the problems that exist today and look at new approaches to automounting. 3 Requirements ============== A new automount system involves several new requirements in order to work gracefully with new Linux facilities. To enumerate these requirements we must start by examining the current implementations and determining where things begin to break. Specifically, we will look at the current modes of userspace / kernelspace communication used by both the current Linux autofs3 and autofs4 implementations. Traditionally the autofs filesystem has needed a way to distinguish whether an application that traverses into an autofs mount is a regular user process, or the daemon coming in to perform a mount. This has previously been handled in Linux by identifying the daemon using its process group, as registered at mount time. The use of the daemon's process group not only abuses Unix semantics, but also makes handling complex automount hierarchies very difficult. It forces the implementation to handle nested mounts using distinct processes in order to traverse the outer directories as if it were not the automounter. Another big caveat to the current approach is the system's reliance on the automount daemon registering an open pipe with the kernel. This registration is made at mount time using a mount option to pass the pipe's file descriptor. This kind of communication channel registration makes for a system that is incapable of self-healing. It is impossible in this form of communication for the daemon to disconnect from the kernel and reconnect. A daemon that dies (accidentally or forcefully) will leave the system with autofs filesystems mounted yet stuck in what is called a 'catatonic' state. The autofs filesystems will give up trying to communicate with their respective daemons and will not process any new triggers. On top of that, any expiry runs that should be occurring will cease to run as they are invoked by the daemon itself [[[Expiry is triggered from userspace via an ioctl on the root directory of the autofs filesystem. The filesystem will in turn check to see if any of the current sub-mounts have been inactive for some period of time and will return the path(!) of the entry to expire back to userspace. Userspace will then attempt to unmount the path using umount(8).]]]. This forces an administrator to either manually unmount all the filesystems left behind, or more often than not, simply restart the daemon, causing more filesystem to be mounted over the existing stale ones in wait for the next reboot. Another reason one would want to move away from a single daemon approach is because automounting semantics are not very clear when namespaces are used. One of the driving forces behind implementing distinct namespaces in Linux is to allow the root user to create distinct mount environments for differing services and users. This is different from chrooting because processes outside of the chroot environment can still navigate any new mountpoints within the chroot. When using namespaces, processes cannot navigate mounts that are not within their own namespace. One particularly useful advantage to namespaces is that a user may mount a privileged filesystem such as a Samba share, without allowing any other users to see the mount in question. Not even the root user himself would be able to gain access to the contents of the filesystem. Another possibility of namespaces is that a system may be configured such that upon login, the login process could create a new namespace for that user and bind mount $HOME/tmp over /tmp. In effect, the user has a private /tmp directory that no other user is capable of accessing. Namespaces are currently implemented such that root can create a new namespace by deriving from an existing namespace. From this derivation, the namespace may be completely customized by adding and removing mounts in the system. Given the current Linux autofs implementation, any derived namespace will inherit autofs filesystems, but they do not work as expected, as the persistent daemon has no access to this namespace and cannot thus mount new filesystems upon trigger. Instead of the mount occurring in the derived namespace, where it was triggered, the mount will occur in the original namespace in which the daemon is running and not be visible from the triggering namespace. Further, any filesystems that were automounted in the original namespace will persist in the new namespace and will never expire. The original mount will expire in its own namespace but the cloned copy of it will not be visible to the daemon. Even if the kernel (which can see all namespaces) told the daemon that the mount needed to be expired, the daemon itself has no way to unmount the filesystem in a namespace other than its own. This is clearly not the desired functionality. Ideally, one would like to properly be able to inherit automount triggers when creating a new namespace. Automount triggers would ideally work as configured in the parent namespace, but also be removable and installable using a different automount configuration. It is also desirable to have a system that is not reliant on a persistent daemon and which is capable of healing any stale triggers. The most obvious approach to handle these kinds of problems is to remove any persistent namespace context - namely the kernel's reliance on a single daemon, while providing more namespace context during the mounting process. The following new set of architectural requirements become necessary: o Automount triggers should continue to operate properly within a cloned namespace. We want to be sure that an automount trigger that exists in both the parent and child namespaces will cause a mount to occur in the appropriate namespace only. o Automount triggers that are inherited from a parent namespace should remain distinct from their parent counterpart. We cannot allow a user in one namespace to alter the automount configuration across multiple namespaces. o Filesystems that have been automounted and duplicated into a cloned namespace should continue to expire. o The addition or removal of an automount trigger should only affect the namespace in which the change applies. In addition, the following functions are required above and beyond the existing Linux automount implementation in order to be in line with the functionality provided by other Unix implementations: o Both direct and indirect maps should work as expected. o The system should expire and unmount any unused automounted filesystems. o Lazy mounting should occur wherever possible. o The system must be able to scale to thousands of mounts. o The browsing of indirect maps should be supported. o The system should be able to handle changing maps and update the current configuration as required. 4 Analyzing the Alternatives ============================ Working with these requirements in mind, different types of architectures can be considered. Several facets of each potential architecture need to be examined. 1) Are any of the required facilities to implement this architecture already in place? 2) How much state is duplicated between userspace and in kernelspace? 3) How well can automount triggers be handled in a multi-namespace environment? 4) How simple is the implementation and how prone is it to error? With these questions, we can evaluate different architectures for our new system. The following are a couple differing ways a new automounting system can be architected. 1) Perform everything in kernelspace. There is no need for a daemon. A utility will communicate with the kernel to install all the triggers. It is the kernel's responsibility to catch all directory traversals that require a new mount to occur. The kernel also handles name-service lookups, map entry parsing and performing the actual mounts. Pros: o Makes handling cross-namespace triggers a lot easier as full access to kernel data-structures is available. o Managing atomicity when handling a trigger is greatly simplified. o Full access to map resources is available. Cons: o Lookups being performed in the kernel places an enormous amount of logic in the kernel that is probably better left in userspace. o Does not leverage the benefit of using the mount(8) utility which already handles mounting different filesystems very well. Many filesystems, notably NFS and SMB, have differing APIs for handling mounts and require packed structures to be passed to the kernel. o Requires new APIs to be put in place that will allow userspace applications to remove triggers from their mount table. o Canceling a trigger action (e.g.: via a SIGINT) becomes much more difficult to handle properly. 2) Continue using a multiprocess daemon using file descriptors to describe the target mountpoints. Use a daemon similar to that used in the current Linux automount package. Augment the kernelspace/userspace communication protocol so that we can have the daemon mount and unmount on file descriptors (which are namespace aware) instead of by pathnames (which are namespace dependent). Pros: o Automounting continues to work across a cloned namespaces. Cons: o Requires new API that allows the passed back file descriptor to be re-associated with a map and key. o Would require one persistent process per direct/indirect mountpoint. o Difficult to handle lazy mounting of multimounts. o Difficult to manage a large hierarchy of processes that is continuously in flux. o Duplicates structure information found in the kernel. o Doesn't allow for clean administration of differing automount schemas across different namespaces. o Requires new system calls to natively support mounting and unmounting on a file descriptor. o Cloned namespaces are left with automount triggers that do not have a daemon running in the new namespace. 3) Create a single process daemon that is capable of handling all trigger requests across the system. Again, uses file descriptors passed back from kernelspace to describe mountpoint targets. Pros: o Consolidated process and memory overhead. o Can be done without maintaining too much state in the userspace daemon. o Continues to work as desired across cloned namespaces. Cons: o Requires new API for grabbing the file descriptor on which to mount, and associate the proper map sources. o Access to map information across namespaces is difficult to access. Files may differ, as may network service client configurations. o Requires new system calls to natively support mounting and unmounting on a file descriptor. o Requires asynchronous infrastructure to handle synchronous name service APIs. o Managing differing automount configurations becomes difficult. 4) Use a usermode helper application that handles the trigger requests. Contextual information is passed to the kernel when installing the automount trigger. This information is then passed back to a usermode helper application that is invoked on each triggering action. The usermode helper is invoked within the triggering action's namespace. All lookup logic and mounting is handled by the usermode helper which then mounts the desired filesystem on a given file descriptor which describes the target directory. Pros: o API for passing file descriptor and associated map information is already in place. All information can be passed in to the helper application via command line arguments, environment variables and through open file descriptors. o No daemon means state is only maintained in kernelspace. o Allows in place replacement of the userspace infrastructure. o No need to worry about a daemon dying and leaving the system with stale automount triggers. o Easy access to local namespace configuration for both file maps and network services. Cons: o A lot of triggers occurring simultaneously would invoke many processes. o A new facility that allows mounting operations using file descriptors of directories is needed. The alternative approach of using a usermode helper application to handle the mount requests using a usermode helper application quickly becomes a viable option when one realizes the benefits in both cross-namespace use and reliability. By moving any logic that was previously in the daemon out into a usermode application, we can enrich the userspace/kernelspace protocol by giving the process context about where the triggering action occurred. The use of the hotplug system is preferred in this implementation because it is already a well-defined and accepted form of kernelspace to userspace communication, though a separate but similar system could be used instead. /sbin/hotplug is currently invoked with any number of arguments and any number of environment variables. The goal is to have all trigger events be performed by the userspace agent. Unfortunately, as we will discover, implementing expiry is a more difficult task and must be done completely in the kernel. Implementing automounting without having a single persistent daemon does also have its own problems. It assumes that the system upon which the automounting is occurring will have enough system resources to be able to handle a high automounting load. By invoking a single process per automount action, we are consuming more resources than a more traditional automount system would otherwise consume, and doing so in bursts. It is the belief of the author that these extra resources are reasonable and will not grossly affect the performance of the system. These assumptions should however be properly qualified by performing relevant benchmarks and stress tests on a prototype implementation. The rest of this document describes a way to implement an automount system that uses a usermode helper application to perform automount requests. 5 Proposed implementation ========================= By removing the need for a persistent daemon and by adding mountpoint navigation facilities we are able to address all of the shortcomings of the current Linux automount system and fulfill all of the new requirements introduced by namespaces. The preferred approach is to use a userspace helper application similar in nature to that used by the hotplug subsystem. /sbin/hotplug already provides userspace defined agents for a variety of systems and adding an automount agent is as simple as dropping a file in the /etc/hotplug directory. It must be noted that the hotplug action will run outside of any chroot(2) environments. The current Linux automount implementations do not enforce any such restriction and mixing automounting with chroot(2) leads to undefined behavior. Chroots are different from namespaces because they share portions of the mount-table while differing namespaces do not. Forcing the hotplug invocation to occur at the root of a namespace enforces a single automount configuration per namespace. These semantics are similar to those on other operating systems when automounting and chroots are used in conjunction. Registering an automount in a namespace will still be handled as a filesystem that will be responsible for catching any triggering actions. In the current Linux autofs implementations, the file descriptor for the writing end of an open pipe is passed as a mount option and used for kernelspace to userspace communication. This makes the kernel dependent on the pipe being open for communication with userspace. This causes an automount trigger to become catatonic when the reading end of the pipe is closed. This communication artifact will be completely removed as part of the new protocol. The daemon's process group is used in the existing automounter implementation to let the filesystem determine if the process causing a trigger was a user process accessing automounted resources or an automount daemon satisfying a prior request. In the design outlined in this document, we avoid this issue altogether by allowing the servicing process to bypass pathname walks. This is done by using file descriptors to describe target locations of mounts. In addition to describing target directories as file descriptors, mount operations that are be capable of dealing directly with file descriptors are needed. Assuming new mount facilities are in place, mount operations throughout this document are done in terms of directory file descriptors. Rudimentary requirements are summarized in section 6.1. Installing automount triggers in a system will be handled by mounting 'autofs' filesystems at the appropriate locations. Mount options will be used to pass all the context information needed later by the helper application when responding to triggering actions. Most of these mount options will not be interpreted by the kernel itself. They solely serve to pass contextual information to the helper application upon invocation. All mount options that are interpreted by the kernel are noted as such. 5.1 Indirect Maps ----------------- The implementation of indirect maps will be done using an autofs filesystem similar to that found in the current implementation. The main difference being that it will take a list of mount options indicating that it is an indirect map as well as where the indirect map entries can be found. For example, if the directory /home is to be an indirect mountpoint using the map auto_home, the following mount command would be used: ---------- mount -o maptype=indirect,mapname=auto_home -t autofs autofs /home ---------- This would mount a filesystem of type autofs on the /home directory in the current namespace. The 'maptype' mount option is used by the filesystem code and tells it to use indirect map semantics [[[The difference between direct and indirect semantics is that a direct map requires a trigger to occur on traversal into the autofs filesystem while an indirect map requires a trigger to occur traversal into each subdirectory. Direct maps are described in more detail in the next section.]]]. A simple example indirect map might have a single entry as follows: --------- mikew host:/export/home/mikew --------- Later on, if user mikew were to access his home directory /home/mikew, the system hotplug handler would be invoked as root in the same namespace as the triggering process: --------- /sbin/hotplug autofs mount --------- This process is invoked in the same namespace as the triggering process because in order for the triggering process to see the mounts, we require that all mounts occur in the namespace of the triggering application. Also, the hotplug helper needs to access the configuration of the triggering application's namespace. This configuration may include the /etc directory, as well as any NIS and/or LDAP settings. Execution of the hotplug system is currently hard-coded to run in init's context. Running /sbin/hotplug in an arbitrary namespace differs from the existing hotplug functionality and should be documented as such. [[[This semantic difference may justify using a different executable rather than /sbin/hotplug. Either way, hotplug is used for the sake of discussion.]]] When invoked, the following environment variables would be set [[[This document uses environment variables to pass values to the hotplug agent because it is easier to convey their relations in pseudo-code terms. An actual implementation may choose to use command line arguments instead of environment variables because '/sbin/hotplug autofs mount auto_home mikew 0' appears clearer. This is an implementation detail and of little importance to the discussion at hand.]]]: --------- MOUNTFD=0 MAPNAME=auto_home MAPKEY=mikew --------- The hotplug agent would be responsible for performing the keyed lookup of $MAPKEY in the map named $MAPNAME. It would then use the information in the entry to perform the mount directly on the $MOUNTFD specified before returning a successful exit code. For the simple indirect mount case, these three environment variables comprise all the information that is required to properly perform the userspace actions. The $MOUNTFD environment variable refers to the number of an open file descriptor of the directory upon which to mount. The new mount system call will be used to allow for file descriptor based mount operations. A file descriptor is preferred because it allows any mount-related system calls to completely bypass any pathname resolution, thus allowing the automounter to bypass any triggers directly. This simplifies any blocking logic when a mount is occurring and eliminates the need for identifying the helper application as performing the mount. This allows us to have automount triggers handled by individual processes without any special reliance on their process group. It also alleviates the need for persistence (again, due to the process group dependency). Once an autofs filesystem is mounted, we no longer rely on its absolute path for automount functionality. We effectively disassociate any map context information from the actual location of the mount. This allows autofs mounts to be moved (mount(8) --move option) or bound (mount(8) --bind option) without affecting automount functionality. It also allows an administrator to install automount triggers without modifying the /etc/auto_master file. For example, a map auto_ws could be manually installed on directory /ws using a command such as: --------- mkdir /ws mount -o maptype=indirect,mapname=auto_ws -t autofs autofs /ws --------- This can be done without affecting any currently configured automount triggers. 5.1.1 Browsing `````````````` When an indirect map is installed on a directory, the resulting filesystem has no files or directories within it. Subdirectories are created upon lookup. For instance, the indirect mount on /home mentioned above would have no contents (other than the usual '.' and '..' entries) until access to some subdirectory is performed. The exception to this rule is when the map entry for /home contains the option 'browse': ---------- /home auto_home -browse ---------- In this case, a directory listing of /home should return a directory entry for each valid key in the associated map. None of the entries should be automounted when this is performed. Such actions are delayed until the directories are traversed. This is useful from a user perspective, allowing a user to enumerate all entries that are available without requiring any mounts to occur. In order to implement this functionality we begin by adding a 'browse' mount option to the autofs filesystem. This option switches behavior such that an indirect mount filesystem will call the usermode helper with the following information upon the first directory listing request (called by the ->readdir file operation on the root directory of the filesystem). The usermode helper will be called with the 'browse' action and will receive the following information on invocation: ---------- MAPNAME=auto_home OUTPUTFD=0 ---------- It is then the helper application's responsibility to retrieve the map and validate the entries. It will then pass the keys of the map back to kernelspace by printing them out to the file descriptor described by $OUTPUTFD. The kernel will take the values written to $OUTPUTFD and will later used them to fill in requests to readdir. It will need to create dummy directory entries so that lookups caused by calling stat(2) will return valid results. Once again, the usermode helper application will run within the same namespace as the triggering application so that namespace-local configuration is used. In order to maintain some form of coherency between changing maps, these dummy directory entries will remain in place within the dcache so that the kernel doesn't need to query the usermode helper as often. These entries will periodically timeout and will be unhashed from the dcache. Any subsequent directory listing requires the kernel refresh these entries with a new call to the usermode helper. The timeout will be specified as another mount option ('browsetimeout=') to the autofs filesystem. The value will be passed back to the usermode helper when mounting as the environment variable $BROWSETIMEOUT, so that the usermode helper may inherit these values for any nested maps. This environment variable will be specified for all automount types, however, the browsetimeout mount option will only be used by autofs mounts that have maptype=indirect and the browse options set. Other configurations will silently ignore this value. A default value of 10 minutes (600 seconds) will be assumed. Executing the usermode helper within the namespace of the triggering application does have a problem when browsing is used. We are caching map keys in kernelspace and can run into coherency problems when an autofs super_block is associated with multiple namespaces which have differing automount maps in /etc. This kind of situation may occur if a namespace is cloned and a new /etc directory with a different auto_home map is mounted. The results from a readdir within the first namespace may differ than the expected results from a readdir in the derived namespace. In order to handle this, facilities need to be added that allow autofs super_blocks to be cloned when cloning namespaces. Doing so ensures that an autofs super_block is local to its namespace and the namespace-local configuration. Cloning of super_blocks is described in section 6.3. 5.2 Direct Maps --------------- Direct maps will be handled in a similar fashion to indirect maps. The main differences are outlined as follows: 1) The mount option 'maptype' is now 'direct'. This tells the filesystem code to have direct map semantics. 2) The map key for the direct mount entry is now passed as a new mount option called 'mapkey'. It will be the key to use when looking up the entry in the direct map. For direct map entries, this will always be the same as the path upon which the trigger is mounted; however, handling lazy mounts will also use this value as they will use the same kind of automount trigger. This is different from indirect maps where the map key is produced by a directory lookup. Direct automounts have no such directory lookup and this contextual information must be explicitly specified at mount time. The value of this mount option is used as the $MAPKEY environment variable when the hotplug agent is invoked. When a user process traverses into the root of an autofs filesystem that has maptype=direct, a mount needs to be performed. The triggering process will block while the hotplug userspace helper application is again invoked in the triggering process's namespace. For example, assume that the auto_master file has the following entry: ---------- /- /etc/auto_direct ---------- This tells the installing application (see below: The Userspace Utility) to iterate over the /etc/auto_direct map and install a direct automount trigger for each of the entries in the map. Assume the auto_direct file contains one entry: ---------- /usr/share hostname:/export/share ---------- To install this entry, the following mount command would be used: ---------- mount -o maptype=direct,mapname=/etc/auto_direct,mapkey=/usr/share \ -t autofs autofs /usr/share ---------- This hands the kernel all the information it needs to pass back to the hotplug agent in order to let it perform the mount when necessary. When the agent is invoked, it is again called with the 'mount' action and it is passed the same environment variables as in the case of an indirect mount. In our example these are: ---------- MOUNTFD=0 MAPNAME=/etc/auto_direct MAPKEY=/usr/share BROWSETIMEOUT=600 ---------- The helper application will need to go through and lookup the key '/usr/share' in the map '/etc/auto_direct', parse the entry and finally mount the relevant filesystem on the directory specified by the given file descriptor [[[Even though the value of the key looks like an absolute path, it should not be interpreted as such. Its sole purpose is to index into the given map.]]]. This is exactly the same logic as required for handling indirect maps. 5.3 Multimounts and Offsets --------------------------- 5.3.1 Explanation ````````````````` A multimount is a map entry with an extended syntax that allows for a potentially complex hierarchy of filesystems to be mounted on a given directory. Multimounts may occur in both direct and indirect maps. They are most often used to enable the automounting of one NFS share nested within another. For example, if we want to automount hosta:/export/src on /usr/src and hostb:/export/linuxsrc on /usr/src/linux, we would need to use a multimount. In this case the multimount entry would be placed in a direct map and would look like the following: ---------- /usr/src hosta:/export/src \ /linux hostb:/export/linuxsrc ---------- In this example, the hosta:/export/src is to be mounted directly on the /usr/src directory, and hostb:/export/linuxsrc. The mount information for /usr/src could have also been written as: ---------- /usr/src / hosta:/export/src \ /linux hostb:/export/linuxsrc ---------- In this example, the '/' of the multimount is explicit whereas in the first example it was implied. Both path components '/' and '/linux' are called offsets. A multimount is comprised of a set of offsets, each of which has a set of sources. In all the examples in this document, only one source (such as an NFS share) is given for each offset. There can very well be more than one source per offset. This technique of listing multiple sources is used to specify fail-over redundancy. Handling NFS fail-over redundancy is better implemented within the NFS subsystem and is not described in this document. By design, the multimount syntax is really just a superset of the regular map entry syntax. For example, the following two map entries are equivalent: ---------- Entry 1: mikew hostc:/export/home/mikew Entry 2: mikew / hostc:/export/home/mikew ---------- In the first entry, the '/' offset is implied. So by design, all map entries may be treated as a multimount. Most of which simply only have the 'root offset' defined. One of the interesting aspects of multimounts is that entries do not have to have a 'root offset' defined at all. For instance, consider the situation where three users exist on the system and their home directories all come from NFS servers. The indirect map for /home may look something like this: ---------- userA host:/export/home/userA userB host:/export/home/userB userC host:/export/home/userC ---------- A new user is then added to the system who needs /home/userD/server1 to come from one server, while /home/userD/server2 to be mounted from a second server. There is no need to mount anything directly on /home/userD. This can be quickly added to the above map as the following entry: ---------- userD /server1 host1:/export/share1 \ /server2 host2:/export/share2 ---------- In this entry, there are two different offsets defined, namely '/server1' and '/server2' but there is no 'root offset' defined. To complicate matters even more, offsets can also nest within each other: ---------- /usr / hosta:/export/share/usr \ /src hostb:/export/src \ /src/linux hostc:/linuxsrc ---------- The desired behavior is to 'lazy-mount' all these mounts. This means that only those directories that are accessed are ever mounted. So, if only /usr is being accessed, then only the share from hosta is mounted. Only when /usr/src is first accessed will the share from hostb be mounted. The same 'laziness' holds for /usr/src/linux from hostc. 5.3.2 Implementation ```````````````````` An interesting aspect of implementing lazy mounts is that a multimount entry can be broken down into several direct mounts. This is done by associating an offset value with each direct mount trigger. This offset value is used at trigger time to identify which portion of the mount has just triggered and which subsequent triggers need to be installed. This offset value will be specified at autofs mount-time using a new mount option, 'mapoffset', and will be passed down to the hotplug agent as a new environment variable: $MAPOFFSET. The 'mapoffset' mount option will default to '/' if it is not explicitly specified. This builds on the definitions explained above for both direct and indirect maps. With this in mind, we provide an example using the following direct multimount entry from map auto_direct: ---------- /usr / hosta:/export/share/usr \ /src hostb:/export/src \ /src/linux hostc:/linuxsrc ---------- The mount command used to install the trigger would now look as follow (with additions in bold): ---------- mount -o maptype=direct,mapname=auto_direct,mapkey=/usr\ ,mapoffset=/ -t autofs autofs /usr ---------- Once this automount trigger has been installed, a first access to the directory /usr will cause /sbin/hotplug to be invoked with the following environment variables: ---------- MOUNTFD=0 MAPNAME=auto_direct MAPKEY=/usr BROWSETIMEOUT=600 MAPOFFSET=/ ---------- $MOUNTFD, $MAPNAME, $MAPKEY are still defined as in the explanations of both direct and indirect map handling. The agent is to retrieve the entry with key '/usr' from the map 'auto_direct' and parse it. The key addition is that it now uses the $MAPOFFSET to figure out which part of the entry is being mounted. Once the filesystem is mounted, the agent then mounts any other required child offsets on top of the filesystem before exiting. So, in the case of traversing into the /usr directory, the following actions are performed: o lookup key '/usr' in map 'auto_direct' o parse entry o lookup offset '/' in entry o mkdir('/tmp/') o mount 'hosta:/export/share/usr' '/tmp/' o mkdir('/tmp//src') o mount -o maptype=direct,mapname=auto_direct,mapkey=/usr\ ,mapoffset=/src -t autofs 'autofs' './tmp//src' o fchdir($MOUNTFD) o mount --move '/tmp/' '.' o rmdir /tmp/ o exit(EXIT_SUCCESS) In this and following examples, we choose to use a temporary directory '/tmp/' as an intermediate root of our mount because we need to be able reach into the newly mounted filesystem to install the child offsets. If we had directly mounted the share from hosta on $MOUNTFD, we would not be able to change the current working directory into the newly mounted filesystem without first traversing back into the parent directory and then walking back across the trigger. Using this intermediate directory allows us to bypass this completely. Once we have finished performing all of the nested mounts we complete the transaction by moving tree of mounts directly onto the target directory and returning a successful exit code. [[[A final implementation would preferably use what we refer to as 'floating mountpoints' as described in section 6.1, 'Mountpoint file descriptors' to achieve the same desired effect without requiring the building of mountpoints in a temporary directory.]]] Comparing the initial autofs mount and the nested autofs mount, we notice that the only difference between the trigger on /usr and the trigger on /usr/src is the mapoffset mount option. This differentiator is enough to distinguish the two automount triggers. If a user were then to traverse into /usr/src, similar actions are performed by the agent: o lookup key '/usr' in map 'auto_direct' o parse entry o lookup offset '/src' in entry o mkdir('/tmp/') o mount 'hostb:/export/src' '/tmp/' o mkdir('/tmp//linux') o mount -o maptype=direct,mapname=auto_direct,mapkey=/usr\ ,mapoffset=/src/linux -t autofs 'autofs' '/tmp//linux' o fchdir($MOUNTFD) o mount --move '/tmp/' '.' o rmdir('/tmp/') o exit(EXIT_SUCCESS) Finally, if one walks into the /usr/src/linux directory: o lookup '/usr' in map 'auto_direct' o parse entry o lookup offset '/src/linux' in entry o mkdir('/tmp/') o mount 'hostc:/linuxsrc' '/tmp/' o fchdir($MOUNTFD) o mount --move '/tmp/' '.' o rmdir('/tmp/') o exit(EXIT_SUCCESS) 5.3.3 Multimounts without root offsets `````````````````````````````````````` The only remaining problem to be dealt with is multimounts that have no 'root offset'. These are a special case of regular multimounts and can be handled by still installing the direct mount trigger on the root of the multimount. However, instead of mounting a real filesystem upon trigger, a tmpfs filesystem is mounted before the agent proceeds to install child trigger mounts. Following is the auto_home map bound to /home from a previous example: ---------- userA host:/export/home/userA userB host:/export/home/userB userC host:/export/home/userC userD /server1 host1:/export/share1 \ /server2 host2:/export/share2 ---------- We still install the indirect trigger on /home as before: ---------- mount -o maptype=indirect,mapname=auto_home -t autofs autofs /home ---------- When a process traverses into the /home/userD directory, the following environment variables are passed to the /sbin/hotplug agent: ---------- MOUNTFD=0 MAPNAME=auto_home MAPKEY=userD MAPOFFSET=/ ---------- The agent takes this information and performs the following actions: o lookup 'userD' in map 'auto_home' o parse entry o lookup offset '/' in entry o mkdir('/tmp/') // no root offset found! Install dummy filesystem: o mount -t tmpfs 'tmpfs' '/tmp/' // handle child offsets o mkdir(/tmp//server1) o mount -o maptype=indirect,mapname=auto_home,\ mapkey=userD,mapoffset=/server1 -t autofs 'autofs' '/tmp//server1' o mkdir(/tmp//server2) o mount -o maptype=indirect,mapname=auto_home,\ mapkey=userD,mapoffset=/server2 -t autofs 'autofs' '/tmp//server2' // remount the tmpfs filesystem read-only because it is just a dummy filesystem. o mount -o remount,ro '/tmp/' // move the tree of mounts onto the target directory o fchdir($MOUNTFD) o mount --move '/tmp/' '.' o rmdir('/tmp/') o exit(EXIT_SUCCESS) We use a tmpfs filesystem on /home/userD because we need to be able to create directories and we would like to have these directories exist on a filesystem that is expirable. Traditionally, the directory of the root offset for entries with no defined root offset is immutable. It may not be changed by any userspace program. We use the simple approach of remounting the filesystem read-only once we have created the directories to simulate this effect. The two nested direct mount triggers act as they normally would. 5.4 Expiry ---------- Handling expiry of mounts is difficult to get right. Several different aspects need to be considered before being able to properly perform expiry. In the existing Linux autofs implementations, the system works such that the userspace daemon will ask the autofs filesystem code to check to see if any of the automounted filesystems can expire (this is done by calling an ioctl on the base directory of the autofs filesystem). The autofs filesystem will then acquire the necessary locks and walk each of the currently mounted filesystems to see if anybody is using them. If the kernel code determines that a mount is ready to be expired, it sends the path back to the daemon. The daemon in turn unmounts it from userspace. This method of expiry has several problems: o The autofs filesystem really should know as little about VFS internal structures as possible. In this case, the filesystem code is charged with walking across mountpoints and manually counting reference counts. This task is much better left to the VFS internals. o Unmounting the filesystem from userspace is racy, as any program can begin using a mount between the time the daemon has received a path to expire and the time it actually makes the umount(2) system call. This sequence of events would make the expiry fail. Even worse, manually unmounting several mounts in a multimount can possibly lead to an expiry that fails to unmount after some of the mounts have already been unmounted, leaving the multimount in an inconsistent state. o Having userspace initiate mount expiry requires a userspace application to periodically make the query the kernel. This is done using a daemon, but as we have already discovered, automounting with a daemon does not work well when you are working in a multi-namespace environment. These points suggest that the kernel's VFS sub-system should be charged with handling expiry. Some of the benefits of having it perform this functionality over other ad-hoc solutions are: o All data structure specifics (like navigation and lock semantics) are maintained within the same component of the kernel. This improves maintainability and sustainability of the kernel proper and of individual filesystem implementations. o Other filesystems would like to have expiry functionality in the VFS sub-system. Providing this service at the VFS layer would reduce duplicated efforts between filesystems to support this functionality. Similar to this is the way the VFS layer provides read-only functionality for all filesystems from a higher level of abstraction. The following questions must be answered before a complete expiry solution is designed: o How will the kernel determine the expiry timeout value? In other words, how does it know how much time must pass for an unused mountpoint before it expires? We will need to pass timeout values in from userspace. The simplest method to pass this information to the kernel is to pass it to the VFS layer as a mount option. This option is tentatively named 'vfsexpire' and will accept a timeout value given in seconds. [[[Unfortunately, the current mount system calls do not allow arbitrary information to be passed directly to the VFS layer if they cannot be represented as a boolean flag. A new set of system calls and interface semantics will need to be thought about and implemented for this mount option to be available.]]] As described above, we may be installing multiple mounts upon each trigger. This tree of mounts will need to expire together as an atomic unit. We will need to register this block of mounts to some expiry system. This will be done by performing a remount on the base automounted filesystem after any nested offset mounts have been installed o How will the VFS layer verify that a filesystem is inactive? The VFS layer can atomically peek into the mountpoint structures (struct vfsmount) and look at the given reference counts to determine whether a filesystem is currently active or not. Reference counting alone does not solve the issue of having to be able to atomically unmount several mountpoints. This is evident when lazy-mounting is considered. We would like to expire a base mountpoint that may optionally have nested autofs mounts ready to catch a trigger. These nested mounts increase the reference count on the base mount, and thus need to be considered as counting towards the total reference count. These nested mounts in turn must recursively also be inactive for the base mount to expire. The proposed semantics are as follows: o A mount may be made without the vfsexpire mount option. In this case, the value defaults to 0, specifying that this mountpoint will never expire. o A mount may be made with the vfsexpire=n mount option. This specifies that the kernel may detach this mount at some time after at least n seconds have passed with the mount inactive. o An existing mountpoint may be remounted with vfsexpire=0. This signifies that if this mountpoint was to previously set to expire, it no longer will. o An existing mountpoint may be remounted with vfsexpire=n, where n is non-zero. This signifies that this mountpoint together with any mountpoints currently underneath it will expire atomically. That is to say, if all of the said mounts are inactive (no one is using any of them, and nothing else is later mounted within them), only then will the entire tree of mounts expire together. This is an all or nothing expiry, where a hierarchy of mountpoints expires as a single unit. We require that a tree of mounts be able to expire atomically together to ensure that we do not wind up with a partial expiry. A partial expiry would break our ability to lazy mount as some of the nested autofs filesystems would no longer be mounted. Such an arrangement would remain inconsistent until the root of the expiry is unmounted. The unmount itself will be performed within the kernel. Doing so assures that the unmount occurred while nobody was accessing the filesystem. Further details on how native expiry support may be implemented are described below in section 6.2. 5.5 Handling Changing Maps -------------------------- In a network that uses automounting in abundance, it is expected that maps will change fairly often. It is desirable that systems using the new automounting architecture will stay coherent with the maps provided by the nameservices on the network. Before designing a strategy to handle changing maps, it is important to first understand what types of changes can occur. Table 1 describes a cross-section of map entry types and of the types of changes that may occur. This cross-section view allows us to identify how map changes are propagated to a running configuration given the automount system described thus far. Table 1 - Strategies for Changing Maps Entry Modified | Entry Removed | Entry Added ____________________________________________________ Direct Entry | | | (in direct map | Updated on | Requires | Requires included from | Expiry | Removal | Addition auto_master) | | | -----------------|---------------------------------------------------- Indirect Map | Requires | | (as listed in | updated | Requires | Requires auto_master) | associated | Removal | Addition | context | | -----------------|---------------------------------------------------- Indirect Entry | | | | Updated on | Updated on | Works | Expiry | Expiry | | | | -----------------|---------------------------------------------------- Most of the changes that may occur get propagated to a running system the next time a trigger is performed. This means that any updates to maps for an already mounted system becomes active after an expiry occurs. Each triggering action causes a new map lookup to occur. These map lookups will cause the trigger to receive any new modified entries. 5.5.1 Base Triggers ``````````````````` There are however certain conditions where a running system will not be completely in sync with changing maps. These changes involve the modification of the master map as well as any direct maps. Entries in these maps will need to be reflected on the running system by running a utility program that will synchronize the map contents against the filesystem layout on a running machine. This will involve adding or removing direct and indirect mountpoints as well as refreshing the context associated with each indirect mountpoint. A utility program will need to create a delta between the running system and the master map and direct maps involved. This information is available from the proc filesystem (/proc/self/mounts). The program will then be able to identify any entries that would have come from the master or direct maps (by finding the autofs filesystem that are mounted on unique paths prefixes) and add and remove filesystems from the running namespace to bring the mount table in line with the maps. We must also consider the case where indirect entries from the master map and direct entries from direct maps are installed and the maps subsequently change. In order to handle updating the context associated with the indirect trigger filesystem atomically, a remount is performed on the autofs filesystem with the new context passed as mount options. A simple approach would allow the remount to happen on a pathname because the following assumptions hold: o The filesystem is an indirect filesystem, which will never be covered by another filesystem. If it is, then it is not updated. o Because it is an indirect filesystem, remounting it will not cause any other filesystems to be incorrectly triggered (because the base directory of the filesystem is immediately available). However, there remains the issue of a direct map entry that changes from one map to another, or is removed from the direct map set. Access to a direct map mount is not available when it is covered by another filesystem, and accessing it directly by pathname would in turn cause the direct mount to trigger and mount a different filesystem. Because of these problems, we need to define some method that allows a direct mount to be accessible in a manner that would not trigger a new mount, nor follow into any overlaying mounts. The proposed solution is to adopt a new interface that allows user space to navigate mountpoints on a given system. The goal is to use this navigation in conjunction with mount operations (such as unmounting and re-mounting with new options) to reconfigure an automount system and bring it up-to-date with all of the changing maps. Such a system for navigating mountpoints is described below in section 6.1. 5.5.2 Forcing Expiry to Occur ````````````````````````````` Given a new interface that allows the navigation of mountpoints within a namespace, we now have the ability to force expiry completely from userspace. Forcing expiry to occur becomes as trivial as writing a simple utility that gets the mountpoint file descriptor for the root filesystem and traverses across all mountpoints. Whenever this utility would see a mountpoint of type 'autofs', we would walk amongst its immediate child mountpoints and performing a lazy unmount on each child mountpoint [[[See umount(8), 'Lazy unmount'.]]]. Similarly, we can also remove all autofs filesystems from a given namespace by lazy unmounting them as well. 5.6 The Userspace Utility ------------------------- The userspace utility program to be used in administrating an automounted system would preferably be called 'automount'. It would fulfill the following functions: ---------- automount install [mastermapname] ---------- This action would go through the master map (overridden by the mastermapname) and would install triggers within the running namespace. [[[The master map (with default value '/etc/auto_master') will need to be accessible from the calling namespace, as would any other file map references.]]] ---------- automount refresh ---------- This action would go through the current namespace and update the base autofs filesystems as described in the section titled "Base Triggers". It would not perform a lazy unmount of all the mounted filesystems. ---------- automount detachall ---------- This action would perform a lazy unmount on all the automounted filesystems. ---------- automount uninstall ---------- This action would remove all autofs triggers from the current namespace. 6 New Facilities ================ The following sub-sections describe in high-level detail the new facilities that are needed in order to fully support a robust automount system. The descriptions that follow are in places deliberately over-simplified as several of their design aspects are open for much discussion and debate. It is hoped that the ideas below are well entertained. It is the intent of the author to further investigate details for each concept introduced and to propose more elaborate requests for comments to the community. Suggestions and comments are most welcomed for the sections that follow. 6.1 Mountpoint file descriptors ------------------------------- Mountpoint file descriptors are intended to describe mountpoints as first-class citizens within the Linux environment. By being able to describe mountpoints using file descriptors, we allow programmers and system administrators to continue using the tools they are used to, while at the same time enriching the semantics allowed for mountpoints. Some of the desired benefits of describing mountpoints as file descriptors are as follows: o We wish to be able to use common APIs such as read(2) and write(2) to communicate with a mountpoint. This would be useful for communicating mount options specific to the filesystem, as well as with the VFS layer directly. o We wish to be able to enumerate mountpoints somehow such that they may be modified without causing any path traversals to occur. This has the added benefit that we may access mountpoint configurations for mountpoints that are covered by other filesystems. These mountpoint descriptors will most likely be accessible via a new mount system call, mount2. Mount2 will multiplex the following actions: o 'Mount' -- Take a mountpoint file descriptor and mount it on a directory, specified by a second file descriptor. o 'Unmount' -- Given a mountpoint file descriptor, attempt to unmount the filesystem if it isn't busy. o 'LazyUnmount' -- Given a mountpoint file descriptor, detach the filesystem from its namespace. Perform a lazy cleanup of resources when the filesystem is no longer in use. o 'ForcedUnmount' -- Given a mountpoint file descriptor, force an unmount to occur. Forcing unmounts is useful for filesystems such as hung NFS shares. o 'Bind' -- Given a source directory file descriptor, create a new mountpoint file descriptor that can later be mounted on any given directory file descriptor using the Mount sub-command. o 'GetMfd' -- Given a directory file descriptor, this command will return the directory's associated mountpoint file descriptor if the directory is the base of a mountpoint. o 'GetDirFd' -- Given a mountpoint file descriptor, this command will return an open directory as a file descriptor. This directory file descriptor will represent the base of the mountpoint as described by the mountpoint file descriptor. o 'GetFirstChild/GetNextChild' -- Facilities will also be put in place to navigate the children mountpoint file descriptors of a given mountpoint file descriptor. Reading from a mountpoint file descriptor will result in a summary of the underlying filesystem, such as its type, the options it is using and its absolute path within the current namespace. When a mountpoint file descriptor is unmounted using either the Unmount or LazyUnmount commands, the mountpoint it represents would remain valid. Instead of being directly associated within a namespace, the mountpoint is considered 'floating'. A floating mountpoint can be re-associated with a namespace by performing the Mount command. One of the benefits of floating mountpoints is that one can mount a filesystem without associating it with a namespace. The floating mountpoint can then be navigated by first acquiring the base directory of the mountpoint using the GetDirFd command and then changing the current working directory to it using fchdir(2). Because of the way support for forcing unmounts is implemented, the ForcedUnmount command will invalidate the given mountpoint file descriptor upon successful completion. Any attempts to access the base directory on a forcefully unmounted filesystem will result in an error. Together, these commands allow one to implement all of the mount operations with which we are familiar. For example, assuming a filesystem is mounted at /from, a move operation can be achieved in the following steps: ---------- sourcefd = open("/from") targetfd = open("/to") mfd = mount2(GetMfd, sourcefd) mount2(LazyUnmount, mfd) mount2(Mount, mfd, targetfd) ---------- This example takes advantage of the fact that the underlying filesystem is still valid when it is lazily unmounted. We effectively disassociate the filesystem with the current namespace (using LazyUnmount) and then re-associate it back with the namespace by calling Mount. Similarly, a recursive bind operation may be done by recursively visiting each mountpoint and creating new floating mountpoints using the Bind operation. These new mountpoints may be stitched together in userspace using the Mount operation along with directory file descriptors obtained using the GetDirfd operation before finally associating the new tree of mountpoints in the namespace using the Mount operation. 6.2 Native Expiry Support ------------------------- David Howell from Red Hat has already implemented an expiry system that may eventually make it into the mainline kernel. His implementation is used to add automount functionality to the AFS filesystem. Specifically, the AFS filesystem implementation catches dangling symlinks whose symlink target is formatted to contain all the information needed in order to mount an AFS cell. His expiry implementation extends the VFS API such that one can construct a mountpoint and have it grafted into the current namespace's tree, while simultaneously linking the mountpoint into an expiry run list. This list is provided by the filesystem implementation. Linking into an expiry run list is handled by the VFS layer so that the filesystem itself need not worry about the locking semantics involved. The experimental AFS automount patch periodically calls a new VFS function, mark_mounts_for_expiry. This function will traverse a list of vfsmounts and determine which are not in use and marks them appropriately. These markings state that the mountpoint has been inactive since that last mark_mounts_for_expiry run. If a later mark_mounts_for_expiry run comes across a vfsmount that already has a marking and is still inactive, the mountpoint is scheduled to be detached from the namespace. These markings are cleared on all calls to mntput, so any user which uses the mount between calls to mark_mounts_for_expiry will either put the mountpoint in an active state, or transition back to an inactive state but also clear the marking. The mark_mounts_for_expiry patch has a few limitations that will need to be dealt with in order to completely integrate it with the VFS sub-system: o The VFS layer currently delegates the run of mark_mounts_for_expiry to each individual filesystem. The delegation forces duplicate code between filesystems that wish to support mountpoint expiry. It also keeps a user from marking arbitrary mounts as being expirable. Each filesystem type must hold onto a list_head for their own expiry list, of which the filesystem code is not allowed to traverse without acquiring VFS-owned locks. These lists should be consolidated into the VFS layer directly. The VFS layer would in turn periodically call mark_mounts_for_expiry. o Using a boolean marking forces the expiry timeout to be the within one and two times the period between calls to mark_mounts_for_expiry. This is fine, however it neglects the possibility of having per-mountpoint configurable timeouts. Greater configurability and granularity can be achieved by having each vfsmount store a timeout period value. Instead of using a boolean marking, a counter would be used that would count up to the timeout value before expiring. In the mark_mounts_for_expiry patch, expiry is specified by a call to do_add_mount. This call now takes an additional argument, a list_head used to enumerate all mountpoints that should expire. By having the VFS layer handle expiry natively, we would no longer need to have this API addition. Instead, the VFS layer would intercept the vfsexpire mount option and will update its mount table and internal expiry run list to reflect these changes. The proposed solution to this would see child mountpoints recursively associated as being part of an expiry when the parent mountpoint is linked into the expiry list. These associations will need to be cleared when any mountpoint manipulation occurs on the child mountpoints. They will be verified when checking the active state of the parent mountpoint to determine whether a child mountpoint is part of the parent mountpoint's expiry. The consistency of these associations will need to be managed by the VFS layer, which will simply remove any associations when a mountpoint is modified (possibly via a bind or a mountpoint move operation). The exception to this occurs when a namespace is cloned. In this case, any markings will need to be updated to remain consistent within the new namespace. The following sequence of events and descriptions attempts to describe the semantics described above by example: ---------- mount -o vfsexpire=10 /dev/hda1 /usr ---------- The mountpoint at /usr is set to expire after ten seconds. ---------- mount /dev/hda2 /usr/src ---------- The mountpoint at /usr cannot expire because it is held busy by the filesystem mounted at /usr/src. ---------- mount -o remount,vfsexpire=20 /usr ---------- The mountpoint at /usr will now expire along with /usr/src after 20 seconds of both mountpoints being inactive. They will expire together atomically; e.g. Under no circumstances will /usr/src be unmounted by an expiry run without also removing the mountpoint at /usr. ---------- mount /dev/hda3 /usr/local ---------- The mountpoint at /usr cannot expire because it now has a new child mountpoint that is not associated with the expiry. ---------- mount --move /usr/local /local ---------- The mountpoint at /usr can now expire along with /usr/src after 20 seconds because it no longer has any child mountpoints that aren't associated with the expiry. ---------- mount --move /usr/src /src ---------- The mountpoint that was at /usr/src will no longer expire. Its association with the expiry of /usr is lost. The mountpoint at /usr will continue to expire after 20 seconds of inactivity. ---------- mount --move /src /usr/src ---------- The mountpoint at /usr will not expire because it is held busy by the mountpoint at /usr/src. ---------- mount -o remount,vfsexpire=0 /usr ---------- The mountpoint has its expiry disabled. 6.3 Cloning super_block ----------------------- When a namespace is cloned, all the super_blocks for each of the currently mounted filesystems are shared between both old and new namespaces. Because filesystem-specific mount options are stored at the super_block layer, this creates the problem that changes to a mounted filesystem will affect all occurrences of the associated super_block. Sharing a super_block across namespaces opens the door to cross namespace tampering and contradicts our goal of keeping namespace configurations as isolated as possible. The implications are less apparent with other types of filesystems. For example, given that an ext3 filesystem may be mounted in several places, it is a fundamental requirement that there only exists one running configuration of the ext3 filesystem at a given time, i.e. you wouldn't want to mount the filesystem in one place with data=journal and in another location with data=ordered (two contradicting options). This running configuration is represented as a single super_block, and the VFS layer ensures that only one super_block exists for any block device-backed filesystem. There is no such requirement for pseudo-device filesystems (those which do not have block devices backing them). In order to allow namespaces to be cloned without letting changes within one namespace effect the other, we must develop a way for mount options to be kept distinct across the clone. Several alternatives are possible, some more immediate than others: 1) Do nothing. Allow cloned namespaces to share automount configuration within shared super_blocks. Pros: o No special work needs to be done Cons: o Can never be sure if a super_block is associated with a different namespace. This is a breach of isolation between namespaces. o It becomes impossible to clone a namespace and update the automount configuration without affecting other namespaces save unmounting all autofs filesystem occurrences and replacing them with new instances. Unfortunately, this option is not very viable as it does not achieve our goal of isolating automount configuration across cloned namespaces. A more complex method needs to be devised: 2) Allow a super_block to clone itself for the purposes of namespace cloning. This is preferably implemented as a new optional callback in super_operations. When called, the callback will generate a new super_block instance with the same configuration as the input instance. All directory entries (dentries) and inodes of the input super_block will also need to be duplicated so that filesystems mounted on top of the cloned filesystem may be stitched into the new namespace. Pros o Allows completely distinct automount triggers across cloned-namespaces. o Filesystems that are mounted within a cloned super_block will still be accessible within the new namespace. Cons o Duplicating all dentries and inodes for a given super_block in a consistent manner is not feasible given the locking and coherency semantics involved. Unfortunately, the second option does not lend itself to dealing with cloning any sub-mountpoints easily. Mountpoints are internally dependent on dentries, which in turn are dependent on super_blocks. In order to clone a complete namespace while allowing the cloning of super_blocks as discussed in the second option above, we would have to not only clone the super_block, but also recreate any dentries and inodes associated with the super_block. This is a very difficult task to accomplish given the locking and coherency semantics involved. This method is the only possible way conceived of guaranteeing the isolation of automount trigger configurations across cloned namespaces. The capability to clone super_blocks is needed and further investigation as to how this can be accomplished is required. 6.3.1 The --bind problem ```````````````````````` When a mountpoint is bound (using mount(8)'s --bind option), the system is left in a state where two mountpoints exist that both use the same super_block. This leads to questionable behavior. Should remount options on one mountpoint affect the other? These semantics are currently being worked out, especially with the soon-to-be introduced per-mountpoint read-only mount option. For the sake of simplicity, we may choose not to clone super_blocks for mountpoints when the mount bind operation occurs. However, this leads to strange semantics when mixed with the cloning of namespaces. For example, consider an autofs filesystem located at /foo. Super_blocks are shared on bind operations, so, ---------- mount --bind /foo /bar ---------- would result in two mountpoints sharing the same super_block. This allows any configuration changes performed on /foo to also affect /bar. Assuming we naively clone super_blocks for autofs filesystems and a new namespace is then created, each of the mountpoints mentioned would each get its own super_block. With independent super_blocks for each mountpoint, changes to /foo would no longer affect the autofs mountpoint on /bar. The semantic of blindly cloning super_blocks for each mountpoint regardless of the number of mountpoints using the super_block results in a derived namespace that does not behave in exactly the same way as its parent namespace. For these reasons, we extend the semantic description of cloning super_blocks when cloning namespaces. Instead of simply cloning the super_blocks that require it as we traverse the namespace, we keep a list of the cloned super_block pairs and re-use the newly cloned super_blocks for each mountpoint duplicated that referred to the ancestor super_block. This solves the --bind problem by ensuring that any mountpoints that referred to a single super_block will continue referring to a single super_block within the new namespace and that the two namespaces will continue to behave alike. 7 Scalability ============= Moving from the customary practice of using a daemon to using a usermode helper to perform automounting brings up the question about scalability. In this design, a new process is created every time a trigger occurs. This may lead to many small processes being created that have a very short lifespan. As such, the problem of having a lot of process overhead becomes a possible issue. The memory footprint for running a lot of small processes also becomes an issue. The argument against these claims is that the process overhead in Linux is comparatively small, and is far outweighed by any network communication that will be occurring as part of the automount process. The time spent communicating with networked nameservices (such as NIS or LDAP),latency spent in communicating with networked nameservices (such as NIS or LDAP) as well as network communication with a remote NFS server is many magnitudes larger than the overhead introduced by spawning a new process. There does, however, remain the possibility of a denial of service attack by a user attempting to simultaneously trigger all of the automount triggers in a large system. Appropriate countermeasures to such activities can be put in place, such as defining a maximum possible number of simultaneous automounts triggered by a given user. This kind of issue remains an area of research and suggestions are welcome in dealing with this problem. 8 Conclusion ============ Linux automounting has always lacked full support for Solaris-style automount maps. This has long been the case due to technical limitations imposed by design as well as to lack of interest and time by the primary developers. It is our goal to make Linux able to support Solaris-style automounter maps completely and reliably. In order to achieve this goal, we need to redesign the way automounting works. Namespaces provide a new and exciting way of dealing with security concerns, however, they make the problem space of automounting much more complex. By using a usermode helper in lieu of a daemon, we gain namespace accessibility. Namespace-local automount configuration and mount operations are at our disposal. We also gain the benefit of no longer having to maintain state in userspace, a task which is vulnerable to subtle changes in semantics (""Simultaneous" mounts causing weird behaviour" http://linux.kernel.org/pipermail/autofs/2003-November/000367.html). We also take the opportunity to define the semantics of automounting across cloned namespaces. These semantics require the ability to clone super_blocks in order to isolate automount configurations across namespaces. This appears at first to be an ugly hack, but in reality it makes sense considering the options that are available. Another automounting task that has always caused problems in the past is the expiry of mountpoints. By moving mountpoint expiry into the VFS layer where it belongs, we eliminate any possible races. Expiring mountpoints also becomes available to anyone wishing to do so, whether it be part of the automount process or not. Related to expiry is the ability for userspace to reliably navigate mountpoints so that covered mountpoints may be accessed and remounted. We've outlined a possible solution that will accommodate this need. The semantics involved are not yet completely defined and require insight from the primary consumers of such an interface. It is hoped that the design outlined in this document is thorough enough to spark discussion as to how automounting should be implemented in the future. By implementing the core kernel facilities listed above, it is felt that a complete automount solution may be developed. This implementation would be completely capable of handling Solaris-style automount maps and would continue to work reliably in a multi-namespace environment. --------------010205070700060103030200-- --------------enig0477A4B7AFFA9B1FED23E6A8 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE/+xKxdQs4kOxk3/MRAkDsAJ44LuSeEaAAUjO03+Iq46Cddxh2bQCdEE8v 49W/XYchtvgn51dRQaRmlCE= =mBuT -----END PGP SIGNATURE----- --------------enig0477A4B7AFFA9B1FED23E6A8-- --===============38600530579307429== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============38600530579307429==-- From autofs-bounces@linux.kernel.org Tue Jan 6 13:06:22 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i06L6Lc6024585 for ; Tue, 6 Jan 2004 13:06:22 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06L3f1x006755; Tue, 6 Jan 2004 13:03:48 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06L2X1v006623 for ; Tue, 6 Jan 2004 13:02:33 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id NAA31393; Tue, 6 Jan 2004 13:02:06 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma031383; Tue, 6 Jan 04 13:01:43 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i06L1lU03855; Tue, 6 Jan 2004 13:01:47 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) by neocesium.transmeta.com (8.11.6/8.11.6) with ESMTP id i06L1lY30348; Tue, 6 Jan 2004 13:01:47 -0800 Message-ID: <3FFB223A.8000606@zytor.com> Date: Tue, 06 Jan 2004 13:01:46 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs References: <3FFB12AD.6010000@sun.com> In-Reply-To: <3FFB12AD.6010000@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Mike Waychison wrote: > > The attached paper was written an attempt to design an automount system > with complete Solaris-style autofs functionality. This includes > browsing, direct maps and lazy mounting of multimounts. The paper can > also be found online at: > Sorry to sound like sour grapes, but this is a requirements document, not a proposed implementation. Furthermore, as I have expressed before, I think your claim that expiry should be done in the VFS to be incorrect. I think you're on the completely wrong track, because you're starting with the wrong problem. The implementation needs to start with the VFS implementation and derive from that. Finally, throwing out the daemon is a huge step backwards. Most of the problems with autofs v3 (and to a lesser extent v4) are due to the *lack* of state in userspace (the current daemon is mostly stateless); putting additional state in userspace would be a benefit in my experience. Pardon me for sounding harsh, but I'm seriously sick of the oft-repeated idiocy that effectively boils down to "the daemon can die and would lose its state, so let's put it all in the kernel." A dead daemon is a painful recovery, admitted. It is also a THIS SHOULD NOT HAPPEN condition. By cramming it into the kernel, you're in fact making the system less stable, not more, because the kernel being tainted with faulty code is a total system malfunction; a crashed userspace daemon is "merely" a messy cleanup. In practice, the autofs daemon does not die unless a careless system administrator kills it. It is a non-problem. -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 6 13:54:22 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i06LsMc6009074 for ; Tue, 6 Jan 2004 13:54:22 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06Lq91x018441; Tue, 6 Jan 2004 13:52:11 -0800 Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06LpO1v018323 for ; Tue, 6 Jan 2004 13:52:07 -0800 Received: from scl1.sfbay.sun.com ([10.6.72.41]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id i06LpNbs015667; Tue, 6 Jan 2004 14:51:23 -0700 (MST) Received: from scl1.sfbay.sun.com (localhost.localdomain [127.0.0.1]) by scl1.sfbay.sun.com (8.12.10/8.12.10) with ESMTP id i06LoIuF001443; Tue, 6 Jan 2004 13:50:19 -0800 Received: (from th122948@localhost) by scl1.sfbay.sun.com (8.12.10/8.12.10/Submit) id i06LoInd001441; Tue, 6 Jan 2004 13:50:18 -0800 Date: Tue, 6 Jan 2004 13:50:18 -0800 From: Tim Hockin To: "H. Peter Anvin" Subject: Re: [autofs] [RFC] Towards a Modern Autofs Message-ID: <20040106215018.GA911@sun.com> References: <3FFB12AD.6010000@sun.com> <3FFB223A.8000606@zytor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FFB223A.8000606@zytor.com> User-Agent: Mutt/1.4.1i X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Mike Waychison cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: thockin@sun.com List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, Jan 06, 2004 at 01:01:46PM -0800, H. Peter Anvin wrote: > Finally, throwing out the daemon is a huge step backwards. Most of the > problems with autofs v3 (and to a lesser extent v4) are due to the > *lack* of state in userspace (the current daemon is mostly stateless); > putting additional state in userspace would be a benefit in my experience. Can you maybe share some details? I think this deign moves MORE state to userspace (expiry aside). The "state" in kernel is really mostly sent back to userspace. No more passing pipes into the kernel (state) or tracking the pgid of the daemon (state). > Pardon me for sounding harsh, but I'm seriously sick of the oft-repeated > idiocy that effectively boils down to "the daemon can die and would lose > its state, so let's put it all in the kernel." A dead daemon is a > painful recovery, admitted. It is also a THIS SHOULD NOT HAPPEN But it *does* happen. > condition. By cramming it into the kernel, you're in fact making the > system less stable, not more, because the kernel being tainted with > faulty code is a total system malfunction; a crashed userspace daemon is I don't think this design crams anything into the kernel. It doesn't put a whole lot more into the kernel than is currently in there (expiry and new mount stuff, aside). All the work still happens in userland. The daemon as it stands does NOT handle namespaces, does NOT handle expiry well, and is a pretty sad copy of an old design. > "merely" a messy cleanup. In practice, the autofs daemon does not die > unless a careless system administrator kills it. It is a non-problem. I have some customers I'd love to send to you, if you really think that's true. _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 6 13:54:37 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i06LsWc6009080 for ; Tue, 6 Jan 2004 13:54:37 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06Lk51x017221; Tue, 6 Jan 2004 13:46:07 -0800 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06LjA1v016620 for ; Tue, 6 Jan 2004 13:46:03 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i06Lj1j6029819 for ; Tue, 6 Jan 2004 13:45:05 -0800 (PST) Received: from sun.com (vpn-129-152-200-55.East.Sun.COM [129.152.200.55]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HR300CHL8EYDL@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Tue, 06 Jan 2004 13:45:02 -0800 (PST) Date: Tue, 06 Jan 2004 16:44:51 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: <3FFB223A.8000606@zytor.com> To: "H. Peter Anvin" Message-id: <3FFB2C53.7050003@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <3FFB12AD.6010000@sun.com> <3FFB223A.8000606@zytor.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============58421379551346919==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============58421379551346919== Content-type: multipart/signed; boundary=------------enigFA655EAB592CAF75661002DC; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigFA655EAB592CAF75661002DC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Peter, H. Peter Anvin wrote: >Mike Waychison wrote: > > >>The attached paper was written an attempt to design an automount system >>with complete Solaris-style autofs functionality. This includes >>browsing, direct maps and lazy mounting of multimounts. The paper can >>also be found online at: >> >> >> > >Sorry to sound like sour grapes, but this is a requirements document, >not a proposed implementation. > You surely read the whole thing, didn't you? >Furthermore, as I have expressed before, >I think your claim that expiry should be done in the VFS to be incorrect. > > Why? You haven't convinced me that it should be elsewhere. >I think you're on the completely wrong track, because you're starting >with the wrong problem. The implementation needs to start with the VFS >implementation and derive from that. > > In which sense? Re-design it? >Finally, throwing out the daemon is a huge step backwards. Most of the >problems with autofs v3 (and to a lesser extent v4) are due to the >*lack* of state in userspace (the current daemon is mostly stateless); >putting additional state in userspace would be a benefit in my experience. > > Bull. Having a single process for each autofs filesystem is state in itself. Eg: - setup an auto_home map on /home - mkdir /home2 - mount --bind /home /home2 The state that you manage with your automount processes themselves is now inconsistent with what the kernel has. >Pardon me for sounding harsh, but I'm seriously sick of the oft-repeated >idiocy that effectively boils down to "the daemon can die and would lose >its state, so let's put it all in the kernel." A dead daemon is a >painful recovery, admitted. It is also a THIS SHOULD NOT HAPPEN >condition. > You've completely discarded the fact that a daemon breaks namespaces in your argument. You somehow mistook the arguments I've presented and assume that we get rid of the daemon solely so that we eliminate state in userspace. The point of getting rid of the daemon is that tying a single process to each mountpoint: - breaks on mount --bind operations - breaks on namespace clones These _can_ be circumvented by using a single process daemon which catches _ALL_ automount requests from the kernel, however: - There are NO facilities for changes namespaces, and there doesn't appear to be any plans to implement them. This doesn't only affect the mount operations themselves, but also reading the /etc/auto_* maps in the different namespace. - This limits a running system to _exactly_ one policy system for handling automount points. Differing namespaces may have different automounter maps and even automounters themselves if they want to under the scheme I've outlined. Also, the current implementation uses pathnames to do everything. This breaks: - mountpount binds in another way - mountpoint moves My goal here is to fix all of the mountpoint logic in automounting that relies on there being a single namespace. Now, going back to your argument of reliability and reconnectivity, yes, I agree that the daemon dying is something that _SHOULD NOT HAPPEN_. But it does in practice. Getting rid of the daemon the way I've outlined simply eliminates that from ever happening as an added bonus. >By cramming it into the kernel, you're in fact making the >system less stable, not more, because the kernel being tainted with >faulty code is a total system malfunction; a crashed userspace daemon is >"merely" a messy cleanup. In practice, the autofs daemon does not die >unless a careless system administrator kills it. It is a non-problem. > > "Faulty code"? I haven't even presented you with code yet. Nice. Somehow, you got the impression that the system I've proposed would be more complex than what we have today, when in fact I believe it's a lot simpler. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enigFA655EAB592CAF75661002DC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE/+yxWdQs4kOxk3/MRAjKQAKCe3A7/yM0HUk/PVCUb/wLbFnBoTACfbrcb woOVPXR3MD5ahERj6+zyzNg= =rTHq -----END PGP SIGNATURE----- --------------enigFA655EAB592CAF75661002DC-- --===============58421379551346919== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============58421379551346919==-- From autofs-bounces@linux.kernel.org Tue Jan 6 14:09:53 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i06M9qc6009125 for ; Tue, 6 Jan 2004 14:09:52 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06M7A1x021758; Tue, 6 Jan 2004 14:07:17 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06M791v021751 for ; Tue, 6 Jan 2004 14:07:09 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id OAA01833; Tue, 6 Jan 2004 14:06:34 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma001822; Tue, 6 Jan 04 14:06:30 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i06M6YU08789; Tue, 6 Jan 2004 14:06:34 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) by neocesium.transmeta.com (8.11.6/8.11.6) with ESMTP id i06M6YY31332; Tue, 6 Jan 2004 14:06:34 -0800 Message-ID: <3FFB316A.6000004@zytor.com> Date: Tue, 06 Jan 2004 14:06:34 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: thockin@sun.com Subject: Re: [autofs] [RFC] Towards a Modern Autofs References: <3FFB12AD.6010000@sun.com> <3FFB223A.8000606@zytor.com> <20040106215018.GA911@sun.com> In-Reply-To: <20040106215018.GA911@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Mike Waychison cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Tim Hockin wrote: > On Tue, Jan 06, 2004 at 01:01:46PM -0800, H. Peter Anvin wrote: > >>Finally, throwing out the daemon is a huge step backwards. Most of the >>problems with autofs v3 (and to a lesser extent v4) are due to the >>*lack* of state in userspace (the current daemon is mostly stateless); >>putting additional state in userspace would be a benefit in my experience. > > Can you maybe share some details? I think this deign moves MORE state to > userspace (expiry aside). The "state" in kernel is really mostly sent back > to userspace. No more passing pipes into the kernel (state) or tracking the > pgid of the daemon (state). > If you want to fire up a new daemon, all that state that was supposed to be kept in userspace has to be reconstructed. That means the kernel has to have all that information; this would include stuff like what kind of umount policy you want for each key entry (the current daemon doesn't do that because it doesn't have the proper state.) >>Pardon me for sounding harsh, but I'm seriously sick of the oft-repeated >>idiocy that effectively boils down to "the daemon can die and would lose >>its state, so let's put it all in the kernel." A dead daemon is a >>painful recovery, admitted. It is also a THIS SHOULD NOT HAPPEN > > But it *does* happen. I don't believe it happens on any significant degree in cases where you wouldn't have a kernel panic if you put the stuff in the kernel, *or* a careless system admininistrator killed it. In fact, I suspect it's virtually all the latter. >>condition. By cramming it into the kernel, you're in fact making the >>system less stable, not more, because the kernel being tainted with >>faulty code is a total system malfunction; a crashed userspace daemon is > > I don't think this design crams anything into the kernel. It doesn't put a > whole lot more into the kernel than is currently in there (expiry and new > mount stuff, aside). All the work still happens in userland. > > The daemon as it stands does NOT handle namespaces, does NOT handle expiry > well, and is a pretty sad copy of an old design. First of all, I'll be blunt: namespaces currently provide zero benefit in Linux, and virtually noone uses them. I have discussed this with Linus in the past, and neither one of us see namespaces as being worth jumping though hoops to support. That being said, it's doable by either having different daemons for different namespaces (useful for policy) or by having them gain access to the requisite namespaces. Second, what you say about the state of the daemon is obviously true. autofs v3 was developed on Linux 2.0 which had a vastly different VFS, and it has by and large bitrotted. Furthermore, at that point Linux didn't support threading in any useful way, which meant that keeping the appropriate state the in daemon was too painful -- hence the largely stateless design with its associated problems. >>"merely" a messy cleanup. In practice, the autofs daemon does not die >>unless a careless system administrator kills it. It is a non-problem. > > I have some customers I'd love to send to you, if you really think that's > true. As root, I can kill the system too by doing "cat /dev/zero > /dev/mem". If you do stupid shit as root you're dead. What's the news? -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 6 14:23:58 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i06MNvc6009185 for ; Tue, 6 Jan 2004 14:23:57 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06MLs1x024997; Tue, 6 Jan 2004 14:21:56 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06MLr1v024990 for ; Tue, 6 Jan 2004 14:21:53 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id OAA02657; Tue, 6 Jan 2004 14:21:20 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma002643; Tue, 6 Jan 04 14:21:01 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i06ML5U09969; Tue, 6 Jan 2004 14:21:05 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) by neocesium.transmeta.com (8.11.6/8.11.6) with ESMTP id i06MKvY31617; Tue, 6 Jan 2004 14:21:05 -0800 Message-ID: <3FFB34C9.5010305@zytor.com> Date: Tue, 06 Jan 2004 14:20:57 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: Tim Hockin Subject: Re: [autofs] [RFC] Towards a Modern Autofs References: <3FFB12AD.6010000@sun.com> <3FFB223A.8000606@zytor.com> <20040106215018.GA911@sun.com> <3FFB316A.6000004@zytor.com> <20040106221502.GA7398@hockin.org> In-Reply-To: <20040106221502.GA7398@hockin.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs cc: linux-kernel X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Tim Hockin wrote: > On Tue, Jan 06, 2004 at 02:06:34PM -0800, H. Peter Anvin wrote: > >>>Can you maybe share some details? I think this deign moves MORE state to >>>userspace (expiry aside). The "state" in kernel is really mostly sent back >>>to userspace. No more passing pipes into the kernel (state) or tracking the >>>pgid of the daemon (state). >> >>If you want to fire up a new daemon, all that state that was supposed to >>be kept in userspace has to be reconstructed. That means the kernel has >>to have all that information; this would include stuff like what kind of >>umount policy you want for each key entry (the current daemon doesn't do >>that because it doesn't have the proper state.) > > I'm not really sure what you're saying., here. I'm sorry. Not trying to be > thick, just not understanding. > > What umount policy? What state is supposed to be kept in userspace that isn't? > The current autofs daemon, for example, does not handle different procedures on umount. This is particularly important when you have mount trees. > >>>The daemon as it stands does NOT handle namespaces, does NOT handle expiry >>>well, and is a pretty sad copy of an old design. >> >>First of all, I'll be blunt: namespaces currently provide zero benefit >>in Linux, and virtually noone uses them. I have discussed this with >>Linus in the past, and neither one of us see namespaces as being worth > > Let's get rid of them, then. Make life that much easier. > That's what the Linux community is doing, de facto. The Linux userspace simply is not set up to handle namespaces, and the autofs daemon is no exception. Consider such a simple thing as /etc/mtab - /proc/mounts which is necessary for most of the mount(8) functionality to work. It doesn't support namespaces and really cannot be made to. namespace support in Linux is at the best a far-off future goal. It is one thing to put in infrastructure, especially since it has some other nice benefits; it's another thing to revamp all of userspace to use it; it's nowhere close and autofs is no exception. -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 6 14:31:25 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i06MVOc6009399 for ; Tue, 6 Jan 2004 14:31:25 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06MTu1x026458; Tue, 6 Jan 2004 14:29:59 -0800 Received: from unogate.unocal.com (unogate.unocal.com [192.94.3.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06MT61v026371 for ; Tue, 6 Jan 2004 14:29:52 -0800 Received: from Halfdome.ad.unocal.com (localhost [127.0.0.1]) by unogate.unocal.com (8.12.10/8.12.10) with ESMTP id i06MT0iH002428; Tue, 6 Jan 2004 14:29:01 -0800 (PST) Received: from kestrel.ad.unocal.com ([134.248.1.123]) by Halfdome.ad.unocal.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2004 14:29:00 -0800 Received: from slexch2.ad.unocal.com ([134.248.127.15]) by kestrel.ad.unocal.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2004 14:29:00 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [autofs] [RFC] Towards a Modern Autofs Date: Tue, 6 Jan 2004 16:28:59 -0600 Message-ID: <6AB920CC10586340BE1674976E0A991D0C6BE4@slexch2.sugarland.unocal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [autofs] [RFC] Towards a Modern Autofs Thread-Index: AcPUoR5C3ApwrbkHQbyM7BUiXOUO2QAAOLvg From: "Ogden, Aaron A." To: , "H. Peter Anvin" X-OriginalArrivalTime: 06 Jan 2004 22:29:00.0366 (UTC) FILETIME=[7B3A76E0:01C3D4A4] X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hera.kernel.org id i06MT61v026371 cc: autofs mailing list cc: Mike Waychison cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: > -----Original Message----- > From: autofs-bounces@linux.kernel.org > [mailto:autofs-bounces@linux.kernel.org] On Behalf Of Tim Hockin > Sent: Tuesday, January 06, 2004 3:50 PM > To: H. Peter Anvin > Cc: autofs mailing list; Mike Waychison; Kernel Mailing List > Subject: Re: [autofs] [RFC] Towards a Modern Autofs > <...snip...> > > > Pardon me for sounding harsh, but I'm seriously sick of the oft-repeated > > idiocy that effectively boils down to "the daemon can die and would lose > > its state, so let's put it all in the kernel." A dead daemon is a > > painful recovery, admitted. It is also a THIS SHOULD NOT HAPPEN > > But it *does* happen. > > > condition. By cramming it into the kernel, you're in fact > > making the system less stable, not more, because the kernel being tainted with > > faulty code is a total system malfunction; a crashed userspace daemon is > > I don't think this design crams anything into the kernel. It > doesn't put a whole lot more into the kernel than is currently in there > (expiry and new mount stuff, aside). All the work still happens in userland. > > The daemon as it stands does NOT handle namespaces, does NOT handle expiry > well, and is a pretty sad copy of an old design. > > > "merely" a messy cleanup. In practice, the autofs daemon does not die > > unless a careless system administrator kills it. It is a non-problem. > > I have some customers I'd love to send to you, if you really > think that's true. Speaking as a sysadmin with 300+ machines (some linux, some solaris) using autofs, I can say that the linux autofs daemon does die on occasion, or at least some of the children become hung or unresponsive. This happened to us with autofs3 and autofs4, leading me to contact Ian Kent and become involved in testing new versions of autofs4. I don't have any problems with the newest versions (4.1.0+) but with previous code, 4.0.0pre10 for example, I found the ability to restart the daemon invaluable. On those occasions where the autofs daemon gets confused (loses track of mountpoints, gets corruption in its internal representation of NIS maps, etc.) we could shut down the autofs daemon, kill any remaining processes, and restart it from scratch. In most cases restarting the daemon fixes the problem. It's worth noting that I have seen this happen on Solaris 2.6 as well but it is extremely rare. On the solaris machine there was no automount daemon to restart so I was forced to reboot it to regain access to the 'missing' mountpoint. If you've read this far, what I'm trying to say is that having userspace related code remain in userland is a good thing since you can restart the daemon if something goes wrong. If you move all of this to kernel-space you can't do anything about it if there is a problem. In Solaris there is a command called 'automount' that tells the kernel to re-read the automount maps, perhaps it resets the autofs subsystem in the kernel as well. If linux autofs had the same capability we might not need the daemon, but until then, having the daemon in userland is a good thing. _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 6 14:51:26 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i06MpPc6026379 for ; Tue, 6 Jan 2004 14:51:26 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06MnL1x030951; Tue, 6 Jan 2004 14:49:22 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06MnJ1v030944 for ; Tue, 6 Jan 2004 14:49:19 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id OAA03996; Tue, 6 Jan 2004 14:48:49 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma003962; Tue, 6 Jan 04 14:48:32 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i06MmaU12145; Tue, 6 Jan 2004 14:48:36 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) by neocesium.transmeta.com (8.11.6/8.11.6) with ESMTP id i06MmaY31843; Tue, 6 Jan 2004 14:48:36 -0800 Message-ID: <3FFB3B44.9060106@zytor.com> Date: Tue, 06 Jan 2004 14:48:36 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: Dax Kelson References: <3FFB12AD.6010000@sun.com> <3FFB223A.8000606@zytor.com> <20040106215018.GA911@sun.com> <3FFB316A.6000004@zytor.com> <1073428129.2454.35.camel@mentor.gurulabs.com> In-Reply-To: <1073428129.2454.35.camel@mentor.gurulabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Mike Waychison cc: thockin@Sun.COM cc: Kernel Mailing List Subject: [autofs] Re: name spaces good X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Dax Kelson wrote: > On Tue, 2004-01-06 at 15:06, H. Peter Anvin wrote: > >>First of all, I'll be blunt: namespaces currently provide zero benefit >>in Linux, and virtually noone uses them. > > > I strongly disagree. > > I find them very useful, and there are lots of problems that are not > cleanly solved any other way. In particular they are very useful in > security hardening, compartmentalization scenarios. > Excellent... if so it would be useful to have a discussion about the proper semantics for these scenarios. So far the consensus opinion among most of the VFS people seems to have been "when you clone a namespace you get an unanimated namespace"; it would be useful ito know if that applies to your scenario, assuming it matters, and if so why/why not. Al Viro has been working on a key piece of infrastructure for doing autofs right called mount traps. This is the main reason -- even more so than the lack of time on my part -- that not much work has been done on the new version of autofs. mount traps, combined with "pseudo-symlinks" (non-S_IFLNK nodes which have follow_link methods), do most of the tasks that have been proven necessary in the kernel. The consensus I have seen seems to be that namespaces is mostly used, as you said, for compartmentalizing and security, you pretty much have two scenarios as far as I can see it: a) You're running autofs "outside" the compartmentalization, in a global namespace. b) You're running autofs "inside" the compartmentalization, then you don't want access to anything on the outside. You thus run the autofs "inside" and can't access anything else. -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 6 14:56:37 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i06Mubc6026428 for ; Tue, 6 Jan 2004 14:56:37 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06MsX1x032107; Tue, 6 Jan 2004 14:54:35 -0800 Received: from gate.nmr.mgh.harvard.edu (gate.nmr.mgh.harvard.edu [132.183.203.69]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06Mrf1v031993 for ; Tue, 6 Jan 2004 14:54:31 -0800 Received: from gate.nmr.mgh.harvard.edu (localhost [127.0.0.1]) i06MrYNv010043verify=NOT); Tue, 6 Jan 2004 17:53:35 -0500 Received: from localhost (raines@localhost)i06MrYTF010039; Tue, 6 Jan 2004 17:53:34 -0500 X-Authentication-Warning: gate.nmr.mgh.harvard.edu: raines owned process doing -bs Date: Tue, 6 Jan 2004 17:53:34 -0500 (EST) From: Paul Raines To: "Ogden, Aaron A." Subject: RE: [autofs] [RFC] Towards a Modern Autofs In-Reply-To: <6AB920CC10586340BE1674976E0A991D0C6BE4@slexch2.sugarland.unocal.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Mike Waychison cc: thockin@Sun.COM cc: Kernel Mailing List cc: "H. Peter Anvin" X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: As another sysadmin with 300+ linux and solaris boxes, I second you sentiments exactly. As my previous post today states, I am having exactly the problem you describe with automount daemons becoming hung or unresponsive. Guess I should give 4.1.0 a try. Of course the same arguement applies to NFS server but they went ahead and moved most of that into the kernel anyway for the performance gain. -- --------------------------------------------------------------- Paul Raines email: raines@nmr.mgh.harvard.edu MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street Charlestown, MA 02129 USA _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 6 15:29:55 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i06NTac6027292 for ; Tue, 6 Jan 2004 15:29:55 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06NR91x007097; Tue, 6 Jan 2004 15:27:16 -0800 Received: from unogate.unocal.com (unogate.unocal.com [192.94.3.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06NQJ1v006999 for ; Tue, 6 Jan 2004 15:27:07 -0800 Received: from ElCapitan.ad.unocal.com (localhost [127.0.0.1]) by unogate.unocal.com (8.12.10/8.12.10) with ESMTP id i06NQDYE026229; Tue, 6 Jan 2004 15:26:13 -0800 (PST) Received: from MTBALDY.ad.unocal.com ([134.248.213.5]) by ElCapitan.ad.unocal.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2004 15:26:12 -0800 Received: from slexch2.ad.unocal.com ([134.248.127.15]) by MTBALDY.ad.unocal.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2004 15:26:12 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [autofs] [RFC] Towards a Modern Autofs Date: Tue, 6 Jan 2004 17:26:11 -0600 Message-ID: <6AB920CC10586340BE1674976E0A991D0C6BE6@slexch2.sugarland.unocal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [autofs] [RFC] Towards a Modern Autofs Thread-Index: AcPUqCD2qVKyDejcQJCAz0KoQsjCQgAAwTuw From: "Ogden, Aaron A." To: "Paul Raines" X-OriginalArrivalTime: 06 Jan 2004 23:26:12.0377 (UTC) FILETIME=[78DDC890:01C3D4AC] X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hera.kernel.org id i06NQJ1v006999 cc: autofs mailing list X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: > -----Original Message----- > From: Paul Raines [mailto:raines@nmr.mgh.harvard.edu] > Sent: Tuesday, January 06, 2004 4:54 PM > To: Ogden, Aaron A. > Cc: thockin@Sun.COM; H. Peter Anvin; autofs mailing list; > Mike Waychison; Kernel Mailing List > Subject: RE: [autofs] [RFC] Towards a Modern Autofs > > > As another sysadmin with 300+ linux and solaris boxes, I second > you sentiments exactly. As my previous post today states, I am > having exactly the problem you describe with automount daemons > becoming hung or unresponsive. Guess I should give 4.1.0 a try. > > Of course the same arguement applies to NFS server but they went > ahead and moved most of that into the kernel anyway for the > performance gain. > I have been working with Ian for a long time, the improvements he's made since autofs-4.0.0pre10 have been tremendous. Although the people from Sun may not agree I think autofs 4.1.0 is mostly on par with Sun's autofs, at least from a sysadmin perspective. The code is still very new but I have not been able to break it yet... unlike previous versions. :-) If you are going to use autofs on linux I would highly recommend the latest version of autofs4, in my experience nothing else will cut it if you want your linux autofs to behave like what you are used to in Solaris. This includes the browsing/ghosting feature. Go to ftp://ftp.kernel.org/pub/linux/daemons/autofs/v4/ and get the latest tarball or source rpm. You can install the daemon with that but you also need to apply patches to the kernel module to get things working properly, the patches are included in the file you download. Good luck! _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 6 15:36:56 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i06Natc6009985 for ; Tue, 6 Jan 2004 15:36:56 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06NZ91x008616; Tue, 6 Jan 2004 15:35:10 -0800 Received: from unogate.unocal.com (unogate.unocal.com [192.94.3.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i06NYN1v008446 for ; Tue, 6 Jan 2004 15:35:07 -0800 Received: from Halfdome.ad.unocal.com (localhost [127.0.0.1]) by unogate.unocal.com (8.12.10/8.12.10) with ESMTP id i06NYBEG001049; Tue, 6 Jan 2004 15:34:12 -0800 (PST) Received: from kestrel.ad.unocal.com ([134.248.1.123]) by Halfdome.ad.unocal.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2004 15:34:11 -0800 Received: from slexch2.ad.unocal.com ([134.248.127.15]) by kestrel.ad.unocal.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 6 Jan 2004 15:34:11 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [autofs] [RFC] Towards a Modern Autofs Date: Tue, 6 Jan 2004 17:34:08 -0600 Message-ID: <6AB920CC10586340BE1674976E0A991D0C6BE7@slexch2.sugarland.unocal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [autofs] [RFC] Towards a Modern Autofs Thread-Index: AcPUp4GE367WqaZWQ/CBr8KhSB9ecQABRftA From: "Ogden, Aaron A." To: "Tim Hockin" X-OriginalArrivalTime: 06 Jan 2004 23:34:11.0302 (UTC) FILETIME=[9653F060:01C3D4AD] X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hera.kernel.org id i06NYN1v008446 cc: autofs mailing list cc: Mike Waychison cc: thockin@sun.com cc: Kernel Mailing List cc: "H. Peter Anvin" X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: > -----Original Message----- > From: Tim Hockin [mailto:thockin@hockin.org] > Sent: Tuesday, January 06, 2004 4:48 PM > To: Ogden, Aaron A. > Cc: thockin@Sun.COM; H. Peter Anvin; autofs mailing list; > Mike Waychison; Kernel Mailing List > Subject: Re: [autofs] [RFC] Towards a Modern Autofs > > > On Tue, Jan 06, 2004 at 04:28:59PM -0600, Ogden, Aaron A. wrote: > > Solaris there is a command called 'automount' that tells the kernel to > > re-read the automount maps, perhaps it resets the autofs subsystem in > > the kernel as well. If linux autofs had the same capability we might > > not need the daemon, but until then, having the daemon in userland is a > > good thing. > > That's more or less exactly what is proposed. > Excellent! I haven't read through the proposal yet but I have it open in another window. :-) The detailed proposal you've written implies that Sun as a whole has given serious thought to the problem, which IMHO is how to make linux autofs work like Solaris autofs. Is Sun willing to devote man-hours to help implement the new autofs? I think Ian has done a tremendous job with autofs4 but the more minds we throw at the problem the better. _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 03:48:53 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09BmnmF017226 for ; Fri, 9 Jan 2004 03:48:53 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09B8uvC022931; Fri, 9 Jan 2004 03:20:02 -0800 Received: from moving-picture.com (mpc-26.sohonet.co.uk [193.203.82.251]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09B6WvA022899 for ; Fri, 9 Jan 2004 03:07:58 -0800 Received: from darke.mpc.local ([172.16.11.6] helo=moving-picture.com) by moving-picture.com with esmtp (Exim 4.24) id 1AeuT2-0007uq-1e; Fri, 09 Jan 2004 11:06:16 +0000 Message-ID: <3FFE8B28.1E645E4E@moving-picture.com> Date: Fri, 09 Jan 2004 11:06:16 +0000 From: James Pearson Organization: Moving Picture Company X-Mailer: Mozilla 4.7 [en] (X11; I; IRIX64 6.5 IP30) X-Accept-Language: en MIME-Version: 1.0 To: nfs@lists.sourceforge.net, autofs@linux.kernel.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Disclaimer: This email and any attachments are confidential, may be legally X-Disclaimer: privileged and intended solely for the use of addressee. If you X-Disclaimer: are not the intended recipient of this message, any disclosure, X-Disclaimer: copying, distribution or any action taken in reliance on it is X-Disclaimer: strictly prohibited and may be unlawful. If you have received X-Disclaimer: this message in error, please notify the sender and delete all X-Disclaimer: copies from your system. X-Disclaimer: X-Disclaimer: Email may be susceptible to data corruption, interception and X-Disclaimer: unauthorised amendment, and we do not accept liability for any X-Disclaimer: such corruption, interception or amendment or the consequences X-Disclaimer: thereof. X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org Subject: [autofs] Busy inodes after unmount followed by Oops X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: There was a long thread a few months ago about this subject: http://marc.theaimsgroup.com/?t=106332683300004&r=1&w=2 and http://marc.theaimsgroup.com/?t=106340013500006&r=1&w=2 I've read the posts but as far as I can tell, I can't find a 'solution' to the problem (but I may have missed it in all the posts!) I have the same problem with a large number of dual CPU machines running 2.4.20 and above that make heavy use of autofs (v4.0.0pre10). We get a: VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice day... mesasage, followed some time later by Oops's from kswapd, umount or some other user application. Is there a 'fix' for this problem? Thanks James Pearson _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 10:38:53 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09IcqmF008438 for ; Fri, 9 Jan 2004 10:38:53 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09IMuvC020554; Fri, 9 Jan 2004 10:34:13 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09IKFvA019640 for ; Fri, 9 Jan 2004 10:21:48 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i09IK3522831; Sat, 10 Jan 2004 02:20:03 +0800 Date: Sat, 10 Jan 2004 02:20:03 +0800 (WST) From: Ian Kent X-X-Sender: To: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-Reply-To: <3FFD79C9.1040404@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.8, required 8, AWL, BAYES_01, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Thu, 8 Jan 2004, Mike Waychison wrote: > > > >Mike can you enlighten me with a few words about how namespaces are useful > >in the design. I have not seen or heard much about them so please be > >gentle. > > > > > Think I have enough on namespaces to understand your proposal now. Thanks. > >What is the form of the trigger talked about? Identifying the automount > >points in the autofs filesystem has always been hard and error prone. > > > > > > > I don't understand what you mean by the identifying part. However, the > 'trigger' would the traditional method used in autofsv3/4 for indirect > maps and probably based off what you already have for doing the browsing > stuff. > > The direct map 'triggers' will be taken care of by another filesystem > with a magic root directory that will catch traversals using some > follow_link magic. I wrote a prototype for this last summer, but > haven't released it as the userspace stuff completely does not fit in > with the existing daemon that was out at the time do the the mess of > glue that was pgids, pipes and processes. It worked in the simple > case, but it didn't extend to being able to direct mount an indirect > map, nor was it able to do the lazy mounting in multimounts as I had > desired. Is this the stuf that Al Viro is working on? > > >Please clearify what we are talking about WRT kernel support for > >automount. Is the plan a new kernel module or are we talking about > >unspecified 'in VFS' support or both? > > > > > > > This module will have its own new autofs module (hopefully named > something other than autofs to avoid confusion/mishaps). The VFS will > have native support for expiry. The VFS will also be slightly extended > to allow the super_block cloning on namespace clone (although this can > probably hold off a while, it's more a semantic issue than anything else). Yep. Got that as well. > > > > >Yes. In 4.1 NIS, LDAP and file maps are browsable for both direct and > >indirect maps. The browsability, only, requires my kernel patch. > >The daemon detects the updated modules' presence, and if the option is > >specified 'ghosts' the directories, mounting them only when accessed. > > > > > > > What is the difference between Solaris's -browse and your ghosting then? Well I don't know, nothing really. I was working to the requirement of providing browsable mount trees. The 'doing it properly' was secondary to satisfying my spec. Mind there are a number of things I haven't done. Since I don't have a need for tree-mounts (closest would be multi-mount) I haven't done anything there. As you say in v4 they are a mount/umount everthing. Consequenty, only the top level leaves are browsable. Indeed, I haven't solved my requirement of a transparent autofs filesystem aka. Solaris automounter again. A difficult problem that will require considerable effort. > > >>lstat('dir') > >>chdir('dir') > >>lstat('.') > >> > >> > > > >This suggestion has been made by others several times but doesn't seem > >to be a problem in practice. In all my testing I have only been able to > >find one case that does'nt work as needed when ghosted. This is the > >situation where a home directory in a map exported from a server, is > >actually not available (eg does not exist) and someone logs into the > >account using wu-ftpd. In this case wu-ftpd thinks all is ok but of course > >an error is returned when the directory access is attempted. In fact an > >error should have been returned at login. Further, I believe this can be > >solved with as little as an additional revalidate call in sys_stat (I > >think the problem call was sys_stst ???). > > > > > > > The find(1) issue is fairly recent. This check was added some time > within the last two years (?) and only appears in the latest distros. > > Another problem were the ACL patches for ls(1) and friends. I *really* > think they should be lgetxattr ing instead of getxattr. They even > explicitly check via an lstat _before hand_ to verify if the file > S_ISLNK, and only then will it getxattr if it isn't. Why not extend > it? I duno. Looks like I have more testing to do to get a better feel for the way this behaves. > > >>This is the subtle difference between direct and indirect maps. The > >>direct map keys are absolute paths, not path components. We are > >>implementing direct mounts as individual filesystems that will trap on > >>traversal into their base directory. This filesystem has no idea where > >>it is located as far as the user is concerned. We need to tell the > >>filesystem directly so that the usermode helper can look it up. > >>Conversely, the indirect map uses the sub-directory name as a mapkey. > >> > >> > > > >I'm not sure what you are saying here. Does this mean there is a mount for > >every direct mount (this might be what you call a trigger)? > > > > > > > Yes, it is its own filesystem (type autofs). This is needed because we > need to overlay direct triggers within NFS filesystems for multimounts. Ahh. I see, you are talking about the cross filesystem problem. I haven't solved that in what I have done either. Fortuneately I still get a good hit rate in satisfying peoples' needs as in practice many people don't use full automounter functionality. > > Browsing however obviously doesn't need that because we control the > parent directory. > > >AIX implemented automounts by mounting everything in each map. This > >made the mount listing very ugly. > > > > > > > ?? Really? I find that hard to believe. I thought Solaris shared it's > automounter with HPUX and AIX. I may be wrong though. Old versions perhaps. AIX 4.x was the last I used. It was definately like that then. 500+ automounts tends to cluter the mount display a bit. > >Mmm. The vfsmount_lock is available to modules in 2.6. At least it was in > >test11. I'm sure I compiled the module under 2.6 as well??? > > > >I thought that, taking the dcache_lock was the correct thing to do when > >traversing a dentry list? > > > > > > > Walking dentrys still takes the dcache_lock, however walking vfsmounts > takes the vfsmount_lock. dcache_lock is no longer used for fast path > walking either (to the best of my understanding). > > find . -name '*.[ch]' -not -path '*SCCS*' | xargs grep vfsmount_lock | > grep EXPORT Strange. How does the module compile I wonder? How does it load without unresolved symbols? Another little mystery to work on. > > shows no results for vfsmount_lock being exported to modules in 2.6. > > > > >The autofs4 moudule blocks (auto) mounts during the umount callback. > >Surely this is the sensible thing to do. > > > > > > > The raciness comes from the fact that we now support the lazy-mounting > of multimount offsets using embedded direct mounts. Autofs4 mounts all > (or as much as it can) from the multimount all together, and unmounts it > all on expiry. But 4.1 does lazy mount for several maps. Mounts that are triggered during the umount step of the expire are put on a wait queue along with the task requesting the umount. I think autofs always worked that way. > > > >Hang on. From the discussion my impression of a lazy mount is that it is > >not actually mounted! > > > > > > > Lazy _un_mounts as opposed to lazy mounts. Lazy unmounts are described > in umount(8): But will this leave the filesystem in a consistent state and allow further mount activity on that mount point? Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 10:40:43 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09IehmF008449 for ; Fri, 9 Jan 2004 10:40:43 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09Ib5vC023595; Fri, 9 Jan 2004 10:38:25 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09IWmvA022658 for ; Fri, 9 Jan 2004 10:34:05 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i09IWC523080; Sat, 10 Jan 2004 02:32:13 +0800 Date: Sat, 10 Jan 2004 02:32:12 +0800 (WST) From: Ian Kent X-X-Sender: To: "H. Peter Anvin" Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-Reply-To: <3FFD9498.6030905@zytor.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.5, required 8, AWL, BAYES_10, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Mike Waychison cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Thu, 8 Jan 2004, H. Peter Anvin wrote: > Ian Kent wrote: > > > > If wildcard map entries are not in autofs v3 then Jeremy implemented this > > in v4. > > > > v3 has had wildcard map entries and substitutions for a very, very, very > long time... it was a v2 feature, in fact. > > > And yes the host map is basically a program map and that's all. Worse, as > > pointed out in the paper it mounts everything under it. This is a source > > of stress for mount and umount. I have put in a fair bit of time on ugly > > hacks to work around this. This same problem is also evident in startup > > and shutdown for master maps with a good number of entries (~50 or more). > > A consequence of the current multiple daemon approach. > > This is why one wants to implement a mount tree with "direct mount > pads"; which also means keeping some state in the daemon. > > For example, let's say one has a mount tree like: > > /foo server1:/export/foo \ > /foo/bar server1:/export/bar \ > /bar server2:/export/bar > > ... then you actually have four diffenent filesystems involved: first, > some kind of "scaffolding" (this can be part of the autofs filesystem > itself or a ramfs) that hold the "foo" and "bar" directories, and then > foo, foo/bar, and bar. > > Consider the following implementation: when one encounters the above, > the daemon stashes this away as an already-encountered map entry (in > case the map entries change, we don't want to be inconsistent), creates > a ramfs for the scaffolding, creates the "foo" and "bar" subdirectories > and mount-traps "foo" and "bar". Then it releases userspace. When it > encounters an access on "foo", it gets invoked again, looks it up in its > "partial mounts" state, then mounts "foo" and mount-traps "foo/bar", > then releases userspace. > Umm. The cross filesystem problem again. This may sound a little silly but it may be able to be done using stackable filesystem methods (aka. Zadok et. al.). I'm thinking of an autofs filesystem stacked on a host filesystem. The dentrys corresponding to mount points marked in some way and the mount occuring under it, on top of the host filesystem. Yes I know it sounds ugly but maybe it's not. Maybe it's actually quite simple. I can't give an opinion yet as I'm still thinking it through and haven't done any feasibility. However, this approach would lend itself to providing autofs filesystem transparency. A requirement as yet not discussed. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 10:48:04 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09Im4mF008471 for ; Fri, 9 Jan 2004 10:48:04 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09IidvC025471; Fri, 9 Jan 2004 10:46:04 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09IhmvA025270 for ; Fri, 9 Jan 2004 10:44:34 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i09IhB523314; Sat, 10 Jan 2004 02:43:12 +0800 Date: Sat, 10 Jan 2004 02:43:11 +0800 (WST) From: Ian Kent X-X-Sender: To: Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-Reply-To: <20040108183135.GE30321@parcelfarce.linux.theplanet.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.5, required 8, AWL, BAYES_10, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Mike Waychison cc: "H. Peter Anvin" cc: "Ogden, Aaron A." cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Thu, 8 Jan 2004 viro@parcelfarce.linux.theplanet.co.uk wrote: > Basically, it's a single-point analog of autofs done entirely in VFS. > The job of automounter is to maintain the traps and react to events. > > And yes, I should've done that months ago. Waaaaay too long backlog - > bdev work, dev_t stuff, netdev, yadda, yadda. > So that's why Peter appears to have not made progress. Yes. Tell me about the 24 hour days that feel like an hour and feel like only an hours progress has been made. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 11:17:17 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09JHHmF008575 for ; Fri, 9 Jan 2004 11:17:17 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09JEhvC032443; Fri, 9 Jan 2004 11:14:47 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09JDXvA032215 for ; Fri, 9 Jan 2004 11:14:26 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i09JDR524042; Sat, 10 Jan 2004 03:13:27 +0800 Date: Sat, 10 Jan 2004 03:13:27 +0800 (WST) From: Ian Kent X-X-Sender: To: James Pearson In-Reply-To: <3FFE8B28.1E645E4E@moving-picture.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.5, required 8, AWL, BAYES_20, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs@linux.kernel.org cc: nfs@lists.sourceforge.net Subject: [autofs] Re: [NFS] Busy inodes after unmount followed by Oops X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Fri, 9 Jan 2004, James Pearson wrote: > I have the same problem with a large number of dual CPU machines running > 2.4.20 and above that make heavy use of autofs (v4.0.0pre10). > > We get a: > > VFS: Busy inodes after unmount. Self-destruct in 5 seconds. Have a nice > day... > > mesasage, followed some time later by Oops's from kswapd, umount or some > other user application. > > Is there a 'fix' for this problem? I would very much appreciate if you would use 4.1.0 (on kernel.org). This may help with the problem. I'm interested to hear how it goes against the stock autofs4 module. I have a patch set for 2.6 but, from a recent discussion, it may be faulty. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 11:46:11 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09JkAmF025899 for ; Fri, 9 Jan 2004 11:46:11 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09JgnvC006568; Fri, 9 Jan 2004 11:42:59 -0800 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09JfqvA006181 for ; Fri, 9 Jan 2004 11:42:31 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i09Jfkj4005723 for ; Fri, 9 Jan 2004 11:41:46 -0800 (PST) Received: from sun.com (vpn-129-152-200-55.East.Sun.COM [129.152.200.55]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HR8005N7MPI3B@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Fri, 09 Jan 2004 11:41:46 -0800 (PST) Date: Fri, 09 Jan 2004 14:41:30 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: <20040108183135.GE30321@parcelfarce.linux.theplanet.co.uk> To: viro@parcelfarce.linux.theplanet.co.uk Message-id: <3FFF03EA.4060603@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <3FFC96FE.9050002@zytor.com> <20040108183135.GE30321@parcelfarce.linux.theplanet.co.uk> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: "Ogden, Aaron A." cc: "H. Peter Anvin" cc: Kernel Mailing List cc: Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============087403064359012017==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============087403064359012017== Content-type: multipart/signed; boundary=------------enigDF8BFFCC985004A828D633B9; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDF8BFFCC985004A828D633B9 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit viro@parcelfarce.linux.theplanet.co.uk wrote: >On Thu, Jan 08, 2004 at 08:52:31PM +0800, Ian Kent wrote: > > >>On Wed, 7 Jan 2004, H. Peter Anvin wrote: >> >> >> >>>These are the mount traps Al Viro has been architecting. >>> >>> >>> >>Please tell me about these. >> >>I have`nt seen any discussion on the implementation. >> >>Just a few sentences .... >> >> > >Special vfsmount mounted somewhere; has no superblock associated with it; >attempt to step on it triggers event; normal result of that event is to >get a normal mount on top of it, at which point usual chaining logics >will make sure that we don't see the trap until it's uncovered by removal >of covering filesystem. Trap (and everything mounted on it, etc.) can >be removed by normal lazy umount. > >Basically, it's a single-point analog of autofs done entirely in VFS. >The job of automounter is to maintain the traps and react to events. > > > Is there any clear advantage to doing this in the VFS other than saving a superblock and a dentry/inode pair or two? I remember talking to you about this, and I seem to recall that these mount traps would probably communicate using a struct file, so a trap-user would somehow receive events about when the trap was set off. Will this communication model continue to work within a cloned namespace? What happens if the trap-client closes the file? -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enigDF8BFFCC985004A828D633B9 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE//wPtdQs4kOxk3/MRAiUvAJ9AdoamY4cnkTfTF4eRq00Ue+6/ygCfcauv aeslSGMIzLiEiGNx/3Pb0FY= =Hp/r -----END PGP SIGNATURE----- --------------enigDF8BFFCC985004A828D633B9-- --===============087403064359012017== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============087403064359012017==-- From autofs-bounces@linux.kernel.org Fri Jan 9 12:02:08 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09K27mF025982 for ; Fri, 9 Jan 2004 12:02:07 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09K00vC010377; Fri, 9 Jan 2004 12:00:06 -0800 Received: from simba.math.ucla.edu (simba.math.ucla.edu [128.97.4.125]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09JwwvA010155 for ; Fri, 9 Jan 2004 11:59:39 -0800 Received: by simba.math.ucla.edu (Postfix, from userid 228) id 189F01BFE2; Fri, 9 Jan 2004 11:58:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by simba.math.ucla.edu (Postfix) with ESMTP id 119F15DFD1; Fri, 9 Jan 2004 11:58:53 -0800 (PST) Date: Fri, 9 Jan 2004 11:58:53 -0800 (PST) From: Jim Carter To: Ian Kent Subject: Re: [autofs] [patch] buffer overflow, failure to auto-dismount, log file diarrhea In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Sat, 3 Jan 2004, Ian Kent wrote: > On Fri, 2 Jan 2004, Jim Carter wrote: > > Right, expire.c :: autofs4_expire() bypasses a mount point if its last_used > > field is too recent, and then it checks is_tree_busy(). Oh, look, a kludge > > that could be added, how wonderful! Assuming that it's feasible to get > > module-provided data into the inode data returned from sys_stat or > > sys_fstat, a mode bit could be set to indicate busyness, e.g. user write > > implies not busy. > > A user write implies an open file. The expire routine must identify this > dentry as busy or it's a bug that needs to be fixed. No, I meant that when the sys_stat method fills in the mode field of the returning stat structure, it would be reported as 555 for a busy filesystem, or 755 if it looks idle and dismountable. The mode field as seen by the VFS layer can stay at 755. This would be when statting autofs's directory inode, not whatever is mounted on it. Is it really true that the VFS layer doesn't maintain use counts for directories where you can find them easily? > > So the key task is to bulldoze aside the wreckage so a new instance of the > > revitalized NFS server can be mounted. Killing the moribund processes and > > forcibly dismounting the destroyed filesystem instance are important so as > > to recover resources, but the client can continue to function for quite a > > long time even if that's not done; the only totally vital action is to be > > able to remount, and that can possibly be done by renaming, or by > > remounting the wreckage elsewhere, deferring the actual dismount. > > I'll have to think about this for a while. The rename idea might cause all > sorts of problems. I can imagine. Maybe a -move remount? Can you even do this when the mounted FS is busy? Well... mkdir mtpt1 ; mkdir mtpt2 mount -t nfs hollyfs:/m1 mtpt1 cd mtpt1 sleep 3600 & (PID is 2486) cd .. umount mtpt1 (device is busy -- correct) mount --move mtpt1 mtpt2 (works -- yay!) ls -l /proc/2486/cwd (says: /proc/2486/cwd -> /tmp/root.jimc/mtpt2/) grep mtpt /proc/mounts (says: hollyfs:/m1 /tmp/root.jimc/mtpt2 nfs...) grep mtpt /etc/mtab (says: hollyfs:/m1 /tmp/root.jimc/mtpt1 nfs... /tmp/root.jimc/mtpt1 /tmp/root.jimc/mtpt2 none rw 0 0 kill 2486 umount mtpt2 (works -- correct) grep mtpt /proc/mounts (says: nothing) grep mtpt /etc/mtab (says: hollyfs:/m1 /tmp/root.jimc/mtpt1, hiss, boo) So you can do a move mount on a busy filesystem; the only downside is that /etc/mtab has a stale entry in it -- obviously a bug, not an essential behavior. > A kill -9 on the blocked process needs further investigation. I'm not sure > what the situation is there (probably not good). I would really like it if, when autofs decided to forcibly unmount, it could kill the using processes, as in "fuser -k -m /net/host/mountpoint". Actually this is a general issue for unmount(8), not specific to autofs. But one wonders whether fuser is going to run wild... > One thing I noticed in the module expire routine is that it doesn't > progress past a failed mount on subsequent calls. A change to the > adjustment of the d_subdirs list is probably needed (a bit difficult, but > not impossible, in my implementation of the expire routine). I thought it moved the mount point to the end, before attempting to unmount it. Maybe that behavior got changed in a subsequent version, or maybe I'm remembering wrong. > By the way. Since you are obviously interested in autofs, it would > be best if you could use the latest version. Please see kernel.org if > you are able to update. I'll discuss this with my management. By the way, for RPM-based distros, a lot of updating happens via mindless scripts, and it helps if ad-hoc fixes are packed up as a RPM. Then vendor updates to retro versions don't overwrite the latest patches. Example: Currently installed: autofs4-4.0.0pre10-504 I create and install: autofs4-4.1.0-001 Vendor issues patch: autofs4-4.0.5-678 The scripts know that the vendor's patch should be bypassed. If I get the go-ahead to install 4.1.0, I'll fake up a spec file (like steal it from the SuSE package) and send in some notes for how to use it. By the way, sorry for the late reply. Your message just arrived (2003-01-09) -- probably stuck on some MX somewhere for 3 days. James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key) _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 12:12:37 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09KCamF026004 for ; Fri, 9 Jan 2004 12:12:37 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09K8IvC012254; Fri, 9 Jan 2004 12:08:22 -0800 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09K7EvA011714 for ; Fri, 9 Jan 2004 12:07:58 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i09K790H028218 for ; Fri, 9 Jan 2004 12:07:09 -0800 (PST) Received: from sun.com (vpn-129-152-200-55.East.Sun.COM [129.152.200.55]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HR8005F1NVP3B@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Fri, 09 Jan 2004 12:07:09 -0800 (PST) Date: Fri, 09 Jan 2004 15:06:49 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: To: Ian Kent Message-id: <3FFF09D9.40909@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============70866615379017195==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============70866615379017195== Content-type: multipart/signed; boundary=------------enig81B952048166ED41571B2513; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig81B952048166ED41571B2513 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ian Kent wrote: >On Thu, 8 Jan 2004, Mike Waychison wrote: > > > >>The direct map 'triggers' will be taken care of by another filesystem >>with a magic root directory that will catch traversals using some >>follow_link magic. I wrote a prototype for this last summer, but >>haven't released it as the userspace stuff completely does not fit in >>with the existing daemon that was out at the time do the the mess of >>glue that was pgids, pipes and processes. It worked in the simple >>case, but it didn't extend to being able to direct mount an indirect >>map, nor was it able to do the lazy mounting in multimounts as I had >>desired. >> >> > >Is this the stuf that Al Viro is working on? > > > Al is proposing doing the same thing directly in the VFS instead of using a magic filesystem as I've described in the document. > Indeed, I >haven't solved my requirement of a transparent autofs filesystem aka. >Solaris automounter again. A difficult problem that will require >considerable effort. > > > What do you mean by this? Something that doesn't show up in /proc/mounts? I don't see this as much of an issue.. On any decently large machine, there are so many entries anyway that /etc/mtab and /proc/mounts become humanly unparseable anyhow. >>>>This is the subtle difference between direct and indirect maps. The >>>>direct map keys are absolute paths, not path components. We are >>>>implementing direct mounts as individual filesystems that will trap on >>>>traversal into their base directory. This filesystem has no idea where >>>>it is located as far as the user is concerned. We need to tell the >>>>filesystem directly so that the usermode helper can look it up. >>>>Conversely, the indirect map uses the sub-directory name as a mapkey. >>>> >>>> >>>> >>>> >>>I'm not sure what you are saying here. Does this mean there is a mount for >>>every direct mount (this might be what you call a trigger)? >>> >>> >>> >>> >>> >>Yes, it is its own filesystem (type autofs). This is needed because we >>need to overlay direct triggers within NFS filesystems for multimounts. >> >> > >Ahh. I see, you are talking about the cross filesystem problem. I haven't >solved that in what I have done either. Fortuneately I still get a good >hit rate in satisfying peoples' needs as in practice many people don't use >full automounter functionality. > > > Yup. But still, one of the nice things about a full automounter solution is accessing a netapp with hundreds of exports through /net in a reasonably fast way. >>?? Really? I find that hard to believe. I thought Solaris shared it's >>automounter with HPUX and AIX. I may be wrong though. >> >> > >Old versions perhaps. AIX 4.x was the last I used. It was definately like >that then. 500+ automounts tends to cluter the mount display a bit. > > > Could be. Either way, on a system with a thousand NFS shares automounted, I'm not really concerned about what the mounttable looks like. It won't be human parseable anyway. >>>Mmm. The vfsmount_lock is available to modules in 2.6. At least it was in >>>test11. I'm sure I compiled the module under 2.6 as well??? >>> >>>I thought that, taking the dcache_lock was the correct thing to do when >>>traversing a dentry list? >>> >>> >>> >>> >>> >>Walking dentrys still takes the dcache_lock, however walking vfsmounts >>takes the vfsmount_lock. dcache_lock is no longer used for fast path >>walking either (to the best of my understanding). >> >>find . -name '*.[ch]' -not -path '*SCCS*' | xargs grep vfsmount_lock | >>grep EXPORT >> >> > >Strange. How does the module compile I wonder? How does it load without >unresolved symbols? Another little mystery to work on. > > > No, you're module doesn't use vfsmount_lock. At least the module in autofs4-2.4-module-20031201.tar.gz doesn't. >>The raciness comes from the fact that we now support the lazy-mounting >>of multimount offsets using embedded direct mounts. Autofs4 mounts all >>(or as much as it can) from the multimount all together, and unmounts it >>all on expiry. >> >> > >But 4.1 does lazy mount for several maps. Mounts that are triggered >during the umount step of the expire are put on a wait queue along with >the task requesting the umount. I think autofs always worked that way. > > > This isn't lazy mounting per se. If you are talking about autofs4's use of AUTOFS_INF_EXPIRING, it's there to prevent somebody from walking into a multimount while it is expiring. >>>Hang on. From the discussion my impression of a lazy mount is that it is >>>not actually mounted! >>> >>> >>> >>> >>> >>Lazy _un_mounts as opposed to lazy mounts. Lazy unmounts are described >>in umount(8): >> >> > >But will this leave the filesystem in a consistent state and allow further >mount activity on that mount point? > > The underlying autofs filesystem? Sure. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enig81B952048166ED41571B2513 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE//wncdQs4kOxk3/MRAkbfAJ9NB/gNAMmLZIcTt75hQkgpgZkg3QCfTIoJ JQ33wzhmHrWB7O4OoFbxWCY= =GQ1k -----END PGP SIGNATURE----- --------------enig81B952048166ED41571B2513-- --===============70866615379017195== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============70866615379017195==-- From autofs-bounces@linux.kernel.org Fri Jan 9 12:16:54 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09KGsmF026047 for ; Fri, 9 Jan 2004 12:16:54 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09JwFvC010124; Fri, 9 Jan 2004 11:58:19 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09Jw5vA010049 for ; Fri, 9 Jan 2004 11:58:06 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id LAA31198; Fri, 9 Jan 2004 11:57:45 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma031190; Fri, 9 Jan 04 11:57:37 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i09Jvdf09368; Fri, 9 Jan 2004 11:57:40 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) by neocesium.transmeta.com (8.11.6/8.11.6) with ESMTP id i09JvdY15905; Fri, 9 Jan 2004 11:57:39 -0800 Message-ID: <3FFF07B2.70801@zytor.com> Date: Fri, 09 Jan 2004 11:57:38 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs References: <3FFC96FE.9050002@zytor.com> <20040108183135.GE30321@parcelfarce.linux.theplanet.co.uk> <3FFF03EA.4060603@sun.com> In-Reply-To: <3FFF03EA.4060603@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: viro@parcelfarce.linux.theplanet.co.uk cc: "Ogden, Aaron A." cc: Kernel Mailing List cc: Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Mike Waychison wrote: >> >> Special vfsmount mounted somewhere; has no superblock associated with it; >> attempt to step on it triggers event; normal result of that event is to >> get a normal mount on top of it, at which point usual chaining logics >> will make sure that we don't see the trap until it's uncovered by removal >> of covering filesystem. Trap (and everything mounted on it, etc.) can >> be removed by normal lazy umount. >> >> Basically, it's a single-point analog of autofs done entirely in VFS. >> The job of automounter is to maintain the traps and react to events. >> > Is there any clear advantage to doing this in the VFS other than saving > a superblock and a dentry/inode pair or two? > > I remember talking to you about this, and I seem to recall that these > mount traps would probably communicate using a struct file, so a > trap-user would somehow receive events about when the trap was set > off. Will this communication model continue to work within a cloned > namespace? What happens if the trap-client closes the file? > The biggest issue is to ensure that the appropriate atomicity guarantees can be maintained. In particular, it must be possible to umount the underlying filesystem and all mount traps on top of it atomically. Anything less will result in race conditions. -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 12:28:56 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09KStmF026327 for ; Fri, 9 Jan 2004 12:28:56 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09KI7vC014553; Fri, 9 Jan 2004 12:18:08 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09KI4vA014541 for ; Fri, 9 Jan 2004 12:18:04 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id MAA32050; Fri, 9 Jan 2004 12:17:37 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma032037; Fri, 9 Jan 04 12:17:09 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i09KHDf10929; Fri, 9 Jan 2004 12:17:13 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) by neocesium.transmeta.com (8.11.6/8.11.6) with ESMTP id i09KHCY20911; Fri, 9 Jan 2004 12:17:12 -0800 Message-ID: <3FFF0C48.6020908@zytor.com> Date: Fri, 09 Jan 2004 12:17:12 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: Jim Carter Subject: Re: [autofs] [patch] buffer overflow, failure to auto-dismount, log file diarrhea References: In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Jim Carter wrote: > >>A kill -9 on the blocked process needs further investigation. I'm not sure >>what the situation is there (probably not good). > > I would really like it if, when autofs decided to forcibly unmount, it > could kill the using processes, as in "fuser -k -m /net/host/mountpoint". > Actually this is a general issue for unmount(8), not specific to autofs. > But one wonders whether fuser is going to run wild... > How on the face of planet Earth do you expect autofs should ever take such a drastic action? This could only by a human deciding to do so, and if so, it's not an issue for autofs, as long as human umounts are properly handled (they should be.) -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 12:32:01 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09KW1mF026343 for ; Fri, 9 Jan 2004 12:32:01 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09KTivC018033; Fri, 9 Jan 2004 12:29:46 -0800 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09KSsvA017838 for ; Fri, 9 Jan 2004 12:29:38 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i09KSn0H008347 for ; Fri, 9 Jan 2004 12:28:49 -0800 (PST) Received: from sun.com (vpn-129-152-200-55.East.Sun.COM [129.152.200.55]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HR800DWYOVWAJ@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Fri, 09 Jan 2004 12:28:49 -0800 (PST) Date: Fri, 09 Jan 2004 15:28:32 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: <3FFDEAE6.4030503@metaparadigm.com> To: Michael Clark Message-id: <3FFF0EF0.90807@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <3FFD9498.6030905@zytor.com> <3FFDEAE6.4030503@metaparadigm.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Ian Kent cc: Kernel Mailing List cc: "H. Peter Anvin" X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============86286609831736216==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============86286609831736216== Content-type: multipart/signed; boundary=------------enigCB976E857DF6C1047F7DF8A1; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigCB976E857DF6C1047F7DF8A1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Michael Clark wrote: > On 01/09/04 01:34, H. Peter Anvin wrote: > >> In many ways this returns to the simplicity of the autofs v3 design >> where the atomicity constraints where guaranteed by the VFS itself, >> *as long as* mount traps can be atomically destroyed with umounting >> the underlying filesystem. > > > Do we need to revive Tigran's forced unmount patch 'badfs' ala FreeBSD's > deadfs? Although it doesn't guarantee atomic unmount, it could help > a lot with the tendancy to get stuck autofs mounts. > > http://tinyurl.com/2hto8 > > I've been long waiting for this functionality in mainline. This is an interesting approach to killing off a mountpoint. However, the problem in question is not the destruction of the mountpoints, but rather being able to check_activity_of_a_hierarchy_of_mountpoints/unmount_them_together atomically. This cannot be done cleanly in userspace even when given an interface to do the check, someone can race in before userspace initiates the unmounts. The alternative is to have userspace detach the hierarchy of mountpoints using the '-l' option to umount(8), but then we may still unneccesarily unmount the filesystem will someone is in it. I think that both HPA and I agree that this capability is needed in order to support lazy mounting of multimounts properly. The issue that remains is *how* to do it. > > I wonder if binding badfs over the mountpoint at the beginning of the > potentially lengthy unmount process would improve the atomicity > to userspace. ie although the unmount would proceed in the background, > badfs would have been mounted at that point at the start of the process > - mounts are atomic no? > > ~mc > The time required to unmount something is constant if we detach the mountpoint using a lazy umount. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enigCB976E857DF6C1047F7DF8A1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE//w7zdQs4kOxk3/MRAsGTAJwMR0IEgCMs5VxRFZ71cRI8TxW0AgCdEBc2 CIDvcCuT5lo3qBkRK1zeR/I= =TCaT -----END PGP SIGNATURE----- --------------enigCB976E857DF6C1047F7DF8A1-- --===============86286609831736216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============86286609831736216==-- From autofs-bounces@linux.kernel.org Fri Jan 9 12:55:47 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09KtjmF010678 for ; Fri, 9 Jan 2004 12:55:46 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09KqlvC023406; Fri, 9 Jan 2004 12:52:57 -0800 Received: from simba.math.ucla.edu (simba.math.ucla.edu [128.97.4.125]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09KpfvA022882 for ; Fri, 9 Jan 2004 12:52:32 -0800 Received: by simba.math.ucla.edu (Postfix, from userid 228) id 0CAD81BFE2; Fri, 9 Jan 2004 12:51:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by simba.math.ucla.edu (Postfix) with ESMTP id 069155DFD1; Fri, 9 Jan 2004 12:51:36 -0800 (PST) Date: Fri, 9 Jan 2004 12:51:36 -0800 (PST) From: Jim Carter To: Ian Kent Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Mike Waychison cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Sat, 10 Jan 2004, Ian Kent wrote: > On Thu, 8 Jan 2004, Mike Waychison wrote: > > This module will have its own new autofs module (hopefully named > > something other than autofs to avoid confusion/mishaps). The VFS will autofs v3 -> autofs.o autofs v4 -> autofs4.o May I suggest autofs5.o? It should still be named "autofs-something", after all. James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key) _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 12:55:47 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09KtjmF010679 for ; Fri, 9 Jan 2004 12:55:46 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09KrovC023683; Fri, 9 Jan 2004 12:53:52 -0800 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09Kr2vA023524 for ; Fri, 9 Jan 2004 12:53:48 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i09Kquj4014683 for ; Fri, 9 Jan 2004 12:52:56 -0800 (PST) Received: from sun.com (vpn-129-152-200-55.East.Sun.COM [129.152.200.55]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HR800DCJQ04AJ@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Fri, 09 Jan 2004 12:52:56 -0800 (PST) Date: Fri, 09 Jan 2004 15:52:41 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: To: Ian Kent Message-id: <3FFF1499.7030508@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List cc: "H. Peter Anvin" X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============70508637203649327==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============70508637203649327== Content-type: multipart/signed; boundary=------------enig059AD2C113BEFBAFBB7D0536; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig059AD2C113BEFBAFBB7D0536 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ian Kent wrote: >On Thu, 8 Jan 2004, H. Peter Anvin wrote: > > > >>Ian Kent wrote: >> >> >>>If wildcard map entries are not in autofs v3 then Jeremy implemented this >>>in v4. >>> >>> >>> >>v3 has had wildcard map entries and substitutions for a very, very, very >>long time... it was a v2 feature, in fact. >> >> >> >>>And yes the host map is basically a program map and that's all. Worse, as >>>pointed out in the paper it mounts everything under it. This is a source >>>of stress for mount and umount. I have put in a fair bit of time on ugly >>>hacks to work around this. This same problem is also evident in startup >>>and shutdown for master maps with a good number of entries (~50 or more). >>>A consequence of the current multiple daemon approach. >>> >>> >>This is why one wants to implement a mount tree with "direct mount >>pads"; which also means keeping some state in the daemon. >> >>For example, let's say one has a mount tree like: >> >>/foo server1:/export/foo \ >>/foo/bar server1:/export/bar \ >>/bar server2:/export/bar >> >>... then you actually have four diffenent filesystems involved: first, >>some kind of "scaffolding" (this can be part of the autofs filesystem >>itself or a ramfs) that hold the "foo" and "bar" directories, and then >>foo, foo/bar, and bar. >> >>Consider the following implementation: when one encounters the above, >>the daemon stashes this away as an already-encountered map entry (in >>case the map entries change, we don't want to be inconsistent), creates >>a ramfs for the scaffolding, creates the "foo" and "bar" subdirectories >>and mount-traps "foo" and "bar". Then it releases userspace. When it >>encounters an access on "foo", it gets invoked again, looks it up in its >>"partial mounts" state, then mounts "foo" and mount-traps "foo/bar", >>then releases userspace. >> >> >> > >Umm. The cross filesystem problem again. > >This may sound a little silly but it may be able to be done using >stackable filesystem methods (aka. Zadok et. al.). I'm thinking of an >autofs filesystem stacked on a host filesystem. The dentrys corresponding >to mount points marked in some way and the mount occuring under it, on top >of the host filesystem. Yes I know it sounds ugly but maybe it's not. >Maybe it's actually quite simple. I can't give an opinion yet as I'm still >thinking it through and haven't done any feasibility. However, this >approach would lend itself to providing autofs filesystem transparency. A >requirement as yet not discussed. > >Ian > > > Doing stackable filesystems is still an area of OS research. It turns out to be a very hard problem to solve (if it's possible at all). Although there are systems in the wild that appear to work, they are usually sub-optimal because there remains alot of issues such as maintaining coherent caches, as well as just staying coherent given that one filesystem may be directly accessible while also accessed from another overlayed filesystem. Not really something you'd want to waste alot of time on unless your looking for a phd thesis. ;) -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enig059AD2C113BEFBAFBB7D0536 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE//xSbdQs4kOxk3/MRAjgxAJ98Qyqkx2dfsuDUx5qk1OzVDjaMmwCgnWLT 9uwicVWBCVgsTaIEZ1CmNGE= =DYaO -----END PGP SIGNATURE----- --------------enig059AD2C113BEFBAFBB7D0536-- --===============70508637203649327== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============70508637203649327==-- From autofs-bounces@linux.kernel.org Fri Jan 9 12:58:01 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09Kw1mF010692 for ; Fri, 9 Jan 2004 12:58:01 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09Kt8vC023965; Fri, 9 Jan 2004 12:55:13 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09KstvA023875 for ; Fri, 9 Jan 2004 12:54:56 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id MAA01018; Fri, 9 Jan 2004 12:54:32 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma001008; Fri, 9 Jan 04 12:54:20 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i09KsOf13148; Fri, 9 Jan 2004 12:54:24 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) by neocesium.transmeta.com (8.11.6/8.11.6) with ESMTP id i09KsIY26544; Fri, 9 Jan 2004 12:54:18 -0800 Message-ID: <3FFF14F9.6030601@zytor.com> Date: Fri, 09 Jan 2004 12:54:17 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs References: <3FFD9498.6030905@zytor.com> <3FFDEAE6.4030503@metaparadigm.com> <3FFF0EF0.90807@sun.com> In-Reply-To: <3FFF0EF0.90807@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: Michael Clark cc: autofs mailing list cc: Kernel Mailing List cc: Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Mike Waychison wrote: > > This is an interesting approach to killing off a mountpoint. However, > the problem in question is not the destruction of the mountpoints, but > rather being able to > check_activity_of_a_hierarchy_of_mountpoints/unmount_them_together > atomically. This cannot be done cleanly in userspace even when given an > interface to do the check, someone can race in before userspace > initiates the unmounts. The alternative is to have userspace detach the > hierarchy of mountpoints using the '-l' option to umount(8), but then we > may still unneccesarily unmount the filesystem will someone is in it. > I think that both HPA and I agree that this capability is needed in > order to support lazy mounting of multimounts properly. The issue > that remains is *how* to do it. > I would argue even stronger: allowing the administrator to umount directories manually is a hard requirement. This means that partial hierarchies *will* occur. Thus, relying on the hierarchy being atomically destructed in inherently broken. This means that constructing the hierarchy with direct-mount automount triggers in between the filesystems is mandatory; you get lazy mounting for free, then -- it's a userspace policy decision whether or not to release the waiting processes before the hierarchy is complete or not. Now, once you recognize that the administrator needs to be able to do umounts, expiry in userspace becomes quite trivial, since expiry is inherently probabilistic: it can simply mimic an administrator preening the trees, and if it fails, stop (or re-mount the submounts, policy decision.) Having a simple kernel-assist to avoid needless umount operations is a good thing if (and only if!) it's cheap, but it doesn't have to be foolproof. Again, the atomicity constraint that umounting a filesystem needs to destroy the mount traps above it derives from the need to cleanly deal with nonatomic destruction. > > The time required to unmount something is constant if we detach the > mountpoint using a lazy umount. > You probably don't want to do that -- you could end up with some really odd timing-related bugs if you then re-mount the filesystem. It's also unnecessary, since expiry is not a triggered event and therefore doesn't keep anything that needs to happen from happening. -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 13:16:37 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09LGa2u010800 for ; Fri, 9 Jan 2004 13:16:37 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09LCSvC028318; Fri, 9 Jan 2004 13:12:33 -0800 Received: from simba.math.ucla.edu (simba.math.ucla.edu [128.97.4.125]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09LBQvA027787 for ; Fri, 9 Jan 2004 13:12:20 -0800 Received: by simba.math.ucla.edu (Postfix, from userid 228) id 1ED871BFE2; Fri, 9 Jan 2004 13:11:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by simba.math.ucla.edu (Postfix) with ESMTP id 18ACB5DFD1; Fri, 9 Jan 2004 13:11:21 -0800 (PST) Date: Fri, 9 Jan 2004 13:11:21 -0800 (PST) From: Jim Carter To: "H. Peter Anvin" Subject: Re: [autofs] [patch] buffer overflow, failure to auto-dismount, log file diarrhea In-Reply-To: <3FFF0C48.6020908@zytor.com> Message-ID: References: <3FFF0C48.6020908@zytor.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: RO X-Status: On Fri, 9 Jan 2004, H. Peter Anvin wrote: > Jim Carter wrote: > > I would really like it if, when autofs decided to forcibly unmount, it > > could kill the using processes, as in "fuser -k -m /net/host/mountpoint". > > Actually this is a general issue for unmount(8), not specific to autofs. > > But one wonders whether fuser is going to run wild... > > How on the face of planet Earth do you expect autofs should ever take > such a drastic action? This could only by a human deciding to do so, > and if so, it's not an issue for autofs, as long as human umounts are > properly handled (they should be.) Just yesterday I had five Linux boxes hang while rebooting, while trying to shut down autofs4, because processes using the filesystems had been killed but wouldn't die. This human said, I've already decided that these machines are idle, and so I just killed the shutdown script, rather than researching more drastic action to get rid of the processes, or to find out why they weren't exiting, or to do "umount -l", etc. It's lucky that autofs is shut off before sshd, or else I would have had to visit every machine. James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key) _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 13:33:34 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09LXW2u011042 for ; Fri, 9 Jan 2004 13:33:33 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09LSpvC031759; Fri, 9 Jan 2004 13:28:54 -0800 Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09LS0vA031578 for ; Fri, 9 Jan 2004 13:28:46 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i09LRxqV015767 for ; Fri, 9 Jan 2004 14:27:59 -0700 (MST) Received: from sun.com (vpn-129-152-200-55.East.Sun.COM [129.152.200.55]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HR800DEGRMIAJ@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Fri, 09 Jan 2004 13:27:59 -0800 (PST) Date: Fri, 09 Jan 2004 16:27:43 -0500 From: Mike Waychison Subject: Re: [autofs] [patch] buffer overflow, failure to auto-dismount, log file diarrhea In-reply-to: To: Jim Carter Message-id: <3FFF1CCF.2070904@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============58051623154556498==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============58051623154556498== Content-type: multipart/signed; boundary=------------enig09B295A7BC080ABA21F2A78E; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig09B295A7BC080ABA21F2A78E Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jim Carter wrote: >On Sat, 3 Jan 2004, Ian Kent wrote: > > >>On Fri, 2 Jan 2004, Jim Carter wrote: >> >> >>>Right, expire.c :: autofs4_expire() bypasses a mount point if its last_used >>>field is too recent, and then it checks is_tree_busy(). Oh, look, a kludge >>>that could be added, how wonderful! Assuming that it's feasible to get >>>module-provided data into the inode data returned from sys_stat or >>>sys_fstat, a mode bit could be set to indicate busyness, e.g. user write >>>implies not busy. >>> >>> >>A user write implies an open file. The expire routine must identify this >>dentry as busy or it's a bug that needs to be fixed. >> >> > >No, I meant that when the sys_stat method fills in the mode field of >the returning stat structure, it would be reported as 555 for a busy >filesystem, or 755 if it looks idle and dismountable. The mode field as >seen by the VFS layer can stay at 755. This would be when statting >autofs's directory inode, not whatever is mounted on it. > > > This hijacking of the st_mode is just that, hijacking. You'd be changing the mode of the directory on the NFS filesystem.. This wouldn't work well in the VFS when it tries to check permissions, but it also wouldn't work for more than one NFS client accessing the same filehandle. >Is it really true that the VFS layer doesn't maintain use counts for >directories where you can find them easily? > > > Use counts for directories? The of a file has no real consistent corelation with which directory that file belongs. >>>So the key task is to bulldoze aside the wreckage so a new instance of the >>>revitalized NFS server can be mounted. Killing the moribund processes and >>>forcibly dismounting the destroyed filesystem instance are important so as >>>to recover resources, but the client can continue to function for quite a >>>long time even if that's not done; the only totally vital action is to be >>>able to remount, and that can possibly be done by renaming, or by >>>remounting the wreckage elsewhere, deferring the actual dismount. >>> >>> >>I'll have to think about this for a while. The rename idea might cause all >>sorts of problems. >> >> > >I can imagine. Maybe a -move remount? Can you even do this when the >mounted FS is busy? Well... > >mkdir mtpt1 ; mkdir mtpt2 >mount -t nfs hollyfs:/m1 mtpt1 >cd mtpt1 >sleep 3600 & (PID is 2486) >cd .. >umount mtpt1 (device is busy -- correct) >mount --move mtpt1 mtpt2 (works -- yay!) >ls -l /proc/2486/cwd (says: /proc/2486/cwd -> /tmp/root.jimc/mtpt2/) >grep mtpt /proc/mounts (says: hollyfs:/m1 /tmp/root.jimc/mtpt2 nfs...) >grep mtpt /etc/mtab (says: hollyfs:/m1 /tmp/root.jimc/mtpt1 nfs... > /tmp/root.jimc/mtpt1 /tmp/root.jimc/mtpt2 none rw 0 0 >kill 2486 >umount mtpt2 (works -- correct) >grep mtpt /proc/mounts (says: nothing) >grep mtpt /etc/mtab (says: hollyfs:/m1 /tmp/root.jimc/mtpt1, hiss, boo) > >So you can do a move mount on a busy filesystem; the only downside is that >/etc/mtab has a stale entry in it -- obviously a bug, not an essential >behavior. > > > Yup, it's a bug, however now that you can mount two filesystems on top of each other, there really is no reliable way to know which entry in /etc/mtab has moved. Eg: # mkdir /foo # mount -o ro host:/path /foo # mount -o rw host:/path /foo # cat /etc/mtab (two lines for /foo are printed) # mkdir /bar # mount --move /foo /bar Which entry in /etc/mtab is changed from /foo to /bar? Unless you can make steadfast rules on entry ordering, you can't reliably decide which entry has changed. Even worse, /etc/mtab is broken when using multiple namespaces. >>A kill -9 on the blocked process needs further investigation. I'm not sure >>what the situation is there (probably not good). >> >> > >I would really like it if, when autofs decided to forcibly unmount, it >could kill the using processes, as in "fuser -k -m /net/host/mountpoint". >Actually this is a general issue for unmount(8), not specific to autofs. >But one wonders whether fuser is going to run wild... > > > Like HPA already mentioned, this is bad. I don't even think you could reliably detect this. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enig09B295A7BC080ABA21F2A78E Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE//xzRdQs4kOxk3/MRAgntAJ9drXy62P26J/9eBF6B3Fq0jw/MhACfReb5 7EaITiFxLn5wKGbCPPmafKg= =tIYO -----END PGP SIGNATURE----- --------------enig09B295A7BC080ABA21F2A78E-- --===============58051623154556498== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============58051623154556498==-- From autofs-bounces@linux.kernel.org Fri Jan 9 13:34:37 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09LYa2u011049 for ; Fri, 9 Jan 2004 13:34:37 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09LWOvC032456; Fri, 9 Jan 2004 13:32:26 -0800 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09LVbvA032196 for ; Fri, 9 Jan 2004 13:32:18 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i09LVW0H007574 for ; Fri, 9 Jan 2004 13:31:32 -0800 (PST) Received: from sun.com (vpn-129-152-200-55.East.Sun.COM [129.152.200.55]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HR800DGNRSHAJ@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Fri, 09 Jan 2004 13:31:32 -0800 (PST) Date: Fri, 09 Jan 2004 16:31:19 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: <3FFF07B2.70801@zytor.com> To: "H. Peter Anvin" Message-id: <3FFF1DA7.8060005@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <3FFC96FE.9050002@zytor.com> <20040108183135.GE30321@parcelfarce.linux.theplanet.co.uk> <3FFF03EA.4060603@sun.com> <3FFF07B2.70801@zytor.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: viro@parcelfarce.linux.theplanet.co.uk cc: "Ogden, Aaron A." cc: Kernel Mailing List cc: Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============55739520587910185==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============55739520587910185== Content-type: multipart/signed; boundary=------------enig0BC603AFCD0DE3986BBF4C74; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0BC603AFCD0DE3986BBF4C74 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit H. Peter Anvin wrote: >Mike Waychison wrote: > > >>>Special vfsmount mounted somewhere; has no superblock associated with it; >>>attempt to step on it triggers event; normal result of that event is to >>>get a normal mount on top of it, at which point usual chaining logics >>>will make sure that we don't see the trap until it's uncovered by removal >>>of covering filesystem. Trap (and everything mounted on it, etc.) can >>>be removed by normal lazy umount. >>> >>>Basically, it's a single-point analog of autofs done entirely in VFS. >>>The job of automounter is to maintain the traps and react to events. >>> >>> >>> >>Is there any clear advantage to doing this in the VFS other than saving >>a superblock and a dentry/inode pair or two? >> >>I remember talking to you about this, and I seem to recall that these >>mount traps would probably communicate using a struct file, so a >>trap-user would somehow receive events about when the trap was set >>off. Will this communication model continue to work within a cloned >>namespace? What happens if the trap-client closes the file? >> >> >> > >The biggest issue is to ensure that the appropriate atomicity guarantees >can be maintained. In particular, it must be possible to umount the >underlying filesystem and all mount traps on top of it atomically. >Anything less will result in race conditions. > > -hpa > > > Unless I'm missing something, implementing this as a seperate filesystem type still has the appropriate atomicity guarantees as long as the VFS support complex expiry, whereby userspace would tag submounts as being part of the overall expiry for a base mountpoint. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enig0BC603AFCD0DE3986BBF4C74 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE//x2odQs4kOxk3/MRAmX7AJ48ewk0pgAvwtUvjNz6YMk4jVhAuACfRdBp jfR4LzbYMcIDCHHqgolyhjQ= =dirY -----END PGP SIGNATURE----- --------------enig0BC603AFCD0DE3986BBF4C74-- --===============55739520587910185== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============55739520587910185==-- From autofs-bounces@linux.kernel.org Fri Jan 9 13:44:27 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09LiQ2u028106 for ; Fri, 9 Jan 2004 13:44:27 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09LcivC001655; Fri, 9 Jan 2004 13:38:50 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09LcavA001630 for ; Fri, 9 Jan 2004 13:38:37 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id NAA02748; Fri, 9 Jan 2004 13:36:24 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma002742; Fri, 9 Jan 04 13:36:02 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i09La5f15738; Fri, 9 Jan 2004 13:36:05 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) by neocesium.transmeta.com (8.11.6/8.11.6) with ESMTP id i09La5Y26747; Fri, 9 Jan 2004 13:36:05 -0800 Message-ID: <3FFF1EC4.7080406@zytor.com> Date: Fri, 09 Jan 2004 13:36:04 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs References: <3FFC96FE.9050002@zytor.com> <20040108183135.GE30321@parcelfarce.linux.theplanet.co.uk> <3FFF03EA.4060603@sun.com> <3FFF07B2.70801@zytor.com> <3FFF1DA7.8060005@sun.com> In-Reply-To: <3FFF1DA7.8060005@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: viro@parcelfarce.linux.theplanet.co.uk cc: "Ogden, Aaron A." cc: Kernel Mailing List cc: Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: RO X-Status: Mike Waychison wrote: > > Unless I'm missing something, implementing this as a seperate filesystem > type still has the appropriate atomicity guarantees as long as the VFS > support complex expiry, whereby userspace would tag submounts as being > part of the overall expiry for a base mountpoint. > It would, but it seems like a vastly more invasive change to the VFS than ought to be necessary. -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 13:46:46 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09Lkk2u028117 for ; Fri, 9 Jan 2004 13:46:46 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09LiivC003027; Fri, 9 Jan 2004 13:44:45 -0800 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09LhtvA002804 for ; Fri, 9 Jan 2004 13:44:42 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i09Lhoj4011368 for ; Fri, 9 Jan 2004 13:43:50 -0800 (PST) Received: from sun.com (vpn-129-152-200-55.East.Sun.COM [129.152.200.55]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HR800D8USCYAJ@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Fri, 09 Jan 2004 13:43:50 -0800 (PST) Date: Fri, 09 Jan 2004 16:43:33 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: <3FFF14F9.6030601@zytor.com> To: "H. Peter Anvin" Message-id: <3FFF2085.4020102@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <3FFD9498.6030905@zytor.com> <3FFDEAE6.4030503@metaparadigm.com> <3FFF0EF0.90807@sun.com> <3FFF14F9.6030601@zytor.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: Michael Clark cc: autofs mailing list cc: Kernel Mailing List cc: Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============44178220787793721==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============44178220787793721== Content-type: multipart/signed; boundary=------------enig90F0E425FCCF33089537B762; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig90F0E425FCCF33089537B762 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit H. Peter Anvin wrote: >Mike Waychison wrote: > > >>This is an interesting approach to killing off a mountpoint. However, >>the problem in question is not the destruction of the mountpoints, but >>rather being able to >>check_activity_of_a_hierarchy_of_mountpoints/unmount_them_together >>atomically. This cannot be done cleanly in userspace even when given an >>interface to do the check, someone can race in before userspace >>initiates the unmounts. The alternative is to have userspace detach the >>hierarchy of mountpoints using the '-l' option to umount(8), but then we >>may still unneccesarily unmount the filesystem will someone is in it. >>I think that both HPA and I agree that this capability is needed in >>order to support lazy mounting of multimounts properly. The issue >>that remains is *how* to do it. >> >> >> > >I would argue even stronger: allowing the administrator to umount >directories manually is a hard requirement. This means that partial >hierarchies *will* occur. Thus, relying on the hierarchy being >atomically destructed in inherently broken. > > Yes, but they shouldn't occur due to normal operation of the system. Yes, the administrator can manually prune things away, yet the remaining bits should still be able to expire atomically. On the other end of the spectrum is the situation where if I had accessed my homedir, /home/mikew, and then I manually mounted something in /home/mikew/mnt as root in another window, /home/mikew should _not_ expire. /home/mikew/mnt is not managed by the automounter, so it shouldn't be expired by it either. >This means that constructing the hierarchy with direct-mount automount >triggers in between the filesystems is mandatory; you get lazy mounting >for free, then -- it's a userspace policy decision whether or not to >release the waiting processes before the hierarchy is complete or not. > > > Yes, and this policy in my proposal is handled by the automount useragent. The system is constructed such that any waiting processes are released when the useragent dies off. If userspace wanted to let people in before it finished construction, it would fork and exit in the parent process. >Now, once you recognize that the administrator needs to be able to do >umounts, expiry in userspace becomes quite trivial, since expiry is >inherently probabilistic: it can simply mimic an administrator preening >the trees, and if it fails, stop (or re-mount the submounts, policy >decision.) Having a simple kernel-assist to avoid needless umount >operations is a good thing if (and only if!) it's cheap, but it doesn't >have to be foolproof. > > > But it doesn't work as a daemon when you have namespaces created left and right. It *would maybe* work as a cron job, if cron was namespace aware. >Again, the atomicity constraint that umounting a filesystem needs to >destroy the mount traps above it derives from the need to cleanly deal >with nonatomic destruction. > > > ?? >>The time required to unmount something is constant if we detach the >>mountpoint using a lazy umount. >> >> >> > >You probably don't want to do that -- you could end up with some really >odd timing-related bugs if you then re-mount the filesystem. It's also >unnecessary, since expiry is not a triggered event and therefore doesn't >keep anything that needs to happen from happening. > > > Off the top of my head, I don't see any issues, but you are right in that something may creep up. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enig90F0E425FCCF33089537B762 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE//yCIdQs4kOxk3/MRAnxvAJ4yYiUDtlN5Du7XBf+vxSdwhzP6wACgniVK QTa+HmcaXF6gXcIpr+C+TsI= =q4pi -----END PGP SIGNATURE----- --------------enig90F0E425FCCF33089537B762-- --===============44178220787793721== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============44178220787793721==-- From autofs-bounces@linux.kernel.org Fri Jan 9 13:46:47 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09Lkl2u028120 for ; Fri, 9 Jan 2004 13:46:47 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09LiPvC002981; Fri, 9 Jan 2004 13:44:29 -0800 Received: from simba.math.ucla.edu (simba.math.ucla.edu [128.97.4.125]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09LhRvA002787 for ; Fri, 9 Jan 2004 13:44:13 -0800 Received: by simba.math.ucla.edu (Postfix, from userid 228) id D8B601BFE2; Fri, 9 Jan 2004 13:43:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by simba.math.ucla.edu (Postfix) with ESMTP id D24085DFD1; Fri, 9 Jan 2004 13:43:22 -0800 (PST) Date: Fri, 9 Jan 2004 13:43:22 -0800 (PST) From: Jim Carter To: Mike Waychison Subject: Re: [autofs] [patch] buffer overflow, failure to auto-dismount, log file diarrhea In-Reply-To: <3FFF1CCF.2070904@sun.com> Message-ID: References: <3FFF1CCF.2070904@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Fri, 9 Jan 2004, Mike Waychison wrote: > Jim Carter wrote: > >No, I meant that when the sys_stat method fills in the mode field of > >the returning stat structure, it would be reported as 555 for a busy > >filesystem, or 755 if it looks idle and dismountable. The mode field as > >seen by the VFS layer can stay at 755. This would be when statting > >autofs's directory inode, not whatever is mounted on it. > This hijacking of the st_mode is just that, hijacking. You'd be > changing the mode of the directory on the NFS filesystem.. This > wouldn't work well in the VFS when it tries to check permissions, but it > also wouldn't work for more than one NFS client accessing the same > filehandle. There are 2 inodes here: the mount point (owned by autofs) and what's mounted on it. We mustn't monkey with the mountee's data, of course. I'm talking about statting the mount point itself. You can't do that by name, but in a prior discussion we were talking about opening the mount point before the mount, and later doing fstat on the file descriptor. HPA mentioned providing a readlink method and doing lstat on the mount point by name, which would intercept the path walk before the mountee was noticed. So the caller gets the mode of the mount point, which autofs can create or interpret any way it wants, rather than the mountee's data. > >I would really like it if, when autofs decided to forcibly unmount, it > >could kill the using processes, as in "fuser -k -m /net/host/mountpoint". > >Actually this is a general issue for unmount(8), not specific to autofs. > >But one wonders whether fuser is going to run wild... > Like HPA already mentioned, this is bad. I don't even think you could > reliably detect this. Agreed, you wonder if the right processes are going to be picked. But... "Ask for the moon; they might give it to you." In the present case it should be possible to stick the fuser execution into the autofs shutdown script -- it already is aware that unmounts haven't finished, and it probably knows or can find out which filesystems are involved. P.S. "Be careful what you wish for; you might get it." James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key) _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 14:04:29 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i09M4S2u028174 for ; Fri, 9 Jan 2004 14:04:29 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09M1jvC008396; Fri, 9 Jan 2004 14:01:53 -0800 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i09M0jvA008254 for ; Fri, 9 Jan 2004 14:01:35 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i09M0d0H020361 for ; Fri, 9 Jan 2004 14:00:39 -0800 (PST) Received: from sun.com (vpn-129-152-200-55.East.Sun.COM [129.152.200.55]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HR800MUQT50FG@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Fri, 09 Jan 2004 14:00:39 -0800 (PST) Date: Fri, 09 Jan 2004 17:00:23 -0500 From: Mike Waychison Subject: Re: [autofs] [patch] buffer overflow, failure to auto-dismount, log file diarrhea In-reply-to: To: Jim Carter Message-id: <3FFF2477.9060909@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <3FFF1CCF.2070904@sun.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Ian Kent X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============61256762441623303==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============61256762441623303== Content-type: multipart/signed; boundary=------------enigA99325A66258AEF78F655AD4; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA99325A66258AEF78F655AD4 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jim Carter wrote: >On Fri, 9 Jan 2004, Mike Waychison wrote: > > > >>Jim Carter wrote: >> >> >>>No, I meant that when the sys_stat method fills in the mode field of >>>the returning stat structure, it would be reported as 555 for a busy >>>filesystem, or 755 if it looks idle and dismountable. The mode field as >>>seen by the VFS layer can stay at 755. This would be when statting >>>autofs's directory inode, not whatever is mounted on it. >>> >>> > > > >>This hijacking of the st_mode is just that, hijacking. You'd be >>changing the mode of the directory on the NFS filesystem.. This >>wouldn't work well in the VFS when it tries to check permissions, but it >>also wouldn't work for more than one NFS client accessing the same >>filehandle. >> >> > >There are 2 inodes here: the mount point (owned by autofs) and what's >mounted on it. We mustn't monkey with the mountee's data, of course. I'm >talking about statting the mount point itself. You can't do that by name, >but in a prior discussion we were talking about opening the mount point >before the mount, and later doing fstat on the file descriptor. HPA >mentioned providing a readlink method and doing lstat on the mount point by >name, which would intercept the path walk before the mountee was noticed. > >So the caller gets the mode of the mount point, which autofs can create or >interpret any way it wants, rather than the mountee's data. > > > Ok. Then the kernel would need to periodically make these checks.. It could work, but I see it as yet another communication kludge. >>>I would really like it if, when autofs decided to forcibly unmount, it >>>could kill the using processes, as in "fuser -k -m /net/host/mountpoint". >>>Actually this is a general issue for unmount(8), not specific to autofs. >>>But one wonders whether fuser is going to run wild... >>> >>> > > > >>Like HPA already mentioned, this is bad. I don't even think you could >>reliably detect this. >> >> > >Agreed, you wonder if the right processes are going to be picked. But... >"Ask for the moon; they might give it to you." In the present case it >should be possible to stick the fuser execution into the autofs shutdown >script -- it already is aware that unmounts haven't finished, and it >probably knows or can find out which filesystems are involved. > > > This probably isn't best placed in the initscript. The automount daemon should instead have a timeout setup for unmounting these filesystems. If the unmount hangs for more than x seconds, move on to the next one. Let init take care of killing off processes if they haven't died in time for shutdown. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enigA99325A66258AEF78F655AD4 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQE//yR6dQs4kOxk3/MRAo3CAJwP2eqU2kSsF/paTiM0iJCpk3J70ACgizCa TD1huqIuINAv+FjtyNMDM9o= =SvTi -----END PGP SIGNATURE----- --------------enigA99325A66258AEF78F655AD4-- --===============61256762441623303== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============61256762441623303==-- From autofs-bounces@linux.kernel.org Fri Jan 9 21:09:50 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0A59na1019279 for ; Fri, 9 Jan 2004 21:09:50 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0A57SvC011130; Fri, 9 Jan 2004 21:07:43 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0A568vA010615 for ; Fri, 9 Jan 2004 21:06:53 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i0A56B502698; Sat, 10 Jan 2004 13:06:11 +0800 Date: Sat, 10 Jan 2004 13:06:11 +0800 (WST) From: Ian Kent X-X-Sender: To: Jim Carter Subject: Re: [autofs] [patch] buffer overflow, failure to auto-dismount, log file diarrhea In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.5, required 8, AWL, BAYES_10, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Fri, 9 Jan 2004, Jim Carter wrote: > > > > A user write implies an open file. The expire routine must identify this > > dentry as busy or it's a bug that needs to be fixed. > > No, I meant that when the sys_stat method fills in the mode field of > the returning stat structure, it would be reported as 555 for a busy > filesystem, or 755 if it looks idle and dismountable. The mode field as > seen by the VFS layer can stay at 755. This would be when statting > autofs's directory inode, not whatever is mounted on it. Don't see how the modes can identify whether a directory is busy. Its modes could just as well be 555 anyway. > > Is it really true that the VFS layer doesn't maintain use counts for > directories where you can find them easily? Good question. I'm not sure but I believe the reference count should be incremented when the dentry is actually being used, so it doesn't go away. For example, during a mount a dentry is obtained for the root directory and, since it is obviously in use it has a none zero reference count as long as the mount is present. > > > > So the key task is to bulldoze aside the wreckage so a new instance of the > > > revitalized NFS server can be mounted. Killing the moribund processes and > > > forcibly dismounting the destroyed filesystem instance are important so as > > > to recover resources, but the client can continue to function for quite a > > > long time even if that's not done; the only totally vital action is to be > > > able to remount, and that can possibly be done by renaming, or by > > > remounting the wreckage elsewhere, deferring the actual dismount. > > > > I'll have to think about this for a while. The rename idea might cause all > > sorts of problems. > > I can imagine. Maybe a -move remount? Can you even do this when the > mounted FS is busy? Well... > > mkdir mtpt1 ; mkdir mtpt2 > mount -t nfs hollyfs:/m1 mtpt1 > cd mtpt1 > sleep 3600 & (PID is 2486) > cd .. > umount mtpt1 (device is busy -- correct) > mount --move mtpt1 mtpt2 (works -- yay!) > ls -l /proc/2486/cwd (says: /proc/2486/cwd -> /tmp/root.jimc/mtpt2/) > grep mtpt /proc/mounts (says: hollyfs:/m1 /tmp/root.jimc/mtpt2 nfs...) > grep mtpt /etc/mtab (says: hollyfs:/m1 /tmp/root.jimc/mtpt1 nfs... > /tmp/root.jimc/mtpt1 /tmp/root.jimc/mtpt2 none rw 0 0 > kill 2486 > umount mtpt2 (works -- correct) > grep mtpt /proc/mounts (says: nothing) > grep mtpt /etc/mtab (says: hollyfs:/m1 /tmp/root.jimc/mtpt1, hiss, boo) > > So you can do a move mount on a busy filesystem; the only downside is that > /etc/mtab has a stale entry in it -- obviously a bug, not an essential > behavior. > > > A kill -9 on the blocked process needs further investigation. I'm not sure > > what the situation is there (probably not good). > > I would really like it if, when autofs decided to forcibly unmount, it > could kill the using processes, as in "fuser -k -m /net/host/mountpoint". > Actually this is a general issue for unmount(8), not specific to autofs. > But one wonders whether fuser is going to run wild... > > > One thing I noticed in the module expire routine is that it doesn't > > progress past a failed mount on subsequent calls. A change to the > > adjustment of the d_subdirs list is probably needed (a bit difficult, but > > not impossible, in my implementation of the expire routine). > > I thought it moved the mount point to the end, before attempting to unmount > it. Maybe that behavior got changed in a subsequent version, or maybe I'm > remembering wrong. I thought it was the front of the list. In fact I thought putting the expire candidate on the end of the list would help with the infinite loop problem as well, along with the limit patch you sent. In fact I think that using the limit patch is a preferable approach to manage this bug for now. I need to do more work on this in my module patch. Changes I needed to make have caused this manipulation to become ineffective. > > > By the way. Since you are obviously interested in autofs, it would > > be best if you could use the latest version. Please see kernel.org if > > you are able to update. > > I'll discuss this with my management. By the way, for RPM-based distros, a > lot of updating happens via mindless scripts, and it helps if ad-hoc fixes > are packed up as a RPM. Then vendor updates to retro versions don't > overwrite the latest patches. Example: > Currently installed: autofs4-4.0.0pre10-504 > I create and install: autofs4-4.1.0-001 > Vendor issues patch: autofs4-4.0.5-678 > SuSE is a bit difficult. The rpm I have is very much RedHat centric. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 21:12:51 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0A5Cpa1019288 for ; Fri, 9 Jan 2004 21:12:51 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0A5B9vC011805; Fri, 9 Jan 2004 21:11:12 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0A59lvA011560 for ; Fri, 9 Jan 2004 21:10:34 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i0A59c502714; Sat, 10 Jan 2004 13:09:38 +0800 Date: Sat, 10 Jan 2004 13:09:38 +0800 (WST) From: Ian Kent X-X-Sender: To: Jim Carter Subject: Re: [autofs] [patch] buffer overflow, failure to auto-dismount, log file diarrhea In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.5, required 8, AWL, BAYES_10, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: "H. Peter Anvin" X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Fri, 9 Jan 2004, Jim Carter wrote: > > Just yesterday I had five Linux boxes hang while rebooting, while > trying to shut down autofs4, because processes using the filesystems had > been killed but wouldn't die. This human said, I've already decided that > these machines are idle, and so I just killed the shutdown script, rather > than researching more drastic action to get rid of the processes, or to > find out why they weren't exiting, or to do "umount -l", etc. Please try 4.1 and the kernel module patch (you are using 2.4?). If it doesn't improve your situation you are no worse of and I will get more bug info. On the other hand .... _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 21:46:19 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0A5kEa1003917 for ; Fri, 9 Jan 2004 21:46:18 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0A5hevC019445; Fri, 9 Jan 2004 21:43:43 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0A5hAvA019437 for ; Fri, 9 Jan 2004 21:43:33 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i0A5hD503273; Sat, 10 Jan 2004 13:43:13 +0800 Date: Sat, 10 Jan 2004 13:43:13 +0800 (WST) From: Ian Kent X-X-Sender: To: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-Reply-To: <3FFF09D9.40909@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.5, required 8, AWL, BAYES_10, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Fri, 9 Jan 2004, Mike Waychison wrote: > > > Indeed, I > >haven't solved my requirement of a transparent autofs filesystem aka. > >Solaris automounter again. A difficult problem that will require > >considerable effort. > > > > > > > What do you mean by this? Something that doesn't show up in > /proc/mounts? I don't see this as much of an issue.. On any decently > large machine, there are so many entries anyway that /etc/mtab and > /proc/mounts become humanly unparseable anyhow. Transparency of an autofs filesystem (as I'm calling it) is the situation where, given a map /usr /man1 server:/usr/man1 /man2 server:/usr/man2 where the filesystem /usr contains, say a directory lib, that needs to be available while also seeing the automounted directories. > > >>>Mmm. The vfsmount_lock is available to modules in 2.6. At least it was in > >>>test11. I'm sure I compiled the module under 2.6 as well??? > >>> > >>>I thought that, taking the dcache_lock was the correct thing to do when > >>>traversing a dentry list? > >>> > >>> > >>> > >>> > >>> > >>Walking dentrys still takes the dcache_lock, however walking vfsmounts > >>takes the vfsmount_lock. dcache_lock is no longer used for fast path > >>walking either (to the best of my understanding). > >> > >>find . -name '*.[ch]' -not -path '*SCCS*' | xargs grep vfsmount_lock | > >>grep EXPORT > >> > >> > > > >Strange. How does the module compile I wonder? How does it load without > >unresolved symbols? Another little mystery to work on. > > > > > > > No, you're module doesn't use vfsmount_lock. At least the module in > autofs4-2.4-module-20031201.tar.gz doesn't. This is the 2.4 code. I do (or though I was able to) use the vfsmount_lock in the 2.6 patches I have in kernel.org/pub/linux/kernel/people/raven/autofs4-2.6. This is bad for me. > > >>The raciness comes from the fact that we now support the lazy-mounting > >>of multimount offsets using embedded direct mounts. Autofs4 mounts all > >>(or as much as it can) from the multimount all together, and unmounts it > >>all on expiry. > >> > >> > > > >But 4.1 does lazy mount for several maps. Mounts that are triggered > >during the umount step of the expire are put on a wait queue along with > >the task requesting the umount. I think autofs always worked that way. > > > > > > > This isn't lazy mounting per se. If you are talking about autofs4's use > of AUTOFS_INF_EXPIRING, it's there to prevent somebody from walking into > a multimount while it is expiring. Or any umount when sending the expire request to userspace. _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 21:59:42 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0A5xda1003957 for ; Fri, 9 Jan 2004 21:59:42 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0A5vevC022662; Fri, 9 Jan 2004 21:57:43 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0A5ugvA022176 for ; Fri, 9 Jan 2004 21:57:24 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i0A5ul503500; Sat, 10 Jan 2004 13:56:47 +0800 Date: Sat, 10 Jan 2004 13:56:47 +0800 (WST) From: Ian Kent X-X-Sender: To: Jim Carter Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.5, required 8, AWL, BAYES_10, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Mike Waychison cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Fri, 9 Jan 2004, Jim Carter wrote: > On Sat, 10 Jan 2004, Ian Kent wrote: > > On Thu, 8 Jan 2004, Mike Waychison wrote: > > > This module will have its own new autofs module (hopefully named > > > something other than autofs to avoid confusion/mishaps). The VFS will > > autofs v3 -> autofs.o > autofs v4 -> autofs4.o > May I suggest autofs5.o? It should still be named "autofs-something", > after all. > Nop. I will continue to develop under the v4 banner. As far as I'm concerned Peter Anvin has claimed v5 and I don't want to challenge that. Mike Waychisons' initiative may possibly be called v6??? In any case the module works fine with v3 and v4 (I haven't tested 4.0.0pre10 for a while though). The 4.1 daemon detects the enhanced module if present. It is currently dubed 4.04. The 'plays well with others' is a self imposed design requirement. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Fri Jan 9 22:08:35 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0A68Xa1003992 for ; Fri, 9 Jan 2004 22:08:34 -0800 Received: from hera.kernel.org (mailman@localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0A66kvC024615; Fri, 9 Jan 2004 22:06:48 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0A65dvA024577 for ; Fri, 9 Jan 2004 22:06:26 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i0A65b503731; Sat, 10 Jan 2004 14:05:37 +0800 Date: Sat, 10 Jan 2004 14:05:37 +0800 (WST) From: Ian Kent X-X-Sender: To: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-Reply-To: <3FFF1499.7030508@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.5, required 8, AWL, BAYES_10, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List cc: "H. Peter Anvin" X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Fri, 9 Jan 2004, Mike Waychison wrote: > > > >This may sound a little silly but it may be able to be done using > >stackable filesystem methods (aka. Zadok et. al.). I'm thinking of an > >autofs filesystem stacked on a host filesystem. The dentrys corresponding > >to mount points marked in some way and the mount occuring under it, on top > >of the host filesystem. Yes I know it sounds ugly but maybe it's not. > >Maybe it's actually quite simple. I can't give an opinion yet as I'm still > >thinking it through and haven't done any feasibility. However, this > >approach would lend itself to providing autofs filesystem transparency. A > >requirement as yet not discussed. > > > >Ian > > > > > > > Doing stackable filesystems is still an area of OS research. It turns > out to be a very hard problem to solve (if it's possible at all). > Although there are systems in the wild that appear to work, they are > usually sub-optimal because there remains alot of issues such as > maintaining coherent caches, as well as just staying coherent given that > one filesystem may be directly accessible while also accessed from > another overlayed filesystem. Yes I see that in what I've read. But I'm thinking of a very tightly controlled autofs layer controlled only by automount. Once owned by automount that part of the underlying fs could only be accessed via automount. The boundry cases obviously are a sensitive area. > > Not really something you'd want to waste alot of time on unless your > looking for a phd thesis. ;) A masters one day might be good. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 12 05:57:06 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0CDv5pC005436 for ; Mon, 12 Jan 2004 05:57:05 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0CDBFvC030994; Mon, 12 Jan 2004 05:22:57 -0800 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0CD8IvA030328 for ; Mon, 12 Jan 2004 05:09:43 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0CD7xj4020926 for ; Mon, 12 Jan 2004 05:07:59 -0800 (PST) Received: from sun.com (vpn-129-152-200-194.East.Sun.COM [129.152.200.194]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HRD00GTROH5M1@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Mon, 12 Jan 2004 05:07:59 -0800 (PST) Date: Mon, 12 Jan 2004 08:07:37 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: To: Ian Kent Message-id: <40029C19.409@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============66357132149658127==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============66357132149658127== Content-type: multipart/signed; boundary=------------enigEC06537060425A855A49AC28; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigEC06537060425A855A49AC28 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ian Kent wrote: >On Fri, 9 Jan 2004, Mike Waychison wrote: > > > >>>Indeed, I >>>haven't solved my requirement of a transparent autofs filesystem aka. >>>Solaris automounter again. A difficult problem that will require >>>considerable effort. >>> >>> >>> >>> >>> >>What do you mean by this? Something that doesn't show up in >>/proc/mounts? I don't see this as much of an issue.. On any decently >>large machine, there are so many entries anyway that /etc/mtab and >>/proc/mounts become humanly unparseable anyhow. >> >> > >Transparency of an autofs filesystem (as I'm calling it) is the situation >where, given a map > >/usr /man1 server:/usr/man1 > /man2 server:/usr/man2 > >where the filesystem /usr contains, say a directory lib, that needs to be >available while also seeing the automounted directories. > > > I see. This requires direct mount triggers to do properly. Trying to do it with some sort of passthrough to the underlying filesystem is a nightmare waiting to happen.. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enigEC06537060425A855A49AC28 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAApwcdQs4kOxk3/MRAgxRAJ41kSxekMyt39Ke4HakQsUWUnYWTACfUOq7 GcLnjaIeN5Z4V15fYeVMDFQ= =1Y6P -----END PGP SIGNATURE----- --------------enigEC06537060425A855A49AC28-- --===============66357132149658127== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============66357132149658127==-- From autofs-bounces@linux.kernel.org Mon Jan 12 09:12:25 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0CHCOpC025426 for ; Mon, 12 Jan 2004 09:12:25 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0CGUIvC015441; Mon, 12 Jan 2004 08:40:42 -0800 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0CGR7vA014284 for ; Mon, 12 Jan 2004 08:28:36 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i0CGQp0H004010 for ; Mon, 12 Jan 2004 08:26:51 -0800 (PST) Received: from sun.com (vpn-129-152-200-194.East.Sun.COM [129.152.200.194]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HRD00KH8XOM73@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Mon, 12 Jan 2004 08:26:51 -0800 (PST) Date: Mon, 12 Jan 2004 11:26:30 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: To: raven@themaw.net Message-id: <4002CAB6.3000800@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <40029C19.409@sun.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============85766676281288889==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: RO X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============85766676281288889== Content-type: multipart/signed; boundary=------------enig4349031CA658B7AE40F974E7; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4349031CA658B7AE40F974E7 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit raven@themaw.net wrote: >On Mon, 12 Jan 2004, Mike Waychison wrote: > > > >>>Transparency of an autofs filesystem (as I'm calling it) is the situation >>>where, given a map >>> >>>/usr /man1 server:/usr/man1 >>> /man2 server:/usr/man2 >>> >>>where the filesystem /usr contains, say a directory lib, that needs to be >>>available while also seeing the automounted directories. >>> >>> >>> >>> >>> >>I see. This requires direct mount triggers to do properly. Trying to >>do it with some sort of passthrough to the underlying filesystem is a >>nightmare waiting to happen.. >> >> >> > >So what are we saying here? > >We install triggers at /usr/man1 and /usr/man2. >Then suppose the map had a nobrowse option. >Does the trigger also take care of hiding man1 and man2? > >Is there some definition of these triggers? > > The example above is a direct map entry with no root offset. The semantics are different than if it were an indirect map with browsing enable. I tested this out against other automount implementations and discovered that direct map entries with no root offsets should be broken down into several direct map entries with root offsets.. so: /usr /man1 server:/usr/man1 \ /man2 server:/usr/man2 is the same as the two distinct entries: /usr/man1 server:/usr/man1 /usr/man2 server:/usr/man2 Now that I think about it, the discussion in my proposal paper about multimounts with no root offsets probably isn't required. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enig4349031CA658B7AE40F974E7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAAsq4dQs4kOxk3/MRAuO/AKCOZDrXEzeuiotXs7DKwPDbO7s7FQCggyQt t90Go9Kqf9D+0f/Be52arLE= =Fpm0 -----END PGP SIGNATURE----- --------------enig4349031CA658B7AE40F974E7-- --===============85766676281288889== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============85766676281288889==-- From autofs-bounces@linux.kernel.org Mon Jan 12 09:51:44 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0CHpipC010188 for ; Mon, 12 Jan 2004 09:51:44 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0CHM4vC027474; Mon, 12 Jan 2004 09:32:06 -0800 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0CGxMvA022061 for ; Mon, 12 Jan 2004 09:00:39 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0CGx6j4014012 for ; Mon, 12 Jan 2004 08:59:06 -0800 (PST) Received: from sun.com (vpn-129-152-200-194.East.Sun.COM [129.152.200.194]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HRD00KE7Z6E73@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Mon, 12 Jan 2004 08:59:06 -0800 (PST) Date: Mon, 12 Jan 2004 11:58:48 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: To: raven@themaw.net Message-id: <4002D248.2070304@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <40029C19.409@sun.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============84414468534079812==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============84414468534079812== Content-type: multipart/signed; boundary=------------enig8E1C5834750FE2B509569C84; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8E1C5834750FE2B509569C84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit raven@themaw.net wrote: >On Tue, 13 Jan 2004 raven@themaw.net wrote: > > > >>On Mon, 12 Jan 2004, Mike Waychison wrote: >> >> >> >>>>Transparency of an autofs filesystem (as I'm calling it) is the situation >>>>where, given a map >>>> >>>>/usr /man1 server:/usr/man1 >>>> /man2 server:/usr/man2 >>>> >>>>where the filesystem /usr contains, say a directory lib, that needs to be >>>>available while also seeing the automounted directories. >>>> >>>> >>>> >>>> >>>> >>>I see. This requires direct mount triggers to do properly. Trying to >>>do it with some sort of passthrough to the underlying filesystem is a >>>nightmare waiting to happen.. >>> >>> >>> >>So what are we saying here? >> >>We install triggers at /usr/man1 and /usr/man2. >>Then suppose the map had a nobrowse option. >>Does the trigger also take care of hiding man1 and man2? >> >>Is there some definition of these triggers? >> >> >> > >And I have another question concerning namespaces. > >Given that there may be several namespaces, each of which may or may not >have a trigger on this dentry, is there some sort of list of triggers? > >How do the triggers know who owns them? > > > > This is the reason I went with using distinct filesystems to perform the triggers. If we use follow_link logic, we will have a reference to the respective vfsmount. Dentry's themselves know nothing about the triggers, as the triggers just look like a mounted filesystem. The vfsmount information has enough information for autofs to call a userspace agent through hotplug and have userspace handle the mount. In effect, there is no daemon so nobody 'owns' a trigger in the same sense as with autofs3/4. As far as userspace is concerned, an autofs filesystem is mounted as is any other filesystem. All that is required is a proper set of mount options. For example, mounting auto_home on /home is: mount -t autofs -o maptype=indirect,mapname=auto_home auto_home /home Whenever somebody traverses into a subdir in /home within any namespace this autofs filesystem has been inherited, userspace is invoked (in that namespace) to perform the mount. Again, there is no 'ownership' other than maybe calling the namespace it resides it the 'owner', as you would for any other mountpoint. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enig8E1C5834750FE2B509569C84 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAAtJIdQs4kOxk3/MRAroLAKCK3K6/m+s+4z6i9/lmUi0C8FDDuACffvD7 Urm2y6k9IR6ct5RZ8FLFKno= =BwsR -----END PGP SIGNATURE----- --------------enig8E1C5834750FE2B509569C84-- --===============84414468534079812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============84414468534079812==-- From autofs-bounces@linux.kernel.org Mon Jan 12 16:04:53 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0D04qpC017327 for ; Mon, 12 Jan 2004 16:04:53 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0CNUnvC022009; Mon, 12 Jan 2004 15:31:55 -0800 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0CNT3vA021534 for ; Mon, 12 Jan 2004 15:29:56 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0CNSvj6017874 for ; Mon, 12 Jan 2004 15:28:57 -0800 (PST) Received: from sun.com (vpn-129-152-200-194.East.Sun.COM [129.152.200.194]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HRE00F0BH86IW@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Mon, 12 Jan 2004 15:28:57 -0800 (PST) Date: Mon, 12 Jan 2004 18:28:39 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: <20040112225023.GA21399@hockin.org> To: Tim Hockin Message-id: <40032DA7.8050000@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <40029C19.409@sun.com> <4002CAB6.3000800@sun.com> <20040112225023.GA21399@hockin.org> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List cc: raven@themaw.net X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============30772347636477004==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============30772347636477004== Content-type: multipart/signed; boundary=------------enig788D76FBBCA3F1090DD4A463; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig788D76FBBCA3F1090DD4A463 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Tim Hockin wrote: >On Mon, Jan 12, 2004 at 11:26:30AM -0500, Mike Waychison wrote: > > >>/usr /man1 server:/usr/man1 \ >> /man2 server:/usr/man2 >> >>is the same as the two distinct entries: >> >>/usr/man1 server:/usr/man1 >>/usr/man2 server:/usr/man2 >> >>Now that I think about it, the discussion in my proposal paper about >>multimounts with no root offsets probably isn't required. >> >> > >The latter requires /usr/man1 and /usr/man2 to exist. The former only >requires /usr to exist, right? > > > Traditionally, the automount system is allowed to create directories as needed. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enig788D76FBBCA3F1090DD4A463 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFAAy2ndQs4kOxk3/MRApKuAJwIIty8W5ZigLpLxBPPZECLrC2JCQCghWYO 60hir2yXhTXrl4XMqW4hzXs= =9vNr -----END PGP SIGNATURE----- --------------enig788D76FBBCA3F1090DD4A463-- --===============30772347636477004== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============30772347636477004==-- From autofs-bounces@linux.kernel.org Mon Jan 12 17:42:02 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0D1g1pC019633 for ; Mon, 12 Jan 2004 17:42:02 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0D1VbvC019218; Mon, 12 Jan 2004 17:31:43 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0D1U4vA018963 for ; Mon, 12 Jan 2004 17:31:00 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i0D1U6510105; Tue, 13 Jan 2004 09:30:06 +0800 Date: Tue, 13 Jan 2004 09:30:06 +0800 (WST) From: Ian Kent X-X-Sender: To: Tim Hockin Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-Reply-To: <20040112225023.GA21399@hockin.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.5, required 8, AWL, BAYES_10, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Mike Waychison cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Mon, 12 Jan 2004, Tim Hockin wrote: > On Mon, Jan 12, 2004 at 11:26:30AM -0500, Mike Waychison wrote: > > /usr /man1 server:/usr/man1 \ > > /man2 server:/usr/man2 > > > > is the same as the two distinct entries: > > > > /usr/man1 server:/usr/man1 > > /usr/man2 server:/usr/man2 > > > > Now that I think about it, the discussion in my proposal paper about > > multimounts with no root offsets probably isn't required. > > The latter requires /usr/man1 and /usr/man2 to exist. The former only > requires /usr to exist, right? > That's one possibility, but man1 and man2 could simply not call filler in the readdir call. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 12 17:56:58 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0D1uvpC019668 for ; Mon, 12 Jan 2004 17:56:58 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0D1shvC024996; Mon, 12 Jan 2004 17:54:47 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0D1rpvA024774 for ; Mon, 12 Jan 2004 17:54:35 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i0D1s6510389; Tue, 13 Jan 2004 09:54:06 +0800 Date: Tue, 13 Jan 2004 09:54:06 +0800 (WST) From: Ian Kent X-X-Sender: To: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-Reply-To: <4002D248.2070304@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.6, required 8, AWL, BAYES_10, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: RO X-Status: On Mon, 12 Jan 2004, Mike Waychison wrote: > > > >And I have another question concerning namespaces. > > > >Given that there may be several namespaces, each of which may or may not > >have a trigger on this dentry, is there some sort of list of triggers? > > > >How do the triggers know who owns them? > > > > > > > > > This is the reason I went with using distinct filesystems to perform the > triggers. If we use follow_link logic, we will have a reference to the > respective vfsmount. Dentry's themselves know nothing about the > triggers, as the triggers just look like a mounted filesystem. The > vfsmount information has enough information for autofs to call a > userspace agent through hotplug and have userspace handle the mount. In > effect, there is no daemon so nobody 'owns' a trigger in the same sense > as with autofs3/4. I'm not familiar with the follow_link mechanism (no prob. I'll pick it up as I go). Correct me if I'm wrong but, the only thing that I can see that is duplicated in cloning a namespace is the root dentry. The rest of the dentries on the system remain the same. The increase in complexity to the VFS to change this would be prohibitive. I see we want the triggers in the vfsmount struct. Is this a good idea? The vfsmount struct has always been difficult to get hold of during lookup and revalidate for me (someone like to help here). > > As far as userspace is concerned, an autofs filesystem is mounted as is > any other filesystem. All that is required is a proper set of mount > options. For example, mounting auto_home on /home is: > > mount -t autofs -o maptype=indirect,mapname=auto_home auto_home /home > > Whenever somebody traverses into a subdir in /home within any namespace > this autofs filesystem has been inherited, userspace is invoked (in that > namespace) to perform the mount. Again, there is no 'ownership' other > than maybe calling the namespace it resides it the 'owner', as you would > for any other mountpoint. The "mount all automount entries" has always been the simpler option but, as you know, the kernel still allows only 255 anonymous mounts. This would have to be the first order of business. Ohh, I was supposed to be working on sysctl inerface for that. I'll just be quiet now. Also, something needs to be done about mount table noise. Several hundred entries is very bad from an administration viewpoint. Except for the cross namespace issues, which I'm still digesting, I can't see why your design can't be done entirely as a filesystem using dentries instead of vfsmount, including expirey. Perhaps you could reinterate a few of the reasons for this. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 12 19:42:00 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0D3fxpC021948 for ; Mon, 12 Jan 2004 19:41:59 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0D3auvC017637; Mon, 12 Jan 2004 19:37:12 -0800 Received: from mail.iinet.net.au (mail-10.iinet.net.au [203.59.3.42]) by hera.kernel.org (8.12.8/8.12.8) with SMTP id i0D3a0vA017609 for ; Mon, 12 Jan 2004 19:36:40 -0800 Received: (qmail 31656 invoked from network); 12 Jan 2004 16:01:18 -0000 Received: from unknown (HELO raven.themaw.net) (203.59.113.56) by mail.iinet.net.au with SMTP; 12 Jan 2004 16:01:18 -0000 Date: Tue, 13 Jan 2004 00:01:26 +0800 (WST) From: raven@themaw.net To: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-Reply-To: <40029C19.409@sun.com> Message-ID: References: <40029C19.409@sun.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Mon, 12 Jan 2004, Mike Waychison wrote: > > > >Transparency of an autofs filesystem (as I'm calling it) is the situation > >where, given a map > > > >/usr /man1 server:/usr/man1 > > /man2 server:/usr/man2 > > > >where the filesystem /usr contains, say a directory lib, that needs to be > >available while also seeing the automounted directories. > > > > > > > I see. This requires direct mount triggers to do properly. Trying to > do it with some sort of passthrough to the underlying filesystem is a > nightmare waiting to happen.. > So what are we saying here? We install triggers at /usr/man1 and /usr/man2. Then suppose the map had a nobrowse option. Does the trigger also take care of hiding man1 and man2? Is there some definition of these triggers? Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 13 06:43:57 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0DEhvpC019339 for ; Tue, 13 Jan 2004 06:43:57 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DESEvC022575; Tue, 13 Jan 2004 06:28:42 -0800 Received: from bbnrelint01.net.external.hp.com (bbnrelint01.net.external.hp.com [192.6.76.88]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DERHvA022078 for ; Tue, 13 Jan 2004 06:28:04 -0800 Received: from isar.bbn.hp.com (isar.bbn.hp.com [15.140.168.13]) by bbnrelint01.net.external.hp.com (Postfix) with ESMTP id 469A137C87 for ; Tue, 13 Jan 2004 15:17:35 +0100 (CET) Received: by isar.bbn.hp.com with Internet Mail Service (5.5.2657.72) id ; Tue, 13 Jan 2004 15:27:05 +0100 Message-ID: From: "MARX,ALEXANDER (HP-Germany,ex1)" To: autofs@linux.kernel.org Date: Tue, 13 Jan 2004 15:26:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org Subject: [autofs] autofs no_local_binds option (nfs <-> bind mounts) X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hi list, autofs (v4,3.1.7-425) is too intelligent ... Directory 'test' is exported via the nfs server on host 'foo' and imported again via the linux automounter locally as soon as 'test' is accessed (corresponding entry in automounter map). The automounter recognizes that 'test' is a local directory and performs a bind mount. Great feature - BUT, there is no way to turn off this functionality. I would need to always have nfs mounts regardless of having the exported directory locally or remotely. In some scenarios (e.g. HA), the nfs server could switch from local to remote, therefore having local binds is not a desirable scenario, there should always be nfs mounts. Is there some kind of workaround or possibiliy to perform such actions, or will the automounter always be smarter that me :-) ? Thanks, Alex - Alexander Marx _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 13 09:17:29 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0DHHTpC021937 for ; Tue, 13 Jan 2004 09:17:29 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DHEovC030309; Tue, 13 Jan 2004 09:14:59 -0800 Received: from terminus.zytor.com (IDENT:root@terminus.zytor.com [63.209.29.3]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DHEcvA030302 for ; Tue, 13 Jan 2004 09:14:39 -0800 Received: from zytor.com (bunbun.zytor.com [66.80.2.163]) (authenticated bits=0) by terminus.zytor.com (8.12.8/8.12.8) with ESMTP id i0DHEXWk007648 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jan 2004 09:14:33 -0800 Message-ID: <40042774.7070003@zytor.com> Date: Tue, 13 Jan 2004 09:14:28 -0800 From: "H. Peter Anvin" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20040105 X-Accept-Language: en, sv, es, fr MIME-Version: 1.0 To: "MARX,ALEXANDER (HP-Germany,ex1)" Subject: Re: [autofs] autofs no_local_binds option (nfs <-> bind mounts) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: MARX,ALEXANDER (HP-Germany,ex1) wrote: > > In some scenarios (e.g. HA), the nfs server could switch from local to > remote, therefore having local binds is not a desirable scenario, there > should always be nfs mounts. > How would you expect this to work? The local bind only happens when local and destination address are the same, therefore keeping anything from going across the network no matter how you slice it. Changing the DNS name of the NFS server has no effect, since once the mount has happened the name was already resolved, and it can't be redirected. Changing the IP address runs into the problem that local == remote. -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 13 09:54:13 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0DHsCTu006757 for ; Tue, 13 Jan 2004 09:54:13 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DHoIvC006238; Tue, 13 Jan 2004 09:51:00 -0800 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DHn7vA005879 for ; Tue, 13 Jan 2004 09:49:57 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i0DHn20J003558 for ; Tue, 13 Jan 2004 09:49:02 -0800 (PST) Received: from sun.com (vpn-129-152-200-194.East.Sun.COM [129.152.200.194]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HRF00475W5MNJ@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Tue, 13 Jan 2004 09:49:02 -0800 (PST) Date: Tue, 13 Jan 2004 12:48:37 -0500 From: Mike Waychison Subject: Re: [autofs] autofs no_local_binds option (nfs <-> bind mounts) In-reply-to: <40042774.7070003@zytor.com> To: "H. Peter Anvin" Message-id: <40042F75.9040304@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <40042774.7070003@zytor.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: "MARX,ALEXANDER \(HP-Germany,ex1\)" cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============31425238736437389==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============31425238736437389== Content-type: multipart/signed; boundary=------------enig45D20319BB9CCCAA187A8140; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig45D20319BB9CCCAA187A8140 Content-Type: multipart/mixed; boundary="------------060703050209020200010505" This is a multi-part message in MIME format. --------------060703050209020200010505 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit H. Peter Anvin wrote: > MARX,ALEXANDER (HP-Germany,ex1) wrote: > >> >> In some scenarios (e.g. HA), the nfs server could switch from local to >> remote, therefore having local binds is not a desirable scenario, there >> should always be nfs mounts. >> > > How would you expect this to work? The local bind only happens when > local and destination address are the same, therefore keeping anything > from going across the network no matter how you slice it. > This is policy made by the daemon that IMHO may be trying to be too smart about what the user wants. I've attached a quick patch, compiled not tested that shows how you can add a no_local_binds option to entries (written against 4.0.0pre10 because that's what I have on my laptop atm). Doing local binds may not be the right thing to do in the first place. It makes assumptions that the local nfs server is serving the same namespace/filesystems as the current application and it will break NFS v4 replication and migration when it's ready. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------060703050209020200010505 Content-Type: text/plain; name="nolocalbinds.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="nolocalbinds.patch" diff -ru orig/modules/mount_nfs.c autofs-4.0.0pre10/modules/mount_nfs.c --- orig/modules/mount_nfs.c 2004-01-13 09:29:27.000000000 -0800 +++ autofs-4.0.0pre10/modules/mount_nfs.c 2004-01-13 09:30:06.000000000 -0800 @@ -73,6 +73,7 @@ struct sockaddr_in saddr, laddr; int sock, local, err; int nosymlink = 0; + int nolocalbinds = 0; size_t len; syslog(LOG_DEBUG, MODPREFIX " root=%s name=%s what=%s, fstype=%s, options=%s", @@ -113,6 +114,8 @@ #endif if (strncmp("nosymlink", cp, comma-cp-1) == 0) nosymlink = 1; + if (strncmp("no_local_binds", cp, comma-cp-1) == 0) + nolocalbinds = 1; else { memcpy(nfsp, cp, comma-cp+1); nfsp += comma-cp+1; @@ -205,7 +208,7 @@ } sprintf(fullpath, "%s/%s", root, name); - if ( local ) { + if ( local && !nolocalbinds ) { /* Local host -- do a "bind" */ syslog(LOG_DEBUG, MODPREFIX "%s is local, doing bind", name); --------------060703050209020200010505-- --------------enig45D20319BB9CCCAA187A8140 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFABC94dQs4kOxk3/MRAgUzAJ4+AZZnIXFXufzGmIBm9IQKJhu96gCff3Yw hIDYQfmn++QhYickKlJrNos= =nLqQ -----END PGP SIGNATURE----- --------------enig45D20319BB9CCCAA187A8140-- --===============31425238736437389== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============31425238736437389==-- From autofs-bounces@linux.kernel.org Tue Jan 13 10:51:08 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0DIp7Tu024363 for ; Tue, 13 Jan 2004 10:51:07 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DImKvC020545; Tue, 13 Jan 2004 10:48:27 -0800 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DIlLvA020233 for ; Tue, 13 Jan 2004 10:48:09 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i0DIlF0H002720 for ; Tue, 13 Jan 2004 10:47:15 -0800 (PST) Received: from sun.com (vpn-129-152-200-194.East.Sun.COM [129.152.200.194]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HRF00DJLYUNI3@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Tue, 13 Jan 2004 10:47:15 -0800 (PST) Date: Tue, 13 Jan 2004 13:46:49 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: To: raven@themaw.net Message-id: <40043D19.3010608@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <40029C19.409@sun.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============78994977434453695==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============78994977434453695== Content-type: multipart/signed; boundary=------------enig5E7A436193FFFE5FA916DA2B; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig5E7A436193FFFE5FA916DA2B Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit raven@themaw.net wrote: >On Mon, 12 Jan 2004, Mike Waychison wrote: > > > >>>Transparency of an autofs filesystem (as I'm calling it) is the situation >>>where, given a map >>> >>>/usr /man1 server:/usr/man1 >>> /man2 server:/usr/man2 >>> >>>where the filesystem /usr contains, say a directory lib, that needs to be >>>available while also seeing the automounted directories. >>> >>> >>> >>> >>> >>I see. This requires direct mount triggers to do properly. Trying to >>do it with some sort of passthrough to the underlying filesystem is a >>nightmare waiting to happen.. >> >> >> > >So what are we saying here? > >We install triggers at /usr/man1 and /usr/man2. >Then suppose the map had a nobrowse option. > > This is a direct map. The browse / nobrowse options do not apply to direct maps. >Does the trigger also take care of hiding man1 and man2? > > > No. man1 and man2 appear as directories to anyone doing an lstat on them. Traversing *into* them will cause filesystems to be mounted on them. This appears to be similar to browsing of an indirect map at first, however it is a different beast. With indirect maps, we are given the right to cover up /usr to help us detects stats and traversals into its sub-directories. With direct entries, we don't have these leisure. Everything in /usr most be accessible at all times. Your need for 'transparency' comes from the fact that you convert direct maps into indirect maps, which require the covering of /usr. >Is there some definition of these triggers? > > > This question is up in the air. I propose using a magic filesystem, whose root dentry has a follow_link callback defined. When somebody walks into the filesystem, the follow_link is called, which does the mount onto a different dentry, and then forwards the original caller to the new vfsmount/dentry pair. HPA and Viro believe this is better done in the VFS layer directly by using special vfsmounts without super_blocks. The path walking code would be modified to know of these 'traps' or 'triggers' natively. Which solution is best is left as an exercise. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enig5E7A436193FFFE5FA916DA2B Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFABD0cdQs4kOxk3/MRAl02AJ9DeLf53/wgbXORk2P/11UkCKKRHgCfYQ4j Jsl0hzwGpzEN0Cyy26d8+oc= =6X1I -----END PGP SIGNATURE----- --------------enig5E7A436193FFFE5FA916DA2B-- --===============78994977434453695== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============78994977434453695==-- From autofs-bounces@linux.kernel.org Tue Jan 13 11:16:44 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0DJGhTu024464 for ; Tue, 13 Jan 2004 11:16:44 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DJ3YvC024443; Tue, 13 Jan 2004 11:03:47 -0800 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DJ2NvA024119 for ; Tue, 13 Jan 2004 11:03:12 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0DJ2DjA012844 for ; Tue, 13 Jan 2004 11:02:16 -0800 (PST) Received: from sun.com (vpn-129-152-200-194.East.Sun.COM [129.152.200.194]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HRF00DVTZJNI3@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Tue, 13 Jan 2004 11:02:15 -0800 (PST) Date: Tue, 13 Jan 2004 14:01:48 -0500 From: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs In-reply-to: To: Ian Kent Message-id: <4004409C.6040900@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs mailing list cc: Kernel Mailing List X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============097166618615483147==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============097166618615483147== Content-type: multipart/signed; boundary=------------enig33ACE2770E76760CD51F22AF; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig33ACE2770E76760CD51F22AF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ian Kent wrote: >On Mon, 12 Jan 2004, Mike Waychison wrote: > > > >>>And I have another question concerning namespaces. >>> >>>Given that there may be several namespaces, each of which may or may not >>>have a trigger on this dentry, is there some sort of list of triggers? >>> >>>How do the triggers know who owns them? >>> >>> >>> >>> >>> >>> >>This is the reason I went with using distinct filesystems to perform the >>triggers. If we use follow_link logic, we will have a reference to the >>respective vfsmount. Dentry's themselves know nothing about the >>triggers, as the triggers just look like a mounted filesystem. The >>vfsmount information has enough information for autofs to call a >>userspace agent through hotplug and have userspace handle the mount. In >>effect, there is no daemon so nobody 'owns' a trigger in the same sense >>as with autofs3/4. >> >> > >I'm not familiar with the follow_link mechanism (no prob. I'll pick it up >as I go). > >Correct me if I'm wrong but, the only thing that I can see that is >duplicated in cloning a namespace is the root dentry. The rest of the >dentries on the system remain the same. The increase in complexity to the >VFS to change this would be prohibitive. > > No. Dentries are *never* duplicated. This goes back to Viro's work on allowing a filesystem to be mounted in multiple locations. See http://kt.zork.net/kernel-traffic/kt20000424_64.html#9 . What is duplicated is the current->namespace tree of vfsmounts. After this is done, current->fs vfsmount members are updated to point to their cloned counterparts. >I see we want the triggers in the vfsmount struct. Is this a good idea? >The vfsmount struct has always been difficult to get hold of during lookup >and revalidate for me (someone like to help here). > > > If triggers in the vfsmount struct are done, then there will be no need to handle lookups or revalidates. In fact, triggers in the vfsmount struct will not help at all for indirect maps. > >Also, something needs to be done about mount table noise. Several hundred >entries is very bad from an administration viewpoint. > > I don't see what you want here. If you have hundreds of users logged into the same machine, you *will* have hundreds of entries in the mount-table. >Except for the cross namespace issues, which I'm still digesting, I can't >see why your design can't be done entirely as a filesystem using dentries >instead of vfsmount, including expirey. Perhaps you could reinterate a few >of the reasons for this. > > My proposal uses filesystems for all automount mechanism *except* expiry. I see expiry as a VFS service, and strongly believe that this is where it belongs. -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enig33ACE2770E76760CD51F22AF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFABEChdQs4kOxk3/MRAjN2AKCYbtW16sHaHGc0DnOHbrpDDjdjlACggMC8 tD9N1UTqN+4PmyjD0gmi874= =b8tF -----END PGP SIGNATURE----- --------------enig33ACE2770E76760CD51F22AF-- --===============097166618615483147== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============097166618615483147==-- From autofs-bounces@linux.kernel.org Tue Jan 13 12:11:25 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0DKBPTu009319 for ; Tue, 13 Jan 2004 12:11:25 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DK4tvC006640; Tue, 13 Jan 2004 12:05:07 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DK4lvA006633 for ; Tue, 13 Jan 2004 12:04:47 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id MAA20172; Tue, 13 Jan 2004 12:04:18 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma020158; Tue, 13 Jan 04 12:03:53 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i0DK3tf14205; Tue, 13 Jan 2004 12:03:55 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) i0DK3s2c025047; Tue, 13 Jan 2004 12:03:54 -0800 Message-ID: <40044F2A.9080305@zytor.com> Date: Tue, 13 Jan 2004 12:03:54 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: Eric Werme USG Subject: Re: [autofs] autofs no_local_binds option (nfs <-> bind mounts) References: <200401131958.i0DJwlV0001078000@anw.zk3.dec.com> In-Reply-To: <200401131958.i0DJwlV0001078000@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs@linux.kernel.org cc: alexander.marx@hp.com X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Eric Werme USG wrote: > > The stop-gap cluster system in Tru64 Unix did this. Typically pairs > of servers had system names (service names in the jargon) and bound > the IP address to a NIC on one server. When the service was relocated > manually or on a crash, the IP address was moved to a NIC on the other > server. Disks were on a shared SCSI bus, and the file system would also > go through a umount/mount cycle. Note that no changes to DNS' database > are necessary, just an update to clients' arp tables. > > For example, we have systems "mailhub1" and "mailhub2". The service name > "mailhub" is where Email here winds up. I send mail via SMTP to mailhub, and > read it via NFS from mailhub. Normally I don't care which of mailhub1 > and mailhub2 handles it. For the most part they're just servers, but > sometimes there are reasons to login to one or both of those systems. However, this doesn't address the issue of the client being *the same system*, in which case you can't just move the IP address away from it, since local == remote; you can no longer send packets to the server and get a response back. You can do it if you can get the client and the server sides to bind to *different* IP addresses, in which case the current autofs behaviour will correctly see them as being separate and mount NFS. -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 13 12:30:58 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0DKUqTu009652 for ; Tue, 13 Jan 2004 12:30:58 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DKOtvC011860; Tue, 13 Jan 2004 12:25:07 -0800 Received: from ptb-relay03.plus.net (ptb-relay03.plus.net [212.159.14.214]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DKO0vA011654 for ; Tue, 13 Jan 2004 12:24:49 -0800 Received: from [212.159.72.97] (helo=scooby.etta.local) by ptb-relay03.plus.net with esmtp (Exim) id 1AgV4o-000Gh2-Uh; Tue, 13 Jan 2004 20:23:51 +0000 From: Dylan To: "H. Peter Anvin" , Eric Werme USG Subject: Re: [autofs] autofs no_local_binds option (nfs <-> bind mounts) Date: Tue, 13 Jan 2004 20:23:49 +0000 User-Agent: KMail/1.5.4 References: <200401131958.i0DJwlV0001078000@anw.zk3.dec.com> <40044F2A.9080305@zytor.com> In-Reply-To: <40044F2A.9080305@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401132023.49657.autofs@dylan.me.uk> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tuesday 13 January 2004 20:03 pm, H. Peter Anvin wrote: > However, this doesn't address the issue of the client being *the same > system*, in which case you can't just move the IP address away from > it, since local == remote; you can no longer send packets to the > server and get a response back. You can do it if you can get the > client and the server sides to bind to *different* IP addresses, in > which case the current autofs behaviour will correctly see them as > being separate and mount NFS. Would binding an alias address to the interface be sufficient? Dylan -- Sweet moderation Heart of this nation Desert us not We are between the wars - Billy Bragg _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 13 12:31:39 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0DKVdTu009658 for ; Tue, 13 Jan 2004 12:31:39 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DKRCvC012204; Tue, 13 Jan 2004 12:27:15 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DKQsvA012175 for ; Tue, 13 Jan 2004 12:26:54 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id MAA21145; Tue, 13 Jan 2004 12:25:57 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma021132; Tue, 13 Jan 04 12:25:45 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i0DKPnf15503; Tue, 13 Jan 2004 12:25:49 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) i0DKPm2c025535; Tue, 13 Jan 2004 12:25:48 -0800 Message-ID: <4004544C.7030904@zytor.com> Date: Tue, 13 Jan 2004 12:25:48 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: Dylan Subject: Re: [autofs] autofs no_local_binds option (nfs <-> bind mounts) References: <200401131958.i0DJwlV0001078000@anw.zk3.dec.com> <40044F2A.9080305@zytor.com> <200401132023.49657.autofs@dylan.me.uk> In-Reply-To: <200401132023.49657.autofs@dylan.me.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs@linux.kernel.org cc: Eric Werme USG X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Dylan wrote: > On Tuesday 13 January 2004 20:03 pm, H. Peter Anvin wrote: > > >>However, this doesn't address the issue of the client being *the same >>system*, in which case you can't just move the IP address away from >>it, since local == remote; you can no longer send packets to the >>server and get a response back. You can do it if you can get the >>client and the server sides to bind to *different* IP addresses, in >>which case the current autofs behaviour will correctly see them as >>being separate and mount NFS. > > Would binding an alias address to the interface be sufficient? > No, you have to force the local port to not be bound to the same address. I think this can be done with iptables rules, but I'm not sure... I'm not a networking wizard. -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 13 13:01:52 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0DL1pTu026926 for ; Tue, 13 Jan 2004 13:01:52 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DKu6vC019379; Tue, 13 Jan 2004 12:56:23 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DKthvA019345 for ; Tue, 13 Jan 2004 12:55:44 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id MAA22671; Tue, 13 Jan 2004 12:55:12 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma022665; Tue, 13 Jan 04 12:54:46 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i0DKsof17252; Tue, 13 Jan 2004 12:54:50 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) i0DKsn2c025751; Tue, 13 Jan 2004 12:54:49 -0800 Message-ID: <40045B19.2040301@zytor.com> Date: Tue, 13 Jan 2004 12:54:49 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: Eric Werme USG Subject: Re: [autofs] autofs no_local_binds option (nfs <-> bind mounts) References: <200401132042.i0DKgDR0001085265@anw.zk3.dec.com> In-Reply-To: <200401132042.i0DKgDR0001085265@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs@linux.kernel.org cc: alexander.marx@hp.com X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Eric Werme USG wrote: > > *the same system* as the server? I don't know much about Linux internals, > one reason I don't post here often, but I try to offer insight to other > systems. Tru64 Unix has a lot of BSD heritage. If mailhub1 is providing the > mailhub service and mounts something from mailhub, messages sent to mailhub > will be caught in the routing code and directed to the loopback "NIC" lo0. > If the mailhub service (IP address) is relocated to mailhub2, the routing > code will see that no NIC on mailhub1 has the mailhub IP address and will > give the message to a NIC that can reach it. (And ARP resolves the MAC > address and it all runs like a normal remote mount.) > That one is not a problem. The problem is that you either need to force the local address of the mount explicitly at the application layer (in this case this would require a localaddr= option to mount, or something similar) or it needs to be done by setting up the appropriate rules in the kernel. > Ah. Back to automount/autofs. I made many fixes to Sun's old automount, > one of them was to rummage among all the NICs looking to see if the > FS was really a local mount and provide the appropriate symlink. The > cluster folks didn't realize I also checked the alias addresses too, > so I had to add an option to disable that to force a real NFS call. > > You mention "you can't just move the IP address away," is that something > Linux doesn't support yet? No problem on Tru64. A NIC has one permanent > address and a bunch of aliases that can come and go at the whims of the > admins or load balancing software: No, the problem is: which local address will the socket be bound to. -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 13 13:03:51 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0DL3oTu026937 for ; Tue, 13 Jan 2004 13:03:50 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DL0YvC020412; Tue, 13 Jan 2004 13:00:40 -0800 Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DKxFvA020196 for ; Tue, 13 Jan 2004 13:00:06 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by brmea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i0DKx8qZ028536 for ; Tue, 13 Jan 2004 13:59:09 -0700 (MST) Received: from sun.com (vpn-129-152-200-194.East.Sun.COM [129.152.200.194]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HRG0070X4YHHS@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Tue, 13 Jan 2004 12:59:08 -0800 (PST) Date: Tue, 13 Jan 2004 15:58:43 -0500 From: Mike Waychison Subject: Re: [autofs] autofs no_local_binds option (nfs <-> bind mounts) In-reply-to: <4004544C.7030904@zytor.com> To: "H. Peter Anvin" Message-id: <40045C03.7020405@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <200401131958.i0DJwlV0001078000@anw.zk3.dec.com> <40044F2A.9080305@zytor.com> <200401132023.49657.autofs@dylan.me.uk> <4004544C.7030904@zytor.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs@linux.kernel.org cc: Eric Werme USG X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============58097944038240756==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============58097944038240756== Content-type: multipart/signed; boundary=------------enig9199E617F590C39C0F2FF355; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9199E617F590C39C0F2FF355 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit H. Peter Anvin wrote: >Dylan wrote: > > >>On Tuesday 13 January 2004 20:03 pm, H. Peter Anvin wrote: >> >> >> >> >>>However, this doesn't address the issue of the client being *the same >>>system*, in which case you can't just move the IP address away from >>>it, since local == remote; you can no longer send packets to the >>>server and get a response back. You can do it if you can get the >>>client and the server sides to bind to *different* IP addresses, in >>>which case the current autofs behaviour will correctly see them as >>>being separate and mount NFS. >>> >>> >>Would binding an alias address to the interface be sufficient? >> >> >> > >No, you have to force the local port to not be bound to the same >address. I think this can be done with iptables rules, but I'm not >sure... I'm not a networking wizard. > > > I know you can do this using chbind from the vserver toolset and kernel patch. http://www.13thfloor.at/vserver/s_release/v1.23/ -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enig9199E617F590C39C0F2FF355 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFABFwGdQs4kOxk3/MRAtbNAKCNi94tossdCAsNiENLZ4TbDtEYfwCdGxrk O1uVzyNZampEMzHOz4hWV3o= =6jXp -----END PGP SIGNATURE----- --------------enig9199E617F590C39C0F2FF355-- --===============58097944038240756== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============58097944038240756==-- From autofs-bounces@linux.kernel.org Tue Jan 13 13:08:56 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0DL8tTu026948 for ; Tue, 13 Jan 2004 13:08:55 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DL6qvC021924; Tue, 13 Jan 2004 13:07:02 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DL61vA021907 for ; Tue, 13 Jan 2004 13:06:02 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id NAA23280; Tue, 13 Jan 2004 13:05:04 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma023261; Tue, 13 Jan 04 13:04:48 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i0DL4qf17910; Tue, 13 Jan 2004 13:04:52 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) i0DL4p2c025758; Tue, 13 Jan 2004 13:04:52 -0800 Message-ID: <40045D73.4010103@zytor.com> Date: Tue, 13 Jan 2004 13:04:51 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: Eric Werme USG Subject: Re: [autofs] autofs no_local_binds option (nfs <-> bind mounts) References: <200401132042.i0DKgDR0001085265@anw.zk3.dec.com> In-Reply-To: <200401132042.i0DKgDR0001085265@anw.zk3.dec.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs@linux.kernel.org cc: alexander.marx@hp.com X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Eric Werme USG wrote: > > Ah. Back to automount/autofs. I made many fixes to Sun's old automount, > one of them was to rummage among all the NICs looking to see if the > FS was really a local mount and provide the appropriate symlink. The > cluster folks didn't realize I also checked the alias addresses too, > so I had to add an option to disable that to force a real NFS call. > Perhaps I should clarify the algorithm used by autofs: it actually goes through and creates a socket and connects it to each of the IP addresses for a server (it uses a UDP socket, so it doesn't actually cause any network traffic.) Then it queries that socket to see what the local and remote addresses the kernel chose for the socket. If for any of the possible addresses then the address is deemed local and autofs will bind-mount. It is thus strictly based on what the kernel would choose as the local address. If you can force the local address to be something other than the remote address -- as you need for relocatability anyway -- then autofs will quite correctly avoid bind-mounting it. Mike raised the at least theoretical issue of what about synthetic NFS servers in userspace and similar issues. I'm not convinced this is an issue in practice, but we came up with the suggestion of making an *explicit* -fstype=nfs force NFS mounting regardless. This has the advantage that it cleans up the daemon somewhat; instead of: parse_sun | mount_nfs | mount_bind one would have: parse_sun | mount_default / \ mount_nfs mount_bind -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 13 13:09:13 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0DL9DTu026954 for ; Tue, 13 Jan 2004 13:09:13 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DL7HvC021964; Tue, 13 Jan 2004 13:07:18 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DL7CvA021953 for ; Tue, 13 Jan 2004 13:07:12 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id NAA23365; Tue, 13 Jan 2004 13:06:43 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma023359; Tue, 13 Jan 04 13:06:31 -0800 Received: from neocesium.transmeta.com (neocesium.transmeta.com [10.10.25.50]) i0DL6Yf18035; Tue, 13 Jan 2004 13:06:34 -0800 (PST) Received: from zytor.com (localhost.localdomain [127.0.0.1]) i0DL6Y2c025770; Tue, 13 Jan 2004 13:06:34 -0800 Message-ID: <40045DDA.1010805@zytor.com> Date: Tue, 13 Jan 2004 13:06:34 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: Mike Waychison Subject: Re: [autofs] autofs no_local_binds option (nfs <-> bind mounts) References: <200401131958.i0DJwlV0001078000@anw.zk3.dec.com> <40044F2A.9080305@zytor.com> <200401132023.49657.autofs@dylan.me.uk> <4004544C.7030904@zytor.com> <40045C03.7020405@sun.com> In-Reply-To: <40045C03.7020405@sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org cc: autofs@linux.kernel.org cc: Eric Werme USG X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Mike Waychison wrote: >>> >>> Would binding an alias address to the interface be sufficient? >>> >> No, you have to force the local port to not be bound to the same >> address. I think this can be done with iptables rules, but I'm not >> sure... I'm not a networking wizard. >> > I know you can do this using chbind from the vserver toolset and kernel > patch. > > http://www.13thfloor.at/vserver/s_release/v1.23/ There you go, then. Either way, autofs should respect this rule once it is installed in the kernel. -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 14 08:31:13 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0EGVDDG004128 for ; Wed, 14 Jan 2004 08:31:13 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0EGOevC016088; Wed, 14 Jan 2004 08:24:59 -0800 Received: from dewire.com ([212.28.208.94]) by hera.kernel.org (8.12.8/8.12.8) with SMTP id i0EGNUvA015834 for ; Wed, 14 Jan 2004 08:24:23 -0800 Received: (qmail 32631 invoked by uid 0); 14 Jan 2004 16:27:42 -0000 Received: from unknown (HELO xine.dewire.com) (127.0.0.1) by 127.0.0.1 with SMTP; 14 Jan 2004 16:27:42 -0000 From: Robin Rosenberg To: autofs@linux.kernel.org Date: Wed, 14 Jan 2004 17:23:28 +0100 User-Agent: KMail/1.5.3 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200401141723.28338.robin.rosenberg.lists@dewire.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org Subject: [autofs] Autofs question X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hi, 1) I grabbed the Dieter Demerre's auto.smb script for mounting samba/windows shares making life hellofalot simpler when it comes to accessing Windows shares. One of the flaws is that I'd like to get around is that it must be configured as root, as opposed to by the user who wants to access a share, and most importantly that I don't see who is requesting the mount. I was thinking along the line of mounting shares in /cifs/$USER/servers/share or simply mounting the share for the first user using the mount point (essentially single user or one-user-at-a-time machines anyway). the auto.smb script is running as root and I printed some info in root.c at the revalidate Jan 12 18:49:06 h6n2fls33o811 kernel: autofs4_root_revalidate, uid=505 name=10.1.1.4 Jan 12 18:49:06 h6n2fls33o811 automount[22233]: attempting to mount entry /cifs/10.1.1.4 Jan 12 18:49:06 h6n2fls33o811 kernel: autofs4_root_revalidate, uid=0 name=10.1.1.4 Jan 12 18:49:06 h6n2fls33o811 logger: uid=0(root) gid=0(root) grupper=0(root) Jan 12 18:49:07 h6n2fls33o811 kernel: autofs4_root_revalidate, uid=0 name=10.1.1.4 Jan 12 18:49:08 h6n2fls33o811 last message repeated 10 times and lots more from mounting with uid=0 Is there any simple way of passing the first uid to the automounter daemon? 2) Another anoying thing with autofs is that it mounts all shares on the machine which is a problem when I don't have access to all. 3) How can the returned map handle spaces in the share names? I'm using vanilla kernel 2.6.1 and autofs tools 4.0.0 as they come on Mandrake Cooker. -- robin _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 14 11:41:51 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0EJfphP010700 for ; Wed, 14 Jan 2004 11:41:51 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0EJXAvC030776; Wed, 14 Jan 2004 11:33:32 -0800 Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0EJWNvA030697 for ; Wed, 14 Jan 2004 11:33:04 -0800 Received: from mail.rhythm.com (rh-la-28-101.rhythm.com [24.130.28.101]) by tahoe.cinenet.net (8.12.10/8.12.10) with ESMTP id i0EJWL3a005537 for ; Wed, 14 Jan 2004 11:32:23 -0800 (PST) Received: from mailhost.rhythm.com (gw-dmz.rhythm.com [24.130.28.100]) by mail.rhythm.com (8.12.9/8.12.5) with ESMTP id i0EJWL6q030429 for ; Wed, 14 Jan 2004 11:32:21 -0800 Received: from rhythm.com (lid2.rhythm.com [10.4.7.102]) by mailhost.rhythm.com (8.12.9/8.12.5) with ESMTP id i0EJWKZ1026944 for ; Wed, 14 Jan 2004 11:32:21 -0800 Message-ID: <40059944.4060901@rhythm.com> Date: Wed, 14 Jan 2004 11:32:20 -0800 From: Greg Bradner User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: autofs@linux.kernel.org References: <4004409C.6040900@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org Subject: [autofs] running out of mount points X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: I have run into a problem of running out of mount points. I have over 600 users and their home dirs are listed in auto.home and they are all stored on the same nfs server. If I list the dirs, automount will create a seperate mount point for each user, and at ~256 mount points, no more home dirs can be mounted. Is there a work around? Here is the auto.master and snip of auto.home auto.master: /home /etc/auto.maps/auto.home vers=3,hard,intr,nosuid,nodev,rw,retrans=4,timeo=15,mountvers=2 auto.home: gregb ntap:/vol/vol0/u/& _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 14 16:26:43 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0F0QhhP016248 for ; Wed, 14 Jan 2004 16:26:43 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0F0N6vC006852; Wed, 14 Jan 2004 16:23:08 -0800 Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DJwsvA005255 for ; Tue, 13 Jan 2004 11:59:52 -0800 Received: from mailrelay01.cac.cpqcorp.net (mailrelay01.cac.cpqcorp.net [16.47.132.152]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 39B6FAC50; Tue, 13 Jan 2004 11:58:49 -0800 (PST) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by mailrelay01.cac.cpqcorp.net (Postfix) with ESMTP id 35EFA1EAE; Tue, 13 Jan 2004 11:58:29 -0800 (PST) Received: by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id i0DJwlV0001078000; Tue, 13 Jan 2004 14:58:47 -0500 (EST) Date: Tue, 13 Jan 2004 14:58:47 -0500 (EST) Message-Id: <200401131958.i0DJwlV0001078000@anw.zk3.dec.com> From: Eric Werme USG To: autofs@linux.kernel.org Subject: Re: [autofs] autofs no_local_binds option (nfs <-> bind mounts) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org X-Mailman-Approved-At: Wed, 14 Jan 2004 16:19:49 -0800 cc: alexander.marx@hp.com cc: hpa@zytor.com X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: hpa@zytor.com wrote: MARX,ALEXANDER (HP-Germany,ex1) wrote: > >> In some scenarios (e.g. HA), the nfs server could switch from local to >> remote, therefore having local binds is not a desirable scenario, there >> should always be nfs mounts. > >How would you expect this to work? The local bind only happens when >local and destination address are the same, therefore keeping anything >from going across the network no matter how you slice it. > >Changing the DNS name of the NFS server has no effect, since once the >mount has happened the name was already resolved, and it can't be >redirected. > >Changing the IP address runs into the problem that local == remote. The stop-gap cluster system in Tru64 Unix did this. Typically pairs of servers had system names (service names in the jargon) and bound the IP address to a NIC on one server. When the service was relocated manually or on a crash, the IP address was moved to a NIC on the other server. Disks were on a shared SCSI bus, and the file system would also go through a umount/mount cycle. Note that no changes to DNS' database are necessary, just an update to clients' arp tables. For example, we have systems "mailhub1" and "mailhub2". The service name "mailhub" is where Email here winds up. I send mail via SMTP to mailhub, and read it via NFS from mailhub. Normally I don't care which of mailhub1 and mailhub2 handles it. For the most part they're just servers, but sometimes there are reasons to login to one or both of those systems. Several vendors have similar products. Personally, I always hated the weird problems we'd get into on loopback mounts, like the client deciding to flush out some pages because memory was low. The server, being the same system, didn't have any more memory.... One of the benefits of the loopback mounts was that unmounting wasn't a problem as long as local access was via NFS. Kill the NFS server, accesses would end, unmount. Clients would retransmit a couple times, but things would resume quickly. -Ric Werme -- Eric (Ric) Werme | werme@zk3.dec.com Hewlett-Packard Co. | http://werme.8m.net/ _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 14 16:26:45 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0F0QjhP016247 for ; Wed, 14 Jan 2004 16:26:45 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0F0JrvC005299; Wed, 14 Jan 2004 16:20:44 -0800 Received: from www.hockin.org ([66.35.79.110]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0CModvA012060 for ; Mon, 12 Jan 2004 14:51:31 -0800 Received: (from thockin@localhost) by www.hockin.org (8.11.6/8.11.6) id i0CMoN921779; Mon, 12 Jan 2004 14:50:23 -0800 Date: Mon, 12 Jan 2004 14:50:23 -0800 From: Tim Hockin To: Mike Waychison Subject: Re: [autofs] [RFC] Towards a Modern Autofs Message-ID: <20040112225023.GA21399@hockin.org> References: <40029C19.409@sun.com> <4002CAB6.3000800@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4002CAB6.3000800@sun.com> User-Agent: Mutt/1.4.1i X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org X-Mailman-Approved-At: Wed, 14 Jan 2004 16:19:49 -0800 cc: autofs mailing list cc: Kernel Mailing List cc: raven@themaw.net X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Mon, Jan 12, 2004 at 11:26:30AM -0500, Mike Waychison wrote: > /usr /man1 server:/usr/man1 \ > /man2 server:/usr/man2 > > is the same as the two distinct entries: > > /usr/man1 server:/usr/man1 > /usr/man2 server:/usr/man2 > > Now that I think about it, the discussion in my proposal paper about > multimounts with no root offsets probably isn't required. The latter requires /usr/man1 and /usr/man2 to exist. The former only requires /usr to exist, right? _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 14 16:30:49 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0F0UnhP016264 for ; Wed, 14 Jan 2004 16:30:49 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0F0OPvC007209; Wed, 14 Jan 2004 16:24:27 -0800 Received: from zcamail05.zca.compaq.com (zcamail05.zca.compaq.com [161.114.32.105]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0DKgKvA015927 for ; Tue, 13 Jan 2004 12:43:05 -0800 Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail05.zca.compaq.com (Postfix) with ESMTP id D28DAE1EA; Tue, 13 Jan 2004 12:42:14 -0800 (PST) Received: from anw.zk3.dec.com (alpha.zk3.dec.com [16.140.128.4]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id C12A6855; Tue, 13 Jan 2004 15:42:13 -0500 (EST) Received: from localhost by anw.zk3.dec.com (8.11.1/1.1.22.2/08Sep98-0251PM) id i0DKgDR0001085265; Tue, 13 Jan 2004 15:42:13 -0500 (EST) From: Eric Werme USG Message-Id: <200401132042.i0DKgDR0001085265@anw.zk3.dec.com> To: "H. Peter Anvin" Subject: Re: [autofs] autofs no_local_binds option (nfs <-> bind mounts) In-reply-to: Your message of "Tue, 13 Jan 2004 12:03:54 PST." <40044F2A.9080305@zytor.com> Date: Tue, 13 Jan 2004 15:42:13 -0500 X-Mts: smtp X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org X-Mailman-Approved-At: Wed, 14 Jan 2004 16:19:49 -0800 cc: autofs@linux.kernel.org cc: alexander.marx@hp.com X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Eric Werme USG wrote: > > The stop-gap cluster system in Tru64 Unix did this. Typically pairs > of servers had system names (service names in the jargon) and bound > the IP address to a NIC on one server. When the service was relocated > manually or on a crash, the IP address was moved to a NIC on the other > server. Disks were on a shared SCSI bus, and the file system would also > go through a umount/mount cycle. Note that no changes to DNS' database > are necessary, just an update to clients' arp tables. > > For example, we have systems "mailhub1" and "mailhub2". The service name > "mailhub" is where Email here winds up. I send mail via SMTP to mailhub, and > read it via NFS from mailhub. Normally I don't care which of mailhub1 > and mailhub2 handles it. For the most part they're just servers, but > sometimes there are reasons to login to one or both of those systems. However, this doesn't address the issue of the client being *the same system*, in which case you can't just move the IP address away from it, since local == remote; you can no longer send packets to the server and get a response back. You can do it if you can get the client and the server sides to bind to *different* IP addresses, in which case the current autofs behaviour will correctly see them as being separate and mount NFS. *the same system* as the server? I don't know much about Linux internals, one reason I don't post here often, but I try to offer insight to other systems. Tru64 Unix has a lot of BSD heritage. If mailhub1 is providing the mailhub service and mounts something from mailhub, messages sent to mailhub will be caught in the routing code and directed to the loopback "NIC" lo0. If the mailhub service (IP address) is relocated to mailhub2, the routing code will see that no NIC on mailhub1 has the mailhub IP address and will give the message to a NIC that can reach it. (And ARP resolves the MAC address and it all runs like a normal remote mount.) Ah. Back to automount/autofs. I made many fixes to Sun's old automount, one of them was to rummage among all the NICs looking to see if the FS was really a local mount and provide the appropriate symlink. The cluster folks didn't realize I also checked the alias addresses too, so I had to add an option to disable that to force a real NFS call. You mention "you can't just move the IP address away," is that something Linux doesn't support yet? No problem on Tru64. A NIC has one permanent address and a bunch of aliases that can come and go at the whims of the admins or load balancing software: # ifconfig ee0 ee0: flags=200c63 inet 16.xx.yy.213 netmask ffffff00 broadcast 16.xx.yy.255 ipmtu 1500 inet 16.xx.yy.192 netmask ffffff00 broadcast 16.xx.yy.255 ipmtu 1500 # ifconfig ee0 -alias 16.xx.yy.192 # ifconfig ee0 ee0: flags=c63 inet 16.xx.yy.213 netmask ffffff00 broadcast 16.xx.yy.255 ipmtu 1500 -Ric Werme -- Eric (Ric) Werme | werme@zk3.dec.com Hewlett-Packard Co. | http://werme.8m.net/ _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Wed Jan 14 16:32:11 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0F0WBhP016272 for ; Wed, 14 Jan 2004 16:32:11 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0F0PevC007507; Wed, 14 Jan 2004 16:25:44 -0800 Received: from neon-gw.transmeta.com (neon-gw-l3.transmeta.com [63.209.4.196]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0F0LkvA006489 for ; Wed, 14 Jan 2004 16:21:46 -0800 Received: (from root@localhost) by neon-gw.transmeta.com (8.9.3/8.9.3) id QAA21086; Wed, 14 Jan 2004 16:21:22 -0800 Received: from mailhost.transmeta.com(10.1.1.15) by neon-gw.transmeta.com via smap (V2.1) id xma021076; Wed, 14 Jan 04 16:20:52 -0800 Received: from cesium.transmeta.com (cesium.transmeta.com [10.10.25.49]) i0F0Kuf07214; Wed, 14 Jan 2004 16:20:56 -0800 (PST) Received: from zytor.com (IDENT:xNbnYnNEXjCekmjIwGlLvx1OVuR4+DTr@localhost.localdomain [127.0.0.1]) by cesium.transmeta.com (8.11.6/8.11.6) with ESMTP id i0F0KuV27748; Wed, 14 Jan 2004 16:20:56 -0800 Message-ID: <4005DCE8.8000902@zytor.com> Date: Wed, 14 Jan 2004 16:20:56 -0800 From: "H. Peter Anvin" Organization: Zytor Communications User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031030 X-Accept-Language: en, sv MIME-Version: 1.0 To: autofs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org Subject: [autofs] Read this if you have multiple email addresses X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: People, If you have more than one address by which you want to post on this list, please subscribe them all to the list and mark them as "no mail." Otherwise your messages will be held for moderation, which is highly annoying for everyone. -hpa _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Sat Jan 17 16:16:26 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0I0GPgu019119 for ; Sat, 17 Jan 2004 16:16:26 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0HNXusu010198; Sat, 17 Jan 2004 15:44:33 -0800 Received: from ptb-relay01.plus.net (ptb-relay01.plus.net [212.159.14.212]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0HNWEss009974 for ; Sat, 17 Jan 2004 15:33:24 -0800 Received: from [212.159.72.97] (helo=scooby.etta.local) by ptb-relay01.plus.net with esmtp (Exim) id 1Ahzv0-000KQU-R0 for autofs@linux.kernel.org; Sat, 17 Jan 2004 23:31:54 +0000 From: Dylan To: autofs@linux.kernel.org Date: Sat, 17 Jan 2004 23:31:52 +0000 User-Agent: KMail/1.5.4 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200401172331.52858.autofs@dylan.me.uk> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org Subject: [autofs] Installing autofs4.1 X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hello All, After reading the posts on this list, I have d/loaded the autofs4.1 files from ftp.kernel.org/pub/linux/daemons/autofs/v4 (all of them, even though I figure I don't need them all...) My queries are: A: What is the difference between autofs4-4.1.0-1.src.rpm and autofs4-4.1.0-2.src.rpm? I notice -2- contains autofs-4.1.0-lookup.patch which -1- does not - is this additional, or already integrated in -1-. Also, -2- depends on hesiod-devel and openldap-devel which -1- does not. Is this related to the patch? B: I have no need for ldap functionality. I tried compiling from the tar with --without-ldap and --with-ldap=no as options to configure but the make still abends complaining about no ldap headers. Can I eliminate the ldap requirements, and if so how? TIA Dylan -- Sweet moderation Heart of this nation Desert us not We are between the wars - Billy Bragg _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Sun Jan 18 05:02:22 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0ID2LxM021560 for ; Sun, 18 Jan 2004 05:02:22 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0ICRhss014705; Sun, 18 Jan 2004 04:28:03 -0800 Received: from ctron-dnm.enterasys.com (firewall-user@ctron-dnm.enterasys.com [12.25.1.120]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0I49wss006283 for ; Sat, 17 Jan 2004 20:11:16 -0800 Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id XAA22854 for ; Sat, 17 Jan 2004 23:11:14 -0500 (EST) Received: from nhrocavg2(134.141.79.124) by ctron-dnm.enterasys.com via smap (4.1) id xma022848; Sat, 17 Jan 04 23:11:11 -0500 Received: from NHROCCNC2.ets.enterasys.com ([134.141.79.124]) by 134.141.79.124 with InterScan Messaging Security Suite; Sat, 17 Jan 2004 23:09:42 -0500 Received: from source ([134.141.79.122]) by host ([134.141.79.124]) with SMTP; Sat, 17 Jan 2004 23:09:42 -0500 Received: from maandmbx1 ([134.141.93.30]) by NHROCCNC2.ets.enterasys.com with Microsoft SMTPSVC(5.0.2195.6713); Sat, 17 Jan 2004 23:09:42 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3DD78.E5D1DB5F" X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 Date: Sat, 17 Jan 2004 23:09:41 -0500 Message-ID: X-MS-Has-Attach: yes Thread-Topic: direct map limitations Thread-Index: AcPdeOIHJ0c88htGTc+QXaX+lVPkig== From: "Bahi, David" To: X-OriginalArrivalTime: 18 Jan 2004 04:09:42.0507 (UTC) FILETIME=[E63CE3B0:01C3DD78] X-pstn-version: pmps:sps_win32_1_1_0c1 pase:2.0 X-pstn-levels: (C:80.8653 M:99.5542 P:95.9108 R:95.9108 S:38.8291 ) X-pstn-settings: 4 (0.2500:0.7500) p:13 m:13 C:14 r:13 X-pstn-addresses: from forward (org good) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60 X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on hera.kernel.org X-Mailman-Approved-At: Sun, 18 Jan 2004 03:44:04 -0800 Subject: [autofs] direct map limitations X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: This is a multi-part message in MIME format. ------_=_NextPart_001_01C3DD78.E5D1DB5F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable is it not possible to use direct mounts on / with /etc/auto.master: /- /etc/auto.direct /etc/auto.direct: /only host:/some/path/of/interest and with a running kernel that has =20 http://kernel.org/pub/linux/daemons/autofs/v4/autofs4-2.4-module-2003120 1.tar.bz2 applied to 2.4.24=20 (messy as it is -=20 cleaner patch attached -=20 please check root.c in particular) and with an rpmbuild --rebuild of http://kernel.org/pub/linux/daemons/autofs/v4/autofs-4.1.0-2.src.rpm on boot/startup of the autofs daemon (alias autofs autofs4 in modules.conf) /var/log/messages: cache_ghost: entry in file:/etc/auto.direct not valid map format, key /only and of course 'ls /only' No such file or directory.... looking at lib/cache.c it seems the logic is inverted so that the daemon must find a /dir/ pattern so the automount daemon can 'watch over' '/dir' when a direct daemon needs to be able to listen over '/' too, no? thanks for any feedback db ps i was going to try this - but figured it would just fail miserably --- lib/cache.c.orig 2004-01-17 21:59:00.000000000 -0500 +++ lib/cache.c 2004-01-17 21:57:31.000000000 -0500 @@ -458,7 +458,7 @@ =20 /* Base path of direct map, each new dir needs to be mounted */ if (!strncmp(gc->root, "/-", 2)) { - slash =3D strchr(gc->key + 1, '/'); + slash =3D strchr(gc->key + 0, '/'); =20 if (*gc->key !=3D '/' || !slash) { return LKP_ERR_FORMAT; ------_=_NextPart_001_01C3DD78.E5D1DB5F Content-Type: application/octet-stream; name="linux-2.4.24-autofs.patch" Content-Transfer-Encoding: base64 Content-Description: linux-2.4.24-autofs.patch Content-Disposition: attachment; filename="linux-2.4.24-autofs.patch" ZGlmZiAtTmF1ciAtLWV4Y2x1ZGUtZnJvbT1leGNsdWRlLWZpbGVzIDIuNC4yNHByZS1hdXRvZnMv ZnMvYXV0b2ZzNC9hdXRvZnNfaS5oIDIuNC4yNHBvc3QtYXV0b2ZzL2ZzL2F1dG9mczQvYXV0b2Zz X2kuaAotLS0gMi40LjI0cHJlLWF1dG9mcy9mcy9hdXRvZnM0L2F1dG9mc19pLmgJMjAwNC0wMS0x NCAxNjoxOTo0NC4wMDAwMDAwMDAgLTA1MDAKKysrIDIuNC4yNHBvc3QtYXV0b2ZzL2ZzL2F1dG9m czQvYXV0b2ZzX2kuaAkyMDA0LTAxLTE3IDA3OjMxOjAwLjAwMDAwMDAwMCAtMDUwMApAQCAtNzMs NiArNzMsNyBAQAogc3RydWN0IGF1dG9mc193YWl0X3F1ZXVlIHsKIAl3YWl0X3F1ZXVlX2hlYWRf dCBxdWV1ZTsKIAlzdHJ1Y3QgYXV0b2ZzX3dhaXRfcXVldWUgKm5leHQ7CisJc3RydWN0IHRhc2tf c3RydWN0ICpvd25lcjsKIAlhdXRvZnNfd3F0X3Qgd2FpdF9xdWV1ZV90b2tlbjsKIAkvKiBXZSB1 c2UgdGhlIGZvbGxvd2luZyB0byBzZWUgd2hhdCB3ZSBhcmUgd2FpdGluZyBmb3IgKi8KIAlpbnQg aGFzaDsKQEAgLTkxLDcgKzkyLDEwIEBACiAJcGlkX3Qgb3pfcGdycDsKIAlpbnQgY2F0YXRvbmlj OwogCWludCB2ZXJzaW9uOworCWludCBzdWJfdmVyc2lvbjsKIAl1bnNpZ25lZCBsb25nIGV4cF90 aW1lb3V0OworCWludCByZWdob3N0X2VuYWJsZWQ7CisJaW50IG5lZWRzX3JlZ2hvc3Q7CiAJc3Ry dWN0IHN1cGVyX2Jsb2NrICpzYjsKIAlzdHJ1Y3QgYXV0b2ZzX3dhaXRfcXVldWUgKnF1ZXVlczsg LyogV2FpdCBxdWV1ZSBwb2ludGVyICovCiB9OwpAQCAtMTIzLDYgKzEyNywxMiBAQAogCQkoaW5m ICE9IE5VTEwgJiYgaW5mLT5mbGFncyAmIEFVVE9GU19JTkZfRVhQSVJJTkcpOwogfQogCitzdGF0 aWMgaW5saW5lIHZvaWQgYXV0b2ZzNF9jb3B5X2F0aW1lKHN0cnVjdCBmaWxlICpzcmMsIHN0cnVj dCBmaWxlICpkc3QpCit7CisJZHN0LT5mX2RlbnRyeS0+ZF9pbm9kZS0+aV9hdGltZSA9IHNyYy0+ Zl9kZW50cnktPmRfaW5vZGUtPmlfYXRpbWU7CisJcmV0dXJuOworfQorCiBzdHJ1Y3QgaW5vZGUg KmF1dG9mczRfZ2V0X2lub2RlKHN0cnVjdCBzdXBlcl9ibG9jayAqLCBzdHJ1Y3QgYXV0b2ZzX2lu Zm8gKik7CiBzdHJ1Y3QgYXV0b2ZzX2luZm8gKmF1dG9mczRfaW5pdF9pbmYoc3RydWN0IGF1dG9m c19zYl9pbmZvICosIG1vZGVfdCBtb2RlKTsKIHZvaWQgYXV0b2ZzNF9mcmVlX2lubyhzdHJ1Y3Qg YXV0b2ZzX2luZm8gKik7CkBAIC0xNTUsNiArMTY1LDU2IEBACiAJTkZZX0VYUElSRQogfTsKIAot aW50IGF1dG9mczRfd2FpdChzdHJ1Y3QgYXV0b2ZzX3NiX2luZm8gKixzdHJ1Y3QgcXN0ciAqLCBl bnVtIGF1dG9mc19ub3RpZnkpOworaW50IGF1dG9mczRfd2FpdChzdHJ1Y3QgYXV0b2ZzX3NiX2lu Zm8gKixzdHJ1Y3QgZGVudHJ5ICosIGVudW0gYXV0b2ZzX25vdGlmeSk7CiBpbnQgYXV0b2ZzNF93 YWl0X3JlbGVhc2Uoc3RydWN0IGF1dG9mc19zYl9pbmZvICosYXV0b2ZzX3dxdF90LGludCk7CiB2 b2lkIGF1dG9mczRfY2F0YXRvbmljX21vZGUoc3RydWN0IGF1dG9mc19zYl9pbmZvICopOworCisj aWYgIWRlZmluZWQoUkVESEFUX0tFUk5FTCkgfHwgTElOVVhfVkVSU0lPTl9DT0RFIDwgS0VSTkVM X1ZFUlNJT04oMiw0LDE5KQorLyoqCisgKiBsaXN0X2Zvcl9lYWNoX2VudHJ5ICAtICAgICAgIGl0 ZXJhdGUgb3ZlciBsaXN0IG9mIGdpdmVuIHR5cGUKKyAqIEBwb3M6ICAgICAgICB0aGUgdHlwZSAq IHRvIHVzZSBhcyBhIGxvb3AgY291bnRlci4KKyAqIEBoZWFkOiAgICAgICB0aGUgaGVhZCBmb3Ig eW91ciBsaXN0LgorICogQG1lbWJlcjogICAgIHRoZSBuYW1lIG9mIHRoZSBsaXN0X3N0cnVjdCB3 aXRoaW4gdGhlIHN0cnVjdC4KKyAqLworI2RlZmluZSBsaXN0X2Zvcl9lYWNoX2VudHJ5KHBvcywg aGVhZCwgbWVtYmVyKSAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICBmb3IgKHBv cyA9IGxpc3RfZW50cnkoKGhlYWQpLT5uZXh0LCB0eXBlb2YoKnBvcyksIG1lbWJlciksICAgICAg XAorICAgICAgICAgICAgICAgICAgICAgcHJlZmV0Y2gocG9zLT5tZW1iZXIubmV4dCk7ICAgICAg ICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgICZwb3MtPm1lbWJlciAhPSAoaGVhZCk7 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgXAorICAgICAgICAgICAgIHBvcyA9 IGxpc3RfZW50cnkocG9zLT5tZW1iZXIubmV4dCwgdHlwZW9mKCpwb3MpLCBtZW1iZXIpLCAgXAor ICAgICAgICAgICAgICAgICAgICAgcHJlZmV0Y2gocG9zLT5tZW1iZXIubmV4dCkpCisKKyNlbmRp ZgorCitzdGF0aWMgaW5saW5lIGludCBzaW1wbGVfcG9zaXRpdmUoc3RydWN0IGRlbnRyeSAqZGVu dHJ5KQoreworCXJldHVybiBkZW50cnktPmRfaW5vZGUgJiYgIWRfdW5oYXNoZWQoZGVudHJ5KTsK K30KKworc3RhdGljIGlubGluZSBpbnQgc2ltcGxlX2VtcHR5X25vbG9jayhzdHJ1Y3QgZGVudHJ5 ICpkZW50cnkpCit7CisJc3RydWN0IGRlbnRyeSAqY2hpbGQ7CisJaW50IHJldCA9IDA7CisKKwls aXN0X2Zvcl9lYWNoX2VudHJ5KGNoaWxkLCAmZGVudHJ5LT5kX3N1YmRpcnMsIGRfY2hpbGQpCisJ CWlmIChzaW1wbGVfcG9zaXRpdmUoY2hpbGQpKQorCQkJZ290byBvdXQ7CisJcmV0ID0gMTsKK291 dDoKKwlyZXR1cm4gcmV0OworfQorCitzdGF0aWMgaW5saW5lIGludCBzaW1wbGVfZW1wdHkoc3Ry dWN0IGRlbnRyeSAqZGVudHJ5KQoreworCXN0cnVjdCBkZW50cnkgKmNoaWxkOworCWludCByZXQg PSAwOworCisJc3Bpbl9sb2NrKCZkY2FjaGVfbG9jayk7CisJbGlzdF9mb3JfZWFjaF9lbnRyeShj aGlsZCwgJmRlbnRyeS0+ZF9zdWJkaXJzLCBkX2NoaWxkKQorCQlpZiAoc2ltcGxlX3Bvc2l0aXZl KGNoaWxkKSkKKwkJCWdvdG8gb3V0OworCXJldCA9IDE7CitvdXQ6CisJc3Bpbl91bmxvY2soJmRj YWNoZV9sb2NrKTsKKwlyZXR1cm4gcmV0OworfQorCmRpZmYgLU5hdXIgLS1leGNsdWRlLWZyb209 ZXhjbHVkZS1maWxlcyAyLjQuMjRwcmUtYXV0b2ZzL2ZzL2F1dG9mczQvZXhwaXJlLmMgMi40LjI0 cG9zdC1hdXRvZnMvZnMvYXV0b2ZzNC9leHBpcmUuYwotLS0gMi40LjI0cHJlLWF1dG9mcy9mcy9h dXRvZnM0L2V4cGlyZS5jCTIwMDEtMDYtMTEgMjI6MTU6MjcuMDAwMDAwMDAwIC0wNDAwCisrKyAy LjQuMjRwb3N0LWF1dG9mcy9mcy9hdXRvZnM0L2V4cGlyZS5jCTIwMDQtMDEtMTcgMDc6MzE6MDAu MDAwMDAwMDAwIC0wNTAwCkBAIC00LDYgKzQsNyBAQAogICoKICAqICBDb3B5cmlnaHQgMTk5Ny0x OTk4IFRyYW5zbWV0YSBDb3Jwb3JhdGlvbiAtLSBBbGwgUmlnaHRzIFJlc2VydmVkCiAgKiAgQ29w eXJpZ2h0IDE5OTktMjAwMCBKZXJlbXkgRml0emhhcmRpbmdlIDxqZXJlbXlAZ29vcC5vcmc+Cisg KiAgQ29weXJpZ2h0IDIwMDEtMjAwMyBJYW4gS2VudCA8cmF2ZW5AdGhlbWF3Lm5ldD4KICAqCiAg KiBUaGlzIGZpbGUgaXMgcGFydCBvZiB0aGUgTGludXgga2VybmVsIGFuZCBpcyBtYWRlIGF2YWls YWJsZSB1bmRlcgogICogdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5z ZSwgdmVyc2lvbiAyLCBvciBhdCB5b3VyCkBAIC0xMywxMzQgKzE0LDIzOCBAQAogCiAjaW5jbHVk ZSAiYXV0b2ZzX2kuaCIKIAotLyoKLSAqIERldGVybWluZSBpZiBhIHN1YnRyZWUgb2YgdGhlIG5h bWVzcGFjZSBpcyBidXN5LgotICoKLSAqIG1udCBpcyB0aGUgbW91bnQgdHJlZSB1bmRlciB0aGUg YXV0b2ZzIG1vdW50cG9pbnQKLSAqLwotc3RhdGljIGlubGluZSBpbnQgaXNfdmZzbW50X3RyZWVf YnVzeShzdHJ1Y3QgdmZzbW91bnQgKm1udCkKK3N0YXRpYyB1bnNpZ25lZCBsb25nIG5vdzsKKwor LyogQ2hlY2sgaWYgYSBkZW50cnkgY2FuIGJlIGV4cGlyZWQgcmV0dXJuIDEgaWYgaXQgY2FuIGVs c2UgcmV0dXJuIDAgKi8KK3N0YXRpYyBpbmxpbmUgaW50IGF1dG9mczRfY2FuX2V4cGlyZShzdHJ1 Y3QgZGVudHJ5ICpkZW50cnksCisJCQkJCXVuc2lnbmVkIGxvbmcgdGltZW91dCwgaW50IGRvX25v dykKK3sKKwlzdHJ1Y3QgYXV0b2ZzX2luZm8gKmlubyA9IGF1dG9mczRfZGVudHJ5X2lubyhkZW50 cnkpOworCisJLyogZGVudHJ5IGluIHRoZSBwcm9jZXNzIG9mIGJlaW5nIGRlbGV0ZWQgKi8KKwlp ZiAoaW5vID09IE5VTEwpCisJCXJldHVybiAwOworCisJLyogTm8gcG9pbnQgZXhwaXJpbmcgYSBw ZW5kaW5nIG1vdW50ICovCisJaWYgKGRlbnRyeS0+ZF9mbGFncyAmIERDQUNIRV9BVVRPRlNfUEVO RElORykKKwkJcmV0dXJuIDA7CisKKwlpZiAoIWRvX25vdykgeworCQkvKiBUb28geW91bmcgdG8g ZGllICovCisJCWlmICh0aW1lX2FmdGVyKGluby0+bGFzdF91c2VkICsgdGltZW91dCwgbm93KSkK KwkJCXJldHVybiAwOworCQkKKwkJLyogdXBkYXRlIGxhc3RfdXNlZCBoZXJlIDotIAorCQkgICAt IG9idmlvdXNseSBtYWtlcyBzZW5zZSBpZiBpdCBpcyBpbiB1c2Ugbm93CisJCSAgIC0gbGVzcyBv YnZpb3VzbHksIHByZXZlbnRzIHJhcGlkLWZpcmUgZXhwaXJlCisJCSAgICAgYXR0ZW1wdHMgaWYg ZXhwaXJlIGZhaWxzIHRoZSBmaXJzdCB0aW1lICovCisJCWluby0+bGFzdF91c2VkID0gbm93Owor CX0KKworCXJldHVybiAxOworfQorCisvKiBTb3JyeSBJIGNhbid0IHNvbHZlIHRoZSBwcm9ibGVt IHdpdGhvdXQgdXNpbmcgY291bnRzIGVpdGhlciAqLworc3RhdGljIGludCBhdXRvZnM0X21heV91 bW91bnQoc3RydWN0IHZmc21vdW50ICptbnQpCiB7Ci0Jc3RydWN0IHZmc21vdW50ICp0aGlzX3Bh cmVudCA9IG1udDsKIAlzdHJ1Y3QgbGlzdF9oZWFkICpuZXh0OwotCWludCBjb3VudDsKKwlzdHJ1 Y3QgdmZzbW91bnQgKnRoaXNfcGFyZW50ID0gbW50OworCWludCBhY3R1YWxfcmVmczsKKwlpbnQg bWluaW11bV9yZWZzOwogCi0JY291bnQgPSBhdG9taWNfcmVhZCgmbW50LT5tbnRfY291bnQpIC0g MTsKKwlhY3R1YWxfcmVmcyA9IGF0b21pY19yZWFkKCZtbnQtPm1udF9jb3VudCk7CisJbWluaW11 bV9yZWZzID0gMjsKIAorCXNwaW5fbG9jaygmZGNhY2hlX2xvY2spOwogcmVwZWF0OgogCW5leHQg PSB0aGlzX3BhcmVudC0+bW50X21vdW50cy5uZXh0OwotCURQUklOVEsoKCJpc192ZnNtbnRfdHJl ZV9idXN5OiBtbnQ9JXAsIHRoaXNfcGFyZW50PSVwLCBuZXh0PSVwXG4iLAotCQkgbW50LCB0aGlz X3BhcmVudCwgbmV4dCkpOwogcmVzdW1lOgotCWZvciggOyBuZXh0ICE9ICZ0aGlzX3BhcmVudC0+ bW50X21vdW50czsgbmV4dCA9IG5leHQtPm5leHQpIHsKLQkJc3RydWN0IHZmc21vdW50ICpwID0g bGlzdF9lbnRyeShuZXh0LCBzdHJ1Y3QgdmZzbW91bnQsCi0JCQkJCQltbnRfY2hpbGQpOwotCi0J CS8qIC0xIGZvciBzdHJ1Y3QgdmZzX21vdW50J3Mgbm9ybWFsIGNvdW50LCAKLQkJICAgLTEgdG8g Y29tcGVuc2F0ZSBmb3IgY2hpbGQncyByZWZlcmVuY2UgdG8gcGFyZW50ICovCi0JCWNvdW50ICs9 IGF0b21pY19yZWFkKCZwLT5tbnRfY291bnQpIC0gMSAtIDE7CisJd2hpbGUgKG5leHQgIT0gJnRo aXNfcGFyZW50LT5tbnRfbW91bnRzKSB7CisJCXN0cnVjdCB2ZnNtb3VudCAqcCA9IGxpc3RfZW50 cnkobmV4dCwgc3RydWN0IHZmc21vdW50LCBtbnRfY2hpbGQpOworCisJCW5leHQgPSBuZXh0LT5u ZXh0OwogCi0JCURQUklOVEsoKCJpc192ZnNtbnRfdHJlZV9idXN5OiBwPSVwLCBjb3VudCBub3cg JWRcbiIsCi0JCQkgcCwgY291bnQpKTsKKwkJYWN0dWFsX3JlZnMgKz0gYXRvbWljX3JlYWQoJnAt Pm1udF9jb3VudCk7CisJCW1pbmltdW1fcmVmcyArPSAyOwogCiAJCWlmICghbGlzdF9lbXB0eSgm cC0+bW50X21vdW50cykpIHsKIAkJCXRoaXNfcGFyZW50ID0gcDsKIAkJCWdvdG8gcmVwZWF0Owog CQl9Ci0JCS8qIHJvb3QgaXMgYnVzeSBpZiBhbnkgbGVhZiBpcyBidXN5ICovCi0JCWlmIChhdG9t aWNfcmVhZCgmcC0+bW50X2NvdW50KSA+IDEpCi0JCQlyZXR1cm4gMTsKIAl9CiAKLQkvKiBBbGwg ZG9uZSBhdCB0aGlzIGxldmVsIC4uLiBhc2NlbmQgYW5kIHJlc3VtZSB0aGUgc2VhcmNoLiAqLwog CWlmICh0aGlzX3BhcmVudCAhPSBtbnQpIHsKLQkJbmV4dCA9IHRoaXNfcGFyZW50LT5tbnRfY2hp bGQubmV4dDsgCisJCW5leHQgPSB0aGlzX3BhcmVudC0+bW50X2NoaWxkLm5leHQ7CiAJCXRoaXNf cGFyZW50ID0gdGhpc19wYXJlbnQtPm1udF9wYXJlbnQ7CiAJCWdvdG8gcmVzdW1lOwogCX0KKwlz cGluX3VubG9jaygmZGNhY2hlX2xvY2spOworCisJRFBSSU5USygoImF1dG9mczRfbWF5X3Vtb3Vu dDogZG9uZSBhY3R1YWwgPSAlZCwgbWluaW11bSA9ICVkXG4iLAorCQkgYWN0dWFsX3JlZnMsIG1p bmltdW1fcmVmcykpOwogCi0JRFBSSU5USygoImlzX3Zmc21udF90cmVlX2J1c3k6IGNvdW50PSVk XG4iLCBjb3VudCkpOwotCXJldHVybiBjb3VudCAhPSAwOyAvKiByZW1haW5pbmcgdXNlcnM/ICov CisJcmV0dXJuIGFjdHVhbF9yZWZzID4gbWluaW11bV9yZWZzOwogfQogCi0vKiBUcmF2ZXJzZSBh IGRlbnRyeSdzIGxpc3Qgb2YgdmZzbW91bnRzIGFuZCByZXR1cm4gdGhlIG51bWJlciBvZgotICAg bm9uLWJ1c3kgbW91bnRzICovCi1zdGF0aWMgaW50IGNoZWNrX3Zmc21udChzdHJ1Y3QgdmZzbW91 bnQgKm1udCwgc3RydWN0IGRlbnRyeSAqZGVudHJ5KQorLyogQ2hlY2sgYSBtb3VudCBwb2ludCBm b3IgYnVzeW5lc3MgcmV0dXJuIDEgaWYgbm90IGJ1c3ksIG90aGVyd2lzZSAqLworc3RhdGljIGlu dCBhdXRvZnM0X2NoZWNrX21vdW50KHN0cnVjdCB2ZnNtb3VudCAqbW50LCBzdHJ1Y3QgZGVudHJ5 ICpkZW50cnkpCiB7Ci0JaW50IHJldCA9IGRlbnRyeS0+ZF9tb3VudGVkOwotCXN0cnVjdCB2ZnNt b3VudCAqdmZzID0gbG9va3VwX21udChtbnQsIGRlbnRyeSk7CisJaW50IHN0YXR1cyA9IDA7CiAK LQlpZiAodmZzICYmIGlzX3Zmc21udF90cmVlX2J1c3kodmZzKSkKLQkJcmV0LS07Ci0JRFBSSU5U SygoImNoZWNrX3Zmc21udDogcmV0PSVkXG4iLCByZXQpKTsKLQlyZXR1cm4gcmV0OworCURQUklO VEsoKCJhdXRvZnM0X2NoZWNrX21vdW50OiBkZW50cnkgJXAgJS4qc1xuIiwKKwkJIGRlbnRyeSwg KGludClkZW50cnktPmRfbmFtZS5sZW4sIGRlbnRyeS0+ZF9uYW1lLm5hbWUpKTsKKworCW1udGdl dChtbnQpOworCWRnZXQoZGVudHJ5KTsKKworCWlmICghZm9sbG93X2Rvd24oJm1udCwgJmRlbnRy eSkpCisJCWdvdG8gZG9uZTsKKworCXdoaWxlIChkX21vdW50cG9pbnQoZGVudHJ5KSAmJiBmb2xs b3dfZG93bigmbW50LCAmZGVudHJ5KSkKKwkJOworCisJLyogVGhpcyBpcyBhbiBhdXRvZnMgc3Vi bW91bnQsIHdlIGNhbid0IGV4cGlyZSBpdCAqLworCWlmIChpc19hdXRvZnM0X2RlbnRyeShkZW50 cnkpKQorCQlnb3RvIGRvbmU7CisJCisJLyogVGhlIGJpZyBxdWVzdGlvbiAqLworCWlmIChhdXRv ZnM0X21heV91bW91bnQobW50KSA9PSAwKQorCQlzdGF0dXMgPSAxOworZG9uZToKKwlEUFJJTlRL KCgiYXV0b2ZzNF9jaGVja19tb3VudDogcmV0dXJuaW5nID0gJWRcbiIsIHN0YXR1cykpOworCW1u dHB1dChtbnQpOworCWRwdXQoZGVudHJ5KTsKKwlyZXR1cm4gc3RhdHVzOwogfQogCi0vKiBDaGVj ayBkZW50cnkgdHJlZSBmb3IgYnVzeW5lc3MuICBJZiBhIGRlbnRyeSBhcHBlYXJzIHRvIGJlIGJ1 c3kKLSAgIGJlY2F1c2UgaXQgaXMgYSBtb3VudHBvaW50LCBjaGVjayB0byBzZWUgaWYgdGhlIG1v dW50ZWQKLSAgIGZpbGVzeXN0ZW0gaXMgYnVzeS4gKi8KLXN0YXRpYyBpbnQgaXNfdHJlZV9idXN5 KHN0cnVjdCB2ZnNtb3VudCAqdG9wbW50LCBzdHJ1Y3QgZGVudHJ5ICp0b3ApCisvKiBDaGVjayBh IGRpcmVjdG9yeSB0cmVlIG9mIG1vdW50IHBvaW50cyBmb3IgYnVzeW5lc3MKKyAqIFRoZSB0cmVl IGlzIG5vdCBidXN5IGlmZiBubyBtb3VudHBvaW50cyBhcmUgYnVzeSAKKyAqIFJldHVybiAxIGlm IHRoZSB0cmVlIGlzIGJ1c3kgb3IgMCBvdGhlcndpc2UKKyAqLworc3RhdGljIGludCBhdXRvZnM0 X2NoZWNrX3RyZWUoc3RydWN0IHZmc21vdW50ICptbnQsCisJICAgICAgIAkJICAgICAgc3RydWN0 IGRlbnRyeSAqdG9wLAorCQkJICAgICAgdW5zaWduZWQgbG9uZyB0aW1lb3V0LAorCQkJICAgICAg aW50IGRvX25vdykKIHsKLQlzdHJ1Y3QgZGVudHJ5ICp0aGlzX3BhcmVudDsKKwlzdHJ1Y3QgZGVu dHJ5ICp0aGlzX3BhcmVudCA9IHRvcDsKIAlzdHJ1Y3QgbGlzdF9oZWFkICpuZXh0OwotCWludCBj b3VudDsKIAotCWNvdW50ID0gYXRvbWljX3JlYWQoJnRvcC0+ZF9jb3VudCk7Ci0JCi0JRFBSSU5U SygoImlzX3RyZWVfYnVzeTogdG9wPSVwIGluaXRpYWwgY291bnQ9JWRcbiIsIAotCQkgdG9wLCBj b3VudCkpOwotCXRoaXNfcGFyZW50ID0gdG9wOwotCi0JaWYgKGlzX2F1dG9mczRfZGVudHJ5KHRv cCkpIHsKLQkJY291bnQtLTsKLQkJRFBSSU5USygoImlzX3RyZWVfYnVzeTogYXV0b2ZzOyBjb3Vu dD0lZFxuIiwgY291bnQpKTsKLQl9CisJRFBSSU5USygoImF1dG9mczRfY2hlY2tfdHJlZTogcGFy ZW50ICVwICUuKnNcbiIsCisJCSB0b3AsIChpbnQpdG9wLT5kX25hbWUubGVuLCB0b3AtPmRfbmFt ZS5uYW1lKSk7CiAKLQlpZiAoZF9tb3VudHBvaW50KHRvcCkpCi0JCWNvdW50IC09IGNoZWNrX3Zm c21udCh0b3BtbnQsIHRvcCk7CisJLyogTmVnYXRpdmUgZGVudHJ5IC0gZ2l2ZSB1cCAqLworCWlm ICghc2ltcGxlX3Bvc2l0aXZlKHRvcCkpCisJCXJldHVybiAwOworCisJLyogVGltZW91dCBvZiBh IHRyZWUgbW91bnQgaXMgZGV0ZXJtaW5lZCBieSBpdHMgdG9wIGRlbnRyeSAqLworCWlmICghYXV0 b2ZzNF9jYW5fZXhwaXJlKHRvcCwgdGltZW91dCwgZG9fbm93KSkKKwkJcmV0dXJuIDA7CiAKLSBy ZXBlYXQ6CisJc3Bpbl9sb2NrKCZkY2FjaGVfbG9jayk7CityZXBlYXQ6CiAJbmV4dCA9IHRoaXNf cGFyZW50LT5kX3N1YmRpcnMubmV4dDsKLSByZXN1bWU6CityZXN1bWU6CiAJd2hpbGUgKG5leHQg IT0gJnRoaXNfcGFyZW50LT5kX3N1YmRpcnMpIHsKLQkJaW50IGFkaiA9IDA7Ci0JCXN0cnVjdCBk ZW50cnkgKmRlbnRyeSA9IGxpc3RfZW50cnkobmV4dCwgc3RydWN0IGRlbnRyeSwKLQkJCQkJCSAg IGRfY2hpbGQpOworCQlzdHJ1Y3QgZGVudHJ5ICpkZW50cnkgPSBsaXN0X2VudHJ5KG5leHQsIHN0 cnVjdCBkZW50cnksIGRfY2hpbGQpOworCisJCS8qIE5lZ2F0aXZlIGRlbnRyeSAtIGdpdmUgdXAg Ki8KKwkJaWYgKCFzaW1wbGVfcG9zaXRpdmUoZGVudHJ5KSkgeworCQkJbmV4dCA9IG5leHQtPm5l eHQ7CisJCQljb250aW51ZTsKKwkJfQorCisJCURQUklOVEsoKCJhdXRvZnM0X2NoZWNrX3RyZWU6 IGRlbnRyeSAlcCAlLipzXG4iLAorCQkJIGRlbnRyeSwgKGludClkZW50cnktPmRfbmFtZS5sZW4s IGRlbnRyeS0+ZF9uYW1lLm5hbWUpKTsKKworCQlpZiAoIWxpc3RfZW1wdHkoJmRlbnRyeS0+ZF9z dWJkaXJzKSkgeworCQkJdGhpc19wYXJlbnQgPSBkZW50cnk7CisJCQlnb3RvIHJlcGVhdDsKKwkJ fQorCisJCWRlbnRyeSA9IGRnZXQoZGVudHJ5KTsKKwkJc3Bpbl91bmxvY2soJmRjYWNoZV9sb2Nr KTsKKworCQlpZiAoZF9tb3VudHBvaW50KGRlbnRyeSkpIHsKKwkJCS8qIEZpcnN0IGJ1c3kgPT4g dHJlZSBidXN5ICovCisJCQlpZiAoIWF1dG9mczRfY2hlY2tfbW91bnQobW50LCBkZW50cnkpKSB7 CisJCQkJZHB1dChkZW50cnkpOworCQkJCXJldHVybiAwOworCQkJfQorCQl9CisKKwkJZHB1dChk ZW50cnkpOworCQlzcGluX2xvY2soJmRjYWNoZV9sb2NrKTsKIAkJbmV4dCA9IG5leHQtPm5leHQ7 CisJfQorCisJaWYgKHRoaXNfcGFyZW50ICE9IHRvcCkgeworCQluZXh0ID0gdGhpc19wYXJlbnQt PmRfY2hpbGQubmV4dDsKKwkJdGhpc19wYXJlbnQgPSB0aGlzX3BhcmVudC0+ZF9wYXJlbnQ7CisJ CWdvdG8gcmVzdW1lOworCX0KKwlzcGluX3VubG9jaygmZGNhY2hlX2xvY2spOworCisJcmV0dXJu IDE7Cit9CisKK3N0cnVjdCBkZW50cnkgKmF1dG9mczRfY2hlY2tfbGVhdmVzKHN0cnVjdCB2ZnNt b3VudCAqbW50LAorCQkJCSAgICBzdHJ1Y3QgZGVudHJ5ICpwYXJlbnQsCisJCQkJICAgIHVuc2ln bmVkIGxvbmcgdGltZW91dCwKKwkJCQkgICAgaW50IGRvX25vdykKK3sKKwlzdHJ1Y3QgZGVudHJ5 ICp0aGlzX3BhcmVudCA9IHBhcmVudDsKKwlzdHJ1Y3QgbGlzdF9oZWFkICpuZXh0OwogCi0JCWNv dW50ICs9IGF0b21pY19yZWFkKCZkZW50cnktPmRfY291bnQpIC0gMTsKKwlEUFJJTlRLKCgiYXV0 b2ZzNF9jaGVja19sZWF2ZXM6IHBhcmVudCAlcCAlLipzXG4iLAorCQkgcGFyZW50LCAoaW50KXBh cmVudC0+ZF9uYW1lLmxlbiwgcGFyZW50LT5kX25hbWUubmFtZSkpOwogCi0JCWlmIChkX21vdW50 cG9pbnQoZGVudHJ5KSkKLQkJCWFkaiArPSBjaGVja192ZnNtbnQodG9wbW50LCBkZW50cnkpOwor CXNwaW5fbG9jaygmZGNhY2hlX2xvY2spOworcmVwZWF0OgorCW5leHQgPSB0aGlzX3BhcmVudC0+ ZF9zdWJkaXJzLm5leHQ7CityZXN1bWU6CisJd2hpbGUgKG5leHQgIT0gJnRoaXNfcGFyZW50LT5k X3N1YmRpcnMpIHsKKwkJc3RydWN0IGRlbnRyeSAqZGVudHJ5ID0gbGlzdF9lbnRyeShuZXh0LCBz dHJ1Y3QgZGVudHJ5LCBkX2NoaWxkKTsKIAotCQlpZiAoaXNfYXV0b2ZzNF9kZW50cnkoZGVudHJ5 KSkgewotCQkJYWRqKys7Ci0JCQlEUFJJTlRLKCgiaXNfdHJlZV9idXN5OiBhdXRvZnM7IGFkaj0l ZFxuIiwKLQkJCQkgYWRqKSk7CisJCS8qIE5lZ2F0aXZlIGRlbnRyeSAtIGdpdmUgdXAgKi8KKwkJ aWYgKCFzaW1wbGVfcG9zaXRpdmUoZGVudHJ5KSkgeworCQkJbmV4dCA9IG5leHQtPm5leHQ7CisJ CQljb250aW51ZTsKIAkJfQogCi0JCWNvdW50IC09IGFkajsKKwkJRFBSSU5USygoImF1dG9mczRf Y2hlY2tfbGVhdmVzOiBkZW50cnkgJXAgJS4qc1xuIiwKKwkJCSBkZW50cnksIChpbnQpZGVudHJ5 LT5kX25hbWUubGVuLCBkZW50cnktPmRfbmFtZS5uYW1lKSk7CiAKIAkJaWYgKCFsaXN0X2VtcHR5 KCZkZW50cnktPmRfc3ViZGlycykpIHsKIAkJCXRoaXNfcGFyZW50ID0gZGVudHJ5OwogCQkJZ290 byByZXBlYXQ7CiAJCX0KIAotCQlpZiAoYXRvbWljX3JlYWQoJmRlbnRyeS0+ZF9jb3VudCkgIT0g YWRqKSB7Ci0JCQlEUFJJTlRLKCgiaXNfdHJlZV9idXN5OiBidXN5IGxlYWYgKGRfY291bnQ9JWQg YWRqPSVkKVxuIiwKLQkJCQkgYXRvbWljX3JlYWQoJmRlbnRyeS0+ZF9jb3VudCksIGFkaikpOwot CQkJcmV0dXJuIDE7CisJCWRlbnRyeSA9IGRnZXQoZGVudHJ5KTsKKwkJc3Bpbl91bmxvY2soJmRj YWNoZV9sb2NrKTsKKworCQlpZiAoZF9tb3VudHBvaW50KGRlbnRyeSkpIHsKKwkJCS8qIENhbiB3 ZSBleHBpcmUgdGhpcyBndXkgKi8KKwkJCWlmICghYXV0b2ZzNF9jYW5fZXhwaXJlKGRlbnRyeSwg dGltZW91dCwgZG9fbm93KSkKKwkJCQlnb3RvIGNvbnQ7CisKKwkJCS8qIENhbiB3ZSB1bW91bnQg dGhpcyBndXkgKi8KKwkJCWlmIChhdXRvZnM0X2NoZWNrX21vdW50KG1udCwgZGVudHJ5KSkKKwkJ CQlyZXR1cm4gZGVudHJ5OwogCQl9Citjb250OgorCQlkcHV0KGRlbnRyeSk7CisJCXNwaW5fbG9j aygmZGNhY2hlX2xvY2spOworCQluZXh0ID0gbmV4dC0+bmV4dDsKIAl9CiAKLQkvKiBBbGwgZG9u ZSBhdCB0aGlzIGxldmVsIC4uLiBhc2NlbmQgYW5kIHJlc3VtZSB0aGUgc2VhcmNoLiAqLwotCWlm ICh0aGlzX3BhcmVudCAhPSB0b3ApIHsKLQkJbmV4dCA9IHRoaXNfcGFyZW50LT5kX2NoaWxkLm5l eHQ7IAorCWlmICh0aGlzX3BhcmVudCAhPSBwYXJlbnQpIHsKKwkJbmV4dCA9IHRoaXNfcGFyZW50 LT5kX2NoaWxkLm5leHQ7CiAJCXRoaXNfcGFyZW50ID0gdGhpc19wYXJlbnQtPmRfcGFyZW50Owog CQlnb3RvIHJlc3VtZTsKIAl9CisJc3Bpbl91bmxvY2soJmRjYWNoZV9sb2NrKTsKIAotCURQUklO VEsoKCJpc190cmVlX2J1c3k6IGNvdW50PSVkXG4iLCBjb3VudCkpOwotCXJldHVybiBjb3VudCAh PSAwOyAvKiByZW1haW5pbmcgdXNlcnM/ICovCisJcmV0dXJuIE5VTEw7CiB9CiAKIC8qCkBAIC0x NTIsNjEgKzI1Nyw4NiBAQAogc3RhdGljIHN0cnVjdCBkZW50cnkgKmF1dG9mczRfZXhwaXJlKHN0 cnVjdCBzdXBlcl9ibG9jayAqc2IsCiAJCQkJICAgICBzdHJ1Y3QgdmZzbW91bnQgKm1udCwKIAkJ CQkgICAgIHN0cnVjdCBhdXRvZnNfc2JfaW5mbyAqc2JpLAotCQkJCSAgICAgaW50IGRvX25vdykK KwkJCQkgICAgIGludCBob3cpCiB7Ci0JdW5zaWduZWQgbG9uZyBub3cgPSBqaWZmaWVzOwogCXVu c2lnbmVkIGxvbmcgdGltZW91dDsKIAlzdHJ1Y3QgZGVudHJ5ICpyb290ID0gc2ItPnNfcm9vdDsK LQlzdHJ1Y3QgbGlzdF9oZWFkICp0bXA7CisJc3RydWN0IGRlbnRyeSAqZXhwaXJlZCA9IE5VTEw7 CisJc3RydWN0IGxpc3RfaGVhZCAqbmV4dDsKKwlpbnQgZG9fbm93ID0gaG93ICYgQVVUT0ZTX0VY UF9JTU1FRElBVEU7CisJaW50IGV4cF9sZWF2ZXMgPSBob3cgJiBBVVRPRlNfRVhQX0xFQVZFUzsK IAogCWlmICghc2JpLT5leHBfdGltZW91dCB8fCAhcm9vdCkKIAkJcmV0dXJuIE5VTEw7CiAKKwlu b3cgPSBqaWZmaWVzOwogCXRpbWVvdXQgPSBzYmktPmV4cF90aW1lb3V0OwogCiAJc3Bpbl9sb2Nr KCZkY2FjaGVfbG9jayk7Ci0JZm9yKHRtcCA9IHJvb3QtPmRfc3ViZGlycy5uZXh0OwotCSAgICB0 bXAgIT0gJnJvb3QtPmRfc3ViZGlyczsgCi0JICAgIHRtcCA9IHRtcC0+bmV4dCkgewotCQlzdHJ1 Y3QgYXV0b2ZzX2luZm8gKmlubzsKLQkJc3RydWN0IGRlbnRyeSAqZGVudHJ5ID0gbGlzdF9lbnRy eSh0bXAsIHN0cnVjdCBkZW50cnksIGRfY2hpbGQpOworCW5leHQgPSByb290LT5kX3N1YmRpcnMu bmV4dDsKIAotCQlpZiAoZGVudHJ5LT5kX2lub2RlID09IE5VTEwpCisJLyogT24gZXhpdCBmcm9t IHRoZSBsb29wIGV4cGlyZSBpcyBzZXQgdG8gYSBkZ290IGRlbnRyeQorCSAqIHRvIGV4cGlyZSBv ciBpdCdzIE5VTEwgKi8KKwl3aGlsZSAobmV4dCAhPSAmcm9vdC0+ZF9zdWJkaXJzKSB7CisJCXN0 cnVjdCBkZW50cnkgKmRlbnRyeSA9IGxpc3RfZW50cnkobmV4dCwgc3RydWN0IGRlbnRyeSwgZF9j aGlsZCk7CisKKwkJLyogTmVnYXRpdmUgZGVudHJ5IC0gZ2l2ZSB1cCAqLworCQlpZiAoIXNpbXBs ZV9wb3NpdGl2ZShkZW50cnkpKSB7CisJCQluZXh0ID0gbmV4dC0+bmV4dDsKIAkJCWNvbnRpbnVl OworCQl9CiAKLQkJaW5vID0gYXV0b2ZzNF9kZW50cnlfaW5vKGRlbnRyeSk7CisJCWRlbnRyeSA9 IGRnZXQoZGVudHJ5KTsKKwkJc3Bpbl91bmxvY2soJmRjYWNoZV9sb2NrKTsKIAotCQlpZiAoaW5v ID09IE5VTEwpIHsKLQkJCS8qIGRlbnRyeSBpbiB0aGUgcHJvY2VzcyBvZiBiZWluZyBkZWxldGVk ICovCi0JCQljb250aW51ZTsKKwkJLyogQ2FzZSAxOiBpbmRpcmVjdCBtb3VudCBvciB0b3AgbGV2 ZWwgZGlyZWN0IG1vdW50ICovCisJCWlmIChkX21vdW50cG9pbnQoZGVudHJ5KSkgeworCQkJRFBS SU5USygoImF1dG9mczRfZXhwaXJlOiBjaGVja2luZyBtb3VudHBvaW50ICVwICUuKnNcbiIsCisJ CQkgZGVudHJ5LCAoaW50KWRlbnRyeS0+ZF9uYW1lLmxlbiwgZGVudHJ5LT5kX25hbWUubmFtZSkp OworCisJCQkvKiBDYW4gd2UgZXhwaXJlIHRoaXMgZ3V5ICovCisJCQlpZiAoIWF1dG9mczRfY2Fu X2V4cGlyZShkZW50cnksIHRpbWVvdXQsIGRvX25vdykpCisJCQkJZ290byBuZXh0OworCisJCQkv KiBDYW4gd2UgdW1vdW50IHRoaXMgZ3V5ICovCisJCQlpZiAoYXV0b2ZzNF9jaGVja19tb3VudCht bnQsIGRlbnRyeSkpIHsKKwkJCQlleHBpcmVkID0gZGVudHJ5OworCQkJCWJyZWFrOworCQkJfQor CQkJZ290byBuZXh0OwogCQl9CiAKLQkJLyogTm8gcG9pbnQgZXhwaXJpbmcgYSBwZW5kaW5nIG1v dW50ICovCi0JCWlmIChkZW50cnktPmRfZmxhZ3MgJiBEQ0FDSEVfQVVUT0ZTX1BFTkRJTkcpCi0J CQljb250aW51ZTsKKwkJaWYgKHNpbXBsZV9lbXB0eShkZW50cnkpKQorCQkJZ290byBuZXh0Owog Ci0JCWlmICghZG9fbm93KSB7Ci0JCQkvKiBUb28geW91bmcgdG8gZGllICovCi0JCQlpZiAodGlt ZV9hZnRlcihpbm8tPmxhc3RfdXNlZCArIHRpbWVvdXQsIG5vdykpCi0JCQkJY29udGludWU7Ci0J CQotCQkJLyogdXBkYXRlIGxhc3RfdXNlZCBoZXJlIDotIAotCQkJICAgLSBvYnZpb3VzbHkgbWFr ZXMgc2Vuc2UgaWYgaXQgaXMgaW4gdXNlIG5vdwotCQkJICAgLSBsZXNzIG9idmlvdXNseSwgcHJl dmVudHMgcmFwaWQtZmlyZSBleHBpcmUKLQkJCSAgICAgYXR0ZW1wdHMgaWYgZXhwaXJlIGZhaWxz IHRoZSBmaXJzdCB0aW1lICovCi0JCQlpbm8tPmxhc3RfdXNlZCA9IG5vdzsKKwkJLyogQ2FzZSAy OiB0cmVlIG1vdW50LCBleHBpcmUgaWZmIGVudGlyZSB0cmVlIGlzIG5vdCBidXN5ICovCisJCWlm ICghZXhwX2xlYXZlcykgeworCQkJaWYgKGF1dG9mczRfY2hlY2tfdHJlZShtbnQsIGRlbnRyeSwg dGltZW91dCwgZG9fbm93KSkgeworCQkJCWV4cGlyZWQgPSBkZW50cnk7CisJCQkJYnJlYWs7CisJ CQl9CisJCS8qIENhc2UgMzogZGlyZWN0IG1vdW50LCBleHBpcmUgaW5kaXZpZHVhbCBsZWF2ZXMg Ki8KKwkJfSBlbHNlIHsKKwkJCWV4cGlyZWQgPSBhdXRvZnM0X2NoZWNrX2xlYXZlcyhtbnQsIGRl bnRyeSwgdGltZW91dCwgZG9fbm93KTsKKwkJCWlmIChleHBpcmVkKSB7CisJCQkJZHB1dChkZW50 cnkpOworCQkJCWJyZWFrOworCQkJfQogCQl9Ci0JCWlmICghaXNfdHJlZV9idXN5KG1udCwgZGVu dHJ5KSkgewotCQkJRFBSSU5USygoImF1dG9mc19leHBpcmU6IHJldHVybmluZyAlcCAlLipzXG4i LAotCQkJCSBkZW50cnksIChpbnQpZGVudHJ5LT5kX25hbWUubGVuLCBkZW50cnktPmRfbmFtZS5u YW1lKSk7Ci0JCQkvKiBTdGFydCBmcm9tIGhlcmUgbmV4dCB0aW1lICovCi0JCQlsaXN0X2RlbCgm cm9vdC0+ZF9zdWJkaXJzKTsKLQkJCWxpc3RfYWRkKCZyb290LT5kX3N1YmRpcnMsICZkZW50cnkt PmRfY2hpbGQpOwotCQkJZGdldChkZW50cnkpOwotCQkJc3Bpbl91bmxvY2soJmRjYWNoZV9sb2Nr KTsKK25leHQ6CisJCWRwdXQoZGVudHJ5KTsKKwkJc3Bpbl9sb2NrKCZkY2FjaGVfbG9jayk7CisJ CW5leHQgPSBuZXh0LT5uZXh0OworCX0KIAotCQkJcmV0dXJuIGRlbnRyeTsKLQkJfQorCWlmICgg ZXhwaXJlZCApIHsKKwkJRFBSSU5USygoImF1dG9mczRfZXhwaXJlOiByZXR1cm5pbmcgJXAgJS4q c1xuIiwKKwkJCSBleHBpcmVkLCAoaW50KWV4cGlyZWQtPmRfbmFtZS5sZW4sIGV4cGlyZWQtPmRf bmFtZS5uYW1lKSk7CisJCXNwaW5fbG9jaygmZGNhY2hlX2xvY2spOworCQlsaXN0X2RlbCgmZXhw aXJlZC0+ZF9wYXJlbnQtPmRfc3ViZGlycyk7CisJCWxpc3RfYWRkKCZleHBpcmVkLT5kX3BhcmVu dC0+ZF9zdWJkaXJzLCAmZXhwaXJlZC0+ZF9jaGlsZCk7CisJCXNwaW5fdW5sb2NrKCZkY2FjaGVf bG9jayk7CisJCXJldHVybiBleHBpcmVkOwogCX0KIAlzcGluX3VubG9jaygmZGNhY2hlX2xvY2sp OwogCkBAIC0yNTksMTEgKzM4OSwxMSBAQAogCQkvKiBUaGlzIGlzIHN5bmNocm9ub3VzIGJlY2F1 c2UgaXQgbWFrZXMgdGhlIGRhZW1vbiBhCiAgICAgICAgICAgICAgICAgICAgbGl0dGxlIGVhc2ll ciAqLwogCQlkZV9pbmZvLT5mbGFncyB8PSBBVVRPRlNfSU5GX0VYUElSSU5HOwotCQlyZXQgPSBh dXRvZnM0X3dhaXQoc2JpLCAmZGVudHJ5LT5kX25hbWUsIE5GWV9FWFBJUkUpOworCQlyZXQgPSBh dXRvZnM0X3dhaXQoc2JpLCBkZW50cnksIE5GWV9FWFBJUkUpOwogCQlkZV9pbmZvLT5mbGFncyAm PSB+QVVUT0ZTX0lORl9FWFBJUklORzsKIAkJZHB1dChkZW50cnkpOwogCX0KLQkJCisKIAlyZXR1 cm4gcmV0OwogfQogCmRpZmYgLU5hdXIgLS1leGNsdWRlLWZyb209ZXhjbHVkZS1maWxlcyAyLjQu MjRwcmUtYXV0b2ZzL2ZzL2F1dG9mczQvaW5vZGUuYyAyLjQuMjRwb3N0LWF1dG9mcy9mcy9hdXRv ZnM0L2lub2RlLmMKLS0tIDIuNC4yNHByZS1hdXRvZnMvZnMvYXV0b2ZzNC9pbm9kZS5jCTIwMDIt MDgtMDIgMjA6Mzk6NDUuMDAwMDAwMDAwIC0wNDAwCisrKyAyLjQuMjRwb3N0LWF1dG9mcy9mcy9h dXRvZnM0L2lub2RlLmMJMjAwNC0wMS0xNyAwNzozMTowMC4wMDAwMDAwMDAgLTA1MDAKQEAgLTg3 LDcgKzg3LDcgQEAKIAogCWtmcmVlKHNiaSk7CiAKLQlEUFJJTlRLKCgiYXV0b2ZzOiBzaHV0dGlu ZyBkb3duXG4iKSk7CisJRFBSSU5USygoImF1dG9mczQ6IHNodXR0aW5nIGRvd25cbiIpKTsKIH0K IAogc3RhdGljIGludCBhdXRvZnM0X3N0YXRmcyhzdHJ1Y3Qgc3VwZXJfYmxvY2sgKnNiLCBzdHJ1 Y3Qgc3RhdGZzICpidWYpOwpAQCAtMTgxLDEyICsxODEsMTMgQEAKIAlzdHJ1Y3QgZmlsZSAqIHBp cGU7CiAJaW50IHBpcGVmZDsKIAlzdHJ1Y3QgYXV0b2ZzX3NiX2luZm8gKnNiaTsKKwlzdHJ1Y3Qg YXV0b2ZzX2luZm8gKmlubzsKIAlpbnQgbWlucHJvdG8sIG1heHByb3RvOwogCiAJc2JpID0gKHN0 cnVjdCBhdXRvZnNfc2JfaW5mbyAqKSBrbWFsbG9jKHNpemVvZigqc2JpKSwgR0ZQX0tFUk5FTCk7 CiAJaWYgKCAhc2JpICkKIAkJZ290byBmYWlsX3VubG9jazsKLQlEUFJJTlRLKCgiYXV0b2ZzOiBz dGFydGluZyB1cCwgc2JpID0gJXBcbiIsc2JpKSk7CisJRFBSSU5USygoImF1dG9mczQ6IHN0YXJ0 aW5nIHVwLCBzYmkgPSAlcFxuIixzYmkpKTsKIAogCW1lbXNldChzYmksIDAsIHNpemVvZigqc2Jp KSk7CiAKQEAgLTE5Nyw3ICsxOTgsMTAgQEAKIAlzYmktPm96X3BncnAgPSBjdXJyZW50LT5wZ3Jw OwogCXNiaS0+c2IgPSBzOwogCXNiaS0+dmVyc2lvbiA9IDA7CisJc2JpLT5zdWJfdmVyc2lvbiA9 IDA7CiAJc2JpLT5xdWV1ZXMgPSBOVUxMOworCXNiaS0+cmVnaG9zdF9lbmFibGVkID0gMDsKKwlz YmktPm5lZWRzX3JlZ2hvc3QgPSAwOwogCXMtPnNfYmxvY2tzaXplID0gMTAyNDsKIAlzLT5zX2Js b2Nrc2l6ZV9iaXRzID0gMTA7CiAJcy0+c19tYWdpYyA9IEFVVE9GU19TVVBFUl9NQUdJQzsKQEAg LTIwNiw3ICsyMTAsOSBAQAogCS8qCiAJICogR2V0IHRoZSByb290IGlub2RlIGFuZCBkZW50cnks IGJ1dCBkZWZlciBjaGVja2luZyBmb3IgZXJyb3JzLgogCSAqLwotCXJvb3RfaW5vZGUgPSBhdXRv ZnM0X2dldF9pbm9kZShzLCBhdXRvZnM0X21rcm9vdChzYmkpKTsKKwlpbm8gPSBhdXRvZnM0X21r cm9vdChzYmkpOworCXJvb3RfaW5vZGUgPSBhdXRvZnM0X2dldF9pbm9kZShzLCBpbm8pOworCWtm cmVlKGlubyk7CiAJcm9vdF9pbm9kZS0+aV9vcCA9ICZhdXRvZnM0X3Jvb3RfaW5vZGVfb3BlcmF0 aW9uczsKIAlyb290X2lub2RlLT5pX2ZvcCA9ICZhdXRvZnM0X3Jvb3Rfb3BlcmF0aW9uczsKIAly b290ID0gZF9hbGxvY19yb290KHJvb3RfaW5vZGUpOwpAQCAtMjIwLDE0ICsyMjYsMTQgQEAKIAkJ CSAgJnJvb3RfaW5vZGUtPmlfdWlkLCAmcm9vdF9pbm9kZS0+aV9naWQsCiAJCQkgICZzYmktPm96 X3BncnAsCiAJCQkgICZtaW5wcm90bywgJm1heHByb3RvKSkgewotCQlwcmludGsoImF1dG9mczog Y2FsbGVkIHdpdGggYm9ndXMgb3B0aW9uc1xuIik7CisJCXByaW50aygiYXV0b2ZzNDogY2FsbGVk IHdpdGggYm9ndXMgb3B0aW9uc1xuIik7CiAJCWdvdG8gZmFpbF9kcHV0OwogCX0KIAogCS8qIENv dWxkbid0IHRoaXMgYmUgdGVzdGVkIGVhcmxpZXI/ICovCiAJaWYgKG1heHByb3RvIDwgQVVUT0ZT X01JTl9QUk9UT19WRVJTSU9OIHx8CiAJICAgIG1pbnByb3RvID4gQVVUT0ZTX01BWF9QUk9UT19W RVJTSU9OKSB7Ci0JCXByaW50aygiYXV0b2ZzOiBrZXJuZWwgZG9lcyBub3QgbWF0Y2ggZGFlbW9u IHZlcnNpb24gIgorCQlwcmludGsoImF1dG9mczQ6IGtlcm5lbCBkb2VzIG5vdCBtYXRjaCBkYWVt b24gdmVyc2lvbiAiCiAJCSAgICAgICAiZGFlbW9uICglZCwgJWQpIGtlcm5lbCAoJWQsICVkKVxu IiwKIAkJCW1pbnByb3RvLCBtYXhwcm90bywKIAkJCUFVVE9GU19NSU5fUFJPVE9fVkVSU0lPTiwg QVVUT0ZTX01BWF9QUk9UT19WRVJTSU9OKTsKQEAgLTIzNSwxMiArMjQxLDEzIEBACiAJfQogCiAJ c2JpLT52ZXJzaW9uID0gbWF4cHJvdG8gPiBBVVRPRlNfTUFYX1BST1RPX1ZFUlNJT04gPyBBVVRP RlNfTUFYX1BST1RPX1ZFUlNJT04gOiBtYXhwcm90bzsKKwlzYmktPnN1Yl92ZXJzaW9uID0gIEFV VE9GU19QUk9UT19TVUJWRVJTSU9OOwogCi0JRFBSSU5USygoImF1dG9mczogcGlwZSBmZCA9ICVk LCBwZ3JwID0gJXVcbiIsIHBpcGVmZCwgc2JpLT5vel9wZ3JwKSk7CisJRFBSSU5USygoImF1dG9m czQ6IHBpcGUgZmQgPSAlZCwgcGdycCA9ICV1XG4iLCBwaXBlZmQsIHNiaS0+b3pfcGdycCkpOwog CXBpcGUgPSBmZ2V0KHBpcGVmZCk7CiAJCiAJaWYgKCAhcGlwZSApIHsKLQkJcHJpbnRrKCJhdXRv ZnM6IGNvdWxkIG5vdCBvcGVuIHBpcGUgZmlsZSBkZXNjcmlwdG9yXG4iKTsKKwkJcHJpbnRrKCJh dXRvZnM0OiBjb3VsZCBub3Qgb3BlbiBwaXBlIGZpbGUgZGVzY3JpcHRvclxuIik7CiAJCWdvdG8g ZmFpbF9kcHV0OwogCX0KIAlpZiAoICFwaXBlLT5mX29wIHx8ICFwaXBlLT5mX29wLT53cml0ZSAp CkBAIC0yNTcsNyArMjY0LDcgQEAKIAkgKiBGYWlsdXJlIC4uLiBjbGVhbiB1cC4KIAkgKi8KIGZh aWxfZnB1dDoKLQlwcmludGsoImF1dG9mczogcGlwZSBmaWxlIGRlc2NyaXB0b3IgZG9lcyBub3Qg Y29udGFpbiBwcm9wZXIgb3BzXG4iKTsKKwlwcmludGsoImF1dG9mczQ6IHBpcGUgZmlsZSBkZXNj cmlwdG9yIGRvZXMgbm90IGNvbnRhaW4gcHJvcGVyIG9wc1xuIik7CiAJLyoKIAkgKiBmcHV0KCkg Y2FuIGJsb2NrLCBzbyB3ZSBjbGVhciB0aGUgc3VwZXIgYmxvY2sgZmlyc3QuCiAJICovCkBAIC0y NzAsNyArMjc3LDcgQEAKIAlkcHV0KHJvb3QpOwogCWdvdG8gZmFpbF9mcmVlOwogZmFpbF9pcHV0 OgotCXByaW50aygiYXV0b2ZzOiBnZXQgcm9vdCBkZW50cnkgZmFpbGVkXG4iKTsKKwlwcmludGso ImF1dG9mczQ6IGdldCByb290IGRlbnRyeSBmYWlsZWRcbiIpOwogCS8qCiAJICogaXB1dCgpIGNh biBibG9jaywgc28gd2UgY2xlYXIgdGhlIHN1cGVyIGJsb2NrIGZpcnN0LgogCSAqLwpkaWZmIC1O YXVyIC0tZXhjbHVkZS1mcm9tPWV4Y2x1ZGUtZmlsZXMgMi40LjI0cHJlLWF1dG9mcy9mcy9hdXRv ZnM0L3Jvb3QuYyAyLjQuMjRwb3N0LWF1dG9mcy9mcy9hdXRvZnM0L3Jvb3QuYwotLS0gMi40LjI0 cHJlLWF1dG9mcy9mcy9hdXRvZnM0L3Jvb3QuYwkyMDAzLTA4LTI1IDA3OjQ0OjQzLjAwMDAwMDAw MCAtMDQwMAorKysgMi40LjI0cG9zdC1hdXRvZnMvZnMvYXV0b2ZzNC9yb290LmMJMjAwNC0wMS0x NyAwODoxNDoxNC4wMDAwMDAwMDAgLTA1MDAKQEAgLTQsNiArNCw3IEBACiAgKgogICogIENvcHly aWdodCAxOTk3LTE5OTggVHJhbnNtZXRhIENvcnBvcmF0aW9uIC0tIEFsbCBSaWdodHMgUmVzZXJ2 ZWQKICAqICBDb3B5cmlnaHQgMTk5OS0yMDAwIEplcmVteSBGaXR6aGFyZGluZ2UgPGplcmVteUBn b29wLm9yZz4KKyAqICBDb3B5cmlnaHQgMjAwMS0yMDAzIElhbiBLZW50IDxyYXZlbkB0aGVtYXcu bmV0PgogICoKICAqIFRoaXMgZmlsZSBpcyBwYXJ0IG9mIHRoZSBMaW51eCBrZXJuZWwgYW5kIGlz IG1hZGUgYXZhaWxhYmxlIHVuZGVyCiAgKiB0aGUgdGVybXMgb2YgdGhlIEdOVSBHZW5lcmFsIFB1 YmxpYyBMaWNlbnNlLCB2ZXJzaW9uIDIsIG9yIGF0IHlvdXIKQEAgLTE2LDYgKzE3LDEwIEBACiAj aW5jbHVkZSA8bGludXgvcGFyYW0uaD4KICNpbmNsdWRlIDxsaW51eC9zY2hlZC5oPgogI2luY2x1 ZGUgPGxpbnV4L3NtcF9sb2NrLmg+CisjaW5jbHVkZSA8bGludXgvZmlsZS5oPgorI2luY2x1ZGUg PGxpbnV4L2xpbWl0cy5oPgorI2luY2x1ZGUgPGxpbnV4L2lvYnVmLmg+CisjaW5jbHVkZSA8bGlu dXgvbW9kdWxlLmg+CiAjaW5jbHVkZSAiYXV0b2ZzX2kuaCIKIAogc3RhdGljIHN0cnVjdCBkZW50 cnkgKmF1dG9mczRfZGlyX2xvb2t1cChzdHJ1Y3QgaW5vZGUgKixzdHJ1Y3QgZGVudHJ5ICopOwpA QCAtMjQsMTggKzI5LDI2IEBACiBzdGF0aWMgaW50IGF1dG9mczRfZGlyX3JtZGlyKHN0cnVjdCBp bm9kZSAqLHN0cnVjdCBkZW50cnkgKik7CiBzdGF0aWMgaW50IGF1dG9mczRfZGlyX21rZGlyKHN0 cnVjdCBpbm9kZSAqLHN0cnVjdCBkZW50cnkgKixpbnQpOwogc3RhdGljIGludCBhdXRvZnM0X3Jv b3RfaW9jdGwoc3RydWN0IGlub2RlICosIHN0cnVjdCBmaWxlICosdW5zaWduZWQgaW50LHVuc2ln bmVkIGxvbmcpOworc3RhdGljIGludCBhdXRvZnM0X2Rpcl9vcGVuKHN0cnVjdCBpbm9kZSAqaW5v ZGUsIHN0cnVjdCBmaWxlICpmaWxlKTsKK3N0YXRpYyBpbnQgYXV0b2ZzNF9kaXJfY2xvc2Uoc3Ry dWN0IGlub2RlICppbm9kZSwgc3RydWN0IGZpbGUgKmZpbGUpOworc3RhdGljIGludCBhdXRvZnM0 X2Rpcl9yZWFkZGlyKHN0cnVjdCBmaWxlICogZmlscCwgdm9pZCAqIGRpcmVudCwgZmlsbGRpcl90 IGZpbGxkaXIpOworc3RhdGljIGludCBhdXRvZnM0X3Jvb3RfcmVhZGRpcihzdHJ1Y3QgZmlsZSAq IGZpbHAsIHZvaWQgKiBkaXJlbnQsIGZpbGxkaXJfdCBmaWxsZGlyKTsKIHN0YXRpYyBzdHJ1Y3Qg ZGVudHJ5ICphdXRvZnM0X3Jvb3RfbG9va3VwKHN0cnVjdCBpbm9kZSAqLHN0cnVjdCBkZW50cnkg Kik7CitzdGF0aWMgaW50IGF1dG9mczRfZGNhY2hlX3JlYWRkaXIoc3RydWN0IGZpbGUgKiwgdm9p ZCAqLCBmaWxsZGlyX3QpOwogCiBzdHJ1Y3QgZmlsZV9vcGVyYXRpb25zIGF1dG9mczRfcm9vdF9v cGVyYXRpb25zID0gewotCW9wZW46CQlkY2FjaGVfZGlyX29wZW4sCi0JcmVsZWFzZToJZGNhY2hl X2Rpcl9jbG9zZSwKLQlsbHNlZWs6CQlkY2FjaGVfZGlyX2xzZWVrLAogCXJlYWQ6CQlnZW5lcmlj X3JlYWRfZGlyLAotCXJlYWRkaXI6CWRjYWNoZV9yZWFkZGlyLAotCWZzeW5jOgkJZGNhY2hlX2Rp cl9mc3luYywKKyAJcmVhZGRpcjoJYXV0b2ZzNF9yb290X3JlYWRkaXIsCiAJaW9jdGw6CQlhdXRv ZnM0X3Jvb3RfaW9jdGwsCiB9OwogCitzdHJ1Y3QgZmlsZV9vcGVyYXRpb25zIGF1dG9mczRfZGly X29wZXJhdGlvbnMgPSB7CisJb3BlbjoJCWF1dG9mczRfZGlyX29wZW4sCisJcmVsZWFzZToJYXV0 b2ZzNF9kaXJfY2xvc2UsCisJcmVhZDoJCWdlbmVyaWNfcmVhZF9kaXIsCisJcmVhZGRpcjoJYXV0 b2ZzNF9kaXJfcmVhZGRpciwKK307CisKIHN0cnVjdCBpbm9kZV9vcGVyYXRpb25zIGF1dG9mczRf cm9vdF9pbm9kZV9vcGVyYXRpb25zID0gewogCWxvb2t1cDoJCWF1dG9mczRfcm9vdF9sb29rdXAs CiAJdW5saW5rOgkJYXV0b2ZzNF9kaXJfdW5saW5rLApAQCAtNTQsMTAgKzY3LDExIEBACiAKIC8q IFVwZGF0ZSB1c2FnZSBmcm9tIGhlcmUgdG8gdG9wIG9mIHRyZWUsIHNvIHRoYXQgc2NhbiBvZgog ICAgdG9wLWxldmVsIGRpcmVjdG9yaWVzIHdpbGwgZ2l2ZSBhIHVzZWZ1bCByZXN1bHQgKi8KLXN0 YXRpYyB2b2lkIGF1dG9mczRfdXBkYXRlX3VzYWdlKHN0cnVjdCBkZW50cnkgKmRlbnRyeSkKK3N0 YXRpYyBpbmxpbmUgdm9pZCBhdXRvZnM0X3VwZGF0ZV91c2FnZShzdHJ1Y3QgZGVudHJ5ICpkZW50 cnkpCiB7CiAJc3RydWN0IGRlbnRyeSAqdG9wID0gZGVudHJ5LT5kX3NiLT5zX3Jvb3Q7CiAKKwlz cGluX2xvY2soJmRjYWNoZV9sb2NrKTsKIAlmb3IoOyBkZW50cnkgIT0gdG9wOyBkZW50cnkgPSBk ZW50cnktPmRfcGFyZW50KSB7CiAJCXN0cnVjdCBhdXRvZnNfaW5mbyAqaW5vID0gYXV0b2ZzNF9k ZW50cnlfaW5vKGRlbnRyeSk7CiAKQEAgLTY2LDExICs4MCwyMzMgQEAKIAkJCWluby0+bGFzdF91 c2VkID0gamlmZmllczsKIAkJfQogCX0KKwlzcGluX3VubG9jaygmZGNhY2hlX2xvY2spOworfQor CitzdGF0aWMgaW50IGF1dG9mczRfcm9vdF9yZWFkZGlyKHN0cnVjdCBmaWxlICpmaWxlLCB2b2lk ICpkaXJlbnQsIGZpbGxkaXJfdCBmaWxsZGlyKQoreworCXN0cnVjdCBhdXRvZnNfc2JfaW5mbyAq c2JpID0gYXV0b2ZzNF9zYmkoZmlsZS0+Zl9kZW50cnktPmRfc2IpOworCWludCBvel9tb2RlID0g YXV0b2ZzNF9vel9tb2RlKHNiaSk7CisKKwlEUFJJTlRLKCgiYXV0b2ZzNF9yb290X3JlYWRkaXIg Y2FsbGVkLCBmaWxwLT5mX3BvcyA9ICVsbGRcbiIsIGZpbGUtPmZfcG9zKSk7CisKKwkvKgorCSAq IERvbid0IHNldCByZWdob3N0IGZsYWcgaWY6CisJICogMSkgZl9wb3MgaXMgbGFyZ2VyIHRoYW4g emVybyAtLSB3ZSd2ZSBhbHJlYWR5IGJlZW4gaGVyZS4KKwkgKiAyKSB3ZSBoYXZlbid0IGV2ZW4g ZW5hYmxlZCByZWdob3N0aW5nIGluIHRoZSAxc3QgcGxhY2UuCisJICogMykgdGhpcyBpcyB0aGUg ZGFlbW9uIGRvaW5nIGEgcmVhZGRpcgorCSAqLworCWlmICggb3pfbW9kZSAmJiBmaWxlLT5mX3Bv cyA9PSAwICYmIHNiaS0+cmVnaG9zdF9lbmFibGVkICkKKwkJc2JpLT5uZWVkc19yZWdob3N0ID0g MTsKKworCURQUklOVEsoKCJhdXRvZnM0X3Jvb3RfcmVhZGRpcjogbmVlZHNfcmVnaG9zdCA9ICVk XG4iLCBzYmktPm5lZWRzX3JlZ2hvc3QpKTsKKworCXJldHVybiBhdXRvZnM0X2RjYWNoZV9yZWFk ZGlyKGZpbGUsIGRpcmVudCwgZmlsbGRpcik7Cit9CisKK3N0YXRpYyB2b2lkIGF1dG9mczRfY2hl Y2tfcHdkKHN0cnVjdCBmaWxlICpmaWxlLCBzdHJ1Y3QgZmlsZSAqZnApCit7CisJc3RydWN0IGRl bnRyeSAqcHdkID0gZmlsZS0+Zl9kZW50cnk7CisJc3RydWN0IGRlbnRyeSAqbmV3X3B3ZCA9IGZw LT5mX2RlbnRyeTsKKwlzdHJ1Y3QgdmZzbW91bnQgKm5ld19tbnQgPSBmcC0+Zl92ZnNtbnQ7CisK KwkvKiBkZW50cnkgaXMgYSBwd2Qgb2YgbW91bnRwb2ludCBzbyBtb3ZlIHRvIGl0ICovCisJaWYg KCBjdXJyZW50LT5mcy0+cHdkID09IHB3ZCApCisJCXNldF9mc19wd2QoY3VycmVudC0+ZnMsIG5l d19tbnQsIG5ld19wd2QpOworCisJLyogZGVudHJ5IGlzIHJvb3Qgb2YgYSBjaHJvb3RlZCBtb3Vu dHBvaW50IHNvIG1vdmUgdG8gaXQgKi8KKwlpZiAoIGN1cnJlbnQtPmZzLT5yb290ID09IHB3ZCAp IHsKKwkJc2V0X2ZzX3Jvb3QoY3VycmVudC0+ZnMsIG5ld19tbnQsIG5ld19wd2QpOworCQkvKiBh bHRlcm5hdGUgb3MgQUJJIG5vdCBzdXBwb3J0ZWQgICovCisJCS8qIHNldF9mc19hbHRyb290KCk7 ICovCisJfQorfQorCisKKy8qCisgKiBGcm9tIDIuNCBrZXJuZWwgcmVhZGRpci5jCisgKi8KK3N0 YXRpYyBpbnQgYXV0b2ZzNF9kY2FjaGVfcmVhZGRpcihzdHJ1Y3QgZmlsZSAqIGZpbHAsIHZvaWQg KiBkaXJlbnQsIGZpbGxkaXJfdCBmaWxsZGlyKQoreworCWludCBpOworCXN0cnVjdCBkZW50cnkg KmRlbnRyeSA9IGZpbHAtPmZfZGVudHJ5OworCisJaSA9IGZpbHAtPmZfcG9zOworCXN3aXRjaCAo aSkgeworCQljYXNlIDA6CisJCQlpZiAoZmlsbGRpcihkaXJlbnQsICIuIiwgMSwgaSwgZGVudHJ5 LT5kX2lub2RlLT5pX2lubywgRFRfRElSKSA8IDApCisJCQkJYnJlYWs7CisJCQlpKys7CisJCQlm aWxwLT5mX3BvcysrOworCQkJLyogZmFsbHRocm91Z2ggKi8KKwkJY2FzZSAxOgorCQkJaWYgKGZp bGxkaXIoZGlyZW50LCAiLi4iLCAyLCBpLCBkZW50cnktPmRfcGFyZW50LT5kX2lub2RlLT5pX2lu bywgRFRfRElSKSA8IDApCisJCQkJYnJlYWs7CisJCQlpKys7CisJCQlmaWxwLT5mX3BvcysrOwor CQkJLyogZmFsbHRocm91Z2ggKi8KKwkJZGVmYXVsdDogeworCQkJc3RydWN0IGxpc3RfaGVhZCAq bGlzdDsKKwkJCWludCBqID0gaS0yOworCisJCQlzcGluX2xvY2soJmRjYWNoZV9sb2NrKTsKKwkJ CWxpc3QgPSBkZW50cnktPmRfc3ViZGlycy5uZXh0OworCisJCQlmb3IgKDs7KSB7CisJCQkJaWYg KGxpc3QgPT0gJmRlbnRyeS0+ZF9zdWJkaXJzKSB7CisJCQkJCXNwaW5fdW5sb2NrKCZkY2FjaGVf bG9jayk7CisJCQkJCXJldHVybiAwOworCQkJCX0KKwkJCQlpZiAoIWopCisJCQkJCWJyZWFrOwor CQkJCWotLTsKKwkJCQlsaXN0ID0gbGlzdC0+bmV4dDsKKwkJCX0KKworCQkJd2hpbGUoMSkgewor CQkJCXN0cnVjdCBkZW50cnkgKmRlID0gbGlzdF9lbnRyeShsaXN0LCBzdHJ1Y3QgZGVudHJ5LCBk X2NoaWxkKTsKKworCQkJCWlmICghbGlzdF9lbXB0eSgmZGUtPmRfaGFzaCkgJiYgZGUtPmRfaW5v ZGUpIHsKKwkJCQkJc3Bpbl91bmxvY2soJmRjYWNoZV9sb2NrKTsKKwkJCQkJaWYgKGZpbGxkaXIo ZGlyZW50LCBkZS0+ZF9uYW1lLm5hbWUsIGRlLT5kX25hbWUubGVuLCBmaWxwLT5mX3BvcywgZGUt PmRfaW5vZGUtPmlfaW5vLCBEVF9VTktOT1dOKSA8IDApCisJCQkJCQlicmVhazsKKwkJCQkJc3Bp bl9sb2NrKCZkY2FjaGVfbG9jayk7CisJCQkJfQorCQkJCWZpbHAtPmZfcG9zKys7CisJCQkJbGlz dCA9IGxpc3QtPm5leHQ7CisJCQkJaWYgKGxpc3QgIT0gJmRlbnRyeS0+ZF9zdWJkaXJzKQorCQkJ CQljb250aW51ZTsKKwkJCQlzcGluX3VubG9jaygmZGNhY2hlX2xvY2spOworCQkJCWJyZWFrOwor CQkJfQorCQl9CisJfQorCXJldHVybiAwOworfQorCitzdGF0aWMgaW50IGF1dG9mczRfZGlyX29w ZW4oc3RydWN0IGlub2RlICppbm9kZSwgc3RydWN0IGZpbGUgKmZpbGUpCit7CisJc3RydWN0IGRl bnRyeSAqZGVudHJ5ID0gZmlsZS0+Zl9kZW50cnk7CisJc3RydWN0IHZmc21vdW50ICptbnQgPSBm aWxlLT5mX3Zmc21udDsKKwlzdHJ1Y3QgYXV0b2ZzX3NiX2luZm8gKnNiaSA9IGF1dG9mczRfc2Jp KGRlbnRyeS0+ZF9zYik7CisJaW50IHN0YXR1czsKKworCURQUklOVEsoKCJhdXRvZnM0X2Rpcl9v cGVuOiBmaWxlPSVwIGRlbnRyeT0lcCAlLipzXG4iLAorCQkgZmlsZSwgZGVudHJ5LCBkZW50cnkt PmRfbmFtZS5sZW4sIGRlbnRyeS0+ZF9uYW1lLm5hbWUpKTsKKworCWlmIChhdXRvZnM0X296X21v ZGUoc2JpKSkKKwkJZ290byBvdXQ7CisKKwlpZiAoYXV0b2ZzNF9pc3BlbmRpbmcoZGVudHJ5KSkg eworCQlEUFJJTlRLKCgiYXV0b2ZzNF9kaXJfb3BlbjogZGVudHJ5IGJ1c3lcbiIpKTsKKwkJcmV0 dXJuIC1FQlVTWTsKKwl9CisKKwlpZiAoIWRfbW91bnRwb2ludChkZW50cnkpICYmIGRlbnRyeS0+ ZF9vcCAmJiBkZW50cnktPmRfb3AtPmRfcmV2YWxpZGF0ZSkgeworCQlpbnQgZW1wdHk7CisKKwkJ LyogSW4gY2FzZSB0aGVyZSBhcmUgc3RhbGUgZGlyZWN0b3J5IGRlbnRyeXMgZnJvbSBhIGZhaWxl ZCBtb3VudCAqLworCQlzcGluX2xvY2soJmRjYWNoZV9sb2NrKTsKKwkJZW1wdHkgPSBsaXN0X2Vt cHR5KCZkZW50cnktPmRfc3ViZGlycyk7CisJCXNwaW5fdW5sb2NrKCZkY2FjaGVfbG9jayk7CisK KwkJaWYgKCFlbXB0eSkKKwkJCWRfaW52YWxpZGF0ZShkZW50cnkpOworCisJCXN0YXR1cyA9IChk ZW50cnktPmRfb3AtPmRfcmV2YWxpZGF0ZSkoZGVudHJ5LCBMT09LVVBfQ09OVElOVUUpOworCisJ CWlmICggIXN0YXR1cyApCisJCQlyZXR1cm4gLUVOT0VOVDsKKwl9CisKKwlpZiAoIGRfbW91bnRw b2ludChkZW50cnkpICkgeworCQlzdHJ1Y3QgZmlsZSAqZnAgPSBOVUxMOworCQlzdHJ1Y3QgdmZz bW91bnQgKmZwX21udCA9IG1udGdldChtbnQpOworCQlzdHJ1Y3QgZGVudHJ5ICpmcF9kZW50cnkg PSBkZ2V0KGRlbnRyeSk7CisKKwkJd2hpbGUgKGZvbGxvd19kb3duKCZmcF9tbnQsICZmcF9kZW50 cnkpICYmIGRfbW91bnRwb2ludChmcF9kZW50cnkpKTsKKworCQlmcCA9IGRlbnRyeV9vcGVuKGZw X2RlbnRyeSwgZnBfbW50LCBmaWxlLT5mX2ZsYWdzKTsKKwkJc3RhdHVzID0gUFRSX0VSUihmcCk7 CisJCWlmICggSVNfRVJSKGZwKSApIHsKKwkJCWZpbGUtPnByaXZhdGVfZGF0YSA9IE5VTEw7CisJ CQlyZXR1cm4gc3RhdHVzOworCQl9CisJCWF1dG9mczRfY2hlY2tfcHdkKGZpbGUsIGZwKTsKKwkJ ZmlsZS0+cHJpdmF0ZV9kYXRhID0gZnA7CisJfQorb3V0OgorCXJldHVybiAwOworfQorCitzdGF0 aWMgaW50IGF1dG9mczRfZGlyX2Nsb3NlKHN0cnVjdCBpbm9kZSAqaW5vZGUsIHN0cnVjdCBmaWxl ICpmaWxlKQoreworCXN0cnVjdCBkZW50cnkgKmRlbnRyeSA9IGZpbGUtPmZfZGVudHJ5OworCXN0 cnVjdCBhdXRvZnNfc2JfaW5mbyAqc2JpID0gYXV0b2ZzNF9zYmkoZGVudHJ5LT5kX3NiKTsKKwor CURQUklOVEsoKCJhdXRvZnM0X2Rpcl9jbG9zZTogZmlsZT0lcCBkZW50cnk9JXAgJS4qc1xuIiwK KwkJIGZpbGUsIGRlbnRyeSwgZGVudHJ5LT5kX25hbWUubGVuLCBkZW50cnktPmRfbmFtZS5uYW1l KSk7CisKKwlpZiAoIGF1dG9mczRfb3pfbW9kZShzYmkpICkKKwkJZ290byBvdXQ7CisKKwlpZiAo IGF1dG9mczRfaXNwZW5kaW5nKGRlbnRyeSkgKSB7CisJCURQUklOVEsoKCJhdXRvZnM0X2Rpcl9j bG9zZTogZGVudHJ5IGJ1c3lcbiIpKTsKKwkJcmV0dXJuIC1FQlVTWTsKKwl9CisKKwlpZiAoIGRf bW91bnRwb2ludChkZW50cnkpICkgeworCQlzdHJ1Y3QgZmlsZSAqZnAgPSBmaWxlLT5wcml2YXRl X2RhdGE7CisKKwkJaWYgKCFmcCkKKwkJCXJldHVybiAtRU5PRU5UOworCisJCWZpbHBfY2xvc2Uo ZnAsIGN1cnJlbnQtPmZpbGVzKTsKKwkJZmlsZS0+cHJpdmF0ZV9kYXRhID0gTlVMTDsKKwl9Citv dXQ6CisJcmV0dXJuIDA7Cit9CisKK3N0YXRpYyBpbnQgYXV0b2ZzNF9kaXJfcmVhZGRpcihzdHJ1 Y3QgZmlsZSAqZmlsZSwgdm9pZCAqZGlyZW50LCBmaWxsZGlyX3QgZmlsbGRpcikKK3sKKwlzdHJ1 Y3QgZGVudHJ5ICpkZW50cnkgPSBmaWxlLT5mX2RlbnRyeTsKKwlzdHJ1Y3QgYXV0b2ZzX3NiX2lu Zm8gKnNiaSA9IGF1dG9mczRfc2JpKGRlbnRyeS0+ZF9zYik7CisJaW50IHN0YXR1czsKKworCURQ UklOVEsoKCJhdXRvZnM0X3JlYWRkaXI6IGZpbGU9JXAgZGVudHJ5PSVwICUuKnNcbiIsCisJCSBm aWxlLCBkZW50cnksIGRlbnRyeS0+ZF9uYW1lLmxlbiwgZGVudHJ5LT5kX25hbWUubmFtZSkpOwor CisJaWYgKCBhdXRvZnM0X296X21vZGUoc2JpKSApCisJCWdvdG8gb3V0OworCisJaWYgKCBhdXRv ZnM0X2lzcGVuZGluZyhkZW50cnkpICkgeworCQlEUFJJTlRLKCgiYXV0b2ZzNF9yZWFkZGlyOiBk ZW50cnkgYnVzeVxuIikpOworCQlyZXR1cm4gLUVCVVNZOworCX0KKworCWlmICggZF9tb3VudHBv aW50KGRlbnRyeSkgKSB7CisJCXN0cnVjdCBmaWxlICpmcCA9IGZpbGUtPnByaXZhdGVfZGF0YTsK KworCQlpZiAoIWZwKQorCQkJcmV0dXJuIC1FTk9FTlQ7CisKKwkJaWYgKCFmcC0+Zl9vcCB8fCAh ZnAtPmZfb3AtPnJlYWRkaXIpCisJCQlnb3RvIG91dDsKKworCQlzdGF0dXMgPSB2ZnNfcmVhZGRp cihmcCwgZmlsbGRpciwgZGlyZW50KTsKKwkJZmlsZS0+Zl9wb3MgPSBmcC0+Zl9wb3M7CisJCWlm ICggc3RhdHVzICkKKwkJCWF1dG9mczRfY29weV9hdGltZShmaWxlLCBmcCk7CisJCXJldHVybiBz dGF0dXM7CisJfQorb3V0OgorCXJldHVybiBhdXRvZnM0X2RjYWNoZV9yZWFkZGlyKGZpbGUsIGRp cmVudCwgZmlsbGRpcik7CiB9CiAKIHN0YXRpYyBpbnQgdHJ5X3RvX2ZpbGxfZGVudHJ5KHN0cnVj dCBkZW50cnkgKmRlbnRyeSwgCiAJCQkgICAgICBzdHJ1Y3Qgc3VwZXJfYmxvY2sgKnNiLAotCQkJ ICAgICAgc3RydWN0IGF1dG9mc19zYl9pbmZvICpzYmkpCisJCQkgICAgICBzdHJ1Y3QgYXV0b2Zz X3NiX2luZm8gKnNiaSwgaW50IGZsYWdzKQogewogCXN0cnVjdCBhdXRvZnNfaW5mbyAqZGVfaW5m byA9IGF1dG9mczRfZGVudHJ5X2lubyhkZW50cnkpOwogCWludCBzdGF0dXMgPSAwOwpAQCAtNzks MTIgKzMxNSwxMSBAQAogICAgICAgICAgICB3aGVuIGV4cGlyYXRpb24gaXMgZG9uZSB0byB0cmln Z2VyIG1vdW50IHJlcXVlc3Qgd2l0aCBhIG5ldwogICAgICAgICAgICBkZW50cnkgKi8KIAlpZiAo ZGVfaW5mbyAmJiAoZGVfaW5mby0+ZmxhZ3MgJiBBVVRPRlNfSU5GX0VYUElSSU5HKSkgewotCQlE UFJJTlRLKCgidHJ5X3RvX2ZpbGxfZW50cnk6IHdhaXRpbmcgZm9yIGV4cGlyZSAlcCBuYW1lPSUu KnMsIGZsYWdzJlBFTkRJTkc9JXMgZGVfaW5mbz0lcCBkZV9pbmZvLT5mbGFncz0leFxuIiwKLQkJ CSBkZW50cnksIGRlbnRyeS0+ZF9uYW1lLmxlbiwgZGVudHJ5LT5kX25hbWUubmFtZSwgCi0JCQkg ZGVudHJ5LT5kX2ZsYWdzICYgRENBQ0hFX0FVVE9GU19QRU5ESU5HPyJ0IjoiZiIsCi0JCQkgZGVf aW5mbywgZGVfaW5mbz9kZV9pbmZvLT5mbGFnczowKSk7Ci0JCXN0YXR1cyA9IGF1dG9mczRfd2Fp dChzYmksICZkZW50cnktPmRfbmFtZSwgTkZZX05PTkUpOwotCQkKKwkJRFBSSU5USygoInRyeV90 b19maWxsX2VudHJ5OiB3YWl0aW5nIGZvciBleHBpcmUgJXAgbmFtZT0lLipzXG4iLAorCQkJIGRl bnRyeSwgZGVudHJ5LT5kX25hbWUubGVuLCBkZW50cnktPmRfbmFtZS5uYW1lKSk7CisKKwkJc3Rh dHVzID0gYXV0b2ZzNF93YWl0KHNiaSwgZGVudHJ5LCBORllfTk9ORSk7CisKIAkJRFBSSU5USygo InRyeV90b19maWxsX2VudHJ5OiBleHBpcmUgZG9uZSBzdGF0dXM9JWRcbiIsIHN0YXR1cykpOwog CQkKIAkJcmV0dXJuIDA7CkBAIC05NCwxMiArMzI5LDEyIEBACiAJCSBkZW50cnksIGRlbnRyeS0+ ZF9uYW1lLmxlbiwgZGVudHJ5LT5kX25hbWUubmFtZSwgZGVudHJ5LT5kX2lub2RlKSk7CiAKIAkv KiBXYWl0IGZvciBhIHBlbmRpbmcgbW91bnQsIHRyaWdnZXJpbmcgb25lIGlmIHRoZXJlIGlzbid0 IG9uZSBhbHJlYWR5ICovCi0Jd2hpbGUoZGVudHJ5LT5kX2lub2RlID09IE5VTEwpIHsKLQkJRFBS SU5USygoInRyeV90b19maWxsX2VudHJ5OiB3YWl0aW5nIGZvciBtb3VudCBuYW1lPSUuKnMsIGRl X2luZm89JXAgZGVfaW5mby0+ZmxhZ3M9JXhcbiIsCi0JCQkgZGVudHJ5LT5kX25hbWUubGVuLCBk ZW50cnktPmRfbmFtZS5uYW1lLCAKLQkJCSBkZV9pbmZvLCBkZV9pbmZvP2RlX2luZm8tPmZsYWdz OjApKTsKLQkJc3RhdHVzID0gYXV0b2ZzNF93YWl0KHNiaSwgJmRlbnRyeS0+ZF9uYW1lLCBORllf TU9VTlQpOwotCQkgCisJaWYgKGRlbnRyeS0+ZF9pbm9kZSA9PSBOVUxMKSB7CisJCURQUklOVEso KCJ0cnlfdG9fZmlsbF9lbnRyeTogd2FpdGluZyBmb3IgbW91bnQgbmFtZT0lLipzXG4iLAorCQkJ IGRlbnRyeS0+ZF9uYW1lLmxlbiwgZGVudHJ5LT5kX25hbWUubmFtZSkpOworCisJCXN0YXR1cyA9 IGF1dG9mczRfd2FpdChzYmksIGRlbnRyeSwgTkZZX01PVU5UKTsKKwogCQlEUFJJTlRLKCgidHJ5 X3RvX2ZpbGxfZW50cnk6IG1vdW50IGRvbmUgc3RhdHVzPSVkXG4iLCBzdGF0dXMpKTsKIAogCQlp ZiAoc3RhdHVzICYmIGRlbnRyeS0+ZF9pbm9kZSkKQEAgLTExNCwxOSArMzQ5LDIxIEBACiAJCQkv KiBSZXR1cm4gYSBuZWdhdGl2ZSBkZW50cnksIGJ1dCBsZWF2ZSBpdCAicGVuZGluZyIgKi8KIAkJ CXJldHVybiAxOwogCQl9Ci0JfQorCS8qIFRyaWdnZXIgbW91bnQgZm9yIHBhdGggY29tcG9uZW50 IG9yIGZvbGxvdyBsaW5rICovCisJfSBlbHNlIGlmICggZmxhZ3MgJiBMT09LVVBfQ09OVElOVUUg fHwgY3VycmVudC0+bGlua19jb3VudCApIHsKKwkJRFBSSU5USygoInRyeV90b19maWxsX2VudHJ5 OiB3YWl0aW5nIGZvciBtb3VudCBuYW1lPSUuKnNcbiIsCisJCQkgZGVudHJ5LT5kX25hbWUubGVu LCBkZW50cnktPmRfbmFtZS5uYW1lKSk7CiAKLQkvKiBJZiB0aGlzIGlzIGFuIHVudXNlZCBkaXJl Y3RvcnkgdGhhdCBpc24ndCBhIG1vdW50IHBvaW50LAotCSAgIGJpdGNoIGF0IHRoZSBkYWVtb24g YW5kIGZpeCBpdCBpbiB1c2VyIHNwYWNlICovCi0Jc3Bpbl9sb2NrKCZkY2FjaGVfbG9jayk7Ci0J aWYgKFNfSVNESVIoZGVudHJ5LT5kX2lub2RlLT5pX21vZGUpICYmCi0JICAgICFkX21vdW50cG9p bnQoZGVudHJ5KSAmJiAKLQkgICAgbGlzdF9lbXB0eSgmZGVudHJ5LT5kX3N1YmRpcnMpKSB7Ci0J CURQUklOVEsoKCJ0cnlfdG9fZmlsbF9lbnRyeTogbW91bnRpbmcgZXhpc3RpbmcgZGlyXG4iKSk7 Ci0JCXNwaW5fdW5sb2NrKCZkY2FjaGVfbG9jayk7Ci0JCXJldHVybiBhdXRvZnM0X3dhaXQoc2Jp LCAmZGVudHJ5LT5kX25hbWUsIE5GWV9NT1VOVCkgPT0gMDsKKwkJZGVudHJ5LT5kX2ZsYWdzIHw9 IERDQUNIRV9BVVRPRlNfUEVORElORzsKKwkJc3RhdHVzID0gYXV0b2ZzNF93YWl0KHNiaSwgZGVu dHJ5LCBORllfTU9VTlQpOworCisJCURQUklOVEsoKCJ0cnlfdG9fZmlsbF9lbnRyeTogbW91bnQg ZG9uZSBzdGF0dXM9JWRcbiIsIHN0YXR1cykpOworCisJCWlmICggc3RhdHVzICkgeworCQkJZGVu dHJ5LT5kX2ZsYWdzICY9IH5EQ0FDSEVfQVVUT0ZTX1BFTkRJTkc7CisJCQlyZXR1cm4gMDsKKwkJ fQogCX0KLQlzcGluX3VubG9jaygmZGNhY2hlX2xvY2spOwogCiAJLyogV2UgZG9uJ3QgdXBkYXRl IHRoZSB1c2FnZXMgZm9yIHRoZSBhdXRvZnMgZGFlbW9uIGl0c2VsZiwgdGhpcwogCSAgIGlzIG5l Y2Vzc2FyeSBmb3IgcmVjdXJzaXZlIGF1dG9mcyBtb3VudHMgKi8KQEAgLTEzNyw0MyArMzc0LDQ2 IEBACiAJcmV0dXJuIDE7CiB9CiAKLQogLyoKICAqIFJldmFsaWRhdGUgaXMgY2FsbGVkIG9uIGV2 ZXJ5IGNhY2hlIGxvb2t1cC4gIFNvbWUgb2YgdGhvc2UKICAqIGNhY2hlIGxvb2t1cHMgbWF5IGFj dHVhbGx5IGhhcHBlbiB3aGlsZSB0aGUgZGVudHJ5IGlzIG5vdAogICogeWV0IGNvbXBsZXRlbHkg ZmlsbGVkIGluLCBhbmQgcmV2YWxpZGF0ZSBoYXMgdG8gZGVsYXkgc3VjaAogICogbG9va3Vwcy4u CiAgKi8KLXN0YXRpYyBpbnQgYXV0b2ZzNF9yb290X3JldmFsaWRhdGUoc3RydWN0IGRlbnRyeSAq IGRlbnRyeSwgaW50IGZsYWdzKQorc3RhdGljIGludCBhdXRvZnM0X3JldmFsaWRhdGUoc3RydWN0 IGRlbnRyeSAqIGRlbnRyeSwgaW50IGZsYWdzKQogewogCXN0cnVjdCBpbm9kZSAqIGRpciA9IGRl bnRyeS0+ZF9wYXJlbnQtPmRfaW5vZGU7CiAJc3RydWN0IGF1dG9mc19zYl9pbmZvICpzYmkgPSBh dXRvZnM0X3NiaShkaXItPmlfc2IpOwogCWludCBvel9tb2RlID0gYXV0b2ZzNF9vel9tb2RlKHNi aSk7CisJaW50IHN0YXR1cyA9IDE7CisKKwlEUFJJTlRLKCgiYXV0b2ZzNF9yZXZhbGlkYXRlOiBk ZW50cnk9JXAgJS4qcyBmbGFncz0lZFxuIiwKKwkJIGRlbnRyeSwgZGVudHJ5LT5kX25hbWUubGVu LCBkZW50cnktPmRfbmFtZS5uYW1lLCBmbGFncykpOwogCiAJLyogUGVuZGluZyBkZW50cnkgKi8K IAlpZiAoYXV0b2ZzNF9pc3BlbmRpbmcoZGVudHJ5KSkgewotCQlpZiAoYXV0b2ZzNF9vel9tb2Rl KHNiaSkpCi0JCQlyZXR1cm4gMTsKLQkJZWxzZQotCQkJcmV0dXJuIHRyeV90b19maWxsX2RlbnRy eShkZW50cnksIGRpci0+aV9zYiwgc2JpKTsKKwkJaWYgKCAhb3pfbW9kZSApCisJCQlzdGF0dXMg PSB0cnlfdG9fZmlsbF9kZW50cnkoZGVudHJ5LCBkaXItPmlfc2IsIHNiaSwgZmxhZ3MpOworCQly ZXR1cm4gc3RhdHVzOwogCX0KIAogCS8qIE5lZ2F0aXZlIGRlbnRyeS4uIGludmFsaWRhdGUgaWYg Im9sZCIgKi8KLQlpZiAoZGVudHJ5LT5kX2lub2RlID09IE5VTEwpCi0JCXJldHVybiAoZGVudHJ5 LT5kX3RpbWUgLSBqaWZmaWVzIDw9IEFVVE9GU19ORUdBVElWRV9USU1FT1VUKTsKKwlpZiAoZGVu dHJ5LT5kX2lub2RlID09IE5VTEwpIHsKKwkJc3RhdHVzID0gKGRlbnRyeS0+ZF90aW1lIC0gamlm ZmllcyA8PSBBVVRPRlNfTkVHQVRJVkVfVElNRU9VVCk7CisJCXJldHVybiBzdGF0dXM7CisJfQog CiAJLyogQ2hlY2sgZm9yIGEgbm9uLW1vdW50cG9pbnQgZGlyZWN0b3J5IHdpdGggbm8gY29udGVu dHMgKi8KIAlzcGluX2xvY2soJmRjYWNoZV9sb2NrKTsKIAlpZiAoU19JU0RJUihkZW50cnktPmRf aW5vZGUtPmlfbW9kZSkgJiYKIAkgICAgIWRfbW91bnRwb2ludChkZW50cnkpICYmIAogCSAgICBs aXN0X2VtcHR5KCZkZW50cnktPmRfc3ViZGlycykpIHsKLQkJRFBSSU5USygoImF1dG9mc19yb290 X3JldmFsaWRhdGU6IGRlbnRyeT0lcCAlLipzLCBlbXB0eWRpclxuIiwKKwkJRFBSSU5USygoImF1 dG9mczRfcmV2YWxpZGF0ZTogZGVudHJ5PSVwICUuKnMsIGVtcHR5ZGlyXG4iLAogCQkJIGRlbnRy eSwgZGVudHJ5LT5kX25hbWUubGVuLCBkZW50cnktPmRfbmFtZS5uYW1lKSk7CiAJCXNwaW5fdW5s b2NrKCZkY2FjaGVfbG9jayk7Ci0JCWlmIChvel9tb2RlKQotCQkJcmV0dXJuIDE7Ci0JCWVsc2UK LQkJCXJldHVybiB0cnlfdG9fZmlsbF9kZW50cnkoZGVudHJ5LCBkaXItPmlfc2IsIHNiaSk7CisJ CWlmICghb3pfbW9kZSkKKwkJCXN0YXR1cyA9IHRyeV90b19maWxsX2RlbnRyeShkZW50cnksIGRp ci0+aV9zYiwgc2JpLCBmbGFncyk7CisJCXJldHVybiBzdGF0dXM7CiAJfQogCXNwaW5fdW5sb2Nr KCZkY2FjaGVfbG9jayk7CiAKQEAgLTE4MSwyNSArNDIxLDEzIEBACiAJaWYgKCFvel9tb2RlKQog CQlhdXRvZnM0X3VwZGF0ZV91c2FnZShkZW50cnkpOwogCi0JcmV0dXJuIDE7Ci19Ci0KLXN0YXRp YyBpbnQgYXV0b2ZzNF9yZXZhbGlkYXRlKHN0cnVjdCBkZW50cnkgKmRlbnRyeSwgaW50IGZsYWdz KQotewotCXN0cnVjdCBhdXRvZnNfc2JfaW5mbyAqc2JpID0gYXV0b2ZzNF9zYmkoZGVudHJ5LT5k X3NiKTsKLQotCWlmICghYXV0b2ZzNF9vel9tb2RlKHNiaSkpCi0JCWF1dG9mczRfdXBkYXRlX3Vz YWdlKGRlbnRyeSk7Ci0KLQlyZXR1cm4gMTsKKwlyZXR1cm4gc3RhdHVzOwogfQogCiBzdGF0aWMg dm9pZCBhdXRvZnM0X2RlbnRyeV9yZWxlYXNlKHN0cnVjdCBkZW50cnkgKmRlKQogewogCXN0cnVj dCBhdXRvZnNfaW5mbyAqaW5mOwogCi0JbG9ja19rZXJuZWwoKTsKLQogCURQUklOVEsoKCJhdXRv ZnM0X2RlbnRyeV9yZWxlYXNlOiByZWxlYXNpbmcgJXBcbiIsIGRlKSk7CiAKIAlpbmYgPSBhdXRv ZnM0X2RlbnRyeV9pbm8oZGUpOwpAQCAtMjExLDEzICs0MzksMTEgQEAKIAogCQlhdXRvZnM0X2Zy ZWVfaW5vKGluZik7CiAJfQotCi0JdW5sb2NrX2tlcm5lbCgpOwogfQogCiAvKiBGb3IgZGVudHJp ZXMgb2YgZGlyZWN0b3JpZXMgaW4gdGhlIHJvb3QgZGlyICovCiBzdGF0aWMgc3RydWN0IGRlbnRy eV9vcGVyYXRpb25zIGF1dG9mczRfcm9vdF9kZW50cnlfb3BlcmF0aW9ucyA9IHsKLQlkX3JldmFs aWRhdGU6CWF1dG9mczRfcm9vdF9yZXZhbGlkYXRlLAorCWRfcmV2YWxpZGF0ZToJYXV0b2ZzNF9y ZXZhbGlkYXRlLAogCWRfcmVsZWFzZToJYXV0b2ZzNF9kZW50cnlfcmVsZWFzZSwKIH07CiAKQEAg LTIyNywxNiArNDUzLDExNCBAQAogCWRfcmVsZWFzZToJYXV0b2ZzNF9kZW50cnlfcmVsZWFzZSwK IH07CiAKLS8qIExvb2t1cHMgaW4gbm9uLXJvb3QgZGlycyBuZXZlciBmaW5kIGFueXRoaW5nIC0g aWYgaXQncyB0aGVyZSwgaXQncwotICAgYWxyZWFkeSBpbiB0aGUgZGNhY2hlICovCisvKgorICog VGhpcyBzdWJyb3V0aW5lIGlzIHRha2VuIHN0cmFpZ2h0IG91dCBvZiBmcy9uYW1laS5jIHNpbmNl IHdlIG5lZWQKKyAqIHRvIGRvIHRoZSBsb29rdXAgYWdhaW4gaW4gZXhhY2x0eSB0aGUgc2FtZSB3 YXkuCisgKi8KK3N0YXRpYyBzdHJ1Y3QgZGVudHJ5ICogcmVhbF9sb29rdXAoc3RydWN0IGRlbnRy eSAqIHBhcmVudCwgc3RydWN0IHFzdHIgKiBuYW1lLCBpbnQgZmxhZ3MpCit7CisJc3RydWN0IGRl bnRyeSAqIHJlc3VsdDsKKwlzdHJ1Y3QgaW5vZGUgKmRpciA9IHBhcmVudC0+ZF9pbm9kZTsKKwor CWRvd24oJmRpci0+aV9zZW0pOworCXJlc3VsdCA9IGRfbG9va3VwKHBhcmVudCwgbmFtZSk7CisJ aWYgKCFyZXN1bHQpIHsKKwkJc3RydWN0IGRlbnRyeSAqIGRlbnRyeSA9IGRfYWxsb2MocGFyZW50 LCBuYW1lKTsKKwkJcmVzdWx0ID0gRVJSX1BUUigtRU5PTUVNKTsKKwkJaWYgKGRlbnRyeSkgewor CQkJbG9ja19rZXJuZWwoKTsKKwkJCXJlc3VsdCA9IGRpci0+aV9vcC0+bG9va3VwKGRpciwgZGVu dHJ5KTsKKwkJCXVubG9ja19rZXJuZWwoKTsKKwkJCWlmIChyZXN1bHQpCisJCQkJZHB1dChkZW50 cnkpOworCQkJZWxzZQorCQkJCXJlc3VsdCA9IGRlbnRyeTsKKwkJfQorCQl1cCgmZGlyLT5pX3Nl bSk7CisJCXJldHVybiByZXN1bHQ7CisJfQorCisJdXAoJmRpci0+aV9zZW0pOworCWlmIChyZXN1 bHQtPmRfb3AgJiYgcmVzdWx0LT5kX29wLT5kX3JldmFsaWRhdGUpIHsKKwkJaWYgKCFyZXN1bHQt PmRfb3AtPmRfcmV2YWxpZGF0ZShyZXN1bHQsIGZsYWdzKSAmJiAhZF9pbnZhbGlkYXRlKHJlc3Vs dCkpIHsKKwkJCWRwdXQocmVzdWx0KTsKKwkJCXJlc3VsdCA9IEVSUl9QVFIoLUVOT0VOVCk7CisJ CX0KKwl9CisJcmV0dXJuIHJlc3VsdDsKK30KKworc3RhdGljIGludCBpc19hdXRvZnM0X21vdW50 cG9pbnQoc3RydWN0IGRlbnRyeSAqcGFyZW50KQoreworCXN0cnVjdCBsaXN0X2hlYWQgKnRtcDsK KworCURQUklOVEsoKCJhdXRvZnM0X2lzX21vdW50cG9pbnQ6IHBhcmVudD0lcCAlLipzXG4iLAor CQlwYXJlbnQsIHBhcmVudC0+ZF9uYW1lLmxlbiwgcGFyZW50LT5kX25hbWUubmFtZSkpOworCisJ c3Bpbl9sb2NrKCZkY2FjaGVfbG9jayk7CisJdG1wID0gcGFyZW50LT5kX3N1YmRpcnMubmV4dDsK Kwl3aGlsZSAoIHRtcCAhPSAmcGFyZW50LT5kX3N1YmRpcnMgKSB7CisJCXN0cnVjdCBkZW50cnkg KiBkZW50cnkgPSBsaXN0X2VudHJ5KHRtcCwgc3RydWN0IGRlbnRyeSwgZF9jaGlsZCk7CisKKwkJ dG1wID0gdG1wLT5uZXh0OworCisJCWlmIChpc19hdXRvZnM0X2RlbnRyeShkZW50cnkpICYmICFk X3VuaGFzaGVkKGRlbnRyeSkpIHsKKwkJCXNwaW5fdW5sb2NrKCZkY2FjaGVfbG9jayk7CisJCQly ZXR1cm4gMDsKKwkJfQorCX0KKwlzcGluX3VubG9jaygmZGNhY2hlX2xvY2spOworCXJldHVybiAx OworfQorCisvKiBMb29rdXBzIGluIG5vbiByb290IGRpcmVjdG9yaWVzICovCiBzdGF0aWMgc3Ry dWN0IGRlbnRyeSAqYXV0b2ZzNF9kaXJfbG9va3VwKHN0cnVjdCBpbm9kZSAqZGlyLCBzdHJ1Y3Qg ZGVudHJ5ICpkZW50cnkpCiB7Ci0jaWYgMAotCURQUklOVEsoKCJhdXRvZnNfZGlyX2xvb2t1cDog aWdub3JpbmcgbG9va3VwIG9mICUuKnMvJS4qc1xuIiwKKwlzdHJ1Y3QgZGVudHJ5ICpwYXJlbnQg PSBkZW50cnktPmRfcGFyZW50OworCXN0cnVjdCBhdXRvZnNfc2JfaW5mbyAqc2JpID0gYXV0b2Zz NF9zYmkocGFyZW50LT5kX3NiKTsKKwlzdHJ1Y3QgcXN0ciAqbmFtZSA9ICZkZW50cnktPmRfbmFt ZTsKKwlzdHJ1Y3QgdmZzbW91bnQgKm1udCA9IE5VTEw7CisJaW50IHN0YXR1cyA9IDA7CisKKwlE UFJJTlRLKCgiYXV0b2ZzNF9kaXJfbG9va3VwOiBsb29rdXAgb2YgJXAgJS4qcy8lLipzXG4iLAor CQkgZGVudHJ5LT5kX3BhcmVudCwgCiAJCSBkZW50cnktPmRfcGFyZW50LT5kX25hbWUubGVuLCBk ZW50cnktPmRfcGFyZW50LT5kX25hbWUubmFtZSwKIAkJIGRlbnRyeS0+ZF9uYW1lLmxlbiwgZGVu dHJ5LT5kX25hbWUubmFtZSkpOwotI2VuZGlmCiAKKwlpZiAoYXV0b2ZzNF9vel9tb2RlKHNiaSkp CisJCWdvdG8gb3V0OworCisJaWYgKCFpc19hdXRvZnM0X21vdW50cG9pbnQocGFyZW50KSkKKwkJ Z290byBvdXQ7CisKKwkvKiBJZiBvdXIgcHdkIG9yIHJvb3QgZGVudHJ5IGlzIGFuIGF1dG9mczQg bGVhZiBub2RlCisJICogd2UgbmVlZCB0byBtb3VudCBpdCBhbmQgcmVkbyB0aGUgbG9va3VwICov CisJaWYgKCFkX21vdW50cG9pbnQocGFyZW50KSkgeworCQlEUFJJTlRLKCgiYXV0b2ZzNF9kaXJf bG9va3VwOiB3YWl0aW5nIGZvciBtb3VudCBuYW1lPSUuKnNcbiIsCisJCQlwYXJlbnQtPmRfbmFt ZS5sZW4sIHBhcmVudC0+ZF9uYW1lLm5hbWUpKTsKKworCQl1cCgmZGlyLT5pX3NlbSk7CisJCXN0 YXR1cyA9IHRyeV90b19maWxsX2RlbnRyeShwYXJlbnQsIGRpci0+aV9zYiwgc2JpLCBMT09LVVBf Q09OVElOVUUpOworCQlkb3duKCZkaXItPmlfc2VtKTsKKworCQlEUFJJTlRLKCgiYXV0b2ZzNF9k aXJfbG9va3VwOiBtb3VudCBkb25lIHN0YXR1cz0lZFxuIiwgc3RhdHVzKSk7CisKKwkJaWYgKCAh c3RhdHVzICkKKwkJCWdvdG8gb3V0OworCX0KKworCXJlYWRfbG9jaygmY3VycmVudC0+ZnMtPmxv Y2spOworCWlmIChjdXJyZW50LT5mcy0+cHdkID09IHBhcmVudCApCisJCW1udCA9IGxvb2t1cF9t bnQoY3VycmVudC0+ZnMtPnB3ZG1udCwgcGFyZW50KTsKKwllbHNlIGlmIChjdXJyZW50LT5mcy0+ cm9vdCA9PSBwYXJlbnQpCisJCW1udCA9IGxvb2t1cF9tbnQoY3VycmVudC0+ZnMtPnJvb3RtbnQs IHBhcmVudCk7CisJcmVhZF91bmxvY2soJmN1cnJlbnQtPmZzLT5sb2NrKTsKKworCWlmICggIW1u dCApCisJCWdvdG8gb3V0OworCisJcmV0dXJuIHJlYWxfbG9va3VwKG1udC0+bW50X3Jvb3QsIG5h bWUsIDApOworb3V0OgogCWRlbnRyeS0+ZF9mc2RhdGEgPSBOVUxMOwogCWRfYWRkKGRlbnRyeSwg TlVMTCk7CiAJcmV0dXJuIE5VTEw7CkBAIC0yNDgsNyArNTcyLDcgQEAKIAlzdHJ1Y3QgYXV0b2Zz X3NiX2luZm8gKnNiaTsKIAlpbnQgb3pfbW9kZTsKIAotCURQUklOVEsoKCJhdXRvZnNfcm9vdF9s b29rdXA6IG5hbWUgPSAlLipzXG4iLCAKKwlEUFJJTlRLKCgiYXV0b2ZzNF9yb290X2xvb2t1cDog bmFtZSA9ICUuKnNcbiIsIAogCQkgZGVudHJ5LT5kX25hbWUubGVuLCBkZW50cnktPmRfbmFtZS5u YW1lKSk7CiAKIAlpZiAoZGVudHJ5LT5kX25hbWUubGVuID4gTkFNRV9NQVgpCkBAIC0yNTcsNyAr NTgxLDggQEAKIAlzYmkgPSBhdXRvZnM0X3NiaShkaXItPmlfc2IpOwogCiAJb3pfbW9kZSA9IGF1 dG9mczRfb3pfbW9kZShzYmkpOwotCURQUklOVEsoKCJhdXRvZnNfbG9va3VwOiBwaWQgPSAldSwg cGdycCA9ICV1LCBjYXRhdG9uaWMgPSAlZCwgb3pfbW9kZSA9ICVkXG4iLAorCisJRFBSSU5USygo ImF1dG9mczRfcm9vdF9sb29rdXA6IHBpZCA9ICV1LCBwZ3JwID0gJXUsIGNhdGF0b25pYyA9ICVk LCBvel9tb2RlID0gJWRcbiIsCiAJCSBjdXJyZW50LT5waWQsIGN1cnJlbnQtPnBncnAsIHNiaS0+ Y2F0YXRvbmljLCBvel9tb2RlKSk7CiAKIAkvKgpAQCAtMzEzLDcgKzYzOCw3IEBACiAJc3RydWN0 IGlub2RlICppbm9kZTsKIAljaGFyICpjcDsKIAotCURQUklOVEsoKCJhdXRvZnNfZGlyX3N5bWxp bms6ICVzIDwtICUuKnNcbiIsIHN5bW5hbWUsIAorCURQUklOVEsoKCJhdXRvZnM0X2Rpcl9zeW1s aW5rOiAlcyA8LSAlLipzXG4iLCBzeW1uYW1lLCAKIAkJIGRlbnRyeS0+ZF9uYW1lLmxlbiwgZGVu dHJ5LT5kX25hbWUubmFtZSkpOwogCiAJaWYgKCFhdXRvZnM0X296X21vZGUoc2JpKSkKQEAgLTM2 Myw3ICs2ODgsNyBAQAogICogSWYgYSBwcm9jZXNzIGlzIGJsb2NrZWQgb24gdGhlIGRlbnRyeSB3 YWl0aW5nIGZvciB0aGUgZXhwaXJlIHRvIGZpbmlzaCwKICAqIGl0IHdpbGwgaW52YWxpZGF0ZSB0 aGUgZGVudHJ5IGFuZCB0cnkgdG8gbW91bnQgd2l0aCBhIG5ldyBvbmUuCiAgKgotICogQWxzbyBz ZWUgYXV0b2ZzX2Rpcl9ybWRpcigpLi4gCisgKiBBbHNvIHNlZSBhdXRvZnM0X2Rpcl9ybWRpcigp Li4gCiAgKi8KIHN0YXRpYyBpbnQgYXV0b2ZzNF9kaXJfdW5saW5rKHN0cnVjdCBpbm9kZSAqZGly LCBzdHJ1Y3QgZGVudHJ5ICpkZW50cnkpCiB7CkBAIC00MTMsOCArNzM4LDYgQEAKIAlyZXR1cm4g MDsKIH0KIAotCi0KIHN0YXRpYyBpbnQgYXV0b2ZzNF9kaXJfbWtkaXIoc3RydWN0IGlub2RlICpk aXIsIHN0cnVjdCBkZW50cnkgKmRlbnRyeSwgaW50IG1vZGUpCiB7CiAJc3RydWN0IGF1dG9mc19z Yl9pbmZvICpzYmkgPSBhdXRvZnM0X3NiaShkaXItPmlfc2IpOwpAQCAtNDI0LDcgKzc0Nyw3IEBA CiAJaWYgKCAhYXV0b2ZzNF9vel9tb2RlKHNiaSkgKQogCQlyZXR1cm4gLUVBQ0NFUzsKIAotCURQ UklOVEsoKCJhdXRvZnNfZGlyX21rZGlyOiBkZW50cnkgJXAsIGNyZWF0aW5nICUuKnNcbiIsCisJ RFBSSU5USygoImF1dG9mczRfZGlyX21rZGlyOiBkZW50cnkgJXAsIGNyZWF0aW5nICUuKnNcbiIs CiAJCSBkZW50cnksIGRlbnRyeS0+ZF9uYW1lLmxlbiwgZGVudHJ5LT5kX25hbWUubmFtZSkpOwog CiAJaW5vID0gYXV0b2ZzNF9pbml0X2lubyhpbm8sIHNiaSwgU19JRkRJUiB8IDA1NTUpOwpAQCAt NDQ4LDYgKzc3MSwxOSBAQAogCXJldHVybiAwOwogfQogCisvKiAKKyAqIElkZW50aWZ5IGF1dG9m c19kZW50cmllcyAtIHRoaXMgaXMgc28gd2UgY2FuIHRlbGwgaWYgdGhlcmUncworICogYW4gZXh0 cmEgZGVudHJ5IHJlZmNvdW50IG9yIG5vdC4gIFdlIG9ubHkgaG9sZCBhIHJlZmNvdW50IG9uIHRo ZQorICogZGVudHJ5IGlmIGl0cyBub24tbmVnYXRpdmUgKGllLCBkX2lub2RlICE9IE5VTEwpCisg Ki8KK2ludCBpc19hdXRvZnM0X2RlbnRyeShzdHJ1Y3QgZGVudHJ5ICpkZW50cnkpCit7CisJcmV0 dXJuIGRlbnRyeSAmJiBkZW50cnktPmRfaW5vZGUgJiYKKwkJKGRlbnRyeS0+ZF9vcCA9PSAmYXV0 b2ZzNF9yb290X2RlbnRyeV9vcGVyYXRpb25zIHx8CisJCSBkZW50cnktPmRfb3AgPT0gJmF1dG9m czRfZGVudHJ5X29wZXJhdGlvbnMpICYmCisJCWRlbnRyeS0+ZF9mc2RhdGEgIT0gTlVMTDsKK30K KwogLyogR2V0L3NldCB0aW1lb3V0IGlvY3RsKCkgb3BlcmF0aW9uICovCiBzdGF0aWMgaW5saW5l IGludCBhdXRvZnM0X2dldF9zZXRfdGltZW91dChzdHJ1Y3QgYXV0b2ZzX3NiX2luZm8gKnNiaSwK IAkJCQkJIHVuc2lnbmVkIGxvbmcgKnApCkBAIC00NzMsMTYgKzgwOSw2NSBAQAogCXJldHVybiBw dXRfdXNlcihzYmktPnZlcnNpb24sIHApOwogfQogCi0vKiBJZGVudGlmeSBhdXRvZnNfZGVudHJp ZXMgLSB0aGlzIGlzIHNvIHdlIGNhbiB0ZWxsIGlmIHRoZXJlJ3MKLSAgIGFuIGV4dHJhIGRlbnRy eSByZWZjb3VudCBvciBub3QuICBXZSBvbmx5IGhvbGQgYSByZWZjb3VudCBvbiB0aGUKLSAgIGRl bnRyeSBpZiBpdHMgbm9uLW5lZ2F0aXZlIChpZSwgZF9pbm9kZSAhPSBOVUxMKQotKi8KLWludCBp c19hdXRvZnM0X2RlbnRyeShzdHJ1Y3QgZGVudHJ5ICpkZW50cnkpCisvKiBSZXR1cm4gcHJvdG9j b2wgc3ViIHZlcnNpb24gKi8KK3N0YXRpYyBpbmxpbmUgaW50IGF1dG9mczRfZ2V0X3Byb3Rvc3Vi dmVyKHN0cnVjdCBhdXRvZnNfc2JfaW5mbyAqc2JpLCBpbnQgKnApCiB7Ci0JcmV0dXJuIGRlbnRy eSAmJiBkZW50cnktPmRfaW5vZGUgJiYKLQkJKGRlbnRyeS0+ZF9vcCA9PSAmYXV0b2ZzNF9yb290 X2RlbnRyeV9vcGVyYXRpb25zIHx8Ci0JCSBkZW50cnktPmRfb3AgPT0gJmF1dG9mczRfZGVudHJ5 X29wZXJhdGlvbnMpICYmCi0JCWRlbnRyeS0+ZF9mc2RhdGEgIT0gTlVMTDsKKwlyZXR1cm4gcHV0 X3VzZXIoc2JpLT5zdWJfdmVyc2lvbiwgcCk7Cit9CisKKy8qCisgKiBUZWxscyB0aGUgZGFlbW9u IHdoZXRoZXIgd2UgbmVlZCB0byByZWdob3N0IG9yIG5vdC4gQWxzbywgY2xlYXJzCisgKiB0aGUg cmVnaG9zdF9uZWVkZWQgZmxhZy4KKyAqLworc3RhdGljIGlubGluZSBpbnQgYXV0b2ZzNF9hc2tf cmVnaG9zdChzdHJ1Y3QgYXV0b2ZzX3NiX2luZm8gKnNiaSwgaW50ICpwKQoreworCWludCBzdGF0 dXM7CisKKwlEUFJJTlRLKCgiYXV0b2ZzX2Fza19yZWdob3N0OiByZXR1cm5pbmcgJWRcbiIsIHNi aS0+bmVlZHNfcmVnaG9zdCkpOworCisJc3RhdHVzID0gcHV0X3VzZXIoc2JpLT5uZWVkc19yZWdo b3N0LCBwKTsKKwlpZiAoIHN0YXR1cyApCisJCXJldHVybiBzdGF0dXM7CisKKwkgc2JpLT5uZWVk c19yZWdob3N0ID0gMDsKKwkgcmV0dXJuIDA7Cit9CisKKy8qCisgKiBFbmFibGUgLyBEaXNhYmxl IHJlZ2hvc3RpbmcgaW9jdGwoKSBvcGVyYXRpb24KKyAqLworc3RhdGljIGlubGluZSBpbnQgYXV0 b2ZzNF90b2dnbGVfcmVnaG9zdChzdHJ1Y3QgYXV0b2ZzX3NiX2luZm8gKnNiaSwgaW50ICpwKQor eworCWludCBzdGF0dXM7CisJaW50IHZhbDsKKworCXN0YXR1cyA9IGdldF91c2VyKHZhbCwgcCk7 CisKKwlEUFJJTlRLKCgiYXV0b2ZzNF90b2dnbGVfcmVnaG9zdDogcmVnaG9zdCA9ICVkXG4iLCB2 YWwpKTsKKworCWlmIChzdGF0dXMpCisJCXJldHVybiBzdGF0dXM7CisKKwkvKiB0dXJuIG9uL29m ZiByZWdob3N0aW5nLCB3aXRoIHRoZSB2YWwgKi8KKwlzYmktPnJlZ2hvc3RfZW5hYmxlZCA9IHZh bDsKKwlyZXR1cm4gMDsKK30KKworLyoKKyAqIFRlbGxzIHRoZSBkYWVtb24gd2hldGhlciB3ZSBj YW4gdW1hb250IHRoZSBhdXRvZnMgbW91bnQuCisgKi8KK3N0YXRpYyBpbmxpbmUgaW50IGF1dG9m czRfYXNrX3Vtb3VudChzdHJ1Y3QgdmZzbW91bnQgKm1udCwgaW50ICpwKQoreworCWludCBzdGF0 dXMgPSAwOworCisJaWYgKG1heV91bW91bnQobW50KSA9PSAwKQorCQlzdGF0dXMgPSAxOworCisJ RFBSSU5USygoImF1dG9mc19hc2tfdW1vdW50OiByZXR1cm5pbmcgJWRcbiIsIHN0YXR1cykpOwor CisJc3RhdHVzID0gcHV0X3VzZXIoc3RhdHVzLCBwKTsKKworCXJldHVybiBzdGF0dXM7CiB9CiAK IC8qCkBAIC00OTQsNyArODc5LDcgQEAKIHsKIAlzdHJ1Y3QgYXV0b2ZzX3NiX2luZm8gKnNiaSA9 IGF1dG9mczRfc2JpKGlub2RlLT5pX3NiKTsKIAotCURQUklOVEsoKCJhdXRvZnNfaW9jdGw6IGNt ZCA9IDB4JTA4eCwgYXJnID0gMHglMDhseCwgc2JpID0gJXAsIHBncnAgPSAldVxuIiwKKwlEUFJJ TlRLKCgiYXV0b2ZzNF9pb2N0bDogY21kID0gMHglMDh4LCBhcmcgPSAweCUwOGx4LCBzYmkgPSAl cCwgcGdycCA9ICV1XG4iLAogCQkgY21kLGFyZyxzYmksY3VycmVudC0+cGdycCkpOwogCiAJaWYg KCBfSU9DX1RZUEUoY21kKSAhPSBfSU9DX1RZUEUoQVVUT0ZTX0lPQ19GSVJTVCkgfHwKQEAgLTUw NSwyOCArODkwLDQ3IEBACiAJCXJldHVybiAtRVBFUk07CiAJCiAJc3dpdGNoKGNtZCkgewotCWNh c2UgQVVUT0ZTX0lPQ19SRUFEWToJLyogV2FpdCBxdWV1ZTogZ28gYWhlYWQgYW5kIHJldHJ5ICov Ci0JCXJldHVybiBhdXRvZnM0X3dhaXRfcmVsZWFzZShzYmksKGF1dG9mc193cXRfdClhcmcsMCk7 Ci0JY2FzZSBBVVRPRlNfSU9DX0ZBSUw6CS8qIFdhaXQgcXVldWU6IGZhaWwgd2l0aCBFTk9FTlQg Ki8KLQkJcmV0dXJuIGF1dG9mczRfd2FpdF9yZWxlYXNlKHNiaSwoYXV0b2ZzX3dxdF90KWFyZywt RU5PRU5UKTsKLQljYXNlIEFVVE9GU19JT0NfQ0FUQVRPTklDOiAvKiBFbnRlciBjYXRhdG9uaWMg bW9kZSAoZGFlbW9uIHNodXRkb3duKSAqLwotCQlhdXRvZnM0X2NhdGF0b25pY19tb2RlKHNiaSk7 Ci0JCXJldHVybiAwOwotCWNhc2UgQVVUT0ZTX0lPQ19QUk9UT1ZFUjogLyogR2V0IHByb3RvY29s IHZlcnNpb24gKi8KLQkJcmV0dXJuIGF1dG9mczRfZ2V0X3Byb3RvdmVyKHNiaSwgKGludCAqKWFy Zyk7Ci0JY2FzZSBBVVRPRlNfSU9DX1NFVFRJTUVPVVQ6Ci0JCXJldHVybiBhdXRvZnM0X2dldF9z ZXRfdGltZW91dChzYmksKHVuc2lnbmVkIGxvbmcgKilhcmcpOwotCi0JLyogcmV0dXJuIGEgc2lu Z2xlIHRoaW5nIHRvIGV4cGlyZSAqLwotCWNhc2UgQVVUT0ZTX0lPQ19FWFBJUkU6Ci0JCXJldHVy biBhdXRvZnM0X2V4cGlyZV9ydW4oaW5vZGUtPmlfc2IsZmlscC0+Zl92ZnNtbnQsc2JpLAotCQkJ CQkgIChzdHJ1Y3QgYXV0b2ZzX3BhY2tldF9leHBpcmUgKilhcmcpOwotCS8qIHNhbWUgYXMgYWJv dmUsIGJ1dCBjYW4gc2VuZCBtdWx0aXBsZSBleHBpcmVzIHRocm91Z2ggcGlwZSAqLwotCWNhc2Ug QVVUT0ZTX0lPQ19FWFBJUkVfTVVMVEk6Ci0JCXJldHVybiBhdXRvZnM0X2V4cGlyZV9tdWx0aShp bm9kZS0+aV9zYixmaWxwLT5mX3Zmc21udCxzYmksCi0JCQkJCSAgICAoaW50ICopYXJnKTsKKwkJ Y2FzZSBBVVRPRlNfSU9DX1JFQURZOgkvKiBXYWl0IHF1ZXVlOiBnbyBhaGVhZCBhbmQgcmV0cnkg Ki8KKwkJCXJldHVybiBhdXRvZnM0X3dhaXRfcmVsZWFzZShzYmksIChhdXRvZnNfd3F0X3QpYXJn LCAwKTsKKworCQljYXNlIEFVVE9GU19JT0NfRkFJTDoJLyogV2FpdCBxdWV1ZTogZmFpbCB3aXRo IEVOT0VOVCAqLworCQkJcmV0dXJuIGF1dG9mczRfd2FpdF9yZWxlYXNlKHNiaSwgKGF1dG9mc193 cXRfdClhcmcsIC1FTk9FTlQpOworCisJCWNhc2UgQVVUT0ZTX0lPQ19DQVRBVE9OSUM6IC8qIEVu dGVyIGNhdGF0b25pYyBtb2RlIChkYWVtb24gc2h1dGRvd24pICovCisJCQlhdXRvZnM0X2NhdGF0 b25pY19tb2RlKHNiaSk7CisJCQlyZXR1cm4gMDsKKworCQljYXNlIEFVVE9GU19JT0NfUFJPVE9W RVI6IC8qIEdldCBwcm90b2NvbCB2ZXJzaW9uICovCisJCQlyZXR1cm4gYXV0b2ZzNF9nZXRfcHJv dG92ZXIoc2JpLCAoaW50ICopYXJnKTsKKworCQljYXNlIEFVVE9GU19JT0NfUFJPVE9TVUJWRVI6 IC8qIEdldCBwcm90b2NvbCBzdWIgdmVyc2lvbiAqLworCQkJcmV0dXJuIGF1dG9mczRfZ2V0X3By b3Rvc3VidmVyKHNiaSwgKGludCAqKSBhcmcpOworCisJCWNhc2UgQVVUT0ZTX0lPQ19TRVRUSU1F T1VUOgorCQkJcmV0dXJuIGF1dG9mczRfZ2V0X3NldF90aW1lb3V0KHNiaSwgKHVuc2lnbmVkIGxv bmcgKikgYXJnKTsKKworCQljYXNlIEFVVE9GU19JT0NfVE9HR0xFUkVHSE9TVDoKKwkJCXJldHVy biBhdXRvZnM0X3RvZ2dsZV9yZWdob3N0KHNiaSwgKGludCAqKSBhcmcpOworCisJCWNhc2UgQVVU T0ZTX0lPQ19BU0tSRUdIT1NUOgorCQkJcmV0dXJuIGF1dG9mczRfYXNrX3JlZ2hvc3Qoc2JpLCAo aW50ICopIGFyZyk7CisKKwkJY2FzZSBBVVRPRlNfSU9DX0FTS1VNT1VOVDoKKwkJCXJldHVybiBh dXRvZnM0X2Fza191bW91bnQoZmlscC0+Zl92ZnNtbnQsIChpbnQgKikgYXJnKTsKKworCQkvKiBy ZXR1cm4gYSBzaW5nbGUgdGhpbmcgdG8gZXhwaXJlICovCisJCWNhc2UgQVVUT0ZTX0lPQ19FWFBJ UkU6CisJCQlyZXR1cm4gYXV0b2ZzNF9leHBpcmVfcnVuKAorCQkJCWlub2RlLT5pX3NiLCBmaWxw LT5mX3Zmc21udCwgc2JpLAorCQkJIAkoc3RydWN0IGF1dG9mc19wYWNrZXRfZXhwaXJlICopYXJn KTsKKworCQkvKiBzYW1lIGFzIGFib3ZlLCBidXQgY2FuIHNlbmQgbXVsdGlwbGUgZXhwaXJlcyB0 aHJvdWdoIHBpcGUgKi8KKwkJY2FzZSBBVVRPRlNfSU9DX0VYUElSRV9NVUxUSToKKwkJCXJldHVy biBhdXRvZnM0X2V4cGlyZV9tdWx0aShpbm9kZS0+aV9zYiwKKwkJCQkJCWZpbHAtPmZfdmZzbW50 LAorCQkJCQkJc2JpLCAoaW50ICopIGFyZyk7CiAKLQlkZWZhdWx0OgotCQlyZXR1cm4gLUVOT1NZ UzsKKwkJZGVmYXVsdDoKKwkJCXJldHVybiAtRU5PU1lTOwogCX0KIH0KZGlmZiAtTmF1ciAtLWV4 Y2x1ZGUtZnJvbT1leGNsdWRlLWZpbGVzIDIuNC4yNHByZS1hdXRvZnMvZnMvYXV0b2ZzNC93YWl0 cS5jIDIuNC4yNHBvc3QtYXV0b2ZzL2ZzL2F1dG9mczQvd2FpdHEuYwotLS0gMi40LjI0cHJlLWF1 dG9mcy9mcy9hdXRvZnM0L3dhaXRxLmMJMjAwMS0wMi0wOSAxNDoyOTo0NC4wMDAwMDAwMDAgLTA1 MDAKKysrIDIuNC4yNHBvc3QtYXV0b2ZzL2ZzL2F1dG9mczQvd2FpdHEuYwkyMDA0LTAxLTE3IDA3 OjMxOjAwLjAwMDAwMDAwMCAtMDUwMApAQCAtMyw2ICszLDcgQEAKICAqIGxpbnV4L2ZzL2F1dG9m cy93YWl0cS5jCiAgKgogICogIENvcHlyaWdodCAxOTk3LTE5OTggVHJhbnNtZXRhIENvcnBvcmF0 aW9uIC0tIEFsbCBSaWdodHMgUmVzZXJ2ZWQKKyAqICBDb3B5cmlnaHQgMjAwMS0yMDAzIElhbiBL ZW50IDxyYXZlbkB0aGVtYXcubmV0PgogICoKICAqIFRoaXMgZmlsZSBpcyBwYXJ0IG9mIHRoZSBM aW51eCBrZXJuZWwgYW5kIGlzIG1hZGUgYXZhaWxhYmxlIHVuZGVyCiAgKiB0aGUgdGVybXMgb2Yg dGhlIEdOVSBHZW5lcmFsIFB1YmxpYyBMaWNlbnNlLCB2ZXJzaW9uIDIsIG9yIGF0IHlvdXIKQEAg LTI3LDcgKzI4LDcgQEAKIHsKIAlzdHJ1Y3QgYXV0b2ZzX3dhaXRfcXVldWUgKndxLCAqbndxOwog Ci0JRFBSSU5USygoImF1dG9mczogZW50ZXJpbmcgY2F0YXRvbmljIG1vZGVcbiIpKTsKKwlEUFJJ TlRLKCgiYXV0b2ZzNDogZW50ZXJpbmcgY2F0YXRvbmljIG1vZGVcbiIpKTsKIAogCXNiaS0+Y2F0 YXRvbmljID0gMTsKIAl3cSA9IHNiaS0+cXVldWVzOwpAQCAtMzUsOSArMzYsMTEgQEAKIAl3aGls ZSAoIHdxICkgewogCQlud3EgPSB3cS0+bmV4dDsKIAkJd3EtPnN0YXR1cyA9IC1FTk9FTlQ7IC8q IE1hZ2ljIGlzIGdvbmUgLSByZXBvcnQgZmFpbHVyZSAqLwotCQlrZnJlZSh3cS0+bmFtZSk7Ci0J CXdxLT5uYW1lID0gTlVMTDsKLQkJd2FrZV91cCgmd3EtPnF1ZXVlKTsKKwkJaWYgKCB3cS0+bmFt ZSApIHsKKwkJCWtmcmVlKHdxLT5uYW1lKTsKKwkJCXdxLT5uYW1lID0gTlVMTDsKKwkJfQorCQl3 YWtlX3VwX2ludGVycnVwdGlibGUoJndxLT5xdWV1ZSk7CiAJCXdxID0gbndxOwogCX0KIAlpZiAo c2JpLT5waXBlKSB7CkBAIC05MCw4ICs5Myw4IEBACiAJdW5pb24gYXV0b2ZzX3BhY2tldF91bmlv biBwa3Q7CiAJc2l6ZV90IHBrdHN6OwogCi0JRFBSSU5USygoImF1dG9mc19ub3RpZnk6IHdhaXQg aWQgPSAweCUwOGx4LCBuYW1lID0gJS4qcywgdHlwZT0lZFxuIiwKLQkJIHdxLT53YWl0X3F1ZXVl X3Rva2VuLCB3cS0+bGVuLCB3cS0+bmFtZSwgdHlwZSkpOworCURQUklOVEsoKCJhdXRvZnM0X25v dGlmeTogd2FpdCBpZCA9IDB4JTA4bHgsIG5hbWUgPSAlLipzLCB0eXBlPSVkXG4iLAorCQkodW5z aWduZWQgbG9uZykgd3EtPndhaXRfcXVldWVfdG9rZW4sIHdxLT5sZW4sIHdxLT5uYW1lLCB0eXBl KSk7CiAKIAltZW1zZXQoJnBrdCwwLHNpemVvZiBwa3QpOyAvKiBGb3Igc2VjdXJpdHkgcmVhc29u cyAqLwogCkBAIC0xMTYsNyArMTE5LDcgQEAKIAkJbWVtY3B5KGVwLT5uYW1lLCB3cS0+bmFtZSwg d3EtPmxlbik7CiAJCWVwLT5uYW1lW3dxLT5sZW5dID0gJ1wwJzsKIAl9IGVsc2UgewotCQlwcmlu dGsoImF1dG9mc19ub3RpZnlfZGFlbW9uOiBiYWQgdHlwZSAlZCFcbiIsIHR5cGUpOworCQlwcmlu dGsoImF1dG9mczRfbm90aWZ5X2RhZW1vbjogYmFkIHR5cGUgJWQhXG4iLCB0eXBlKTsKIAkJcmV0 dXJuOwogCX0KIApAQCAtMTI0LDYyICsxMjcsMTAxIEBACiAJCWF1dG9mczRfY2F0YXRvbmljX21v ZGUoc2JpKTsKIH0KIAotaW50IGF1dG9mczRfd2FpdChzdHJ1Y3QgYXV0b2ZzX3NiX2luZm8gKnNi aSwgc3RydWN0IHFzdHIgKm5hbWUsCitzdGF0aWMgaW50IGF1dG9mczRfZ2V0cGF0aChzdHJ1Y3Qg YXV0b2ZzX3NiX2luZm8gKnNiaSwKKwkJCSAgIHN0cnVjdCBkZW50cnkgKmRlbnRyeSwgY2hhciAq Km5hbWUpCit7CisJc3RydWN0IGRlbnRyeSAqcm9vdCA9IHNiaS0+c2ItPnNfcm9vdDsKKwlzdHJ1 Y3QgZGVudHJ5ICp0bXA7CisJY2hhciAqYnVmID0gKm5hbWU7CisJY2hhciAqcDsKKwlpbnQgbGVu ID0gMDsKKworCXNwaW5fbG9jaygmZGNhY2hlX2xvY2spOworCWZvciAodG1wID0gZGVudHJ5IDsg dG1wICE9IHJvb3QgOyB0bXAgPSB0bXAtPmRfcGFyZW50KQorCQlsZW4gKz0gdG1wLT5kX25hbWUu bGVuICsgMTsKKworCWlmICgtLWxlbiA+IE5BTUVfTUFYKSB7CisJCXNwaW5fdW5sb2NrKCZkY2Fj aGVfbG9jayk7CisJCXJldHVybiAwOworCX0KKworCSooYnVmICsgbGVuKSA9ICdcMCc7CisJcCA9 IGJ1ZiArIGxlbiAtIGRlbnRyeS0+ZF9uYW1lLmxlbjsKKwlzdHJuY3B5KHAsIGRlbnRyeS0+ZF9u YW1lLm5hbWUsIGRlbnRyeS0+ZF9uYW1lLmxlbik7CisKKwlmb3IgKHRtcCA9IGRlbnRyeS0+ZF9w YXJlbnQ7IHRtcCAhPSByb290IDsgdG1wID0gdG1wLT5kX3BhcmVudCkgeworCQkqKC0tcCkgPSAn Lyc7CisJCXAgLT0gdG1wLT5kX25hbWUubGVuOworCQlzdHJuY3B5KHAsIHRtcC0+ZF9uYW1lLm5h bWUsIHRtcC0+ZF9uYW1lLmxlbik7CisJfQorLyoJKm5hbWUgPSBidWY7ICovCisJc3Bpbl91bmxv Y2soJmRjYWNoZV9sb2NrKTsKKworCXJldHVybiBsZW47Cit9CisKK2ludCBhdXRvZnM0X3dhaXQo c3RydWN0IGF1dG9mc19zYl9pbmZvICpzYmksIHN0cnVjdCBkZW50cnkgKmRlbnRyeSwKIAkJZW51 bSBhdXRvZnNfbm90aWZ5IG5vdGlmeSkKIHsKIAlzdHJ1Y3QgYXV0b2ZzX3dhaXRfcXVldWUgKndx OwotCWludCBzdGF0dXM7CisJY2hhciAqbmFtZTsKKwlpbnQgbGVuLCBzdGF0dXM7CiAKIAkvKiBJ biBjYXRhdG9uaWMgbW9kZSwgd2UgZG9uJ3Qgd2FpdCBmb3Igbm9ib2R5ICovCi0JaWYgKCBzYmkt PmNhdGF0b25pYyApCisJaWYgKHNiaS0+Y2F0YXRvbmljKQogCQlyZXR1cm4gLUVOT0VOVDsKLQkK LQkvKiBXZSBzaG91bGRuJ3QgYmUgYWJsZSB0byBnZXQgaGVyZSwgYnV0IGp1c3QgaW4gY2FzZSAq LwotCWlmICggbmFtZS0+bGVuID4gTkFNRV9NQVggKQorCisJbmFtZSA9IGttYWxsb2MoTkFNRV9N QVggKyAxLCBHRlBfS0VSTkVMKTsKKwlpZiAoIW5hbWUpCisJCXJldHVybiAtRU5PTUVNOworCisJ bGVuID0gYXV0b2ZzNF9nZXRwYXRoKHNiaSwgZGVudHJ5LCAmbmFtZSk7CisJaWYgKCFsZW4pIHsK KwkJa2ZyZWUobmFtZSk7CiAJCXJldHVybiAtRU5PRU5UOworCX0KIAogCWZvciAoIHdxID0gc2Jp LT5xdWV1ZXMgOyB3cSA7IHdxID0gd3EtPm5leHQgKSB7Ci0JCWlmICggd3EtPmhhc2ggPT0gbmFt ZS0+aGFzaCAmJgotCQkgICAgIHdxLT5sZW4gPT0gbmFtZS0+bGVuICYmCi0JCSAgICAgd3EtPm5h bWUgJiYgIW1lbWNtcCh3cS0+bmFtZSxuYW1lLT5uYW1lLG5hbWUtPmxlbikgKQorCQlpZiAoIHdx LT5oYXNoID09IGRlbnRyeS0+ZF9uYW1lLmhhc2ggJiYKKwkJICAgICB3cS0+bGVuID09IGxlbiAm JgorCQkgICAgIHdxLT5uYW1lICYmICFtZW1jbXAod3EtPm5hbWUsIG5hbWUsIGxlbikgKQogCQkJ YnJlYWs7CiAJfQogCQogCWlmICggIXdxICkgewogCQkvKiBDcmVhdGUgYSBuZXcgd2FpdCBxdWV1 ZSAqLwotCQl3cSA9IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCBhdXRvZnNfd2FpdF9xdWV1ZSksR0ZQ X0tFUk5FTCk7Ci0JCWlmICggIXdxICkKLQkJCXJldHVybiAtRU5PTUVNOwotCi0JCXdxLT5uYW1l ID0ga21hbGxvYyhuYW1lLT5sZW4sR0ZQX0tFUk5FTCk7Ci0JCWlmICggIXdxLT5uYW1lICkgewot CQkJa2ZyZWUod3EpOworCQl3cSA9IGttYWxsb2Moc2l6ZW9mKHN0cnVjdCBhdXRvZnNfd2FpdF9x dWV1ZSksIEdGUF9LRVJORUwpOworCQlpZiAoICF3cSApIHsKKwkJCWtmcmVlKG5hbWUpOwogCQkJ cmV0dXJuIC1FTk9NRU07CiAJCX0KKwogCQl3cS0+d2FpdF9xdWV1ZV90b2tlbiA9IGF1dG9mczRf bmV4dF93YWl0X3F1ZXVlOwogCQlpZiAoKythdXRvZnM0X25leHRfd2FpdF9xdWV1ZSA9PSAwKQog CQkJYXV0b2ZzNF9uZXh0X3dhaXRfcXVldWUgPSAxOwogCQlpbml0X3dhaXRxdWV1ZV9oZWFkKCZ3 cS0+cXVldWUpOwotCQl3cS0+aGFzaCA9IG5hbWUtPmhhc2g7Ci0JCXdxLT5sZW4gPSBuYW1lLT5s ZW47CisJCXdxLT5vd25lciA9IGN1cnJlbnQ7CisJCXdxLT5oYXNoID0gZGVudHJ5LT5kX25hbWUu aGFzaDsKKwkJd3EtPm5hbWUgPSBuYW1lOworCQl3cS0+bGVuID0gbGVuOwogCQl3cS0+c3RhdHVz ID0gLUVJTlRSOyAvKiBTdGF0dXMgcmV0dXJuIGlmIGludGVycnVwdGVkICovCi0JCW1lbWNweSh3 cS0+bmFtZSwgbmFtZS0+bmFtZSwgbmFtZS0+bGVuKTsKIAkJd3EtPm5leHQgPSBzYmktPnF1ZXVl czsKIAkJc2JpLT5xdWV1ZXMgPSB3cTsKIAotCQlEUFJJTlRLKCgiYXV0b2ZzX3dhaXQ6IG5ldyB3 YWl0IGlkID0gMHglMDhseCwgbmFtZSA9ICUuKnMsIG5meT0lZFxuIiwKLQkJCSB3cS0+d2FpdF9x dWV1ZV90b2tlbiwgd3EtPmxlbiwgd3EtPm5hbWUsIG5vdGlmeSkpOworCQlEUFJJTlRLKCgiYXV0 b2ZzNF93YWl0OiBuZXcgd2FpdCBpZCA9IDB4JTA4bHgsIG5hbWUgPSAlLipzLCBuZnk9JWRcbiIs CisJCQkodW5zaWduZWQgbG9uZykgd3EtPndhaXRfcXVldWVfdG9rZW4sIHdxLT5sZW4sIHdxLT5u YW1lLCBub3RpZnkpKTsKIAkJLyogYXV0b2ZzNF9ub3RpZnlfZGFlbW9uKCkgbWF5IGJsb2NrICov CiAJCXdxLT53YWl0X2N0ciA9IDI7CiAJCWlmIChub3RpZnkgIT0gTkZZX05PTkUpIHsKIAkJCWF1 dG9mczRfbm90aWZ5X2RhZW1vbihzYmksd3EsIAotCQkJCQkgICAgICBub3RpZnkgPT0gTkZZX01P VU5UID8gYXV0b2ZzX3B0eXBlX21pc3NpbmcgOgotCQkJCQkJCQkgICAgYXV0b2ZzX3B0eXBlX2V4 cGlyZV9tdWx0aSk7CisJCQkJbm90aWZ5ID09IE5GWV9NT1VOVCA/IAorCQkJCQlhdXRvZnNfcHR5 cGVfbWlzc2luZyA6CisJCQkJICAgICAgIAlhdXRvZnNfcHR5cGVfZXhwaXJlX211bHRpKTsKIAkJ fQogCX0gZWxzZSB7CiAJCXdxLT53YWl0X2N0cisrOwotCQlEUFJJTlRLKCgiYXV0b2ZzX3dhaXQ6 IGV4aXN0aW5nIHdhaXQgaWQgPSAweCUwOGx4LCBuYW1lID0gJS4qcywgbmZ5PSVkXG4iLAotCQkJ IHdxLT53YWl0X3F1ZXVlX3Rva2VuLCB3cS0+bGVuLCB3cS0+bmFtZSwgbm90aWZ5KSk7CisJCURQ UklOVEsoKCJhdXRvZnM0X3dhaXQ6IGV4aXN0aW5nIHdhaXQgaWQgPSAweCUwOGx4LCBuYW1lID0g JS4qcywgbmZ5PSVkXG4iLAorCQkJKHVuc2lnbmVkIGxvbmcpIHdxLT53YWl0X3F1ZXVlX3Rva2Vu LCB3cS0+bGVuLCB3cS0+bmFtZSwgbm90aWZ5KSk7CiAJfQogCiAJLyogd3EtPm5hbWUgaXMgTlVM TCBpZiBhbmQgb25seSBpZiB0aGUgbG9jayBpcyBhbHJlYWR5IHJlbGVhc2VkICovCkBAIC0yMDQs NyArMjQ2LDEyIEBACiAJCXJlY2FsY19zaWdwZW5kaW5nKGN1cnJlbnQpOwogCQlzcGluX3VubG9j a19pcnFyZXN0b3JlKCZjdXJyZW50LT5zaWdtYXNrX2xvY2ssIGlycWZsYWdzKTsKIAotCQlpbnRl cnJ1cHRpYmxlX3NsZWVwX29uKCZ3cS0+cXVldWUpOworCQl3YWl0X2V2ZW50X2ludGVycnVwdGli bGUod3EtPnF1ZXVlLCB3cS0+bmFtZSA9PSBOVUxMKTsKKworCQlpZiAod2FpdHF1ZXVlX2FjdGl2 ZSgmd3EtPnF1ZXVlKSAmJiBjdXJyZW50ICE9IHdxLT5vd25lcikgeworCQkJc2V0X2N1cnJlbnRf c3RhdGUoVEFTS19JTlRFUlJVUFRJQkxFKTsKKwkJCXNjaGVkdWxlX3RpbWVvdXQoSFovMTApOwor CQl9CiAKIAkJc3Bpbl9sb2NrX2lycXNhdmUoJmN1cnJlbnQtPnNpZ21hc2tfbG9jaywgaXJxZmxh Z3MpOwogCQljdXJyZW50LT5ibG9ja2VkID0gb2xkc2V0OwpAQCAtMjQzLDcgKzI5MCw3IEBACiAJ aWYgKC0td3EtPndhaXRfY3RyID09IDApCS8qIElzIGFueW9uZSBzdGlsbCB3YWl0aW5nIGZvciB0 aGlzIGd1eT8gKi8KIAkJa2ZyZWUod3EpOwogCWVsc2UKLQkJd2FrZV91cCgmd3EtPnF1ZXVlKTsK KwkJd2FrZV91cF9pbnRlcnJ1cHRpYmxlKCZ3cS0+cXVldWUpOwogCiAJcmV0dXJuIDA7CiB9CmRp ZmYgLU5hdXIgLS1leGNsdWRlLWZyb209ZXhjbHVkZS1maWxlcyAyLjQuMjRwcmUtYXV0b2ZzL2lu Y2x1ZGUvbGludXgvYXV0b19mczQuaCAyLjQuMjRwb3N0LWF1dG9mcy9pbmNsdWRlL2xpbnV4L2F1 dG9fZnM0LmgKLS0tIDIuNC4yNHByZS1hdXRvZnMvaW5jbHVkZS9saW51eC9hdXRvX2ZzNC5oCTIw MDQtMDEtMTQgMTY6MTk6NDQuMDAwMDAwMDAwIC0wNTAwCisrKyAyLjQuMjRwb3N0LWF1dG9mcy9p bmNsdWRlL2xpbnV4L2F1dG9fZnM0LmgJMjAwNC0wMS0xNyAwNzozMTowMC4wMDAwMDAwMDAgLTA1 MDAKQEAgLTIzLDYgKzIzLDEyIEBACiAjZGVmaW5lIEFVVE9GU19NSU5fUFJPVE9fVkVSU0lPTgkz CiAjZGVmaW5lIEFVVE9GU19NQVhfUFJPVE9fVkVSU0lPTgk0CiAKKyNkZWZpbmUgQVVUT0ZTX1BS T1RPX1NVQlZFUlNJT04JCTQKKworLyogTWFzayBmb3IgZXhwaXJlIGJlaGF2aW91ciAqLworI2Rl ZmluZSBBVVRPRlNfRVhQX0lNTUVESUFURSAgICAgICAgICAgIDEKKyNkZWZpbmUgQVVUT0ZTX0VY UF9MRUFWRVMgICAgICAgICAgICAgICAyCisKIC8qIE5ldyBtZXNzYWdlIHR5cGUgKi8KICNkZWZp bmUgYXV0b2ZzX3B0eXBlX2V4cGlyZV9tdWx0aQkyCS8qIEV4cGlyZSBlbnRyeSAodW1vdW50IHJl cXVlc3QpICovCiAKQEAgLTQxLDcgKzQ3LDEwIEBACiAJc3RydWN0IGF1dG9mc19wYWNrZXRfZXhw aXJlX211bHRpIGV4cGlyZV9tdWx0aTsKIH07CiAKLSNkZWZpbmUgQVVUT0ZTX0lPQ19FWFBJUkVf TVVMVEkgX0lPVygweDkzLDB4NjYsaW50KQotCisjZGVmaW5lIEFVVE9GU19JT0NfRVhQSVJFX01V TFRJCQlfSU9XKDB4OTMsMHg2NixpbnQpCisjZGVmaW5lIEFVVE9GU19JT0NfUFJPVE9TVUJWRVIJ CV9JT1IoMHg5MywweDY3LGludCkKKyNkZWZpbmUgQVVUT0ZTX0lPQ19BU0tSRUdIT1NUCQlfSU9S KDB4OTMsMHg2OCxpbnQpCisjZGVmaW5lIEFVVE9GU19JT0NfVE9HR0xFUkVHSE9TVAlfSU9SKDB4 OTMsMHg2OSxpbnQpCisjZGVmaW5lIEFVVE9GU19JT0NfQVNLVU1PVU5UCQlfSU9SKDB4OTMsMHg3 MCxpbnQpCiAKICNlbmRpZiAvKiBfTElOVVhfQVVUT19GUzRfSCAqLwpkaWZmIC1OYXVyIC0tZXhj bHVkZS1mcm9tPWV4Y2x1ZGUtZmlsZXMgMi40LjI0cHJlLWF1dG9mcy9pbmNsdWRlL2xpbnV4L2F1 dG9fZnMuaCAyLjQuMjRwb3N0LWF1dG9mcy9pbmNsdWRlL2xpbnV4L2F1dG9fZnMuaAotLS0gMi40 LjI0cHJlLWF1dG9mcy9pbmNsdWRlL2xpbnV4L2F1dG9fZnMuaAkyMDA0LTAxLTE0IDE2OjE5OjQy LjAwMDAwMDAwMCAtMDUwMAorKysgMi40LjI0cG9zdC1hdXRvZnMvaW5jbHVkZS9saW51eC9hdXRv X2ZzLmgJMjAwNC0wMS0xNyAwNzozMTowMC4wMDAwMDAwMDAgLTA1MDAKQEAgLTQ1LDcgKzQ1LDcg QEAKICAqIElmIHNvLCAzMi1iaXQgdXNlci1zcGFjZSBjb2RlIHNob3VsZCBiZSBiYWNrd2FyZHMg Y29tcGF0aWJsZS4KICAqLwogCi0jaWYgIWRlZmluZWQoX19hbHBoYV9fKSAmJiAhZGVmaW5lZChf X2lhNjRfXykgICAKKyNpZiBkZWZpbmVkKF9fc3BhcmNfXykgfHwgZGVmaW5lZChfX21pcHNfXykg fHwgZGVmaW5lZChfX3MzOTBfXykgfHwgZGVmaW5lZChfX3Bvd2VycGNfXykgfHwgZGVmaW5lZChf X3g4Nl82NF9fKQogdHlwZWRlZiB1bnNpZ25lZCBpbnQgYXV0b2ZzX3dxdF90OwogI2Vsc2UKIHR5 cGVkZWYgdW5zaWduZWQgbG9uZyBhdXRvZnNfd3F0X3Q7Cg== ------_=_NextPart_001_01C3DD78.E5D1DB5F Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs ------_=_NextPart_001_01C3DD78.E5D1DB5F-- From autofs-bounces@linux.kernel.org Sun Jan 18 17:12:45 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0J1CiHt015068 for ; Sun, 18 Jan 2004 17:12:45 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0J0W13H015119; Sun, 18 Jan 2004 16:42:20 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0J0UD3F014269 for ; Sun, 18 Jan 2004 16:31:22 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i0J0Ud527476; Mon, 19 Jan 2004 08:30:39 +0800 Date: Mon, 19 Jan 2004 08:30:39 +0800 (WST) From: Ian Kent X-X-Sender: To: "Bahi, David" Subject: Re: [autofs] direct map limitations In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-5.6, required 8, AWL, BAYES_10, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on hera.kernel.org cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Sat, 17 Jan 2004, Bahi, David wrote: > is it not possible to use direct mounts on / with > > /etc/auto.master: > > /- /etc/auto.direct > > /etc/auto.direct: > > /only host:/some/path/of/interest > > and with a running kernel that has > > > http://kernel.org/pub/linux/daemons/autofs/v4/autofs4-2.4-module-2003120 > 1.tar.bz2 > > applied to 2.4.24 > (messy as it is - > cleaner patch attached - > please check root.c in particular) > > and with an rpmbuild --rebuild of > > http://kernel.org/pub/linux/daemons/autofs/v4/autofs-4.1.0-2.src.rpm > > on boot/startup of the autofs daemon (alias autofs autofs4 in > modules.conf) > > /var/log/messages: > > cache_ghost: entry in file:/etc/auto.direct not valid map format, key > /only > > and of course 'ls /only' No such file or directory.... This is a limitation of the implementation. It has been done this way largely because of the limit in the kernel on the maximum number of anonymous mounts. > > looking at lib/cache.c it seems the logic is inverted so that the daemon > must find a /dir/ pattern so the automount daemon can 'watch over' > '/dir' > when a direct daemon needs to be able to listen over '/' too, no? > > thanks for any feedback > > db > > ps i was going to try this - but figured it would just fail miserably Yes. This will not work. Sorry you'll have to wait for a new implementation. I have no idea of when that may be. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 19 08:37:34 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0JGbYHt009898 for ; Mon, 19 Jan 2004 08:37:34 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0JFpF3H014564; Mon, 19 Jan 2004 08:01:16 -0800 Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0JFn63F013688 for ; Mon, 19 Jan 2004 07:50:34 -0800 Received: from mail.rhythm.com (rh-la-28-101.rhythm.com [24.130.28.101]) by tahoe.cinenet.net (8.12.10/8.12.10) with ESMTP id i0JFmr3a014508 for ; Mon, 19 Jan 2004 07:48:53 -0800 (PST) Received: from mailhost.rhythm.com (gw-dmz.rhythm.com [24.130.28.100]) by mail.rhythm.com (8.12.9/8.12.5) with ESMTP id i0JFmr6q011500 for ; Mon, 19 Jan 2004 07:48:53 -0800 Received: from rhythm.com (lid2.rhythm.com [10.4.7.102]) by mailhost.rhythm.com (8.12.9/8.12.5) with ESMTP id i0JFmrFs012501 for ; Mon, 19 Jan 2004 07:48:53 -0800 Message-ID: <400BFC65.3000700@rhythm.com> Date: Mon, 19 Jan 2004 07:48:53 -0800 From: Greg Bradner User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: autofs@linux.kernel.org References: <4004409C.6040900@sun.com> <40059944.4060901@rhythm.com> In-Reply-To: <40059944.4060901@rhythm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on hera.kernel.org Subject: [autofs] running out of mount points X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: I wanted to repost this plea. I am really in a bind and could use some help. I need to mount these users on the mail server. BTW: this is with autofs 4.1.0 Greg Bradner wrote: > I have run into a problem of running out of mount points. I have over > 600 users and their home dirs are listed in auto.home and they are all > stored on the same nfs server. If I list the dirs, automount will > create a seperate mount point for each user, and at ~256 mount points, > no more home dirs can be mounted. > Is there a work around? > > Here is the auto.master and snip of auto.home > > > auto.master: > /home /etc/auto.maps/auto.home > vers=3,hard,intr,nosuid,nodev,rw,retrans=4,timeo=15,mountvers=2 > > > auto.home: > gregb ntap:/vol/vol0/u/& > > _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 19 10:44:06 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0JIi5Ht015293 for ; Mon, 19 Jan 2004 10:44:05 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0JHxq3H010142; Mon, 19 Jan 2004 10:09:49 -0800 Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0JHCh3F032380 for ; Mon, 19 Jan 2004 09:14:06 -0800 Received: from phys-mpk-1 ([129.146.11.81]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id i0JHCOj4026616 for ; Mon, 19 Jan 2004 09:12:28 -0800 (PST) Received: from sun.com (vpn-3k-129-149-244-34.SFBay.Sun.COM [129.149.244.34]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTP id <0HRQ00BDIYGK1P@mpk-mail1.sfbay.sun.com> for autofs@linux.kernel.org; Mon, 19 Jan 2004 09:12:24 -0800 (PST) Date: Mon, 19 Jan 2004 12:11:46 -0500 From: Mike Waychison Subject: Re: [autofs] running out of mount points In-reply-to: <400BFC65.3000700@rhythm.com> To: Greg Bradner Message-id: <400C0FD2.6000507@sun.com> MIME-version: 1.0 X-Accept-Language: en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031107 Debian/1.5-3 X-Enigmail-Version: 0.82.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime References: <40059944.4060901@rhythm.com> <400BFC65.3000700@rhythm.com> X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on hera.kernel.org cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============5136068196808834==" Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: RO X-Status: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============5136068196808834== Content-type: multipart/signed; boundary=------------enig75B1DE8A9717E08116C01FEF; protocol="application/pgp-signature"; micalg=pgp-sha1 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig75B1DE8A9717E08116C01FEF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Greg Bradner wrote: > I wanted to repost this plea. I am really in a bind and could use some > help. I need to mount these users on the mail server. > BTW: this is with autofs 4.1.0 > This has been discussed various times on this mailing list and is a known limitation in 2.4 / 2.6. In 2.4, you can patch your kernel using something similar to: http://people.redhat.com/zaitcev/linux/linux-2.4.19-pre7-unmaj.diff HTH, -- Mike Waychison Sun Microsystems, Inc. 1 (650) 352-5299 voice 1 (416) 202-8336 voice mailto: Michael.Waychison@Sun.COM http://www.sun.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: The opinions expressed in this email are held by me, and may not represent the views of Sun Microsystems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------enig75B1DE8A9717E08116C01FEF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Debian - http://enigmail.mozdev.org iD8DBQFADA/VdQs4kOxk3/MRAuIoAKCQq19kDka2YJED8XXVW5Ud2xy0VwCfTdQP ldnwSoxKoJ7tWFeNhFnRQZg= =q//O -----END PGP SIGNATURE----- --------------enig75B1DE8A9717E08116C01FEF-- --===============5136068196808834== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs --===============5136068196808834==-- From autofs-bounces@linux.kernel.org Mon Jan 19 11:03:23 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0JJ3DHt015392 for ; Mon, 19 Jan 2004 11:03:23 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0JHDm3H032486; Mon, 19 Jan 2004 09:23:29 -0800 Received: from zeus.kernel.org (zeus.kernel.org [204.152.189.113]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0JHCf3F032378 for ; Mon, 19 Jan 2004 09:13:01 -0800 Received: from unogate.unocal.com (unogate.unocal.com [192.94.3.1]) by zeus.kernel.org (8.11.6/8.11.6) with ESMTP id i0JHCPV02477 for ; Mon, 19 Jan 2004 09:12:25 -0800 Received: from Halfdome.ad.unocal.com (localhost [127.0.0.1]) by unogate.unocal.com (8.12.10/8.12.10) with ESMTP id i0JHBDdn027705; Mon, 19 Jan 2004 09:11:19 -0800 (PST) Received: from slexch2.ad.unocal.com ([134.248.127.15]) by Halfdome.ad.unocal.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 19 Jan 2004 09:11:14 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [autofs] running out of mount points Date: Mon, 19 Jan 2004 11:11:12 -0600 Message-ID: <6AB920CC10586340BE1674976E0A991D0C6C00@slexch2.sugarland.unocal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [autofs] running out of mount points Thread-Index: AcPerS4+ndAu/2oEQVe/DQ0z9ZvxWgAAB4jA From: "Ogden, Aaron A." To: "Greg Bradner" , X-OriginalArrivalTime: 19 Jan 2004 17:11:14.0480 (UTC) FILETIME=[3E71E300:01C3DEAF] X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on hera.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hera.kernel.org id i0JHCf3F032378 X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: > -----Original Message----- > From: autofs-bounces@linux.kernel.org > [mailto:autofs-bounces@linux.kernel.org] On Behalf Of Greg Bradner > Sent: Monday, January 19, 2004 9:49 AM > To: autofs@linux.kernel.org > Subject: [autofs] running out of mount points > > > I wanted to repost this plea. I am really in a bind and could use some > help. I need to mount these users on the mail server. > BTW: this is with autofs 4.1.0 > Hello Greg, I have run into this problem as well, actually it isn't autofs but the kernel itself. The kernel hackers can explain the details but the simplified version is that the kernel runs out of 'unnamed devices' and when it does it cannot make any additional NFS mounts. You can get around this by applying a patch or using a kernel that already has the patch applied. RedHat's kernels (updates.redhat.com) have this patch and more, I have had good results with them. You can grab the source RPM and apply the autofs 4.1.0 patch to it to get the functionality you want. The 'unnamed devices' patch used by RedHat is supposed to allow around 1200 simultaneous NFS mounts. Without this patch the kernel has an 8-bit address space for unnamed devices so you hit the limit at 255 mounts. Once you get past this hurdle you may run into another problem, you may find (as I did) that you can't actually mount 1200 filesystems... RPC will start running into problems around 800 mounts or slightly less. I've been told that this happens because RPC is using a separate port for each NFS mount, it starts at port 800 and counts down to 1, so when the system runs out of ports it is once again unable to mount anything. Supposedly there is some work being done to rewire linux RPC so that it uses one port *per server* rather than one port per NFS mount, that change would fix the problem for any reasonable configuration. hope this helps, aaron _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 19 11:50:54 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0JJosHt000537 for ; Mon, 19 Jan 2004 11:50:54 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0JJ9n3H026088; Mon, 19 Jan 2004 11:19:50 -0800 Received: from tahoe.cinenet.net (root@tahoe1.cinenet.net [198.147.76.178]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0JJ7h3F025877 for ; Mon, 19 Jan 2004 11:09:12 -0800 Received: from mail.rhythm.com (rh-la-28-101.rhythm.com [24.130.28.101]) by tahoe.cinenet.net (8.12.10/8.12.10) with ESMTP id i0JJ7V3a019750 for ; Mon, 19 Jan 2004 11:07:33 -0800 (PST) Received: from mailhost.rhythm.com (gw-dmz.rhythm.com [24.130.28.100]) by mail.rhythm.com (8.12.9/8.12.5) with ESMTP id i0JJ7V6q006130 for ; Mon, 19 Jan 2004 11:07:31 -0800 Received: from rhythm.com (lid2.rhythm.com [10.4.7.102]) by mailhost.rhythm.com (8.12.9/8.12.5) with ESMTP id i0JJ7TFs027989 for ; Mon, 19 Jan 2004 11:07:31 -0800 Message-ID: <400C2AF1.10309@rhythm.com> Date: Mon, 19 Jan 2004 11:07:29 -0800 From: Greg Bradner User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: autofs@linux.kernel.org Subject: Re: [autofs] running out of mount points References: <4004409C.6040900@sun.com> <40059944.4060901@rhythm.com> <400BFC65.3000700@rhythm.com> <400C0FD2.6000507@sun.com> In-Reply-To: <400C0FD2.6000507@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on hera.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: RO X-Status: I was hoping there would have been something in the configuration. Right now I use AMD on my mailhost because it understands that it has the server mounted and just links to the mount without creating another mount point. Wouldn't that be more desirable? > Greg Bradner wrote: > >> I wanted to repost this plea. I am really in a bind and could use >> some help. I need to mount these users on the mail server. >> BTW: this is with autofs 4.1.0 >> > This has been discussed various times on this mailing list and is a > known limitation in 2.4 / 2.6. In 2.4, you can patch your kernel > using something similar to: > > http://people.redhat.com/zaitcev/linux/linux-2.4.19-pre7-unmaj.diff > > HTH, > _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Mon Jan 19 15:21:17 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0JNLGoV021817 for ; Mon, 19 Jan 2004 15:21:17 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0JMe83H016470; Mon, 19 Jan 2004 14:50:03 -0800 Received: from mail.wrs.com (unknown-1-11.windriver.com [147.11.1.11]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0JMbv3F016069 for ; Mon, 19 Jan 2004 14:39:21 -0800 Received: from windriver.com (jetstream.beaverton.windriver.com [147.11.222.4]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id OAA20702 for ; Mon, 19 Jan 2004 14:37:28 -0800 (PST) Message-ID: <400C5C32.7070504@windriver.com> Date: Mon, 19 Jan 2004 14:37:38 -0800 From: Jason Brooks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016 X-Accept-Language: en-us, en MIME-Version: 1.0 To: autofs@linux.kernel.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on hera.kernel.org Subject: [autofs] Introduction: I am new X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: Hello, Is there a FAQ for this mailing list? If not, here are a couple right off the bat: 1) Is it in the plans to support a "-hosts" option as found under solaris's automountd? (or for that matter, did I just miss it and it should be obvious?) 2) Is this list for developers, or for users? 3) (something's glimmering inside my brain, but not enough to formulate a third question...) --jason -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jason Brooks ~ (503) 641-3440 x1861 Direct ~ (503) 924-1861 Email to: jason.brooks@windriver.com Twiki: http://twiki.wrs.com/do/view/Main/JasonBrooks Senior Systems Administration Analyst Wind River Systems 8905 SW Nimbus ~ Suite 255 Beaverton, Or 97008 _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 20 10:01:07 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0KI13Q2002826 for ; Tue, 20 Jan 2004 10:01:07 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0KHo53H016311; Tue, 20 Jan 2004 09:50:09 -0800 Received: from mail.iinet.net.au (mail-04.iinet.net.au [203.59.3.36]) by hera.kernel.org (8.12.8/8.12.8) with SMTP id i0KHnN3F016139 for ; Tue, 20 Jan 2004 09:50:00 -0800 Received: (qmail 5760 invoked from network); 20 Jan 2004 15:11:49 -0000 Received: from unknown (HELO raven.themaw.net) (203.59.164.150) by mail.iinet.net.au with SMTP; 20 Jan 2004 15:11:49 -0000 Date: Tue, 20 Jan 2004 23:11:59 +0800 (WST) From: Ian Kent To: Greg Bradner Subject: RE: [autofs] running out of mount points In-Reply-To: <6AB920CC10586340BE1674976E0A991D0C6C00@slexch2.sugarland.unocal.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on hera.kernel.org cc: autofs mailing list cc: nfs@lists.sourceforge.net X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Mon, 19 Jan 2004, Ogden, Aaron A. wrote: > > > -----Original Message----- > > From: autofs-bounces@linux.kernel.org > > [mailto:autofs-bounces@linux.kernel.org] On Behalf Of Greg Bradner > > Sent: Monday, January 19, 2004 9:49 AM > > To: autofs@linux.kernel.org > > Subject: [autofs] running out of mount points > > > > > > I wanted to repost this plea. I am really in a bind and could use some > > > help. I need to mount these users on the mail server. > > BTW: this is with autofs 4.1.0 > > > > > Once you get past this hurdle you may run into another problem, you may > find (as I did) > that you can't actually mount 1200 filesystems... RPC will start running > into problems > around 800 mounts or slightly less. I've been told that this happens > because RPC is using > a separate port for each NFS mount, it starts at port 800 and counts > down to 1, so when the > system runs out of ports it is once again unable to mount anything. > Supposedly there is > some work being done to rewire linux RPC so that it uses one port *per > server* rather than > one port per NFS mount, that change would fix the problem for any > reasonable configuration. I have worked on Tronds' patch for that. I posted my first attempt on the nfs list to see if Trond could sanity check it but he was clearly to busy. So I went ahead and did the best I could. This resulted in a port for 2.6 and 2.4 vanila kernel only. It is entirely untested and I expect will have problems as the depth of my understanding of the NFS subsystem is poor at best. I found trying to make it apply to a RedHat 2.4 kernel was something of a nightmare and have left it there for now. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 20 11:04:49 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0KJ4jQ2020765 for ; Tue, 20 Jan 2004 11:04:49 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0KIwu3H032659; Tue, 20 Jan 2004 10:59:03 -0800 Received: from mail.iinet.net.au (mail-10.iinet.net.au [203.59.3.42]) by hera.kernel.org (8.12.8/8.12.8) with SMTP id i0KIwE3F032609 for ; Tue, 20 Jan 2004 10:58:52 -0800 Received: (qmail 18240 invoked from network); 20 Jan 2004 15:15:11 -0000 Received: from unknown (HELO raven.themaw.net) (203.59.164.150) by mail.iinet.net.au with SMTP; 20 Jan 2004 15:15:11 -0000 Date: Tue, 20 Jan 2004 23:15:21 +0800 (WST) From: Ian Kent To: Jason Brooks Subject: Re: [autofs] Introduction: I am new In-Reply-To: <400C5C32.7070504@windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on hera.kernel.org cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Mon, 19 Jan 2004, Jason Brooks wrote: > Hello, > > Is there a FAQ for this mailing list? > > If not, here are a couple right off the bat: > > 1) Is it in the plans to support a "-hosts" option as found under solaris's automountd? (or for > that matter, did I just miss it and it should be obvious?) This function is done by using a program mount in 4.0.0 and above. It does not do late mounting so all exports from a given host are mounted when accessed. See auto.net in the distribution. > > 2) Is this list for developers, or for users? Both. > > 3) (something's glimmering inside my brain, but not enough to formulate a third question...) Don't know the answer to that one. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 20 11:19:40 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0KJJdQ2020819 for ; Tue, 20 Jan 2004 11:19:40 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0KJFu3H004495; Tue, 20 Jan 2004 11:16:02 -0800 Received: from harlech.math.ucla.edu (harlech.math.ucla.edu [128.97.4.250]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0KJFL3F004176 for ; Tue, 20 Jan 2004 11:15:55 -0800 Received: from xena.cft.ca.us (unknown [192.9.200.195]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (verified OK)) by harlech.math.ucla.edu (Postfix) with ESMTP id 13EA076704; Tue, 20 Jan 2004 11:15:21 -0800 (PST) Received: by xena.cft.ca.us (Postfix, from userid 228) id 5014627E15; Tue, 20 Jan 2004 11:15:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xena.cft.ca.us (Postfix) with ESMTP id 4CF4F62780; Tue, 20 Jan 2004 11:15:20 -0800 (PST) Date: Tue, 20 Jan 2004 11:15:20 -0800 (PST) From: Jim Carter To: Greg Bradner Subject: Re: [autofs] running out of mount points In-Reply-To: <400BFC65.3000700@rhythm.com> Message-ID: References: <40059944.4060901@rhythm.com> <400BFC65.3000700@rhythm.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on hera.kernel.org cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Mon, 19 Jan 2004, Greg Bradner wrote: > > I have run into a problem of running out of mount points. I have over > > 600 users and their home dirs are listed in auto.home and they are all > > stored on the same nfs server. If I list the dirs, automount will > > create a seperate mount point for each user, and at ~256 mount points, > > no more home dirs can be mounted. Our "workaround" is to not use the auto.home map. In /etc/passwd, write the user's homedir as /net/tupelo/h1/maint/jimc (using mine as an example), where the actual mount point is /net/tupelo/h1. We provide the auto.home map for convenience so users can manually type their homedir as /home/$USER, but at any one time only two or three /home mounts will be seen throughout our collection of clients and servers. Also to minimize the number of mounts per machine it's helpful if the users execute on either the fileserver or their personal workstations. In some cases this is impractical (e.g. the fileserver is a network appliance) and you need a shared execution machine. But 600 users would bring anything to its knees. We provide several shared execution machines and keep each category of (lesser-funded) user on his/her assigned machine, thus cutting down the number of mounts even if auto.home is used. Hope this helps! James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc@math.ucla.edu http://www.math.ucla.edu/~jimc (q.v. for PGP key) _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Tue Jan 20 16:35:16 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0L0ZGsv014085 for ; Tue, 20 Jan 2004 16:35:16 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0L0Gd3H010453; Tue, 20 Jan 2004 16:16:51 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0L0Fv3F010344 for ; Tue, 20 Jan 2004 16:16:35 -0800 Received: from wombat.indigo.net.au (wombat.indigo.net.au [202.0.185.19]) by wombat.indigo.net.au (8.11.6/8.11.6) with ESMTP id i0L0GJ513505; Wed, 21 Jan 2004 08:16:20 +0800 Date: Wed, 21 Jan 2004 08:16:19 +0800 (WST) From: Ian Kent X-X-Sender: To: Jason Brooks Subject: Re: [autofs] Introduction: I am new In-Reply-To: <400D6530.6050109@windriver.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-MailScanner: Found to be clean X-MailScanner-SpamCheck: not spam, SpamAssassin (score=-4.5, required 8, AWL, BAYES_20, EMAIL_ATTRIBUTION, IN_REP_TO, QUOTED_EMAIL_TEXT, REPLY_WITH_QUOTES, USER_AGENT_PINE) X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.61 X-Spam-Checker-Version: SpamAssassin 2.61 (1.212.2.1-2003-12-09-exp) on hera.kernel.org cc: autofs@linux.kernel.org X-BeenThere: autofs@linux.kernel.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion list for the autofs automounter for Linux List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: autofs-bounces@linux.kernel.org Errors-To: autofs-bounces@linux.kernel.org Status: O X-Status: On Tue, 20 Jan 2004, Jason Brooks wrote: > Thank you for your reply. > > When you say: > > This function is done by using a program mount in 4.0.0 and above. > > Do you mean when using a later version of the mount/umount program? Or Autofs > version 4.x.x? Or perhaps the kernel autofs4.o module? possibilities here> autofs. An updated autofs4 module is not needed to do this. Ian _______________________________________________ autofs mailing list autofs@linux.kernel.org http://linux.kernel.org/mailman/listinfo/autofs From autofs-bounces@linux.kernel.org Thu Jan 22 08:31:19 2004 Return-Path: Received: from hera.kernel.org (hera.kernel.org [63.209.29.2]) by Mail.Linux-Consulting.com (8.12.9/8.12.9/check_local-5) with ESMTP id i0MGVJs3012035 for ; Thu, 22 Jan 2004 08:31:19 -0800 Received: from hera.kernel.org (localhost [127.0.0.1]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0MGKY3H010451; Thu, 22 Jan 2004 08:21:50 -0800 Received: from mail5.utc.com ([192.249.46.188]) by hera.kernel.org (8.12.8/8.12.8) with ESMTP id i0MGKA3F010428 for ; Thu, 22 Jan 2004 08:20:29 -0800 Received: (from uucp@localhost) by mail5.utc.com (8.10.0/8.10.0) id i0MGIFg02972 for ; Thu, 22 Jan 2004 11:18:15 -0500 (EST) Received: from uusnwa0p.utc.com(159.82.80.106) by mail5.utc.com via csmap (V6.0) id srcAAA9FaGSf; Thu, 22 Jan 04 11:18:12 -0500 Received: from saexch-bh2-stf.sikorsky.com (saexch-bh2-stf.sikorsky.com [140.76.216.22])i0MGJ9518565 for ; Thu, 22 Jan 2004 11:19:09 -0500 (E