[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190321064029.GW18740@MiWiFi-R3L-srv>
Date: Thu, 21 Mar 2019 14:40:29 +0800
From: Baoquan He <bhe@...hat.com>
To: Matthew Wilcox <willy@...radead.org>,
Mike Rapoport <rppt@...ux.ibm.com>,
Oscar Salvador <osalvador@...e.de>
Cc: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
pasha.tatashin@...cle.com, mhocko@...e.com,
rppt@...ux.vnet.ibm.com, richard.weiyang@...il.com,
linux-mm@...ck.org
Subject: Re: [PATCH 1/3] mm/sparse: Clean up the obsolete code comment
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
text's fault?
Personal opinion.
Thanks
Baoquan
>
> $ errno ENOSPC
> ENOSPC 28 No space left on device
>
> net/sunrpc/auth_gss/gss_rpc_xdr.c: return -ENOSPC;
>
> ... that's an authentication failure, not "I've run out of disc space".
Powered by blists - more mailing lists