On Fri, 09 Sep 2005 20:12:05 PDT, Gerrit Huizenga wrote:
>
> 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);
> >
Well, it looks like I need a little more than that; somehow your
patch is a little garbled with line wrapping and some ascii text
encoding and I'm too tired to see how to unwrap it cleanly. Can
you take a peek at Documentation/SubmittingPatches and make sure you
have the right diff options to make my life simple? I'm not just
lazy but after fifteen hours in front of a laptop even simple looking
patches make my eyes hurt.
I'm actually testing most of the patches up to this at the moment;
they are going to run for a while. I'll try to make progress around
this but I'd like to hold off on e19 until I get this in. It looks
like it will be useful to get it fixed once up front and tested
so we have a good baseline as we approach the "f" series.
FWIW, I'm expecting that after e19 I'll do one more round - an e20
to simplify the patch layout a bit, rename the patches as suggested
(yes, I hate the patch names too ;-), and maybe pull in a few more
things that have been pending for a while, such as the IO controller
(I was hoping to get to it this round but I'm not sure I'll make it).
One e20 is out, I'd like to start playing with some of the ideas
that I've been hearing for simplifying the patch set, which will
probably lead to an experimental "f" patch set for a while. The
"e" series should remain stable for those that are using it now;
"f" may stabilize quickly as there will be less code to test. ;)
gerrit
-------------------------------------------------------
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
