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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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