This way we don't need to care about the next_index wrapping
around in dma_ops_alloc_addresses.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

Instead of setting need_flush, do the flush directly in
dma_ops_free_addresses.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

It points to the next aperture index to allocate from. We
don't need the full address anymore because this is now
tracked in struct aperture_range.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

Parameter is not needed because the value is part of the
already passed in struct dma_ops_domain.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

Since the allocator wraparound happens in this function now,
flush the iommu tlb there too.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

Instead of skipping to the next aperture, first try again in
the current one.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

Moving it before the pte_pages array puts in into the same
cache-line as the spin-lock and the bitmap array pointer.
This should safe a cache-miss.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

Make this a wrapper around iommu_ops_area_alloc() for now
and add more logic to this function later on.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

The page-offset of the aperture must be passed instead of 0.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

This allows to keep the bitmap_lock only for a very short
period of time.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

There have been present PTEs which in theory could have made
it to the IOMMU TLB. Flush the addresses out on the error
path to make sure no stale entries remain.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

This lock only protects the address allocation bitmap in one
aperture.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

It is only used in this file anyway, so keep it there. Same
with 'struct aperture_range'.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

This prevents possible flooding of the kernel log.
Signed-off-by: Joerg Roedel <jroedel@suse.de>

This mmu_notifier_ops structure is never modified, so declare it as
const, like the other mmu_notifier_ops structures.

Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Joerg Roedel <jroedel@suse.de>

Get rid of the three error paths that look the same and move
error handling to a single place.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>

Instead of just checking for a write access, calculate the
flags that are passed to handle_mm_fault() more precisly and
use the pre-defined macros.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>

Not doing so is a bug and might trigger a BUG_ON in
handle_mm_fault(). So add the proper permission checks
before calling into mm code.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>

The handle_mm_fault function expects the caller to do the
access checks. Not doing so and calling the function with
wrong permissions is a bug (catched by a BUG_ON).
So fix this bug by adding proper access checking to the io
page-fault code in the AMD IOMMUv2 driver.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Acked-By: David Woodhouse <David.Woodhouse@intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>

Jan Stancek reported that I wrecked things for him by fixing things for
Vladimir :/

His report was due to an UNINTERRUPTIBLE wait getting -EINTR, which
should not be possible, however my previous patch made this possible by
unconditionally checking signal_pending().

We cannot use current->state as was done previously, because the
instruction after the store to that variable it can be changed.  We must
instead pass the initial state along and use that.

Fixes: 68985633 ("sched/wait: Fix signal handling in bit wait helpers")
Reported-by: Jan Stancek <jstancek@redhat.com>
Reported-by: Chris Mason <clm@fb.com>
Tested-by: Jan Stancek <jstancek@redhat.com>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com>
Tested-by: Chris Mason <clm@fb.com>
Reviewed-by: Paul Turner <pjt@google.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: tglx@linutronix.de
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: hpa@zytor.com
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Pull NFS client bugfix from Trond Myklebust:
 "SUNRPC: Fix a NFSv4.1 callback channel regression"

* tag 'nfs-for-4.4-3' of git://git.linux-nfs.org/projects/trondmy/linux-nfs:
  SUNRPC: Fix callback channel

Pull timer fixlets from Thomas Gleixner:
 "Two trivial fixes which add missing header fileas and forward
  declarations so the code will compile even when the magic include
  chains are different"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  irqchip/gic-v3: Add missing include for barrier.h
  irqchip/gic-v3: Add missing struct device_node declaration

Pull timer fix from Thomas Gleixner:
 "A single fix to unbreak a clocksource driver which has more than 32bit
  counter width"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  clocksource: Mmio: remove artificial 32bit limitation

Pull fpga driver fixes from Greg KH:
 "Only two small fpga driver fixes here, both have been in linux-next
  for a while, and resolve some reported issues"

* tag 'char-misc-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc:
  fpga manager: Fix firmware resource leak on error
  fpga manager: remove label

Pull staging driver fixes from Greg KH:
 "Here are a few staging and IIO driver fixes for 4.4-rc5.

  All of them resolve reported problems and have been in linux-next for
  a while.  Nothing major here, just small fixes where needed"

