]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commit272c2f50c2e7402d676b50ba0c51e4fec15d042c
treeaf9b66562749a261ea8b3a493d778748ea4c5ca1
parent574d31b7a9a37812c905b5ad729def4bf945dd15
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