From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id BEC93C43465 for ; Mon, 21 Sep 2020 14:38:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 683672220C for ; Mon, 21 Sep 2020 14:38:59 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="lluI7KGP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 683672220C Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EC5C790006E; Mon, 21 Sep 2020 10:38:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E4E49900069; Mon, 21 Sep 2020 10:38:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D165290006E; Mon, 21 Sep 2020 10:38:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0095.hostedemail.com [216.40.44.95]) by kanga.kvack.org (Postfix) with ESMTP id B979B900069 for ; Mon, 21 Sep 2020 10:38:58 -0400 (EDT) Received: from smtpin20.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 789CD181AEF15 for ; Mon, 21 Sep 2020 14:38:58 +0000 (UTC) X-FDA: 77287325556.20.start67_46094c527145 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin20.hostedemail.com (Postfix) with ESMTP id 0F0DA180C07AF for ; Mon, 21 Sep 2020 14:38:51 +0000 (UTC) X-HE-Tag: start67_46094c527145 X-Filterd-Recvd-Size: 5239 Received: from mail-qt1-f196.google.com (mail-qt1-f196.google.com [209.85.160.196]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 14:38:50 +0000 (UTC) Received: by mail-qt1-f196.google.com with SMTP id p65so12469532qtd.2 for ; Mon, 21 Sep 2020 07:38:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=QMHiWFQdsvZHKBI/j/7oYy979M/DAsi7XHjdGEu8DOk=; b=lluI7KGPFyOukCPwfQIYGmlkjVC0zPmyi+/1Efes0ZxI/qiF5mtDVjKBuYQR4Bidno +Grn4xepSRETquj1FSjZP65oo/nVJPpIJ47WsFCpKrrocSfDbivpKwynueRb1Jf5d17G UF0WKlzZc8fXvd1fPz09pzJsNY1ZTzjwlgGUFvB2pNYOtK/MdP2W/kKVWsYTzigi9ENS 98kapqDXy/tccuzjPeHbnjDQEvGWHayJep3AUpJUwc+pY8r7YZwMdg3/L04MH3HZR8Jf ooOV1DoRRXfK+0LqcUBIIhDAJa+TwfLDTQwq9gdKYaQY/63x70AaX+X/AgzrBS+peka1 oJUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=QMHiWFQdsvZHKBI/j/7oYy979M/DAsi7XHjdGEu8DOk=; b=qN9b50jYrXUZ8SwltFzBtHNZxgp9tdIdzfWjUMJOsb6ghx7MqYssyboLf2Aw+6k4CG rFp0b5X0VNKTeNn4c3A4wInxDz8KmCacG/QEmFZDuCU11kSqy3X8Lw1uvGNqJwm8Xb4f xWyx2OhDy65ngIvFTachCn8uY3Dv23iN+KvQCqoNGoNVMg2ooUfZsFk8J9tdFdKp1MN0 IANZInXcfdhxCiyUJ2SIHMBorF8v5eZJRapDqSoCO8Ygp/OyfcYBMhNvAIwmRHXJLJMq FlPmDGQqgFQZox/LRewO+KrQy4xJ9MJdCnAgBxZ3h4oAgZ5TDU2Ku5FflYNT6ufL32xn AA/A== X-Gm-Message-State: AOAM533RV5aImjaMS/zLxdfmflA47XxuOgOJn1nmPfyMekv/tfCF8c24 zMUW+3v+H0ztUZaKF7rOQrE= X-Google-Smtp-Source: ABdhPJzecNCAKF0YIZdZ2frAo/HvF0zJWZ70w2IuxkJ6PpqtVmpMDCAHcSVYUNSv5jfsRvd4iYhWPg== X-Received: by 2002:ac8:4e49:: with SMTP id e9mr34887724qtw.167.1600699129898; Mon, 21 Sep 2020 07:38:49 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:54a6]) by smtp.gmail.com with ESMTPSA id r24sm9825884qtm.70.2020.09.21.07.38.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Sep 2020 07:38:49 -0700 (PDT) Date: Mon, 21 Sep 2020 10:38:47 -0400 From: Tejun Heo To: Michal Hocko Cc: Peter Xu , Christian Brauner , Linus Torvalds , Jason Gunthorpe , John Hubbard , Leon Romanovsky , Linux-MM , Linux Kernel Mailing List , "Maya B . Gokhale" , Yang Shi , Marty Mcfadden , Kirill Shutemov , Oleg Nesterov , Jann Horn , Jan Kara , Kirill Tkhai , Andrea Arcangeli , Christoph Hellwig , Andrew Morton Subject: Re: [PATCH 1/4] mm: Trial do_wp_page() simplification Message-ID: <20200921143847.GB4268@mtj.duckdns.org> References: <20200916174804.GC8409@ziepe.ca> <20200916184619.GB40154@xz-x1> <20200917112538.GD8409@ziepe.ca> <20200917193824.GL8409@ziepe.ca> <20200918164032.GA5962@xz-x1> <20200921134200.GK12990@dhcp22.suse.cz> <20200921141830.GE5962@xz-x1> <20200921142834.GL12990@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200921142834.GL12990@dhcp22.suse.cz> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hello, On Mon, Sep 21, 2020 at 04:28:34PM +0200, Michal Hocko wrote: > Fundamentaly CLONE_INTO_CGROUP is similar to regular fork + move to the > target cgroup after the child gets executed. So in principle there > shouldn't be any big difference. Except that the move has to be explicit > and the the child has to have enough privileges to move itself. I am not Yeap, they're supposed to be the same operations. We've never clearly defined how the accounting gets split across moves because 1. it's inherently blurry and difficult 2. doesn't make any practical difference for the recommended and vast majority usage pattern which uses migration to seed the new cgroup. CLONE_INTO_CGROUP doesn't change any of that. > completely sure about CLONE_INTO_CGROUP model though. According to man > clone(2) it seems that O_RDONLY for the target cgroup directory is > sufficient. That seems much more relaxed IIUC and it would allow to fork > into a different cgroup while keeping a lot of resources in the parent's > proper. If the man page is documenting that, it's wrong. cgroup_css_set_fork() has an explicit cgroup_may_write() test on the destination cgroup. CLONE_INTO_CGROUP should follow exactly the same rules as regular migrations. Thanks. -- tejun