COMPLETION_INITIALIZER_ONSTACK() is supposed to be used as an initializer,
in other words, it should only be used in assignment expressions or
compound literals. So the usage in drivers/acpi/nfit/core.c:
COMPLETION_INITIALIZER_ONSTACK(flush.cmp);
... is inappropriate.
Besides, this usage could also break the build for another fix that
reduces stack sizes caused by COMPLETION_INITIALIZER_ONSTACK(), because
that fix changes COMPLETION_INITIALIZER_ONSTACK() from rvalue to lvalue,
and usage as above will report the following error:
drivers/acpi/nfit/core.c: In function 'acpi_nfit_flush_probe':
include/linux/completion.h:77:3: error: value computed is not used [-Werror=unused-value]
(*({ init_completion(&work); &work; }))
This patch fixes this by replacing COMPLETION_INITIALIZER_ONSTACK()
with init_completion() in acpi_nfit_flush_probe(), which does the
same initialization without any other problems.
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Dan Williams <dan.j.williams@intel.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Byungchul Park <byungchul.park@lge.com>
Cc: Len Brown <lenb@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: walken@google.com
Cc: willy@infradead.org
Link: http://lkml.kernel.org/r/20170824142239.15178-1-boqun.feng@gmail.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
All the locking related cmpxchg's in the following functions are
replaced with the _acquire variants:
- pv_queued_spin_steal_lock()
- trylock_clear_pending()
This change should help performance on architectures that use LL/SC.
The cmpxchg in pv_kick_node() is replaced with a relaxed version
with explicit memory barrier to make sure that it is fully ordered
in the writing of next->lock and the reading of pn->state whether
the cmpxchg is a success or failure without affecting performance in
non-LL/SC architectures.
On a 2-socket 12-core 96-thread Power8 system with pvqspinlock
explicitly enabled, the performance of a locking microbenchmark
with and without this patch on a 4.13-rc4 kernel with Xinhui's PPC
qspinlock patch were as follows:
# of thread w/o patch with patch % Change
----------- --------- ---------- --------
8 5054.8 Mop/s 5209.4 Mop/s +3.1%
16 3985.0 Mop/s 4015.0 Mop/s +0.8%
32 2378.2 Mop/s 2396.0 Mop/s +0.7%
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Waiman Long <longman@redhat.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Andrea Parri <parri.andrea@gmail.com>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Pan Xinhui <xinhui@linux.vnet.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Link: http://lkml.kernel.org/r/1502741222-24360-1-git-send-email-longman@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
struct call_single_data is used in IPIs to transfer information between
CPUs. Its size is bigger than sizeof(unsigned long) and less than
cache line size. Currently it is not allocated with any explicit alignment
requirements. This makes it possible for allocated call_single_data to
cross two cache lines, which results in double the number of the cache lines
that need to be transferred among CPUs.
This can be fixed by requiring call_single_data to be aligned with the
size of call_single_data. Currently the size of call_single_data is the
power of 2. If we add new fields to call_single_data, we may need to
add padding to make sure the size of new definition is the power of 2
as well.
Fortunately, this is enforced by GCC, which will report bad sizes.
To set alignment requirements of call_single_data to the size of
call_single_data, a struct definition and a typedef is used.
To test the effect of the patch, I used the vm-scalability multiple
thread swap test case (swap-w-seq-mt). The test will create multiple
threads and each thread will eat memory until all RAM and part of swap
is used, so that huge number of IPIs are triggered when unmapping
memory. In the test, the throughput of memory writing improves ~5%
compared with misaligned call_single_data, because of faster IPIs.
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Huang, Ying <ying.huang@intel.com>
[ Add call_single_data_t and align with size of call_single_data. ]
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Aaron Lu <aaron.lu@intel.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/87bmnqd6lz.fsf@yhuang-mobile.sh.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Where XHLOCK_{SOFT,HARD} are save/restore points in the xhlocks[] to
ensure the temporal IRQ events don't interact with task state, the
XHLOCK_PROC is a fundament different beast that just happens to share
the interface.
The purpose of XHLOCK_PROC is to annotate independent execution inside
one task. For example workqueues, each work should appear to run in its
own 'pristine' 'task'.
Remove XHLOCK_PROC in favour of its own interface to avoid confusion.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Byungchul Park <byungchul.park@lge.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: david@fromorbit.com
Cc: johannes@sipsolutions.net
Cc: kernel-team@lge.com
Cc: oleg@redhat.com
Cc: tj@kernel.org
Link: http://lkml.kernel.org/r/20170829085939.ggmb6xiohw67micb@hirez.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Mike Galbraith bisected a boot crash back to the following commit:
7a46ec0e2f ("locking/refcounts, x86/asm: Implement fast refcount overflow protection")
The crash/hang pattern is:
> Symptom is a few splats as below, with box finally hanging. Network
> comes up, but neither ssh nor console login is possible.
>
> ------------[ cut here ]------------
> WARNING: CPU: 4 PID: 0 at net/netlink/af_netlink.c:374 netlink_sock_destruct+0x82/0xa0
> ...
> __sk_destruct()
> rcu_process_callbacks()
> __do_softirq()
> irq_exit()
> smp_apic_timer_interrupt()
> apic_timer_interrupt()
We are at -rc7 already, and the code has grown some dependencies, so
instead of a plain revert disable the config temporarily, in the hope
of getting real fixes.
Reported-by: Mike Galbraith <efault@gmx.de>
Tested-by: Mike Galbraith <efault@gmx.de>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Davidlohr Bueso <dave@stgolabs.net>
Cc: Elena Reshetova <elena.reshetova@intel.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Rik van Riel <riel@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/tip-7a46ec0e2f4850407de5e1d19a44edee6efa58ec@git.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
There is code duplicated over all architecture's headers for
futex_atomic_op_inuser. Namely op decoding, access_ok check for uaddr,
and comparison of the result.
Remove this duplication and leave up to the arches only the needed
assembly which is now in arch_futex_atomic_op_inuser.
This effectively distributes the Will Deacon's arm64 fix for undefined
behaviour reported by UBSAN to all architectures. The fix was done in
commit 5f16a046f8 (arm64: futex: Fix undefined behaviour with
FUTEX_OP_OPARG_SHIFT usage). Look there for an example dump.
And as suggested by Thomas, check for negative oparg too, because it was
also reported to cause undefined behaviour report.
Note that s390 removed access_ok check in d12a29703 ("s390/uaccess:
remove pointless access_ok() checks") as access_ok there returns true.
We introduce it back to the helper for the sake of simplicity (it gets
optimized away anyway).
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> [s390]
Acked-by: Chris Metcalf <cmetcalf@mellanox.com> [for tile]
Reviewed-by: Darren Hart (VMware) <dvhart@infradead.org>
Reviewed-by: Will Deacon <will.deacon@arm.com> [core/arm64]
Cc: linux-mips@linux-mips.org
Cc: Rich Felker <dalias@libc.org>
Cc: linux-ia64@vger.kernel.org
Cc: linux-sh@vger.kernel.org
Cc: peterz@infradead.org
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: sparclinux@vger.kernel.org
Cc: Jonas Bonn <jonas@southpole.se>
Cc: linux-s390@vger.kernel.org
Cc: linux-arch@vger.kernel.org
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Cc: linux-hexagon@vger.kernel.org
Cc: Helge Deller <deller@gmx.de>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Matt Turner <mattst88@gmail.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: linux-xtensa@linux-xtensa.org
Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
Cc: openrisc@lists.librecores.org
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Stafford Horne <shorne@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Richard Henderson <rth@twiddle.net>
Cc: Chris Zankel <chris@zankel.net>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-parisc@vger.kernel.org
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Richard Kuo <rkuo@codeaurora.org>
Cc: linux-alpha@vger.kernel.org
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: linuxppc-dev@lists.ozlabs.org
Cc: "David S. Miller" <davem@davemloft.net>
Link: http://lkml.kernel.org/r/20170824073105.3901-1-jslaby@suse.cz
Julia reported that the document looked unfinished, and it is. I
forgot to include the example cooked up by Paul here:
https://lkml.kernel.org/r/20170731174345.GL3730@linux.vnet.ibm.com
and I added an explicit example showing how, while it is an ACQUIRE
pattern, it really does provide an MB.
Reported-by: Julia Cartwright <julia@ni.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Boqun Feng <boqun.feng@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The new completion/crossrelease annotations interact unfavourable with
the extant flush_work()/flush_workqueue() annotations.
The problem is that when a single work class does:
wait_for_completion(&C)
and
complete(&C)
in different executions, we'll build dependencies like:
lock_map_acquire(W)
complete_acquire(C)
and
lock_map_acquire(W)
complete_release(C)
which results in the dependency chain: W->C->W, which lockdep thinks
spells deadlock, even though there is no deadlock potential since
works are ran concurrently.
One possibility would be to change the work 'lock' to recursive-read,
but that would mean hitting a lockdep limitation on recursive locks.
Also, unconditinoally switching to recursive-read here would fail to
detect the actual deadlock on single-threaded workqueues, which do
have a problem with this.
For now, forcefully disregard these locks for crossrelease.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: byungchul.park@lge.com
Cc: david@fromorbit.com
Cc: johannes@sipsolutions.net
Cc: oleg@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
The flush_work() annotation as introduced by commit:
e159489baa ("workqueue: relax lockdep annotation on flush_work()")
hits on the lockdep problem with recursive read locks.
The situation as described is:
Work W1: Work W2: Task:
ARR(Q) ARR(Q) flush_workqueue(Q)
A(W1) A(W2) A(Q)
flush_work(W2) R(Q)
A(W2)
R(W2)
if (special)
A(Q)
else
ARR(Q)
R(Q)
where: A - acquire, ARR - acquire-read-recursive, R - release.
Where under 'special' conditions we want to trigger a lock recursion
deadlock, but otherwise allow the flush_work(). The allowing is done
by using recursive read locks (ARR), but lockdep is broken for
recursive stuff.
However, there appears to be no need to acquire the lock if we're not
'special', so if we remove the 'else' clause things become much
simpler and no longer need the recursion thing at all.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Tejun Heo <tj@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: byungchul.park@lge.com
Cc: david@fromorbit.com
Cc: johannes@sipsolutions.net
Cc: oleg@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Currently lockdep has limited support for recursive readers, add a few
mixed read-write ABBA selftests to show the extend of these
limitations.
[ 0.000000] ----------------------------------------------------------------------------
[ 0.000000] | spin |wlock |rlock |mutex | wsem | rsem |
[ 0.000000] --------------------------------------------------------------------------
[ 0.000000] mixed read-lock/lock-write ABBA: |FAILED| | ok |
[ 0.000000] mixed read-lock/lock-read ABBA: | ok | | ok |
[ 0.000000] mixed write-lock/lock-write ABBA: | ok | | ok |
This clearly illustrates the case where lockdep fails to find a
deadlock.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: boqun.feng@gmail.com
Cc: byungchul.park@lge.com
Cc: david@fromorbit.com
Cc: johannes@sipsolutions.net
Cc: oleg@redhat.com
Cc: tj@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
- One core fix accidentally applied first to for-next and then cherry
picked back because it needed to be in the -rc cycles instead
- Another core fix
- Two mlx5 fixes
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJZnyrHAAoJELgmozMOVy/dnZ0P/0oDCZ94NF4MlGnRpYNwnkkU
TmU0fRJZJv4Z+aZOiBYPXs2JbVcu9lTUBko7XB6OTIPEvDKxZrGSzv+SHP8n3W13
xC+i/GdrVN7GC2HrKNPaN4PgPvlmcuC1GvUpi7xMd8qKK/Zj125vqQFjcE0JXdXt
YS8fp/AUFGxkdbaU1/TfBtWAJ1RYrzXocDC+AsQI6hM90Rn9VZy56hLH6Bqm+S+S
L53wUleMkMIa96/6HeyXbMP3C9ZahNJuGYUPAOoNDUeVsZA1MprJ4a2RAOaI0siX
tT+Q66pxvy049ub1NhSI0K7c9KDeApT4GCGmohKaMODLaRfTzLa7xJxUmsAEnk/d
QjAx/VmeEATo929FKf/b+oZNHLrxEYrmxhu1yBfW9LIjrfK2bXgn2uLaBG+/MhNY
ZA2UQ7gio1HPVt4zdAMQSrkTUIchysVoa+vboCOdDpMyQiR6Z1S/mG8IPpF26HYX
QEm/ao4jIEqgcE5X8iBvN63/aOhq6W762jSQu2c9fGJNSks25fPdcagRkAEWUFeg
fbUhYIMDxZDqPNB7V6z61Ob9mOzijJ0RPJPU9ItgwcG0GVY1YMGZV4f07+aK8PEM
wZg6ylehqzJY0I1f2fSzm9W990igBknCm1RC5RYj3m7DrMDZCONXPR9UNqFxSuHh
Ne4hicmCKmmaH8DV+58d
=mnhL
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma
Pull more rdma fixes from Doug Ledford:
"Well, I thought we were going to be done for this -rc cycle. I should
have known better than to say so though.
We have four additional items that trickled in.
One was a simple mistake on my part. I took a patch into my for-next
thinking that the issue was less severe than it was. I was then
notified that it needed to be in my -rc area instead.
The other three were just found late in testing.
Summary:
- One core fix accidentally applied first to for-next and then cherry
picked back because it needed to be in the -rc cycles instead
- Another core fix
- Two mlx5 fixes"
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
IB/mlx5: Always return success for RoCE modify port
IB/mlx5: Fix Raw Packet QP event handler assignment
IB/core: Avoid accessing non-allocated memory when inferring port type
RDMA/uverbs: Initialize cq_context appropriately
- Fix a regression in the ACPI EC driver causing a kernel to crash
during initialization on some systems due to a code ordering issue
exposed by a recent change (Lv Zheng).
- Fix a recent regression in ACPICA due to a change of the behavior
of a library function in a way that is not backwards compatible
with some existing callers of it (Rafael Wysocki).
- Fix a coding mistake in a library function related to the handling
of ACPI device properties introduced during the 4.12 cycle (Sakari
Ailus).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABCAAGBQJZnzf/AAoJEILEb/54YlRxBsIP+gL2fe97Ozg74Or/o3Nvx78D
qpvNPDsqav85nI9um2d0XIl/OWoZ130z4tZLCNK5DkDroEaEGWM99B2S5Rvvf2I6
X1K1GAmepvxJvfcTu/E2Fsfx6FMqxEiYQp5hzEqOU1BFzgYax/cM6TCMtxQgzjdg
Jls96QtFcZYwfNHeshdgvAhPlxjYnchE/YSBwymabiQIGLbaqLg3NMN9l3KKWQru
8A7rR0KyrJNAlRiptpm8hxnNS+GncURryyP/7iyL0XVABC9J1HA2LIfvszaNi9BE
eXr2FKKPnMoVvuBfvuEYwAo/Kcq6ffRHoaYUIzbBpGgHqGIxath5Od2SQtDaAKxV
YL72WGTdU06uvSbJUnphe1pT/gbDSaaMY2j3Npv61KzpAab+GIK8cim21mQ8+ItD
nyz0++C2SVdFd4RioXBFkK4MCBLgfjLapHbnIS9PtuETMHkHgk+MQPRcLcQ/37Vf
sstcYuVNkxzVn/Na5d9vOkBudc13HeMPOYQ++ZfscUNyxy2QCid8B4jZGg9APfg6
WNt66/NVwCA09Df+5T2xzDwWPzv5aPoecXAQopBQlMpziHH/oRi6jbRVLIt7qRm3
8Z3JjLEwhb5EgGqRV84eBNGb/cVmRVFPzw35n9gBUUybvER3hbPksmAs78V6aCh6
wioaS13fV+uHbjTgTDup
=b1HB
-----END PGP SIGNATURE-----
Merge tag 'acpi-4.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI fixes from Rafael Wysocki:
"These fix two recent regressions (in ACPICA and in the ACPI EC driver)
and one bug in code introduced during the 4.12 cycle (ACPI device
properties library routine).
Specifics:
- Fix a regression in the ACPI EC driver causing a kernel to crash
during initialization on some systems due to a code ordering issue
exposed by a recent change (Lv Zheng).
- Fix a recent regression in ACPICA due to a change of the behavior
of a library function in a way that is not backwards compatible
with some existing callers of it (Rafael Wysocki).
- Fix a coding mistake in a library function related to the handling
of ACPI device properties introduced during the 4.12 cycle (Sakari
Ailus)"
* tag 'acpi-4.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI: device property: Fix node lookup in acpi_graph_get_child_prop_value()
ACPICA: Fix acpi_evaluate_object_typed()
ACPI: EC: Fix regression related to wrong ECDT initialization order
- fix linker script regression caused by dead code elimination support
- fix typos and outdated comments
- specify kselftest-clean as a PHONY target
- fix "make dtbs_install" when $(srctree) includes shell special
characters like '~'
- Move -fshort-wchar to the global option list because defining it
partially emits warnings
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZnvezAAoJED2LAQed4NsGTK0P/jZY3jNT3tzgldH5ggCeA7Z2
qekRVR3z0CCm3FU+NlWLVNsiyWDRxuN93lIVML8f7wt/kuJDNxycx5G7+Yiw60yH
h41gibJJdS3GL+VzfGUk1WeZkoAiGVVbLvENJzOQRIeHblsi8Ris+pBwT3MY/WKl
XM0k+xsc/abB3dnhgws8WiUvrNhRiqsciq7IBkDPzxGa4JC53+9Yjjc1HA6gah+g
gKX2qZmsjKm9Hsueot9clTttT+iDHmJ0QetHeMGy0T6bqjlRzG+H37ZGtGv3ZP4p
wcsct8QJt+8/TSEtvkROg2apBUlrEkblvsL/G2UFew42Fz4Z3XLariHTcrDoYuHY
IiUc/tUbmx6Ft72ZvepD+qN+rxQiWKqRzTD+7sDDNPPbdgC4pwZ2Z6m7Oih8mRT5
jGlex4PN/rA5ZvTDFF8c/1GhStZrfxM7A7t6k4Snui6hOpxcpK9vHDgKrfGjk83h
xkwvrPIXnreaAvUYz18JhTU1Zuzj5vwIZgPI1bRl3fi4JmagsAwl+IJawWXMFODA
WONJnqavCYRcdffD0cGfJqA8YSmpxfiDxtP7NiOt05jagDHDGH6bbsUR5Oni/9wU
9D8wdn4XdrrYGG2kEVMDa0x4Yn8vVuPfyxy5DgcRciMcYCUfNHOIHFutRvFhwcqm
rV7ege5oIH8DdsWoE5pj
=m8Zm
-----END PGP SIGNATURE-----
Merge tag 'kbuild-fixes-v4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild
Pull Kbuild fixes from Masahiro Yamada:
- fix linker script regression caused by dead code elimination support
- fix typos and outdated comments
- specify kselftest-clean as a PHONY target
- fix "make dtbs_install" when $(srctree) includes shell special
characters like '~'
- Move -fshort-wchar to the global option list because defining it
partially emits warnings
* tag 'kbuild-fixes-v4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild:
kbuild: update comments of Makefile.asm-generic
kbuild: Do not use hyphen in exported variable name
Makefile: add kselftest-clean to PHONY target list
Kbuild: use -fshort-wchar globally
fixdep: trivial: typo fix and correction
kbuild: trivial cleanups on the comments
kbuild: linker script do not match C names unless LD_DEAD_CODE_DATA_ELIMINATION is configured
Pull btrfs fix from David Sterba:
"We have one more fixup that stems from the blk_status_t conversion
that did not quite cover everything.
The normal cases were not affected because the code is 0, but any
error and retries could mix up new and old values"
* 'for-4.13-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
Btrfs: fix blk_status_t/errno confusion
- Two small memory leaks in error paths.
- A missed return error code on an error path.
- A fix to check the tracing ring buffer CPU when it doesn't
exist (caused by setting maxcpus on the command line that is less
than the actual number of CPUs, and then onlining them manually).
- A fix to have the reset of boot tracers called by lateinit_sync()
instead of just lateinit(). As some of the tracers register via
lateinit(), and if the clear happens before the tracer is registered,
it will never start even though it was told to via the kernel command
line.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEEQEw9Eu0DdyUUkuUUybkF8mrZjcsFAlme4DwUHHJvc3RlZHRA
Z29vZG1pcy5vcmcACgkQybkF8mrZjcssNwf+Itap7Mtbk48wJYNqfjk1pzyiOcYV
WM88EOBFM46dttVN6cBs2uUmtdvmX/g52RtsHzG6ZbwxzLE+tIGbSO2plGoknOyD
lro5CSHT2j3bu0enqkxfznDUT0PNrELEaYBoMK0yhMsXm0v+XqHUxkIqb19Ubuo+
ORPBShZghJtAiEBFArV1nXBW1kzrIFJwjymdF2ccqUlg+XxtPS1wgnZPIOjCa8ia
YM4bX3aTUh4LiUUvS7FlJsrwjB+JFOHdXu1Vg140CvJEon1a+bW4Jx88MxoN6zrp
xmFlXm/8MLWz27GO11IkveH01mSrdP67bKIIx8v2ybPBbwsW0Msb2HfZkw==
=rUJQ
-----END PGP SIGNATURE-----
Merge tag 'trace-v4.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace
Pull tracing fixes from Steven Rostedt:
"Various bug fixes:
- Two small memory leaks in error paths.
- A missed return error code on an error path.
- A fix to check the tracing ring buffer CPU when it doesn't exist
(caused by setting maxcpus on the command line that is less than
the actual number of CPUs, and then onlining them manually).
- A fix to have the reset of boot tracers called by lateinit_sync()
instead of just lateinit(). As some of the tracers register via
lateinit(), and if the clear happens before the tracer is
registered, it will never start even though it was told to via the
kernel command line"
* tag 'trace-v4.13-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
tracing: Fix freeing of filter in create_filter() when set_str is false
tracing: Fix kmemleak in tracing_map_array_free()
ftrace: Check for null ret_stack on profile function graph entry function
ring-buffer: Have ring_buffer_alloc_read_page() return error on offline CPU
tracing: Missing error code in tracer_alloc_buffers()
tracing: Call clear_boot_tracer() at lateinit_sync
A small number of bugfixes, again nothing serious.
- Alexander Dahl found multiple bugs in the Atmel memory interface driver
- A randconfig build fix for at91 was incomplete, the second
attempt fixes the remaining corner case
- One fix for the TI Keystone queue handler
- The Odroid XU4 HDMI port (added in 4.13) needs a small
DT fix
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUAWZ7eqmCrR//JCVInAQIklg/8DNhWPxYzlsCEDN3l2/NdMKeUxQebVEs8
uxSviP3k95nk0G1GwpExX4ywhKRjtdGiwjGtpajtRW06OSTwsd44k1NWMSb2ezUl
01bEjakd/n0OKE9HSuH2ZVs7Wr6BI/4wGhlf5lyB7iq8nuwqOj4w+UBF62aqV3e/
1I9lsumyzwoKo2egDwSusdhivY/IBLggjZGH/Zm3iHzQH5PAM9t701e7/Cc65Pv5
67RUmMbHY5zlTmXtvNlSfw2bMrgXBAh/e5qlaxu/FSxqw9iV2fFikOgjFGGQYofV
/aPiJogAoI1g5aMcq6EwToo1rc9ct9dXHmaquRiPCHEsBSq6DENQ3qC7jwByyaHq
Owzm5Hqoiw6hQ0ERef0zl+0vxwKwAFjDLhAufl3qA4Nihnt8BYpAi72qjMI09fM5
6SR0JHqmlxSg7lydjXORtYtbL40Eiige529LD1lgS5L1WC/p2sVRXrzkyPsiSbdG
HGuYOQWSVRqmihV/WrWYf6gIvcSapxes1SfPGECmGsxPQaSOpQITn9p1kpjtP+u1
KryKKCc93uO+Tk3UgOcujEzT7/+MgQDEksmukXdcD8KS4vK33QPE7SdKAJHvKFo+
Xu8wis5SqHtqga7KMU2qoDzPFyiTSSC0Hry/fEghOCRNguD9jS19DDLdggGXJkV0
+hhvq41jWJA=
=efYA
-----END PGP SIGNATURE-----
Merge tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC fixes from Arnd Bergmann:
"A small number of bugfixes, again nothing serious.
- Alexander Dahl found multiple bugs in the Atmel memory interface
driver
- A randconfig build fix for at91 was incomplete, the second attempt
fixes the remaining corner case
- One fix for the TI Keystone queue handler
- The Odroid XU4 HDMI port (added in 4.13) needs a small DT fix"
* tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc:
ARM: dts: exynos: add needs-hpd for Odroid-XU3/4
ARM: at91: don't select CONFIG_ARM_CPU_SUSPEND for old platforms
soc: ti: knav: Add a NULL pointer check for kdev in knav_pool_create
memory: atmel-ebi: Fix smc cycle xlate converter
memory: atmel-ebi: Allow t_DF timings of zero ns
memory: atmel-ebi: Fix smc timing return value evaluation
The implementation of TIOCGPTPEER has two issues.
When /dev/ptmx (as opposed to /dev/pts/ptmx) is opened the wrong
vfsmount is passed to dentry_open. Which results in the kernel displaying
the wrong pathname for the peer.
The second is simply by caching the vfsmount and dentry of the peer it leaves
them open, in a way they were not previously Which because of the inreased
reference counts can cause unnecessary behaviour differences resulting in
regressions.
To fix these move the ioctl into tty_io.c at a generic level allowing
the ioctl to have access to the struct file on which the ioctl is
being called. This allows the path of the slave to be derived when
opening the slave through TIOCGPTPEER instead of requiring the path to
the slave be cached. Thus removing the need for caching the path.
A new function devpts_ptmx_path is factored out of devpts_acquire and
used to implement a function devpts_mntget. The new function devpts_mntget
takes a filp to perform the lookup on and fsi so that it can confirm
that the superblock that is found by devpts_ptmx_path is the proper superblock.
v2: Lots of fixes to make the code actually work
v3: Suggestions by Linus
- Removed the unnecessary initialization of filp in ptm_open_peer
- Simplified devpts_ptmx_path as gotos are no longer required
[ This is the fix for the issue that was reverted in commit
143c97cc65, but this time without breaking 'pbuilder' due to
increased reference counts - Linus ]
Fixes: 54ebbfb160 ("tty: add TIOCGPTPEER ioctl")
Reported-by: Christian Brauner <christian.brauner@canonical.com>
Reported-and-tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
CM layer calls ib_modify_port() regardless of the link layer.
For the Ethernet ports, qkey violation and Port capabilities
are meaningless. Therefore, always return success for ib_modify_port
calls on the Ethernet ports.
Cc: Selvin Xavier <selvin.xavier@broadcom.com>
Signed-off-by: Majd Dibbiny <majd@mellanox.com>
Reviewed-by: Moni Shoua <monis@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Commit 44c58487d5 ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types")
introduced the concept of type in ah_attr:
* During ib_register_device, each port is checked for its type which
is stored in ib_device's port_immutable array.
* During uverbs' modify_qp, the type is inferred using the port number
in ib_uverbs_qp_dest struct (address vector) by accessing the
relevant port_immutable array and the type is passed on to
providers.
IB spec (version 1.3) enforces a valid port value only in Reset to
Init. During Init to RTR, the address vector must be valid but port
number is not mentioned as a field in the address vector, so its
value is not validated, which leads to accesses to a non-allocated
memory when inferring the port type.
Save the real port number in ib_qp during modify to Init (when the
comp_mask indicates that the port number is valid) and use this value
to infer the port type.
Avoid copying the address vector fields if the matching bit is not set
in the attr_mask. Address vector can't be modified before the port, so
no valid flow is affected.
Fixes: 44c58487d5 ('IB/core: Define 'ib' and 'roce' rdma_ah_attr types')
Signed-off-by: Noa Osherovich <noaos@mellanox.com>
Reviewed-by: Yishai Hadas <yishaih@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
This fixes several instances of blk_status_t and bare errno ints being
mixed up, some of which are real bugs.
In the normal case, 0 matches BLK_STS_OK, so we don't observe any
effects of the missing conversion, but in case of errors or passes
through the repair/retry paths, the errors get mixed up.
The changes were identified using 'sparse', we don't have reports of the
buggy behaviour.
Fixes: 4e4cbee93d ("block: switch bios to blk_status_t")
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Performing the following task with kmemleak enabled:
# cd /sys/kernel/tracing/events/irq/irq_handler_entry/
# echo 'enable_event:kmem:kmalloc:3 if irq >' > trigger
# echo 'enable_event:kmem:kmalloc:3 if irq > 31' > trigger
# echo scan > /sys/kernel/debug/kmemleak
# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffff8800b9290308 (size 32):
comm "bash", pid 1114, jiffies 4294848451 (age 141.139s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff81cef5aa>] kmemleak_alloc+0x4a/0xa0
[<ffffffff81357938>] kmem_cache_alloc_trace+0x158/0x290
[<ffffffff81261c09>] create_filter_start.constprop.28+0x99/0x940
[<ffffffff812639c9>] create_filter+0xa9/0x160
[<ffffffff81263bdc>] create_event_filter+0xc/0x10
[<ffffffff812655e5>] set_trigger_filter+0xe5/0x210
[<ffffffff812660c4>] event_enable_trigger_func+0x324/0x490
[<ffffffff812652e2>] event_trigger_write+0x1a2/0x260
[<ffffffff8138cf87>] __vfs_write+0xd7/0x380
[<ffffffff8138f421>] vfs_write+0x101/0x260
[<ffffffff8139187b>] SyS_write+0xab/0x130
[<ffffffff81cfd501>] entry_SYSCALL_64_fastpath+0x1f/0xbe
[<ffffffffffffffff>] 0xffffffffffffffff
The function create_filter() is passed a 'filterp' pointer that gets
allocated, and if "set_str" is true, it is up to the caller to free it, even
on error. The problem is that the pointer is not freed by create_filter()
when set_str is false. This is a bug, and it is not up to the caller to free
the filter on error if it doesn't care about the string.
Link: http://lkml.kernel.org/r/1502705898-27571-2-git-send-email-chuhu@redhat.com
Cc: stable@vger.kernel.org
Fixes: 38b78eb85 ("tracing: Factorize filter creation")
Reported-by: Chunyu Hu <chuhu@redhat.com>
Tested-by: Chunyu Hu <chuhu@redhat.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
There's a small race when function graph shutsdown and the calling of the
registered function graph entry callback. The callback must not reference
the task's ret_stack without first checking that it is not NULL. Note, when
a ret_stack is allocated for a task, it stays allocated until the task exits.
The problem here, is that function_graph is shutdown, and a new task was
created, which doesn't have its ret_stack allocated. But since some of the
functions are still being traced, the callbacks can still be called.
The normal function_graph code handles this, but starting with commit
8861dd303c ("ftrace: Access ret_stack->subtime only in the function
profiler") the profiler code references the ret_stack on function entry, but
doesn't check if it is NULL first.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=196611
Cc: stable@vger.kernel.org
Fixes: 8861dd303c ("ftrace: Access ret_stack->subtime only in the function profiler")
Reported-by: lilydjwg@gmail.com
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
This reverts commit c8c03f1858.
It turns out that while fixing the ptmx file descriptor to have the
correct 'struct path' to the associated slave pty is a really good
thing, it breaks some user space tools for a very annoying reason.
The problem is that /dev/ptmx and its associated slave pty (/dev/pts/X)
are on different mounts. That was what caused us to have the wrong path
in the first place (we would mix up the vfsmount of the 'ptmx' node,
with the dentry of the pty slave node), but it also means that now while
we use the right vfsmount, having the pty master open also keeps the pts
mount busy.
And it turn sout that that makes 'pbuilder' very unhappy, as noted by
Stefan Lippers-Hollmann:
"This patch introduces a regression for me when using pbuilder
0.228.7[2] (a helper to build Debian packages in a chroot and to
create and update its chroots) when trying to umount /dev/ptmx (inside
the chroot) on Debian/ unstable (full log and pbuilder configuration
file[3] attached).
[...]
Setting up build-essential (12.3) ...
Processing triggers for libc-bin (2.24-15) ...
I: unmounting dev/ptmx filesystem
W: Could not unmount dev/ptmx: umount: /var/cache/pbuilder/build/1340/dev/ptmx: target is busy
(In some cases useful info about processes that
use the device is found by lsof(8) or fuser(1).)"
apparently pbuilder tries to unmount the /dev/pts filesystem while still
holding at least one master node open, which is arguably not very nice,
but we don't break user space even when fixing other bugs.
So this commit has to be reverted.
I'll try to figure out a way to avoid caching the path to the slave pty
in the master pty. The only thing that actually wants that slave pty
path is the "TIOCGPTPEER" ioctl, and I think we could just recreate the
path at that time.
Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de>
Cc: Eric W Biederman <ebiederm@xmission.com>
Cc: Christian Brauner <christian.brauner@canonical.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
CEC support was added for Exynos5 in 4.13, but for the Odroids we need to set
'needs-hpd' as well since CEC is disabled when there is no HDMI hotplug signal,
just as for the exynos4 Odroid-U3.
This is due to the level-shifter that is disabled when there is no HPD, thus
blocking the CEC signal as well. Same close-but-no-cigar board design as the
Odroid-U3.
Tested with my Odroid XU4.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
- Fix very early boot failures with KASLR enabled
- Fix fatal signal handling on userspace access from kernel
- Fix leakage of floating point register state across exec()
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABCgAGBQJZnUeIAAoJELescNyEwWM0hH8IALpwELGRIKFkHYCSnBBjyHUl
SfoWSJJ8Q9X8filHk5DakfM8wTcsbwlk6XpCwqx+hbETGDq8Zz8eKlzJvg0ARpND
/Z6H3nhp3Z1MIV0nkn10XLgbKNwl7/512lTaO+TfqiIXG7fLZh5+zWBlHMcvDuNb
RAy8AVNnYOfiqB4tRupZ8MoRerVi8PHPUpPY/FB1NeGoD0nNIl/lopKRwaD+XXiS
KDfnZd4jAs8y71iaOSidybyNFQ7T++MvZsGx4eLB86MY4IBihxBWQojvtNp7Pptp
H50IFvSYKG4LXTYphZUbWriW600PGHO4oVjeY1KaZsgAhtIsegqi1SH75ulXe70=
=ES28
-----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:
"Late arm64 fixes.
They fix very early boot failures with KASLR where the early mapping
of the kernel is incorrect, so the failure mode looks like a hang with
no output. There's also a signal-handling fix when a uaccess routine
faults with a fatal signal pending, which could be used to create
unkillable user tasks using userfaultfd and finally a state leak fix
for the floating pointer registers across a call to exec().
We're still seeing some random issues crop up (inode memory corruption
and spinlock recursion) but we've not managed to reproduce things
reliably enough to debug or bisect them yet.
Summary:
- Fix very early boot failures with KASLR enabled
- Fix fatal signal handling on userspace access from kernel
- Fix leakage of floating point register state across exec()"
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
arm64: kaslr: Adjust the offset to avoid Image across alignment boundary
arm64: kaslr: ignore modulo offset when validating virtual displacement
arm64: mm: abort uaccess retries upon fatal signal
arm64: fpsimd: Prevent registers leaking across exec
- An important core fix to reject invalid GPIOs *before* trying
to obtain a GPIO descriptor for it.
- A driver fix for the mvebu driver IRQ handling.
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJZnT/4AAoJEEEQszewGV1zt4oP/14p4YCqooukiR8oZpG30Wj3
34EOPQ2k2/BrKegO3IN+4TkZScfnH4hqeJ6z95mrJtI0MMXBM3Zu+967L1lVOueB
TBaxb034iNGpjztB3gQ1cCBuR7409AH89irzUFeNXfSZtelAu73lfiEp1W02+uUt
80Jlzuov/ANJi2PrNS1arH8QJmurWwhmbCsqQ8xB8RXkNE0uu5809ahntqlgfSpf
bXGXPrtmNgM14BheGhYMTR+jZRprlblRYrz1Cjy9x9iJeJWOzADVpjeIjBZxI4OG
M+MPWfyXZldiVXlhR5QQgeJnQgmi4AkhL7VSkez5Dpdirtrnh0hgVc+oPw01w2g4
bsbaXGzwTuT5ok20+E92po5ALMCLfOwj3Jw91b7UquLbM0QqgDVz/u7VpAk2gPuT
fWTIBxyQMfUSvNqKTF6/gJIkfA40H/x2ydVJvDdFT9I3B4KP4yxPjHzMTd99MmuR
+2n4nULjzjocuaYAdZVAd8gxh+dzsaVBBEx+uSu/jgjoObMKyt93JnWZvak8sBvI
Gehe2zvfvLtGN3C9cBAGzlZIP6vIhB8emCLR7DMLsarGybgwhoxU45cvAfuKepge
FojltQhVXMmiwdNQI4CxNzfRhXOpUhY7/yim/2w+evT9UM15QHKI7CS/3QUqe8uk
qnAFYNXQ9v6PVrh+egu9
=eV+r
-----END PGP SIGNATURE-----
Merge tag 'gpio-v4.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio
Pull GPIO fixes from Linus Walleij:
"Here are the (hopefully) last GPIO fixes for v4.13:
- an important core fix to reject invalid GPIOs *before* trying to
obtain a GPIO descriptor for it.
- a driver fix for the mvebu driver IRQ handling"
* tag 'gpio-v4.13-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
gpio: mvebu: Fix cause computation in irq handler
gpio: reject invalid gpio before getting gpio_desc
Six minor and error leg fixes, plus one major change: the reversion of
scsi-mq as the default. We're doing the latter temporarily (with a
backport to stable) to give us time to fix all the issues that turned
up with this default before trying again.
Signed-off-by: James E.J. Bottomley <jejb@linux.vnet.ibm.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQIcBAABAgAGBQJZnSOUAAoJEAVr7HOZEZN4W/4QAJ4YCDZaS1QH2Yud7IpPA/tb
1A9r5YY0KDqqONiha4u2NbKiCQDr+RupA+r5ZdlO4upFk7ilV4d90EwCbl4L10HL
4wXAhedO8LXcz4bmAx9xWrBD6JXfG92H4UnM3ciWOhNV5eW4e4t3IikxWeYnZBuM
uLNwSIMVKMvz5VXZmItDny0izFjcWbfYIld/7wXSX+naOx5Z1ianeURj7S3kpapb
54olbUjSQfzW325gFRbyvXa78uWVfRmY7wF2KyMBv5DrrJz0mEAEGN84NzGPcOwR
bcHhYRDUNzF1eODRWjtw5lHu+mngtEWILbw3uIjLEuJXnox9cSGgrd+AK96sEuKr
teahjszEsN93MORDafllZylreGdWn+G/DJnF+b6CGKY0h4XsEX/rFIAmvF06hMc/
pBemzjIUJQgXXzMBtPTzciNvYxOAFe4JVrY8AB6FTuvJY6F90HPA71bnmDUnvjhl
wrysqtuSTJoFlCgnO0e0i2koPnxNmuImKoln3VjpDNeW3rBBMJlcMtWueegbOHUh
r5Xc/HQZ2L/8ihB0oqPpnwYmD2czpkldMmEiRMvhJ/f89RxaPub4tmFndbiW8gxs
5wZxFDkN9Fi/+MCjDUZQ2dMfubWmwRpPXm0MWyUQ4rG8+bM+17yci7Be1TGPwQMA
Ito9txXbsdMSE6fTgtk7
=aB/i
-----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:
"Six minor and error leg fixes, plus one major change: the reversion of
scsi-mq as the default.
We're doing the latter temporarily (with a backport to stable) to give
us time to fix all the issues that turned up with this default before
trying again"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: cxgb4i: call neigh_event_send() to update MAC address
Revert "scsi: default to scsi-mq"
scsi: sd_zbc: Write unlock zone from sd_uninit_cmnd()
scsi: aacraid: Fix out of bounds in aac_get_name_resp
scsi: csiostor: fail probe if fw does not support FCoE
scsi: megaraid_sas: fix error handle in megasas_probe_one
My previous patch fixed a link error for all at91 platforms when
CONFIG_ARM_CPU_SUSPEND was not set, however this caused another
problem on a configuration that enabled CONFIG_ARCH_AT91 but none
of the individual SoCs, and that also enabled CPU_ARM720 as
the only CPU:
warning: (ARCH_AT91 && SOC_IMX23 && SOC_IMX28 && ARCH_PXA && MACH_MVEBU_V7 && SOC_IMX6 && ARCH_OMAP3 && ARCH_OMAP4 && SOC_OMAP5 && SOC_AM33XX && SOC_DRA7XX && ARCH_EXYNOS3 && ARCH_EXYNOS4 && EXYNOS5420_MCPM && EXYNOS_CPU_SUSPEND && ARCH_VEXPRESS_TC2_PM && ARM_BIG_LITTLE_CPUIDLE && ARM_HIGHBANK_CPUIDLE && QCOM_PM) selects ARM_CPU_SUSPEND which has unmet direct dependencies (ARCH_SUSPEND_POSSIBLE)
arch/arm/kernel/sleep.o: In function `cpu_resume':
(.text+0xf0): undefined reference to `cpu_arm720_suspend_size'
arch/arm/kernel/suspend.o: In function `__cpu_suspend_save':
suspend.c:(.text+0x134): undefined reference to `cpu_arm720_do_suspend'
This improves the hack some more by only selecting ARM_CPU_SUSPEND
for the part that requires it, and changing pm.c to drop the
contents of unused init functions so we no longer refer to
cpu_resume on at91 platforms that don't need it.
Fixes: cc7a938f5f ("ARM: at91: select CONFIG_ARM_CPU_SUSPEND")
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
acpi_graph_get_child_prop_value() is intended to find a child node with a
certain property value pair. The check
if (!fwnode_property_read_u32(fwnode, prop_name, &nr))
continue;
is faulty: fwnode_property_read_u32() returns zero on success, not on
failure, leading to comparing values only if the searched property was not
found.
Moreover, the check is made against the parent device node instead of
the child one as it should be.
Fixes: 79389a83bc (ACPI / property: Add support for remote endpoints)
Reported-by: Hyungwoo Yang <hyungwoo.yang@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Cc: 4.12+ <stable@vger.kernel.org> # 4.12+
[ rjw: Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Commit 2d2a954375 (ACPICA: Update two error messages to emit
control method name) causes acpi_evaluate_object_typed() to fail
if its pathname argument is NULL, but some callers of that function
in the kernel, particularly acpi_nondev_subnode_data_ok(), pass
NULL as pathname to it and expect it to work.
For this reason, make acpi_evaluate_object_typed() check if its
pathname argument is NULL and fall back to using the pathname of
its handle argument if that is the case.
Reported-by: Sakari Ailus <sakari.ailus@intel.com>
Tested-by: Yang, Hyungwoo <hyungwoo.yang@intel.com>
Fixes: 2d2a954375 (ACPICA: Update two error messages to emit control method name)
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Initializing cq_context with ev_queue in create_cq(), leads to NULL pointer
dereference in ib_uverbs_comp_handler(), if application doesnot use completion
channel. This patch fixes the cq_context initialization.
Fixes: 1e7710f3f6 ("IB/core: Change completion channel to use the reworked")
Cc: stable@vger.kernel.org # 4.12
Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com>
Reviewed-by: Matan Barak <matanb@mellanox.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
(cherry picked from commit 699a2d5b1b)
With 16KB pages and a kernel Image larger than 16MB, the current
kaslr_early_init() logic for avoiding mappings across swapper table
boundaries fails since increasing the offset by kimg_sz just moves the
problem to the next boundary.
This patch rounds the offset down to (1 << SWAPPER_TABLE_SHIFT) if the
Image crosses a PMD_SIZE boundary.
Fixes: afd0e5a876 ("arm64: kaslr: Fix up the kernel image alignment")
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Neeraj Upadhyay <neeraju@codeaurora.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
In the KASLR setup routine, we ensure that the early virtual mapping
of the kernel image does not cover more than a single table entry at
the level above the swapper block level, so that the assembler routines
involved in setting up this mapping can remain simple.
In this calculation we add the proposed KASLR offset to the values of
the _text and _end markers, and reject it if they would end up falling
in different swapper table sized windows.
However, when taking the addresses of _text and _end, the modulo offset
(the physical displacement modulo 2 MB) is already accounted for, and
so adding it again results in incorrect results. So disregard the modulo
offset from the calculation.
Fixes: 08cdac619c ("arm64: relocatable: deal with physically misaligned ...")
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
When there's a fatal signal pending, arm64's do_page_fault()
implementation returns 0. The intent is that we'll return to the
faulting userspace instruction, delivering the signal on the way.
However, if we take a fatal signal during fixing up a uaccess, this
results in a return to the faulting kernel instruction, which will be
instantly retried, resulting in the same fault being taken forever. As
the task never reaches userspace, the signal is not delivered, and the
task is left unkillable. While the task is stuck in this state, it can
inhibit the forward progress of the system.
To avoid this, we must ensure that when a fatal signal is pending, we
apply any necessary fixup for a faulting kernel instruction. Thus we
will return to an error path, and it is up to that code to make forward
progress towards delivering the fatal signal.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Laura Abbott <labbott@redhat.com>
Cc: stable@vger.kernel.org
Reviewed-by: Steve Capper <steve.capper@arm.com>
Tested-by: Steve Capper <steve.capper@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Tested-by: James Morse <james.morse@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
There are some tricky dependencies between the different stages of
flushing the FPSIMD register state during exec, and these can race
with context switch in ways that can cause the old task's regs to
leak across. In particular, a context switch during the memset() can
cause some of the task's old FPSIMD registers to reappear.
Disabling preemption for this small window would be no big deal for
performance: preemption is already disabled for similar scenarios
like updating the FPSIMD registers in sigreturn.
So, instead of rearranging things in ways that might swap existing
subtle bugs for new ones, this patch just disables preemption
around the FPSIMD state flushing so that races of this type can't
occur here. This brings fpsimd_flush_thread() into line with other
code paths.
Cc: stable@vger.kernel.org
Fixes: 674c242c93 ("arm64: flush FP/SIMD state correctly after execve()")
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
This patch was applied to the MFD twice, causing unwanted behavour.
This reverts commit b77eb79acc.
Fixes: b77eb79acc ("mfd: da9061: Fix to remove BBAT_CONT register from chip model")
Reported-by: Steve Twiss <stwiss.opensource@diasemi.com>
Reviewed-by: Steve Twiss <stwiss.opensource@diasemi.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Pull sparc fixes from David Miller:
"Just a couple small fixes, two of which have to do with gcc-7:
1) Don't clobber kernel fixed registers in __multi4 libgcc helper.
2) Fix a new uninitialized variable warning on sparc32 with gcc-7,
from Thomas Petazzoni.
3) Adjust pmd_t initializer on sparc32 to make gcc happy.
4) If ATU isn't available, don't bark in the logs. From Tushar Dave"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc: kernel/pcic: silence gcc 7.x warning in pcibios_fixup_bus()
sparc64: remove unnecessary log message
sparc64: Don't clibber fixed registers in __multi4.
mm: add pmd_t initializer __pmd() to work around a GCC bug.
When building the kernel for Sparc using gcc 7.x, the build fails
with:
arch/sparc/kernel/pcic.c: In function ‘pcibios_fixup_bus’:
arch/sparc/kernel/pcic.c:647:8: error: ‘cmd’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
cmd |= PCI_COMMAND_IO;
^~
The simplified code looks like this:
unsigned int cmd;
[...]
pcic_read_config(dev->bus, dev->devfn, PCI_COMMAND, 2, &cmd);
[...]
cmd |= PCI_COMMAND_IO;
I.e, the code assumes that pcic_read_config() will always initialize
cmd. But it's not the case. Looking at pcic_read_config(), if
bus->number is != 0 or if the size is not one of 1, 2 or 4, *val will
not be initialized.
As a simple fix, we initialize cmd to zero at the beginning of
pcibios_fixup_bus.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
- PAE40 related updates
- SLC errata for region ops
- intc line masking by default
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJZmw0DAAoJEGnX8d3iisJeoogP/R78jWBmVIRr7YBvOMEbNZAz
r5dJHnd2jCUtqQ/rmCndwzOqLv2j77RRdH3nlwfM7YaS8LZmK0Dkz9zUGReCalQU
z1sZfBSZuOfodWbDzfXdJVNEGGu8eSG7/s87E6K9UxOuaZJIPNMyU9qGxjDb3BTo
dzgNmT0xgiqZYtv9Y3uciPgkddJLOxE+eMuEpxzbzejLerUUc/jRV8m5qAL8ja9w
NanzLjo7Ec0FiczyYf1DtiONXBVl556IPQoFJtXIbsfZww8kJxFSZ+qemvmFXJOF
cxSfZeRBOCWV9mRW36kGAeKVE9EWqFHFn/UiCfvhTCpoFXPX63Hz+nVRLEE1lhrQ
ZaiQSuu0QgUkWP39ZpAPQjmdBlVxzv9Jsz5Dh72l3C00Hf9yw3jVCsKX/nZLpLM2
pS8pFVnJqttOLX/6wU1JjIQDhPvzqn0V21SwCXBt2DwyXd1zuce82ioPY7K2Uefc
4Unrso+YpIJNh8NlIe7Pvn8kEitNF7MViybofjhKPXlFXT4FqSJIV0Q/iq/L6lh8
RAfJO3GCQQymkB03aVmfRWq+xgCS0v3K2vP50T3+XEyix98ZwH+D4ViaXs9egmLk
EO323ebCKp8AJxICTme5qtmXs+k/CH+KeCzwSc90Mtf1SD3ohvyUeJvA5BGCCyP5
NP5sxiH9cNKwrMIBdvuE
=mOLm
-----END PGP SIGNATURE-----
Merge tag 'arc-4.13-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
Pull ARC fixes from Vineet Gupta:
- PAE40 related updates
- SLC errata for region ops
- intc line masking by default
* tag 'arc-4.13-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
arc: Mask individual IRQ lines during core INTC init
ARCv2: PAE40: set MSB even if !CONFIG_ARC_HAS_PAE40 but PAE exists in SoC
ARCv2: PAE40: Explicitly set MSB counterpart of SLC region ops addresses
ARC: dma: implement dma_unmap_page and sg variant
ARCv2: SLC: Make sure busy bit is set properly for region ops
ARC: [plat-sim] Include this platform unconditionally
ARC: [plat-axs10x]: prepare dts files for enabling PAE40 on axs103
ARC: defconfig: Cleanup from old Kconfig options
Pull networking fixes from David Miller:
1) Fix IGMP handling wrt VRF, from David Ahern.
2) Fix timer access to freed object in dccp, from Eric Dumazet.
3) Use kmalloc_array() in ptr_ring to avoid overflow cases which are
triggerable by userspace. Also from Eric Dumazet.
4) Fix infinite loop in unmapping cleanup of nfp driver, from Colin Ian
King.
5) Correct datagram peek handling of empty SKBs, from Matthew Dawson.
6) Fix use after free in TIPC, from Eric Dumazet.
7) When replacing a route in ipv6 we need to reset the round robin
pointer, from Wei Wang.
8) Fix bug in pci_find_pcie_root_port() which was unearthed by the
relaxed ordering changes, from Thierry Redding. I made sure to get
an explicit ACK from Bjorn this time around :-)
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net: (27 commits)
ipv6: repair fib6 tree in failure case
net_sched: fix order of queue length updates in qdisc_replace()
tools lib bpf: improve warning
switchdev: documentation: minor typo fixes
bpf, doc: also add s390x as arch to sysctl description
net: sched: fix NULL pointer dereference when action calls some targets
rxrpc: Fix oops when discarding a preallocated service call
irda: do not leak initialized list.dev to userspace
net/mlx4_core: Enable 4K UAR if SRIOV module parameter is not enabled
PCI: Allow PCI express root ports to find themselves
tcp: when rearming RTO, if RTO time is in past then fire RTO ASAP
net: check and errout if res->fi is NULL when RTM_F_FIB_MATCH is set
ipv6: reset fn->rr_ptr when replacing route
sctp: fully initialize the IPv6 address in sctp_v6_to_addr()
tipc: fix use-after-free
tun: handle register_netdevice() failures properly
datagram: When peeking datagrams with offset < 0 don't skip empty skbs
bpf, doc: improve sysctl knob description
netxen: fix incorrect loop counter decrement
nfp: fix infinite loop on umapping cleanup
...