Re: Filepaths in VM map for tmpfs files

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