From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 20:33:44 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 950396F4 for ; Tue, 3 Feb 2015 20:33:44 +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 36DF6A80 for ; Tue, 3 Feb 2015 20:33:44 +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 t13KXa1Q037773 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Feb 2015 22:33:36 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua t13KXa1Q037773 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id t13KXaAn037772; Tue, 3 Feb 2015 22:33:36 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 3 Feb 2015 22:33:36 +0200 From: Konstantin Belousov To: Eric Badger Subject: Re: Filepaths in VM map for tmpfs files Message-ID: <20150203203336.GB42409@kib.kiev.ua> References: <54CCEFAB.9040406@badgerio.us> <20150131153621.GH42409@kib.kiev.ua> <54CEE325.4040903@badgerio.us> <20150202093027.GL42409@kib.kiev.ua> <54D0457E.90006@badgerio.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54D0457E.90006@badgerio.us> 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: 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: Tue, 03 Feb 2015 20:33:44 -0000 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. > > > > >>> Second, note that it is possible that the vnode is recycled, so > >>> OBJ_TMPFS flag is cleared for tmpfs swap object. The OBJ_TMPFS_NODE > >>> flag is still set then. I am not sure what to do in this case, > >>> should the type changed to KVME_TYPE_VNODE still, but kve_vn_* > >>> fields left invalid ? > >> I think if we changed to KVME_TYPE_VNODE in some cases, it should be > >> done in all cases, even if the vnode has been recycled (but leave vp == > >> NULL in that case). Though if it is left as KVME_TYPE_SWAP, then that > >> concern goes away on its own. > > Concern is not vp == NULL, but the fact that kve_vn* cannot be filled, > > there is simply no (easy) way to fetch this information. > > Right; by leaving vp == NULL, I meant "don't populate the kve_vn* > fields", which admittedly isn't a great solution. > But as you say, the information is not really available once the vnode > has been reclaimed. > > There is some inherent difficultly in the duality of the vm object here; > it would be nice if it could be treated > uniformly with other vnodes, but I think I lack the expertise to > approach a more involved solution that > would achieve this.