Re: [PATCH] mm/vmalloc: Check absolute error return from vmap_[p4d|pud|pmd|pte]_range()

From: Matthew Wilcox
Date: Fri Jun 14 2019 - 09:47:10 EST


On Fri, Jun 14, 2019 at 10:57:42AM +0530, Anshuman Khandual wrote:
>
>
> On 06/13/2019 09:01 PM, Matthew Wilcox wrote:
> > On Thu, Jun 13, 2019 at 08:51:17PM +0530, Anshuman Khandual wrote:
> >> acceptable ? What we have currently is wrong where vmap_pmd_range() could
> >> just wrap EBUSY as ENOMEM and send up the call chain.
> >
> > It's not wrong. We do it in lots of places. Unless there's a caller
> > which really needs to know the difference, it's often better than
> > returning the "real error".
>
> I can understand the fact that because there are no active users of this
> return code, the current situation has been alright. But then I fail to
> understand how can EBUSY be made ENOMEM and let the caller to think that
> vmap_page_rage() failed because of lack of memory when it is clearly not
> the case. It is really surprising how it can be acceptable inside kernel
> (init_mm) page table functions which need to be thorough enough.

It's a corollary of Steinbach's Guideline for Systems Programming.
There is no possible way to handle this error because this error is
never supposed to happen. So we may as well return a different error
that will still lead to the caller doing the right thing.