Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp787033ybh; Wed, 11 Mar 2020 10:47:34 -0700 (PDT) X-Google-Smtp-Source: ADFU+vszOnqn6SxbUfPAhkwbutWDfBcoKY44WZZeIhTTa4A4OXHgZl5x5ZU2BZHnYIa9J1qH4rUI X-Received: by 2002:aca:ef82:: with SMTP id n124mr2659771oih.73.1583948854670; Wed, 11 Mar 2020 10:47:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1583948854; cv=none; d=google.com; s=arc-20160816; b=FmHjk0zxEBhIIFXjzHl5v9zykgnoJBlIo2hBiXnxF3ly2501QBv5DIotsLN3teXkz2 i/nlXHFktcFAinDhg828430DKzs01N0cURrleHMfBcXqrJAl7O7WwZMAum9avVhdeFhG y+eMVTYkhYP33syj9fglnlHyW3OCpRIAaNQ6qeU35u8vrYuSaYgah6OqmtHxTQXCmmZI bAjlKio6CrSiJXXDnEK/XK+Vf8ZGm0P4vBf1yuhkodx/T2Cob4gpOnufw0uS6yX2u2Ad xu2J4sbOHcF+UaTS64Nj1kXkaUGm9cLDPGYWHU7lfeGiadCdWfn6xSRoLjVsBAQKpp3R tKnw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=mlpzXRhsMRDH1YY7GqVuVp0TT22uI+TLEFO2W2lrSms=; b=xbREO/CIHbK6p/ie+CPp6v2XWUdMLa4v1junsvOqcXyKMSrR9HpuSCOU6uS47+o3KN oI295FN1+ksOyKWQC1ibKgjrsTWNhA42rFBcekrHbM0OrwYZH4pZUr59uqCxbArjsW9K Mx4KoFDMlIwlc8vFkSLdpUU3fdZmXBhtJ4tKxQRTlOu+yqEYcPtzNxMUaC0HhAPjfnxn 8d/2T0ylEFKIrySO7r7b9G5eBo2U8GOLn1fBki0Yr3TdpKdCXRE92LYeqnkjDL9tWm2/ 4KewigpLYmYeg5R6SaNEXt92Igts/ZIDwD4HmE1mwngxabdXFdi2xAxL4dWKyq+9fyCU b+Jw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=bkrnUftX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w83si1347822oie.244.2020.03.11.10.47.22; Wed, 11 Mar 2020 10:47:34 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=bkrnUftX; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730570AbgCKRqy (ORCPT + 99 others); Wed, 11 Mar 2020 13:46:54 -0400 Received: from mail-lj1-f194.google.com ([209.85.208.194]:41094 "EHLO mail-lj1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730487AbgCKRqx (ORCPT ); Wed, 11 Mar 2020 13:46:53 -0400 Received: by mail-lj1-f194.google.com with SMTP id o10so3306580ljc.8 for ; Wed, 11 Mar 2020 10:46:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mlpzXRhsMRDH1YY7GqVuVp0TT22uI+TLEFO2W2lrSms=; b=bkrnUftXBQZT9mtbI/EX+cveDpBLPJw5YgtyI66gzgie3phE0v0QHsOzjvTZVZ9Sk5 LZ2SeHAHTgtVv59iU8D+Q7y72uG/GpzZXa2WL2mVl0sVqSY9OOVxXTrzzW8TJ3QRqwR9 D3x7FIW1oNXUbRu0geCKaQRCITuGpqDhunFslSWLg1b6t8soT29RKgj1UEZczzHuamxP yr+uoZzFijDhwi/CPUOKKeXaPBi1t9Y7X22XObnK9HSc8gmO1V2npZZUMOpOPRT7DKRu Erbbj3Pp4Dkg6QYdOABx0A91KfBGxJP1nWbHQGaUBWPLpbU60f66M0QrmL1Q2AQsT5hk kJMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mlpzXRhsMRDH1YY7GqVuVp0TT22uI+TLEFO2W2lrSms=; b=MNLjLetse+WFozw0d4/oeyQjqyuHOsszLPKInj9JVKsA18PgfRAHYZ9SSZun9O5/NG cWmViFc2yYfE77NXeGTZAljAc0ErnxCY6PZtM6j3jtaUQPPiEwl+iDawtCHPsGOOmh9V Bd/abr34Q72wyFwJUwhkTea4o/Yq4x3YeQjIpaPbAs0aQMJ3n+Bx21R+A/juk4upj/bC +Yc3sq9GspMOOFWzxgtUkbFNcuhS9VOZ0tVUZ7y9w8sj6BswwCd9GMYHy2doTIXf3pvG g/mkfeE9vZ1izYmQSj/Gg3Yel7DGRg0Aaq4/CVtju3OCte38C4Wh08b0s+4lGyBV5P5j 4t3g== X-Gm-Message-State: ANhLgQ13i3fDzd1Lgx5FDpeIqhDGJsBHKmyLGdhXA21aEvXuJ35xJylv YJ62BvMsJ1R/7fCECx6vOWmUfeYIo68c+QmE9nzClg== X-Received: by 2002:a2e:800a:: with SMTP id j10mr2690722ljg.23.1583948811038; Wed, 11 Mar 2020 10:46:51 -0700 (PDT) MIME-Version: 1.0 References: <20200219183231.50985-1-balejs@google.com> <20200303134855.GA186184@mtj.thefacebook.com> In-Reply-To: <20200303134855.GA186184@mtj.thefacebook.com> From: Daniel Colascione Date: Wed, 11 Mar 2020 10:46:15 -0700 Message-ID: Subject: Re: [PATCH] cgroup-v1: freezer: optionally killable freezer To: Tejun Heo Cc: Marco Ballesio , Roman Gushchin , cgroups@vger.kernel.org, linux-kernel , lizefan@huawei.com, Johannes Weiner , Jonathan Corbet , rjw@rjwysocki.net, Pavel Machek , len.brown@intel.com, "open list:DOCUMENTATION" , linux-pm@vger.kernel.org, Minchan Kim , Suren Baghdasaryan Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 3, 2020 at 5:48 AM Tejun Heo wrote: > > Hello, > > On Wed, Feb 19, 2020 at 10:32:31AM -0800, Marco Ballesio wrote: > > @@ -94,6 +94,18 @@ The following cgroupfs files are created by cgroup freezer. > > Shows the parent-state. 0 if none of the cgroup's ancestors is > > frozen; otherwise, 1. > > > > +* freezer.killable: Read-write > > + > > + When read, returns the killable state of a cgroup - "1" if frozen > > + tasks will respond to fatal signals, or "0" if they won't. > > + > > + When written, this property sets the killable state of the cgroup. > > + A value equal to "1" will switch the state of all frozen tasks in > > + the cgroup to TASK_INTERRUPTIBLE (similarly to cgroup v2) and will > > + make them react to fatal signals. A value of "0" will switch the > > + state of frozen tasks to TASK_UNINTERRUPTIBLE and they won't respond > > + to signals unless thawed or unfrozen. > > As Roman said, I'm not too sure about adding a new cgroup1 freezer > interface at this point. If we do this, *maybe* a mount option would > be more minimal? I'd still prefer a cgroup flag. A mount option is a bigger compatibility risk and isn't really any simpler than another cgroup flag. A mount option will affect anything using the cgroup mount point, potentially turning non-killable frozen processes into killable ones unexpectedly. (Sure, you could mount multiple times, but only one location is canonical, and that's the one that's going to get the flag flipped.) A per-cgroup flag allows people to opt into the new behavior only in specific contexts, so it's safer.