From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <545C1EC0.1070907@huawei.com> Date: Fri, 7 Nov 2014 09:22:08 +0800 From: Yijing Wang MIME-Version: 1.0 To: Tejun Heo CC: , , , Weng Meiling , Subject: Re: [PATCH] sysfs: driver core: Fix glue dir race condition References: <1415261798-9671-1-git-send-email-wangyijing@huawei.com> <20141106165547.GG25642@htj.dyndns.org> In-Reply-To: <20141106165547.GG25642@htj.dyndns.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: On 2014/11/7 0:55, Tejun Heo wrote: > Maybe "fix glue dir race condition by not removing them" is a better > title? Yes, it's better, thank you! > > On Thu, Nov 06, 2014 at 04:16:38PM +0800, Yijing Wang wrote: >> There is a race condition when removing glue directory. >> It can be reproduced in following test: >> >> path 1: Add first child device >> device_add() >> get_device_parent() >> /*find parent from glue_dirs.list*/ >> list_for_each_entry(k, &dev->class->p->glue_dirs.list, entry) >> if (k->parent == parent_kobj) { >> kobj = kobject_get(k); >> break; >> } >> .... >> class_dir_create_and_add() >> >> path2: Remove last child device under glue dir >> device_del() >> cleanup_device_parent() >> cleanup_glue_dir() >> kobject_put(glue_dir); >> >> If path2 has been called cleanup_glue_dir(), but not >> call kobject_put(glue_dir), the glue dir is still >> in parent's kset list. Meanwhile, path1 find the glue >> dir from the glue_dirs.list. Path2 may release glue dir >> before path1 call kobject_get(). So kernel will report >> the warning and bug_on. >> >> This fix keep glue dir around once it created suggested >> by Tejun Heo. > > I think you prolly want to explain why this is okay / desired. > e.g. list how the glue dir is used and how many of them are there and > explain that there's no real benefit in removing them. > Right, I will add the explanation. :) > ... >> Signed-off-by: Yijing Wang >> Signed-off-by: Weng Meiling >> Cc: #3.4+ > > Except for the above nits. > > Reviewed-by: Tejun Heo Thanks! > -- Thanks! Yijing