Pull xfs fixes from Darrick Wong:
- Avoid leaking kernel stack contents to userspace
- Fix a potential null pointer dereference in the dabtree scrub code
* tag 'xfs-5.3-fixes-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: Fix possible null-pointer dereferences in xchk_da_btree_block_check_sibling()
xfs: fix stack contents leakage in the v1 inumber ioctls
Merge misc fixes from Andrew Morton:
"17 fixes"
* emailed patches from Andrew Morton <akpm@linux-foundation.org>:
drivers/acpi/scan.c: document why we don't need the device_hotplug_lock
memremap: move from kernel/ to mm/
lib/test_meminit.c: use GFP_ATOMIC in RCU critical section
asm-generic: fix -Wtype-limits compiler warnings
cgroup: kselftest: relax fs_spec checks
mm/memory_hotplug.c: remove unneeded return for void function
mm/migrate.c: initialize pud_entry in migrate_vma()
coredump: split pipe command whitespace before expanding template
page flags: prioritize kasan bits over last-cpuid
ubsan: build ubsan.c more conservatively
kasan: remove clang version check for KASAN_STACK
mm: compaction: avoid 100% CPU usage during compaction when a task is killed
mm: migrate: fix reference check race between __find_get_block() and migration
mm: vmscan: check if mem cgroup is disabled or not before calling memcg slab shrinker
ocfs2: remove set but not used variable 'last_hash'
Revert "kmemleak: allow to coexist with fault injection"
kernel/signal.c: fix a kernel-doc markup
Three minor RISC-V-related changes for v5.3-rc3:
- Add build ID to VDSO builds to avoid a double-free in perf when
libelf isn't used
- Align the RV64 defconfig to the output of "make savedefconfig" so
subsequent defconfig patches don't get out of hand
- Drop a superfluous DT property from the FU540 SoC DT data (since it
must be already set in board data that includes it)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElRDoIDdEz9/svf2Kx4+xDQu9KksFAl1Fk/wACgkQx4+xDQu9
KkuE7w/+KUTC3UVH0kmgLHWTDpBpIM9fCEHBf6yFeNcodKt4a6cOasQcKxH2W1Ly
RdgEvIjB25vA9hjOqs9c1CI62WWN4oZ/HoRgKrhqR9v20nMTXEBMN/3Avv/01Q8t
W3vOvKViwSmft1MpgY4bnD8ECGFU8C4P/uwQj3YTj9qNhcxCf8uOM+PEpaYYckin
YogUjQWYbyQCAnt+FECvPr6fq0TGLSVedF4oe+3AX/P4XBDmyWJ0xnSqZsUaa1/x
g34dCVAbKTnHKlN1diq1QeGySv4w9EmLx2IXARFhVemiIr+BpES8pDmrmSylnOH8
SdJHttpvDvGSIQEPS3ja2gufQNs0INeQoRmAe1IUWkw1UgYjH9AQ0GsK6xONCUGQ
YB6Sc/9NPZa8xAkRBgNiv0W2v1QTxUAwInT7/tYf9r4YFXEZl8YMp/73Y4w4W8fV
4oym0JCUUuS5hTb2fUYA7dssprMdx620hl6X973spzbFEcciQKX2IDn9rrpu6buU
5nHz2tA76eFbIaJ52P4DPTDncOvRGHj0BpfnzsUa72Vucf1tkg9bkD7ZT1TRglCP
86c2FNE15+NMKG6i6x98voRJJ+gSBSPalTebyX3sU8SZvRkHogahuIB+JPooD/8m
rnuTK26M8uGigoTEtN9sqhcx/95HdM4EyyfE2KyTJryeTU9GqCA=
=CIhE
-----END PGP SIGNATURE-----
Merge tag 'riscv/for-v5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux
Pull RISC-V fixes from Paul Walmsley:
"Three minor RISC-V-related changes for v5.3-rc3:
- Add build ID to VDSO builds to avoid a double-free in perf when
libelf isn't used
- Align the RV64 defconfig to the output of "make savedefconfig" so
subsequent defconfig patches don't get out of hand
- Drop a superfluous DT property from the FU540 SoC DT data (since it
must be already set in board data that includes it)"
* tag 'riscv/for-v5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux:
riscv: defconfig: align RV64 defconfig to the output of "make savedefconfig"
riscv: dts: fu540-c000: drop "timebase-frequency"
riscv: Fix perf record without libelf support
Let's document why the lock is not needed in acpi_scan_init(), right now
this is not really obvious.
[akpm@linux-foundation.org: fix tpyo]
Link: http://lkml.kernel.org/r/20190731135306.31524-1-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Oscar Salvador <osalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
memremap.c implements MM functionality for ZONE_DEVICE, so it really
should be in the mm/ directory, not the kernel/ one.
Link: http://lkml.kernel.org/r/20190722094143.18387-1-hch@lst.de
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
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>
kmalloc() shouldn't sleep while in RCU critical section, therefore use
GFP_ATOMIC instead of GFP_KERNEL.
The bug was spotted by the 0day kernel testing robot.
Link: http://lkml.kernel.org/r/20190725121703.210874-1-glider@google.com
Fixes: 7e659650cbda ("lib: introduce test_meminit module")
Signed-off-by: Alexander Potapenko <glider@google.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: kernel test robot <lkp@intel.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Commit d66acc39c7 ("bitops: Optimise get_order()") introduced a
compilation warning because "rx_frag_size" is an "ushort" while
PAGE_SHIFT here is 16.
The commit changed the get_order() to be a multi-line macro where
compilers insist to check all statements in the macro even when
__builtin_constant_p(rx_frag_size) will return false as "rx_frag_size"
is a module parameter.
In file included from ./arch/powerpc/include/asm/page_64.h:107,
from ./arch/powerpc/include/asm/page.h:242,
from ./arch/powerpc/include/asm/mmu.h:132,
from ./arch/powerpc/include/asm/lppaca.h:47,
from ./arch/powerpc/include/asm/paca.h:17,
from ./arch/powerpc/include/asm/current.h:13,
from ./include/linux/thread_info.h:21,
from ./arch/powerpc/include/asm/processor.h:39,
from ./include/linux/prefetch.h:15,
from drivers/net/ethernet/emulex/benet/be_main.c:14:
drivers/net/ethernet/emulex/benet/be_main.c: In function 'be_rx_cqs_create':
./include/asm-generic/getorder.h:54:9: warning: comparison is always
true due to limited range of data type [-Wtype-limits]
(((n) < (1UL << PAGE_SHIFT)) ? 0 : \
^
drivers/net/ethernet/emulex/benet/be_main.c:3138:33: note: in expansion
of macro 'get_order'
adapter->big_page_size = (1 << get_order(rx_frag_size)) * PAGE_SIZE;
^~~~~~~~~
Fix it by moving all of this multi-line macro into a proper function,
and killing __get_order() off.
[akpm@linux-foundation.org: remove __get_order() altogether]
[cai@lca.pw: v2]
Link: http://lkml.kernel.org/r/1564000166-31428-1-git-send-email-cai@lca.pw
Link: http://lkml.kernel.org/r/1563914986-26502-1-git-send-email-cai@lca.pw
Fixes: d66acc39c7 ("bitops: Optimise get_order()")
Signed-off-by: Qian Cai <cai@lca.pw>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: David Howells <dhowells@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Bill Wendling <morbo@google.com>
Cc: James Y Knight <jyknight@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
On my laptop most memcg kselftests were being skipped because it claimed
cgroup v2 hierarchy wasn't mounted, but this isn't correct. Instead, it
seems current systemd HEAD mounts it with the name "cgroup2" instead of
"cgroup":
% grep cgroup /proc/mounts
cgroup2 /sys/fs/cgroup cgroup2 rw,nosuid,nodev,noexec,relatime,nsdelegate 0 0
I can't think of a reason to need to check fs_spec explicitly
since it's arbitrary, so we can just rely on fs_vfstype.
After these changes, `make TARGETS=cgroup kselftest` actually runs the
cgroup v2 tests in more cases.
Link: http://lkml.kernel.org/r/20190723210737.GA487@chrisdown.name
Signed-off-by: Chris Down <chris@chrisdown.name>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
return is unneeded in void function
Link: http://lkml.kernel.org/r/20190723130814.21826-1-houweitaoo@gmail.com
Signed-off-by: Weitao Hou <houweitaoo@gmail.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Oscar Salvador <osalvador@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When CONFIG_MIGRATE_VMA_HELPER is enabled, migrate_vma() calls
migrate_vma_collect() which initializes a struct mm_walk but didn't
initialize mm_walk.pud_entry. (Found by code inspection) Use a C
structure initialization to make sure it is set to NULL.
Link: http://lkml.kernel.org/r/20190719233225.12243-1-rcampbell@nvidia.com
Fixes: 8763cb45ab ("mm/migrate: new memory migration helper for use with device memory")
Signed-off-by: Ralph Campbell <rcampbell@nvidia.com>
Reviewed-by: John Hubbard <jhubbard@nvidia.com>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Save the offsets of the start of each argument to avoid having to update
pointers to each argument after every corename krealloc and to avoid
having to duplicate the memory for the dump command.
Executable names containing spaces were previously being expanded from
%e or %E and then split in the middle of the filename. This is
incorrect behaviour since an argument list can represent arguments with
spaces.
The splitting could lead to extra arguments being passed to the core
dump handler that it might have interpreted as options or ignored
completely.
Core dump handlers that are not aware of this Linux kernel issue will be
using %e or %E without considering that it may be split and so they will
be vulnerable to processes with spaces in their names breaking their
argument list. If their internals are otherwise well written, such as
if they are written in shell but quote arguments, they will work better
after this change than before. If they are not well written, then there
is a slight chance of breakage depending on the details of the code but
they will already be fairly broken by the split filenames.
Core dump handlers that are aware of this Linux kernel issue will be
placing %e or %E as the last item in their core_pattern and then
aggregating all of the remaining arguments into one, separated by
spaces. Alternatively they will be obtaining the filename via other
methods. Both of these will be compatible with the new arrangement.
A side effect from this change is that unknown template types (for
example %z) result in an empty argument to the dump handler instead of
the argument being dropped. This is a desired change as:
It is easier for dump handlers to process empty arguments than dropped
ones, especially if they are written in shell or don't pass each
template item with a preceding command-line option in order to
differentiate between individual template types. Most core_patterns in
the wild do not use options so they can confuse different template types
(especially numeric ones) if an earlier one gets dropped in old kernels.
If the kernel introduces a new template type and a core_pattern uses it,
the core dump handler might not expect that the argument can be dropped
in old kernels.
For example, this can result in security issues when %d is dropped in
old kernels. This happened with the corekeeper package in Debian and
resulted in the interface between corekeeper and Linux having to be
rewritten to use command-line options to differentiate between template
types.
The core_pattern for most core dump handlers is written by the handler
author who would generally not insert unknown template types so this
change should be compatible with all the core dump handlers that exist.
Link: http://lkml.kernel.org/r/20190528051142.24939-1-pabs3@bonedaddy.net
Fixes: 74aadce986 ("core_pattern: allow passing of arguments to user mode helper when core_pattern is a pipe")
Signed-off-by: Paul Wise <pabs3@bonedaddy.net>
Reported-by: Jakub Wilk <jwilk@jwilk.net> [https://bugs.debian.org/924398]
Reported-by: Paul Wise <pabs3@bonedaddy.net> [https://lore.kernel.org/linux-fsdevel/c8b7ecb8508895bf4adb62a748e2ea2c71854597.camel@bonedaddy.net/]
Suggested-by: Jakub Wilk <jwilk@jwilk.net>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
ARM64 randdconfig builds regularly run into a build error, especially
when NUMA_BALANCING and SPARSEMEM are enabled but not SPARSEMEM_VMEMMAP:
#error "KASAN: not enough bits in page flags for tag"
The last-cpuid bits are already contitional on the available space, so
the result of the calculation is a bit random on whether they were
already left out or not.
Adding the kasan tag bits before last-cpuid makes it much more likely to
end up with a successful build here, and should be reliable for
randconfig at least, as long as that does not randomize NR_CPUS or
NODES_SHIFT but uses the defaults.
In order for the modified check to not trigger in the x86 vdso32 code
where all constants are wrong (building with -m32), enclose all the
definitions with an #ifdef.
[arnd@arndb.de: build fix]
Link: http://lkml.kernel.org/r/CAK8P3a3Mno1SWTcuAOT0Wa9VS15pdU6EfnkxLbDpyS55yO04+g@mail.gmail.com
Link: http://lkml.kernel.org/r/20190722115520.3743282-1-arnd@arndb.de
Link: https://lore.kernel.org/lkml/20190618095347.3850490-1-arnd@arndb.de/
Fixes: 2813b9c029 ("kasan, mm, arm64: tag non slab memory allocated via pagealloc")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Andrey Konovalov <andreyknvl@google.com>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
objtool points out several conditions that it does not like, depending
on the combination with other configuration options and compiler
variants:
stack protector:
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0xbf: call to __stack_chk_fail() with UACCESS enabled
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0xbe: call to __stack_chk_fail() with UACCESS enabled
stackleak plugin:
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x4a: call to stackleak_track_stack() with UACCESS enabled
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x4a: call to stackleak_track_stack() with UACCESS enabled
kasan:
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch()+0x25: call to memcpy() with UACCESS enabled
lib/ubsan.o: warning: objtool: __ubsan_handle_type_mismatch_v1()+0x25: call to memcpy() with UACCESS enabled
The stackleak and kasan options just need to be disabled for this file
as we do for other files already. For the stack protector, we already
attempt to disable it, but this fails on clang because the check is
mixed with the gcc specific -fno-conserve-stack option. According to
Andrey Ryabinin, that option is not even needed, dropping it here fixes
the stackprotector issue.
Link: http://lkml.kernel.org/r/20190722125139.1335385-1-arnd@arndb.de
Link: https://lore.kernel.org/lkml/20190617123109.667090-1-arnd@arndb.de/t/
Link: https://lore.kernel.org/lkml/20190722091050.2188664-1-arnd@arndb.de/t/
Fixes: d08965a27e ("x86/uaccess, ubsan: Fix UBSAN vs. SMAP")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Andy Shevchenko <andriy.shevchenko@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>
asan-stack mode still uses dangerously large kernel stacks of tens of
kilobytes in some drivers, and it does not seem that anyone is working
on the clang bug.
Turn it off for all clang versions to prevent users from accidentally
enabling it once they update to clang-9, and to help automated build
testing with clang-9.
Link: https://bugs.llvm.org/show_bug.cgi?id=38809
Link: http://lkml.kernel.org/r/20190719200347.2596375-1-arnd@arndb.de
Fixes: 6baec880d7 ("kasan: turn off asan-stack for clang-8 and earlier")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Qian Cai <cai@lca.pw>
Cc: Andrey Konovalov <andreyknvl@google.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
"howaboutsynergy" reported via kernel buzilla number 204165 that
compact_zone_order was consuming 100% CPU during a stress test for
prolonged periods of time. Specifically the following command, which
should exit in 10 seconds, was taking an excessive time to finish while
the CPU was pegged at 100%.
stress -m 220 --vm-bytes 1000000000 --timeout 10
Tracing indicated a pattern as follows
stress-3923 [007] 519.106208: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0
stress-3923 [007] 519.106212: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0
stress-3923 [007] 519.106216: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0
stress-3923 [007] 519.106219: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0
stress-3923 [007] 519.106223: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0
stress-3923 [007] 519.106227: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0
stress-3923 [007] 519.106231: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0
stress-3923 [007] 519.106235: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0
stress-3923 [007] 519.106238: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0
stress-3923 [007] 519.106242: mm_compaction_isolate_migratepages: range=(0x70bb80 ~ 0x70bb80) nr_scanned=0 nr_taken=0
Note that compaction is entered in rapid succession while scanning and
isolating nothing. The problem is that when a task that is compacting
receives a fatal signal, it retries indefinitely instead of exiting
while making no progress as a fatal signal is pending.
It's not easy to trigger this condition although enabling zswap helps on
the basis that the timing is altered. A very small window has to be hit
for the problem to occur (signal delivered while compacting and
isolating a PFN for migration that is not aligned to SWAP_CLUSTER_MAX).
This was reproduced locally -- 16G single socket system, 8G swap, 30%
zswap configured, vm-bytes 22000000000 using Colin Kings stress-ng
implementation from github running in a loop until the problem hits).
Tracing recorded the problem occurring almost 200K times in a short
window. With this patch, the problem hit 4 times but the task existed
normally instead of consuming CPU.
This problem has existed for some time but it was made worse by commit
cf66f0700c ("mm, compaction: do not consider a need to reschedule as
contention"). Before that commit, if the same condition was hit then
locks would be quickly contended and compaction would exit that way.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204165
Link: http://lkml.kernel.org/r/20190718085708.GE24383@techsingularity.net
Fixes: cf66f0700c ("mm, compaction: do not consider a need to reschedule as contention")
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Cc: <stable@vger.kernel.org> [5.1+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
buffer_migrate_page_norefs() can race with bh users in the following
way:
CPU1 CPU2
buffer_migrate_page_norefs()
buffer_migrate_lock_buffers()
checks bh refs
spin_unlock(&mapping->private_lock)
__find_get_block()
spin_lock(&mapping->private_lock)
grab bh ref
spin_unlock(&mapping->private_lock)
move page do bh work
This can result in various issues like lost updates to buffers (i.e.
metadata corruption) or use after free issues for the old page.
This patch closes the race by holding mapping->private_lock while the
mapping is being moved to a new page. Ordinarily, a reference can be
taken outside of the private_lock using the per-cpu BH LRU but the
references are checked and the LRU invalidated if necessary. The
private_lock is held once the references are known so the buffer lookup
slow path will spin on the private_lock. Between the page lock and
private_lock, it should be impossible for other references to be
acquired and updates to happen during the migration.
A user had reported data corruption issues on a distribution kernel with
a similar page migration implementation as mainline. The data
corruption could not be reproduced with this patch applied. A small
number of migration-intensive tests were run and no performance problems
were noted.
[mgorman@techsingularity.net: Changelog, removed tracing]
Link: http://lkml.kernel.org/r/20190718090238.GF24383@techsingularity.net
Fixes: 89cb0888ca "mm: migrate: provide buffer_migrate_page_norefs()"
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Mel Gorman <mgorman@techsingularity.net>
Cc: <stable@vger.kernel.org> [5.0+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Shakeel Butt reported premature oom on kernel with
"cgroup_disable=memory" since mem_cgroup_is_root() returns false even
though memcg is actually NULL. The drop_caches is also broken.
It is because commit aeed1d325d ("mm/vmscan.c: generalize
shrink_slab() calls in shrink_node()") removed the !memcg check before
!mem_cgroup_is_root(). And, surprisingly root memcg is allocated even
though memory cgroup is disabled by kernel boot parameter.
Add mem_cgroup_disabled() check to make reclaimer work as expected.
Link: http://lkml.kernel.org/r/1563385526-20805-1-git-send-email-yang.shi@linux.alibaba.com
Fixes: aeed1d325d ("mm/vmscan.c: generalize shrink_slab() calls in shrink_node()")
Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
Reported-by: Shakeel Butt <shakeelb@google.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Reviewed-by: Kirill Tkhai <ktkhai@virtuozzo.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Jan Hadrava <had@kam.mff.cuni.cz>
Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Roman Gushchin <guro@fb.com>
Cc: Hugh Dickins <hughd@google.com>
Cc: Qian Cai <cai@lca.pw>
Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Cc: <stable@vger.kernel.org> [4.19+]
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Fixes gcc '-Wunused-but-set-variable' warning:
fs/ocfs2/xattr.c: In function ocfs2_xattr_bucket_find:
fs/ocfs2/xattr.c:3828:6: warning: variable last_hash set but not used [-Wunused-but-set-variable]
It's never used and can be removed.
Link: http://lkml.kernel.org/r/20190716132110.34836-1-yuehaibing@huawei.com
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Acked-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <gechangwei@live.cn>
Cc: Gang He <ghe@suse.com>
Cc: Jun Piao <piaojun@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
When running ltp's oom test with kmemleak enabled, the below warning was
triggerred since kernel detects __GFP_NOFAIL & ~__GFP_DIRECT_RECLAIM is
passed in:
WARNING: CPU: 105 PID: 2138 at mm/page_alloc.c:4608 __alloc_pages_nodemask+0x1c31/0x1d50
Modules linked in: loop dax_pmem dax_pmem_core ip_tables x_tables xfs virtio_net net_failover virtio_blk failover ata_generic virtio_pci virtio_ring virtio libata
CPU: 105 PID: 2138 Comm: oom01 Not tainted 5.2.0-next-20190710+ #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
RIP: 0010:__alloc_pages_nodemask+0x1c31/0x1d50
...
kmemleak_alloc+0x4e/0xb0
kmem_cache_alloc+0x2a7/0x3e0
mempool_alloc_slab+0x2d/0x40
mempool_alloc+0x118/0x2b0
bio_alloc_bioset+0x19d/0x350
get_swap_bio+0x80/0x230
__swap_writepage+0x5ff/0xb20
The mempool_alloc_slab() clears __GFP_DIRECT_RECLAIM, however kmemleak
has __GFP_NOFAIL set all the time due to d9570ee3bd ("kmemleak:
allow to coexist with fault injection"). But, it doesn't make any sense
to have __GFP_NOFAIL and ~__GFP_DIRECT_RECLAIM specified at the same
time.
According to the discussion on the mailing list, the commit should be
reverted for short term solution. Catalin Marinas would follow up with
a better solution for longer term.
The failure rate of kmemleak metadata allocation may increase in some
circumstances, but this should be expected side effect.
Link: http://lkml.kernel.org/r/1563299431-111710-1-git-send-email-yang.shi@linux.alibaba.com
Fixes: d9570ee3bd ("kmemleak: allow to coexist with fault injection")
Signed-off-by: Yang Shi <yang.shi@linux.alibaba.com>
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Qian Cai <cai@lca.pw>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The kernel-doc parser doesn't handle expressions with %foo*. Instead,
when an asterisk should be part of a constant, it uses an alternative
notation: `foo*`.
Link: http://lkml.kernel.org/r/7f18c2e0b5e39e6b7eb55ddeb043b8b260b49f2d.1563361575.git.mchehab+samsung@kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
intel fixes (didn't have any ever since the main merge window pull):
- gvt fixes (2 cc: stable)
- fix gpu reset vs mm-shrinker vs wakeup fun (needed a few patches)
- two gem locking fixes (one cc: stable)
- pile of misc fixes all over with minor impact, 6 cc: stable, others
from this window
exynos:
- misc minor fixes
misc:
- some build/Kconfig fixes
- regression fix for vm scalability perf test which seems to mostly
exercise dmesg/console logging ...
- the vgem cache flush fix for arm64 broke the world on x86, so that's
reverted again
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEb4nG6jLu8Y5XI+PfTA9ye/CYqnEFAl1Eh6UACgkQTA9ye/CY
qnEr0xAAoCm/z3Y02494iuWfHTnSM3ILEILRoKur3ewaYg7u5qLppdFSCPN92EIC
M3ODjNLaYSIJWB+mT6II9tdPzARL2Uug5ItJBE0OtnJmexYIdkBDc7GlctfW3ENB
KFcW2i3MrA1lrNC69snzO0uWtchfkuXvFH0W8q6l+n5y8Yevcqs12XYZbYQYpV4Z
KHScTggWQ2owjKBTDDZ1zYtp+pkto/CUlL2ln6b32T27YtdJIc4vtqB0+sR5iThx
KCduQR897WOjueOIsy/qyhg45cC5Eci28HXTMoh/HVjG1igmAAPhapWH48Yrfkdu
bSbwbBAaA6OGv+7yWCESpl7Au2KCtQ26nDESOIP4KDl+Kl5uAgoiDTIyCVLI7b6p
gYH88LhL7UJKvvej7BtHrQy6BMZElznRWVtEESfCuyk8wn/cAxJNOxbdNIWIUjha
NDUTdyZOuY8C8xGDdLLFWX7mn/1lkVFxxTRlx2lgKJROAfjA+CsohgXeMTsStqdX
W4Mx/3Q8oBELcsUMGL/+N3vZGPIckk6trs0SteV6J3XaOduWClAQA9KV4JHb7JOq
tVC88MkxXK0bZAT9W6sSM5KOmZo6t7XiaP2QZAd5vWljaMPov489e40RK0ZFmKPW
xfhWBxNdaTeu7d0X+25oOUBmroUnnGSukOLJheGISwTBDAlkp7U=
=2TGW
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2019-08-02-1' of git://anongit.freedesktop.org/drm/drm
Pull more drm fixes from Daniel Vetter:
"Dave sends his pull, everyone realizes they've been asleep at the
wheel and hits send on their own pulls :-/
Normally I'd just ignore these all because w/e for me and Dave. But
this time around the latecomers also included drm-intel-fixes, which
failed to send out a -fixes pull thus far for this release (screwed up
vacation coverage, despite that 2/3 maintainers were around ... they
all look appropriately guilty), and that really is overdue to get
landed.
And since I had to do a pull request anyway I pulled the other two
late ones too.
intel fixes (didn't have any ever since the main merge window pull):
- gvt fixes (2 cc: stable)
- fix gpu reset vs mm-shrinker vs wakeup fun (needed a few patches)
- two gem locking fixes (one cc: stable)
- pile of misc fixes all over with minor impact, 6 cc: stable, others
from this window
exynos:
- misc minor fixes
misc:
- some build/Kconfig fixes
- regression fix for vm scalability perf test which seems to mostly
exercise dmesg/console logging ...
- the vgem cache flush fix for arm64 broke the world on x86, so
that's reverted again
* tag 'drm-fixes-2019-08-02-1' of git://anongit.freedesktop.org/drm/drm: (42 commits)
Revert "drm/vgem: fix cache synchronization on arm/arm64"
drm/exynos: fix missing decrement of retry counter
drm/exynos: add CONFIG_MMU dependency
drm/exynos: remove redundant assignment to pointer 'node'
drm/exynos: using dev_get_drvdata directly
drm/bochs: Use shadow buffer for bochs framebuffer console
drm/fb-helper: Instanciate shadow FB if configured in device's mode_config
drm/fb-helper: Map DRM client buffer only when required
drm/client: Support unmapping of DRM client buffers
drm/i915: Only recover active engines
drm/i915: Add a wakeref getter for iff the wakeref is already active
drm/i915: Lift intel_engines_resume() to callers
drm/vgem: fix cache synchronization on arm/arm64
drm/i810: Use CONFIG_PREEMPTION
drm/bridge: tc358764: Fix build error
drm/bridge: lvds-encoder: Fix build error while CONFIG_DRM_KMS_HELPER=m
drm/i915/gvt: Adding ppgtt to GVT GEM context after shadow pdps settled.
drm/i915/gvt: grab runtime pm first for forcewake use
drm/i915/gvt: fix incorrect cache entry for guest page mapping
drm/i915/gvt: Checking workload's gma earlier
...
-----BEGIN PGP SIGNATURE-----
iQJIBAABCAAyFiEES0KozwfymdVUl37v6iDy2pc3iXMFAl1DbfsUHHBhdWxAcGF1
bC1tb29yZS5jb20ACgkQ6iDy2pc3iXPB9A/+Kr17ng4Oygg0fIO+dW1KrHu64ZCm
TkLff1+9uNmWSu1NOsctJDQ5kSbBV7XgCT/wv8dT0TfA55D3CX11LtbhqVsIaASA
8iSq2FNgt91d8AIlw0X+5tXljswWLHTJw29ROY/SC2Eyhj5G2fT8eOwMtz59AmJv
rHlFt9VfAw7Faf4/egccmxS6fqE7p6gt4Prf77ZYSB8r9dlLDKqW8HT59UyE58MU
09mK1hqE40U6+wZVuU95ATqtQRMrn4pRgTOEgO9j7xUeLKC6z9cbVRAWtzAcWMRr
/bHuRm30ij83kHI18gYvXjMBr9Jierg+brW1s/sTV7KSXAyTYYXzUnQYgTHqbhJq
Do+dggZwCbze19IGfPafI8fjUoGU1tBuPkcy3+Ag8r4+2yB+z+fuN1PxP+AqWZZC
X1lQhtUlNfHNFmB/1XBTVzDaozKmKp56DiDjCmPvgcH5kWtc35ZTUuXk1YmYtB+a
O76haRE5386K0SzEAJ4SaPpHPyWzg1Qgi7EQlJy2x8uGc2R4QkXZrj/uGyOL90QJ
zjPNUPtqSAoLVzemA+PG7BZ/gcGVXuwrwHIPHprg/l/VVNl+4azW5b595pyHh5xL
0d8A0j/zz1E+A8vzqK9/G0nlLgYw6+yIuI42aT3qBhbxDJDRzvZH8w07W93F4+df
9+y0Fx+2HSsvbVA=
=pIeX
-----END PGP SIGNATURE-----
Merge tag 'selinux-pr-20190801' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux
Pull selinux fix from Paul Moore:
"One more small fix for a potential memory leak in an error path"
* tag 'selinux-pr-20190801' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux:
selinux: fix memory leak in policydb_init()
The hbmc-am654 driver is for the TI AM654, which is an ARM64 SoC, so
don't propose this driver on other architectures unless
build-testing.
Fixes: b07079f164 ("mtd: hyperbus: Add driver for TI's HyperBus memory controller")
Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
On x86_64, when CONFIG_OF is not disabled:
WARNING: unmet direct dependencies detected for MUX_MMIO
Depends on [n]: MULTIPLEXER [=y] && (OF [=n] || COMPILE_TEST [=n])
Selected by [y]:
- HBMC_AM654 [=y] && MTD [=y] && MTD_HYPERBUS [=y]
due to
config HBMC_AM654
tristate "HyperBus controller driver for AM65x SoC"
select MULTIPLEXER
select MUX_MMIO
Fix this by making HBMC_AM654 imply MUX_MMIO instead of select so
that dependencies are taken care of. MUX_MMIO is optional for
functioning of driver.
Fixes: b07079f164 ("mtd: hyperbus: Add driver for TI's HyperBus memory controller")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Some devices are not supposed to support on-die ECC but experience
shows that internal ECC machinery can actually be enabled through the
"SET FEATURE (EFh)" command, even if a read of the "READ ID Parameter
Tables" returns that it is not.
Currently, the driver checks the "READ ID Parameter" field directly
after having enabled the feature. If the check fails it returns
immediately but leaves the ECC on. When using buggy chips like
MT29F2G08ABAGA and MT29F2G08ABBGA, all future read/program cycles will
go through the on-die ECC, confusing the host controller which is
supposed to be the one handling correction.
To address this in a common way we need to turn off the on-die ECC
directly after reading the "READ ID Parameter" and before checking the
"ECC status".
Cc: stable@vger.kernel.org
Fixes: dbc44edbf8 ("mtd: rawnand: micron: Fix on-die ECC detection logic")
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRTLbB6QfY48x44uB6AXGG7T9hjvgUCXURMOQAKCRCAXGG7T9hj
vqZtAP94YCWvBsB6m3UUEzyOinIj9XaVd+K6ET4C6lLyZRsXBAD7BBMlUQQbuZcW
R1wjdC/oph4y52FgGZY+qE3wfRJhAw8=
=LAXD
-----END PGP SIGNATURE-----
Merge tag 'for-linus-5.3a-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip
Pull xen fixes from Juergen Gross:
- a small cleanup
- a fix for a build error on ARM with some configs
- a fix of a patch for the Xen gntdev driver
- three patches for fixing a potential problem in the swiotlb-xen
driver which Konrad was fine with me carrying them through the Xen
tree
* tag 'for-linus-5.3a-rc3-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
xen/swiotlb: remember having called xen_create_contiguous_region()
xen/swiotlb: simplify range_straddles_page_boundary()
xen/swiotlb: fix condition for calling xen_destroy_contiguous_region()
xen: avoid link error on ARM
xen/gntdev.c: Replace vm_map_pages() with vm_map_pages_zero()
xen/pciback: remove set but not used variable 'old_state'
- Update the compat layer to allow single-byte watchpoints on all
addresses (similar to the native support)
- arm_pmu: fix the restoration of the counters on the
CPU_PM_ENTER_FAILED path
- Fix build regression with vDSO and Makefile not stripping
CROSS_COMPILE_COMPAT
- Fix the CTR_EL0 (cache type register) sanitisation on heterogeneous
machines (e.g. big.LITTLE)
- Fix the interrupt controller priority mask value when pseudo-NMIs are
enabled
- arm64 kprobes fixes: recovering of the PSTATE.D flag in the
single-step exception handler, NOKPROBE annotations for unwind_frame()
and walk_stackframe(), remove unneeded rcu_read_lock/unlock from debug
handlers
- Several gcc fall-through warnings
- Unused variable warnings
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE5RElWfyWxS+3PLO2a9axLQDIXvEFAl1Eb40ACgkQa9axLQDI
XvECLA/+MKOdD1q+0IkMabCj2aCeteVhwaR2mn/EAjIoIUX0Kh9CUJK2HUO9f2zS
zP86XkQ9dvJaXAm62l0dSWuxmkAZ9Mocrj0S6syTynkxz6Vugo5teSVZMbNygVLd
rekzUUQ2lufTgRlwNS+I1l7Ku5/D3ySvI6UYYOG3456pNATD9hd+28mySaXxadkX
AZt09xoIernBg1VPZ61WJZ7f9eBpco5pvJVY0xwm1V0HolfDkksfiqbjKzEWig0s
zgS8rdFfI9+YWsWnHxdOf/0TzpIlIxRli4r49u4mKyVJWINDaqpIRzvrxMfn8wzY
HDzAOfY8QfZeXig4ifbjBZixMRO/2zWAhiqnvPgNZXw21XbN2vCmqJJJTdJh/Xy3
9sT4Yb20xuXAqaJ8j0jeVqCk1vKiijp6MW2Y+HqWH0ChYuzLuNSOEphAj5JXxnI5
ZygsyXOQ1roJ0K5P46y3P0G4P953RZKjgBezfk9dMimtjK6CDqGaxhKxhONuQ/g6
MH3m2MqjkXM4+4qjE+6+Xwuvn8THLZTaTXOv54cX5Y7u3vAZhwL5vMTabgTr1mjo
Mf8yguEp10KQ9e2Fn9A9dLNYFf1mA1V95kv8cLxD0iMf7LpTwW/2db67/q/WjIMn
e3PtaiZt6n+lnSsuGtSVJ3mmV6wfrioAhFbRAf5U3xaYOd2AfGQ=
=vA+f
-----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 compat layer to allow single-byte watchpoints on all
addresses (similar to the native support)
- arm_pmu: fix the restoration of the counters on the
CPU_PM_ENTER_FAILED path
- Fix build regression with vDSO and Makefile not stripping
CROSS_COMPILE_COMPAT
- Fix the CTR_EL0 (cache type register) sanitisation on heterogeneous
machines (e.g. big.LITTLE)
- Fix the interrupt controller priority mask value when pseudo-NMIs are
enabled
- arm64 kprobes fixes: recovering of the PSTATE.D flag in the
single-step exception handler, NOKPROBE annotations for
unwind_frame() and walk_stackframe(), remove unneeded
rcu_read_lock/unlock from debug handlers
- Several gcc fall-through warnings
- Unused variable warnings
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: Make debug exception handlers visible from RCU
arm64: kprobes: Recover pstate.D in single-step exception handler
arm64/mm: fix variable 'tag' set but not used
arm64/mm: fix variable 'pud' set but not used
arm64: Remove unneeded rcu_read_lock from debug handlers
arm64: unwind: Prohibit probing on return_address()
arm64: Lower priority mask for GIC_PRIO_IRQON
arm64/efi: fix variable 'si' set but not used
arm64: cpufeature: Fix feature comparison for CTR_EL0.{CWG,ERG}
arm64: vdso: Fix Makefile regression
arm64: module: Mark expected switch fall-through
arm64: smp: Mark expected switch fall-through
arm64: hw_breakpoint: Fix warnings about implicit fallthrough
drivers/perf: arm_pmu: Fix failure path in PM notifier
arm64: compat: Allow single-byte watchpoints on all addresses
Pull parisc fixes from Helge Deller:
"A few small fixes for the parisc architecture:
- Fix fall-through warnings in parisc math emu code
- Fix vmlinuz linking failure with debug-enabled kernels
- Fix a race condition in kernel live-patching code
- Add missing archclean Makefile target & defconfig adjustments"
* 'parisc-5.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Add archclean Makefile target
parisc: Strip debug info from kernel before creating compressed vmlinuz
parisc: Fix build of compressed kernel even with debug enabled
parisc: fix race condition in patching code
parisc: rename default_defconfig to defconfig
parisc: Fix fall-through warnings in fpudispatch.c
parisc: Mark expected switch fall-throughs in fault.c
Seven fixes to four drivers with no core changes. The mpt3sas one is
theoretical until we get a CPU that goes up to 64 bits physical, the
qla2xxx one fixes an oops in a driver initialization error leg and the
others are mostly cosmetic.
Signed-off-by: James E.J. Bottomley <jejb@linux.ibm.com>
-----BEGIN PGP SIGNATURE-----
iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCXURSriYcamFtZXMuYm90
dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishWpKAQCbTaKz
AWOXWaMUoL26nZ036slYx9KjxcXS/MFuDXCAnQEA5ww+AfKurovX62i3B7YqVDxm
j0TBq+LvzUUNcrA+JU8=
=NfZ0
-----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:
"Seven fixes to four drivers with no core changes.
The mpt3sas one is theoretical until we get a CPU that goes up to 64
bits physical, the qla2xxx one fixes an oops in a driver
initialization error leg and the others are mostly cosmetic"
[ The fcoe patches may be worth highlighting - they may be "just"
cleanups, but they simplify and fix the odd fc_rport_priv structure
handling rules so that the new gcc-9 warnings about memset crossing
structure boundaries are gone.
The old code was hard for humans to understand too, and really
confused the compiler sanity checks - Linus ]
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: qla2xxx: Fix possible fcport null-pointer dereferences
scsi: mpt3sas: Use 63-bit DMA addressing on SAS35 HBA
scsi: hpsa: remove printing internal cdb on tag collision
scsi: hpsa: correct scsi command status issue after reset
scsi: fcoe: pass in fcoe_rport structure instead of fc_rport_priv
scsi: fcoe: Embed fc_rport_priv in fcoe_rport structure
scsi: libfc: Whitespace cleanup in libfc.h
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAl1ERCMQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpjr7D/0U8SMu1T9JOge91zXQQUc7XtCX9RvHYhhj
vbwwN9RwpIfrTwuLZUCvt2vEz8WPOVfZbwYGkfFcdI+N5I/dOfT8Swiwy7Zabpi2
KTedn2EdELTizEuWQ3QhaBHWuTGvE04aAzZTBRCQ0tCOYTPpXGRavxhG6UHcQi+z
lohB5Pr/cyX8/jWJj4kq7381QYUUH2bm9uY7qutBsQOt2CsN5prjWxX3JM6EO1wb
VyyI25fWLaS+bZW+crVutcARxccuav4e+LEJbb9Z7+19vjmkc2qE+22F3MBxYCzo
tOjU0RP0IvvVR9t0Hahw/3MnDTDfuSqlqrT12zNtn7FrzOKpkygMyRa+u8YygI6k
2iAp92HkNWpjBxUFNGoRCRfJpApG3vT6/VkI8tixFSw/Re3F1H9Bc9IRZxc3uU4H
5DMRmjZXGg+8Nw+93XzwWnD1paCJcDsHRHUpWFNJvRfJYQzDaziPUBV9a9TZ+HMF
BnCJBCW641tcA5yCRwBF6OpoowtmxOtWce7Lr9wAjU+cYHMEzOQoG+J6gPH3q8Jh
aD9U2FcnE6kReL+MsGj42q1U1n60xngcdzo8Ca4bWfWNpqb4lJatjumkDAiI6U4q
DFDs9bRbB4LLgwkRQ+n1biwAK626KJOp5lGXrEu7XHXSTlO/BiJytISwASjlzKsZ
4uGHc/uUdA==
=P5E/
-----END PGP SIGNATURE-----
Merge tag 'for-linus-20190802' of git://git.kernel.dk/linux-block
Pull block fixes from Jens Axboe:
"Here's a small collection of fixes that should go into this series.
This contains:
- io_uring potential use-after-free fix (Jackie)
- loop regression fix (Jan)
- O_DIRECT fragmented bio regression fix (Damien)
- Mark Denis as the new floppy maintainer (Denis)
- ataflop switch fall-through annotation (Gustavo)
- libata zpodd overflow fix (Kees)
- libata ahci deferred probe fix (Miquel)
- nbd invalidation BUG_ON() fix (Munehisa)
- dasd endless loop fix (Stefan)"
* tag 'for-linus-20190802' of git://git.kernel.dk/linux-block:
s390/dasd: fix endless loop after read unit address configuration
block: Fix __blkdev_direct_IO() for bio fragments
MAINTAINERS: floppy: take over maintainership
nbd: replace kill_bdev() with __invalidate_device() again
ata: libahci: do not complain in case of deferred probe
io_uring: fix KASAN use after free in io_sq_wq_submit_work
loop: Fix mount(2) failure due to race with LOOP_SET_FD
libata: zpodd: Fix small read overflow in zpodd_get_mech_type()
ataflop: Mark expected switch fall-through
changes from commit in 5.3 merge.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCAAxFiEEJfWUX4UqZ4x1O2wixSPxCi2dA1oFAl1EUvUTHHNuaXR6ZXJA
cmVkaGF0LmNvbQAKCRDFI/EKLZ0DWgj9B/0QQL8kB5DybBkADKAkmTw4pTtEqGSy
LebPIGl45RHHgLcXB1J1cSGs6uA6AuNnn9XoFY7juEJthGp0IR+NgxKiq5r4UW2Q
/k72a82D8T/FlBGet+5w44mKMARXiq5opdMS8iFezcd0c15IeNbbSmKZHluRppQX
KsCKJ1FsZobXlUUMSeJFIS5eJNMaSg1isotcT8P6kWXsaNYziGul2Akjhxw8a2qZ
kN6ATBKcvT4EOy/tDMFQhbFU6t5ydEH3buOZ1h8slCOSuzSzXuz56ff42dFYV8QK
WzldzZ7PSSHqKn7SAKwRs4g/iEMotPk1ChsMSvDBVGs3VG3yACV0OCdB
=KJ3q
-----END PGP SIGNATURE-----
Merge tag 'for-5.3/dm-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mike Snitzer:
"Fix NULL pointer and various whitespace issues with DM's recent DAX
code changes from commit in 5.3 merge"
* tag 'for-5.3/dm-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm table: fix various whitespace issues with recent DAX code
dm table: fix dax_dev NULL dereference in device_synchronous()
- A couple Spectre V1 fixes (umad, hfi1)
- Fix a tricky deadlock in the rdma core code with refcounting instead
of locks (client removal patches)
- Build errors (hns)
- Fix a scheduling while atomic issue (mlx5)
- Use after free fix (mad)
- Fix error path return code (hns)
- Null deref fix (siw_crypto_hash)
- A few other misc. minor fixes
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEErmsb2hIrI7QmWxJ0uCajMw5XL90FAl1ESa0ACgkQuCajMw5X
L91Beg//RqM0d05EmAqR0G3taQfzXZezE81CHk+92WxsZPN9SYdLeeJH0RXJNVsC
BrWrzR/g4s8e+cCdXeEU0fr0oxd4pzsxya3WjQmZ+ZgUoYyesbz4wvnzX8JVBuV6
fZ1AvXTviAYQvMA6RAddyuH+g951LAvNNvrZpfFUoD6AGEm8s/F9xHBUl2hR5hE/
W6LQvO65rzXKEkHC6r91qUNS1CIEUyhrlFe3Qs3jI8cqLzfUEUb5hAyUd/Oe+kRa
UiocfazisQzJX2NJWUFSWy0C+H7m38q6WNKrfoBLfyBpBj+Q2MOqoA8ghq095qj3
8DoWgD2tgdq3+ttYBEvNn21ZkOKBk0MLJDKVt34YLR8p+M4k1yP3f1V5TVIfnhdz
Y6Iv++JhpB9tMJXIucCXdmVyLOjwid8b8UMcyZE91y8u8nucTt/JWlPjob+D9aA9
gHQMZmaQvBSCGgorpWRfyTH04Sey2WOkQKWZQWSeEMvRX6wS5wab/RB5c13EHKF2
0B2+V2WsR8Mrj4fG7XSsBOGvIcBssSppnFSW1OaR98rspZcU4ykjRgBO0T9PXzce
kzCTCa9Zl48fEMYR1P50YJyVFu3X8RTOKv/cs5s/XoDLsvSU76+NhHQSlMV5XU12
lfXd2vDeUJX2cVlT+YAAwg+a0+tVskySww7vZmOpuYVvj/8z3mw=
=CfX3
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma fixes from Doug Ledford:
"Here's our second -rc pull request. Nothing particularly special in
this one. The client removal deadlock fix is kindy tricky, but we had
multiple eyes on it and no one could find a fault in it. A couple
Spectre V1 fixes too. Otherwise, all just normal -rc fodder:
- A couple Spectre V1 fixes (umad, hfi1)
- Fix a tricky deadlock in the rdma core code with refcounting
instead of locks (client removal patches)
- Build errors (hns)
- Fix a scheduling while atomic issue (mlx5)
- Use after free fix (mad)
- Fix error path return code (hns)
- Null deref fix (siw_crypto_hash)
- A few other misc. minor fixes"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma:
RDMA/hns: Fix error return code in hns_roce_v1_rsv_lp_qp()
RDMA/mlx5: Release locks during notifier unregister
IB/hfi1: Fix Spectre v1 vulnerability
IB/mad: Fix use-after-free in ib mad completion handling
RDMA/restrack: Track driver QP types in resource tracker
IB/mlx5: Fix MR registration flow to use UMR properly
RDMA/devices: Remove the lock around remove_client_context
RDMA/devices: Do not deadlock during client removal
IB/core: Add mitigation for Spectre V1
Do not dereference 'siw_crypto_shash' before checking
RDMA/qedr: Fix the hca_type and hca_rev returned in device attributes
RDMA/hns: Fix build error
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE8rQSAMVO+zA4DBdWxWXV+ddtWDsFAl1ETYkACgkQxWXV+ddt
WDupLA/+LXPJvxRG/Ob655sxOAqpG4+XUW7aaI5jSnlr958TtDlNFkpzrQ28NFzk
XlEe/HjgI6CH7DhNwe1IlHLqFt874fiCeIZ2jvuSVVbPAO+9T8a5BIbeUY6V4h5v
QUmbaUpVshsh2IDArU8Vc/UjycCuwrccfGkS5ydTVI6Eni4BWsOY2PMiB5ojdOTE
bpclws3ca/CMbNpGKnn3cH5aXJpENTXedXxBbp99DproZVY3YL1ZyDxc37R6+5Ua
kbZznSMZFoLjHt3vktHmiozF7W1Zdi6ExOp9NHApshlw/n08ICkY1oNfd9KSYgQs
8gTl9mZ8jbJnSfZTuHNL6LwfSZjDyT5LCTbXSj0UnaVOYwJVwopsDrrdO6AESd8S
1eFeEFQ62lEV+31xa0nsYBz5j6ejEfcvxiq14W8LawWpkxtAIsEyXockWtmXPods
29BYkstQADlCOu2WYdQ8ugseBtfEpEAvD+Rf+qqyZ6XlHMIjL1J1S+BIXQ868z1f
KZCVsepJ0dVm0siVNMFBUaM2z1PcHusxNgYd37YcJRX2t4Gql9Ku/00PJ+tRhsBa
80a5ue9p6nuZfR6XoM6Cpe3uG8qyFyPccC3ohwKEOAnHnmk2LEJYASudV4pk/P8G
Vy3o9Uv/NMMznop24r7UB3mklBQCIchKpaij3RT0Jx+3RGdR4Yo=
=jr4T
-----END PGP SIGNATURE-----
Merge tag 'for-5.3-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
- tiny race window during 2 transactions aborting at the same time can
accidentally lead to a commit
- regression fix, possible deadlock during fiemap
- fix for an old bug when incremental send can fail on a file that has
been deduplicated in a special way
* tag 'for-5.3-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
Btrfs: fix deadlock between fiemap and transaction commits
Btrfs: fix race leading to fs corruption after transaction abort
Btrfs: fix incremental send failure after deduplication
- A further fix for syzcaller issues with USB-audio, addressing
NULL dereference that was introduced by the recent fix
- Avoid a long delay at boot with HD-audio when i915 module was
built but not installed, found on some Debian systems
- A fix of small race window at PCM draining
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl1EAPUOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE/UKw/+J7YWMbLMDUNlmCFBi2MStSc898LB3UsB+W+O
VGsluaiv9ZkyVmu/v6D4HqLDNCzNsqpg1NSNIDOAM/RBdsOjR1PYO0LZWED1hQet
frYiaIEx9xOKV8b1Q4X0soQY7OztXTOWvB5qzhl+HhAijhPaoMcjP0g6kqQiIRwQ
CxMljNAmE9pikFCqrmzi1XdaMr73tllfaAfUfNqvSoBTh++t3y3xt0OTEshsvidS
Df/3/rF+apRavyFoyGdXGNZsP16T1crWN1g2Ln/i2kCyCLU/YsVj290fnS3WJAzH
gMwridTLUaGF8gTbvwIdyKXejnK2gUqz6Kp/2m6v1DGQZxhdFzTbc1TMurqqc54K
1vAul0lFFrc9AIsTnBucTpUbI4enMcwXlrUBCU57NezjK60cMd6NWLv1wJIkD1el
WxDliDrHPuhgf6w6FiT3Ul+YirvcNm/zJKQSs/yDoj6GfjETgIoXQgoAP4HQK/XG
DrfQRvujFzv4tMiP7aaSCGe0zoGR09SwJdQyYTtxkD58GKtBFkX1/jiM682eAfSB
cIw44yKXto+P/g8BQYi+TgdTMBV/JKX2Oa0B2nhhOl1rHe6T2fKkKAqSN/J7EcYg
/Hx6NQglSos2+r9pk3nofvdBC9nT9KQgqDOGzKuBvPeY7cCbv5BsZlBkKJ46bplt
7IwtXho=
=IaLJ
-----END PGP SIGNATURE-----
Merge tag 'sound-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
- A further fix for syzcaller issues with USB-audio, addressing NULL
dereference that was introduced by the recent fix
- Avoid a long delay at boot with HD-audio when i915 module was built
but not installed, found on some Debian systems
- A fix of small race window at PCM draining
* tag 'sound-5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: usb-audio: Fix gpf in snd_usb_pipe_sanity_check
ALSA: pcm: fix lost wakeup event scenarios in snd_pcm_drain
ALSA: hda: Fix 1-minute detection delay when i915 module is not available
amdgpu:
navi10 temperature and pstate fixes
vcn dynamic power management fix
CS ioctl error handling fix
debugfs info leak fix
amdkfd VegaM fix.
msm:
dma sync call fix
mdp5 dsi command mode fix
fall-through fixes
disabled GPU fix
nouveau:
regression fix for displayport MST support.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJdQ5SQAAoJEAx081l5xIa+m4gP/jaCuo50oIAoTcKGWi6JM4FB
6dg3peqNSLx+pGnNHOXx3hYUyf2KfUZ2CtTYvab4xFjES//rJOy+HwrtbjVvW0AG
RfFDVHB2Vsz5e23TxVJBkodJwudsuVCUsINHGDg3o9GYOnZDe8bO7aiEiZ7xbFYA
29DOCXuLx8JvN3Gm/HKVrasIY7T3mm84/L1Yo72OhExSipyfGImBsxZ5gW1K7GzO
XL+I8W2h9ViBEsy7DfRGAqn5SwSl81JePf1X73Fl3ZEzMB9drtt/+BsJc2eAfacP
aG3vQL8i1EdzGGMqLZTy0csfr76Bp8hnZIhKdmyYVq2zTGd+J5SCQWlaJ/ov0vTj
dzPMfbLysVzQzxOdQNAkokyM1N+r2QicjR1W8jki/BCGoZhrhoMH3JA9qgxnLVw9
ggem6rMSb5yXnp4JxCOBWZzROON06hdaiGBHAeXqq+mU9DFj/xTqlloUE3Ln/ncs
2HVFxsN6+tNN5vEFzKPPJYk+OpW8+r5UfWJmcpaDfMiuzBWyuqOkw2+DFrfdrQDp
ubDC7O0ZBlhfEcUjHVYbFJc5lv7ip21DxHGEUnDdPdePi+/UKOq6ySDM2yE+rshL
Sg05Ifu17uUGwd2gtDKaIcX9RMxwc8TdSt3CRhAVl2JrCLFsbQwhntWthIHlndmn
OkzCKmsylr2lX19GEh5J
=jOZ/
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm
Pull drm fixes from Dave Airlie:
"Thanks to Daniel for handling the email the last couple of weeks, flus
and break-ins combined to derail me. Surprised nothing materialised
today to take me out again.
Just more amdgpu navi fixes, msm fixes and a single nouveau regression
fix:
amdgpu:
- navi10 temperature and pstate fixes
- vcn dynamic power management fix
- CS ioctl error handling fix
- debugfs info leak fix
- amdkfd VegaM fix
msm:
- dma sync call fix
- mdp5 dsi command mode fix
- fall-through fixes
- disabled GPU fix
nouveau:
- regression fix for displayport MST support"
* tag 'drm-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm:
drm/nouveau: Only release VCPI slots on mode changes
drm: msm: Fix add_gpu_components
drm/msm: Annotate intentional switch statement fall throughs
drm/msm: add support for per-CRTC max_vblank_count on mdp5
drm/msm: Use the correct dma_sync calls in msm_gem
drm/amd/powerplay: correct UVD/VCE/VCN power status retrieval
drm/amd/powerplay: correct Navi10 VCN powergate control (v2)
drm/amd/powerplay: support VCN powergate status retrieval for SW SMU
drm/amd/powerplay: support VCN powergate status retrieval on Raven
drm/amd/powerplay: add new sensor type for VCN powergate status
drm/amdgpu: fix a potential information leaking bug
drm/amdgpu: fix error handling in amdgpu_cs_process_fence_dep
drm/amd/powerplay: enable SW SMU reset functionality
drm/amd/powerplay: fix null pointer dereference around dpm state relates
drm/amdgpu/powerplay: use proper revision id for navi
drm/amd/powerplay: fix temperature granularity error in smu11
drm/amd/powerplay: add callback function of get_thermal_temperature_range
drm/amdkfd: Fix byte align on VegaM
that started getting exercised differently this time around:
- Select regmap MMIO kconfig in spreadtrum driver to avoid compile
errors
- Complete kerneldoc on devm_clk_bulk_get_optional()
- Register an essential clk earlier on mediatek mt8183 SoCs so
the clocksource driver can use it
- Fix divisor math in the at91 driver
- Plug a race in Renesas reset control logic
-----BEGIN PGP SIGNATURE-----
iQJFBAABCAAvFiEE9L57QeeUxqYDyoaDrQKIl8bklSUFAl1DH5oRHHNib3lkQGtl
cm5lbC5vcmcACgkQrQKIl8bklSXEiRAAlKgH3gBvg9gtwRuK11qeW/yJYA9/rdF6
nRxMQDq3AA/BktyHpnfDBOHbHs7zmwaeg/bk0x/Ex4+mgdCRe8+X9PJxlgSovenY
8Ky0CAijGxY2Mud/R0YPR2+QVCLYON8cp9SryrWpfokZP4bMqZOKUE6vs2NbeYCa
0iDneX9UUQhvGejEnhgKiuGtiRWPux3htxNlGaHkk/I/z1CvvsfGnxfbAPWN6ppl
txiZDLvtYjGx4tHVWg+olXhyQAMg3JADS1MOx3AcDv7OO5UnfLzdLMp/NLVwqdor
ZmbE2yTdzplGtuoh7waE7Mel6bm/gd94XHsX5S0gJU+ock2wWYoCMMkRGskSJFg3
/Dn7ajNS0Z4xMmdyz+O3kBMB4zu8kiedT07nkwXm+bsFzGK4UEzY6Gn09JP9+m2P
qSzxVLoO5Kg1M4yDIauOX6IyOC0VNgpftdZ4SGoCVqUrH3BYI804I6unbLOF5nad
u4mL0v8Bfz/OuJxuvaFpWCYoowHMi7NOz9ipQRB2bS/QYCB9H6rjv8tT4xAw81w6
P6DI0eG+QCjfHCEbe8W/KikLWSL52fnycwAAospkV+1AFFZ2735oJgb9KY4xY6Qd
tMRLsVjOTnq3mu/PlHuilnyaNtH7OHxp47HoBdgg8kc8VEIsfY+Z7SsPMms228/u
KBzPg709SIk=
=tNyv
-----END PGP SIGNATURE-----
Merge tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux
Pull clk fixes from Stephen Boyd:
"A few fixes for code that came in during the merge window or that
started getting exercised differently this time around:
- Select regmap MMIO kconfig in spreadtrum driver to avoid compile
errors
- Complete kerneldoc on devm_clk_bulk_get_optional()
- Register an essential clk earlier on mediatek mt8183 SoCs so the
clocksource driver can use it
- Fix divisor math in the at91 driver
- Plug a race in Renesas reset control logic"
* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
clk: renesas: cpg-mssr: Fix reset control race condition
clk: sprd: Select REGMAP_MMIO to avoid compile errors
clk: mediatek: mt8183: Register 13MHz clock earlier for clocksource
clk: Add missing documentation of devm_clk_bulk_get_optional() argument
clk: at91: generated: Truncate divisor to GENERATED_MAX_DIV + 1
This fixes a cascade of regressions that originally started with
the addition of the ia64 port, but only got fatal once we removed
most uses of block layer bounce buffering in Linux 4.18.
The reason is that while the original i386/PAE code that was the first
architecture that supported > 4GB of memory without an iommu decided to
leave bounce buffering to the subsystems, which in those days just mean
block and networking as no one else consumer arbitrary userspace memory.
Later with ia64, x86_64 and other ports we assumed that either an iommu
or something that fakes it up ("software IOTLB" in beautiful Intel
speak) is present and that subsystems can rely on that for dealing with
addressing limitations in devices. Except that the ARM LPAE scheme
that added larger physical address to 32-bit ARM did not follow that
scheme and thus only worked by chance and only for block and networking
I/O directly to highmem.
Long story, short fix - add swiotlb support to arm when build for LPAE
platforms, which actuallys turns out to be pretty trivial with the
modern dma-direct / swiotlb code to fix the Linux 4.18-ish regression.
-----BEGIN PGP SIGNATURE-----
iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAl1DFj8LHGhjaEBsc3Qu
ZGUACgkQD55TZVIEUYPFqg/+Oh62VCFCkIK07NAeTq6EmrfHI8I1Wm/SFWPOOB+a
vm7nMcSG3C8K8PRHzGc6Zk3SC1+RrHghcyKw54yLT1Mhroakv6Um7p2y8S3M4tmZ
uEg8yYbtzxvuaY9T42s2msZURbBCEELzA2bYbQzgQ1zczRI1zuMI07ssMr91IQ91
HC1OjAUoxUkp/+2uU/X2k6DvPQLSJSyWvKgbi1bjNpE+FRCKJP+2a2K3psBQuDBe
aJXiz/kD2L/JNvF/e4c414d5GnGXwtIYs1kbskmnj3LeToS+JjX+6ZcENorpScIP
c20s/3H6nsb14TFy548rJUlAHdcd9kOdeTw+0oPUliNLCogGs6FKNU4N5gVAo+bC
AWDP0wMHMWkrVz6lQL9PR78IHrHOxFYS5/uHsqqdKo5YTsgaHnwKEiPxX1aiKQ67
ovUrOnGRo4R9Y4YwD+BbHY9qw9jFMqazBdLWMivK5NxqltsahOug8w2emTFfXzQn
m4APJYa0RVJA4mkh3ejcci5qHyyzPOjslyIJn7eaJPV2rknkxRn9UngkgJLnzHfc
+lKiD1zaRy82nV4auPjYRiOdAoQN40YFB/RT16OVkjkT+jJEE2UAMjqh2SRlRusp
Ce8vK7pw6VpDNGJRQveQA+1n9OR/jl0Jf8R7GFRrf9c/bM1J8GErJ6xS/EwNPrgI
5dE=
=D6Uy
-----END PGP SIGNATURE-----
Merge tag 'arm-swiotlb-5.3' of git://git.infradead.org/users/hch/dma-mapping
Pull arm swiotlb support from Christoph Hellwig:
"This fixes a cascade of regressions that originally started with the
addition of the ia64 port, but only got fatal once we removed most
uses of block layer bounce buffering in Linux 4.18.
The reason is that while the original i386/PAE code that was the first
architecture that supported > 4GB of memory without an iommu decided
to leave bounce buffering to the subsystems, which in those days just
mean block and networking as no one else consumed arbitrary userspace
memory.
Later with ia64, x86_64 and other ports we assumed that either an
iommu or something that fakes it up ("software IOTLB" in beautiful
Intel speak) is present and that subsystems can rely on that for
dealing with addressing limitations in devices. Except that the ARM
LPAE scheme that added larger physical address to 32-bit ARM did not
follow that scheme and thus only worked by chance and only for block
and networking I/O directly to highmem.
Long story, short fix - add swiotlb support to arm when build for LPAE
platforms, which actuallys turns out to be pretty trivial with the
modern dma-direct / swiotlb code to fix the Linux 4.18-ish regression"
* tag 'arm-swiotlb-5.3' of git://git.infradead.org/users/hch/dma-mapping:
arm: use swiotlb for bounce buffering on LPAE configs
dma-mapping: check pfn validity in dma_common_{mmap,get_sgtable}
- fix alignment issues introduced in the CMA allocation rework
(Nicolin Chen)
-----BEGIN PGP SIGNATURE-----
iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAl1DE+YLHGhjaEBsc3Qu
ZGUACgkQD55TZVIEUYOrkA//Y7YxsJ9MaI0DNu9gYbYHg9u4ORBWXJ4fN67g2AUe
rdrHdEHyd4uYduy4Ggi65oknfMZms6xYHGaFr1iDforBmOk0CXfvovocHzJkcV/R
gtHSkp0L+SVmsLrWFXjd7pbkVhBziLEVrFlw07FbtBlNIeS2VvcAnU+CUcTKpxNi
7MHhCqxTjVuUZ/qRKyyAnKHGoLCdLqTvpaf1uJq9ca838I/9E5UqitaxL/72G7ab
q/fe93d94Xj3QNk+ekim6xBSD82VPU+OnFUf+f5dELDwyhgI0LAtz6iL8gH+NnK1
P9cIIs2sFyBLXRQEaRXF5KhA97sjlWLioXYWs/AxvCphDeb1Zk4u3uGn0bGt90fQ
g8DryY++nVo6sKpFsaNN7RQ9w/LfxejIcf0hVbNfH6tP8KDO19ds/05kE4O2LUC2
gLOmPMt+dIOJlBQY0fUNrZN/IH6u60LnULmCWDiy7iY7VBJOf+H3zXM0UAJ+XEbs
l2OG5vxkQ4hnFZVD1csNRd9gKYyjhrqOA0VssopgdBS53/seYMNopSbQsMTdp8J7
V3c7Rozz3f62pwxJ7Jd7AwCgpvw8zHOESb5WOzi5DEmxAqRaJQ80H2DdAvQc3orL
x0SummHKX2mY0cJdrFFbXkGoYt3sjJ+J6P+0CP11UIEIqtw4Zfa2hyWmbs8Q9SFt
KYg=
=rM5q
-----END PGP SIGNATURE-----
Merge tag 'dma-mapping-5.3-3' of git://git.infradead.org/users/hch/dma-mapping
Pull dma-mapping regression fixes from Christoph Hellwig:
"Two related regression fixes for changes from this merge window to fix
alignment issues introduced in the CMA allocation rework (Nicolin
Chen)"
* tag 'dma-mapping-5.3-3' of git://git.infradead.org/users/hch/dma-mapping:
dma-contiguous: page-align the size in dma_free_contiguous()
dma-contiguous: do not overwrite align in dma_alloc_contiguous()
. use dev_get_drvdata for readability instead of platform_get_drvdata
. remove redundant assignment to node.
- Two fixup patches
. fix undefined reference to 'vmf_insert_mixed' with NOMMU configuration.
. fix potential infinite spin issue by decrementing 'retry' variable in
scaler_reset function of exynos_drm_scaler.c
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJdQ/OtAAoJEFc4NIkMQxK48yQQAIrLBIN88jL0A+gfWjqjGOfO
W66zBigAmKsxz6lT0NTYHyarqrXe3WsdEuAhggUKkilbsRsj6w6DZVnmwlmI7Kly
yfz+WJKZK4X/02hz2smqXiQeYW+a17TsCtnpIOZLJKMIJ/Q3zFNNpVNKl1wQQhmK
KsL7QL9GOQXW3UdqjfGNPdT4e4BHIK0yO4xcaYEzBYg6H7dN9bIeYEiD97FlSiez
DnQGIE6mH0Frii2n+DEPo+LknTUfqOZBAig1SL5JZs8dxhJ7Bl7T2TN3BiMS5MiK
X/A+zn6bKJjhKCiUrzWoNHJMXtvtfOJxCpQKo042Ed4bHOvRV4hRBYIuZBLqsUI1
uYrgSgZoytKY3uyJWXckxmtwOJQDxJJmEbXtifpbwanyHTaExfINTB6IVFgxTQwc
oJ6obP2FeYIn7ehV+0P64eg7RxJYqVUTLirbEwdIs/o6/2yqo+/KcpCx3W294aP4
oyvDVvYPA5vf+4QyNznvK+gRdg79ojXPe4gogFOrFVYSCmhTIOUxT/d/X7PD9OJD
4VwgD2J3vOjG134J7XylyfQLyuYcmYXL5DPf08dY3+tefazOTpDh7tdF2PdHBMny
imBACcjcOWoQnyw77mjFOhoyuhlthzfgnwpEl+sAyDBuypF+6RGHz7/282gvO8iN
XwN/MnasUbowy6RhPpwe
=Qqyg
-----END PGP SIGNATURE-----
Merge tag 'exynos-drm-fixes-for-v5.3-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes
- Two cleanup patches
. use dev_get_drvdata for readability instead of platform_get_drvdata
. remove redundant assignment to node.
- Two fixup patches
. fix undefined reference to 'vmf_insert_mixed' with NOMMU configuration.
. fix potential infinite spin issue by decrementing 'retry' variable in
scaler_reset function of exynos_drm_scaler.c
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Inki Dae <inki.dae@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1564734791-745-1-git-send-email-inki.dae@samsung.com
commit 7e9e5ead55 ("drm/vgem: fix cache synchronization on arm/arm64")
broke all of the !llc i915-vgem coherency tests in CI, and left the HW
very, very unhappy (which is even more scary).
Fixes: 7e9e5ead55 ("drm/vgem: fix cache synchronization on arm/arm64")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Rob Clark <robdclark@chromium.org>
Cc: Sean Paul <seanpaul@chromium.org>
Acked-by: Sean Paul <sean@poorly.run>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20190801124458.24949-1-chris@chris-wilson.co.uk
- Fix some build errors in drm/bridge.
- Do not build i810 on CONFIG_PREEMPTION.
- Fix cache sync on arm in vgem.
- Allow mapping fb in drm_client only when required, and use it to fix bochs fbdev.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAl1EPe0ACgkQ/lWMcqZw
E8NwlBAAg3698yPzGFKuXQ+LDpcgUA0zL+j2uvpQjmOYsyZCIAkT8gzKP9Z+vySx
ga7mm15uCDE4J3WFYBMIsI3m+r0d3Fdyt2l/r7TTjnNMBE0/X8rtpCb5EWWLuCbf
t6hX4gfwMXz5li7EcQKVq+oeOSuqQV8fPJYgJgdub8ePft3yx3QNDRLBz+BRDap9
NQEwaY0XwYq2PWGx5sNP6Ku8E1tIOzit+UGonkBnYy6RmZ9CPSiR2QIFN3llJ00+
UhGWcr+CXljIj1CkaDJA/f6FDVBo5dbGkhSJUHirB0csDnvq4ena5xKg8FGFAQ3e
RLKMwRbTXKHlTY/wxl9iibUR2wNA0DnQYIeWBBaEGpUtnjmMgzugPWGXWm6+qIZ2
zl2k2cTSJmgubzABY+FSI27MwYpgqT9Bh5pceJitx4/ijojgdN+KzkN5Nlw7XcAt
ejRbIdfMrtN6XRgoNtliBNyfzLccb4ONNQNbvKYTo6pIxbgSnlnHGF+VIxPUvBnN
oEbd7OcjaBEU0eL0gZWAFlFeZlMvqaYk1dlC4wMqPECIDMTJV6F5CyXILq2PVjMj
+i2+5Twqa2L7naOFedn0B6wfaVAiXtR5VZ9lzXc8l5L8KpF46Yajx/ndAn+iGAWC
ERiqwMvhCy6eK9JUbEyhrL+NPiIxTsbgV+VD4cLsFtkh2cR484I=
=oX0Q
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-fixes-2019-08-02' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
drm-misc-fixes for v5.3-rc3:
- Fix some build errors in drm/bridge.
- Do not build i810 on CONFIG_PREEMPTION.
- Fix cache sync on arm in vgem.
- Allow mapping fb in drm_client only when required, and use it to fix bochs fbdev.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/af0dc371-16e0-cee8-0d71-4824d44aa973@linux.intel.com
Silence the following warnings when built with -Wimplicit-fallthrough=3
enabled by default since 5.3-rc2:
In file included from ./include/linux/preempt.h:11,
from ./include/linux/spinlock.h:51,
from ./include/linux/mmzone.h:8,
from ./include/linux/gfp.h:6,
from ./include/linux/slab.h:15,
from drivers/s390/crypto/ap_queue.c:13:
drivers/s390/crypto/ap_queue.c: In function 'ap_sm_recv':
./include/linux/list.h:577:2: warning: this statement may fall through [-Wimplicit-fallthrough=]
577 | for (pos = list_first_entry(head, typeof(*pos), member); \
| ^~~
drivers/s390/crypto/ap_queue.c:147:3: note: in expansion of macro 'list_for_each_entry'
147 | list_for_each_entry(ap_msg, &aq->pendingq, list) {
| ^~~~~~~~~~~~~~~~~~~
drivers/s390/crypto/ap_queue.c:155:2: note: here
155 | case AP_RESPONSE_NO_PENDING_REPLY:
| ^~~~
drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_ep11_xcrb':
drivers/s390/crypto/zcrypt_msgtype6.c:871:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
871 | if (msg->cprbx.cprb_ver_id == 0x04)
| ^
drivers/s390/crypto/zcrypt_msgtype6.c:874:2: note: here
874 | default: /* Unknown response type, this should NEVER EVER happen */
| ^~~~~~~
drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_rng':
drivers/s390/crypto/zcrypt_msgtype6.c:901:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
901 | if (msg->cprbx.cprb_ver_id == 0x02)
| ^
drivers/s390/crypto/zcrypt_msgtype6.c:907:2: note: here
907 | default: /* Unknown response type, this should NEVER EVER happen */
| ^~~~~~~
drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_xcrb':
drivers/s390/crypto/zcrypt_msgtype6.c:838:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
838 | if (msg->cprbx.cprb_ver_id == 0x02)
| ^
drivers/s390/crypto/zcrypt_msgtype6.c:844:2: note: here
844 | default: /* Unknown response type, this should NEVER EVER happen */
| ^~~~~~~
drivers/s390/crypto/zcrypt_msgtype6.c: In function 'convert_response_ica':
drivers/s390/crypto/zcrypt_msgtype6.c:801:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
801 | if (msg->cprbx.cprb_ver_id == 0x02)
| ^
drivers/s390/crypto/zcrypt_msgtype6.c:808:2: note: here
808 | default: /* Unknown response type, this should NEVER EVER happen */
| ^~~~~~~
Acked-by: Patrick Steuer <patrick.steuer@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Make debug exceptions visible from RCU so that synchronize_rcu()
correctly track the debug exception handler.
This also introduces sanity checks for user-mode exceptions as same
as x86's ist_enter()/ist_exit().
The debug exception can interrupt in idle task. For example, it warns
if we put a kprobe on a function called from idle task as below.
The warning message showed that the rcu_read_lock() caused this
problem. But actually, this means the RCU is lost the context which
is already in NMI/IRQ.
/sys/kernel/debug/tracing # echo p default_idle_call >> kprobe_events
/sys/kernel/debug/tracing # echo 1 > events/kprobes/enable
/sys/kernel/debug/tracing # [ 135.122237]
[ 135.125035] =============================
[ 135.125310] WARNING: suspicious RCU usage
[ 135.125581] 5.2.0-08445-g9187c508bdc7 #20 Not tainted
[ 135.125904] -----------------------------
[ 135.126205] include/linux/rcupdate.h:594 rcu_read_lock() used illegally while idle!
[ 135.126839]
[ 135.126839] other info that might help us debug this:
[ 135.126839]
[ 135.127410]
[ 135.127410] RCU used illegally from idle CPU!
[ 135.127410] rcu_scheduler_active = 2, debug_locks = 1
[ 135.128114] RCU used illegally from extended quiescent state!
[ 135.128555] 1 lock held by swapper/0/0:
[ 135.128944] #0: (____ptrval____) (rcu_read_lock){....}, at: call_break_hook+0x0/0x178
[ 135.130499]
[ 135.130499] stack backtrace:
[ 135.131192] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.2.0-08445-g9187c508bdc7 #20
[ 135.131841] Hardware name: linux,dummy-virt (DT)
[ 135.132224] Call trace:
[ 135.132491] dump_backtrace+0x0/0x140
[ 135.132806] show_stack+0x24/0x30
[ 135.133133] dump_stack+0xc4/0x10c
[ 135.133726] lockdep_rcu_suspicious+0xf8/0x108
[ 135.134171] call_break_hook+0x170/0x178
[ 135.134486] brk_handler+0x28/0x68
[ 135.134792] do_debug_exception+0x90/0x150
[ 135.135051] el1_dbg+0x18/0x8c
[ 135.135260] default_idle_call+0x0/0x44
[ 135.135516] cpu_startup_entry+0x2c/0x30
[ 135.135815] rest_init+0x1b0/0x280
[ 135.136044] arch_call_rest_init+0x14/0x1c
[ 135.136305] start_kernel+0x4d4/0x500
[ 135.136597]
So make debug exception visible to RCU can fix this warning.
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Acked-by: Paul E. McKenney <paulmck@linux.ibm.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
kprobes manipulates the interrupted PSTATE for single step, and
doesn't restore it. Thus, if we put a kprobe where the pstate.D
(debug) masked, the mask will be cleared after the kprobe hits.
Moreover, in the most complicated case, this can lead a kernel
crash with below message when a nested kprobe hits.
[ 152.118921] Unexpected kernel single-step exception at EL1
When the 1st kprobe hits, do_debug_exception() will be called.
At this point, debug exception (= pstate.D) must be masked (=1).
But if another kprobes hits before single-step of the first kprobe
(e.g. inside user pre_handler), it unmask the debug exception
(pstate.D = 0) and return.
Then, when the 1st kprobe setting up single-step, it saves current
DAIF, mask DAIF, enable single-step, and restore DAIF.
However, since "D" flag in DAIF is cleared by the 2nd kprobe, the
single-step exception happens soon after restoring DAIF.
This has been introduced by commit 7419333fa1 ("arm64: kprobe:
Always clear pstate.D in breakpoint exception handler")
To solve this issue, this stores all DAIF bits and restore it
after single stepping.
Reported-by: Naresh Kamboju <naresh.kamboju@linaro.org>
Fixes: 7419333fa1 ("arm64: kprobe: Always clear pstate.D in breakpoint exception handler")
Reviewed-by: James Morse <james.morse@arm.com>
Tested-by: James Morse <james.morse@arm.com>
Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Currently the retry counter is not being decremented, leading to a
potential infinite spin if the scalar_reads don't change state.
Addresses-Coverity: ("Infinite loop")
Fixes: 280e54c9f6 ("drm/exynos: scaler: Reset hardware before starting the operation")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Compile-testing this driver on a NOMMU configuration shows a link failure:
drivers/gpu/drm/exynos/exynos_drm_gem.o: In function `exynos_drm_gem_fault':
exynos_drm_gem.c:(.text+0x484): undefined reference to `vmf_insert_mixed'
Add a CONFIG_MMU dependency to ensure we only enable this in configurations
that build correctly.
Many other drm drivers have the same dependency. It would be nice to
make this work in MMU-less configurations, but evidently nobody has
ever needed this so far.
Fixes: 156bdac990 ("drm/exynos: trigger build of all modules")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Inki Dae <daeinki@gmail.com>
Linus Torvalds