| Message ID | 1454045043-25545-3-git-send-email-david@gibson.dropbear.id.au (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On 01/29/2016 10:53 AM, David Gibson wrote: > Currently, the only error that htab_remove_mapping() can report is -EINVAL, > if removal of bolted HPTEs isn't implemeted for this platform. We make > a few clean ups to the handling of this: > > * EINVAL isn't really the right code - there's nothing wrong with the > function's arguments - use ENODEV instead You are right, guess there are other places with this kind of problem as well. > * We were also printing a warning message, but that's a decision better > left up to the callers, so remove it > * One caller is vmemmap_remove_mapping(), which will just BUG_ON() on > error, making the warning message irrelevant, so no change is needed > there. It makes it redundant not irrelevant. It still prints a valid reason why the remove operation failed. > * The other caller is remove_section_mapping(). This is called in the > memory hot remove path at a point after vmemmap_remove_mapping() so > if hpte_removebolted isn't implemented, we'd expect to have already > BUG()ed anyway. Put a WARN_ON() here, in lieu of a printk() since this > really shouldn't be happening. Right.
On Fri, Jan 29, 2016 at 04:23:56PM +1100, David Gibson wrote: > Currently, the only error that htab_remove_mapping() can report is -EINVAL, > if removal of bolted HPTEs isn't implemeted for this platform. We make > a few clean ups to the handling of this: > > * EINVAL isn't really the right code - there's nothing wrong with the > function's arguments - use ENODEV instead > * We were also printing a warning message, but that's a decision better > left up to the callers, so remove it > * One caller is vmemmap_remove_mapping(), which will just BUG_ON() on > error, making the warning message irrelevant, so no change is needed > there. > * The other caller is remove_section_mapping(). This is called in the > memory hot remove path at a point after vmemmap_remove_mapping() so > if hpte_removebolted isn't implemented, we'd expect to have already > BUG()ed anyway. Put a WARN_ON() here, in lieu of a printk() since this > really shouldn't be happening. > > Signed-off-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Paul Mackerras <paulus@samba.org>
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c index ba59d59..9f7d727 100644 --- a/arch/powerpc/mm/hash_utils_64.c +++ b/arch/powerpc/mm/hash_utils_64.c @@ -273,11 +273,8 @@ int htab_remove_mapping(unsigned long vstart, unsigned long vend, shift = mmu_psize_defs[psize].shift; step = 1 << shift; - if (!ppc_md.hpte_removebolted) { - printk(KERN_WARNING "Platform doesn't implement " - "hpte_removebolted\n"); - return -EINVAL; - } + if (!ppc_md.hpte_removebolted) + return -ENODEV; for (vaddr = vstart; vaddr < vend; vaddr += step) ppc_md.hpte_removebolted(vaddr, psize, ssize); @@ -641,8 +638,10 @@ int create_section_mapping(unsigned long start, unsigned long end) int remove_section_mapping(unsigned long start, unsigned long end) { - return htab_remove_mapping(start, end, mmu_linear_psize, - mmu_kernel_ssize); + int rc = htab_remove_mapping(start, end, mmu_linear_psize, + mmu_kernel_ssize); + WARN_ON(rc < 0); + return rc; } #endif /* CONFIG_MEMORY_HOTPLUG */
Currently, the only error that htab_remove_mapping() can report is -EINVAL, if removal of bolted HPTEs isn't implemeted for this platform. We make a few clean ups to the handling of this: * EINVAL isn't really the right code - there's nothing wrong with the function's arguments - use ENODEV instead * We were also printing a warning message, but that's a decision better left up to the callers, so remove it * One caller is vmemmap_remove_mapping(), which will just BUG_ON() on error, making the warning message irrelevant, so no change is needed there. * The other caller is remove_section_mapping(). This is called in the memory hot remove path at a point after vmemmap_remove_mapping() so if hpte_removebolted isn't implemented, we'd expect to have already BUG()ed anyway. Put a WARN_ON() here, in lieu of a printk() since this really shouldn't be happening. Signed-off-by: David Gibson <david@gibson.dropbear.id.au> --- arch/powerpc/mm/hash_utils_64.c | 13 ++++++------- 1 file changed, 6 insertions(+), 7 deletions(-)