* tag 'staging-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging:
  staging: lustre: echo_copy.._lsm() dereferences userland pointers directly
  iio: adc: spmi-vadc: add missing of_node_put
  iio: fix some warning messages
  iio: light: apds9960: correct ->last_busy count
  iio: lidar: return -EINVAL on invalid signal
  staging: iio: dummy: complete IIO events delivery to userspace

Pull USB driver fixes from Greg KH:
 "Here are a number of small USB fixes for 4.4-rc5.  All of them have
  been in linux-next.  The majority are gadget and phy issues, with a
  few new quirks and device ids added as well"

* tag 'usb-4.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (32 commits)
  USB: add quirk for devices with broken LPM
  xhci: fix usb2 resume timing and races.
  usb: musb: fail with error when no DMA controller set
  usb: gadget: uvc: fix permissions of configfs attributes
  usb: musb: core: Fix pm runtime for deferred probe
  usb: phy: msm: fix a possible NULL dereference
  USB: host: ohci-at91: fix a crash in ohci_hcd_at91_overcurrent_irq
  usb: Quiet down false peer failure messages
  usb: xhci: fix config fail of FS hub behind a HS hub with MTT
  xhci: Fix memory leak in xhci_pme_acpi_rtd3_enable()
  usb: Use the USB_SS_MULT() macro to decode burst multiplier for log message
  USB: whci-hcd: add check for dma mapping error
  usb: core : hub: Fix BOS 'NULL pointer' kernel panic
  USB: quirks: Apply ALWAYS_POLL to all ELAN devices
  usb-storage: Fix scsi-sd failure "Invalid field in cdb" for USB adapter JMicron
  USB: quirks: Fix another ELAN touchscreen
  usb: dwc3: gadget: don't prestart interrupt endpoints
  USB: serial: Another Infineon flash loader USB ID
  USB: cdc_acm: Ignore Infineon Flash Loader utility
  USB: cp210x: Remove CP2110 ID from compatibility list
  ...

Pull ARM SoC fixes from Arnd Bergmann:
 "Here are a bunch of small bug fixes for various ARM platforms, nothing
  really sticks out this week, most of either fixes bugs in code that
  was just added in 4.4, or that has been broken for many years without
  anyone noticing.

  at91/sama5d2:
   - fix sama5de hardware setup of sd/mmc interface
   - proper selection of pinctrl drivers.  PIO4 is necessary for sama5d2

  berlin:
   - fix incorrect clock input for SDIO

  exynos:
   - Fix potential NULL pointer dereference in Exynos PMU driver.

  imx:
   - Fix vf610 SAI clock configuration bug which is discovered by the
     newly added master mode support in SAI audio driver.
   - Fix buggy L2 cache latency values in vf610 device trees, which may
     cause system hang when cpu runs at a higher frequency.

  ixp4xx:
   - fix prototypes for readl/writel functions

  ls2080a:
   - use little-endian register access for GPIO and SDHCI

  omap:
   - Fix clock source for ARM TWD and global timers on am437x
   - Always select REGULATOR_FIXED_VOLTAGE for omap2+ instead of when
     MACH_OMAP3_PANDORA is selected
   - Fix SPI DMA handles for dm816x as only some were mapped
   - Fix up mbox cells for dm816x to make mailbox usable

  pxa:
   - use PWM lookup table for all ezx machines

  s3c24xx:
   - Remove incorrect __init annotation from s3c24xx cpufreq driver
     structures.

  versatile:
   - fix PCI IRQ mapping on Versatile PB"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
  ls2080a/dts: Add little endian property for GPIO IP block
  dt-bindings: define little-endian property for QorIQ GPIO
  ARM64: dts: ls2080a: fix eSDHC endianness
  ARM: dts: vf610: use reset values for L2 cache latencies
  ARM: pxa: use PWM lookup table for all machines
  ARM: dts: berlin: add 2nd clock for BG2Q sdhci0 and sdhci1
  ARM: dts: berlin: correct BG2Q's sdhci2 2nd clock
  ARM: dts: am4372: fix clock source for arm twd and global timers
  ARM: at91: fix pinctrl driver selection
  ARM: at91/dt: add always-on to 1.8V regulator
  ARM: dts: vf610: fix clock definition for SAI2
  ARM: imx: clk-vf610: fix SAI clock tree
  ARM: ixp4xx: fix read{b,w,l} return types
  irqchip/versatile-fpga: Fix PCI IRQ mapping on Versatile PB
  ARM: OMAP2+: enable REGULATOR_FIXED_VOLTAGE
  ARM: dts: add dm816x missing spi DT dma handles
  ARM: dts: add dm816x missing #mbox-cells
  cpufreq: s3c24xx: Do not mark s3c2410_plls_add as __init
  ARM: EXYNOS: Fix potential NULL pointer access in exynos_sys_powerdown_conf

Pull powerpc fixes from Michael Ellerman:
 - opal-irqchip: Fix double endian conversion from Alistair Popple
 - cxl: Set endianess of kernel contexts from Frederic Barrat
 - sbc8641: drop bogus PHY IRQ entries from DTS file from Paul Gortmaker
 - Revert "powerpc/eeh: Don't unfreeze PHB PE after reset" from Andrew
   Donnellan

* tag 'powerpc-4.4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  Revert "powerpc/eeh: Don't unfreeze PHB PE after reset"
  powerpc/sbc8641: drop bogus PHY IRQ entries from DTS file
  cxl: Set endianess of kernel contexts
  powerpc/opal-irqchip: Fix double endian conversion

Merge misc fixes from Andrew Morton:
 "17 fixes"

* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
  MIPS: fix DMA contiguous allocation
  sh64: fix __NR_fgetxattr
  ocfs2: fix SGID not inherited issue
  mm/oom_kill.c: avoid attempting to kill init sharing same memory
  drivers/base/memory.c: prohibit offlining of memory blocks with missing sections
  tmpfs: fix shmem_evict_inode() warnings on i_blocks
  mm/hugetlb.c: fix resv map memory leak for placeholder entries
  mm: hugetlb: call huge_pte_alloc() only if ptep is null
  kernel: remove stop_machine() Kconfig dependency
  mm: kmemleak: mark kmemleak_init prototype as __init
  mm: fix kerneldoc on mem_cgroup_replace_page
  osd fs: __r4w_get_page rely on PageUptodate for uptodate
  MAINTAINERS: make Vladimir co-maintainer of the memory controller
  mm, vmstat: allow WQ concurrency to discover memory reclaim doesn't make any progress
  mm: fix swapped Movable and Reclaimable in /proc/pagetypeinfo
  memcg: fix memory.high target
  mm: hugetlb: fix hugepage memory leak caused by wrong reserve count

Pull parisc fixes from Helge Deller:
 "Fix the boot crash on Mako machines with Huge Pages, prevent a panic
  with SATA controllers (and others) by correctly calculating the IOMMU
  space, hook up the mlock2 syscall and drop unneeded code in the parisc
  pci code"

* 'parisc-4.4-3' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
  parisc: Disable huge pages on Mako machines
  parisc: Wire up mlock2 syscall
  parisc: Remove unused pcibios_init_bus()
  parisc iommu: fix panic due to trying to allocate too large region

Pull block layer fixes from Jens Axboe:
 "A set of fixes for the current series.  This contains:

   - A bunch of fixes for lightnvm, should be the last round for this
     series.  From Matias and Wenwei.

   - A writeback detach inode fix from Ilya, also marked for stable.

   - A block (though it says SCSI) fix for an OOPS in SCSI runtime power
     management.

   - Module init error path fixes for null_blk from Minfei"

* 'for-linus' of git://git.kernel.dk/linux-block:
  null_blk: Fix error path in module initialization
  lightnvm: do not compile in debugging by default
  lightnvm: prevent gennvm module unload on use
  lightnvm: fix media mgr registration
  lightnvm: replace req queue with nvmdev for lld
  lightnvm: comments on constants
  lightnvm: check mm before use
  lightnvm: refactor spin_unlock in gennvm_get_blk
  lightnvm: put blks when luns configure failed
  lightnvm: use flags in rrpc_get_blk
  block: detach bdev inode from its wb in __blkdev_put()
  SCSI: Fix NULL pointer dereference in runtime PM

