From: Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] sysfs: fix namespace refcnt leak
Date: Wed, 19 Feb 2014 09:39:28 +0800 [thread overview]
Message-ID: <53040B50.4060600@huawei.com> (raw)
In-Reply-To: <20140218231242.GJ31892-9pTldWuhBndy/B6EtB590w@public.gmane.org>
On 2014/2/19 7:12, Tejun Heo wrote:
> 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?
>
cgroupfs also needs this to fix refcnt leak.
Because success in finding an existing cgroup_root doesn't mean no new
superblock is needed. For example:
# mount -t cgroup -o cpuacct xxx /cgroup
# mkdir /cgroup/tmp
# umount /cgroup <--- sb will be freed but cgroup_root won't
// this will allocate new sb, but we find the cgroup_root is there.
# mount -t cgroup -o cpuacct xxx /cgroup
But debugfs won't need this if it's converted to kernfs.
How about I keep kernfs_mount() API intact, and when this fix gets
merged into mainline, you merge the fix into cgroup-next, and then
I make a fix for cgroup by changing kernfs_mount()?
>> @@ -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?
>
WARNING: multiple messages have this Message-ID (diff)
From: Li Zefan <lizefan@huawei.com>
To: Tejun Heo <tj@kernel.org>
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: Wed, 19 Feb 2014 09:39:28 +0800 [thread overview]
Message-ID: <53040B50.4060600@huawei.com> (raw)
In-Reply-To: <20140218231242.GJ31892@mtj.dyndns.org>
On 2014/2/19 7:12, Tejun Heo wrote:
> 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?
>
cgroupfs also needs this to fix refcnt leak.
Because success in finding an existing cgroup_root doesn't mean no new
superblock is needed. For example:
# mount -t cgroup -o cpuacct xxx /cgroup
# mkdir /cgroup/tmp
# umount /cgroup <--- sb will be freed but cgroup_root won't
// this will allocate new sb, but we find the cgroup_root is there.
# mount -t cgroup -o cpuacct xxx /cgroup
But debugfs won't need this if it's converted to kernfs.
How about I keep kernfs_mount() API intact, and when this fix gets
merged into mainline, you merge the fix into cgroup-next, and then
I make a fix for cgroup by changing kernfs_mount()?
>> @@ -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?
>
next prev parent reply other threads:[~2014-02-19 1:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-17 3:54 [PATCH] sysfs: fix namespace refcnt leak Li Zefan
2014-02-17 3:54 ` Li Zefan
2014-02-18 23:12 ` Tejun Heo
[not found] ` <20140218231242.GJ31892-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2014-02-19 1:39 ` Li Zefan [this message]
2014-02-19 1:39 ` Li Zefan
[not found] ` <53040B50.4060600-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2014-02-20 14:30 ` Tejun Heo
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=53040B50.4060600@huawei.com \
--to=lizefan-hv44wf8li93qt0dzr+alfa@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.