From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <885058543eea2b91cb1e88db79969625@plan9.bell-labs.com> To: 9fans@cse.psu.edu Subject: Re: [9fans] bind, ns weirdness From: "Russ Cox" In-Reply-To: <20030306235259.27037.qmail@mail.dirac.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Thu, 6 Mar 2003 16:18:20 -0500 Topicbox-Message-UUID: 7bd53578-eacb-11e9-9e20-41e7f4b1d025 ns is not manipulating the data. it is showing you the internal kernel data structures. the kernel doesn't keep the history of every mount, bind, unmount, and in fact the kernel doesn't keep the structure as a list. it keeps it as a hash table for quick access, and the mount points are represented by chans (think vnodes) rather than actual path strings. when you look at just the strings (as happens when it is presented in the ns file) there is no guarantee that the names are still valid. as you point out the fundamental problem here is that unmount removes things from the hash table (and thus from the list presented in /proc/$pid/ns), things that other binds or mounts might have depended on to make sense of the names at the time. it is entirely reasonable that unmount removes things from the hash table: they're gone! then the chans can be closed, and the resources reused. in order to keep the entries in /proc/$pid/ns around, the chans would have to be kept open, which is against the point of unmount. unmount means release this binding, not make it invisible but hold onto the resources. perhaps some stub should remain in the in-order list that has an empty chan structure with just a name, so that the ns list is correct. perhaps.