Re: 9pfs double kfree

["Latchesar Ionkov" <lionkov@gmail.com>]

We can't allocate it on the outermost caller's stack. The memory
pointed by v9fs_fcall strucures has variable size and depends on the
incoming 9P messages.

Thanks,
    Lucho

On 3/6/06, Andrew Morton <akpm@osdl.org> wrote:
> Dave Jones <davej@redhat.com> wrote:
> >
> > Probably the first of many found with Coverity.
> >
> > This is kfree'd outside of both arms of the if condition already,
> > so fall through and free it just once.
> >
> > Second variant is double-nasty, it deref's the free'd fcall
> > before it tries to free it a second time.
> >
> > (I wish we had a kfree variant that NULL'd the target when it was free'd)
> >
> > Coverity bugs: 987, 986
> >
> > Signed-off-by: Dave Jones <davej@redhat.com>
> >
> >
> > --- linux-2.6.15.noarch/fs/9p/vfs_super.c~    2006-03-06 01:53:38.000000000 -0500
> > +++ linux-2.6.15.noarch/fs/9p/vfs_super.c     2006-03-06 01:54:36.000000000 -0500
> > @@ -156,7 +156,6 @@ static struct super_block *v9fs_get_sb(s
> >       stat_result = v9fs_t_stat(v9ses, newfid, &fcall);
> >       if (stat_result < 0) {
> >               dprintk(DEBUG_ERROR, "stat error\n");
> > -             kfree(fcall);
> >               v9fs_t_clunk(v9ses, newfid);
> >       } else {
> >               /* Setup the Root Inode */
> > --- linux-2.6.15.noarch/fs/9p/vfs_inode.c~    2006-03-06 01:57:05.000000000 -0500
> > +++ linux-2.6.15.noarch/fs/9p/vfs_inode.c     2006-03-06 01:58:05.000000000 -0500
> > @@ -274,7 +274,6 @@ v9fs_create(struct v9fs_session_info *v9
> >               PRINT_FCALL_ERROR("clone error", fcall);
> >               goto error;
> >       }
> > -     kfree(fcall);
> >
> >       err = v9fs_t_create(v9ses, fid, name, perm, mode, &fcall);
> >       if (err < 0) {
>
> The second hunk is probably right and I guess the first one has to be right
> as well, but it's all rather obscure, complex and (naturally) comment-free.
>
> So I'll duck on this - Eric, could you please handle it?  Consider doing
> away with the dynamically-allocated thing altogether and just allocating it
> on the outermost caller's stack.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>