14 Dec, 2017
40 commits
-
[ 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
-> IRQswap 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
Acked-by: Minchan Kim
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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()
Reviewed-by: Steven Sistare
Reviewed-by: Daniel Jordan
Reviewed-by: Bob Picco
Acked-by: David S. Miller
Acked-by: Michal Hocko
Cc: Alexander Potapenko
Cc: Andrey Ryabinin
Cc: Ard Biesheuvel
Cc: Catalin Marinas
Cc: Christian Borntraeger
Cc: Dmitry Vyukov
Cc: Heiko Carstens
Cc: "H. Peter Anvin"
Cc: Ingo Molnar
Cc: Mark Rutland
Cc: Matthew Wilcox
Cc: Mel Gorman
Cc: Michal Hocko
Cc: Sam Ravnborg
Cc: Thomas Gleixner
Cc: Will Deacon
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Signed-off-by: Jens Axboe
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Signed-off-by: Rob Herring
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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: [] 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
Signed-off-by: Darrick J. Wong
Reviewed-by: Christoph Hellwig
Reviewed-by: Omar Sandoval
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Reviewed-by: Jakub Kicinski
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Reviewed-by: Jakub Kicinski
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Signed-off-by: Anna Schumaker
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Signed-off-by: Anna Schumaker
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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 failedLink: http://lkml.kernel.org/r/10a6a101-e2be-209f-1f41-54637824788e@infradead.org
Signed-off-by: Randy Dunlap
Acked-by: Jason Baron
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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 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
Reviewed-by: Logan Gunthorpe
Reviewed-by: Mathieu Desnoyers
Reviewed-by: Daniel Mentz
Cc: Jonathan Corbet
Cc: Andrew Morton
Cc: Will Deacon
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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=2This 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
-2147483648Use 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
Reported-by: Mikulas Patocka
Reviewed-by: Mikulas Patocka
Cc: Michael Kerrisk
Cc: Randy Dunlap
Cc: Al Viro
Cc: Jens Axboe
Cc: Josh Poimboeuf
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
…th 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> -
[ 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
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Acked-by: Hannes Frederic Sowa
Signed-off-by: Xin Long
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Signed-off-by: Xin Long
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Signed-off-by: Johannes Berg
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Acked-by: Thomas Gleixner
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20171111001229.58A7933D@viggo.jf.intel.com
Signed-off-by: Ingo Molnar
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ Upstream commit 4633307e5ed6128975595df43f796a10c41d11c1 ]
Fixes: d07881d2edb0 ("apparmor: move new_null_profile to after profile lookup fns()")
Reported-by: Seth Arnold
Signed-off-by: John Johansen
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Signed-off-by: Michael Ellerman
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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 is given and 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
Acked-by: Julia Lawall
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Reviewed-by: Hans Wippel
Signed-off-by: David S. Miller
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
[ 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
Signed-off-by: Thomas Gleixner
Cc: Marc Zyngier
Cc: kernel-janitors@vger.kernel.org
Cc: Jason Cooper
Link: https://lkml.kernel.org/r/20171117183553.2739-1-colin.king@canonical.com
Signed-off-by: Sasha Levin
Signed-off-by: Greg Kroah-Hartman -
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
Cc: Alex Shi
Signed-off-by: Greg Kroah-Hartman -
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
Cc: Alex Shi
Signed-off-by: Greg Kroah-Hartman -
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 95This patch fixes the descriptor type which is special for CTR AES
Fixes: 5e75ae1b3cef6 ("crypto: talitos - add new crypto modes")
Signed-off-by: Christophe Leroy
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
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
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
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=22This 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
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
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=100This is due to setkey being expected to detect weak keys.
Signed-off-by: Christophe Leroy
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
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 freedThis patch reworks the handling of the CICV out in order
to properly handle all cases.Signed-off-by: Christophe Leroy
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
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 dcThis patch fixes that.
Signed-off-by: Christophe Leroy
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
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
Cc: Don Dutile
Reported-by: Potnuri Bharat Teja
Fixes: d291f1a65232("IB/core: Enforce PKey security on QPs")
Fixes: 47a2b338fe63("IB/core: Enforce security on management datagrams")
Signed-off-by: Daniel Jurgens
Reviewed-by: Parav Pandit
Tested-by: Potnuri Bharat Teja
Signed-off-by: Leon Romanovsky
Signed-off-by: Jason Gunthorpe
Signed-off-by: Greg Kroah-Hartman -
commit 2e4c85c6edc80fa532b2c7e1eb3597ef4d4bbb8f upstream.
Since there is nothing done with non zero return value, such check is
avoided.Signed-off-by: Parav Pandit
Reviewed-by: Daniel Jurgens
Signed-off-by: Leon Romanovsky
Signed-off-by: Doug Ledford
Signed-off-by: Greg Kroah-Hartman -
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 : [] lr : [] 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] [] __cpuhp_remove_state_cpuslocked+0x454/0x4f0
[ 268.748580] [] __cpuhp_remove_state+0x54/0x80
[ 268.748597] [] arm_ccn_exit+0x2c/0x70 [arm_ccn]
[ 268.748604] [] 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] [] __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
Acked-by: Sebastian Andrzej Siewior
Signed-off-by: Pawel Moll
Signed-off-by: Greg Kroah-Hartman -
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:
[] dump_backtrace+0x0/0x278
[] show_stack+0x24/0x30
[] dump_stack+0x8c/0xb0
[] check_preemption_disabled+0xfc/0x100
[] debug_smp_processor_id+0x1c/0x28
[] 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
Acked-by: Mark Rutland
Signed-off-by: Pawel Moll
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Scott Branden
Signed-off-by: Pawel Moll
Signed-off-by: Greg Kroah-Hartman -
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
Acked-by: Mark Rutland
Signed-off-by: Pawel Moll
Signed-off-by: Greg Kroah-Hartman -
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
Suggested-by: Juergen Borleis
Signed-off-by: Fabio Estevam
Signed-off-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman
