All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oscar Salvador <osalvador@suse.de>
To: Matthew Wilcox <willy@infradead.org>
Cc: Baoquan He <bhe@redhat.com>,
	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
Date: Wed, 20 Mar 2019 13:37:47 +0100	[thread overview]
Message-ID: <20190320123747.vzreusrqx74zkdfm@d104.suse.de> (raw)
In-Reply-To: <20190320122243.GX19508@bombadil.infradead.org>

On Wed, Mar 20, 2019 at 05:22:43AM -0700, Matthew Wilcox wrote:
> On Wed, Mar 20, 2019 at 01:20:15PM +0100, Oscar Salvador wrote:
> > On Wed, Mar 20, 2019 at 04:19:59AM -0700, Matthew Wilcox wrote:
> > > On Wed, Mar 20, 2019 at 03:35:38PM +0800, Baoquan He wrote:
> > > >  /*
> > > > - * returns the number of sections whose mem_maps were properly
> > > > - * set.  If this is <=0, then that means that the passed-in
> > > > - * map was not consumed and must be freed.
> > > > + * sparse_add_one_section - add a memory section
> > > > + * @nid:	The node to add section on
> > > > + * @start_pfn:	start pfn of the memory range
> > > > + * @altmap:	device page map
> > > > + *
> > > > + * Return 0 on success and an appropriate error code otherwise.
> > > >   */
> > > 
> > > I think it's worth documenting what those error codes are.  Seems to be
> > > just -ENOMEM and -EEXIST, but it'd be nice for users to know what they
> > > can expect under which circumstances.
> > > 
> > > Also, -EEXIST is a bad errno to return here:
> > > 
> > > $ errno EEXIST
> > > EEXIST 17 File exists
> > > 
> > > What file?  I think we should be using -EBUSY instead in case this errno
> > > makes it back to userspace:
> > > 
> > > $ errno EBUSY
> > > EBUSY 16 Device or resource busy
> > 
> > We return -EEXIST in case the section we are trying to add is already
> > there, and that error is being caught by __add_pages(), which ignores the
> > error in case is -EXIST and keeps going with further sections.
> > 
> > Sure we can change that for -EBUSY, but I think -EEXIST makes more sense,
> > plus that kind of error is never handed back to userspace.
> 
> Not returned to userspace today.  It's also bad precedent for other parts
> of the kernel where errnos do get returned to userspace.

Yes, I get your point, but I do not really see -EBUSY fitting here.
Actually, we do have the same kind of situation when dealing with resources.
We return -EEXIST in register_memory_resource() in case the resource we are
trying to add conflicts with another one.

I think that -EEXIST is more intuitive in that code path, but I am not going to
insist.

-- 
Oscar Salvador
SUSE L3

      parent reply	other threads:[~2019-03-20 12:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20  7:35 [PATCH 1/3] mm/sparse: Clean up the obsolete code comment Baoquan He
2019-03-20  7:35 ` [PATCH 2/3] mm/sparse: Optimize sparse_add_one_section() Baoquan He
2019-03-20  7:56   ` Mike Rapoport
2019-03-20  8:03     ` Baoquan He
2019-03-20 10:13     ` Baoquan He
2019-03-20 11:22       ` Matthew Wilcox
2019-03-20 11:27       ` Mike Rapoport
2019-03-20  7:35 ` [PATCH 3/3] mm/sparse: Rename function related to section memmap allocation/free Baoquan He
2019-03-20  7:50 ` [PATCH 1/3] mm/sparse: Clean up the obsolete code comment Mike Rapoport
2019-03-20  8:00   ` Baoquan He
2019-03-20 11:19 ` Matthew Wilcox
2019-03-20 11:53   ` Baoquan He
2019-03-20 12:20   ` Oscar Salvador
2019-03-20 12:22     ` Matthew Wilcox
2019-03-20 12:36       ` Mike Rapoport
2019-03-20 12:58         ` Matthew Wilcox
2019-03-21  6:40           ` Baoquan He
2019-03-21  9:21             ` Baoquan He
2019-03-21 10:24               ` William Kucharski
2019-03-21 10:35                 ` Michal Hocko
2019-03-21 11:19                   ` William Kucharski
2019-03-21 14:19                     ` Baoquan He
2019-03-20 12:37       ` Oscar Salvador [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190320123747.vzreusrqx74zkdfm@d104.suse.de \
    --to=osalvador@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=bhe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=pasha.tatashin@oracle.com \
    --cc=richard.weiyang@gmail.com \
    --cc=rppt@linux.vnet.ibm.com \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.