From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752618AbcF2FFr (ORCPT ); Wed, 29 Jun 2016 01:05:47 -0400 Received: from mx2.suse.de ([195.135.220.15]:49156 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751266AbcF2FFp (ORCPT ); Wed, 29 Jun 2016 01:05:45 -0400 Subject: Re: [PATCH 1/2] cgroup: pids: show number of failed forks since limit reset To: Tejun Heo References: <20160624030049.13341-1-asarai@suse.de> <20160624030049.13341-2-asarai@suse.de> <20160624153151.GQ3262@mtj.duckdns.org> <78d17b23-d712-7d9c-3655-34c646bc4897@suse.de> <20160626234258.GJ9219@stj.duckdns.org> Cc: Jonathan Corbet , Li Zefan , Johannes Weiner , Kenny Yu , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org From: Aleksa Sarai Message-ID: Date: Wed, 29 Jun 2016 15:10:26 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <20160626234258.GJ9219@stj.duckdns.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Sun, Jun 26, 2016 at 09:34:41PM +1000, Aleksa Sarai wrote: >> If a user has a setup where they wait for notifications on changes to >> pids.event, and then auto-adjust the cgroup limits based on the number of >> failures you have a race condition between reading the pids.event file and >> then setting the new limit. Then, upon getting notified again there may have >> been many failed forks with the old limit set, so you might decide to bump >> up the limit again. >> >> It's not a huge deal, I just though it could be useful to alleviate problems >> like the above. > > This is something which can easily be avoided from userland. I don't > think we need to add extra facilities for this. Maybe I'm misunderstanding what the purpose of pids.events is meant to be. If it's just meant to be a "hint" to the administrator, then that seems like an awfully odd way of giving hints (the kernel logging should be enough for that). If it's meant so that the administrator can make policy decisions, then she won't know if the change in failures happened before or after she adjusted the limit. I also don't see what you mean by "it can be avoided from userland". There's a race between changing pids.max and a process forking that causes pids.events to be updated. -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/