Sriharsha Basavapatna [Thu, 2 Nov 2017 21:09:04 +0000 (02:39 +0530)]
bnxt_re: changing the ip address shouldn't affect new connections
[ Upstream commit
063fb5bd1a01937094f40169a20e4aa5ca030db1 ]
While adding a new gid, the driver currently does not return the context
back to the stack. A subsequent del_gid() (e.g, when ip address is changed)
doesn't find the right context in the driver and it ends up dropping that
request. This results in the HW caching a stale gid entry and traffic fails
because of that. Fix by returning the proper context in bnxt_re_add_gid().
Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chao Yu [Mon, 13 Nov 2017 09:32:39 +0000 (17:32 +0800)]
f2fs: fix to clear FI_NO_PREALLOC
[ Upstream commit
28cfafb73853f0494b06649716687a3ea07681d5 ]
We need to clear FI_NO_PREALLOC flag in error path of f2fs_file_write_iter,
otherwise we will lose the chance to preallocate blocks in latter write()
at one time.
Fixes:
dc91de78e5e1 ("f2fs: do not preallocate blocks which has wrong buffer")
Signed-off-by: Chao Yu <yuchao0@huawei.com>
Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Herbert Xu [Fri, 10 Nov 2017 03:14:06 +0000 (14:14 +1100)]
xfrm: Copy policy family in clone_policy
[ Upstream commit
0e74aa1d79a5bbc663e03a2804399cae418a0321 ]
The syzbot found an ancient bug in the IPsec code. When we cloned
a socket policy (for example, for a child TCP socket derived from a
listening socket), we did not copy the family field. This results
in a live policy with a zero family field. This triggers a BUG_ON
check in the af_key code when the cloned policy is retrieved.
This patch fixes it by copying the family field over.
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ilya Lesokhin [Mon, 13 Nov 2017 08:22:44 +0000 (10:22 +0200)]
tls: Use kzalloc for aead_request allocation
[ Upstream commit
61ef6da622aa7b66bf92991bd272490eea6c712e ]
Use kzalloc for aead_request allocation as
we don't set all the bits in the request.
Fixes:
3c4d7559159b ('tls: kernel TLS support')
Signed-off-by: Ilya Lesokhin <ilyal@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jason Baron [Mon, 13 Nov 2017 21:48:47 +0000 (16:48 -0500)]
jump_label: Invoke jump_label_test() via early_initcall()
[ Upstream commit
92ee46efeb505ead3ab06d3c5ce695637ed5f152 ]
Fengguang Wu reported that running the rcuperf test during boot can cause
the jump_label_test() to hit a WARN_ON(). The issue is that the core jump
label code relies on kernel_text_address() to detect when it can no longer
update branches that may be contained in __init sections. The
kernel_text_address() in turn assumes that if the system_state variable is
greter than or equal to SYSTEM_RUNNING then __init sections are no longer
valid (since the assumption is that they have been freed). However, when
rcuperf is setup to run in early boot it can call kernel_power_off() which
sets the system_state to SYSTEM_POWER_OFF.
Since rcuperf initialization is invoked via a module_init(), we can make
the dependency of jump_label_test() needing to complete before rcuperf
explicit by calling it via early_initcall().
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Jason Baron <jbaron@akamai.com>
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/1510609727-2238-1-git-send-email-jbaron@akamai.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arvind Yadav [Tue, 14 Nov 2017 08:12:38 +0000 (13:42 +0530)]
atm: horizon: Fix irq release error
[ Upstream commit
bde533f2ea607cbbbe76ef8738b36243939a7bc2 ]
atm_dev_register() can fail here and passed parameters to free irq
which is not initialised. Initialization of 'dev->irq' happened after
the 'goto out_free_irq'. So using 'irq' insted of 'dev->irq' in
free_irq().
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masahiro Yamada [Sat, 30 Sep 2017 01:10:09 +0000 (10:10 +0900)]
kbuild: rpm-pkg: fix jobserver unavailable warning
[ Upstream commit
606625be47bc87b6fab0af10cd57aaa675cb9e42 ]
If "make rpm-pkg" or "make binrpm-pkg" is run with -j[jobs] option,
the following warning message is displayed.
warning: jobserver unavailable: using -j1. Add '+' to parent make rule.
Follow the suggestion.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sudeep Holla [Thu, 28 Sep 2017 10:18:53 +0000 (11:18 +0100)]
mailbox: mailbox-test: don't rely on rx_buffer content to signal data ready
[ Upstream commit
e339c80af95e14de3712d69ddea09a3868fa14cd ]
Currently we rely on the first byte of the Rx buffer to check if there's
any data available to be read. If the first byte of the received buffer
is zero (i.e. null character), then we fail to signal that data is
available even when it's available.
Instead introduce a boolean variable to track the data availability and
update it in the channel receive callback as ready and clear it when the
data is read.
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Zhong Kaihua [Mon, 7 Aug 2017 14:51:56 +0000 (22:51 +0800)]
clk: hi3660: fix incorrect uart3 clock freqency
[ Upstream commit
d33fb1b9f0fcb67f2b9f8b1891465a088a9480f8 ]
UART3 clock rate is doubled in previous commit.
This error is not detected until recently a mezzanine board which makes
real use of uart3 port (through LS connector of 96boards) was setup
and tested on hi3660-hikey960 board.
This patch changes clock source rate of clk_factor_uart3 to
100000000.
Signed-off-by: Zhong Kaihua <zhongkaihua@huawei.com>
Signed-off-by: Guodong Xu <guodong.xu@linaro.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masahiro Yamada [Thu, 5 Oct 2017 02:32:59 +0000 (11:32 +0900)]
clk: uniphier: fix DAPLL2 clock rate of Pro5
[ Upstream commit
67affb78a4e4feb837953e3434c8402a5c3b272f ]
The parent of DAPLL2 should be DAPLL1. Fix the clock connection.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Sat, 11 Nov 2017 16:29:28 +0000 (17:29 +0100)]
clk: qcom: common: fix legacy board-clock registration
[ Upstream commit
43a51019cc8ff1b1cd2ba72e86563beb40d356fc ]
Make sure to search only the child nodes of "/clocks", rather than the
whole device-tree depth-first starting at "/clocks" when determining
whether to register a fixed clock in the legacy board-clock registration
helper.
Fixes:
ee15faffef11 ("clk: qcom: common: Add API to register board clocks backwards compatibly")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mylene JOSSERAND [Sun, 5 Nov 2017 16:51:34 +0000 (17:51 +0100)]
clk: sunxi-ng: a83t: Fix i2c buses bits
[ Upstream commit
cc54c0955d6f8618a38a999eecdc3d95306b90de ]
i2c1 and i2c2 bits for CCU are not bit 0 but bit 1 and bit 2.
Because of that, the i2c0 (bit 0) was not correctly configured.
Fixed the correct bits for i2c1 and i2c2.
Fixes:
05359be1176b ("clk: sunxi-ng: Add driver for A83T CCU")
Signed-off-by: Mylène Josserand <mylene.josserand@free-electrons.com>
Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Gabriel Fernandez [Wed, 11 Oct 2017 06:57:24 +0000 (08:57 +0200)]
clk: stm32h7: fix test of clock config
[ Upstream commit
c1ea839c41d049604a3f64ef72712d1c7c6639d0 ]
fix test of composite clock config (bad copy / past)
Signed-off-by: Gabriel Fernandez <gabriel.fernandez@st.com>
Fixes:
3e4d618b0722 ("clk: stm32h7: Add stm32h743 clock driver")
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Wed, 15 Nov 2017 01:15:50 +0000 (17:15 -0800)]
bpf: fix lockdep splat
[ Upstream commit
89ad2fa3f043a1e8daae193bcb5fe34d5f8caf28 ]
pcpu_freelist_pop() needs the same lockdep awareness than
pcpu_freelist_populate() to avoid a false positive.
[ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
switchto-defaul/12508 [HC0[0]:SC0[6]:HE0:SE0] is trying to acquire:
(&htab->buckets[i].lock){......}, at: [<
ffffffff9dc099cb>] __htab_percpu_map_update_elem+0x1cb/0x300
and this task is already holding:
(dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2){+.-...}, at: [<
ffffffff9e135848>] __dev_queue_xmit+0
x868/0x1240
which would create a new lock dependency:
(dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2){+.-...} -> (&htab->buckets[i].lock){......}
but this new dependency connects a SOFTIRQ-irq-safe lock:
(dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2){+.-...}
... which became SOFTIRQ-irq-safe at:
[<
ffffffff9db5931b>] __lock_acquire+0x42b/0x1f10
[<
ffffffff9db5b32c>] lock_acquire+0xbc/0x1b0
[<
ffffffff9da05e38>] _raw_spin_lock+0x38/0x50
[<
ffffffff9e135848>] __dev_queue_xmit+0x868/0x1240
[<
ffffffff9e136240>] dev_queue_xmit+0x10/0x20
[<
ffffffff9e1965d9>] ip_finish_output2+0x439/0x590
[<
ffffffff9e197410>] ip_finish_output+0x150/0x2f0
[<
ffffffff9e19886d>] ip_output+0x7d/0x260
[<
ffffffff9e19789e>] ip_local_out+0x5e/0xe0
[<
ffffffff9e197b25>] ip_queue_xmit+0x205/0x620
[<
ffffffff9e1b8398>] tcp_transmit_skb+0x5a8/0xcb0
[<
ffffffff9e1ba152>] tcp_write_xmit+0x242/0x1070
[<
ffffffff9e1baffc>] __tcp_push_pending_frames+0x3c/0xf0
[<
ffffffff9e1b3472>] tcp_rcv_established+0x312/0x700
[<
ffffffff9e1c1acc>] tcp_v4_do_rcv+0x11c/0x200
[<
ffffffff9e1c3dc2>] tcp_v4_rcv+0xaa2/0xc30
[<
ffffffff9e191107>] ip_local_deliver_finish+0xa7/0x240
[<
ffffffff9e191a36>] ip_local_deliver+0x66/0x200
[<
ffffffff9e19137d>] ip_rcv_finish+0xdd/0x560
[<
ffffffff9e191e65>] ip_rcv+0x295/0x510
[<
ffffffff9e12ff88>] __netif_receive_skb_core+0x988/0x1020
[<
ffffffff9e130641>] __netif_receive_skb+0x21/0x70
[<
ffffffff9e1306ff>] process_backlog+0x6f/0x230
[<
ffffffff9e132129>] net_rx_action+0x229/0x420
[<
ffffffff9da07ee8>] __do_softirq+0xd8/0x43d
[<
ffffffff9e282bcc>] do_softirq_own_stack+0x1c/0x30
[<
ffffffff9dafc2f5>] do_softirq+0x55/0x60
[<
ffffffff9dafc3a8>] __local_bh_enable_ip+0xa8/0xb0
[<
ffffffff9db4c727>] cpu_startup_entry+0x1c7/0x500
[<
ffffffff9daab333>] start_secondary+0x113/0x140
to a SOFTIRQ-irq-unsafe lock:
(&head->lock){+.+...}
... which became SOFTIRQ-irq-unsafe at:
... [<
ffffffff9db5971f>] __lock_acquire+0x82f/0x1f10
[<
ffffffff9db5b32c>] lock_acquire+0xbc/0x1b0
[<
ffffffff9da05e38>] _raw_spin_lock+0x38/0x50
[<
ffffffff9dc0b7fa>] pcpu_freelist_pop+0x7a/0xb0
[<
ffffffff9dc08b2c>] htab_map_alloc+0x50c/0x5f0
[<
ffffffff9dc00dc5>] SyS_bpf+0x265/0x1200
[<
ffffffff9e28195f>] entry_SYSCALL_64_fastpath+0x12/0x17
other info that might help us debug this:
Chain exists of:
dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2 --> &htab->buckets[i].lock --> &head->lock
Possible interrupt unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&head->lock);
local_irq_disable();
lock(dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2);
lock(&htab->buckets[i].lock);
<Interrupt>
lock(dev_queue->dev->qdisc_class ?: &qdisc_tx_lock#2);
*** DEADLOCK ***
Fixes:
e19494edab82 ("bpf: introduce percpu_freelist")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hangbin Liu [Wed, 15 Nov 2017 01:43:09 +0000 (09:43 +0800)]
geneve: fix fill_info when link down
[ Upstream commit
fd7eafd02121d6ef501ef1a4a891e6061366c952 ]
geneve->sock4/6 were added with geneve_open and released with geneve_stop.
So when geneve link down, we will not able to show remote address and
checksum info after commit
11387fe4a98 ("geneve: fix fill_info when using
collect_metadata").
Fix this by avoid passing *_REMOTE{,6} for COLLECT_METADATA since they are
mutually exclusive, and always show UDP_ZERO_CSUM6_RX info.
Fixes:
11387fe4a98 ("geneve: fix fill_info when using collect_metadata")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeff Layton [Tue, 14 Nov 2017 19:43:56 +0000 (14:43 -0500)]
fcntl: don't leak fd reference when fixup_compat_flock fails
[ Upstream commit
9280a601e6080c9ff658468c1c775ff6514099a6 ]
Currently we just return err here, but we need to put the fd reference
first.
Fixes:
94073ad77fff (fs/locks: don't mess with the address limit in compat_fcntl64)
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Wed, 15 Nov 2017 08:57:26 +0000 (16:57 +0800)]
sctp: use the right sk after waking up from wait_buf sleep
[ Upstream commit
cea0cc80a6777beb6eb643d4ad53690e1ad1d4ff ]
Commit
dfcb9f4f99f1 ("sctp: deny peeloff operation on asocs with threads
sleeping on it") fixed the race between peeloff and wait sndbuf by
checking waitqueue_active(&asoc->wait) in sctp_do_peeloff().
But it actually doesn't work, as even if waitqueue_active returns false
the waiting sndbuf thread may still not yet hold sk lock. After asoc is
peeled off, sk is not asoc->base.sk any more, then to hold the old sk
lock couldn't make assoc safe to access.
This patch is to fix this by changing to hold the new sk lock if sk is
not asoc->base.sk, meanwhile, also set the sk in sctp_sendmsg with the
new sk.
With this fix, there is no more race between peeloff and waitbuf, the
check 'waitqueue_active' in sctp_do_peeloff can be removed.
Thanks Marcelo and Neil for making this clear.
v1->v2:
fix it by changing to lock the new sock instead of adding a flag in asoc.
Suggested-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Wed, 15 Nov 2017 08:55:54 +0000 (16:55 +0800)]
sctp: do not free asoc when it is already dead in sctp_sendmsg
[ Upstream commit
ca3af4dd28cff4e7216e213ba3b671fbf9f84758 ]
Now in sctp_sendmsg sctp_wait_for_sndbuf could schedule out without
holding sock sk. It means the current asoc can be freed elsewhere,
like when receiving an abort packet.
If the asoc is just created in sctp_sendmsg and sctp_wait_for_sndbuf
returns err, the asoc will be freed again due to new_asoc is not nil.
An use-after-free issue would be triggered by this.
This patch is to fix it by setting new_asoc with nil if the asoc is
already dead when cpu schedules back, so that it will not be freed
again in sctp_sendmsg.
v1->v2:
set new_asoc as nil in sctp_sendmsg instead of sctp_wait_for_sndbuf.
Suggested-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Miles Chen [Thu, 16 Nov 2017 01:32:25 +0000 (17:32 -0800)]
slub: fix sysfs duplicate filename creation when slub_debug=O
[ Upstream commit
11066386efa692f77171484c32ea30f6e5a0d729 ]
When slub_debug=O is set. It is possible to clear debug flags for an
"unmergeable" slab cache in kmem_cache_open(). It makes the "unmergeable"
cache became "mergeable" in sysfs_slab_add().
These caches will generate their "unique IDs" by create_unique_id(), but
it is possible to create identical unique IDs. In my experiment,
sgpool-128, names_cache, biovec-256 generate the same ID ":Ft-0004096" and
the kernel reports "sysfs: cannot create duplicate filename
'/kernel/slab/:Ft-0004096'".
To repeat my experiment, set disable_higher_order_debug=1,
CONFIG_SLUB_DEBUG_ON=y in kernel-4.14.
Fix this issue by setting unmergeable=1 if slub_debug=O and the the
default slub_debug contains any no-merge flags.
call path:
kmem_cache_create()
__kmem_cache_alias() -> we set SLAB_NEVER_MERGE flags here
create_cache()
__kmem_cache_create()
kmem_cache_open() -> clear DEBUG_METADATA_FLAGS
sysfs_slab_add() -> the slab cache is mergeable now
sysfs: cannot create duplicate filename '/kernel/slab/:Ft-0004096'
------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x60/0x7c
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.14.0-rc7ajb-00131-gd4c2e9f-dirty #123
Hardware name: linux,dummy-virt (DT)
task:
ffffffc07d4e0080 task.stack:
ffffff8008008000
PC is at sysfs_warn_dup+0x60/0x7c
LR is at sysfs_warn_dup+0x60/0x7c
pc : lr : pstate:
60000145
Call trace:
sysfs_warn_dup+0x60/0x7c
sysfs_create_dir_ns+0x98/0xa0
kobject_add_internal+0xa0/0x294
kobject_init_and_add+0x90/0xb4
sysfs_slab_add+0x90/0x200
__kmem_cache_create+0x26c/0x438
kmem_cache_create+0x164/0x1f4
sg_pool_init+0x60/0x100
do_one_initcall+0x38/0x12c
kernel_init_freeable+0x138/0x1d4
kernel_init+0x10/0xfc
ret_from_fork+0x10/0x18
Link: http://lkml.kernel.org/r/1510365805-5155-1-git-send-email-miles.chen@mediatek.com
Signed-off-by: Miles Chen <miles.chen@mediatek.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sergey Senozhatsky [Thu, 16 Nov 2017 01:34:03 +0000 (17:34 -0800)]
zsmalloc: calling zs_map_object() from irq is a bug
[ Upstream commit
1aedcafbf32b3f232c159b14cd0d423fcfe2b861 ]
Use BUG_ON(in_interrupt()) in zs_map_object(). This is not a new
BUG_ON(), it's always been there, but was recently changed to
VM_BUG_ON(). There are several problems there. First, we use use
per-CPU mappings both in zsmalloc and in zram, and interrupt may easily
corrupt those buffers. Second, and more importantly, we believe it's
possible to start leaking sensitive information. Consider the following
case:
-> process P
swap out
zram
per-cpu mapping CPU1
compress page A
-> IRQ
swap out
zram
per-cpu mapping CPU1
compress page B
write page from per-cpu mapping CPU1 to zsmalloc pool
iret
-> process P
write page from per-cpu mapping CPU1 to zsmalloc pool [*]
return
* so we store overwritten data that actually belongs to another
page (task) and potentially contains sensitive data. And when
process P will page fault it's going to read (swap in) that
other task's data.
Link: http://lkml.kernel.org/r/20170929045140.4055-1-sergey.senozhatsky@gmail.com
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Acked-by: Minchan Kim <minchan@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pavel Tatashin [Thu, 16 Nov 2017 01:36:18 +0000 (17:36 -0800)]
sparc64/mm: set fields in deferred pages
[ Upstream commit
2a20aa171071a334d80c4e5d5af719d8374702fc ]
Without deferred struct page feature (CONFIG_DEFERRED_STRUCT_PAGE_INIT),
flags and other fields in "struct page"es are never changed prior to
first initializing struct pages by going through __init_single_page().
With deferred struct page feature enabled there is a case where we set
some fields prior to initializing:
mem_init() {
register_page_bootmem_info();
free_all_bootmem();
...
}
When register_page_bootmem_info() is called only non-deferred struct
pages are initialized. But, this function goes through some reserved
pages which might be part of the deferred, and thus are not yet
initialized.
mem_init
register_page_bootmem_info
register_page_bootmem_info_node
get_page_bootmem
.. setting fields here ..
such as: page->freelist = (void *)type;
free_all_bootmem()
free_low_memory_core_early()
for_each_reserved_mem_region()
reserve_bootmem_region()
init_reserved_page() <- Only if this is deferred reserved page
__init_single_pfn()
__init_single_page()
memset(0) <-- Loose the set fields here
We end up with similar issue as in the previous patch, where currently
we do not observe problem as memory is zeroed. But, if flag asserts are
changed we can start hitting issues.
Also, because in this patch series we will stop zeroing struct page
memory during allocation, we must make sure that struct pages are
properly initialized prior to using them.
The deferred-reserved pages are initialized in free_all_bootmem().
Therefore, the fix is to switch the above calls.
Link: http://lkml.kernel.org/r/20171013173214.27300-4-pasha.tatashin@oracle.com
Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
Reviewed-by: Steven Sistare <steven.sistare@oracle.com>
Reviewed-by: Daniel Jordan <daniel.m.jordan@oracle.com>
Reviewed-by: Bob Picco <bob.picco@oracle.com>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Michal Hocko <mhocko@suse.com>
Cc: Alexander Potapenko <glider@google.com>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christian Borntraeger <borntraeger@de.ibm.com>
Cc: Dmitry Vyukov <dvyukov@google.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Michal Hocko <mhocko@kernel.org>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ming Lei [Thu, 16 Nov 2017 00:08:44 +0000 (08:08 +0800)]
block: wake up all tasks blocked in get_request()
[ Upstream commit
34d9715ac1edd50285168dd8d80c972739a4f6a4 ]
Once blk_set_queue_dying() is done in blk_cleanup_queue(), we call
blk_freeze_queue() and wait for q->q_usage_counter becoming zero. But
if there are tasks blocked in get_request(), q->q_usage_counter can
never become zero. So we have to wake up all these tasks in
blk_set_queue_dying() first.
Fixes:
3ef28e83ab157997 ("block: generic request_queue reference counting")
Signed-off-by: Ming Lei <ming.lei@redhat.com>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 9 Nov 2017 17:07:17 +0000 (18:07 +0100)]
dt-bindings: usb: fix reg-property port-number range
[ Upstream commit
f42ae7b0540937e00fe005812997f126aaac4bc2 ]
The USB hub port-number range for USB 2.0 is 1-255 and not 1-31 which
reflects an arbitrary limit set by the current Linux implementation.
Note that for USB 3.1 hubs the valid range is 1-15.
Increase the documented valid range in the binding to 255, which is the
maximum allowed by the specifications.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Darrick J. Wong [Wed, 15 Nov 2017 00:34:44 +0000 (16:34 -0800)]
xfs: fix forgotten rcu read unlock when skipping inode reclaim
[ Upstream commit
962cc1ad6caddb5abbb9f0a43e5abe7131a71f18 ]
In commit
f2e9ad21 ("xfs: check for race with xfs_reclaim_inode"), we
skip an inode if we're racing with freeing the inode via
xfs_reclaim_inode, but we forgot to release the rcu read lock when
dumping the inode, with the result that we exit to userspace with a lock
held. Don't do that; generic/320 with a 1k block size fails this
very occasionally.
================================================
WARNING: lock held when returning to user space!
4.14.0-rc6-djwong #4 Tainted: G W
------------------------------------------------
rm/30466 is leaving the kernel with locks still held!
1 lock held by rm/30466:
#0: (rcu_read_lock){....}, at: [<
ffffffffa01364d3>] xfs_ifree_cluster.isra.17+0x2c3/0x6f0 [xfs]
------------[ cut here ]------------
WARNING: CPU: 1 PID: 30466 at kernel/rcu/tree_plugin.h:329 rcu_note_context_switch+0x71/0x700
Modules linked in: deadline_iosched dm_snapshot dm_bufio ext4 mbcache jbd2 dm_flakey xfs libcrc32c dax_pmem device_dax nd_pmem sch_fq_codel af_packet [last unloaded: scsi_debug]
CPU: 1 PID: 30466 Comm: rm Tainted: G W 4.14.0-rc6-djwong #4
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.10.2-1ubuntu1djwong0 04/01/2014
task:
ffff880037680000 task.stack:
ffffc90001064000
RIP: 0010:rcu_note_context_switch+0x71/0x700
RSP: 0000:
ffffc90001067e50 EFLAGS:
00010002
RAX:
0000000000000001 RBX:
ffff880037680000 RCX:
ffff88003e73d200
RDX:
0000000000000002 RSI:
ffffffff819e53e9 RDI:
ffffffff819f4375
RBP:
0000000000000000 R08:
0000000000000000 R09:
ffff880062c900d0
R10:
0000000000000000 R11:
0000000000000000 R12:
ffff880037680000
R13:
0000000000000000 R14:
ffffc90001067eb8 R15:
ffff880037680690
FS:
00007fa3b8ce8700(0000) GS:
ffff88003ec00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00007f69bf77c000 CR3:
000000002450a000 CR4:
00000000000006e0
Call Trace:
__schedule+0xb8/0xb10
schedule+0x40/0x90
exit_to_usermode_loop+0x6b/0xa0
prepare_exit_to_usermode+0x7a/0x90
retint_user+0x8/0x20
RIP: 0033:0x7fa3b87fda87
RSP: 002b:
00007ffe41206568 EFLAGS:
00000246 ORIG_RAX:
ffffffffffffff02
RAX:
0000000000000000 RBX:
00000000010e88c0 RCX:
00007fa3b87fda87
RDX:
0000000000000000 RSI:
00000000010e89c8 RDI:
0000000000000005
RBP:
0000000000000000 R08:
0000000000000003 R09:
0000000000000000
R10:
000000000000015e R11:
0000000000000246 R12:
00000000010c8060
R13:
00007ffe41206690 R14:
0000000000000000 R15:
0000000000000000
---[ end trace
e88f83bf0cfbd07d ]---
Fixes:
f2e9ad212def50bcf4c098c6288779dd97fff0f0
Cc: Omar Sandoval <osandov@fb.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pieter Jansen van Vuuren [Fri, 17 Nov 2017 01:06:39 +0000 (17:06 -0800)]
nfp: fix flower offload metadata flag usage
[ Upstream commit
6c3ab204f4ca00374a374bc0fc9a275b64d1bcbb ]
Hardware has no notion of new or last mask id, instead it makes use of the
message type (i.e. add flow or del flow) in combination with a single bit
in metadata flags to determine when to add or delete a mask id. Previously
we made use of the new or last flags to indicate that a new mask should be
allocated or deallocated, respectively. This incorrect behaviour is fixed
by making use single bit in metadata flags to indicate mask allocation or
deallocation.
Fixes:
43f84b72c50d ("nfp: add metadata to each flow offload")
Signed-off-by: Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dirk van der Merwe [Fri, 17 Nov 2017 01:06:41 +0000 (17:06 -0800)]
nfp: inherit the max_mtu from the PF netdev
[ Upstream commit
743ba5b47f7961fb29f2e06bb694fb4f068ac58f ]
The PF netdev is used for data transfer for reprs, so reprs inherit the
maximum MTU settings of the PF netdev.
Fixes:
5de73ee46704 ("nfp: general representor implementation")
Signed-off-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Chuck Lever [Fri, 3 Nov 2017 17:46:06 +0000 (13:46 -0400)]
sunrpc: Fix rpc_task_begin trace point
[ Upstream commit
b2bfe5915d5fe7577221031a39ac722a0a2a1199 ]
The rpc_task_begin trace point always display a task ID of zero.
Move the trace point call site so that it picks up the new task ID.
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Trond Myklebust [Mon, 6 Nov 2017 20:28:04 +0000 (15:28 -0500)]
NFS: Fix a typo in nfs_rename()
[ Upstream commit
d803224c84be067754db7fa58a93f36f61566493 ]
On successful rename, the "old_dentry" is retained and is attached to
the "new_dir", so we need to call nfs_set_verifier() accordingly.
Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Randy Dunlap [Fri, 17 Nov 2017 23:27:35 +0000 (15:27 -0800)]
dynamic-debug-howto: fix optional/omitted ending line number to be LARGE instead of 0
[ Upstream commit
1f3c790bd5989fcfec9e53ad8fa09f5b740c958f ]
line-range is supposed to treat "1-" as "1-endoffile", so
handle the special case by setting last_lineno to UINT_MAX.
Fixes this error:
dynamic_debug:ddebug_parse_query: last-line:0 < 1st-line:1
dynamic_debug:ddebug_exec_query: query parse failed
Link: http://lkml.kernel.org/r/10a6a101-e2be-209f-1f41-54637824788e@infradead.org
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Acked-by: Jason Baron <jbaron@akamai.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stephen Bates [Fri, 17 Nov 2017 23:28:16 +0000 (15:28 -0800)]
lib/genalloc.c: make the avail variable an atomic_long_t
[ Upstream commit
36a3d1dd4e16bcd0d2ddfb4a2ec7092f0ae0d931 ]
If the amount of resources allocated to a gen_pool exceeds 2^32 then the
avail atomic overflows and this causes problems when clients try and
borrow resources from the pool. This is only expected to be an issue on
64 bit systems.
Add the <linux/atomic.h> header to pull in atomic_long* operations. So
that 32 bit systems continue to use atomic32_t but 64 bit systems can
use atomic64_t.
Link: http://lkml.kernel.org/r/1509033843-25667-1-git-send-email-sbates@raithlin.com
Signed-off-by: Stephen Bates <sbates@raithlin.com>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Reviewed-by: Daniel Mentz <danielmentz@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joe Lawrence [Fri, 17 Nov 2017 23:29:17 +0000 (15:29 -0800)]
pipe: match pipe_max_size data type with procfs
[ Upstream commit
98159d977f71c3b3dee898d1c34e56f520b094e7 ]
Patch series "A few round_pipe_size() and pipe-max-size fixups", v3.
While backporting Michael's "pipe: fix limit handling" patchset to a
distro-kernel, Mikulas noticed that current upstream pipe limit handling
contains a few problems:
1 - procfs signed wrap: echo'ing a large number into
/proc/sys/fs/pipe-max-size and then cat'ing it back out shows a
negative value.
2 - round_pipe_size() nr_pages overflow on 32bit: this would
subsequently try roundup_pow_of_two(0), which is undefined.
3 - visible non-rounded pipe-max-size value: there is no mutual
exclusion or protection between the time pipe_max_size is assigned
a raw value from proc_dointvec_minmax() and when it is rounded.
4 - unsigned long -> unsigned int conversion makes for potential odd
return errors from do_proc_douintvec_minmax_conv() and
do_proc_dopipe_max_size_conv().
This version underwent the same testing as v1:
https://marc.info/?l=linux-kernel&m=
150643571406022&w=2
This patch (of 4):
pipe_max_size is defined as an unsigned int:
unsigned int pipe_max_size = 1048576;
but its procfs/sysctl representation is an integer:
static struct ctl_table fs_table[] = {
...
{
.procname = "pipe-max-size",
.data = &pipe_max_size,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = &pipe_proc_fn,
.extra1 = &pipe_min_size,
},
...
that is signed:
int pipe_proc_fn(struct ctl_table *table, int write, void __user *buf,
size_t *lenp, loff_t *ppos)
{
...
ret = proc_dointvec_minmax(table, write, buf, lenp, ppos)
This leads to signed results via procfs for large values of pipe_max_size:
% echo
2147483647 >/proc/sys/fs/pipe-max-size
% cat /proc/sys/fs/pipe-max-size
-
2147483648
Use unsigned operations on this variable to avoid such negative values.
Link: http://lkml.kernel.org/r/1507658689-11669-2-git-send-email-joe.lawrence@redhat.com
Signed-off-by: Joe Lawrence <joe.lawrence@redhat.com>
Reported-by: Mikulas Patocka <mpatocka@redhat.com>
Reviewed-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Michael Kerrisk <mtk.manpages@gmail.com>
Cc: Randy Dunlap <rdunlap@infradead.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Fri, 17 Nov 2017 23:37:57 +0000 (15:37 -0800)]
drivers/rapidio/devices/rio_mport_cdev.c: fix resource leak in error handling path in 'rio_dma_transfer()'
[ Upstream commit
b1402dcb5643b7a27d46a05edd7491d49ba0e248 ]
If 'dma_map_sg()', we should branch to the existing error handling path
to free some resources before returning.
Link: http://lkml.kernel.org/r/61292a4f369229eee03394247385e955027283f8.1505687047.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Reviewed-by: Logan Gunthorpe <logang@deltatee.com>
Cc: Matt Porter <mporter@kernel.crashing.org>
Cc: Alexandre Bounine <alexandre.bounine@idt.com>
Cc: Lorenzo Stoakes <lstoakes@gmail.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Christian K_nig <christian.koenig@amd.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Thu, 16 Nov 2017 17:39:18 +0000 (17:39 +0000)]
rsi: fix memory leak on buf and usb_reg_buf
[ Upstream commit
d35ef8f846c72d84bfccf239c248c84f79c3a7e8 ]
In the cases where len is too long, the error return path fails to
kfree allocated buffers buf and usb_reg_buf. The simplest fix is to
perform the sanity check on len before the allocations to avoid having
to do the kfree'ing in the first place.
Detected by CoverityScan, CID#1452258,1452259 ("Resource Leak")
Fixes:
59f73e2ae185 ("rsi: check length before USB read/write register")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Fri, 17 Nov 2017 06:27:06 +0000 (14:27 +0800)]
route: update fnhe_expires for redirect when the fnhe exists
[ Upstream commit
e39d5246111399dbc6e11cd39fd8580191b86c47 ]
Now when creating fnhe for redirect, it sets fnhe_expires for this
new route cache. But when updating the exist one, it doesn't do it.
It will cause this fnhe never to be expired.
Paolo already noticed it before, in Jianlin's test case, it became
even worse:
When ip route flush cache, the old fnhe is not to be removed, but
only clean it's members. When redirect comes again, this fnhe will
be found and updated, but never be expired due to fnhe_expires not
being set.
So fix it by simply updating fnhe_expires even it's for redirect.
Fixes:
aee06da6726d ("ipv4: use seqlock for nh_exceptions")
Reported-by: Jianlin Shi <jishi@redhat.com>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Xin Long [Fri, 17 Nov 2017 06:27:18 +0000 (14:27 +0800)]
route: also update fnhe_genid when updating a route cache
[ Upstream commit
cebe84c6190d741045a322f5343f717139993c08 ]
Now when ip route flush cache and it turn out all fnhe_genid != genid.
If a redirect/pmtu icmp packet comes and the old fnhe is found and all
it's members but fnhe_genid will be updated.
Then next time when it looks up route and tries to rebind this fnhe to
the new dst, the fnhe will be flushed due to fnhe_genid != genid. It
causes this redirect/pmtu icmp packet acutally not to be applied.
This patch is to also reset fnhe_genid when updating a route cache.
Fixes:
5aad1de5ea2c ("ipv4: use separate genid for next hop exceptions")
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexey Kodanev [Fri, 17 Nov 2017 16:16:17 +0000 (19:16 +0300)]
gre6: use log_ecn_error module parameter in ip6_tnl_rcv()
[ Upstream commit
981542c526ecd846920bc500e9989da906ee9fb9 ]
After commit
308edfdf1563 ("gre6: Cleanup GREv6 receive path, call
common GRE functions") it's not used anywhere in the module, but
previously was used in ip6gre_rcv().
Fixes:
308edfdf1563 ("gre6: Cleanup GREv6 receive path, call common GRE functions")
Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Hutchings [Fri, 10 Nov 2017 18:48:50 +0000 (18:48 +0000)]
mac80211_hwsim: Fix memory leak in hwsim_new_radio_nl()
[ Upstream commit
67bd52386125ce1159c0581cbcd2740addf33cd4 ]
hwsim_new_radio_nl() now copies the name attribute in order to add a
null-terminator. mac80211_hwsim_new_radio() (indirectly) copies it
again into the net_device structure, so the first copy is not used or
freed later. Free the first copy before returning.
Fixes:
ff4dd73dd2b4 ("mac80211_hwsim: check HWSIM_ATTR_RADIO_NAME length")
Signed-off-by: Ben Hutchings <ben.hutchings@codethink.co.uk>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Hansen [Sat, 11 Nov 2017 00:12:29 +0000 (16:12 -0800)]
x86/mpx/selftests: Fix up weird arrays
[ Upstream commit
a6400120d042397675fcf694060779d21e9e762d ]
The MPX hardware data structurse are defined in a weird way: they define
their size in bytes and then union that with the type with which we want
to access them.
Yes, this is weird, but it does work. But, new GCC's complain that we
are accessing the array out of bounds. Just make it a zero-sized array
so gcc will stop complaining. There was not really a bug here.
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Acked-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20171111001229.58A7933D@viggo.jf.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
John Johansen [Wed, 15 Nov 2017 23:25:30 +0000 (15:25 -0800)]
apparmor: fix leak of null profile name if profile allocation fails
[ Upstream commit
4633307e5ed6128975595df43f796a10c41d11c1 ]
Fixes:
d07881d2edb0 ("apparmor: move new_null_profile to after profile lookup fns()")
Reported-by: Seth Arnold <seth.arnold@canonical.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Madhavan Srinivasan [Wed, 22 Nov 2017 05:15:38 +0000 (10:45 +0530)]
powerpc/perf: Fix pmu_count to count only nest imc pmus
[ Upstream commit
de34787f1096cce38e2590be0013b44418d14546 ]
"pmu_count" in opal_imc_counters_probe() is intended to hold
the number of successful nest imc pmu registerations. But
current code also counts other imc units like core_imc and
thread_imc. Patch add a check to count only nest imc pmus.
Signed-off-by: Madhavan Srinivasan <maddy@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masahiro Yamada [Tue, 14 Nov 2017 11:38:07 +0000 (20:38 +0900)]
coccinelle: fix parallel build with CHECK=scripts/coccicheck
[ Upstream commit
d7059ca0147adcd495f3c5b41f260e1ac55bb679 ]
The command "make -j8 C=1 CHECK=scripts/coccicheck" produces
lots of "coccicheck failed" error messages.
Julia Lawall explained the Coccinelle behavior as follows:
"The problem on the Coccinelle side is that it uses a subdirectory
with the name of the semantic patch to store standard output and
standard error for the different threads. I didn't want to use a
name with the pid, so that one could easily find this information
while Coccinelle is running. Normally the subdirectory is cleaned
up when Coccinelle completes, so there is only one of them at a time.
Maybe it is best to just add the pid. There is the risk that these
subdirectories will accumulate if Coccinelle crashes in a way such
that they don't get cleaned up, but Coccinelle could print a warning
if it detects this case, rather than failing."
When scripts/coccicheck is used as CHECK tool and -j option is given
to Make, the whole of build process runs in parallel. So, multiple
processes try to get access to the same subdirectory.
I notice spatch creates the subdirectory only when it runs in parallel
(i.e. --jobs <N> is given and <N> is greater than 1).
Setting NPROC=1 is a reasonable solution; spatch does not create the
subdirectory. Besides, ONLINE=1 mode takes a single file input for
each spatch invocation, so there is no reason to parallelize it in
the first place.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Julia Lawall <Julia.Lawall@lip6.fr>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Masahiro Yamada [Wed, 15 Nov 2017 09:17:07 +0000 (18:17 +0900)]
kbuild: pkg: use --transform option to prefix paths in tar
[ Upstream commit
2dbc644ac62bbcb9ee78e84719953f611be0413d ]
For rpm-pkg and deb-pkg, a source tar file is created. All paths in
the archive must be prefixed with the base name of the tar so that
everything is contained in the directory when you extract it.
Currently, scripts/package/Makefile uses a symlink for that, and
removes it after the tar is created.
If you terminate the build during the tar creation, the symlink is
left over. Then, at the next package build, you will see a warning
like follows:
ln: '.' and 'kernel-4.14.0+/.' are the same file
It is possible to fix it by adding -n (--no-dereference) option to
the "ln" command, but a cleaner way is to use --transform option
of "tar" command. This option is GNU extension, but it should not
hurt to use it in the Linux build system.
The 'S' flag is needed to exclude symlinks from the path fixup.
Without it, symlinks in the kernel are broken.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ursula Braun [Tue, 21 Nov 2017 12:23:53 +0000 (13:23 +0100)]
net/smc: use sk_rcvbuf as start for rmb creation
[ Upstream commit
4e1061f4a2bba1669c7297455c73ddafbebf2b12 ]
Commit
3e034725c0d8 ("net/smc: common functions for RMBs and send buffers")
merged handling of SMC receive and send buffers. It introduced sk_buf_size
as merged start value for size determination. But since sk_buf_size is not
used at all, sk_sndbuf is erroneously used as start for rmb creation.
This patch makes sure, sk_buf_size is really used as intended, and
sk_rcvbuf is used as start value for rmb creation.
Fixes:
3e034725c0d8 ("net/smc: common functions for RMBs and send buffers")
Signed-off-by: Ursula Braun <ubraun@linux.vnet.ibm.com>
Reviewed-by: Hans Wippel <hwippel@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Fri, 17 Nov 2017 18:35:53 +0000 (18:35 +0000)]
irqchip/qcom: Fix u32 comparison with value less than zero
[ Upstream commit
e9990d70e8a063a7b894c5cbb99f630a0f41200d ]
The comparison of u32 nregs being less than zero is never true since
nregs is unsigned. Fix this by making nregs a signed integer.
Fixes:
f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: kernel-janitors@vger.kernel.org
Cc: Jason Cooper <jason@lakedaemon.net>
Link: https://lkml.kernel.org/r/20171117183553.2739-1-colin.king@canonical.com
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Mon, 27 Nov 2017 11:22:42 +0000 (11:22 +0000)]
ARM: avoid faulting on qemu
commit
3aaf33bebda8d4ffcc0fc8ef39e6c1ac68823b11 upstream.
When qemu starts a kernel in a bare environment, the default SCR has
the AW and FW bits clear, which means that the kernel can't modify
the PSR A or PSR F bits, and means that FIQs and imprecise aborts are
always masked.
When running uboot under qemu, the AW and FW SCR bits are set, and the
kernel functions normally - and this is how real hardware behaves.
Fix this for qemu by ignoring the FIQ bit.
Fixes:
8bafae202c82 ("ARM: BUG if jumping to usermode address in kernel mode")
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Alex Shi <alex.shi@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Russell King [Fri, 24 Nov 2017 23:49:34 +0000 (23:49 +0000)]
ARM: BUG if jumping to usermode address in kernel mode
commit
8bafae202c82dc257f649ea3c275a0f35ee15113 upstream.
Detect if we are returning to usermode via the normal kernel exit paths
but the saved PSR value indicates that we are in kernel mode. This
could occur due to corrupted stack state, which has been observed with
"ftracetest".
This ensures that we catch the problem case before we get to user code.
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Cc: Alex Shi <alex.shi@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
LEROY Christophe [Fri, 6 Oct 2017 13:04:43 +0000 (15:04 +0200)]
crypto: talitos - fix ctr-aes-talitos
commit
70d355ccea899dad47dc22d3a4406998f55143fd upstream.
ctr-aes-talitos test fails as follows on SEC2
[ 0.837427] alg: skcipher: Test 1 failed (invalid result) on encryption for ctr-aes-talitos
[ 0.845763]
00000000: 16 36 d5 ee 34 f8 06 25 d7 7f 8e 56 ca 88 43 45
[ 0.852345]
00000010: f9 3f f7 17 2a b2 12 23 30 43 09 15 82 dd e1 97
[ 0.858940]
00000020: a7 f7 32 b5 eb 25 06 13 9a ec f5 29 25 f8 4d 66
[ 0.865366]
00000030: b0 03 5b 8e aa 9a 42 b6 19 33 8a e2 9d 65 96 95
This patch fixes the descriptor type which is special for CTR AES
Fixes:
5e75ae1b3cef6 ("crypto: talitos - add new crypto modes")
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
LEROY Christophe [Fri, 6 Oct 2017 13:04:41 +0000 (15:04 +0200)]
crypto: talitos - fix use of sg_link_tbl_len
commit
fbb22137c4d9bab536958b152d096fb3f98020ea upstream.
sg_link_tbl_len shall be used instead of cryptlen, otherwise
SECs which perform HW CICV verification will fail.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
LEROY Christophe [Fri, 6 Oct 2017 13:04:39 +0000 (15:04 +0200)]
crypto: talitos - fix AEAD for sha224 on non sha224 capable chips
commit
6cda075aff67a1b9b5ba1b2818091dc939643b6c upstream.
sha224 AEAD test fails with:
[ 2.803125] talitos
ff020000.crypto: DEUISR 0x00000000_00000000
[ 2.808743] talitos
ff020000.crypto: MDEUISR 0x80100000_00000000
[ 2.814678] talitos
ff020000.crypto: DESCBUF 0x20731f21_00000018
[ 2.820616] talitos
ff020000.crypto: DESCBUF 0x0628d64c_00000010
[ 2.826554] talitos
ff020000.crypto: DESCBUF 0x0631005c_00000018
[ 2.832492] talitos
ff020000.crypto: DESCBUF 0x0628d664_00000008
[ 2.838430] talitos
ff020000.crypto: DESCBUF 0x061b13a0_00000080
[ 2.844369] talitos
ff020000.crypto: DESCBUF 0x0631006c_00000080
[ 2.850307] talitos
ff020000.crypto: DESCBUF 0x0631006c_00000018
[ 2.856245] talitos
ff020000.crypto: DESCBUF 0x063100ec_00000000
[ 2.884972] talitos
ff020000.crypto: failed to reset channel 0
[ 2.890503] talitos
ff020000.crypto: done overflow, internal time out, or rngu error: ISR 0x20000000_00020000
[ 2.900652] alg: aead: encryption failed on test 1 for authenc-hmac-sha224-cbc-3des-talitos: ret=22
This is due to SHA224 not being supported by the HW. Allthough for
hash we are able to init the hash context by SW, it is not
possible for AEAD. Therefore SHA224 AEAD has to be deactivated.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
LEROY Christophe [Fri, 6 Oct 2017 13:04:37 +0000 (15:04 +0200)]
crypto: talitos - fix setkey to check key weakness
commit
f384cdc4faf350fdb6ad93c5f26952b9ba7c7566 upstream.
Crypto manager test report the following failures:
[ 3.061081] alg: skcipher: setkey failed on test 5 for ecb-des-talitos: flags=100
[ 3.069342] alg: skcipher-ddst: setkey failed on test 5 for ecb-des-talitos: flags=100
[ 3.077754] alg: skcipher-ddst: setkey failed on test 5 for ecb-des-talitos: flags=100
This is due to setkey being expected to detect weak keys.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
LEROY Christophe [Fri, 6 Oct 2017 13:04:35 +0000 (15:04 +0200)]
crypto: talitos - fix memory corruption on SEC2
commit
e04a61bebc5da1535b6f194b464295b8d558e2fc upstream.
On SEC2, when using the old descriptors type (hmac snoop no afeu)
for doing IPsec, the CICV out pointeur points out of the allocated
memory.
[ 2.502554] =============================================================================
[ 2.510740] BUG dma-kmalloc-256 (Not tainted): Redzone overwritten
[ 2.516907] -----------------------------------------------------------------------------
[ 2.516907]
[ 2.526535] Disabling lock debugging due to kernel taint
[ 2.531845] INFO: 0xde858108-0xde85810b. First byte 0xf8 instead of 0xcc
[ 2.538549] INFO: Allocated in 0x806181a9 age=0 cpu=0 pid=58
[ 2.544229] __kmalloc+0x374/0x564
[ 2.547649] talitos_edesc_alloc+0x17c/0x48c
[ 2.551929] aead_edesc_alloc+0x80/0x154
[ 2.555863] aead_encrypt+0x30/0xe0
[ 2.559368] __test_aead+0x5a0/0x1f3c
[ 2.563042] test_aead+0x2c/0x110
[ 2.566371] alg_test_aead+0x5c/0xf4
[ 2.569958] alg_test+0x1dc/0x5a0
[ 2.573305] cryptomgr_test+0x50/0x70
[ 2.576984] kthread+0xd8/0x134
[ 2.580155] ret_from_kernel_thread+0x5c/0x64
[ 2.584534] INFO: Freed in ipsec_esp_encrypt_done+0x130/0x240 age=6 cpu=0 pid=0
[ 2.591839] ipsec_esp_encrypt_done+0x130/0x240
[ 2.596395] flush_channel+0x1dc/0x488
[ 2.600161] talitos2_done_4ch+0x30/0x200
[ 2.604185] tasklet_action+0xa0/0x13c
[ 2.607948] __do_softirq+0x148/0x6cc
[ 2.611623] irq_exit+0xc0/0x124
[ 2.614869] call_do_irq+0x24/0x3c
[ 2.618292] do_IRQ+0x78/0x108
[ 2.621369] ret_from_except+0x0/0x14
[ 2.625055] finish_task_switch+0x58/0x350
[ 2.629165] schedule+0x80/0x134
[ 2.632409] schedule_preempt_disabled+0x38/0xc8
[ 2.637042] cpu_startup_entry+0xe4/0x190
[ 2.641074] start_kernel+0x3f4/0x408
[ 2.644741] 0x3438
[ 2.646857] INFO: Slab 0xdffbdb00 objects=9 used=1 fp=0xde8581c0 flags=0x0080
[ 2.653978] INFO: Object 0xde858008 @offset=8 fp=0xca4395df
[ 2.653978]
[ 2.661032] Redzone
de858000: cc cc cc cc cc cc cc cc ........
[ 2.669029] Object
de858008: 00 00 00 02 00 00 00 02 00 6b 6b 6b 1e 83 ea 28 .........kkk...(
[ 2.677628] Object
de858018: 00 00 00 70 1e 85 80 64 ff 73 1d 21 6b 6b 6b 6b ...p...d.s.!kkkk
[ 2.686228] Object
de858028: 00 20 00 00 1e 84 17 24 00 10 00 00 1e 85 70 00 . .....$......p.
[ 2.694829] Object
de858038: 00 18 00 00 1e 84 17 44 00 08 00 00 1e 83 ea 28 .......D.......(
[ 2.703430] Object
de858048: 00 80 00 00 1e 84 f0 00 00 80 00 00 1e 85 70 10 ..............p.
[ 2.712030] Object
de858058: 00 20 6b 00 1e 85 80 f4 6b 6b 6b 6b 00 80 02 00 . k.....kkkk....
[ 2.720629] Object
de858068: 1e 84 f0 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
[ 2.729230] Object
de858078: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 2.737830] Object
de858088: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 2.746429] Object
de858098: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 2.755029] Object
de8580a8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 2.763628] Object
de8580b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 2.772229] Object
de8580c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 2.780829] Object
de8580d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
[ 2.789430] Object
de8580e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 73 b0 ea 9f kkkkkkkkkkkks...
[ 2.798030] Object
de8580f8: e8 18 80 d6 56 38 44 c0 db e3 4f 71 f7 ce d1 d3 ....V8D...Oq....
[ 2.806629] Redzone
de858108: f8 bd 3e 4f ..>O
[ 2.814279] Padding
de8581b0: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
[ 2.822283] CPU: 0 PID: 0 Comm: swapper Tainted: G B 4.9.50-g995be12679 #179
[ 2.831819] Call Trace:
[ 2.834301] [
dffefd20] [
c01aa9a8] check_bytes_and_report+0x100/0x194 (unreliable)
[ 2.841801] [
dffefd50] [
c01aac3c] check_object+0x200/0x530
[ 2.847306] [
dffefd80] [
c01ae584] free_debug_processing+0x290/0x690
[ 2.853585] [
dffefde0] [
c01aec8c] __slab_free+0x308/0x628
[ 2.859000] [
dffefe80] [
c05057f4] ipsec_esp_encrypt_done+0x130/0x240
[ 2.865378] [
dffefeb0] [
c05002c4] flush_channel+0x1dc/0x488
[ 2.870968] [
dffeff10] [
c05007a8] talitos2_done_4ch+0x30/0x200
[ 2.876814] [
dffeff30] [
c002fe38] tasklet_action+0xa0/0x13c
[ 2.882399] [
dffeff60] [
c002f118] __do_softirq+0x148/0x6cc
[ 2.887896] [
dffeffd0] [
c002f954] irq_exit+0xc0/0x124
[ 2.892968] [
dffefff0] [
c0013adc] call_do_irq+0x24/0x3c
[ 2.898213] [
c0d4be00] [
c000757c] do_IRQ+0x78/0x108
[ 2.903113] [
c0d4be30] [
c0015c08] ret_from_except+0x0/0x14
[ 2.908634] --- interrupt: 501 at finish_task_switch+0x70/0x350
[ 2.908634] LR = finish_task_switch+0x58/0x350
[ 2.919327] [
c0d4bf20] [
c085e1d4] schedule+0x80/0x134
[ 2.924398] [
c0d4bf50] [
c085e2c0] schedule_preempt_disabled+0x38/0xc8
[ 2.930853] [
c0d4bf60] [
c007f064] cpu_startup_entry+0xe4/0x190
[ 2.936707] [
c0d4bfb0] [
c096c434] start_kernel+0x3f4/0x408
[ 2.942198] [
c0d4bff0] [
00003438] 0x3438
[ 2.946137] FIX dma-kmalloc-256: Restoring 0xde858108-0xde85810b=0xcc
[ 2.946137]
[ 2.954158] FIX dma-kmalloc-256: Object at 0xde858008 not freed
This patch reworks the handling of the CICV out in order
to properly handle all cases.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
LEROY Christophe [Fri, 6 Oct 2017 13:04:33 +0000 (15:04 +0200)]
crypto: talitos - fix AEAD test failures
commit
ec8c7d14acc0a477429d3a6fade5dab72c996c82 upstream.
AEAD tests fail when destination SG list has more than 1 element.
[ 2.058752] alg: aead: Test 1 failed on encryption for authenc-hmac-sha1-cbc-aes-talitos
[ 2.066965]
00000000: 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67
00000010: c0 43 ff 74 c0 43 ff e0 de 83 d1 20 de 84 8e 54
00000020: de 83 d7 c4
[ 2.082138] alg: aead: Test 1 failed on encryption for authenc-hmac-sha1-cbc-aes-talitos
[ 2.090435]
00000000: 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67
00000010: de 84 ea 58 c0 93 1a 24 de 84 e8 59 de 84 f1 20
00000020: 00 00 00 00
[ 2.105721] alg: aead: Test 1 failed on encryption for authenc-hmac-sha1-cbc-3des-talitos
[ 2.114259]
00000000: 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72 73 74
00000010: 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63 74 65
00000020: 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72
00000030: 73 74 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63
00000040: 74 65 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65
00000050: 65 72 73 74 54 20 6f 6f 4d 20 6e 61 20 79 65 53
00000060: 72 63 74 65 20 73 6f 54 20 6f 61 4d 79 6e 53 20
00000070: 63 65 65 72 73 74 54 20 6f 6f 4d 20 6e 61 0a 79
00000080: c0 50 f1 ac c0 50 f3 38 c0 50 f3 94 c0 50 f5 30
00000090: c0 99 74 3c
[ 2.166410] alg: aead: Test 1 failed on encryption for authenc-hmac-sha1-cbc-3des-talitos
[ 2.174794]
00000000: 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72 73 74
00000010: 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63 74 65
00000020: 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72
00000030: 73 74 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63
00000040: 74 65 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65
00000050: 65 72 73 74 54 20 6f 6f 4d 20 6e 61 20 79 65 53
00000060: 72 63 74 65 20 73 6f 54 20 6f 61 4d 79 6e 53 20
00000070: 63 65 65 72 73 74 54 20 6f 6f 4d 20 6e 61 0a 79
00000080: c0 50 f1 ac c0 50 f3 38 c0 50 f3 94 c0 50 f5 30
00000090: c0 99 74 3c
[ 2.226486] alg: No test for authenc(hmac(sha224),cbc(aes)) (authenc-hmac-sha224-cbc-aes-talitos)
[ 2.236459] alg: No test for authenc(hmac(sha224),cbc(aes)) (authenc-hmac-sha224-cbc-aes-talitos)
[ 2.247196] alg: aead: Test 1 failed on encryption for authenc-hmac-sha224-cbc-3des-talitos
[ 2.255555]
00000000: 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72 73 74
00000010: 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63 74 65
00000020: 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72
00000030: 73 74 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63
00000040: 74 65 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65
00000050: 65 72 73 74 54 20 6f 6f 4d 20 6e 61 20 79 65 53
00000060: 72 63 74 65 20 73 6f 54 20 6f 61 4d 79 6e 53 20
00000070: 63 65 65 72 73 74 54 20 6f 6f 4d 20 6e 61 0a 79
00000080: c0 50 f1 ac c0 50 f3 38 c0 50 f3 94 c0 50 f5 30
00000090: c0 99 74 3c c0 96 e5 b8
[ 2.309004] alg: aead: Test 1 failed on encryption for authenc-hmac-sha224-cbc-3des-talitos
[ 2.317562]
00000000: 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72 73 74
00000010: 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63 74 65
00000020: 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72
00000030: 73 74 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63
00000040: 74 65 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65
00000050: 65 72 73 74 54 20 6f 6f 4d 20 6e 61 20 79 65 53
00000060: 72 63 74 65 20 73 6f 54 20 6f 61 4d 79 6e 53 20
00000070: 63 65 65 72 73 74 54 20 6f 6f 4d 20 6e 61 0a 79
00000080: c0 50 f1 ac c0 50 f3 38 c0 50 f3 94 c0 50 f5 30
00000090: c0 99 74 3c c0 96 e5 b8
[ 2.370710] alg: aead: Test 1 failed on encryption for authenc-hmac-sha256-cbc-aes-talitos
[ 2.379177]
00000000: 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67
00000010: 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63 74 65
00000020: 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72
[ 2.397863] alg: aead: Test 1 failed on encryption for authenc-hmac-sha256-cbc-aes-talitos
[ 2.406134]
00000000: 53 69 6e 67 6c 65 20 62 6c 6f 63 6b 20 6d 73 67
00000010: 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63 74 65
00000020: 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72
[ 2.424789] alg: aead: Test 1 failed on encryption for authenc-hmac-sha256-cbc-3des-talitos
[ 2.433491]
00000000: 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72 73 74
00000010: 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63 74 65
00000020: 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72
00000030: 73 74 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63
00000040: 74 65 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65
00000050: 65 72 73 74 54 20 6f 6f 4d 20 6e 61 20 79 65 53
00000060: 72 63 74 65 20 73 6f 54 20 6f 61 4d 79 6e 53 20
00000070: 63 65 65 72 73 74 54 20 6f 6f 4d 20 6e 61 0a 79
00000080: c0 50 f1 ac c0 50 f3 38 c0 50 f3 94 c0 50 f5 30
00000090: c0 99 74 3c c0 96 e5 b8 c0 96 e9 20 c0 00 3d dc
[ 2.488832] alg: aead: Test 1 failed on encryption for authenc-hmac-sha256-cbc-3des-talitos
[ 2.497387]
00000000: 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72 73 74
00000010: 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63 74 65
00000020: 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65 65 72
00000030: 73 74 54 20 6f 6f 4d 20 6e 61 20 79 65 53 72 63
00000040: 74 65 20 73 6f 54 20 6f 61 4d 79 6e 53 20 63 65
00000050: 65 72 73 74 54 20 6f 6f 4d 20 6e 61 20 79 65 53
00000060: 72 63 74 65 20 73 6f 54 20 6f 61 4d 79 6e 53 20
00000070: 63 65 65 72 73 74 54 20 6f 6f 4d 20 6e 61 0a 79
00000080: c0 50 f1 ac c0 50 f3 38 c0 50 f3 94 c0 50 f5 30
00000090: c0 99 74 3c c0 96 e5 b8 c0 96 e9 20 c0 00 3d dc
This patch fixes that.
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Jurgens [Wed, 29 Nov 2017 18:10:39 +0000 (20:10 +0200)]
IB/core: Only enforce security for InfiniBand
commit
315d160c5a4e034a576a13aa21e7235d5c9ec609 upstream.
For now the only LSM security enforcement mechanism available is
specific to InfiniBand. Bypass enforcement for non-IB link types.
This fixes a regression where modify_qp fails for iWARP because
querying the PKEY returns -EINVAL.
Cc: Paul Moore <paul@paul-moore.com>
Cc: Don Dutile <ddutile@redhat.com>
Reported-by: Potnuri Bharat Teja <bharat@chelsio.com>
Fixes:
d291f1a65232("IB/core: Enforce PKey security on QPs")
Fixes:
47a2b338fe63("IB/core: Enforce security on management datagrams")
Signed-off-by: Daniel Jurgens <danielj@mellanox.com>
Reviewed-by: Parav Pandit <parav@mellanox.com>
Tested-by: Potnuri Bharat Teja <bharat@chelsio.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Parav Pandit [Thu, 2 Nov 2017 13:22:27 +0000 (15:22 +0200)]
IB/core: Avoid unnecessary return value check
commit
2e4c85c6edc80fa532b2c7e1eb3597ef4d4bbb8f upstream.
Since there is nothing done with non zero return value, such check is
avoided.
Signed-off-by: Parav Pandit <parav@mellanox.com>
Reviewed-by: Daniel Jurgens <danielj@mellanox.com>
Signed-off-by: Leon Romanovsky <leon@kernel.org>
Signed-off-by: Doug Ledford <dledford@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kim Phillips [Wed, 11 Oct 2017 21:33:24 +0000 (22:33 +0100)]
bus: arm-ccn: fix module unloading Error: Removing state 147 which has instances left.
commit
b69f63ebf553504739cc8534cbed31bd530c6f0b upstream.
Unregistering the driver before calling cpuhp_remove_multi_state() removes
any remaining hotplug cpu instances so __cpuhp_remove_state_cpuslocked()
doesn't emit this warning:
[ 268.748362] Error: Removing state 147 which has instances left.
[ 268.748373] ------------[ cut here ]------------
[ 268.748386] WARNING: CPU: 2 PID: 5476 at kernel/cpu.c:1734 __cpuhp_remove_state_cpuslocked+0x454/0x4f0
[ 268.748389] Modules linked in: arm_ccn(-) [last unloaded: arm_ccn]
[ 268.748403] CPU: 2 PID: 5476 Comm: rmmod Tainted: G W 4.14.0-rc4+ #3
[ 268.748406] Hardware name: AMD Seattle/Seattle, BIOS 10:18:39 Dec 8 2016
[ 268.748410] task:
ffff8001a18ca000 task.stack:
ffff80019c120000
[ 268.748416] PC is at __cpuhp_remove_state_cpuslocked+0x454/0x4f0
[ 268.748421] LR is at __cpuhp_remove_state_cpuslocked+0x448/0x4f0
[ 268.748425] pc : [<
ffff2000081729ec>] lr : [<
ffff2000081729e0>] pstate:
60000145
[ 268.748427] sp :
ffff80019c127d30
[ 268.748430] x29:
ffff80019c127d30 x28:
ffff8001a18ca000
[ 268.748437] x27:
ffff20000c2cb000 x26:
1fffe4000042d490
[ 268.748443] x25:
ffff20000216a480 x24:
0000000000000000
[ 268.748449] x23:
ffff20000b08e000 x22:
0000000000000001
[ 268.748455] x21:
0000000000000093 x20:
00000000000016f8
[ 268.748460] x19:
ffff20000c2cbb80 x18:
0000ffffb5fe7c58
[ 268.748466] x17:
00000000004402d0 x16:
1fffe40001864f01
[ 268.748472] x15:
ffff20000c4bf8b0 x14:
0000000000000000
[ 268.748477] x13:
0000000000007032 x12:
ffff20000829ae48
[ 268.748483] x11:
ffff20000c4bf000 x10:
0000000000000004
[ 268.748488] x9 :
0000000000006fbc x8 :
ffff20000c318a40
[ 268.748494] x7 :
0000000000000000 x6 :
ffff040001864f02
[ 268.748500] x5 :
0000000000000000 x4 :
0000000000000000
[ 268.748505] x3 :
0000000000000007 x2 :
dfff200000000000
[ 268.748510] x1 :
000000000000ad3d x0 :
00000000000001f0
[ 268.748516] Call trace:
[ 268.748521] Exception stack(0xffff80019c127bf0 to 0xffff80019c127d30)
[ 268.748526] 7be0:
00000000000001f0 000000000000ad3d
[ 268.748531] 7c00:
dfff200000000000 0000000000000007 0000000000000000 0000000000000000
[ 268.748535] 7c20:
ffff040001864f02 0000000000000000 ffff20000c318a40 0000000000006fbc
[ 268.748539] 7c40:
0000000000000004 ffff20000c4bf000 ffff20000829ae48 0000000000007032
[ 268.748544] 7c60:
0000000000000000 ffff20000c4bf8b0 1fffe40001864f01 00000000004402d0
[ 268.748548] 7c80:
0000ffffb5fe7c58 ffff20000c2cbb80 00000000000016f8 0000000000000093
[ 268.748553] 7ca0:
0000000000000001 ffff20000b08e000 0000000000000000 ffff20000216a480
[ 268.748557] 7cc0:
1fffe4000042d490 ffff20000c2cb000 ffff8001a18ca000 ffff80019c127d30
[ 268.748562] 7ce0:
ffff2000081729e0 ffff80019c127d30 ffff2000081729ec 0000000060000145
[ 268.748566] 7d00:
00000000000001f0 0000000000000000 0001000000000000 0000000000000000
[ 268.748569] 7d20:
ffff80019c127d30 ffff2000081729ec
[ 268.748575] [<
ffff2000081729ec>] __cpuhp_remove_state_cpuslocked+0x454/0x4f0
[ 268.748580] [<
ffff200008172adc>] __cpuhp_remove_state+0x54/0x80
[ 268.748597] [<
ffff20000215dd84>] arm_ccn_exit+0x2c/0x70 [arm_ccn]
[ 268.748604] [<
ffff20000834cfbc>] SyS_delete_module+0x5a4/0x708
[ 268.748607] Exception stack(0xffff80019c127ec0 to 0xffff80019c128000)
[ 268.748612] 7ec0:
0000000019bb7258 0000000000000800 ba64d0fb3d26a800 00000000000000da
[ 268.748616] 7ee0:
0000ffffb6144e28 0000ffffcd95b409 fefefefefefefeff 7f7f7f7f7f7f7f7f
[ 268.748621] 7f00:
000000000000006a 1999999999999999 0000ffffb6179000 0000000000bbcc6d
[ 268.748625] 7f20:
0000ffffb6176b98 0000ffffcd95c2d0 0000ffffb5fe7b58 0000ffffb6163000
[ 268.748630] 7f40:
0000ffffb60ad3e0 00000000004402d0 0000ffffb5fe7c58 0000000019bb71f0
[ 268.748634] 7f60:
0000ffffcd95c740 0000000000000000 0000000019bb71f0 0000000000416700
[ 268.748639] 7f80:
0000000000000000 00000000004402e8 0000000019bb6010 0000ffffcd95c748
[ 268.748643] 7fa0:
0000000000000000 0000ffffcd95c460 00000000004113a8 0000ffffcd95c460
[ 268.748648] 7fc0:
0000ffffb60ad3e8 0000000080000000 0000000019bb7258 000000000000006a
[ 268.748652] 7fe0:
0000000000000000 0000000000000000 0000000000000000 0000000000000000
[ 268.748657] [<
ffff200008084f9c>] __sys_trace_return+0x0/0x4
[ 268.748661] ---[ end trace
a996d358dcaa7f9c ]---
Fixes:
8df038725ad5 ("bus/arm-ccn: Use cpu-hp's multi instance support instead custom list")
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Tue, 3 Oct 2017 17:14:12 +0000 (18:14 +0100)]
bus: arm-ccn: Fix use of smp_processor_id() in preemptible context
commit
b18c2b9487d8e797fc0a757e57ac3645348c5fba upstream.
Booting a DEBUG_PREEMPT enabled kernel on a CCN-based system
results in the following splat:
[...]
arm-ccn
e8000000.ccn: No access to interrupts, using timer.
BUG: using smp_processor_id() in preemptible [
00000000] code: swapper/0/1
caller is debug_smp_processor_id+0x1c/0x28
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0 #6111
Hardware name: AMD Seattle/Seattle, BIOS 17:08:23 Jun 26 2017
Call trace:
[<
ffff000008089e78>] dump_backtrace+0x0/0x278
[<
ffff00000808a22c>] show_stack+0x24/0x30
[<
ffff000008bc3bc4>] dump_stack+0x8c/0xb0
[<
ffff00000852b534>] check_preemption_disabled+0xfc/0x100
[<
ffff00000852b554>] debug_smp_processor_id+0x1c/0x28
[<
ffff000008551bd8>] arm_ccn_probe+0x358/0x4f0
[...]
as we use smp_processor_id() in the wrong context.
Turn this into a get_cpu()/put_cpu() that extends over the CPU hotplug
registration, making sure that we don't race against a CPU down operation.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christophe JAILLET [Sun, 27 Aug 2017 10:06:50 +0000 (11:06 +0100)]
bus: arm-ccn: Check memory allocation failure
commit
24771179c5c138f0ea3ef88b7972979f62f2d5db upstream.
Check memory allocation failures and return -ENOMEM in such cases
This avoids a potential NULL pointer dereference.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Tue, 3 Oct 2017 17:14:13 +0000 (18:14 +0100)]
bus: arm-cci: Fix use of smp_processor_id() in preemptible context
commit
4608af8aa53e7f3922ddee695d023b7bcd5cb35b upstream.
The ARM CCI driver seem to be using smp_processor_id() in a
preemptible context, which is likely to make a DEBUG_PREMPT
kernel scream at boot time.
Turn this into a get_cpu()/put_cpu() that extends over the CPU
hotplug registration, making sure that we don't race against
a CPU down operation.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fabio Estevam [Wed, 15 Nov 2017 12:03:53 +0000 (10:03 -0200)]
Revert "ARM: dts: imx53: add srtc node"
commit
e501506d3ea00eefa64463ebd9e5c13ee70990bd upstream.
This reverts commit
5b725054147deaf966b3919e10a86c6bfe946a18.
The rtc block on i.MX53 is a completely different hardware than the
one found on i.MX25.
Reported-by: Noel Vellemans <Noel.Vellemans@visionbms.com>
Suggested-by: Juergen Borleis <jbe@pengutronix.de>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Wed, 6 Dec 2017 10:51:12 +0000 (10:51 +0000)]
arm64: SW PAN: Update saved ttbr0 value on enter_lazy_tlb
commit
d96cc49bff5a7735576cc6f6f111f875d101cec8 upstream.
enter_lazy_tlb is called when a kernel thread rides on the back of
another mm, due to a context switch or an explicit call to unuse_mm
where a call to switch_mm is elided.
In these cases, it's important to keep the saved ttbr value up to date
with the active mm, otherwise we can end up with a stale value which
points to a potentially freed page table.
This patch implements enter_lazy_tlb for arm64, so that the saved ttbr0
is kept up-to-date with the active mm for kernel threads.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Vinayak Menon <vinmenon@codeaurora.org>
Fixes:
39bc88e5e38e9b21 ("arm64: Disable TTBR0_EL1 during normal kernel execution")
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Wed, 6 Dec 2017 10:42:10 +0000 (10:42 +0000)]
arm64: SW PAN: Point saved ttbr0 at the zero page when switching to init_mm
commit
0adbdfde8cfc9415aeed2a4955d2d17b3bd9bf13 upstream.
update_saved_ttbr0 mandates that mm->pgd is not swapper, since swapper
contains kernel mappings and should never be installed into ttbr0. However,
this means that callers must avoid passing the init_mm to update_saved_ttbr0
which in turn can cause the saved ttbr0 value to be out-of-date in the context
of the idle thread. For example, EFI runtime services may leave the saved ttbr0
pointing at the EFI page table, and kernel threads may end up with stale
references to freed page tables.
This patch changes update_saved_ttbr0 so that the init_mm points the saved
ttbr0 value to the empty zero page, which always exists and never contains
valid translations. EFI and switch can then call into update_saved_ttbr0
unconditionally.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Vinayak Menon <vinmenon@codeaurora.org>
Fixes:
39bc88e5e38e9b21 ("arm64: Disable TTBR0_EL1 during normal kernel execution")
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Vinayak Menon <vinmenon@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dave Martin [Tue, 5 Dec 2017 14:56:42 +0000 (14:56 +0000)]
arm64: fpsimd: Prevent registers leaking from dead tasks
commit
071b6d4a5d343046f253a5a8835d477d93992002 upstream.
Currently, loading of a task's fpsimd state into the CPU registers
is skipped if that task's state is already present in the registers
of that CPU.
However, the code relies on the struct fpsimd_state * (and by
extension struct task_struct *) to unambiguously identify a task.
There is a particular case in which this doesn't work reliably:
when a task exits, its task_struct may be recycled to describe a
new task.
Consider the following scenario:
1) Task P loads its fpsimd state onto cpu C.
per_cpu(fpsimd_last_state, C) := P;
P->thread.fpsimd_state.cpu := C;
2) Task X is scheduled onto C and loads its fpsimd state on C.
per_cpu(fpsimd_last_state, C) := X;
X->thread.fpsimd_state.cpu := C;
3) X exits, causing X's task_struct to be freed.
4) P forks a new child T, which obtains X's recycled task_struct.
T == X.
T->thread.fpsimd_state.cpu == C (inherited from P).
5) T is scheduled on C.
T's fpsimd state is not loaded, because
per_cpu(fpsimd_last_state, C) == T (== X) &&
T->thread.fpsimd_state.cpu == C.
(This is the check performed by fpsimd_thread_switch().)
So, T gets X's registers because the last registers loaded onto C
were those of X, in (2).
This patch fixes the problem by ensuring that the sched-in check
fails in (5): fpsimd_flush_task_state(T) is called when T is
forked, so that T->thread.fpsimd_state.cpu == C cannot be true.
This relies on the fact that T is not schedulable until after
copy_thread() completes.
Once T's fpsimd state has been loaded on some CPU C there may still
be other cpus D for which per_cpu(fpsimd_last_state, D) ==
&X->thread.fpsimd_state. But D is necessarily != C in this case,
and the check in (5) must fail.
An alternative fix would be to do refcounting on task_struct. This
would result in each CPU holding a reference to the last task whose
fpsimd state was loaded there. It's not clear whether this is
preferable, and it involves higher overhead than the fix proposed
in this patch. It would also move all the task_struct freeing
work into the context switch critical section, or otherwise some
deferred cleanup mechanism would need to be introduced, neither of
which seems obviously justified.
Fixes:
005f78cd8849 ("arm64: defer reloading a task's FPSIMD state to userland resume")
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[will: word-smithed the comment so it makes more sense]
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Thu, 16 Nov 2017 17:58:18 +0000 (17:58 +0000)]
KVM: arm/arm64: vgic-its: Check result of allocation before use
commit
686f294f2f1ae40705283dd413ca1e4c14f20f93 upstream.
We miss a test against NULL after allocation.
Fixes:
6d03a68f8054 ("KVM: arm64: vgic-its: Turn device_id validation into generic ID validation")
Reported-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Thu, 16 Nov 2017 17:58:16 +0000 (17:58 +0000)]
KVM: arm/arm64: vgic: Preserve the revious read from the pending table
commit
ddb4b0102cb9cdd2398d98b3e1e024e08a2f4239 upstream.
The current pending table parsing code assumes that we keep the
previous read of the pending bits, but keep that variable in
the current block, making sure it is discarded on each loop.
We end-up using whatever is on the stack. Who knows, it might
just be the right thing...
Fixes:
280771252c1ba ("KVM: arm64: vgic-v3: KVM_DEV_ARM_VGIC_SAVE_PENDING_TABLES")
Reported-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Thu, 16 Nov 2017 17:58:15 +0000 (17:58 +0000)]
KVM: arm/arm64: vgic-irqfd: Fix MSI entry allocation
commit
150009e2c70cc3c6e97f00e7595055765d32fb85 upstream.
Using the size of the structure we're allocating is a good idea
and avoids any surprise... In this case, we're happilly confusing
kvm_kernel_irq_routing_entry and kvm_irq_routing_entry...
Fixes:
95b110ab9a09 ("KVM: arm/arm64: Enable irqchip routing")
Reported-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christoffer Dall [Sun, 3 Dec 2017 22:54:41 +0000 (23:54 +0100)]
KVM: arm/arm64: Fix broken GICH_ELRSR big endian conversion
commit
fc396e066318c0a02208c1d3f0b62950a7714999 upstream.
We are incorrectly rearranging 32-bit words inside a 64-bit typed value
for big endian systems, which would result in never marking a virtual
interrupt as inactive on big endian systems (assuming 32 or fewer LRs on
the hardware). Fix this by not doing any word order manipulation for
the typed values.
Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrew Honig [Fri, 1 Dec 2017 18:21:09 +0000 (10:21 -0800)]
KVM: VMX: remove I/O port 0x80 bypass on Intel hosts
commit
d59d51f088014f25c2562de59b9abff4f42a7468 upstream.
This fixes CVE-2017-1000407.
KVM allows guests to directly access I/O port 0x80 on Intel hosts. If
the guest floods this port with writes it generates exceptions and
instability in the host kernel, leading to a crash. With this change
guest writes to port 0x80 on Intel will behave the same as they
currently behave on AMD systems.
Prevent the flooding by removing the code that sets port 0x80 as a
passthrough port. This is essentially the same as upstream patch
99f85a28a78e96d28907fe036e1671a218fee597, except that patch was
for AMD chipsets and this patch is for Intel.
Signed-off-by: Andrew Honig <ahonig@google.com>
Signed-off-by: Jim Mattson <jmattson@google.com>
Fixes:
fdef3ad1b386 ("KVM: VMX: Enable io bitmaps to avoid IO port 0x80 VMEXITs")
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Zyngier [Thu, 16 Nov 2017 17:58:21 +0000 (17:58 +0000)]
arm: KVM: Fix VTTBR_BADDR_MASK BUG_ON off-by-one
commit
5553b142be11e794ebc0805950b2e8313f93d718 upstream.
VTTBR_BADDR_MASK is used to sanity check the size and alignment of the
VTTBR address. It seems to currently be off by one, thereby only
allowing up to 39-bit addresses (instead of 40-bit) and also
insufficiently checking the alignment. This patch fixes it.
This patch is the 32bit pendent of Kristina's arm64 fix, and
she deserves the actual kudos for pinpointing that one.
Fixes:
f7ed45be3ba52 ("KVM: ARM: World-switch implementation")
Reported-by: Kristina Martsenko <kristina.martsenko@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kristina Martsenko [Thu, 16 Nov 2017 17:58:20 +0000 (17:58 +0000)]
arm64: KVM: fix VTTBR_BADDR_MASK BUG_ON off-by-one
commit
26aa7b3b1c0fb3f1a6176a0c1847204ef4355693 upstream.
VTTBR_BADDR_MASK is used to sanity check the size and alignment of the
VTTBR address. It seems to currently be off by one, thereby only
allowing up to 47-bit addresses (instead of 48-bit) and also
insufficiently checking the alignment. This patch fixes it.
As an example, with 4k pages, before this patch we have:
PHYS_MASK_SHIFT = 48
VTTBR_X = 37 - 24 = 13
VTTBR_BADDR_SHIFT = 13 - 1 = 12
VTTBR_BADDR_MASK = ((1 << 35) - 1) << 12 = 0x00007ffffffff000
Which is wrong, because the mask doesn't allow bit 47 of the VTTBR
address to be set, and only requires the address to be 12-bit (4k)
aligned, while it actually needs to be 13-bit (8k) aligned because we
concatenate two 4k tables.
With this patch, the mask becomes 0x0000ffffffffe000, which is what we
want.
Fixes:
0369f6a34b9f ("arm64: KVM: EL2 register definitions")
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Kristina Martsenko <kristina.martsenko@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sean Young [Sun, 19 Nov 2017 21:57:27 +0000 (16:57 -0500)]
media: rc: partial revert of "media: rc: per-protocol repeat period"
commit
67f0f15ad5c47490e19f2526f8f9cea97c5ce1a6 upstream.
Since commit
d57ea877af38 ("media: rc: per-protocol repeat period"), most
IR protocols have a lower keyup timeout. This causes problems on the
ite-cir, which has default IR timeout of 200ms.
Since the IR decoders read the trailing space, with a IR timeout of 200ms,
the last keydown will have at least a delay of 200ms. This is more than
the protocol timeout of e.g. rc-6 (which is 164ms). As a result the last
IR will be interpreted as a new keydown event, and we get two keypresses.
Revert the protocol timeout to 250ms, except for cec which needs a timeout
of 550ms.
Fixes:
d57ea877af38 ("media: rc: per-protocol repeat period")
Reported-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Sean Young <sean@mess.org>
Tested-by: Matthias Reichl <hias@horus.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sean Young [Wed, 8 Nov 2017 21:19:45 +0000 (16:19 -0500)]
media: rc: sir_ir: detect presence of port
commit
30b4e122d71cbec2944a5f8b558b88936ee42f10 upstream.
Without this test, sir_ir clumsy claims resources for a device which
does not exist.
The 0-day kernel test robot reports the following errors (in a loop):
sir_ir sir_ir.0: Trapped in interrupt
genirq: Flags mismatch irq 4.
00000000 (ttyS0) vs.
00000000 (sir_ir)
When sir_ir is loaded with the default io and irq, the following happens:
- sir_ir claims irq 4
- user space opens /dev/ttyS0
- in serial8250_do_startup(), some setup is done for ttyS0, which causes
irq 4 to fire (in THRE test)
- sir_ir does not realise it was not for it, and spins until the "trapped
in interrupt"
- now serial driver calls setup_irq() and fails and we get the
"Flags mismatch" error.
There is no port present at 0x3e8 so simply check for the presence of a
port, as suggested by Linus.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Tested-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Laurent Caumont [Sat, 11 Nov 2017 17:44:46 +0000 (12:44 -0500)]
media: dvb: i2c transfers over usb cannot be done from stack
commit
6d33377f2abbf9f0e561b116dd468d1c3ff36a6a upstream.
Signed-off-by: Laurent Caumont <lcaumont2@gmail.com>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ville Syrjälä [Wed, 29 Nov 2017 15:37:30 +0000 (17:37 +0200)]
drm/i915: Fix vblank timestamp/frame counter jumps on gen2
commit
a87e55f89f0b0dc541d89248a8445635936a3858 upstream.
Previously I was under the impression that the scanline counter
reads 0 when the pipe is off. Turns out that's not correct, and
instead the scanline counter simply stops when the pipe stops, and
it retains it's last value until the pipe starts up again, at which
point the scanline counter jumps to vblank start.
These jumps can cause the timestamp to jump backwards by one frame.
Since we use the timestamps to guesstimage also the frame counter
value on gen2, that would cause the frame counter to also jump
backwards, which leads to a massice difference from the previous value.
The end result is that flips/vblank events don't appear to complete as
they're stuck waiting for the frame counter to catch up to that massive
difference.
Fix the problem properly by actually making sure the scanline counter
has started to move before we assume that it's safe to enable vblank
processing.
v2: Less pointless duplication in the code (Chris)
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes:
b7792d8b54cc ("drm/i915: Wait for pipe to start before sampling vblank timestamps on gen2")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171129153732.3612-1-ville.syrjala@linux.intel.com
(cherry picked from commit
8fedd64dabc86d0f31a0d1e152be3aa23c323553)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marek Szyprowski [Wed, 22 Nov 2017 13:14:47 +0000 (14:14 +0100)]
drm/exynos: gem: Drop NONCONTIG flag for buffers allocated without IOMMU
commit
120a264f9c2782682027d931d83dcbd22e01da80 upstream.
When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
are contiguous, because of the underlying dma_alloc_attrs() function
provides only such buffers. In such case it makes no sense to keep
BO_NONCONTIG flag for the allocated GEM buffers. This allows to avoid
failures for buffer contiguity checks in the subsequent operations on GEM
objects.
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marek Szyprowski [Tue, 21 Nov 2017 07:49:36 +0000 (08:49 +0100)]
drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback
commit
510353a63796d467b41237ab4f136136f68c297d upstream.
get_modes() callback might be called asynchronously from the DRM core and
it is not synchronized with bridge_enable(), which sets proper runtime PM
state of the main DP device. Fix this by calling pm_runtime_get_sync()
before calling drm_get_edid(), which in turn calls drm_dp_i2c_xfer() and
analogix_dp_transfer() to ensure that main DP device is runtime active
when doing any access to its registers.
This fixes the following kernel issue on Samsung Exynos5250 Snow board:
Unhandled fault: imprecise external abort (0x406) at 0x00000000
pgd =
c0004000
[
00000000] *pgd=
00000000
Internal error: : 406 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 62 Comm: kworker/0:2 Not tainted 4.13.0-rc2-00364-g4a97a3da420b #3357
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: events output_poll_execute
task:
edc14800 task.stack:
edcb2000
PC is at analogix_dp_transfer+0x15c/0x2fc
LR is at analogix_dp_transfer+0x134/0x2fc
pc : [<
c0468538>] lr : [<
c0468510>] psr:
60000013
sp :
edcb3be8 ip :
0000002a fp :
00000001
r10:
00000000 r9 :
edcb3cd8 r8 :
edcb3c40
r7 :
00000000 r6 :
edd3b380 r5 :
edd3b010 r4 :
00000064
r3 :
00000000 r2 :
f0ad3000 r1 :
edcb3c40 r0 :
edd3b010
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
Control:
10c5387d Table:
4000406a DAC:
00000051
Process kworker/0:2 (pid: 62, stack limit = 0xedcb2210)
Stack: (0xedcb3be8 to 0xedcb4000)
[<
c0468538>] (analogix_dp_transfer) from [<
c0424ba4>] (drm_dp_i2c_do_msg+0x8c/0x2b4)
[<
c0424ba4>] (drm_dp_i2c_do_msg) from [<
c0424e64>] (drm_dp_i2c_xfer+0x98/0x214)
[<
c0424e64>] (drm_dp_i2c_xfer) from [<
c057b2d8>] (__i2c_transfer+0x140/0x29c)
[<
c057b2d8>] (__i2c_transfer) from [<
c057b4a4>] (i2c_transfer+0x70/0xe4)
[<
c057b4a4>] (i2c_transfer) from [<
c0441de4>] (drm_do_probe_ddc_edid+0xb4/0x114)
[<
c0441de4>] (drm_do_probe_ddc_edid) from [<
c0441e5c>] (drm_probe_ddc+0x18/0x28)
[<
c0441e5c>] (drm_probe_ddc) from [<
c0445728>] (drm_get_edid+0x124/0x2d4)
[<
c0445728>] (drm_get_edid) from [<
c0465ea0>] (analogix_dp_get_modes+0x90/0x114)
[<
c0465ea0>] (analogix_dp_get_modes) from [<
c0425e8c>] (drm_helper_probe_single_connector_modes+0x198/0x68c)
[<
c0425e8c>] (drm_helper_probe_single_connector_modes) from [<
c04325d4>] (drm_setup_crtcs+0x1b4/0xd18)
[<
c04325d4>] (drm_setup_crtcs) from [<
c04344a8>] (drm_fb_helper_hotplug_event+0x94/0xd0)
[<
c04344a8>] (drm_fb_helper_hotplug_event) from [<
c0425a50>] (drm_kms_helper_hotplug_event+0x24/0x28)
[<
c0425a50>] (drm_kms_helper_hotplug_event) from [<
c04263ec>] (output_poll_execute+0x6c/0x174)
[<
c04263ec>] (output_poll_execute) from [<
c0136f18>] (process_one_work+0x188/0x3fc)
[<
c0136f18>] (process_one_work) from [<
c01371f4>] (worker_thread+0x30/0x4b8)
[<
c01371f4>] (worker_thread) from [<
c013daf8>] (kthread+0x128/0x164)
[<
c013daf8>] (kthread) from [<
c0108510>] (ret_from_fork+0x14/0x24)
Code:
0a000002 ea000009 e2544001 0a00004a (
e59537c8)
---[ end trace
cddc7919c79f7878 ]---
Reported-by: Misha Komarovskiy <zombah@gmail.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Archit Taneja <architt@codeaurora.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20171121074936.22520-1-m.szyprowski@samsung.com
Song Liu [Mon, 20 Nov 2017 06:17:00 +0000 (22:17 -0800)]
md/r5cache: move mddev_lock() out of r5c_journal_mode_set()
commit
ff35f58e8f8eb520367879a0ccc6f2ec4b62b17b upstream.
r5c_journal_mode_set() is called by r5c_journal_mode_store() and
raid_ctr() in dm-raid. We don't need mddev_lock() when calling from
raid_ctr(). This patch fixes this by moves the mddev_lock() to
r5c_journal_mode_store().
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Thompson [Mon, 2 Mar 2015 14:13:36 +0000 (14:13 +0000)]
kdb: Fix handling of kallsyms_symbol_next() return value
commit
c07d35338081d107e57cf37572d8cc931a8e32e2 upstream.
kallsyms_symbol_next() returns a boolean (true on success). Currently
kdb_read() tests the return value with an inequality that
unconditionally evaluates to true.
This is fixed in the obvious way and, since the conditional branch is
supposed to be unreachable, we also add a WARN_ON().
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Arend Van Spriel [Sat, 25 Nov 2017 20:39:25 +0000 (21:39 +0100)]
brcmfmac: change driver unbind order of the sdio function devices
commit
5c3de777bdaf48bd0cfb43097c0d0fb85056cab7 upstream.
In the function brcmf_sdio_firmware_callback() the driver is
unbound from the sdio function devices in the error path.
However, the order in which it is done resulted in a use-after-free
issue (see brcmf_ops_sdio_remove() in bcmsdh.c). Hence change
the order and first unbind sdio function #2 device and then
unbind sdio function #1 device.
Fixes:
7a51461fc2da ("brcmfmac: unbind all devices upon failure in firmware callback")
Reported-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Hante Meuleman <hante.meuleman@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieter-paul.giesberts@broadcom.com>
Reviewed-by: Franky Lin <franky.lin@broadcom.com>
Signed-off-by: Arend van Spriel <arend.vanspriel@broadcom.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Spinadel [Mon, 21 Nov 2016 15:01:25 +0000 (17:01 +0200)]
iwlwifi: mvm: enable RX offloading with TKIP and WEP
commit
9d0fc5a50a0548f8e5d61243e5e5f26d5c405aef upstream.
Set the flag that indicates that ICV was stripped on if
this option was enabled in the HW.
[this is needed for the 9000-series HW to work properly]
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Emmanuel Grumbach [Sun, 19 Nov 2017 08:35:14 +0000 (10:35 +0200)]
iwlwifi: mvm: fix packet injection
commit
b13f43a48571f0cd0fda271b5046b65f1f268db5 upstream.
We need to have a station and a queue for the monitor
interface to be able to inject traffic. We used to have
this traffic routed to the auxiliary queue, but this queue
isn't scheduled for the station we had linked to the
monitor vif.
Allocate a new queue, link it to the monitor vif's station
and make that queue use the BE fifo.
This fixes https://bugzilla.kernel.org/show_bug.cgi?id=196715
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ihab Zhaika [Thu, 16 Nov 2017 07:29:19 +0000 (09:29 +0200)]
iwlwifi: add new cards for 9260 and 22000 series
commit
567deca8e72df3ceb6c07c63f8541a4928f64d3b upstream.
add 1 PCI ID for 9260 series and 1 for 22000 series.
Signed-off-by: Ihab Zhaika <ihab.zhaika@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Mon, 13 Nov 2017 16:26:09 +0000 (17:26 +0100)]
iwlwifi: mvm: flush queue before deleting ROC
commit
6c2d49fdc5d947c5fe89935bd52e69f10000f4cb upstream.
Before deleting a time event (remain-on-channel instance), flush
the queue so that frames cannot get stuck on it. We already flush
the AUX STA queues, but a separate station is used for the P2P
Device queue.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Emmanuel Grumbach [Mon, 13 Nov 2017 07:50:47 +0000 (09:50 +0200)]
iwlwifi: mvm: don't use transmit queue hang detection when it is not possible
commit
0b9832b712d6767d6c7b01965fd788d1ca84fc92 upstream.
When we act as an AP, new firmware versions handle
internally the power saving clients and the driver doesn't
know that the peers went to sleep. It is, hence, possible
that a peer goes to sleep for a long time and stop pulling
frames. This will cause its transmit queue to hang which is
a condition that triggers the recovery flow in the driver.
While this client is certainly buggy (it should have pulled
the frame based on the TIM IE in the beacon), we can't blow
up because of a buggy client.
Change the current implementation to not enable the
transmit queue hang detection on queues that serve peers
when we act as an AP / GO.
We can still enable this mechanism using the debug
configuration which can come in handy when we want to
debug why the client doesn't wake up.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sara Sharon [Mon, 8 Feb 2016 21:30:47 +0000 (23:30 +0200)]
iwlwifi: mvm: mark MIC stripped MPDUs
commit
bf19037074e770aad74b3b90f37b8b98db3f3748 upstream.
When RADA is active, the hardware decrypts the packets and strips off
the MIC as it is useless after decryption. Indicate that to mac80211.
[this is needed for the 9000-series HW to work properly]
Signed-off-by: Sara Sharon <sara.sharon@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Piggin [Wed, 6 Dec 2017 08:21:14 +0000 (18:21 +1000)]
powerpc/64s: Initialize ISAv3 MMU registers before setting partition table
commit
371b80447ff33ddac392c189cf884a5a3e18faeb upstream.
kexec can leave MMU registers set when booting into a new kernel,
the PIDR (Process Identification Register) in particular. The boot
sequence does not zero PIDR, so it only gets set when CPUs first
switch to a userspace processes (until then it's running a kernel
thread with effective PID = 0).
This leaves a window where a process table entry and page tables are
set up due to user processes running on other CPUs, that happen to
match with a stale PID. The CPU with that PID may cause speculative
accesses that address quadrant 0 (aka userspace addresses), which will
result in cached translations and PWC (Page Walk Cache) for that
process, on a CPU which is not in the mm_cpumask and so they will not
be invalidated properly.
The most common result is the kernel hanging in infinite page fault
loops soon after kexec (usually in schedule_tail, which is usually the
first non-speculative quadrant 0 access to a new PID) due to a stale
PWC. However being a stale translation error, it could result in
anything up to security and data corruption problems.
Fix this by zeroing out PIDR at boot and kexec.
Fixes:
7e381c0ff618 ("powerpc/mm/radix: Add mmu context handling callback for radix")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Gibson [Mon, 4 Dec 2017 05:27:25 +0000 (16:27 +1100)]
Revert "powerpc: Do not call ppc_md.panic in fadump panic notifier"
commit
ab9dbf771ff9b6b7e814e759213ed01d7f0de320 upstream.
This reverts commit
a3b2cb30f252b21a6f962e0dd107c8b897ca65e4.
That commit tried to fix problems with panic on powerpc in certain
circumstances, where some output from the generic panic code was being
dropped.
Unfortunately, it breaks things worse in other circumstances. In
particular when running a PAPR guest, it will now attempt to reboot
instead of informing the hypervisor (KVM or PowerVM) that the guest
has crashed. The crash notification is important to some
virtualization management layers.
Revert it for now until we can come up with a better solution.
Fixes:
a3b2cb30f252 ("powerpc: Do not call ppc_md.panic in fadump panic notifier")
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
[mpe: Tweak change log a bit]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Janosch Frank [Mon, 4 Dec 2017 11:19:11 +0000 (12:19 +0100)]
KVM: s390: Fix skey emulation permission check
commit
ca76ec9ca871e67d8cd0b6caba24aca3d3ac4546 upstream.
All skey functions call skey_check_enable at their start, which checks
if we are in the PSTATE and injects a privileged operation exception
if we are.
Unfortunately they continue processing afterwards and perform the
operation anyhow as skey_check_enable does not deliver an error if the
exception injection was successful.
Let's move the PSTATE check into the skey functions and exit them on
such an occasion, also we now do not enable skey handling anymore in
such a case.
Signed-off-by: Janosch Frank <frankja@linux.vnet.ibm.com>
Reviewed-by: Christian Borntraeger <borntraeger@de.ibm.com>
Fixes: a7e19ab ("KVM: s390: handle missing storage-key facility")
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiko Carstens [Wed, 6 Dec 2017 15:11:27 +0000 (16:11 +0100)]
s390: fix compat system call table
commit
e779498df587dd2189b30fe5b9245aefab870eb8 upstream.
When wiring up the socket system calls the compat entries were
incorrectly set. Not all of them point to the corresponding compat
wrapper functions, which clear the upper 33 bits of user space
pointers, like it is required.
Fixes:
977108f89c989 ("s390: wire up separate socketcalls system calls")
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiko Carstens [Mon, 4 Dec 2017 08:42:45 +0000 (09:42 +0100)]
s390/mm: fix off-by-one bug in 5-level page table handling
commit
8d306f53b63099fec2d56300149e400d181ba4f5 upstream.
Martin Cermak reported that setting a uprobe doesn't work. Reason for
this is that the common uprobes code tries to get an unmapped area at
the last possible page within an address space.
This broke with commit
1aea9b3f9210 ("s390/mm: implement 5 level pages
tables") which introduced an off-by-one bug which prevents to map
anything at the last possible page within an address space.
The check with the off-by-one bug however can be removed since with
commit
8ab867cb0806 ("s390/mm: fix BUG_ON in crst_table_upgrade") the
necessary check is done at both call sites.
Reported-by: Martin Cermak <mcermak@redhat.com>
Bisected-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Fixes:
1aea9b3f9210 ("s390/mm: implement 5 level pages tables")
Reviewed-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiko Carstens [Mon, 20 Nov 2017 11:38:44 +0000 (12:38 +0100)]
s390: always save and restore all registers on context switch
commit
fbbd7f1a51965b50dd12924841da0d478f3da71b upstream.
The switch_to() macro has an optimization to avoid saving and
restoring register contents that aren't needed for kernel threads.
There is however the possibility that a kernel thread execve's a user
space program. In such a case the execve'd process can partially see
the contents of the previous process, which shouldn't be allowed.
To avoid this, simply always save and restore register contents on
context switch.
Fixes:
fdb6d070effba ("switch_to: dont restore/save access & fpu regs for kernel threads")
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Lai Jiangshan [Tue, 28 Nov 2017 13:19:53 +0000 (21:19 +0800)]
smp/hotplug: Move step CPUHP_AP_SMPCFD_DYING to the correct place
commit
46febd37f9c758b05cd25feae8512f22584742fe upstream.
Commit
31487f8328f2 ("smp/cfd: Convert core to hotplug state machine")
accidently put this step on the wrong place. The step should be at the
cpuhp_ap_states[] rather than the cpuhp_bp_states[].
grep smpcfd /sys/devices/system/cpu/hotplug/states
40: smpcfd:prepare
129: smpcfd:dying
"smpcfd:dying" was missing before.
So was the invocation of the function smpcfd_dying_cpu().
Fixes:
31487f8328f2 ("smp/cfd: Convert core to hotplug state machine")
Signed-off-by: Lai Jiangshan <jiangshanlai@gmail.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Link: https://lkml.kernel.org/r/20171128131954.81229-1-jiangshanlai@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Robin Murphy [Thu, 28 Sep 2017 14:14:01 +0000 (15:14 +0100)]
iommu/vt-d: Fix scatterlist offset handling
commit
29a90b70893817e2f2bb3cea40a29f5308e21b21 upstream.
The intel-iommu DMA ops fail to correctly handle scatterlists where
sg->offset is greater than PAGE_SIZE - the IOVA allocation is computed
appropriately based on the page-aligned portion of the offset, but the
mapping is set up relative to sg->page, which means it fails to actually
cover the whole buffer (and in the worst case doesn't cover it at all):
(sg->dma_address + sg->dma_len) ----+
sg->dma_address ---------+ |
iov_pfn------+ | |
| | |
v v v
iova: a b c d e f
|--------|--------|--------|--------|--------|
<...calculated....>
[_____mapped______]
pfn: 0 1 2 3 4 5
|--------|--------|--------|--------|--------|
^ ^ ^
| | |
sg->page ----+ | |
sg->offset --------------+ |
(sg->offset + sg->length) ----------+
As a result, the caller ends up overrunning the mapping into whatever
lies beyond, which usually goes badly:
[ 429.645492] DMAR: DRHD: handling fault status reg 2
[ 429.650847] DMAR: [DMA Write] Request device [02:00.4] fault addr
f2682000 ...
Whilst this is a fairly rare occurrence, it can happen from the result
of intermediate scatterlist processing such as scatterwalk_ffwd() in the
crypto layer. Whilst that particular site could be fixed up, it still
seems worthwhile to bring intel-iommu in line with other DMA API
implementations in handling this robustly.
To that end, fix the intel_map_sg() path to line up the mapping
correctly (in units of MM pages rather than VT-d pages to match the
aligned_nrpages() calculation) regardless of the offset, and use
sg_phys() consistently for clarity.
Reported-by: Harsh Jain <Harsh@chelsio.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed by: Ashok Raj <ashok.raj@intel.com>
Tested by: Jacob Pan <jacob.jun.pan@intel.com>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jaejoong Kim [Mon, 4 Dec 2017 06:31:49 +0000 (15:31 +0900)]
ALSA: usb-audio: Add check return value for usb_string()
commit
89b89d121ffcf8d9546633b98ded9d18b8f75891 upstream.
snd_usb_copy_string_desc() returns zero if usb_string() fails.
In case of failure, we need to check the snd_usb_copy_string_desc()'s
return value and add an exception case
Signed-off-by: Jaejoong Kim <climbbb.kim@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jaejoong Kim [Mon, 4 Dec 2017 06:31:48 +0000 (15:31 +0900)]
ALSA: usb-audio: Fix out-of-bound error
commit
251552a2b0d454badc8f486e6d79100970c744b0 upstream.
The snd_usb_copy_string_desc() retrieves the usb string corresponding to
the index number through the usb_string(). The problem is that the
usb_string() returns the length of the string (>= 0) when successful, but
it can also return a negative value about the error case or status of
usb_control_msg().
If iClockSource is '0' as shown below, usb_string() will returns -EINVAL.
This will result in '0' being inserted into buf[-22], and the following
KASAN out-of-bound error message will be output.
AudioControl Interface Descriptor:
bLength 8
bDescriptorType 36
bDescriptorSubtype 10 (CLOCK_SOURCE)
bClockID 1
bmAttributes 0x07 Internal programmable Clock (synced to SOF)
bmControls 0x07
Clock Frequency Control (read/write)
Clock Validity Control (read-only)
bAssocTerminal 0
iClockSource 0
To fix it, check usb_string()'return value and bail out.
==================================================================
BUG: KASAN: stack-out-of-bounds in parse_audio_unit+0x1327/0x1960 [snd_usb_audio]
Write of size 1 at addr
ffff88007e66735a by task systemd-udevd/18376
CPU: 0 PID: 18376 Comm: systemd-udevd Not tainted 4.13.0+ #3
Hardware name: LG Electronics 15N540-RFLGL/White Tip Mountain, BIOS 15N5
Call Trace:
dump_stack+0x63/0x8d
print_address_description+0x70/0x290
? parse_audio_unit+0x1327/0x1960 [snd_usb_audio]
kasan_report+0x265/0x350
__asan_store1+0x4a/0x50
parse_audio_unit+0x1327/0x1960 [snd_usb_audio]
? save_stack+0xb5/0xd0
? save_stack_trace+0x1b/0x20
? save_stack+0x46/0xd0
? kasan_kmalloc+0xad/0xe0
? kmem_cache_alloc_trace+0xff/0x230
? snd_usb_create_mixer+0xb0/0x4b0 [snd_usb_audio]
? usb_audio_probe+0x4de/0xf40 [snd_usb_audio]
? usb_probe_interface+0x1f5/0x440
? driver_probe_device+0x3ed/0x660
? build_feature_ctl+0xb10/0xb10 [snd_usb_audio]
? save_stack_trace+0x1b/0x20
? init_object+0x69/0xa0
? snd_usb_find_csint_desc+0xa8/0xf0 [snd_usb_audio]
snd_usb_mixer_controls+0x1dc/0x370 [snd_usb_audio]
? build_audio_procunit+0x890/0x890 [snd_usb_audio]
? snd_usb_create_mixer+0xb0/0x4b0 [snd_usb_audio]
? kmem_cache_alloc_trace+0xff/0x230
? usb_ifnum_to_if+0xbd/0xf0
snd_usb_create_mixer+0x25b/0x4b0 [snd_usb_audio]
? snd_usb_create_stream+0x255/0x2c0 [snd_usb_audio]
usb_audio_probe+0x4de/0xf40 [snd_usb_audio]
? snd_usb_autosuspend.part.7+0x30/0x30 [snd_usb_audio]
? __pm_runtime_idle+0x90/0x90
? kernfs_activate+0xa6/0xc0
? usb_match_one_id_intf+0xdc/0x130
? __pm_runtime_set_status+0x2d4/0x450
usb_probe_interface+0x1f5/0x440
Signed-off-by: Jaejoong Kim <climbbb.kim@gmail.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Thu, 30 Nov 2017 09:08:28 +0000 (10:08 +0100)]
ALSA: seq: Remove spurious WARN_ON() at timer check
commit
43a3542870328601be02fcc9d27b09db467336ef upstream.
The use of snd_BUG_ON() in ALSA sequencer timer may lead to a spurious
WARN_ON() when a slave timer is deployed as its backend and a
corresponding master timer stops meanwhile. The symptom was triggered
by syzkaller spontaneously.
Since the NULL timer is valid there, rip off snd_BUG_ON().
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Robb Glasser [Tue, 5 Dec 2017 17:16:55 +0000 (09:16 -0800)]
ALSA: pcm: prevent UAF in snd_pcm_info
commit
362bca57f5d78220f8b5907b875961af9436e229 upstream.
When the device descriptor is closed, the `substream->runtime` pointer
is freed. But another thread may be in the ioctl handler, case
SNDRV_CTL_IOCTL_PCM_INFO. This case calls snd_pcm_info_user() which
calls snd_pcm_info() which accesses the now freed `substream->runtime`.
Note: this fixes CVE-2017-0861
Signed-off-by: Robb Glasser <rglasser@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kailang Yang [Tue, 5 Dec 2017 07:38:24 +0000 (15:38 +0800)]
ALSA: hda/realtek - New codec support for ALC257
commit
f429e7e494afaded76e62c6f98211a635aa03098 upstream.
Add new support for ALC257 codec.
[ It's supposed to be almost equivalent with other ALC25x variants,
just adding another type and id -- tiwai ]
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeff Mahoney [Tue, 21 Nov 2017 18:58:49 +0000 (13:58 -0500)]
btrfs: handle errors while updating refcounts in update_ref_for_cow
commit
692826b2738101549f032a761a9191636e83be4e upstream.
Since commit
fb235dc06fa (btrfs: qgroup: Move half of the qgroup
accounting time out of commit trans) the assumption that
btrfs_add_delayed_{data,tree}_ref can only return 0 or -ENOMEM has
been false. The qgroup operations call into btrfs_search_slot
and friends and can now return the full spectrum of error codes.
Fortunately, the fix here is easy since update_ref_for_cow failing
is already handled so we just need to bail early with the error
code.
Fixes:
fb235dc06fa (btrfs: qgroup: Move half of the qgroup accounting ...)
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Edmund Nadolski <enadolski@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jeff Mahoney [Mon, 4 Dec 2017 18:11:45 +0000 (13:11 -0500)]
btrfs: fix missing error return in btrfs_drop_snapshot
commit
e19182c0fff451e3744c1107d98f072e7ca377a0 upstream.
If btrfs_del_root fails in btrfs_drop_snapshot, we'll pick up the
error but then return 0 anyway due to mixing err and ret.
Fixes:
79787eaab4612 ("btrfs: replace many BUG_ONs with proper error handling")
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Radim Krčmář [Thu, 30 Nov 2017 18:05:45 +0000 (19:05 +0100)]
KVM: x86: fix APIC page invalidation
commit
b1394e745b9453dcb5b0671c205b770e87dedb87 upstream.
Implementation of the unpinned APIC page didn't update the VMCS address
cache when invalidation was done through range mmu notifiers.
This became a problem when the page notifier was removed.
Re-introduce the arch-specific helper and call it from ...range_start.
Reported-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Fixes:
38b9917350cb ("kvm: vmx: Implement set_apic_access_page_addr")
Fixes:
369ea8242c0f ("mm/rmap: update to new mmu_notifier semantic v2")
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Reviewed-by: Andrea Arcangeli <aarcange@redhat.com>
Tested-by: Wanpeng Li <wanpeng.li@hotmail.com>
Tested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>