Pull arm64 fixes from Catalin Marinas:

 - Update the linker script to use L1_CACHE_BYTES instead of hard-coded
   64.  We recently changed L1_CACHE_BYTES to 128

 - Improve race condition reporting on set_pte_at() and change the BUG
   to WARN_ONCE.  With hardware update of the accessed/dirty state, we
   need to ensure that set_pte_at() does not inadvertently override
   hardware updated state.  The patch also makes the checks ignore
   !pte_valid() new entries

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: Improve error reporting on set_pte_at() checks
  arm64: update linker script to increased L1_CACHE_BYTES value

Recent changes to how GFP_ATOMIC is defined seems to have broken the
condition to use mips_alloc_from_contiguous() in
mips_dma_alloc_coherent().

I couldn't bottom out the exact change but I think it's this commit
d0164adc ("mm, page_alloc: distinguish between being unable to
sleep, unwilling to sleep and avoiding waking kswapd").

GFP_ATOMIC has multiple bits set and the check for !(gfp & GFP_ATOMIC)
isn't enough.

The reason behind this condition is to check whether we can potentially
do a sleeping memory allocation.  Use gfpflags_allow_blocking() instead
which should be more robust.
Signed-off-by: Qais Yousef <qais.yousef@imgtec.com>
Acked-by: Mel Gorman <mgorman@techsingularity.net>
Cc: Ralf Baechle <ralf@linux-mips.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

According to arch/sh/kernel/syscalls_64.S and common sense, __NR_fgetxattr
has to be defined to 259, but it doesn't.  Instead, it's defined to 269,
which is of course used by another syscall, __NR_sched_setaffinity in this
case.

This bug was found by strace test suite.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Commit 8f1eb487 ("ocfs2: fix umask ignored issue") introduced an
issue, SGID of sub dir was not inherited from its parents dir.  It is
because SGID is set into "inode->i_mode" in ocfs2_get_init_inode(), but
is overwritten by "mode" which don't have SGID set later.

Fixes: 8f1eb487 ("ocfs2: fix umask ignored issue")
Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Mark Fasheh <mfasheh@suse.de>
Cc: Joel Becker <jlbec@evilplan.org>
Acked-by: Srinivas Eeda <srinivas.eeda@oracle.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

It's possible that an oom killed victim shares an ->mm with the init
process and thus oom_kill_process() would end up trying to kill init as
well.

This has been shown in practice:

	Out of memory: Kill process 9134 (init) score 3 or sacrifice child
	Killed process 9134 (init) total-vm:1868kB, anon-rss:84kB, file-rss:572kB
	Kill process 1 (init) sharing same memory
	...
	Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009

And this will result in a kernel panic.

If a process is forked by init and selected for oom kill while still
sharing init_mm, then it's likely this system is in a recoverable state.
However, it's better not to try to kill init and allow the machine to
panic due to unkillable processes.

[rientjes@google.com: rewrote changelog]
[akpm@linux-foundation.org: fix inverted test, per Ben]
Signed-off-by: Chen Jie <chenjie6@huawei.com>
Signed-off-by: David Rientjes <rientjes@google.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: Li Zefan <lizefan@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Commit bdee237c ("x86: mm: Use 2GB memory block size on large-memory
x86-64 systems") and 982792c7 ("x86, mm: probe memory block size for
generic x86 64bit") introduced large block sizes for x86.  This made it
possible to have multiple sections per memory block where previously,
there was a only every one section per block.

Since blocks consist of contiguous ranges of section, there can be holes
in the blocks where sections are not present.  If one attempts to
offline such a block, a crash occurs since the code is not designed to
deal with this.

This patch is a quick fix to gaurd against the crash by not allowing
blocks with non-present sections to be offlined.

Addresses https://bugzilla.kernel.org/show_bug.cgi?id=107781Signed-off-by: Seth Jennings <sjennings@variantweb.net>
Reported-by: Andrew Banman <abanman@sgi.com>
Cc: Daniel J Blueman <daniel@numascale.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Greg KH <greg@kroah.com>
Cc: Russ Anderson <rja@sgi.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Dmitry Vyukov provides a little program, autogenerated by syzkaller,
which races a fault on a mapping of a sparse memfd object, against
truncation of that object below the fault address: run repeatedly for a
few minutes, it reliably generates shmem_evict_inode()'s
WARN_ON(inode->i_blocks).

(But there's nothing specific to memfd here, nor to the fstat which it
happened to use to generate the fault: though that looked suspicious,
since a shmem_recalc_inode() had been added there recently.  The same
problem can be reproduced with open+unlink in place of memfd_create, and
with fstatfs in place of fstat.)

v3.7 commit 0f3c42f5 ("tmpfs: change final i_blocks BUG to WARNING")
explains one cause of such a warning (a race with shmem_writepage to
swap), and possible solutions; but we never took it further, and this
syzkaller incident turns out to have a different cause.

shmem_getpage_gfp()'s error recovery, when a freshly allocated page is
then found to be beyond eof, looks plausible - decrementing the alloced
count that was just before incremented - but in fact can go wrong, if a
racing thread (the truncator, for example) gets its shmem_recalc_inode()
in just after our delete_from_page_cache().  delete_from_page_cache()
decrements nrpages, that shmem_recalc_inode() will balance the books by
decrementing alloced itself, then our decrement of alloced take it one
too low: leading to the WARNING when the object is finally evicted.

Once the new page has been exposed in the page cache,
shmem_getpage_gfp() must leave it to shmem_recalc_inode() itself to get
the accounting right in all cases (and not fall through from "trunc:" to
"decused:").  Adjust that error recovery block; and the reinitialization
of info and sbinfo can be removed too.

While we're here, fix shmem_writepage() to avoid the original issue: it
will be safe against a racing shmem_recalc_inode(), if it merely
increments swapped before the shmem_delete_from_page_cache() which
decrements nrpages (but it must then do its own shmem_recalc_inode()
before that, while still in balance, instead of after).  (Aside: why do
we shmem_recalc_inode() here in the swap path? Because its raison d'etre
is to cope with clean sparse shmem pages being reclaimed behind our
back: so here when swapping is a good place to look for that case.) But
I've not now managed to reproduce this bug, even without the patch.

I don't see why I didn't do that earlier: perhaps inhibited by the
preference to eliminate shmem_recalc_inode() altogether.  Driven by this
incident, I do now have a patch to do so at last; but still want to sit
on it for a bit, there's a couple of questions yet to be resolved.
Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Dmitry Vyukov reported the following memory leak

unreferenced object 0xffff88002eaafd88 (size 32):
  comm "a.out", pid 5063, jiffies 4295774645 (age 15.810s)
  hex dump (first 32 bytes):
    28 e9 4e 63 00 88 ff ff 28 e9 4e 63 00 88 ff ff  (.Nc....(.Nc....
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
     kmalloc include/linux/slab.h:458
     region_chg+0x2d4/0x6b0 mm/hugetlb.c:398
     __vma_reservation_common+0x2c3/0x390 mm/hugetlb.c:1791
     vma_needs_reservation mm/hugetlb.c:1813
     alloc_huge_page+0x19e/0xc70 mm/hugetlb.c:1845
     hugetlb_no_page mm/hugetlb.c:3543
     hugetlb_fault+0x7a1/0x1250 mm/hugetlb.c:3717
     follow_hugetlb_page+0x339/0xc70 mm/hugetlb.c:3880
     __get_user_pages+0x542/0xf30 mm/gup.c:497
     populate_vma_page_range+0xde/0x110 mm/gup.c:919
     __mm_populate+0x1c7/0x310 mm/gup.c:969
     do_mlock+0x291/0x360 mm/mlock.c:637
     SYSC_mlock2 mm/mlock.c:658
     SyS_mlock2+0x4b/0x70 mm/mlock.c:648

Dmitry identified a potential memory leak in the routine region_chg,
where a region descriptor is not free'ed on an error path.

However, the root cause for the above memory leak resides in region_del.
In this specific case, a "placeholder" entry is created in region_chg.
The associated page allocation fails, and the placeholder entry is left
in the reserve map.  This is "by design" as the entry should be deleted
when the map is released.  The bug is in the region_del routine which is
used to delete entries within a specific range (and when the map is
released).  region_del did not handle the case where a placeholder entry
exactly matched the start of the range range to be deleted.  In this
case, the entry would not be deleted and leaked.  The fix is to take
these special placeholder entries into account in region_del.

The region_chg error path leak is also fixed.

Fixes: feba16e2 ("mm/hugetlb: add region_del() to delete a specific range of entries")
Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: <stable@vger.kernel.org>	[4.3+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>