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=-1.0 required=3.0 tests=MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 98CC1C2BB1D for ; Tue, 7 Apr 2020 11:10:22 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 64BAB206F7 for ; Tue, 7 Apr 2020 11:10:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 64BAB206F7 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 0B02C8E0024; Tue, 7 Apr 2020 07:10:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 061518E0001; Tue, 7 Apr 2020 07:10:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EB80F8E0024; Tue, 7 Apr 2020 07:10:21 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0191.hostedemail.com [216.40.44.191]) by kanga.kvack.org (Postfix) with ESMTP id D12DE8E0001 for ; Tue, 7 Apr 2020 07:10:21 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 94E3999BE for ; Tue, 7 Apr 2020 11:10:21 +0000 (UTC) X-FDA: 76680790242.23.hand18_777f7c8e24c28 X-HE-Tag: hand18_777f7c8e24c28 X-Filterd-Recvd-Size: 5184 Received: from mail-wr1-f67.google.com (mail-wr1-f67.google.com [209.85.221.67]) by imf50.hostedemail.com (Postfix) with ESMTP for ; Tue, 7 Apr 2020 11:10:21 +0000 (UTC) Received: by mail-wr1-f67.google.com with SMTP id g3so3417809wrx.2 for ; Tue, 07 Apr 2020 04:10:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=AqswjrGg7XNWbBt+aofKEmgNrhnuVAzX6thcVWXwl9g=; b=NVQI8mgtFGNTX5rfg5N60Q1olHqs5/k/5GJBaKrwBART0cR1gVpLAHNe3vTheNRjpx mod9+cxNiPj2ao9VQlRiEnzfmbc9fa6niu9MCbJYSeCKci8jiM5yNQrxTVDPxUL8gXms X2PoZrNPUbT7mJ9eaUIJE/744fANXKGcBGT4hV2Ee8scq7/k4YFuiNY73XiTGtbVbD0P YgdP2zWmNSQQhXVrR62Fa2L2JIkJ76o4fcCayRcfLgCD/93/U7buCxkgg3SatkyKR4t+ YY/dIZpn/mGRk0qnK198LDuI1VwfI+3r0Wqlz75xg9xrBCbi3bkAtWRan27yZFAcL0Iy ufqA== X-Gm-Message-State: AGi0PubAbDdzeWSlt0yWE3vTqem0OR+N7QqSC9tgtHYeGSH51QCd4sma Sws9YMyFlOjApBeIqkdzExY= X-Google-Smtp-Source: APiQypJ+Uk40EIytihXmJkDVQCoGMP1Gah1yNlr0FOjsoyM0cHdTtKJ0Dw5NRG1MBnNULx/CVSk7AA== X-Received: by 2002:a5d:6742:: with SMTP id l2mr2330338wrw.124.1586257819916; Tue, 07 Apr 2020 04:10:19 -0700 (PDT) Received: from localhost (ip-37-188-180-223.eurotel.cz. [37.188.180.223]) by smtp.gmail.com with ESMTPSA id u17sm33467059wri.45.2020.04.07.04.10.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Apr 2020 04:10:18 -0700 (PDT) Date: Tue, 7 Apr 2020 13:10:17 +0200 From: Michal Hocko To: Yafang Shao Cc: Andrew Morton , Matthew Wilcox , Johannes Weiner , Vladimir Davydov , Linux MM Subject: Re: [PATCH v3] mm, memcg: fix error return value of mem_cgroup_css_alloc() Message-ID: <20200407111017.GN18914@dhcp22.suse.cz> References: <1586192163-20099-1-git-send-email-laoar.shao@gmail.com> <20200406162343.6ae4b8f74c74bcb84d026471@linux-foundation.org> <20200406200916.2623f34403155264d8c8e9e7@linux-foundation.org> <20200407064329.GB18914@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: On Tue 07-04-20 17:31:33, Yafang Shao wrote: > On Tue, Apr 7, 2020 at 2:43 PM Michal Hocko wrote: > > > > [I have only now noticed there was another version posted. Please try to > > wait a bit longer for other feedback before reposting a newer version] > > > > Sure I will. sorry about that. > But after we send a patch, we always don't know in which state this > patch is, e.g. Changes Requested, Not Applicable, Rejected, Needs > Review / ACK and etc, as listed in netdev list[1]. That could give us > an explicit instruction on what to do next. Yes I can see how that can be unclear or consuming at times. But a general rule of thumb I would suggest is to simply wait few days before reposting a new version. If you need to discuss an incremental change based on the review feedback you can always do that in the original email thread and repost the new version after the review feedback settles. > [1]. https://patchwork.ozlabs.org/project/netdev/list/?state=*&page=2¶m=3 > > > On Tue 07-04-20 11:11:13, Yafang Shao wrote: [...] > > See my comment about EBUSY in the previous version > > http://lkml.kernel.org/r/20200407063621.GA18914@dhcp22.suse.cz > > > > >From the perspective of mkdir(2), it is better to use ENOSPC here. But > I'm not sure whether it is better to update the man page of mkdir(2) > or not. Well, I do not know whether EBUSY missing in the man page is an omission or an intention. But adding it only for this single operation failure would sound like an overkill to me. > I checked the explaination about ENOSPC in 73f576c04b94 ("mm: > memcontrol: fix cgroup creation failure after many small jobs") > carefully, but I don't a clear idea which one is better now. The changelog simply mentioned that without the additional id tracking the ENOSPC would have been returned from elsewhere. I haven't checked but I suspect it would be from the cgroup core. This patch just didn't propagate the idr failure specifically and hid it under the ENOMEM failure path. I can only speculate why that was the case but I suspect that Johannes simply didn't consider the distinction important enough. All I am saying is that preserving the failure mode would be preferable. Especially unless there a strong reason to use EBUSY which then should be carefully explained in the changelog. -- Michal Hocko SUSE Labs