Merge fixes from Andrew Morton:
"10 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
mm: slab: free kmem_cache_node after destroy sysfs file
ipc/shm: handle removed segments gracefully in shm_mmap()
MAINTAINERS: update Kselftest Framework mailing list
devm_memremap_release(): fix memremap'd addr handling
mm/hugetlb.c: fix incorrect proc nr_hugepages value
mm, x86: fix pte_page() crash in gup_pte_range()
fsnotify: turn fsnotify reaper thread into a workqueue job
Revert "fsnotify: destroy marks with call_srcu instead of dedicated thread"
mm: fix regression in remap_file_pages() emulation
thp, dax: do not try to withdraw pgtable from non-anon VMA
- Allow EFI stub to use strnlen(), which is required by recent libfdt
- Avoid smp_processor_id() in preempt context during unwinding
- Avoid false Kasan warnings during unwinding
- Ensure early devices are picked up by the IOMMU DMA ops
- Avoid rebuilding the kernel for the 'install' target
- Run fixup handlers for alignment faults on userspace access
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCgAGBQJWxwt3AAoJELescNyEwWM09rIH/3ygrixUcnk/22vI+y32ALDL
TpBih0pgNmFmls3QxTQaIYqsdjfHVCuzoLRcHGYsPgb42fIeLTgcx6Bp4xacUVGh
+xjBdEjacUR92TiB/QeP3lNEYIuBhHEPE+H5hHccbdRa+xNB5rUx0Z6nTRokOM4u
j25KiNf5wO2bOMwo6TNYT0N1Lggp+TZrIP2bIUkWm+RSorF3NGqLS0Rw3ZKwBXxm
jtUA4ohKR3uyeRHki8Nw/M/AV+gMq+nELX1RGK4HMW00cqakKwIEFvANbdbxGMmg
q7OIgluSK3BCTQPVQTiss+W6rEjg1z0dTyHGCPVwP16SGXH2i0ys0xQ0BZR5SMw=
=/uso
-----END PGP SIGNATURE-----
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
"Here are some more arm64 fixes for 4.5. This has mostly come from
Yang Shi, who saw some issues under -rt that also affect mainline.
The rest of it is pretty small, but still worth having.
We've got an old issue outstanding with valid_user_regs which will
likely wait until 4.6 (since it would really benefit from some time in
-next) and another issue with kasan and idle which should be fixed
next week.
Apart from that, pretty quiet here (and still no sign of the THP issue
reported on s390...)
Summary:
- Allow EFI stub to use strnlen(), which is required by recent libfdt
- Avoid smp_processor_id() in preempt context during unwinding
- Avoid false Kasan warnings during unwinding
- Ensure early devices are picked up by the IOMMU DMA ops
- Avoid rebuilding the kernel for the 'install' target
- Run fixup handlers for alignment faults on userspace access"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: mm: allow the kernel to handle alignment faults on user accesses
arm64: kbuild: make "make install" not depend on vmlinux
arm64: dma-mapping: fix handling of devices registered before arch_initcall
arm64/efi: Make strnlen() available to the EFI namespace
arm/arm64: crypto: assure that ECB modes don't require an IV
arm64: make irq_stack_ptr more robust
arm64: debug: re-enable irqs before sending breakpoint SIGTRAP
arm64: disable kasan when accessing frame->fp in unwind_frame
Pull s390 fixes from Martin Schwidefsky:
"Several bug fixes:
- There are four different stack tracers, and three of them have
bugs. For 4.5 the bugs are fixed and we prepare a cleanup patch
for the next merge window.
- Three bug fixes for the dasd driver in regard to parallel access
volumes and the new max_dev_sectors block device queue limit
- The irq restore optimization needs a fixup for memcpy_real
- The diagnose trace code has a conflict with lockdep"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
s390/dasd: fix performance drop
s390/maccess: reduce stnsm instructions
s390/diag: avoid lockdep recursion
s390/dasd: fix refcount for PAV reassignment
s390/dasd: prevent incorrect length error under z/VM after PAV changes
s390: fix DAT off memory access, e.g. on kdump
s390/oprofile: fix address range for asynchronous stack
s390/perf_event: fix address range for asynchronous stack
s390/stacktrace: add save_stack_trace_regs()
s390/stacktrace: save full stack traces
s390/stacktrace: add missing end marker
s390/stacktrace: fix address ranges for asynchronous and panic stack
s390/stacktrace: fix save_stack_trace_tsk() for current task
driver fixes:
- Fix the PXA2xx driver to export its init function so we
do not break modular compiles.
- Hide unused functions in the Nomadik driver.
- Fix up direction control in the Mediatek driver.
- Toggle the sunxi GPIO lines to input when you read them
on the H3 GPIO controller, lest you only get garbage.
- Fix up the number of settings in the MVEBU driver.
- Fix a serious SMP race condition in the Samsung driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWxvyrAAoJEEEQszewGV1zgL4QAMGRaOXb2JIxz39gc37h92Cv
Cop92w8SU54OCAsA0UhfNv/y2oUZ5Hui++N5M3pTFlVZbtOD/POzcObehmi61DYJ
IkJEcA4df6prDLTtmIALXwSYoUapgc+kjl3RyNAg0pRPj5k/QxrqMmEhbHt3ZOwo
ZehWdl/4Kap4gzHYcflYICf71u0HGE0QbjEUkr8oB+lhCE3zFlfYSVelu5Ysg/CF
tRugNsLhn4rke3e1QTK2leOWREatgqngJUEMhSrxyulA7E+0tQPRt9dhHaQD47Zw
NxDDcpXevgRGRo9//VLM33tjMe4vZlWdjGTJ2Bro3rGYyJBDwdiiDumKCR9b8Ba6
qEddYoSjFV2IJWy3ngLuGXy7+t14LGHN6+kWU9XMD2V0idPcKipCcaUKl92x4v1s
at8+uStzeLPyb9NZ2v3PxE7IvAwSG85xtSZ53yJgoudxJHMBU0xFO42G4D3mCzIm
xd2ERHhIsuUIS9+hOC++lcxXfdMVogcGpA3NyW9TCiX5NMs0IG957iWADL2z73Yu
uoX4GUEBjQwsSyWIiic90mOw/OByKBIQmx/8Kj2kIotINzRHrwg+bBfplc+gQumX
CKREs3QHAfBrvfSTd115rJX5UuKFiCX6eG2z7Ardori3qkRVOYpWh1dkGSZg0ZKO
ft/f8ZD6qZ8+0F5xb3/m
=Qs3i
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v4.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl
Pull Pin control fixes from Linus Walleij:
"Pin control fixes for the v4.5 series, all are individual driver
fixes:
- Fix the PXA2xx driver to export its init function so we do not
break modular compiles.
- Hide unused functions in the Nomadik driver.
- Fix up direction control in the Mediatek driver.
- Toggle the sunxi GPIO lines to input when you read them on the H3
GPIO controller, lest you only get garbage.
- Fix up the number of settings in the MVEBU driver.
- Fix a serious SMP race condition in the Samsung driver"
* tag 'pinctrl-v4.5-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl:
pinctrl: samsung: fix SMP race condition
pinctrl: mvebu: fix num_settings in mpp group assignment
pinctrl: sunxi: H3 requires irq_read_needs_mux
pinctrl: mediatek: fix direction control issue
pinctrl: nomadik: hide unused functions
pinctrl: pxa: export pxa2xx_pinctrl_init()
this update contains again a few more fixes for ALSA core stuff
although it's no longer high flux: two race fixes in sequencer and one
PCM race fix for non-atomic PCM ops. In addition, HD-audio gained a
similar fix for race at reloading the driver.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJWxvBBAAoJEGwxgFQ9KSmk2RoQALqPcE1WomF9KoCTRDQ0+V2V
CDQFBDZsrlBPNH0p5tiVOWdzk8tsKh/asF5JO83g5RmIBd3MP06MJYdMnbEa7xVE
77WykgGT3onmiY7fka4ufNysm0LGdPNjaPvdOmzrrU0z3+JdrffuWPT2nnd6znDF
aZH3sx/Hy+Hl7nrfhG+xh08OAQJNK9ro6ZrEzQFAdhZMUoWTAlI0cV6fTxdnMLVf
DV9lYT4TMfCijHAu+ujPoP5TihgQ2215RvQa4GCERX2vmoXK7yPfDB6Kbkh7uQhl
HW8blEKHKfrEOElmg/VKUKaa1W7Of+n3m1eFrBgPiDfUEzpBM4U0Bp3dr/097rnk
v2arIBQQcu/V3yInID8BxQAH9Rq4P+wS8UREBXws5AEe0OSyMsYheVmkPOJoBSST
uudqKSf876qqC2+ze7R90rUF91UNiWJNyraynUPPgXO5IXMpUbt6H8oucICU+vys
eaIl/sl0n0fB3XUcMLXKGySgXxeKUGKqWPNga5v2YLdyFLhtd3uHJFuoq7vy8as2
vzjq/sd87R2VUCxN907UKdhQkvXuhIXs5I6ugc7Wwv+RHv9dhLNs+zB8yOnA+iFT
T6tMX0M/5lgJ+s8DH9mLUxZWb8cUjLWU0llVedBuicFAilnujIkw4Gc+3RKcf3h0
Hj/sHiss0F9q0XhPI5gI
=u/fj
-----END PGP SIGNATURE-----
Merge tag 'sound-4.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"This update contains again a few more fixes for ALSA core stuff
although it's no longer high flux: two race fixes in sequencer and one
PCM race fix for non-atomic PCM ops.
In addition, HD-audio gained a similar fix for race at reloading the
driver"
* tag 'sound-4.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: pcm: Fix rwsem deadlock for non-atomic PCM stream
ALSA: seq: Fix double port list deletion
ALSA: hda - Cancel probe work instead of flush at remove
ALSA: seq: Fix leak of pool buffer at concurrent writes
Although we don't expect to take alignment faults on access to normal
memory, misbehaving (i.e. buggy) user code can pass MMIO pointers into
system calls, leading to things like get_user accessing device memory.
Rather than OOPS the kernel, allow any exception fixups to run and
return something like -EFAULT back to userspace. This makes the
behaviour more consistent with userspace, even though applications with
access to device mappings can easily cause other issues if they try
hard enough.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Eun Taik Lee <eun.taik.lee@samsung.com>
[will: dropped __kprobes annotation and rewrote commit mesage]
Signed-off-by: Will Deacon <will.deacon@arm.com>
For the same reason as commit 19514fc665 ("arm, kbuild: make "make
install" not depend on vmlinux"), the install targets should never
trigger the rebuild of the kernel.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Pull livepatching fixes from Jiri Kosina:
- regression (from 4.4) fix for ordering issue, introduced by an
earlier ftrace change, that broke live patching of modules.
The fix replaces the ftrace module notifier by direct call in order
to make the ordering guaranteed and well-defined. The patch, from
Jessica Yu, has been acked both by Steven and Rusty
- error message fix from Miroslav Benes
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching:
ftrace/module: remove ftrace module notifier
livepatch: change the error message in asm/livepatch.h header files
Two simple fixes. One prevents a soft lockup on some target removal
scenarios and the other prevents us trying to probe the marvell
console device, which causes it to time out and need the bus
resetting.
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAABAgAGBQJWxf9xAAoJEDeqqVYsXL0M9noIAL7F5d/zvbJPHS0gHErd+TX8
vkdMbFmrXkrARy1ZChCv7Z/3NcdLPzMp/erB7Ed9uc9SrcMEVGYNw3zJUicJCrmN
1WEvd+4iFhCpqjYtmKwxOTcuvZAgobJA8Is4Lnrx5KmY0YKUoFOpFPZBbWuY22mR
QNZwxOL1O6uM8PihKsCJCzHJVB1RiicHL24DmFK4sOU85c7zStwuvKNv/3RPy+0c
FtDz4Gc6NmmSrsC/DZHcf5q+ybSe4VSoqeKj5eSvuhxhpPpVku2sEgtxHBhm9cZ+
nPMWQIlXxR4vSJ6oOq+IpezorlIF3NlJVKPtwg6CyNI3sOgFxUg3EN2YKRlp+KQ=
=cX3U
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Two simple fixes.
One prevents a soft lockup on some target removal scenarios and the
other prevents us trying to probe the marvell console device, which
causes it to time out and need the bus resetting"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: fix soft lockup in scsi_remove_target() on module removal
SCSI: Add Marvell configuration device to VPD blacklist
When slub_debug alloc_calls_show is enabled we will try to track
location and user of slab object on each online node, kmem_cache_node
structure and cpu_cache/cpu_slub shouldn't be freed till there is the
last reference to sysfs file.
This fixes the following panic:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
IP: list_locations+0x169/0x4e0
PGD 257304067 PUD 438456067 PMD 0
Oops: 0000 [#1] SMP
CPU: 3 PID: 973074 Comm: cat ve: 0 Not tainted 3.10.0-229.7.2.ovz.9.30-00007-japdoll-dirty #2 9.30
Hardware name: DEPO Computers To Be Filled By O.E.M./H67DE3, BIOS L1.60c 07/14/2011
task: ffff88042a5dc5b0 ti: ffff88037f8d8000 task.ti: ffff88037f8d8000
RIP: list_locations+0x169/0x4e0
Call Trace:
alloc_calls_show+0x1d/0x30
slab_attr_show+0x1b/0x30
sysfs_read_file+0x9a/0x1a0
vfs_read+0x9c/0x170
SyS_read+0x58/0xb0
system_call_fastpath+0x16/0x1b
Code: 5e 07 12 00 b9 00 04 00 00 3d 00 04 00 00 0f 4f c1 3d 00 04 00 00 89 45 b0 0f 84 c3 00 00 00 48 63 45 b0 49 8b 9c c4 f8 00 00 00 <48> 8b 43 20 48 85 c0 74 b6 48 89 df e8 46 37 44 00 48 8b 53 10
CR2: 0000000000000020
Separated __kmem_cache_release from __kmem_cache_shutdown which now
called on slab_kmem_cache_release (after the last reference to sysfs
file object has dropped).
Reintroduced locking in free_partial as sysfs file might access cache's
partial list after shutdowning - partial revert of the commit
69cb8e6b7c ("slub: free slabs without holding locks"). Zap
__remove_partial and use remove_partial (w/o underscores) as
free_partial now takes list_lock which s partial revert for commit
1e4dd9461f ("slub: do not assert not having lock in removing freed
partial")
Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com>
Suggested-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Acked-by: Vladimir Davydov <vdavydov@virtuozzo.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
remap_file_pages(2) emulation can reach file which represents removed
IPC ID as long as a memory segment is mapped. It breaks expectations of
IPC subsystem.
Test case (rewritten to be more human readable, originally autogenerated
by syzkaller[1]):
#define _GNU_SOURCE
#include <stdlib.h>
#include <sys/ipc.h>
#include <sys/mman.h>
#include <sys/shm.h>
#define PAGE_SIZE 4096
int main()
{
int id;
void *p;
id = shmget(IPC_PRIVATE, 3 * PAGE_SIZE, 0);
p = shmat(id, NULL, 0);
shmctl(id, IPC_RMID, NULL);
remap_file_pages(p, 3 * PAGE_SIZE, 0, 7, 0);
return 0;
}
The patch changes shm_mmap() and code around shm_lock() to propagate
locking error back to caller of shm_mmap().
[1] http://github.com/google/syzkaller
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Manfred Spraul <manfred@colorfullife.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Kselftest Framework now has a dedicated mailing list linux-kselftest.
Update the entry in MAINTAINERS file.
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The pmem driver calls devm_memremap() to map a persistent memory range.
When the pmem driver is unloaded, this memremap'd range is not released
so the kernel will leak a vma.
Fix devm_memremap_release() to handle a given memremap'd address
properly.
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Matthew Wilcox <willy@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Currently incorrect default hugepage pool size is reported by proc
nr_hugepages when number of pages for the default huge page size is
specified twice.
When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages
indicates the current number of pre-allocated huge pages of the default
size. Basically /proc/sys/vm/nr_hugepages displays default_hstate->
max_huge_pages and after boot time pre-allocation, max_huge_pages should
equal the number of pre-allocated pages (nr_hugepages).
Test case:
Note that this is specific to x86 architecture.
Boot the kernel with command line option 'default_hugepagesz=1G
hugepages=X hugepagesz=2M hugepages=Y hugepagesz=1G hugepages=Z'. After
boot, 'cat /proc/sys/vm/nr_hugepages' and 'sysctl -a | grep hugepages'
returns the value X. However, dmesg output shows that Z huge pages were
pre-allocated.
So, the root cause of the problem here is that the global variable
default_hstate_max_huge_pages is set if a default huge page size is
specified (directly or indirectly) on the command line. After the command
line processing in hugetlb_init, if default_hstate_max_huge_pages is set,
the value is assigned to default_hstae.max_huge_pages. However,
default_hstate.max_huge_pages may have already been set based on the
number of pre-allocated huge pages of default_hstate size.
The solution to this problem is if hstate->max_huge_pages is already set
then it should not set as a result of global max_huge_pages value.
Basically if the value of the variable hugepages is set multiple times on
a command line for a specific supported hugepagesize then proc layer
should consider the last specified value.
Signed-off-by: Vaishali Thakkar <vaishali.thakkar@oracle.com>
Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: Hillf Danton <hillf.zj@alibaba-inc.com>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit 3565fce3a6 ("mm, x86: get_user_pages() for dax mappings") has
moved up the pte_page(pte) in x86's fast gup_pte_range(), for no
discernible reason: put it back where it belongs, after the pte_flags
check and the pfn_valid cross-check.
That may be the cause of the NULL pointer dereference in
gup_pte_range(), seen when vfio called vaddr_get_pfn() when starting a
qemu-kvm based VM.
Signed-off-by: Hugh Dickins <hughd@google.com>
Reported-by: Michael Long <Harn-Solo@gmx.de>
Tested-by: Michael Long <Harn-Solo@gmx.de>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We don't require a dedicated thread for fsnotify cleanup. Switch it
over to a workqueue job instead that runs on the system_unbound_wq.
In the interest of not thrashing the queued job too often when there are
a lot of marks being removed, we delay the reaper job slightly when
queueing it, to allow several to gather on the list.
Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
Tested-by: Eryu Guan <guaneryu@gmail.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Eric Paris <eparis@parisplace.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This reverts commit c510eff6be ("fsnotify: destroy marks with
call_srcu instead of dedicated thread").
Eryu reported that he was seeing some OOM kills kick in when running a
testcase that adds and removes inotify marks on a file in a tight loop.
The above commit changed the code to use call_srcu to clean up the
marks. While that does (in principle) work, the srcu callback job is
limited to cleaning up entries in small batches and only once per jiffy.
It's easily possible to overwhelm that machinery with too many call_srcu
callbacks, and Eryu's reproduer did just that.
There's also another potential problem with using call_srcu here. While
you can obviously sleep while holding the srcu_read_lock, the callbacks
run under local_bh_disable, so you can't sleep there.
It's possible when putting the last reference to the fsnotify_mark that
we'll end up putting a chain of references including the fsnotify_group,
uid, and associated keys. While I don't see any obvious ways that that
could occurs, it's probably still best to avoid using call_srcu here
after all.
This patch reverts the above patch. A later patch will take a different
approach to eliminated the dedicated thread here.
Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
Reported-by: Eryu Guan <guaneryu@gmail.com>
Tested-by: Eryu Guan <guaneryu@gmail.com>
Cc: Jan Kara <jack@suse.com>
Cc: Eric Paris <eparis@parisplace.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Grazvydas Ignotas has reported a regression in remap_file_pages()
emulation.
Testcase:
#define _GNU_SOURCE
#include <assert.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/mman.h>
#define SIZE (4096 * 3)
int main(int argc, char **argv)
{
unsigned long *p;
long i;
p = mmap(NULL, SIZE, PROT_READ | PROT_WRITE,
MAP_SHARED | MAP_ANONYMOUS, -1, 0);
if (p == MAP_FAILED) {
perror("mmap");
return -1;
}
for (i = 0; i < SIZE / 4096; i++)
p[i * 4096 / sizeof(*p)] = i;
if (remap_file_pages(p, 4096, 0, 1, 0)) {
perror("remap_file_pages");
return -1;
}
if (remap_file_pages(p, 4096 * 2, 0, 1, 0)) {
perror("remap_file_pages");
return -1;
}
assert(p[0] == 1);
munmap(p, SIZE);
return 0;
}
The second remap_file_pages() fails with -EINVAL.
The reason is that remap_file_pages() emulation assumes that the target
vma covers whole area we want to over map. That assumption is broken by
first remap_file_pages() call: it split the area into two vma.
The solution is to check next adjacent vmas, if they map the same file
with the same flags.
Fixes: c8d78c1823 ("mm: replace remap_file_pages() syscall with emulation")
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Reported-by: Grazvydas Ignotas <notasas@gmail.com>
Tested-by: Grazvydas Ignotas <notasas@gmail.com>
Cc: <stable@vger.kernel.org> [4.0+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
DAX doesn't deposit pgtables when it maps huge pages: nothing to
withdraw. It can lead to crash.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Matthew Wilcox <willy@linux.intel.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
A non-atomic PCM stream may take snd_pcm_link_rwsem rw semaphore twice
in the same code path, e.g. one in snd_pcm_action_nonatomic() and
another in snd_pcm_stream_lock(). Usually this is OK, but when a
write lock is issued between these two read locks, the problem
happens: the write lock is blocked due to the first reade lock, and
the second read lock is also blocked by the write lock. This
eventually deadlocks.
The reason is the way rwsem manages waiters; it's queued like FIFO, so
even if the writer itself doesn't take the lock yet, it blocks all the
waiters (including reads) queued after it.
As a workaround, in this patch, we replace the standard down_write()
with an spinning loop. This is far from optimal, but it's good
enough, as the spinning time is supposed to be relatively short for
normal PCM operations, and the code paths requiring the write lock
aren't called so often.
Reported-by: Vinod Koul <vinod.koul@intel.com>
Tested-by: Ramesh Babu <ramesh.babu@intel.com>
Cc: <stable@vger.kernel.org> # v3.18+
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Remove the ftrace module notifier in favor of directly calling
ftrace_module_enable() and ftrace_release_mod() in the module loader.
Hard-coding the function calls directly in the module loader removes
dependence on the module notifier call chain and provides better
visibility and control over what gets called when, which is important
to kernel utilities such as livepatch.
This fixes a notifier ordering issue in which the ftrace module notifier
(and hence ftrace_module_enable()) for coming modules was being called
after klp_module_notify(), which caused livepatch modules to initialize
incorrectly. This patch removes dependence on the module notifier call
chain in favor of hard coding the corresponding function calls in the
module loader. This ensures that ftrace and livepatch code get called in
the correct order on patch module load and unload.
Fixes: 5156dca34a ("ftrace: Fix the race between ftrace and insmod")
Signed-off-by: Jessica Yu <jeyu@redhat.com>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Petr Mladek <pmladek@suse.cz>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Reviewed-by: Josh Poimboeuf <jpoimboe@redhat.com>
Reviewed-by: Miroslav Benes <mbenes@suse.cz>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Pull block fixes from Jens Axboe:
"A collection of fixes from the past few weeks that should go into 4.5.
This contains:
- Overflow fix for sysfs discard show function from Alan.
- A stacking limit init fix for max_dev_sectors, so we don't end up
artificially capping some use cases. From Keith.
- Have blk-mq proper end unstarted requests on a dying queue, instead
of pushing that to the driver. From Keith.
- NVMe:
- Update to Kconfig description for NVME_SCSI, since it was
vague and having it on is important for some SUSE distros.
From Christoph.
- Set of fixes from Keith, around surprise removal. Also kills
the no-merge flag, so it supports merging.
- Set of fixes for lightnvm from Matias, Javier, and Wenwei.
- Fix null_blk oops when asked for lightnvm, but not available. From
Matias.
- Copy-to-user EINTR fix from Hannes, fixing a case where SG_IO fails
if interrupted by a signal.
- Two floppy fixes from Jiri, fixing signal handling and blocking
open.
- A use-after-free fix for O_DIRECT, from Mike Krinkin.
- A block module ref count fix from Roman Pen.
- An fs IO wait accounting fix for O_DSYNC from Stephane Gasparini.
- Smaller reallo fix for xen-blkfront from Bob Liu.
- Removal of an unused struct member in the deadline IO scheduler,
from Tahsin.
- Also from Tahsin, properly initialize inode struct members
associated with cgroup writeback, if enabled.
- From Tejun, ensure that we keep the superblock pinned during cgroup
writeback"
* 'for-linus' of git://git.kernel.dk/linux-block: (25 commits)
blk: fix overflow in queue_discard_max_hw_show
writeback: initialize inode members that track writeback history
writeback: keep superblock pinned during cgroup writeback association switches
bio: return EINTR if copying to user space got interrupted
NVMe: Rate limit nvme IO warnings
NVMe: Poll device while still active during remove
NVMe: Requeue requests on suspended queues
NVMe: Allow request merges
NVMe: Fix io incapable return values
blk-mq: End unstarted requests on dying queue
block: Initialize max_dev_sectors to 0
null_blk: oops when initializing without lightnvm
block: fix module reference leak on put_disk() call for cgroups throttle
nvme: fix Kconfig description for BLK_DEV_NVME_SCSI
kernel/fs: fix I/O wait not accounted for RW O_DSYNC
floppy: refactor open() flags handling
lightnvm: allow to force mm initialization
lightnvm: check overflow and correct mlc pairs
lightnvm: fix request intersection locking in rrpc
lightnvm: warn if irqs are disabled in lock laddr
...
Pull drm fixes from Dave Airlie:
"This has two main sets of fixes:
- A bunch of Exynos fixes, mainly for their MIC component.
- vblank regression fixes from Mario, apparantly some changes in 4.4
caused some vblank breakage on radeon/nouveau, this set fixes all
the issues seen.
There is also a revert of one of the MST changse, that I was
overzealous in including, that broke 30" MST monitors, and two qxl
fixes"
* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/qxl: fix erroneous return value
drm/nouveau/display: Enable vblank irqs after display engine is on again.
drm/radeon/pm: Handle failure of drm_vblank_get.
drm: Fix treatment of drm_vblank_offdelay in drm_vblank_on() (v2)
drm: Fix drm_vblank_pre/post_modeset regression from Linux 4.4
drm: Prevent vblank counter bumps > 1 with active vblank clients. (v2)
drm: No-Op redundant calls to drm_vblank_off() (v2)
drm/qxl: use kmalloc_array to alloc reloc_info in qxl_process_single_command
Revert "drm/dp/mst: change MST detection scheme"
drm/exynos/decon: fix disable clocks order
drm/exynos: fix incorrect cpu address for dma_mmap_attrs()
drm/exynos: exynos5433_decon: fix wrong state in decon_vblank_enable
drm/exynos: exynos5433_decon: fix wrong state assignment in decon_enable
drm/exynos: dsi: restore support for drm bridge
drm/exynos: mic: make all functions static
drm/exynos: mic: convert to component framework
drm/exynos: mic: use devm_clk interface
drm/exynos: fix types for compilation on 64bit architectures
drm/exynos: ipp: fix incorrect format specifiers in debug messages
drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS
The first is something that has come up a few times and has been
worked out individually, but it's come up now enough that the problem
should be generic. Tracepoints are protected by RCU sched. There are
several tracepoints within core infrastructure like kfree().
If a tracepoint is called when the CPU is going down, or when it's
coming up but has yet to be recognized by RCU, a RCU warning is
triggered. This is a true bug as that tracepoint is not protected by
RCU. Usually, this is taken care of by testing for cpu online as
a tracepoint condition. But as this is happening more often, moving
it from a individual tracepoint to a check in the tracepoint infrastructure
is more robust.
Note, there is now a duplicate of a cpu online test, because this update
does not remove the individual checks. But the overhead is small enough
that the removal can be done in another release.
The second change is strange linker breakage due to the branch tracer's
builtin_constant_p() check failing, and treating the condition as a
variable instead of a constant. Arnd Bergmann found that this can be
fixed by testing !!(cond) instead of just (cond).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWw2vTAAoJEKKk/i67LK/8vkMIAI+Fx+S9sCeWVGp4VZ3DKH9K
DibRD/2KREZe1AjYEU8ZAgo+VsFzW8OHiI1TI/1jP61YkiQSIhu6kVdPCoLG5buy
8WwiKEQ94VWC1hbPOiiq3K7THEu+M8zuFdU3+odS8E3sXIGqKPKQ3iFwwfTVHI6o
/cMTuefqsxo/hj8VwwaZdwlgWwLltM8sR040auTTEsqBLZ7D1q0aCyBrnju3FtBt
uSIPK91d92ANkpq3ELDihxBa41XSEahYgGm/ozewjHwpooWvIQz4tpGaxxkyltuE
RzeYBrM5LNBQUaXZ6C6jAdL0Y+bukS2MdNUjv8U6LwKbUvQoLuYteGEQ9g/m+mE=
=8LDX
-----END PGP SIGNATURE-----
Merge tag 'trace-fixes-v4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt:
"This includes two fixes.
The first is something that has come up a few times and has been
worked out individually, but it's come up now enough that the problem
should be generic. Tracepoints are protected by RCU sched. There are
several tracepoints within core infrastructure like kfree(). If a
tracepoint is called when the CPU is going down, or when it's coming
up but has yet to be recognized by RCU, a RCU warning is triggered.
This is a true bug as that tracepoint is not protected by RCU.
Usually, this is taken care of by testing for cpu online as a
tracepoint condition. But as this is happening more often, moving it
from a individual tracepoint to a check in the tracepoint
infrastructure is more robust.
Note, there is now a duplicate of a cpu online test, because this
update does not remove the individual checks. But the overhead is
small enough that the removal can be done in another release.
The second change is strange linker breakage due to the branch
tracer's builtin_constant_p() check failing, and treating the
condition as a variable instead of a constant. Arnd Bergmann found
that this can be fixed by testing !!(cond) instead of just (cond)"
* tag 'trace-fixes-v4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Fix freak link error caused by branch tracer
tracepoints: Do not trace when cpu is offline
We get this right for queue_discard_max_show but not max_hw_show. Follow the
same pattern as queue_discard_max_show instead so that we don't truncate.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Jens Axboe <axboe@fb.com>
This patch ensures that devices, which got registered before arch_initcall
will be handled correctly by IOMMU-based DMA-mapping code.
Cc: <stable@vger.kernel.org>
Fixes: 13b8629f65 ("arm64: Add IOMMU dma_ops")
Acked-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Commit ca369d51b ("sd: Fix device-imposed transfer length limits")
introduced a new queue limit max_dev_sectors which limits the maximum
sectors for requests. The default value leads to small dasd requests
and therefor to a performance drop.
Set the max_dev_sectors value to the same value as the max_hw_sectors
to use the maximum available request size for DASD devices.
Signed-off-by: Stefan Haberland <sth@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org # 4.4+
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
When fixing the DAT off bug ("s390: fix DAT off memory access, e.g.
on kdump") both Christian and I missed that we can save an additional
stnsm instruction.
This saves us a couple of cycles which could improve the speed of
memcpy_real.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
The qxl_gem_prime_mmap() function returns ENOSYS instead of -ENOSYS
Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
In the display resume path, move the calls to drm_vblank_on()
after the point when the display engine is running again.
Since changes were made to drm_update_vblank_count() in Linux 4.4+
to emulate hw vblank counters via vblank timestamping, the function
drm_vblank_on() now needs working high precision vblank timestamping
and therefore working scanout position queries at time of call.
These don't work before the display engine gets restarted, causing
miscalculation of vblank counter increments and thereby large forward
jumps in vblank count at display resume. These jumps can cause client
hangs on resume, or desktop hangs in the case of composited desktops.
Fix this Linux 4.4 regression by reordering calls accordingly.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Cc: <stable@vger.kernel.org> # 4.4+
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
drm_vblank_offdelay can have three different types of values:
< 0 is to be always treated the same as dev->vblank_disable_immediate
= 0 is to be treated as "never disable vblanks"
> 0 is to be treated as disable immediate if kms driver wants it
that way via dev->vblank_disable_immediate. Otherwise it is
a disable timeout in msecs.
This got broken in Linux 3.18+ for the implementation of
drm_vblank_on. If the user specified a value of zero which should
always reenable vblank irqs in this function, a kms driver could
override the users choice by setting vblank_disable_immediate
to true. This patch fixes the regression and keeps the user in
control.
v2: Only reenable vblank if there are clients left or the user
requested to "never disable vblanks" via offdelay 0. Enabling
vblanks even in the "delayed disable" case (offdelay > 0) was
specifically added by Ville in commit cd19e52aee
("drm: Kick start vblank interrupts at drm_vblank_on()"),
but after discussion it turns out that this was done by accident.
Citing Ville: "I think it just ended up as a mess due to changing
some of the semantics of offdelay<0 vs. offdelay==0 vs.
disable_immediate during the review of the series. So yeah, given
how drm_vblank_put() works now, I'd just make this check for
offdelay==0."
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # 3.18+
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Changes to drm_update_vblank_count() in Linux 4.4 broke the
behaviour of the pre/post modeset functions as the new update
code doesn't deal with hw vblank counter resets inbetween calls
to drm_vblank_pre_modeset an drm_vblank_post_modeset, as it
should.
This causes mistreatment of such hw counter resets as counter
wraparound, and thereby large forward jumps of the software
vblank counter which in turn cause vblank event dispatching
and vblank waits to fail/hang --> userspace clients hang.
This symptom was reported on radeon-kms to cause a infinite
hang of KDE Plasma 5 shell's login procedure, preventing users
from logging in.
Fix this by detecting when drm_update_vblank_count() is called
inside a pre->post modeset interval. If so, clamp valid vblank
increments to the safe values 0 and 1, pretty much restoring
the update behavior of the old update code of Linux 4.3 and
earlier. Also reset the last recorded hw vblank count at call
to drm_vblank_post_modeset() to be safe against hw that after
modesetting, dpms on etc. only fires its first vblank irq after
drm_vblank_post_modeset() was already called.
Reported-by: Vlastimil Babka <vbabka@suse.cz>
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Tested-by: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org> # 4.4+
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
This fixes a regression introduced by the new drm_update_vblank_count()
implementation in Linux 4.4:
Restrict the bump of the software vblank counter in drm_update_vblank_count()
to a safe maximum value of +1 whenever there is the possibility that
concurrent readers of vblank timestamps could be active at the moment,
as the current implementation of the timestamp caching and updating is
not safe against concurrent readers for calls to store_vblank() with a
bump of anything but +1. A bump != 1 would very likely return corrupted
timestamps to userspace, because the same slot in the cache could
be concurrently written by store_vblank() and read by one of those
readers in a non-atomic fashion and without the read-retry logic
detecting this collision.
Concurrent readers can exist while drm_update_vblank_count() is called
from the drm_vblank_off() or drm_vblank_on() functions or other non-vblank-
irq callers. However, all those calls are happening with the vbl_lock
locked thereby preventing a drm_vblank_get(), so the vblank refcount
can't increase while drm_update_vblank_count() is executing. Therefore
a zero vblank refcount during execution of that function signals that
is safe for arbitrary counter bumps if called from outside vblank irq,
whereas a non-zero count is not safe.
Whenever the function is called from vblank irq, we have to assume concurrent
readers could show up any time during its execution, even if the refcount
is currently zero, as vblank irqs are usually only enabled due to the
presence of readers, and because when it is called from vblank irq it
can't hold the vbl_lock to protect it from sudden bumps in vblank refcount.
Therefore also restrict bumps to +1 when the function is called from vblank
irq.
Such bumps of more than +1 can happen at other times than reenabling
vblank irqs, e.g., when regular vblank interrupts get delayed by more
than 1 frame due to long held locks, long irq off periods, realtime
preemption on RT kernels, or system management interrupts.
A better solution would be to rewrite the timestamp caching to use
full seqlocks to allow concurrent writes and reads for arbitrary
vblank counter increments.
v2: Add code comment that this is essentially a hack and should
be replaced by a full seqlock implementation for caching of
timestamps.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # 4.4+
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: daniel.vetter@ffwll.ch
Cc: dri-devel@lists.freedesktop.org
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
Otherwise if a kms driver calls into drm_vblank_off() more than once
before calling drm_vblank_on() again, the redundant calls to
vblank_disable_and_save() will call drm_update_vblank_count()
while hw vblank counters and vblank timestamping are in a undefined
state during modesets, dpms off etc.
At least with the legacy drm helpers it is not unusual to
get multiple calls to drm_vblank_off and drm_vblank_on, e.g.,
half a dozen calls to drm_vblank_off and two calls to drm_vblank_on
were observed on radeon-kms during dpms-off -> dpms-on transition.
We don't no-op calls from atomic modesetting drivers, as they
should do a proper job of tracking hw state.
Fixes large jumps of the software maintained vblank counter due to
the hardware vblank counter resetting to zero during dpms off or
modeset, e.g., if radeon-kms is modified to use drm_vblank_off/on
instead of drm_vblank_pre/post_modeset().
This fixes a regression caused by the changes made to
drm_update_vblank_count() in Linux 4.4.
v2: Don't no-op on atomic modesetting drivers, per suggestion
of Daniel Vetter.
Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org> # 4.4+
Cc: michel@daenzer.net
Cc: vbabka@suse.cz
Cc: ville.syrjala@linux.intel.com
Cc: alexander.deucher@amd.com
Cc: christian.koenig@amd.com
Signed-off-by: Dave Airlie <airlied@redhat.com>
This avoids integer overflows on 32bit machines when calculating
reloc_info size, as reported by Alan Cox.
Cc: stable@vger.kernel.org
Cc: gnomes@lxorguk.ukuu.org.uk
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Summary:
- fix compilation warnings on ARM64bit.
- fix mic driver initialization.
. MIC is a part of KMS so it converts it to use component framework
like other KMS drivers did.
- fix wrong driver state and disable clock order on DECON driver.
- fix incorrect use of dma_mmap_attrs function.
* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
drm/exynos/decon: fix disable clocks order
drm/exynos: fix incorrect cpu address for dma_mmap_attrs()
drm/exynos: exynos5433_decon: fix wrong state in decon_vblank_enable
drm/exynos: exynos5433_decon: fix wrong state assignment in decon_enable
drm/exynos: dsi: restore support for drm bridge
drm/exynos: mic: make all functions static
drm/exynos: mic: convert to component framework
drm/exynos: mic: use devm_clk interface
drm/exynos: fix types for compilation on 64bit architectures
drm/exynos: ipp: fix incorrect format specifiers in debug messages
drm/exynos: depend on ARCH_EXYNOS for DRM_EXYNOS
This reverts commit cfcfa086d4.
This causes the tiling properties to break in some unexpected ways,
Revert it for now.
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
inode struct members that track cgroup writeback information
should be reinitialized when inode gets allocated from
kmem_cache. Otherwise, their values remain and get used by the
new inode.
Signed-off-by: Tahsin Erdogan <tahsin@google.com>
Acked-by: Tejun Heo <tj@kernel.org>
Fixes: d10c809552 ("writeback: implement foreign cgroup inode bdi_writeback switching")
Signed-off-by: Jens Axboe <axboe@fb.com>
Pull cifs fixes from Steve French:
"A small set of cifs fixes.
I am still reviewing some more, recently submitted SMB3 fixes, but
these three are small and safe and ready now"
* 'for-next' of git://git.samba.org/sfrench/cifs-2.6:
cifs: fix erroneous return value
cifs: fix potential overflow in cifs_compose_mount_options
cifs: remove redundant check for null string pointer
- Fix for an unpleasant crash when the VM is created without a timer
- Allow HYP mode to access the full PA space, and not only 40bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQEcBAABAgAGBQJWw2HjAAoJEL/70l94x66DdAwH/iM6R6dlgNk60X0oquujAbra
p9t/6ulNDxMHz/ICQkk6VuH12XMQS9dYr22SLUGuDOVOyB3VB6SQk3H+t4yUUIuD
8HY3ZVFGoX56EsTel3S3/elIksG9SLPIyma8FImbMvPzjTV8KLqEEexZVmMpq8og
ufG5rPkwBbg2r4OMl8NBmaGB822IMT8WfL5ECsnml5BDnU4Eo680AcMm8FZgqRTS
cKiT04QkRhQAiemoVdIPJhAcslSTTj5o6cmD1XwcmRR4z3HdZFBAt+IigC9ZQvnE
Y7J9L7pBgzr8j91lFRPcv1pM0D5+EOP4C3mjNDg4ghvvjko0S8UNS1EhRL1upk0=
=DJUb
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull ARM KVM fixes from Paolo Bonzini:
- Fix for an unpleasant crash when the VM is created without a timer
- Allow HYP mode to access the full PA space, and not only 40bit
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
arm64: KVM: Configure TCR_EL2.PS at runtime
KVM: arm/arm64: Fix reference to uninitialised VGIC
If cgroup writeback is in use, an inode is associated with a cgroup
for writeback. If the inode's main dirtier changes to another cgroup,
the association gets updated asynchronously. Nothing was pinning the
superblock while such switches are in progress and superblock could go
away while async switching is pending or in progress leading to
crashes like the following.
kernel BUG at fs/jbd2/transaction.c:319!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
CPU: 1 PID: 29158 Comm: kworker/1:10 Not tainted 4.5.0-rc3 #51
Hardware name: Google Google, BIOS Google 01/01/2011
Workqueue: events inode_switch_wbs_work_fn
task: ffff880213dbbd40 ti: ffff880209264000 task.ti: ffff880209264000
RIP: 0010:[<ffffffff803e6922>] [<ffffffff803e6922>] start_this_handle+0x382/0x3e0
RSP: 0018:ffff880209267c30 EFLAGS: 00010202
...
Call Trace:
[<ffffffff803e6be4>] jbd2__journal_start+0xf4/0x190
[<ffffffff803cfc7e>] __ext4_journal_start_sb+0x4e/0x70
[<ffffffff803b31ec>] ext4_evict_inode+0x12c/0x3d0
[<ffffffff8035338b>] evict+0xbb/0x190
[<ffffffff80354190>] iput+0x130/0x190
[<ffffffff80360223>] inode_switch_wbs_work_fn+0x343/0x4c0
[<ffffffff80279819>] process_one_work+0x129/0x300
[<ffffffff80279b16>] worker_thread+0x126/0x480
[<ffffffff8027ed14>] kthread+0xc4/0xe0
[<ffffffff809771df>] ret_from_fork+0x3f/0x70
Fix it by bumping s_active while cgroup association switching is in
flight.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-and-tested-by: Tahsin Erdogan <tahsin@google.com>
Link: http://lkml.kernel.org/g/CAAeU0aNCq7LGODvVGRU-oU_o-6enii5ey0p1c26D1ZzYwkDc5A@mail.gmail.com
Fixes: d10c809552 ("writeback: implement foreign cgroup inode bdi_writeback switching")
Cc: stable@vger.kernel.org #v4.5+
Signed-off-by: Jens Axboe <axboe@fb.com>
- Fix for an unpleasant crash when the VM is created without a timer
- Allow HYP mode to access the full PA space, and not only 40bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJWvK38AAoJECPQ0LrRPXpDZisQAIt7fQOYAl/qcDb9rWcKVlUK
ExOjVW1fJ8PTB1lMp0fdIATIfWQZUHc3mdZ2BixllPopUbTRn2+UXNR0lm4+C6Dq
SnqGuIlBkOIbKyJcxTLYQv3fgApZ7qRTCLDJv6XCm5tou2y6TWvLm+sikILWNaij
dDXIt35qxnF2lGqynW9k/mz11BEr7v1VsL1riJRI+p/wPTePs2KF5XR3ufKlpQJT
1u6NwG+QR+AJmKqFgrNPOx2IbpmEJ+Kxta7Qk+2HhNgdKeMFGe+6t1PsYmNV3p0v
/eRXNDKDyhJG98ALR0dxruqUhqgfjyIdhZ4uORHiqKw4P8Tt0tG0DQ2lh9QzO8KN
r9PjqgBKW7ciQ5Bi7xRu1qfeuc5P+aoXYg80FfpUzqBFsjxTu70G5ekDr/bvr9Ky
ymwHDIuULW9l2LZfh9xDVZEPWGqpb8Bt4g1B9Og6NUrQmHH63FY7gcB92ceECMc3
gmsnhW7C3PXO1DCDHDD4KPTd7iXoD4jotMB0bFQc09F+ulXlU877i7D2ZPyzrqF+
YPQ6LWYiHe4y2Hl2SHj0/pL2XHadutSxIRhHRCLEgRa0pGSEnZREye33hw3m/Oyq
/t7bYNsPCtNv4+IS9hhlYdmP3skz0IqvKl7WYmSKf2sYiHnlbuNRojKtcQXuhTiz
0Nsn66/97wXgtGdPqPln
=1qeo
-----END PGP SIGNATURE-----
Merge tag 'kvm-arm-for-4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master
KVM/ARM fixes for 4.5-rc4
- Fix for an unpleasant crash when the VM is created without a timer
- Allow HYP mode to access the full PA space, and not only 40bit
Minor register size and interrupt acknowledgement fixes which only showed
up in testing on newer hardware, but mostly a fix to the MM refcount
handling to prevent a recursive refcount issue when mmap() is used on
the file descriptor associated with a bound PASID.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEABECAAYFAlbC/gAACgkQdwG7hYl686OY8QCfUPH+IB0zou9/MH3JNMz1ujot
I6wAoK0R4KiOFXvjNeNPy+XroZ9xKqv/
=RM+0
-----END PGP SIGNATURE-----
Merge tag 'for-linus-20160216' of git://git.infradead.org/intel-iommu
Pull IOMMU SVM fixes from David Woodhouse:
"Minor register size and interrupt acknowledgement fixes which only
showed up in testing on newer hardware, but mostly a fix to the MM
refcount handling to prevent a recursive refcount issue when mmap() is
used on the file descriptor associated with a bound PASID"
* tag 'for-linus-20160216' of git://git.infradead.org/intel-iommu:
iommu/vt-d: Clear PPR bit to ensure we get more page request interrupts
iommu/vt-d: Fix 64-bit accesses to 32-bit DMAR_GSTS_REG
iommu/vt-d: Fix mm refcounting to hold mm_count not mm_users
A small clutch of driver specific fixes. The OMAP one is a bit worrying
since it seems to be triggered by some changes in the runtime PM core
code and I suspect there's other drivers across that are going to be
using the same pattern outside of OMAP but nothing seems to be coming up
in the testing people are doing.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJWwcN2AAoJECTWi3JdVIfQM9IH/2WWGIU4ByQeHLd7FnNHQwZk
wh4g7xpo/SRzob2rz2yqeKgkIg4Ew4+BsD5jslvGhBn9ph5HIFYHVcHt3vjVUNRE
EyOoM8X4lLc97LYog10ieXk5dFkvcCTDYoQDcTxVDmMPRsRrt2Z7htTB4jAbhlk/
kH5nJCir4Cwk5qDTw7+9W8d5hCXl3ESM7KoTCqtvpA8JmTD++vRcphp39NWZejAw
ukO/EAJcwqlTmds3zki1/lM6R4NBtbAE2BGy9j0eUQnL3/37Sl77hAxcsKjey1Zj
dVa8ow9ZRTEZtbCQjrK8WpD3V26TNuUGZs4qEQ+nizQnvAnrqgkfOOg6wBJ6LDg=
=imJW
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A small clutch of driver specific fixes.
The OMAP one is a bit worrying since it seems to be triggered by some
changes in the runtime PM core code and I suspect there's other
drivers across that are going to be using the same pattern outside of
OMAP but nothing seems to be coming up in the testing people are
doing"
* tag 'spi-fix-v4.5-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: omap2-mcspi: Fix PM regression with deferred probe for pm_runtime_reinit
spi: bcm2835aux: fix bitmask defines
spi: atmel: fix gpio chip-select in case of non-DT platform
spi/fsl-espi: Correct the maximum transaction length
spi: imx: fix spi resource leak with dma transfer
spi: fix counting in spi-loopback-test code
Pull m68k fixes from Geert Uytterhoeven:
"Summary:
- Wire up new copy_file_range syscall
- Update defconfigs"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k:
m68k/defconfig: Update defconfigs for v4.5-rc1
m68k: Wire up copy_file_range
The commit [7f0973e973cd: ALSA: seq: Fix lockdep warnings due to
double mutex locks] split the management of two linked lists (source
and destination) into two individual calls for avoiding the AB/BA
deadlock. However, this may leave the possible double deletion of one
of two lists when the counterpart is being deleted concurrently.
It ends up with a list corruption, as revealed by syzkaller fuzzer.
This patch fixes it by checking the list emptiness and skipping the
deletion and the following process.
BugLink: http://lkml.kernel.org/r/CACT4Y+bay9qsrz6dQu31EcGaH9XwfW7o3oBzSQUG9fMszoh=Sg@mail.gmail.com
Fixes: 7f0973e973 ('ALSA: seq: Fix lockdep warnings due to 'double mutex locks)
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Tested-by: Dmitry Vyukov <dvyukov@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Changes introduced in the upstream version of libfdt pulled in by commit
91feabc2e2 ("scripts/dtc: Update to upstream commit b06e55c88b9b") use
the strnlen() function, which isn't currently available to the EFI name-
space. Add it to the EFI namespace to avoid a linker error.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Rob Herring <robh@kernel.org>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Previously, samsung_gpio_drection_in/output function were not covered
with a spinlock.
For example, samsung_gpio_direction_output function consists of
two functions.
1. samsung_gpio_set
2. samsung_gpio_set_direction
When 2 CPUs try to control the same gpio pin heavily,
(situation like i2c control with gpio emulation)
This situation can cause below problem.
CPU 0 | CPU1
|
samsung_gpio_direction_output |
samsung_gpio_set(pin A as 1) | samsung_gpio_direction_output
| samsung_gpio_set(pin A as 0)
samsung_gpio_set_direction |
| samsung_gpio_set_direction
The initial value of pin A will be set as 0 while we wanted to set pin A as 1.
This patch modifies samsung_gpio_direction_in/output function
to be done in one spinlock to fix race condition.
Additionally, the new samsung_gpio_set_value was added to implement
gpio set callback(samsung_gpio_set) with spinlock using this function.
Cc: stable@vger.kernel.org
Signed-off-by: Youngmin Nam <ym0914@gmail.com>
Acked-by: Tomasz Figa <tomasz.figa@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
