Chandra Seetharaman wrote:
On Thu, 2005-09-08 at 12:15 -0700, Paul Menage wrote:
On 9/8/05, Chandra Seetharaman <[EMAIL PROTECTED]> wrote:
it is a counted reference... the count is incremented during alloc (in
ckrm_init_core_class), which is expected to be decremented during
removal of directory.
Yes, the reference in the rcfs_inode_info for the class directory
inode is refcounted. The references in the rcfs_inode_info structures
for the "magic" files are not, and they persist beyond the point when
the ckrm_core_class object is freed.
Looks like we need to get a reference while calling any control
functions (like classifying a task, getting stats etc.,) through the
control files.
Wouldn't it be simpler to say that a reference to the inode guarantees
that the ckrm_core_class object won't be freed (in the same way that
holding a valid reference to a dentry guarantees that its inode won't
be freed)? Then there's no need to muck around with reference counts
and calls to ckrm_validate_and_grab_core(). If you need to hold a
reference to a ckrm_core_class without holding a reference on its
inode, then you need to grab a reference count, but that should be
rarer.
So, you are suggesting that we could get a reference immediately after
we get a core (in rcfs_create_coredir()) and drop it only when the inode
is destroyed (rcfs_destroy_inode) ?
Only problem i see with that is that in rcfs_destroy_inode(), we do not
knowwhat the inode corresponds to, a file or a directory...
S_ISDIR(inode->i_mode)
S_ISREG(inode->i_mode)
can do that, even in rcfs_destroy_inode.
may be we
can keep the core and from that (in rcfs_inode_info) we can know that it
is associated with a core class and decrement it. But, keeping the
reference after we called free on that objects doesn't sound right to
me.
Irrespective of this, code needs to make sure that a task is not getting
classified to a class that is deleted.
Paul
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
