From: Tejun Heo <tj@kernel.org>
To: Li Zefan <lizefan@huawei.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
LKML <linux-kernel@vger.kernel.org>,
Cgroups <cgroups@vger.kernel.org>
Subject: Re: [PATCH] sysfs: fix namespace refcnt leak
Date: Tue, 18 Feb 2014 18:12:42 -0500 [thread overview]
Message-ID: <20140218231242.GJ31892@mtj.dyndns.org> (raw)
In-Reply-To: <53018813.7030409@huawei.com>
Hey,
On Mon, Feb 17, 2014 at 11:54:59AM +0800, Li Zefan wrote:
> I think we have to fix kernfs in order to fix refcnt leak in sysfs
> and cgroupfs. This fix is for 3.14, but it creates conflicts for
> cgroup-next.
>
> ====================
>
> As mount() and kill_sb() is not a one-to-one match, we shoudn't get
> ns refcnt unconditionally in sysfs_mount(), and instead we should
> get the refcnt only when kernfs_mount() allocated a new superblock.
Ugh... nasty :(
> @@ -132,6 +132,7 @@ const void *kernfs_super_ns(struct super_block *sb)
> * @flags: mount flags specified for the mount
> * @root: kernfs_root of the hierarchy being mounted
> * @ns: optional namespace tag of the mount
> + * @new: tell the caller if we allocated a new superblock
Maybe something like @new_sb_created is better?
> struct super_block *sb;
> struct kernfs_super_info *info;
> int error;
>
> + *new_sb = false;
Can we make it optional so that users who don't care about it can
ignore it?
> @@ -430,9 +431,9 @@ static inline int kernfs_rename(struct kernfs_node *kn,
>
> static inline struct dentry *
> kernfs_mount(struct file_system_type *fs_type, int flags,
> - struct kernfs_root *root)
> + struct kernfs_root *root, bool *new_sb)
> {
> - return kernfs_mount_ns(fs_type, flags, root, NULL);
> + return kernfs_mount_ns(fs_type, flags, root, NULL, new_sb);
And let kernfs_mount() just use NULL for the parameter?
Thanks.
--
tejun
next prev parent reply other threads:[~2014-02-18 23:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 3:54 Li Zefan
2014-02-18 23:12 ` Tejun Heo [this message]
2014-02-19 1:39 ` Li Zefan
2014-02-20 14:30 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140218231242.GJ31892@mtj.dyndns.org \
--to=tj@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®