In the spi_loopback_test driver there is the need to initialize
a spi_message that is filled with values from a static structure.
Applying spi_message_init to such a prefilled structure results in
all the settings getting reset to zero, which is not what we want.
Copying each field of spi_message separately instead always includes
the risk that some new fields have not been implemented in the copying
code.
So here we introduce a version of spi_message_init called
spi_message_init_no_memset that does not fill the structure
with zero first, but only initializes the relevant list_heads.
Signed-off-by: Martin Sperl <kernel@martin.sperl.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
When setting aside capacity for struct page it must be aligned to the
largest mapping size that is to be made available via DAX. Make the
alignment configurable to enable support for 1GiB page-size mappings.
The offset for PFN_MODE_RAM may now be larger than SZ_8K, so fixup the
offset check in nvdimm_namespace_attach_pfn().
Reported-by: Toshi Kani <toshi.kani@hpe.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Add support for PA gpio pin for controlling an external amplifier as used
on some Allwinner boards.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Rename the codec dapm widgets and routes with a _codec prefix. This is
a preparation patch for adding card dapm widgets and routes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
DPCM does not fully support symmetry attributes. soc_pcm_apply_symmetry()
is skipped in soc_pcm_open() for DPCM, without being applied elsewhere.
So HW parameters cannot be correctly limited, and user space can do
playback/capture at different rates while HW actually does not support it.
soc_pcm_params_symmetry() will return error and the second stream stops.
This patch adds soc_pcm_apply_symmetry() for FE, BE, and codec DAIs
in DPCM path that was skipped in soc_pcm_open().
Signed-off-by: PC Liao <pc.liao@mediatek.com>
Signed-off-by: Koro Chen <koro.chen@mediatek.com>
Acked-by: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
davinci_spi_bufs() uses wait_for_completion_interruptible()
without bothering to handle -ERESTARTSYS. Due to this,
sometime, it returns prematurely when a signal is received.
Since the return value is never checked, userspace eventually
receives a spurious -EIO.
To fix this, use un-interruptible wait_for_completion_timeout().
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add code to unregister codec in probe function,
when the error occurs after the codec is registered.
Signed-off-by: Songjun Wu <songjun.wu@atmel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add binding document for Pistachio Internal DAC
Signed-off-by: Damien.Horsley <Damien.Horsley@imgtec.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Locking is currently missing from the DSP firmware controls, which can
lead to some race conditions if the controls are accessed as the DSP
powers up or down. This patch adds them to the new power lock.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We should hold the DSP power lock whilst changing the firmware since we
need to check if it is running first.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Most events around the DSP just need to be locked to ensure that the DSP
can't change power state whilst they are happening. This includes the
debugfs entries and this will make sorting the rest of the locking
simpler.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add driver for Texas Instruments pcm3168a codec
Signed-off-by: Damien.Horsley <Damien.Horsley@imgtec.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add binding document for Texas Instruments pcm3168a codec
Signed-off-by: Damien.Horsley <Damien.Horsley@imgtec.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Add SOC_DOUBLE_STS macro for read-only volatile status controls
Signed-off-by: Damien.Horsley <Damien.Horsley@imgtec.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If the register defaults are provided by the driver without the
number by mistake, it should just return an error with one promotion.
This should be as early as possible, then there is no need to verify
the register defaults' stride and the other code followed.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
If there is no cache used for the drivers, the register defaults
or the register defaults raw are not need any more. This patch
will check this and print a warning.
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
This new code is unreachable. Presumably there was supposed to be a
case statement there similar to the earlier code.
Fixes: afcc00b91f ('regmap: add 64-bit mode support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
We should cast these to 64bit so that we don't truncate away the high
bits.
Fixes: afcc00b91f ('regmap: add 64-bit mode support')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
These were supposed to be bitwise AND instead of logical. Also kernel
style is for the operator to be on the first line and I removed some
extra parenthesis.
Fixes: c90456e36d ('regulator: pv88090: new regulator driver')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Use devm_request_threaded_irq to ensure the irq is freed when unload the
module.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
DSPI instances in Vybrid have a different amount of chip selects
and CTARs (Clock and transfer Attributes Register). In case of
DSPI1 we only have 2 CTAR registers and 4 CS. In present driver
implementation CTAR offset is derived from CS instance which will
lead to out of bound access if chip select instance is greater than
CTAR register instance, hence use single CTAR0 register for all CS
instances. Since we write the CTAR register anyway before each access,
there is no value in using the additional CTAR registers. Also one
should not program a value in CTAS for a CTAR register that is not
present, hence configure CTAS to use CTAR0.
Signed-off-by: Bhuvanchandra DV <bhuvanchandra.dv@toradex.com>
Acked-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Mark Brown <broonie@kernel.org>
Explicitly set the transmit data level on the transceiver to 16 samples
rather then the default 0. This matches both the level set in the vendor
kernel and the (seemingly very similar) i2s engine. This fixes audio
glitches when playing back at 192k rate.
At the same time, fix a trivial typo in the TDL mask definition
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
Attempting to use this codec driver triggers a BUG() in regcache_sync()
since no cache type is set. The register map of this device is fairly
small and has few holes so a flat cache is suitable.
Signed-off-by: Mans Rullgard <mans@mansr.com>
Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
There is a need of a broadcast timer in this case to ensure proper
wakeup when the cpus are in sleep mode and a timer expires.
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
These are all off by one; the playback and bypass switches are the top
two bits of the registers, which are at shifts 7 and 6 not 8 and 7.
Signed-off-by: John Keeping <john@metanate.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
- 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWbIyYAAoJEFHr6jzI4aWA30QP+wUIWYwPsceIguT2IQLFN6mj
buPS/wukpcSiqltAFtpf2aAe+LgTPt2P6geZfIdrd8QsS8wgO4ncpW8NGxyNIRNr
sBZONQIwPMkrOMAQeCvz7wEQk5pfIT5IqY0qP6HqIwBpSr80+zHRSr+RAwYT0VHn
sHoCObSumc099dvj+YUetKzF5L3bTCLK+GVytB471OL7ORmc5EOnrwFSG6HBO/KC
yiJQ1VjCm7tNfaXL9BmBfpePyGBCFySXjb5vB8rtS2pXjg7Ugnnp5pGUCBtM05ar
mMmhaxTv4QffcJKh7XtwKPwCcSDVcF4nmtL/3F/TfvT8IkuHbageORp1wnda+5uL
MF6QEOfWWETTXzd6lFib+Z5WoC/XBiPTKg1rx+vpEqyeuPVm/mkwcsYpVoU69z+w
zY5Bzs6tIkTBTg5qQXQM6dckamWHpKa4xjiVyHJbnPyJcsR4fHpD3W0rUY9NwZu9
siqRM0rlabq9fNdsfN8f8XZBZ9z4dNBtTDulDgLgaQK4J17H/9/jWrz8TYPg3cfH
iFK2ilv8zJpLQEFWmubsyO1QZeJe7GbMQcCmnZH2wK94XtbFHDjaMFwRpZ7ibPnl
GzgmRLqboWTVqwlOFtRZvY7dH7r9lVQD2nOhHHO1d471RQB7PoWlmdEZzRWHqP39
DiGMymogq3IYjPhXL/dx
=bYj2
-----END PGP SIGNATURE-----
Merge tag 'powerpc-4.4-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux
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
Reference the newly added efuse clock-ids in the clock-tree.
Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the clock tree definition for the new rk3228 SoC.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add the devicetree binding for the cru on the rk3228 which quite similar
structured as previous clock controllers.
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add clock-ids for the two efuse blocks of the rk3288.
Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Acked-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
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
- 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWaw39AAoJEGvWsS0AyF7xfg0P/3wOZ2geccc480/sJmjBvx4d
gSJQHkXXvlOgf1SgQd05148M9Xcv+nfZqBuDctDrQCJx0IXne46a5dlaJ3GfMzzU
8ZzlrIW8GVGFgScpUuAgc/M6Bx8HBc5pZgDW8FqmlX7xeZ+T1MGvC4jDMUz7oUH0
ERN6yAasgLVew8mvEPvKPB3tQHEADyiEx09X61pkos8p4m45kVH4FCBu3INnQQ8W
pOBGvrQ1QjEX66DPJfLgRxOSozjDEs8sNdbznoLvXVO39lmC1yJFarGaK6jstLih
90oIo4gSxtEicEE6w6mCd54uzNzFygFv2FZ22NjYcgSoxWVeX0N37IHaP4AgMtl0
FMkyTfzaTdq9thx5gO0aP90mvxnZ/sHCytEnkFwsEYftDn7ncHppCJxAKroSldfv
N/MaVtxR6KLU38ZJCE2as9ufNPeATzfiyd69VE0fKyjV4gmWGXakkSiNTsSj3Nz6
4UGZ2WKOJjR0DNwi+4W64wvkhYCQQBDZElil7hxUIcjiy5fOtXANJy73BeqeSu+Y
h0x+iy5KlqR8ZpabwmruV5aYB/qcBa1ZFTB6zshBfA4fDyUSjQ59Pi3RlUh78ZxE
d4aRHbmiwKcA+DPQYgl9q9eul4DCEZX5AG3r2m7bly9q4dzv6luF2Q7NrH55nCZh
QaB8lhdsUF4y0clDShvr
=L6aC
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
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
d0164adc89 ("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 8f1eb48758 ("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: 8f1eb48758 ("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 bdee237c03 ("x86: mm: Use 2GB memory block size on large-memory
x86-64 systems") and 982792c782 ("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=107781
Signed-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 0f3c42f522 ("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: feba16e25a ("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>
