From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751843AbaFXC2e (ORCPT ); Mon, 23 Jun 2014 22:28:34 -0400 Received: from szxga01-in.huawei.com ([119.145.14.64]:50995 "EHLO szxga01-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751014AbaFXC2c (ORCPT ); Mon, 23 Jun 2014 22:28:32 -0400 Message-ID: <53A8E23C.4050103@huawei.com> Date: Tue, 24 Jun 2014 10:28:12 +0800 From: Li Zefan User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: Tejun Heo CC: David Rientjes , Gu Zheng , Andrew Morton , linux-kernel , , Cgroups , Subject: Re: [PATCH] mm/mempolicy: fix sleeping function called from invalid context References: <53902A44.50005@cn.fujitsu.com> <20140605132339.ddf6df4a0cf5c14d17eb8691@linux-foundation.org> <539192F1.7050308@cn.fujitsu.com> <539574F1.2060701@cn.fujitsu.com> <53967465.7070908@huawei.com> <20140620210137.GA2059@mtj.dyndns.org> In-Reply-To: <20140620210137.GA2059@mtj.dyndns.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.177.18.230] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2014/6/21 5:01, Tejun Heo wrote: > Hello, Li. > > Sorry about the long delay. > > On Tue, Jun 10, 2014 at 10:58:45AM +0800, Li Zefan wrote: >> Yes, this is a long-standing issue. Besides the race you described, the child >> task's mems_allowed can be wrong if the cpuset's nodemask changes before the >> child has been added to the cgroup's tasklist. >> >> I remember Tejun once said he wanted to disallow task migration between >> cgroups during fork, and that should fix this problem. > > I'm having trouble remembering but yeah enforcing stricter behavior > across fork could be beneficial. Hmmm... the problem with making > forks exclusive against migrations is that we'll end up adding more > locking to the fork path which isn't too nice. > > Hmmm... other controllers (cgroup_freezer) can reliably synchronize > the child's state to the cgroup it belongs to. Why can't cpuset? Is > there something fundamentally missing in the cgroup API? > cgroup_freezer uses the fork callback. We can also do this for cpuset as suggested by David, which adds a little bit overhead to the fork path. David, care to send out a patch? >>> It needs to be slightly rewritten to work properly without negatively >>> impacting the latency of fork(). Do you have the cycles to do it? >>> >> >> Sounds you have other idea? > > I don't think the suggested patch breaks anything more than it was > broken before and we should probably apply it for the time being. Li? > Yeah, we should apply Gu Zheng's patch any way. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by kanga.kvack.org (Postfix) with ESMTP id 8162A6B0031 for ; Mon, 23 Jun 2014 22:29:53 -0400 (EDT) Received: by mail-pa0-f44.google.com with SMTP id rd3so6631051pab.3 for ; Mon, 23 Jun 2014 19:29:53 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com. [119.145.14.64]) by mx.google.com with ESMTPS id sd3si24324172pac.94.2014.06.23.19.29.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 23 Jun 2014 19:29:52 -0700 (PDT) Message-ID: <53A8E23C.4050103@huawei.com> Date: Tue, 24 Jun 2014 10:28:12 +0800 From: Li Zefan MIME-Version: 1.0 Subject: Re: [PATCH] mm/mempolicy: fix sleeping function called from invalid context References: <53902A44.50005@cn.fujitsu.com> <20140605132339.ddf6df4a0cf5c14d17eb8691@linux-foundation.org> <539192F1.7050308@cn.fujitsu.com> <539574F1.2060701@cn.fujitsu.com> <53967465.7070908@huawei.com> <20140620210137.GA2059@mtj.dyndns.org> In-Reply-To: <20140620210137.GA2059@mtj.dyndns.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Tejun Heo Cc: David Rientjes , Gu Zheng , Andrew Morton , linux-kernel , linux-mm@kvack.org, Cgroups , stable@vger.kernel.org On 2014/6/21 5:01, Tejun Heo wrote: > Hello, Li. > > Sorry about the long delay. > > On Tue, Jun 10, 2014 at 10:58:45AM +0800, Li Zefan wrote: >> Yes, this is a long-standing issue. Besides the race you described, the child >> task's mems_allowed can be wrong if the cpuset's nodemask changes before the >> child has been added to the cgroup's tasklist. >> >> I remember Tejun once said he wanted to disallow task migration between >> cgroups during fork, and that should fix this problem. > > I'm having trouble remembering but yeah enforcing stricter behavior > across fork could be beneficial. Hmmm... the problem with making > forks exclusive against migrations is that we'll end up adding more > locking to the fork path which isn't too nice. > > Hmmm... other controllers (cgroup_freezer) can reliably synchronize > the child's state to the cgroup it belongs to. Why can't cpuset? Is > there something fundamentally missing in the cgroup API? > cgroup_freezer uses the fork callback. We can also do this for cpuset as suggested by David, which adds a little bit overhead to the fork path. David, care to send out a patch? >>> It needs to be slightly rewritten to work properly without negatively >>> impacting the latency of fork(). Do you have the cycles to do it? >>> >> >> Sounds you have other idea? > > I don't think the suggested patch breaks anything more than it was > broken before and we should probably apply it for the time being. Li? > Yeah, we should apply Gu Zheng's patch any way. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: Li Zefan Subject: Re: [PATCH] mm/mempolicy: fix sleeping function called from invalid context Date: Tue, 24 Jun 2014 10:28:12 +0800 Message-ID: <53A8E23C.4050103@huawei.com> References: <53902A44.50005@cn.fujitsu.com> <20140605132339.ddf6df4a0cf5c14d17eb8691@linux-foundation.org> <539192F1.7050308@cn.fujitsu.com> <539574F1.2060701@cn.fujitsu.com> <53967465.7070908@huawei.com> <20140620210137.GA2059@mtj.dyndns.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20140620210137.GA2059@mtj.dyndns.org> Sender: stable-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" To: Tejun Heo Cc: David Rientjes , Gu Zheng , Andrew Morton , linux-kernel , linux-mm@kvack.org, Cgroups , stable@vger.kernel.org On 2014/6/21 5:01, Tejun Heo wrote: > Hello, Li. > > Sorry about the long delay. > > On Tue, Jun 10, 2014 at 10:58:45AM +0800, Li Zefan wrote: >> Yes, this is a long-standing issue. Besides the race you described, the child >> task's mems_allowed can be wrong if the cpuset's nodemask changes before the >> child has been added to the cgroup's tasklist. >> >> I remember Tejun once said he wanted to disallow task migration between >> cgroups during fork, and that should fix this problem. > > I'm having trouble remembering but yeah enforcing stricter behavior > across fork could be beneficial. Hmmm... the problem with making > forks exclusive against migrations is that we'll end up adding more > locking to the fork path which isn't too nice. > > Hmmm... other controllers (cgroup_freezer) can reliably synchronize > the child's state to the cgroup it belongs to. Why can't cpuset? Is > there something fundamentally missing in the cgroup API? > cgroup_freezer uses the fork callback. We can also do this for cpuset as suggested by David, which adds a little bit overhead to the fork path. David, care to send out a patch? >>> It needs to be slightly rewritten to work properly without negatively >>> impacting the latency of fork(). Do you have the cycles to do it? >>> >> >> Sounds you have other idea? > > I don't think the suggested patch breaks anything more than it was > broken before and we should probably apply it for the time being. Li? > Yeah, we should apply Gu Zheng's patch any way.