[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220817140149.pfakskeyxkqcot54@wittgenstein>
Date: Wed, 17 Aug 2022 16:01:49 +0200
From: Christian Brauner <brauner@...nel.org>
To: Al Viro <viro@...iv.linux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Dongliang Mu <mudongliangabcd@...il.com>,
Dongliang Mu <dzm91@...t.edu.cn>,
Arve Hjønnevåg <arve@...roid.com>,
Todd Kjos <tkjos@...roid.com>,
Martijn Coenen <maco@...roid.com>,
Joel Fernandes <joel@...lfernandes.org>,
Carlos Llamas <cmllamas@...gle.com>,
Suren Baghdasaryan <surenb@...gle.com>,
Kees Cook <keescook@...omium.org>,
syzkaller <syzkaller@...glegroups.com>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] binderfs: rework superblock destruction
On Wed, Aug 17, 2022 at 02:59:02PM +0100, Al Viro wrote:
> On Wed, Aug 17, 2022 at 03:03:06PM +0200, Christian Brauner wrote:
>
> > +static void binderfs_kill_super(struct super_block *sb)
> > +{
> > + struct binderfs_info *info = sb->s_fs_info;
> > +
> > + if (info && info->ipc_ns)
> > + put_ipc_ns(info->ipc_ns);
> > +
> > + kfree(info);
> > + kill_litter_super(sb);
> > +}
>
> Other way round, please - shut the superblock down, *then*
> free the objects it'd been using. IOW,
I wondered about that but a lot of places do it the other way around.
So maybe the expected order should be documented somewhere.
Powered by blists - more mailing lists