If I can get a Signed-Off-By: for this patch, I'll include it
in e19.
gerrit
On Fri, 09 Sep 2005 19:47:09 PDT, Paul Menage wrote:
> On 9/9/05, Shailabh Nagar <[EMAIL PROTECTED]> wrote:
> >
> >
> > Here are two patches that fix the inode leak problem. They apply over
> > 2.6.12 + e18 + magic_c.patch which is our interim version till e19 comes
> > out.
>
> Thanks, I can confirm that these fix the inode leak problem for me.
>
> Additionally, the following changes fix the Oops race that I described
> yesterday. They also lead to the warning about delayed deletion on
> every class creation/deletion, but I think that it's better to remove
> the warning and accept that successfully deleting the core class at
> that point is unlikely to happen due to all the other references to
> it.
>
> I think that even with this change it's possible to leak class
> objects, if a task gets classified into a task at just the wrong
> moment.
>
> Longer term I think it would make sense to rename free() to kill(),
> and have the primary action of kill() be to set a "dead" flag (to
> prevent new members) and clear out any current members.
>
> Paul
>
> --- /home/menage/kernel7/2.6/fs/rcfs/super.c 2005-08-03
> 00:21:23.000000000 -0700
> +++ fs/rcfs/super.c 2005-09-09 19:27:48.000000000 -0700
> @@ -55,6 +55,7 @@
> struct rcfs_inode_info *ri =3D rcfs_get_inode_info(inode);
>
> kfree(ri->name);
> + if (ri->core) ckrm_core_drop(ri->core);
> kmem_cache_free(rcfs_inode_cachep, ri);
> }
> --- /home/menage/kernel7/2.6/fs/rcfs/magic.c 2005-08-03
> 00:28:12.000000000 -0700
> +++ fs/rcfs/magic.c 2005-09-09 19:28:28.000000000 -0700
> @@ -497,6 +501,7 @@
> }
> rcfs_get_inode_info(mfdentry->d_inode)->core =3D
> rcfs_get_inode_info(parent->d_inode)->core;
> + ckrm_core_grab(rcfs_get_inode_info(mfdentry->d_inode)->cor=
> e);
> rcfs_get_inode_info(mfdentry->d_inode)->mfdentry =3D mfdent=
> ry;
> mfdentry->d_fsdata =3D &RCFS_IS_MAGIC;
> if (magf[i].i_fop)
> --- /home/menage/kernel7/2.6/fs/rcfs/dir.c 2005-08-03
> 00:21:23.000000000 -0700
> +++ fs/rcfs/dir.c 2005-09-09 19:29:01.000000000 -0700
> @@ -69,6 +85,7 @@
> dentry->d_name.name);
> ridir->core =3D (*(ripar->core->classtype->alloc))
> (ripar->core, ridir->name);
> + ckrm_core_grab(ridir->core);
> } else {
> printk(KERN_ERR "rcfs_mkdir: Invalid parent core %p\n",
> ripar->core);
> @@ -124,7 +141,6 @@
> printk(KERN_ERR "rcfs_rmdir: ckrm_free_core_class failed\n"=
> );
> goto out;
> }
> - ri->core =3D NULL; /* just to be safe */
>
> /* Clear magic files only after core successfully removed */
> rcfs_clear_magic(dentry);
>
>
> -------------------------------------------------------
> 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
>
>
-------------------------------------------------------
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
