From owner-freebsd-current@FreeBSD.ORG Tue Feb 3 03:50:39 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 7D160891 for ; Tue, 3 Feb 2015 03:50:39 +0000 (UTC) Received: from sasl.smtp.pobox.com (pb-smtp1.int.icgroup.com [208.72.237.35]) by mx1.freebsd.org (Postfix) with ESMTP id 372407BA for ; Tue, 3 Feb 2015 03:50:37 +0000 (UTC) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 73F3236ACB for ; Mon, 2 Feb 2015 22:50:30 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=8/dfXEt/5ZPh z0TtleyTkcl9X/c=; b=IMefyyscx/DtOKjVX4fBiO6Brvn8LjtTuQFFhTSgl7me WJOLRJvla732SRo8KCbaD0vaXqUdVI3A0GCgsUctVpzIA3s5eMc46YiVsT5Ffbae tflCQiiodQpfXOaJ89u+Jk/tQ8+vQczAGhEbW3PbumP+oBONJAdoPn+RguSNIWc= Received: from pb-smtp1.int.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 6A9E536ACA for ; Mon, 2 Feb 2015 22:50:30 -0500 (EST) Received: from [192.168.1.103] (unknown [73.164.1.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 0D6FC36AC9 for ; Mon, 2 Feb 2015 22:50:28 -0500 (EST) Message-ID: <54D0457E.90006@badgerio.us> Date: Mon, 02 Feb 2015 21:50:22 -0600 From: Eric Badger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: freebsd-current@freebsd.org Subject: Re: Filepaths in VM map for tmpfs files References: <54CCEFAB.9040406@badgerio.us> <20150131153621.GH42409@kib.kiev.ua> <54CEE325.4040903@badgerio.us> <20150202093027.GL42409@kib.kiev.ua> In-Reply-To: <20150202093027.GL42409@kib.kiev.ua> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: CB68411A-AB57-11E4-BEE7-7BA29F42C9D4-46178211!pb-smtp1.pobox.com 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 03:50:39 -0000 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... > >>> 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. Incidentally Konstantin, thanks for the feedback and advice. Eric