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.
