Re: Filepaths in VM map for tmpfs files

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Tue, 3 Feb 2015 22:33:36 +0200
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.
Received on Tue Feb 03 2015 - 19:33:44 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:55 UTC