Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp482482img; Thu, 21 Mar 2019 02:22:39 -0700 (PDT) X-Google-Smtp-Source: APXvYqxbtTXAXP1gAUVpAywVVfdQUDOmIpaa3koak0bnXS4yfZnLu5Pd+a5/mlapc0sQo6Wefpol X-Received: by 2002:a63:441b:: with SMTP id r27mr2326914pga.36.1553160159834; Thu, 21 Mar 2019 02:22:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553160159; cv=none; d=google.com; s=arc-20160816; b=ikmQNFktznRrAhVWiQGDGh4JomOJJ3M+r8sQiAVdPhxryF/VtOCPZz/B++M736UKSA aip6EK41XgbGzKRmqA5MVoERyW9ZoCYCOAlfIPClafD55FJ3C9/yz0F8zkrK3fNtxpjs x86XPLZJfrX2fWh+Fu0DDaJVrv/Tf/zz+Qg83TWuchjQjm0GwhWFe7F9n9Vni99r40ut iSGXniI+Q0C3LCs4W2v38AEFjSHP0QGbdTxTgUdqhy3JL76cKBwFmYgaPTGx7AteF81V p5SOfZ6oBs1qLXG6xyQhDvxGoCOI0DfI/fItgTBuPWq/toHXGjAvWE/A4i+Yx+zi2rA0 fgUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=AVT41CEyC25KmfkzIyCyWF8KIQqm++BNqyfkHFE/lJ8=; b=TBpIh9Jt4671EB0tC4y3mpvgQ+FPgnn5miSeWhbT6X+kEtHjUsuf/dz1B53ALYPEF6 Fmk9OBtRmxtdzKMzKqZUXM9hvJI7uoYVUZwzAhCL5kCml31xbf4EKaZGiskridJZyEoS 4QvNm0N2Lht1ogYbcnecz9tuE6CNNVrQTxKkY58/zW4I4iw6lv93Id5bkuOSLdrNfLd2 nnGrvWSU1fAyiYfi6s01On+05hunVlvjcdFBtAUpT6Lq59UvwtHZ3YacjKD783oR31hK i0ZYrbhKNgH4ib6/ZAz0k3vVeAbVMyrA0XfVDXuAVYxxmri3ntAnyoin/RuYty+0S9I4 6grg== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m3si3685911pgp.263.2019.03.21.02.22.24; Thu, 21 Mar 2019 02:22:39 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728001AbfCUJVq (ORCPT + 99 others); Thu, 21 Mar 2019 05:21:46 -0400 Received: from mx1.redhat.com ([209.132.183.28]:58976 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727868AbfCUJVq (ORCPT ); Thu, 21 Mar 2019 05:21:46 -0400 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AB603F74A8; Thu, 21 Mar 2019 09:21:45 +0000 (UTC) Received: from localhost (ovpn-12-72.pek2.redhat.com [10.72.12.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id CD0F3600C1; Thu, 21 Mar 2019 09:21:42 +0000 (UTC) Date: Thu, 21 Mar 2019 17:21:38 +0800 From: Baoquan He To: Matthew Wilcox , Mike Rapoport , Oscar Salvador Cc: linux-kernel@vger.kernel.org, akpm@linux-foundation.org, pasha.tatashin@oracle.com, mhocko@suse.com, rppt@linux.vnet.ibm.com, richard.weiyang@gmail.com, linux-mm@kvack.org Subject: Re: [PATCH 1/3] mm/sparse: Clean up the obsolete code comment Message-ID: <20190321092138.GY18740@MiWiFi-R3L-srv> References: <20190320073540.12866-1-bhe@redhat.com> <20190320111959.GV19508@bombadil.infradead.org> <20190320122011.stuoqugpjdt3d7cd@d104.suse.de> <20190320122243.GX19508@bombadil.infradead.org> <20190320123658.GF13626@rapoport-lnx> <20190320125843.GY19508@bombadil.infradead.org> <20190321064029.GW18740@MiWiFi-R3L-srv> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190321064029.GW18740@MiWiFi-R3L-srv> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Thu, 21 Mar 2019 09:21:45 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/21/19 at 02:40pm, Baoquan He wrote: > Hi all, > > On 03/20/19 at 05:58am, Matthew Wilcox wrote: > > On Wed, Mar 20, 2019 at 02:36:58PM +0200, Mike Rapoport wrote: > > > There are more than a thousand -EEXIST in the kernel, I really doubt all of > > > them mean "File exists" ;-) > > > > And yet that's what the user will see if it's ever printed with perror() > > or similar. We're pretty bad at choosing errnos; look how abused > > ENOSPC is: > > When I tried to change -EEXIST to -EBUSY, seems the returned value will > return back over the whole path. And -EEXIST is checked explicitly > several times during the path. > > acpi_memory_enable_device -> __add_pages .. -> __add_section -> sparse_add_one_section > > Only look into hotplug path triggered by ACPI event, there are also > device memory and ballon memory paths I haven't checked carefully > because not familiar with them. > > So from the checking, I tend to agree with Oscar and Mike. There have > been so many places to use '-EEXIST' to indicate that stuffs checked have > been existing. We can't deny it's inconsistent with term explanation > text. While the defense is that -EEXIST is more precise to indicate a > static instance has been present when we want to create it, but -EBUSY > is a little blizarre. I would rather see -EBUSY is used on a device. > When want to stop it or destroy it, need check if it's busy or not. > > #define EBUSY 16 /* Device or resource busy */ > #define EEXIST 17 /* File exists */ > > Obviously saying resource busy or not, it violates semanics in any > language. So many people use EEXIST instead, isn't it the obsolete Surely when we require a lock which is protecting resource, we can also return -EBUSY since someone is busy on this resource. For creating one instance, just check if the instance exists already, no matter what the code comment of the errno is saying, IMHO, it really should not be -EBUSY. Thanks Baoquan