From owner-freebsd-current@FreeBSD.ORG Thu Feb 5 08:38:08 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5FA042D; Thu, 5 Feb 2015 08:38:08 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 675106DD; Thu, 5 Feb 2015 08:38:08 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id t158bumH029288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Feb 2015 10:37:56 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t158bumH029288 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t158btIw029287; Thu, 5 Feb 2015 10:37:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 5 Feb 2015 10:37:55 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: Filepaths in VM map for tmpfs files Message-ID: <20150205083755.GG42409@kib.kiev.ua> References: <54CCEFAB.9040406@badgerio.us> <54D0457E.90006@badgerio.us> <20150203203336.GB42409@kib.kiev.ua> <1601131.aIB9RoRbLs@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1601131.aIB9RoRbLs@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Eric Badger , freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 08:38:09 -0000 On Wed, Feb 04, 2015 at 10:15:04AM -0500, John Baldwin wrote: > On Tuesday, February 03, 2015 10:33:36 PM Konstantin Belousov wrote: > > On Mon, Feb 02, 2015 at 09:50:22PM -0600, Eric Badger wrote: > > > On 02/02/2015 03:30 AM, Konstantin Belousov wrote: > > > > On Sun, Feb 01, 2015 at 08:38:29PM -0600, Eric Badger wrote: > > > >> On 01/31/2015 09:36 AM, Konstantin Belousov wrote: > > > >>> First, shouldn't the kve_type changed to KVME_TYPE_VNODE as well ? > > > >> > > > >> My thinking is no, because KVME_TYPE_SWAP is in fact the correct type; > > > >> I'd opine that it is better to be transparent than make it look like > > > >> there is an OBJT_VNODE object there. It may be that some programs would > > > >> be confused by VNODE info returned on a SWAP type mapping, though I > > > >> know > > > >> that dtrace handles it OK. > > > > > > > > kve_vn_* and kve_path fields are defined only for KVME_TYPE_VNODE > > > > kve_type. > > > > So this is in fact a bug in whatever used the API to access kve_path > > > > for KVE_TYPE_SWAP. > > > > > > Hmm, is that documented anywhere? I think it's fair to assume that > > > kve_vn* applies only to the VNODE type, > > > but I know there are several in-tree users that reference kve_path > > > regardless of type (ostensibly relying > > > on the default of an empty string). Maybe one could determine the > > > validity of the kve_vn* fields by > > > inspecting the kve_vn_type (not sure of all the consequences of that)? > > > Or change it to KVME_TYPE_VNODE > > > and deal with the below problem... > > > > There is no useful documentation for the kern.proc. sysctls. > > My word (and statements from other involved developers) could be > > considered as close to the truth as it can be. > > Somebody taking the efforts to document the stuff would make very > > valuable contribution. > > I think that kve_path should be valid for all types (e.g. shm_open() > is not a vnode but has a pathname, and that should be fixed to display > if possible). In the equivalent for files (kinfo_file), the pathname > is type-independent and always valid. Well, this means that it should be valid for vnodes and shm. My point is that kvme_vn_path should be used only after the check for type. We can and do set it to nul string, but using the path unconditionally is a bug in the user code. > > That said, I think tmpfs nodes should be exposed as files. It is an > implementation detail of tmpfs that they are swap-backed, but from a > user's perspective these are files, and if you want to expose other > vnode-specific fields than just the path, KVME_TYPE_VNODE would be > more correct. I agree, but doing it is not easy, since there might be no vnode to get the required information from. We do know that this swap object is for tmpfs node, but currently we only store pointer to object in the node, not pointer to node from the object. When the vnode exists, pointer to vnode is stored in the object. To fix the issue, we should store pointer to node. Code was not done this way, because VM code which handles special-case for OBJT_TMPFS, would need to know tmpfs internals. Right now, code knows about vnodes anyway, so object->vnode does not bring tmpfs internals into vm.