powerpc/mm: Handle removing maybe-present bolted HPTEs
authorDavid Gibson <david@gibson.dropbear.id.au>
Tue, 9 Feb 2016 03:32:41 +0000 (13:32 +1000)
committerMichael Ellerman <mpe@ellerman.id.au>
Tue, 1 Mar 2016 11:04:18 +0000 (22:04 +1100)
commit27828f98a0522ad4a745a80407d051e5874c8d93
treeaf9b66562749a261ea8b3a493d778748ea4c5ca1
parentabd0a0e7914a1137973119ac3b3cace26e8ffa96
powerpc/mm: Handle removing maybe-present bolted HPTEs

At the moment the hpte_removebolted callback in ppc_md returns void and
will BUG_ON() if the hpte it's asked to remove doesn't exist in the first
place.  This is awkward for the case of cleaning up a mapping which was
partially made before failing.

So, we add a return value to hpte_removebolted, and have it return ENOENT
in the case that the HPTE to remove didn't exist in the first place.

In the (sole) caller, we propagate errors in hpte_removebolted to its
caller to handle.  However, we handle ENOENT specially, continuing to
complete the unmapping over the specified range before returning the error
to the caller.

This means that htab_remove_mapping() will work sanely on a partially
present mapping, removing any HPTEs which are present, while also returning
ENOENT to its caller in case it's important there.

There are two callers of htab_remove_mapping():
   - In remove_section_mapping() we already WARN_ON() any error return,
     which is reasonable - in this case the mapping should be fully
     present
   - In vmemmap_remove_mapping() we BUG_ON() any error.  We change that to
     just a WARN_ON() in the case of ENOENT, since failing to remove a
     mapping that wasn't there in the first place probably shouldn't be
     fatal.

Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
arch/powerpc/include/asm/machdep.h
arch/powerpc/mm/hash_utils_64.c
arch/powerpc/mm/init_64.c
arch/powerpc/platforms/pseries/lpar.c