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

[Baoquan He <bhe@redhat.com>]

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