Re: [PATCH 1/3] mm/sparse: Clean up the obsolete code comment

[Baoquan He <bhe@redhat.com>]

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".