[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5459992B.1040700@huawei.com>
Date: Wed, 5 Nov 2014 11:27:39 +0800
From: Yijing Wang <wangyijing@...wei.com>
To: Tejun Heo <tj@...nel.org>
CC: Weng Meiling <wengmeiling.weng@...wei.com>,
Greg KH <gregkh@...uxfoundation.org>,
Frans Klaver <fransklaver@...il.com>,
"Jens Axboe" <axboe@...nel.dk>, <akpm@...ux-foundation.org>,
<adilger.kernel@...ger.ca>, Jan Kara <jack@...e.cz>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Xiang Rui <rui.xiang@...wei.com>,
Li Zefan <lizefan@...wei.com>,
Huang Qiang <h.huangqiang@...wei.com>,
Zhao Hongjiang <zhaohongjiang@...wei.com>
Subject: Re: Subject: [PATCH] kobject: fix the race between kobject_del and
get_device_parent
On 2014/11/5 11:13, Tejun Heo wrote:
> Hello,
>
> On Wed, Nov 05, 2014 at 10:01:39AM +0800, Yijing Wang wrote:
>>> So, yeah, this looks like a correct approach; however, do we even need
>>> to clear the glue directories?
>>
>> Yes. In our platform, the glue directories
>> /sys/devices/virtual/block will be removed once the last child
>> device call device_del().
>
> What I mean is why are we even trying to remove the parent directory?
> Can't we just keep them around once created?
We remove the parent directory because parent ref count is equal to children
device numebr, every child device will get/add parent's ref count when child
device be created.
Keep the parent directory looks good to me, we could only add kobject_get(&parent)
after the parent dir be created.
....
/* or create a new class-directory at the parent device */
k = class_dir_create_and_add(dev->class, parent_kobj);
/* do not emit an uevent for this simple "glue" directory */
kobject_get(k); <--------add parent ref count for first child device.
mutex_unlock(&gdp_mutex);
return k;
....
>
> Thanks.
>
--
Thanks!
Yijing
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists